Questions about GCC 3.3 strict aliasing warning

Questions about GCC 3.3 strict aliasing warning

[Jonathan Lennox]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 319 bytes --]

Hello, all:

I've got existing code that defines an "object" API in C.  This API defines
opaque objects which are operated on by a library, but which also permit
user-specific data to accompany the objects.  These objects are accessed via
void* pointers passed by the library.

Here's a simplified version of the code:

[-- Attachment #2: objectref.c --]
[-- Type: text/plain, Size: 820 bytes --]

/* Stripped-down API equivalent */
typedef struct object object;

typedef int errcode;

extern errcode SetUserContext(object* obj, void* user_context);
extern errcode GetUserContext(object* obj, void** user_context);


/* API-using code */

typedef struct my_user_context my_user_context;

extern my_user_context* AllocMyUserContext(void);

void my_set_func(object* the_object)
{
  my_user_context* uc;
  errcode err;

  uc = AllocMyUserContext();

  err = SetUserContext(the_object, (void*)uc);
}

void my_get_func(object* the_object)
{
  my_user_context* uc;
  errcode err;

  /* Breaks strict aliasing rules? */
  err = GetUserContext(the_object, (void**)&uc);
}


void my_get_func2(object* the_object)
{
  my_user_context* uc;
  void* uc_v;
  errcode err;

  err = GetUserContext(the_object, &uc_v);
  uc = uc_v;
}


[-- Attachment #3: message body and .signature --]
[-- Type: text/plain, Size: 2491 bytes --]


Now, up through GCC 3.2.x, this code produced no warnings.  However, as of
GCC 3.3.x, the line
      err = GetUserContext(the_object, (void**)&uc);
produces the warning
objectref.c:31: warning: dereferencing type-punned pointer will break strict-aliasing rules

I have several questions:
1.  Is the function my_get_func() indeed non-conformant C?

2.  Might GCC actually mis-compile it?  (It seems like it would need
    inter-module optimization to do so, assuming GetUserContext isn't an
    inline function and that all object pointers have the same
    representation.)

3.  Is the function my_get_func2() conformant?  (It generates no -W -Wall
    warnings with GCC 3.2.2.)

4.  Is there any way to write this code conformantly without needing the
    intermediate void* variable?

5.  If not, will GCC (with -O2) always realize that the void* variable is
    unnecessary, and optimize it out?

Thanks.

I've included the output of gcc -v below.

$ gcc -v -Wall -g -O2 -c objectref.c
Reading specs from /home/lennox/Proj/New-GNU/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs
Configured with: /home/lennox/Proj/NoBackup/build/gcc-3.3.2/configure --prefix=/home/lennox/Proj/New-GNU --with-gnu-as --with-as=/usr/local/gnu/bin/as --with-gnu-ld --with-ld=/usr/local/gnu/bin/ld --enable-version-specific-runtime-libs
Thread model: posix
gcc version 3.3.2
 /home/lennox/Proj/New-GNU/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/cc1 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 -Dsparc -D__sparc__ -D__sparc -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc objectref.c -quiet -dumpbase objectref.c -auxbase objectref -g -O2 -Wall -version -o /var/tmp//cc1j4kMI.s
GNU C version 3.3.2 (sparc-sun-solaris2.8)
        compiled by GNU C version 3.3.2.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
ignoring nonexistent directory "/home/lennox/Proj/New-GNU/sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/lennox/Proj/New-GNU/include
 /home/lennox/Proj/New-GNU/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/include
 /usr/include
End of search list.
objectref.c: In function `my_get_func':
objectref.c:32: warning: dereferencing type-punned pointer will break strict-aliasing rules
 /usr/local/gnu/bin/as -V -Qy -s -o objectref.o /var/tmp//cc1j4kMI.s
GNU assembler version 2.13.2.1 (sparc-sun-solaris2.8) using BFD version 2.13.2.1

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Re: Questions about GCC 3.3 strict aliasing warning

[Falk Hueffner]

Jonathan Lennox <lennox@cs.columbia.edu> writes:

> void my_get_func(object* the_object)
> {
>   my_user_context* uc;
>   errcode err;
> 
>   /* Breaks strict aliasing rules? */
>   err = GetUserContext(the_object, (void**)&uc);
> }
> 
> Now, up through GCC 3.2.x, this code produced no warnings.  However, as of
> GCC 3.3.x, the line
>       err = GetUserContext(the_object, (void**)&uc);
> produces the warning
> objectref.c:31: warning: dereferencing type-punned pointer will break strict-aliasing rules
> 
> I have several questions:
> 1.  Is the function my_get_func() indeed non-conformant C?

No. However, GetUserContext is if it actually dereferences its
argument. In other words, the warning is correct.

> 2.  Might GCC actually mis-compile it?  (It seems like it would need
>     inter-module optimization to do so, assuming GetUserContext isn't an
>     inline function and that all object pointers have the same
>     representation.)

Correct. However, future gccs might have inter-module optimizations.

> 3.  Is the function my_get_func2() conformant?  (It generates no -W -Wall
>     warnings with GCC 3.2.2.)

Looks OK to me.

> 4.  Is there any way to write this code conformantly without needing the
>     intermediate void* variable?

Have it return the void*, and use NULL to indicate an error.

> 5.  If not, will GCC (with -O2) always realize that the void* variable is
>     unnecessary, and optimize it out?

Very likely yes. You could check the assembly to verify.

-- 
	Falk