From: Earnie B. <ear...@ya...> - 2002-12-18 20:30:22
|
I've not narrowed this down but the problem is persistent. I've been building an extremely large package, SourceNavigator, with M&M. I started with gcc-3.2 then switched to gcc-2 then tried gcc-3.2.1. The gcc-2 version presents no problems. The GCC-3.2x problems can be seen with the default -O2 and with a specified -O3. If I specify -O0, the problem disappears. If you wish to try this yourself, follow the directions on http://sourcenav.sf.net/download.html create an empty build directory and execute the top level configure script. Then type make, 20 to 30 minutes later, the error will be shown. Earnie. |
From: Danny S. <dan...@cl...> - 2002-12-18 22:44:41
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Wednesday, 18 December 2002 20:30 Subject: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization causing link resolution errors. > I've not narrowed this down but the problem is persistent. I've been > building an extremely large package, SourceNavigator, with M&M. I > started with gcc-3.2 then switched to gcc-2 then tried gcc-3.2.1. The > gcc-2 version presents no problems. The GCC-3.2x problems can be seen > with the default -O2 and with a specified -O3. If I specify -O0, the > problem disappears. If you wish to try this yourself, follow the > directions on http://sourcenav.sf.net/download.html create an empty > build directory and execute the top level configure script. Then type > make, 20 to 30 minutes later, the error will be shown. http://gcc.gnu.org/bugs.html > > Earnie. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ear...@ya...> - 2002-12-19 12:10:41
|
Danny Smith wrote: > ----- Original Message ----- > From: "Earnie Boyd" <ear...@ya...> > To: <min...@li...> > Sent: Wednesday, 18 December 2002 20:30 > Subject: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization > causing link resolution errors. > > > >>I've not narrowed this down but the problem is persistent. I've been >>building an extremely large package, SourceNavigator, with M&M. I >>started with gcc-3.2 then switched to gcc-2 then tried gcc-3.2.1. The >>gcc-2 version presents no problems. The GCC-3.2x problems can be seen >>with the default -O2 and with a specified -O3. If I specify -O0, the >>problem disappears. If you wish to try this yourself, follow the >>directions on http://sourcenav.sf.net/download.html create an empty >>build directory and execute the top level configure script. Then type >>make, 20 to 30 minutes later, the error will be shown. > > > http://gcc.gnu.org/bugs.html > I knew that my report wasn't a bug report. It was a developers beware report. It's taken three days to narrow it down to optimization issues. I use -O0 because I wanted to debug the problem but had no joy with the bug because it went away. Today, I'll rebuild with -O2 -g and see if the linker will give me more useful information. Later, Earnie. |
From: Earnie B. <ear...@ya...> - 2002-12-19 21:49:15
|
Earnie Boyd wrote: > > > I knew that my report wasn't a bug report. It was a developers beware > report. It's taken three days to narrow it down to optimization issues. > I use -O0 because I wanted to debug the problem but had no joy with the > bug because it went away. Today, I'll rebuild with -O2 -g and see if > the linker will give me more useful information. > I've narrowed this further to the declaration of _pctype in ctypes.h. But I still don't have a proper bug report. When declared as __declspec(dllimport) extern unsigned short* _pctype; the error persists. When declared as extern unsigned short** _imp___pctype; #define _pctype (*_imp___pctype); the error does not occur. The error is happening in a static library with a link line similar to gcc -o foo.exe foo.o libbar.a The function uses the isspace() and friends and every use is listed in the error assuming I use the -W1,--disable-auto-import option. If I don't --disable-auto-import, the _pctype is resolved to _imp___pctype but I get ``undefined reference to `libmsvcrt_a_iname''' instead of ``undefined reference to `_pctype'''. Earnie. |
From: Earnie B. <ear...@ya...> - 2002-12-19 22:46:22
|
Earnie Boyd wrote: > Earnie Boyd wrote: > >> >> >> I knew that my report wasn't a bug report. It was a developers beware >> report. It's taken three days to narrow it down to optimization >> issues. I use -O0 because I wanted to debug the problem but had no >> joy with the bug because it went away. Today, I'll rebuild with -O2 >> -g and see if the linker will give me more useful information. >> > > I've narrowed this further to the declaration of _pctype in ctypes.h. > But I still don't have a proper bug report. > I've also discovered that -D__NO_CTYPE_INLINES also cures my problem. > When declared as > __declspec(dllimport) extern unsigned short* _pctype; > the error persists. > > When declared as > extern unsigned short** _imp___pctype; > #define _pctype (*_imp___pctype); > the error does not occur. > > The error is happening in a static library with a link line similar to > gcc -o foo.exe foo.o libbar.a > The function uses the isspace() and friends and every use is listed in > the error assuming I use the -W1,--disable-auto-import option. If I > don't --disable-auto-import, the _pctype is resolved to _imp___pctype > but I get ``undefined reference to `libmsvcrt_a_iname''' instead of > ``undefined reference to `_pctype'''. > > Earnie. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Geek Gift Procrastinating? > Get the perfect geek gift now! Before the Holidays pass you by. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > |
From: Danny S. <dan...@cl...> - 2002-12-22 02:02:47
Attachments:
ctype.h.diff
|
This is a WAG. According to my reading of C++ standard, extern inline means something different in C++ than does the GCC C extension extern __inline__. It means inline the function _and_ also emit the function with extern linkage. The GCC extension means inline the function if possible, else use the extern symbol. That may be causing your problem. See if attached patch to ctype.h helps. If it does than I will clean up rest inlines in headers in new year. Danny |
From: Danny S. <dan...@cl...> - 2002-12-22 04:06:36
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> To: <min...@li...> Sent: Sunday, 22 December 2002 01:59 Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization causing link resolution errors. > This is a WAG. According to my reading of C++ standard, extern inline > means something different in C++ than does the GCC C extension extern > __inline__. It means inline the function _and_ also emit the function > with extern linkage. The GCC extension means inline the function if > possible, else use the extern symbol. > > That may be causing your problem. See if attached patch to ctype.h > helps. If it does than I will clean up rest inlines in headers in new > year. > Well, I don't know if it helps with your problem, but I think the extern inlines do need to be fixed in headers. Here is a testcase. Compied as C, the gcc "extern inline" extension is implemented and the linker complains about no foo. Compiled as C++, the C++ standard meaning of extern inline is implemented and foo is emitted. This would cause problems with multiple definitions in C++ if foo was in a header and another translation unit used foo in a similar way. /* compile this as "gcc -O2 inline.c" then compile as "gcc -O2 inline.C" */ #include <stdio.h> extern inline int foo(int a) { return a * 2;} int main () { int (* foofun)(int) = foo; int number = 2; /* Using the function's address means we can't inline foo. In C, the extern says to look elswhere for foo, In C++ the extern says to emit the function with extern linkage */ printf("2 * %d = %d\n", number, foofun(number)); return 0; } Question: Should we define __CTYPE_INLINE, __MATH_INLINE, etc in respective headers or just do a single __INLINE__ definition, conditional on __cplusplus, in _mingw.h and use it everywhere. My preference is the former, even though it means more work, because it is immediately visible to users reading the headers and also more flexible (say if we wanted to make __MATH_INLINE conditional on other defines). Danny > > > |
From: Earnie B. <ear...@ya...> - 2002-12-22 13:07:29
|
Danny Smith wrote: > > Question: Should we define __CTYPE_INLINE, __MATH_INLINE, etc in > respective headers or just do a single __INLINE__ definition, > conditional on __cplusplus, in _mingw.h and use it everywhere. My > preference is the former, even though it means more work, because it is > immediately visible to users reading the headers and also more flexible > (say if we wanted to make __MATH_INLINE conditional on other defines). > How about both? Define __INLINE__ in _mingw.h and then just define __CTYPE_INLINE, etc. to __INLINE__ in the respective headers. Earnie. |
From: Danny S. <dan...@cl...> - 2002-12-22 19:51:09
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Sunday, 22 December 2002 13:07 Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization causing link resolution errors. > Danny Smith wrote: > > > > Question: Should we define __CTYPE_INLINE, __MATH_INLINE, etc in > > respective headers or just do a single __INLINE__ definition, > > conditional on __cplusplus, in _mingw.h and use it everywhere. My > > preference is the former, even though it means more work, because it is > > immediately visible to users reading the headers and also more flexible > > (say if we wanted to make __MATH_INLINE conditional on other defines). > > > > How about both? Define __INLINE__ in _mingw.h and then just define > __CTYPE_INLINE, etc. to __INLINE__ in the respective headers. > That's what I had come up with too. I need to check that __INLINE__ isn't a "bad name" used by GCC itself, but ..... > Earnie. > > After a bit more testing I realised that the extern really isn't a problem with C++ (at least with C++98). I had forgotten about C++'s use of .linkonce semantic when emitting an inlined function that needs a real symbol as well. The same asm code is emitted with or without the extern. See this explanation of C++ inline as governed by 1994 vs 1998 C++ standard: http://www.glenmccl.com/ansi_015.htm . I need to do more testing with older G++ to see if the extern makes a difference Danny.. |
From: Ranjit M. <rm...@ho...> - 2002-12-24 06:05:13
|
Hi, Maybe my current bootstrap problems with GCC 3.3 are related to this topic (or maybe not, sorry) - see this message I posted to the gcc java list: http://gcc.gnu.org/ml/java/2002-12/msg00219.html Summary: I'm getting a lot of "multiple definition" errors from the linker for methods that are defined inline in headers (but not explicitly marked "inline") for libgcj, like this: jint length( void) { return length;} The weird part is that these methods were defined the same way in the same headers even in 3.2, but I never used to see these errors there. :-( Ideas? Sincerely Yours, Ranjit. Danny Smith wrote: > ----- Original Message ----- > From: "Earnie Boyd" <earnie_boyd=/E15...@pu...> > To: <mingw-dvlpr=5NW...@pu...> > Sent: Sunday, 22 December 2002 13:07 > Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization > causing link resolution errors. > > >> Danny Smith wrote: >> > >> > Question: Should we define __CTYPE_INLINE, __MATH_INLINE, etc in >> > respective headers or just do a single __INLINE__ definition, >> > conditional on __cplusplus, in _mingw.h and use it everywhere. My >> > preference is the former, even though it means more work, because it > is >> > immediately visible to users reading the headers and also more > flexible >> > (say if we wanted to make __MATH_INLINE conditional on other > defines). >> > >> >> How about both? Define __INLINE__ in _mingw.h and then just define >> __CTYPE_INLINE, etc. to __INLINE__ in the respective headers. >> > > That's what I had come up with too. I need to check that __INLINE__ > isn't a "bad name" used by GCC itself, but ..... > >> Earnie. >> >> > After a bit more testing I realised that the extern really isn't a > problem with C++ (at least with C++98). I had forgotten about C++'s use > of .linkonce semantic when emitting an inlined function that needs a > real symbol as well. The same asm code is emitted with or without the > extern. See this explanation of C++ inline as governed by 1994 vs > 1998 C++ standard: > http://www.glenmccl.com/ansi_015.htm > . > I need to do more testing with older G++ to see if the extern makes a > difference > > Danny.. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf -- Ranjit Mathew Email: rmathew AT hotmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ |
From: Earnie B. <ear...@ya...> - 2003-01-07 14:56:18
|
The patch did not help. I'm using gcc-3.2.1 and binutils 20030104. I get: Info: resolving __pctype by linking to __imp___pctype (auto-import) fu000001.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu000002.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu000003.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu000004.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu000005.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu000006.o(.idata$3+0xc): more undefined references to `libmsvcrt_a_iname' follow nmth000000.o(.idata$4+0x0): undefined reference to `_nm___pctype' make[4]: *** [dbdump.exe] Error 1 make[4]: Leaving directory `/prjz/pkg/bld/sourcenav/mingw32/snavigator/db' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/prjz/pkg/bld/sourcenav/mingw32/snavigator/db' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/prjz/pkg/bld/sourcenav/mingw32/snavigator' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/prjz/pkg/bld/sourcenav/mingw32/snavigator' make: *** [all-snavigator] Error 2 Earnie. Danny Smith wrote: > This is a WAG. According to my reading of C++ standard, extern inline > means something different in C++ than does the GCC C extension extern > __inline__. It means inline the function _and_ also emit the function > with extern linkage. The GCC extension means inline the function if > possible, else use the extern symbol. > > That may be causing your problem. See if attached patch to ctype.h > helps. If it does than I will clean up rest inlines in headers in new > year. > > Danny > > > > > ------------------------------------------------------------------------ > > 2002-12-22 Danny Smith <dan...@us...> > > * include/ctype.h (__CTYPE_INLINE): Define. Use throughout > instead of extern __inline__. > > > --- ctype.h.orig Thu Oct 03 00:48:44 2002 > +++ ctype.h Sun Dec 22 01:49:46 2002 > @@ -36,6 +36,12 @@ > #include <stddef.h> > #endif /* Not RC_INVOKED */ > > +#ifdef __cplusplus > +# define __CTYPE_INLINE inline > +#else > +# define __CTYPE_INLINE extern __inline__ > +#endif > + > > /* > * The following flags are used to tell iswctype and _isctype what character > @@ -155,21 +161,21 @@ extern unsigned short** _imp___ctype; > #if ! (defined (__NO_CTYPE_INLINES) || defined (__STRICT_ANSI__ )) > /* use simple lookup if SB locale, else _isctype() */ > #define __ISCTYPE(c, mask) (MB_CUR_MAX == 1 ? (_pctype[c] & mask) : _isctype(c, mask)) > -extern __inline__ int isalnum(int c) {return __ISCTYPE(c, (_ALPHA|_DIGIT));} > -extern __inline__ int isalpha(int c) {return __ISCTYPE(c, _ALPHA);} > -extern __inline__ int iscntrl(int c) {return __ISCTYPE(c, _CONTROL);} > -extern __inline__ int isdigit(int c) {return __ISCTYPE(c, _DIGIT);} > -extern __inline__ int isgraph(int c) {return __ISCTYPE(c, (_PUNCT|_ALPHA|_DIGIT));} > -extern __inline__ int islower(int c) {return __ISCTYPE(c, _LOWER);} > -extern __inline__ int isprint(int c) {return __ISCTYPE(c, (_BLANK|_PUNCT|_ALPHA|_DIGIT));} > -extern __inline__ int ispunct(int c) {return __ISCTYPE(c, _PUNCT);} > -extern __inline__ int isspace(int c) {return __ISCTYPE(c, _SPACE);} > -extern __inline__ int isupper(int c) {return __ISCTYPE(c, _UPPER);} > -extern __inline__ int isxdigit(int c) {return __ISCTYPE(c, _HEX);} > +__CTYPE_INLINE int isalnum(int c) {return __ISCTYPE(c, (_ALPHA|_DIGIT));} > +__CTYPE_INLINE int isalpha(int c) {return __ISCTYPE(c, _ALPHA);} > +__CTYPE_INLINE int iscntrl(int c) {return __ISCTYPE(c, _CONTROL);} > +__CTYPE_INLINE int isdigit(int c) {return __ISCTYPE(c, _DIGIT);} > +__CTYPE_INLINE int isgraph(int c) {return __ISCTYPE(c, (_PUNCT|_ALPHA|_DIGIT));} > +__CTYPE_INLINE int islower(int c) {return __ISCTYPE(c, _LOWER);} > +__CTYPE_INLINE int isprint(int c) {return __ISCTYPE(c, (_BLANK|_PUNCT|_ALPHA|_DIGIT));} > +__CTYPE_INLINE int ispunct(int c) {return __ISCTYPE(c, _PUNCT);} > +__CTYPE_INLINE int isspace(int c) {return __ISCTYPE(c, _SPACE);} > +__CTYPE_INLINE int isupper(int c) {return __ISCTYPE(c, _UPPER);} > +__CTYPE_INLINE int isxdigit(int c) {return __ISCTYPE(c, _HEX);} > > /* these reproduce behaviour of lib underscored versions */ > -extern __inline__ int _tolower(int c) {return ( c -'A'+'a');} > -extern __inline__ int _toupper(int c) {return ( c -'a'+'A');} > +__CTYPE_INLINE int _tolower(int c) {return ( c -'A'+'a');} > +__CTYPE_INLINE int _toupper(int c) {return ( c -'a'+'A');} > > /* TODO? Is it worth inlining ANSI tolower, toupper? Probably only > if we only want C-locale. */ > @@ -210,19 +216,19 @@ int isleadbyte (int); > /* Also in wctype.h */ > #if ! (defined(__NO_CTYPE_INLINES) || defined(__WCTYPE_INLINES_DEFINED)) > #define __WCTYPE_INLINES_DEFINED > -extern __inline__ int iswalnum(wint_t wc) {return (iswctype(wc,_ALPHA|_DIGIT));} > -extern __inline__ int iswalpha(wint_t wc) {return (iswctype(wc,_ALPHA));} > -extern __inline__ int iswascii(wint_t wc) {return (((unsigned)wc & 0x7F) ==0);} > -extern __inline__ int iswcntrl(wint_t wc) {return (iswctype(wc,_CONTROL));} > -extern __inline__ int iswdigit(wint_t wc) {return (iswctype(wc,_DIGIT));} > -extern __inline__ int iswgraph(wint_t wc) {return (iswctype(wc,_PUNCT|_ALPHA|_DIGIT));} > -extern __inline__ int iswlower(wint_t wc) {return (iswctype(wc,_LOWER));} > -extern __inline__ int iswprint(wint_t wc) {return (iswctype(wc,_BLANK|_PUNCT|_ALPHA|_DIGIT));} > -extern __inline__ int iswpunct(wint_t wc) {return (iswctype(wc,_PUNCT));} > -extern __inline__ int iswspace(wint_t wc) {return (iswctype(wc,_SPACE));} > -extern __inline__ int iswupper(wint_t wc) {return (iswctype(wc,_UPPER));} > -extern __inline__ int iswxdigit(wint_t wc) {return (iswctype(wc,_HEX));} > -extern __inline__ int isleadbyte(int c) {return (_pctype[(unsigned char)(c)] & _LEADBYTE);} > +__CTYPE_INLINE int iswalnum(wint_t wc) {return (iswctype(wc,_ALPHA|_DIGIT));} > +__CTYPE_INLINE int iswalpha(wint_t wc) {return (iswctype(wc,_ALPHA));} > +__CTYPE_INLINE int iswascii(wint_t wc) {return (((unsigned)wc & 0x7F) ==0);} > +__CTYPE_INLINE int iswcntrl(wint_t wc) {return (iswctype(wc,_CONTROL));} > +__CTYPE_INLINE int iswdigit(wint_t wc) {return (iswctype(wc,_DIGIT));} > +__CTYPE_INLINE int iswgraph(wint_t wc) {return (iswctype(wc,_PUNCT|_ALPHA|_DIGIT));} > +__CTYPE_INLINE int iswlower(wint_t wc) {return (iswctype(wc,_LOWER));} > +__CTYPE_INLINE int iswprint(wint_t wc) {return (iswctype(wc,_BLANK|_PUNCT|_ALPHA|_DIGIT));} > +__CTYPE_INLINE int iswpunct(wint_t wc) {return (iswctype(wc,_PUNCT));} > +__CTYPE_INLINE int iswspace(wint_t wc) {return (iswctype(wc,_SPACE));} > +__CTYPE_INLINE int iswupper(wint_t wc) {return (iswctype(wc,_UPPER));} > +__CTYPE_INLINE int iswxdigit(wint_t wc) {return (iswctype(wc,_HEX));} > +__CTYPE_INLINE int isleadbyte(int c) {return (_pctype[(unsigned char)(c)] & _LEADBYTE);} > #endif /* !(defined(__NO_CTYPE_INLINES) || defined(__WCTYPE_INLINES_DEFINED)) */ > > #ifndef __STRICT_ANSI__ > @@ -232,10 +238,10 @@ int __iscsymf (int); /* Valid first char > int __iscsym (int); /* Valid character in C symbol (after first) */ > > #ifndef __NO_CTYPE_INLINES > -extern __inline__ int __isascii(int c) {return (((unsigned)c & ~0x7F) == 0);} > -extern __inline__ int __toascii(int c) {return (c & 0x7F);} > -extern __inline__ int __iscsymf(int c) {return (isalpha(c) || (c == '_'));} > -extern __inline__ int __iscsym(int c) {return (isalnum(c) || (c == '_'));} > +__CTYPE_INLINE int __isascii(int c) {return (((unsigned)c & ~0x7F) == 0);} > +__CTYPE_INLINE int __toascii(int c) {return (c & 0x7F);} > +__CTYPE_INLINE int __iscsymf(int c) {return (isalpha(c) || (c == '_'));} > +__CTYPE_INLINE int __iscsym(int c) {return (isalnum(c) || (c == '_'));} > #endif /* __NO_CTYPE_INLINES */ > > #ifndef _NO_OLDNAMES |
From: Danny S. <dan...@cl...> - 2003-01-07 21:15:32
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Tuesday, 7 January 2003 14:56 Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization causing link resolution errors. > The patch did not help. I'm using gcc-3.2.1 and binutils 20030104. I get: > > Info: resolving __pctype by linking to __imp___pctype (auto-import) > fu000001.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > fu000002.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > fu000003.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > fu000004.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > fu000005.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > fu000006.o(.idata$3+0xc): more undefined references to > `libmsvcrt_a_iname' follow > nmth000000.o(.idata$4+0x0): undefined reference to `_nm___pctype' > make[4]: *** [dbdump.exe] Error 1 Can you track down which object(s) in dbdump has __pctype as undefined symbol, and post prepocessed source. I can't understand how _pctype is there rather than _imp___pctype Danny |
From: Earnie B. <ear...@ya...> - 2003-01-08 19:52:02
|
Danny Smith wrote: > ----- Original Message ----- > From: "Earnie Boyd" <ear...@ya...> > To: <min...@li...> > Sent: Tuesday, 7 January 2003 14:56 > Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization > causing link resolution errors. > > > >>The patch did not help. I'm using gcc-3.2.1 and binutils 20030104. I > > get: > >>Info: resolving __pctype by linking to __imp___pctype (auto-import) >>fu000001.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>fu000002.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>fu000003.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>fu000004.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>fu000005.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>fu000006.o(.idata$3+0xc): more undefined references to >>`libmsvcrt_a_iname' follow >>nmth000000.o(.idata$4+0x0): undefined reference to `_nm___pctype' >>make[4]: *** [dbdump.exe] Error 1 > > > Can you track down which object(s) in dbdump has __pctype as undefined > symbol, and post prepocessed source. I can't understand how _pctype is > there rather than _imp___pctype > I'll get there eventually. I know it's a ctype function that's the reference. From the GCC online manual I see that -O1 turns on -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fcrossjumping -fif-conversion -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers However, -floop-optimize, -fcrossjumping, -fif-conversion and -fif-conversion2 are unknown options. Since using -O0 specifically causes the problem to disappear I was going to add one at a time to determine which optimization caused the problems to narrow the scope. I've worked through this list '-fdefer-pop -fmerge-constants -fthread-jumps -fdelayed-branch -fguess-branch-probability -fcprop-registers' but these are not causing problems. What other optimizations are turned on by -O1? Earnie. |
From: Earnie B. <ear...@ya...> - 2003-01-08 23:46:50
|
Earnie Boyd wrote: >> >>> Info: resolving __pctype by linking to __imp___pctype (auto-import) >>> fu000001.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>> fu000002.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>> fu000003.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>> fu000004.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>> fu000005.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' >>> fu000006.o(.idata$3+0xc): more undefined references to >>> `libmsvcrt_a_iname' follow >>> nmth000000.o(.idata$4+0x0): undefined reference to `_nm___pctype' >>> make[4]: *** [dbdump.exe] Error 1 I've tracked this to compiler confusion with optimization and ``extern __attribute__((dllimport))''. Removing the ``extern'' removes the confusion. So as a work around we could modify _mingw.h to remove the ``extern'' from the __MINGW_IMPORT define. Earnie. |
From: Danny S. <dan...@cl...> - 2003-01-09 00:26:47
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Wednesday, 8 January 2003 23:46 Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization causing link resolution errors. > Earnie Boyd wrote: > > >> > >>> Info: resolving __pctype by linking to __imp___pctype (auto-import) > >>> fu000001.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > >>> fu000002.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > >>> fu000003.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > >>> fu000004.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > >>> fu000005.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' > >>> fu000006.o(.idata$3+0xc): more undefined references to > >>> `libmsvcrt_a_iname' follow > >>> nmth000000.o(.idata$4+0x0): undefined reference to `_nm___pctype' > >>> make[4]: *** [dbdump.exe] Error 1 > > I've tracked this to compiler confusion with optimization and ``extern > __attribute__((dllimport))''. Removing the ``extern'' removes the > confusion. So as a work around we could modify _mingw.h to remove the > ``extern'' from the __MINGW_IMPORT define. > > Earnie. > Can you provide a testcase? If that is the real problem then there is serious bug in GCC. Danny > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ear...@ya...> - 2003-01-09 00:40:35
|
Danny Smith wrote: > > > Can you provide a testcase? If that is the real problem then there is > serious bug in GCC. I don't know if I can get one small enough. It may come down to the generated .s files. Earnie. |
From: Danny S. <dan...@cl...> - 2003-01-09 00:49:35
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Thursday, 9 January 2003 00:40 Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization causing link resolution errors. > Danny Smith wrote: > > > > > > Can you provide a testcase? If that is the real problem then there is > > serious bug in GCC. > > I don't know if I can get one small enough. It may come down to the > generated .s files. A preprocessed source file would be better. Then I could look at different optimisation switches. If too big for list, feel free to send privately (if less than 1MB). A big single source file is still better than downloading SourceNav and grinding away through that . Danny Danny > > Earnie. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ear...@ya...> - 2003-01-09 12:46:58
|
Danny Smith wrote: > ----- Original Message ----- > From: "Earnie Boyd" <ear...@ya...> > To: <min...@li...> > Sent: Thursday, 9 January 2003 00:40 > Subject: Re: [MinGW-dvlpr] HEADSUP: GCC-3.2 and GCC-3.2.1 optimization > causing link resolution errors. > > > >>Danny Smith wrote: >> >>> >>>Can you provide a testcase? If that is the real problem then there >> > is > >>>serious bug in GCC. >> >>I don't know if I can get one small enough. It may come down to the >>generated .s files. > > > A preprocessed source file would be better. Then I could look at > different optimisation switches. If too big for list, feel free to send > privately (if less than 1MB). A big single source file is still better > than downloading SourceNav and grinding away through that . > I sent Danny the preprocessed dbutils.i file. Here is the difference in the generated assembler files with pctype defined with and without the ``extern'' declaration. --- dbutils.s Thu Jan 9 07:34:45 2003 +++ dbutils.s.noextern Thu Jan 9 07:32:26 2003 @@ -5155,20 +5155,21 @@ .p2align 4,,7 L888: leal -216(%ebp), %edx pushl %eax pushl %ebx pushl $LC87 pushl %edx call _sprintf orl $-1, %eax jmp L887 + .comm __pctype, 16 # 4 .lcomm _db_class_tree,16 .lcomm _db_cached_classes,16 .lcomm _process_handle,16 .lcomm _db_include,16 .lcomm _include_array,16 .comm _cross_ref_fp, 16 # 4 .lcomm _db_syms,208 .lcomm _db_project_dir,272 .lcomm _db_cachesize,16 .lcomm _db_cross_cachesize,16 HTH, Earnie. |