#1624 BUG on Structure operation and assignment

closed-invalid
nobody
gcc (462)
2012-02-15
2012-02-15
INTERGVE
No

I use MinGW 4.6.1 combined with code::blocks IDE.
-------------------------------------------------------------------
GCC version:
Utilisation des specs internes.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe
Target: mingw32
Configuré avec: ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-ver
sion-specific-runtime-libs --build=mingw32 --prefix=/mingw
Modèle de thread: win32
gcc version 4.6.1 (GCC)

I think I found a BUG on a special operation and assignment with a Structure.
The bug is in this special assignment: VAR.B *= (--VAR.B); when VAR.B is a field of a structure.
If VAR_B was just a variable, the bug is not present (the result of VAR_B *= (--VAR_B); is correct).

By initializing the field VAR.B to 256, the result of the operation VAR.B *= (--VAR.B) should be 65025 (=255*255). But the current result is 65280 (=255*256).

I join to this description a C-code that does not work.

Discussion

  • INTERGVE
    INTERGVE
    2012-02-15

    C-code to see the BUG

     
    Attachments
  • INTERGVE
    INTERGVE
    2012-02-15

    • priority: 5 --> 9
     
  • Earnie Boyd
    Earnie Boyd
    2012-02-15

    • priority: 9 --> 1
     
  • Earnie Boyd
    Earnie Boyd
    2012-02-15

    This issue is verified but I don't have the C specifications available to check how the decrement of VAR.B in ``VAR.B *= (--VAR.B);'' should occur. If this is changed to:

    --VAR.B;
    VAR.B *= VAR.B;

    Then the result is as the OP expected.

    I'm guessing though that the result with the structure is correct and the result with the variable is incorrect but it still depends on the language of the C spec.

    Also the result is inconsistent if you use -O2 optimization and the result from the structure is the same as from the variable.

     
  • INTERGVE
    INTERGVE
    2012-02-15

    Thanks for the answer.

    I think (but I’m not sure) that the result with the Structure is correct. I used other targets and the result was always 255*255 (when VAR.B is initialized to 256). Even when I use an older version of gcc (3.2.3), the operation is 255*255.

    I was not using the –O2 option. After you answer, I try to use it and strangely, the result is as I expected (255*255).

     
  • Keith Marshall
    Keith Marshall
    2012-02-15

    • status: open --> closed-invalid
     
  • Keith Marshall
    Keith Marshall
    2012-02-15

    Shouting BUG at me, on a bug tracking system, isn't going to grab my attention. Attempting to escalate priority, (which is *my* prerogative, not yours), is always going to achieve the reverse effect.

    > I think (but I’m not sure) ...

    Well, I am 100% certain ...

    > that the result with the Structure is correct.

    ...that it is not *necessarily* so. See, the result of any expression resembling

    foo = --foo;

    is *always* undefined; it may be the result you expected; it may equally well be anything at all. As I understand the C/C++ standards, your ...

    VAR.B *= (--VAR.B);

    is a classical example of this *invalid* code construct, which results in undefined behaviour; (irrespective of parentheses, there is no guarantee as to whether the pre-decrement of VAR.B will be performed before or after the multiplicative assignment; the statement is ambiguous, and its result is undefined).

    > I used other targets and the result was always 255*255 (when VAR.B is
    > initialized to 256). Even when I use an older version of gcc (3.2.3), the
    > operation is 255*255.

    This is irrelevant: when behaviour is undefined, any outcome is "correct".

    Since this alleged bug relates to your invalid code, in cannot be classified as a MinGW bug; it is yours, and yours alone.