X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com Message-ID: <484D91C2.1050004@iki.fi> Date: Mon, 09 Jun 2008 23:25:38 +0300 From: Andris Pavenis User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Difficulties compiling emu387.cc with gcc 4.3.0 References: <200806092058 DOT 05925 DOT juan DOT guerrero AT gmx DOT de> In-Reply-To: <200806092058.05925.juan.guerrero@gmx.de> Content-Type: multipart/mixed; boundary="------------050503020104040306000201" Reply-To: djgpp-workers AT delorie DOT com This is a multi-part message in MIME format. --------------050503020104040306000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juan Manuel Guerrero kirjoitti: > I have tried to compile today's CVS sources and I have run into a problem. > I am using gcc 4.3.0 and bnu217br2. The sources can only be compiled if > Andris' patches to emu387.cc and ieeefp.h are applied (see > > Not committed because I don't know whether it is correct. Perhaps somebody who know emu387.cc better could say more > and > ). > This patch is broken (sorry for that). The inline function is in some contexts not inlined and generates duplicate external references with gcc-4.3.0. The better one is in attachment (one perhaps needs some better place for typedef though) > That is ok and well known. Now if I apply the following patch: > > diff -aprNU3 djgpp.orig/include/string.h djgpp/include/string.h > --- djgpp.orig/include/string.h 2007-12-11 07:01:20 +0000 > +++ djgpp/include/string.h 2008-06-09 16:05:26 +0000 > @@ -77,6 +77,7 @@ char * rindex(const char *_string, int > char * stpcpy(char *_dest, const char *_src); > char * stpncpy(char *_dest, const char *_src, size_t _n); > char * strdup(const char *_s); > +char * strndup(const char *_s, size_t _n); > size_t strlcat(char *_dest, const char *_src, size_t _size); > size_t strlcpy(char *_dest, const char *_src, size_t _size); > char * strlwr(char *_s); > @@ -84,6 +85,7 @@ int strcasecmp(const char *_s1, const ch > int stricmp(const char *_s1, const char *_s2); > int strncasecmp(const char *_s1, const char *_s2, size_t _n); > int strnicmp(const char *_s1, const char *_s2, size_t _n); > +size_t strnlen(const char *_s, size_t _n); > char * strsep(char **_stringp, const char *_delim); > char * strupr(char *_s); > > > the compilation of emu387.cc fails with the following error message: > > > ./makemake.exe > makemake: scanning libemu for makefiles > C:/djgpp/bin/make.exe -f makefile.sub > C:/djgpp/bin/make.exe -C src > gcc -MD -O2 -mtune=i586 -march=i386 -Wall -Wcast-qual -Werror -Wpointer-arith -Wshadow -Wwrite-strings -Wundef -Wcast-align -Wsign-compare -nostdinc -iquote . -isystem ../../../include -DGAS_MAJOR=2 -DGAS_MINOR=17 -DGAS_MINORMINOR=0 -c -fno-exceptions emu387.cc > cc1plus.exe: warnings being treated as errors > emu387.cc: In function 'void fsqrt()': > emu387.cc:2366: error: likely type-punning may break strict-aliasing rules: object '*{unknown}' of main type 'long int' is referenced at or around emu387.cc:2366 and may be aliased to object 'result' of main type 'long long unsigned int' which is referenced at or around emu387.cc:2357. > emu387.cc:2371: error: likely type-punning may break strict-aliasing rules: object '*{unknown}' of main type 'unsigned int' is referenced at or around emu387.cc:2371 and may be aliased to object 'val' of main type 'long long unsigned int' which is referenced at or around emu387.cc:2356. > make.exe[3]: *** [emu387.o] Error 1 > make.exe[2]: *** [all_subs] Error 2 > make.exe[1]: *** [all] Error 2 > make.exe: *** [subs] Error 2 > > Compiles for me with GCC-4.3.1 when my attached patch is being used. > Please note that strndup() and strnlen() are neither implemented nor used > anywhere in the complete CVS code. If I comment out one of the declaration > (no matter which one) the code compiles without error. As soon as both are > declarations are active again the compilation fails. If I replace gcc and > gpp 4.3.0 with gcc and gpp 4.2.3 then the sources can be compiled without > any difficulties. The surprising fact to me is not really the error message > but the way it is triggered. > Any ideas what I am missing here? If more information is needed, let me know. > Andris --------------050503020104040306000201 Content-Type: text/plain; name="djcrx-ieeefp_h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="djcrx-ieeefp_h.patch" Index: ieeefp.h =================================================================== RCS file: /cvs/djgpp/djgpp/include/ieeefp.h,v retrieving revision 1.2 diff -u -r1.2 djgpp/include/ieeefp.h --- djgpp/include/ieeefp.h 11 Dec 2007 07:27:40 -0000 1.2 +++ djgpp/include/ieeefp.h 24 May 2008 12:50:33 -0000 @@ -72,14 +72,19 @@ #define __IEEE_DBL_NAN_EXP 0x7ff #define __IEEE_FLT_NAN_EXP 0xff +#if (__GNUC__ >= 4) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 3)) +typedef long __attribute__((__may_alias__)) __dj_long_a; +#else +typedef long __dj_long_a; +#endif -#define isnanf(x) (((*(long *)(void *)&(x) & 0x7f800000L)==0x7f800000L) && \ - ((*(long *)(void *)&(x) & 0x007fffffL)!=0000000000L)) +#define isnanf(x) (((*(__dj_long_a *)&(x) & 0x7f800000L)==0x7f800000L) && \ + ((*(__dj_long_a *)&(x) & 0x007fffffL)!=0000000000L)) -#define isinff(x) (((*(long *)(void *)&(x) & 0x7f800000L)==0x7f800000L) && \ - ((*(long *)(void *)&(x) & 0x007fffffL)==0000000000L)) +#define isinff(x) (((*(__dj_long_a *)&(x) & 0x7f800000L)==0x7f800000L) && \ + ((*(__dj_long_a *)&(x) & 0x007fffffL)==0000000000L)) -#define finitef(x) (((*(long *)(void *)&(x) & 0x7f800000L)!=0x7f800000L)) +#define finitef(x) (((*(__dj_long_a *)&(x) & 0x7f800000L)!=0x7f800000L)) #ifdef __cplusplus } --------------050503020104040306000201--