Compiler bug with bitfields

Compiler bug with bitfields

[libreknight]

Greetings.

I have come across erroneous behavior whilst comparing optimizations
performed by different compilers. Said behavior persists through
different versions of GCC and flags. The output from GCC is incorrect
and diverges from all compilers.

In order to reproduce aforementioned behavior, compile with any flags of
your liking the following code:

#include <stdio.h>
#include <stdlib.h>

typedef struct
{
  unsigned char value:1;
} boolean;

int
main (void)
{
  boolean var;

  var.value = 0;

  printf ("%d %d\n", --var.value, --var.value);

  return EXIT_SUCCESS;
}

The outcome disparates from the expected by producing the opposite
result.

GCC:
0 1

clang, tcc, icc, icx, msvc, compcert:
1 0

Inasmuch as the potential consequences of faulty logic allows for
undefined behavior, security vulnerabilities emerges. Nevertheless,
acknowledging the atypicality of causal application, I evaluate the
significance of low-medium priority.

Thanks in advance.

Re: Compiler bug with bitfields

[Andrew Pinski]

On Thu, Aug 24, 2023 at 8:06 PM libreknight via Gcc-bugs
<gcc-bugs@gcc.gnu.org> wrote:
>
> Greetings.
>
> I have come across erroneous behavior whilst comparing optimizations
> performed by different compilers. Said behavior persists through
> different versions of GCC and flags. The output from GCC is incorrect
> and diverges from all compilers.
>
> In order to reproduce aforementioned behavior, compile with any flags of
> your liking the following code:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> typedef struct
> {
>   unsigned char value:1;
> } boolean;
>
> int
> main (void)
> {
>   boolean var;
>
>   var.value = 0;
>
>   printf ("%d %d\n", --var.value, --var.value);


GCC does produce a warning:
<source>: In function 'main':
<source>:16:35: warning: operation on 'var.value' may be undefined
[-Wsequence-point]
   16 |   printf ("%d %d\n", --var.value, --var.value);
      |                                   ^~~~~~~~~~~


Anyways the order of evaluation is not specified in the C standard
when it comes to function arguments; left to right or right to left is
both valid.

Thanks,
Andrew Pinski

>
>   return EXIT_SUCCESS;
> }
>
> The outcome disparates from the expected by producing the opposite
> result.
>
> GCC:
> 0 1
>
> clang, tcc, icc, icx, msvc, compcert:
> 1 0
>
> Inasmuch as the potential consequences of faulty logic allows for
> undefined behavior, security vulnerabilities emerges. Nevertheless,
> acknowledging the atypicality of causal application, I evaluate the
> significance of low-medium priority.
>
> Thanks in advance.

Re: Compiler bug with bitfields

[libreknight]

On 2023-08-25 03:06, libreknight wrote:
> Greetings.
> 
> I have come across erroneous behavior whilst comparing optimizations
> performed by different compilers. Said behavior persists through
> different versions of GCC and flags. The output from GCC is incorrect
> and diverges from all compilers.
> 
> In order to reproduce aforementioned behavior, compile with any flags of
> your liking the following code:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> typedef struct
> {
>   unsigned char value:1;
> } boolean;
> 
> int
> main (void)
> {
>   boolean var;
> 
>   var.value = 0;
> 
>   printf ("%d %d\n", --var.value, --var.value);
> 
>   return EXIT_SUCCESS;
> }
> 
> The outcome disparates from the expected by producing the opposite
> result.
> 
> GCC:
> 0 1
> 
> clang, tcc, icc, icx, msvc, compcert:
> 1 0
> 
> Inasmuch as the potential consequences of faulty logic allows for
> undefined behavior, security vulnerabilities emerges. Nevertheless,
> acknowledging the atypicality of causal application, I evaluate the
> significance of low-medium priority.
> 
> Thanks in advance.
My apologies, further testing has confirmed this has nothing to do with
bitfields. I could replicate this experiment with "normal" variables and
the outcome from gcc compiled binaries still differs. From what it
seems, it is a already known undefined behavior practice
(https://stackoverflow.com/questions/4706404/post-pre-increments-in-printf).

Sorry for any inconvenience.