No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

[Anders Torger]

/*

  on x86, sizeof(long long) == 8, sizeof(long) == 4
  
  Ok, I'm back. While fixing my strict aliasing breakerage as Andreas 
  told me to, I found a case where GCC does not warn even with
  -Wstrict-aliasing, but makes incorrect asm code anyway. So I started
  to investigate which optimisation flags in -O2 that causes the
  problem, and have again made a small dummy program demonstrating the
  error:

  gcc -O2 -Wstrict-aliasing -Wall -S test.c

  with all documented optimisation flags included in -O2 enabled
  (including -fstrict-aliasing), the error still does not occur.
  However, with -O2 alone, GCC makes the mistake:
  
  hash:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        movl    -4(%ebp), %eax
        xorl    -8(%ebp), %eax
        leave
        ret
          
  The compiler allocates stack space, and uses it, but without 
  putting anything into it first.

  Debian Linux Pentium 4 system, gcc installed from package system
  from unstable as of 9 Nov 2004.

  gcc -O2 -Wstrict-aliasing -Wall -S test.c

  no messages are generated at compilation. I'm not sure if I have
  understood the strict aliasing rules, but I think the code below
  does violate them (by casting an uint64 array to an uint32 array), 
  although GCC does not think so.

  gcc 2.95 generates correct code.
  gcc 3.2.3 fails
  gcc 3.3.5 fails
  gcc 3.4.2 fails

  /Anders Torger
  
 */

#include <stdio.h>

unsigned long
hash(void *key)
{
    unsigned long long u[1];
    u[0] = *(unsigned long long *)key;
    return ((unsigned long *)u)[0] ^ ((unsigned long *)u)[1];
}

int
main(void)
{
    unsigned long long ull;

    ull = 0xDEADBEAF;
    
    fprintf(stderr, "%08lX\n", hash(&ull));
    return 0;
}

Re: No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

[Andrew Pinski]

On Nov 9, 2004, at 2:23 PM, Anders Torger wrote:

>   gcc 2.95 generates correct code.

It just generates code which you expected not the code which
the C standard says it is undefined (oh by the way we could wipe
your HD if you invoke undefined behavior).

Also a DR report says we cannot error out on undefined code
because it might not execute at all.

Thanks,
Andrew Pinski

Re: No warning when breaking strict-aliasing rules despite -Wstrict-aliasing

[Giovanni Bajo]

Anders Torger <torger@ludd.luth.se> wrote:

>   I found a case where GCC does not warn even with
>   -Wstrict-aliasing, but makes incorrect asm code anyway.

> unsigned long
> hash(void *key)
> {
>     unsigned long long u[1];
>     u[0] = *(unsigned long long *)key;
>     return ((unsigned long *)u)[0] ^ ((unsigned long *)u)[1];
> }

There is absolutely no guarantee that we always generate a warning for every
possible type-aliasing violation. For instance, if you passed the pointer to a
double as "key" to this function, we could not possibly find it out and emit a
warning.

Nonetheless, there is a problem here: we could easily emit a warning on this
line:

>     return ((unsigned long *)u)[0] ^ ((unsigned long *)u)[1];

but we do not. The problem appears to be in c-typeck.c, in build_c_cast():

      if (TREE_CODE (type) == POINTER_TYPE
          && TREE_CODE (otype) == POINTER_TYPE
          && TREE_CODE (expr) == ADDR_EXPR
          && DECL_P (TREE_OPERAND (expr, 0))
          && flag_strict_aliasing && warn_strict_aliasing
          && !VOID_TYPE_P (TREE_TYPE (type)))

The code only warns for expressions like  "(cast*)&decl", but
"(cast*)array_decl" is also something to warn about.

This is a possible enhancement. Would you please file a bug report in Bugzilla
about this?

Thanks,
Giovanni Bajo