From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29346 invoked by alias); 16 Dec 2003 01:42:34 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 29272 invoked from network); 16 Dec 2003 01:42:32 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 16 Dec 2003 01:42:32 -0000 Received: from [128.59.16.20] (helo=cs.columbia.edu) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AW55S-0003bx-LY for gcc-help@gcc.gnu.org; Mon, 15 Dec 2003 21:37:26 -0500 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hBG1YoiF016788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Dec 2003 20:34:50 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.9p1/8.12.9) with ESMTP id hBG1YXMT031919 for ; Mon, 15 Dec 2003 20:34:33 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.9p1/8.12.9/Submit) id hBG1YXvd031916; Mon, 15 Dec 2003 20:34:33 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="F0JvvM3Y7d" Content-Transfer-Encoding: 7bit Message-ID: <16350.24873.420914.525540@cnr.cs.columbia.edu> Date: Tue, 16 Dec 2003 01:42:00 -0000 To: gcc-help@gcc.gnu.org Subject: Questions about GCC 3.3 strict aliasing warning X-SW-Source: 2003-12/txt/msg00149.txt.bz2 --F0JvvM3Y7d Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Content-length: 319 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: --F0JvvM3Y7d Content-Type: text/plain Content-Disposition: inline; filename="objectref.c" Content-Transfer-Encoding: 7bit Content-length: 820 /* 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; } --F0JvvM3Y7d Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Content-length: 2491 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 --F0JvvM3Y7d--