Re: gcc 4.0.0 on amd64: problem with -O2?

2005-05-08 Thread Harald Dunkel
Andrew Pinski wrote:

 Wrong, try again.  Violating aliasing rules cause undefined behavior
 so seg faulting is an okay thing to do.

But producing a warning message and bad code is not OK. Either
using a type-punned pointer should be treated as a fatal
error, because gcc would create bad code, or gcc should create
working code.

If gcc knows that the code is bad, why does it continue?


Regards

Harri


signature.asc
Description: OpenPGP digital signature


Re: gcc 4.0.0 on amd64: problem with -O2?

2005-05-08 Thread Harald Dunkel
Falk Hueffner wrote:

 It doesn't know that. The warning is for the *creation* of the
 type-punned pointer, which is still perfectly fine. Gcc is too stupid
 to notice whether you actually dereference it.


Yup. There are billions of this constructs in everbodies
and his moms source files. By now ( 4.0.0) this did not
hurt.


Regards

Harri


signature.asc
Description: OpenPGP digital signature


gcc 4.0.0 on amd64: problem with -O2?

2005-05-07 Thread Harald Dunkel
Hi folks,


The attached testcase dies on Debian (amd64) if
compiled with -O2.

Here is the usual data:

% gcc -v
Using built-in specs.
Target: x86_64-linux
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--libexecdir=/usr/lib --enable-shared --with-system-zlib --enable-nls 
--enable-threads=posix --without-included-gettext --program-suffix=-4.0 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm 
--enable-java-awt=gtk --enable-mpfr --disable-werror --enable-checking=release 
x86_64-linux
Thread model: posix
gcc version 4.0.0 (Debian 4.0.0-1)
% gcc -O -o testcase testcase.c
% ./testcase
Data: 42
% gcc -O2 -o testcase testcase.c
% ./testcase
Segmentation fault (core dumped)


The testcase has been created by grabbing some code
fragments from libX11, XFree86 4.3 on Debian, amd64.
-Wall complains about dereferencing type-punned pointer.

Is this a known problem? I haven't seen it in the database.


Regards

Harri
#include stdio.h

typedef struct _XDisplay Display;

typedef union {
	Display *display;
	void *gc;
	void *visual;
	void *screen;
	void *pixmap_format;
	void *font; } XEDataObject;


typedef struct _XExtData {
	int number;		/* number returned by XRegisterExtension */
	struct _XExtData *next;	/* next item on list of data for structure */
	int (*free_private)(	/* called to free private storage */
	struct _XExtData *extension
	);
	void * private_data;	/* data private to this extension. */
} XExtData;


struct _XDisplay
{
	XExtData *ext_data;	/* hook for extension to hang data */
	int data;		/* Network socket. */
};


XExtData **XEHeadOfExtensionList(object)
XEDataObject object;
{
return *(XExtData ***)object;
}


void _XF86BigfontCodes (dpy)
register Display *dpy;
{
XEDataObject dpy_union;
XExtData **pData;

dpy_union.display = dpy;

pData = XEHeadOfExtensionList(dpy_union);
printf(Data: %d\n, (*pData)-number);
}

int main()
{
	XExtData extdata_in_main;
	Display dpy = {
		extdata_in_main,
		0xdeadbeef,
	};
	extdata_in_main.number = 42;
	extdata_in_main.next   =  0;
	_XF86BigfontCodes(dpy);
	return 0;
}
# 1 testcase.c
# 1 built-in
# 1 command line
# 1 testcase.c
# 1 /usr/include/stdio.h 1 3 4
# 28 /usr/include/stdio.h 3 4
# 1 /usr/include/features.h 1 3 4
# 308 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 309 /usr/include/features.h 2 3 4
# 331 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 332 /usr/include/features.h 2 3 4
# 29 /usr/include/stdio.h 2 3 4





# 1 /usr/lib/gcc/x86_64-linux/4.0.0/include/stddef.h 1 3 4
# 214 /usr/lib/gcc/x86_64-linux/4.0.0/include/stddef.h 3 4
typedef long unsigned int size_t;
# 35 /usr/include/stdio.h 2 3 4

# 1 /usr/include/bits/types.h 1 3 4
# 28 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 29 /usr/include/bits/types.h 2 3 4


# 1 /usr/lib/gcc/x86_64-linux/4.0.0/include/stddef.h 1 3 4
# 32 /usr/include/bits/types.h 2 3 4


typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;


typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;

typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;







typedef long int __quad_t;
typedef unsigned long int __u_quad_t;
# 129 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/typesizes.h 1 3 4
# 130 /usr/include/bits/types.h 2 3 4






__extension__ typedef unsigned long int __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef unsigned long int __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned long int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef long int __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef unsigned long int __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;

__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;


__extension__ typedef int __clockid_t;


__extension__ typedef void * __timer_t;


__extension__ typedef long int __blksize_t;




__extension__ typedef long int __blkcnt_t;
__extension__ typedef long int __blkcnt64_t;


__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef unsigned long int __fsblkcnt64_t;


__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef 

Re: gcc 4.0.0 on amd64: problem with -O2?

2005-05-07 Thread Harald Dunkel
Andrew Pinski wrote:

 Stop right there, you said it warns, well this is a case where
 you are violating C89/C99/C++ aliasing rules so it is a bug in your
 code and not in GCC.


This is not my code. It is XFree86 4.3. I am just trying to
help by investigating a problem and providing an easy testcase.

If you read my report, then you will recognize that it is
a problem of the optimizer.


Regards

Harri


signature.asc
Description: OpenPGP digital signature