Issues with building gcc trunk with ada on cygwin
I have an issue with building gcc trunk, current and since quite a while. There seems to me to be quite some missing includes while building stage 3 compared with stage 2. For example, the adadecode.c comile in stage 2 for me looks like this: make[5]: Entering directory `/usr/local/src/trunk/objdir.withada-java/gcc/ada/rts' /usr/local/src/trunk/objdir.withada-java/./gcc/xgcc -B/usr/local/src/trunk/objdir.withada-java/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -c -DIN_GCC -W -Wall -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO \ -iquote . -iquote .. -iquote ../.. -iquote /usr/local/src/trunk/gcc/gcc/ada -I/usr/local/src/trunk/gcc/gcc/../include -I./../.. adadecode.c -o adadecode.o In file included from adadecode.c:34:0: ../../tconfig.h:9:36: fatal error: config/i386/xm-cygwin.h: No such file or directory compilation terminated. make[5]: *** [adadecode.o] Error 1 make[5]: Leaving directory `/usr/local/src/trunk/objdir.withada-java/gcc/ada/rts' make[4]: *** [gnatlib] Error 2 make[4]: Leaving directory `/usr/local/src/trunk/objdir.withada-java/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/usr/local/src/trunk/objdir.withada-java/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir.withada-java/i686-pc-cygwin/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir.withada-java' make: *** [all] Error 2 while the stage1 compile looks liike this: /usr/local/src/trunk/objdir.withada-java/./prev-gcc/g++ -B/usr/local/src/trunk/objdir.withada-java/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ -nostdinc++ -B/usr/local/src/trunk/objdir.withada-java/prev-i686-pc-cygwin/libstdc++-v3/src/.libs -B/usr/local/src/trunk/objdir.withada-java/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs -I/usr/local/src/trunk/objdir.withada-java/prev-i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/usr/local/src/trunk/objdir.withada-java/prev-i686-pc-cygwin/libstdc++-v3/include -I/usr/local/src/trunk/gcc/libstdc++-v3/libsupc++ -L/usr/local/src/trunk/objdir.withada-java/prev-i686-pc-cygwin/libstdc++-v3/src/.libs -L/usr/local/src/trunk/objdir.withada-java/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Iada -I/usr/local/src/trunk/objdir.withada-java/../gcc/gcc -I/usr/local/src/trunk/objdir.withada-java/../gcc/gcc/ada -I/usr/local/src/trunk/objdir.withada-java/../gcc/gcc/../include -I/usr/local/src/trunk/objdir.withada-java/../gcc/gcc/../libcpp/include -I/usr/include -I/usr/include -I/usr/local/src/trunk/objdir.withada-java/../gcc/gcc/../libdecnumber -I/usr/local/src/trunk/objdir.withada-java/../gcc/gcc/../libdecnumber/bid -I../libdecnumber /usr/local/src/trunk/objdir.withada-java/../gcc/gcc/ada/adadecode.c -o ada/adadecode.o the compile error I get in stage 2 is resolved adding -I/usr/local/src/trunk/gcc/gcc/ as include, there, and only there, is the missing include file config/i386/xm-cygwin.h... Now, are there anyones here that recognise the issue and perhaps have an idea of how to address it? -- Cheers, /ChJ
Re: Issues with building gcc trunk with ada on cygwin
> Now, are there anyones here that recognise the issue and perhaps have > an idea of how to address it? Take a look at gcc/ada/Makefile.in lines 279 and below: ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),) # On Windows native the tconfig.h files used by C runtime files needs to have # the gcc source dir in its include dir list INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. -iquote $(fsrcdir)/ada \ -I$(fsrcdir)/../include -I$(fsrcdir) endif It's probably only a matter of adjusting the regexp. -- Eric Botcazou
libgcc: why emutls.c in LIB2ADDEH instead of LIB2ADD?
As subject says, in libgcc, why is $(srcdir)/emutls.c in LIB2ADDEH (and LIB2ADDEHSTATIC and LIB2ADDEHSHARED) instead of LIB2ADD? Emulating TLS has nothing to do with exception-handling, nor is there something that might throw while calling one of its functions. Ok to fix that? brgds, H-P
Profiling gcc itself
I posted this question at irc://irc.oftc.net/#gcc and they suggested that I pose it here instead. I do some "large-ish" builds (linux, gcc itself, etc) on a too-regular basis, and I was wondering what could be done to speed things up. A little printf-style checking hints to me that I might be spending the majority of my time in CPP rather g++, gasm, ld, etc. Has anyone (ever, regularly, or recently) built gcc (g++, gcpp) with profiling turned on? Is it hard? Did you get good results? Specifically I'm wondering what percentage of a g++ compile is spent in one of three places: 1) opening/reading header files 2) opening/reading source files 3) doing everything else Thanks in advance for any pointers, results, or thoughts. -Jeff
Re: Profiling gcc itself
On Sun, 20 Nov 2011 03:43:20 -0800
Jeff Evarts wrote:
> I posted this question at irc://irc.oftc.net/#gcc and they suggested
> that I pose it here instead.
>
> I do some "large-ish" builds (linux, gcc itself, etc) on a too-regular
> basis, and I was wondering what could be done to speed things up. A
> little printf-style checking hints to me that I might be spending the
> majority of my time in CPP rather g++, gasm, ld, etc. Has anyone
> (ever, regularly, or recently) built gcc (g++, gcpp) with profiling
> turned on? Is it hard? Did you get good results?
I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps
gcc-h...@gcc.gnu.org might
be a better place.
First, if you compile all GCC with -pg, then both the gcc driver and the cc1
compiler
proper are profiled (and there can be a conflict). You can then run gcc with
-v, and run
again the cc1 which it gives you.
Second, if you want some crude time report, gcc -ftime-report is simpler, but
don't give
you a very precise information.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Profiling gcc itself
On 11/20/2011 11:10 AM, Basile Starynkevitch wrote: On Sun, 20 Nov 2011 03:43:20 -0800 Jeff Evarts wrote: I posted this question at irc://irc.oftc.net/#gcc and they suggested that I pose it here instead. I do some "large-ish" builds (linux, gcc itself, etc) on a too-regular basis, and I was wondering what could be done to speed things up. A little printf-style checking hints to me that I might be spending the majority of my time in CPP rather g++, gasm, ld, etc. Has anyone (ever, regularly, or recently) built gcc (g++, gcpp) with profiling turned on? Is it hard? Did you get good results? I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps gcc-h...@gcc.gnu.org might be a better place. If you choose to follow such advice, explaining whether other facilities already in gcc, e.g. http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html apply to your situation may be useful. -- Tim Prince
Bootstrap fails in 32bit libjava on x86_64 Fedora 16 with undefined reference to `__cxa_call_unexpected'
Hello! For some reason bootstrap on Fedora 16 fails when compiling 32bit libjava with undefined reference to `__cxa_call_unexpected': libtool: link: /home/uros/gcc-build/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build/./gcc -nostdinc++ -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -shared -nostdlib /usr/lib/../lib/crti.o /home/uros/gcc-build/./gcc/32/crtbeginS.o .libs/jni-libjvm.o -Wl,-rpath -Wl,/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libjava/.libs -Wl,-rpath -Wl,/usr/local/lib/../lib -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libjava/.libs -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs ./.libs/libgcj.so -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libjava -lpthread -lrt -ldl -L/home/uros/gcc-build/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/home/uros/gcc-build/./gcc -L/usr/local/x86_64-unknown-linux-gnu/bin -L/usr/local/x86_64-unknown-linux-gnu/lib -lc -lgcc_s /home/uros/gcc-build/./gcc/32/crtendS.o /usr/lib/../lib/crtn.o -m32 -m32 -m32 -Wl,-Bsymbolic -Wl,-soname -Wl,libjvm.so -o .libs/libjvm.so libtool: link: ( cd ".libs" && rm -f "libgcj_bc.la" && ln -s "../libgcj_bc.la" "libgcj_bc.la" ) libtool: link: /home/uros/gcc-build/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build/./gcc -nostdinc++ -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -shared -nostdlib /usr/lib/../lib/crti.o /home/uros/gcc-build/./gcc/32/crtbeginS.o .libs/gij.o -Wl,-rpath -Wl,/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libjava/.libs -Wl,-rpath -Wl,/usr/local/lib/../lib -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libjava/.libs -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs ./.libs/libgcj.so -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libjava -lpthread -lrt -ldl -L/home/uros/gcc-build/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/home/uros/gcc-build/./gcc -L/usr/local/x86_64-unknown-linux-gnu/bin -L/usr/local/x86_64-unknown-linux-gnu/lib -lc -lgcc_s /home/uros/gcc-build/./gcc/32/crtendS.o /usr/lib/../lib/crtn.o -m32 -m32 -m32 -Wl,-Bsymbolic -Wl,-soname -Wl,libgij.so.13 -o .libs/libgij.so.13.0.0 ./.libs/libgcj.so: undefined reference to `__cxa_call_unexpected' collect2: error: ld returned 1 exit status make[3]: *** [jv-convert] Error 1 make[3]: *** Waiting for unfinished jobs libtool: link: ( cd ".libs" && rm -f "libjvm.la" && ln -s "../libjvm.la" "libjvm.la" ) ./.libs/libgcj.so: undefined reference to `__cxa_call_unexpected' collect2: error: ld returned 1 exit status make[3]: *** [gcj-dbtool] Error 1 Digging a bit deeper with: find . -name '*.o' | xargs nm -o | grep __cxa_call_unexpected ./32/libjava/.libs/prims.o: U __cxa_call_unexpected Googling a bit around the net, it looks that this file is wrongly compiled to use C++ exception code, not java exception code. Any hints what is going wrong there? Thanks, Uros.
Re: Profiling gcc itself
I understand that the noob traffic to gcc@ must be high. Nonetheless... On Sun, Nov 20, 2011 at 8:10 AM, Basile Starynkevitch wrote: > > On Sun, 20 Nov 2011 03:43:20 -0800 > Jeff Evarts wrote: > > I posted this question at irc://irc.oftc.net/#gcc and they suggested > > that I pose it here instead. > > > > I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps > gcc-h...@gcc.gnu.org might > be a better place. > > Second, if you want some crude time report, gcc -ftime-report is simpler, but > don't give > you a very precise information. And shortly thereafter: On Sun, 20 Nov 2011 11:34:27 -0500, Tim Prince wrote: > On 11/20/2011 11:10 AM, Basile Starynkevitch wrote: >> On Sun, 20 Nov 2011 03:43:20 -0800 Jeff Evarts wrote: >>> I posted this question at irc://irc.oftc.net/#gcc and they suggested >>> that I pose it here instead. >> >> I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps >> gcc-h...@gcc.gnu.org might >> be a better place. > > If you choose to follow such advice [ed: ouch!], explaining whether other > facilities already in gcc, e.g. > http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html apply to your > situation may be useful. Apparently my question "Has anyone done X and what were the results" has been mysteriously translated into "The GCC compiler is way too slow and what are you lazy developers going to do to speed up my compiles?!?". I will be more careful to shower my favorite compiler and its contributors with praise before posting another question here. :) To clarify: I wanted to know if anyone had performed a profiling run on gcc, whether that was a regular occurrence, and what the results (if any) were. Basile: The -ftime-report was new to me. It confirms that > 50% of the time is spent in CPP, even on subsequent runs when the cache is loaded. Tim: Precompiled Headers: This certainly helps with performance, but isn't directly useful in the "how much time is spent doing X" direction. Seriously, I meant no offense, and didn't want to cause a stir. Humbly, -Jeff Evarts P.S. If someone has recently built gcc with a full profiling rig and the results are out there somewhere, I'd love a pointer. Googling "profiling gnu gcc" et al doesn't get quite the right results.
Re: libgcc: why emutls.c in LIB2ADDEH instead of LIB2ADD?
On 11/20/2011 01:28 AM, Hans-Peter Nilsson wrote: > As subject says, in libgcc, why is $(srcdir)/emutls.c in > LIB2ADDEH (and LIB2ADDEHSTATIC and LIB2ADDEHSHARED) instead of > LIB2ADD? > > Emulating TLS has nothing to do with exception-handling, nor is > there something that might throw while calling one of its > functions. > > Ok to fix that? Not without further study. There was a reason we wanted these in libgcc_eh.a. I can't recall exactly why at the moment; it should be in the archives... r~
Re: Profiling gcc itself
On Sun, Nov 20, 2011 at 7:50 PM, Jeff Evarts wrote: > Apparently my question "Has anyone done X and what were the results" > has been mysteriously translated into "The GCC compiler is way too > slow and what are you lazy developers going to do to speed up my > compiles?!?". I will be more careful to shower my favorite compiler > and its contributors with praise before posting another question here. > :) > > To clarify: I wanted to know if anyone had performed a profiling run > on gcc, whether that was a regular occurrence, and what the results > (if any) were. Yes, a lot of groups perform detailed profiling and analysis of GCC, including Google and SuSE. You can look at GCC Bugzilla PR 45375 for detailed analysis of GCC LTO performance. Or PR 26854. GCC's performance scales a lot with memory usage, so most recent work has focused on reducing GCC's memory footprint and using more compact and efficient data structures. - David
Re: Profiling gcc itself
On Sun, Nov 20, 2011 at 03:43, Jeff Evarts wrote: > I posted this question at irc://irc.oftc.net/#gcc and they suggested > that I pose it here instead. > > I do some "large-ish" builds (linux, gcc itself, etc) on a too-regular > basis, and I was wondering what could be done to speed things up. A > little printf-style checking hints to me that I might be spending the > majority of my time in CPP rather g++, gasm, ld, etc. Has anyone > (ever, regularly, or recently) built gcc (g++, gcpp) with profiling > turned on? Is it hard? Did you get good results? > > Specifically I'm wondering what percentage of a g++ compile is spent > in one of three places: > > 1) opening/reading header files > 2) opening/reading source files > 3) doing everything else > > Thanks in advance for any pointers, results, or thoughts. We (Google) did such measurements on our code base. The answer is highly dependent on the nature of your code base. We found a significant amount of time spent parsing header files, so we are implementing a caching scheme for avoiding repeated parsing actions on the same header files (http://gcc.gnu.org/wiki/pph). You will find our findings and what we are doing about the problem. Our short answer: in our code base, the parser spends between 50%-80% of the total compilation time. There has been some other profiling efforts as part of the Google Summer of Code program, but I cannot find a link for you atm. Some thoughts on compile time are here: http://gcc.gnu.org/wiki/Speedup_areas Diego.
Re: Profiling gcc itself
On Sun, Nov 20, 2011 at 08:10, Basile Starynkevitch wrote: > I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps > gcc-h...@gcc.gnu.org might > be a better place. gcc@ is the right forum for this question. Diego.
Re: Profiling gcc itself
On 21 November 2011 00:50, Jeff Evarts wrote: > Seriously, I meant no offense, and didn't want to cause a stir. I didn't interpret the replies as offended or stirred, I think they were just saying "it's not clear from your question whether you are already familiar with the most rudimentary* tools used for profiling GCC or potentially reducing time spent in the preprocessor." * and -ftime-report is useful, but quite rudimentary compared with a full profile.
RE: Is VRP is too conservative to identify boolean value 0 and 1?
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Friday, September 02, 2011 5:07 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: Is VRP is too conservative to identify boolean value 0 and
> 1?
>
> On Fri, Sep 2, 2011 at 7:58 AM, Jiangning Liu
> wrote:
> > Hi,
> >
> > For the following small case,
> >
> > int f(int i, int j)
> > {
> > if (i==1 && j==2)
> > return i;
> > else
> > return j;
> > }
> >
> > with -O2 option, GCC has vrp2 dump like below,
> >
> > ==
> >
> > Value ranges after VRP:
> >
> > i_1: VARYING
> > i_2(D): VARYING
> > D.1249_3: [0, +INF]
> > j_4(D): VARYING
> > D.1250_5: [0, +INF]
> > D.1251_6: [0, +INF]
> > j_10: [2, 2] EQUIVALENCES: { j_4(D) } (1 elements)
> >
> >
> > Removing basic block 3
> > f (int i, int j)
> > {
> > _Bool D.1251;
> > _Bool D.1250;
> > _Bool D.1249;
> >
> > :
> > D.1249_3 = i_2(D) == 1;
> > D.1250_5 = j_4(D) == 2;
> > D.1251_6 = D.1250_5 & D.1249_3;
> > if (D.1251_6 != 0)
> > goto ;
> > else
> > goto ;
> >
> > :
> >
> > :
> > # i_1 = PHI <1(3), j_4(D)(2)>
> > return i_1;
> >
> > }
> >
> >
> >
> > Variable D.1249_3, D.1250_5 and D.1251_6 should be boolean values, so
> the
> > their value ranges should be
> >
> > D.1249_3: [0, 1]
> > D.1250_5: [0, 1]
> > D.1251_6: [0, 1]
> >
> > So why current VRP can't find out this value range?
>
> It does - it just prints it as [0, +INF], they are bools with
> TYPE_MAX_VALUE
> == 1 after all.
Richard,
May I use REG_EXPR(rtx of D.1249_3) in xxx.md file to detect whether
D.1249_3 is a bool or not?
Some comments in GCC says REG_EXPR may be lost in back-end. True?
If we do have REG_EXPR info for some cases in back-end, is it guaranteed to
be correct? May I implementing back-end peephole optimization depending on
REG_EXPR?
Thanks,
-Jiangning
>
> Richard.
>
> >
> > I'm asking this question because the optimizations in back-end need
> this
> > info to do advanced optimization.
> >
> > Thanks,
> > -Jiangning
> >
> >
> >
Re: Profiling gcc itself
On Sun, 20 Nov 2011, Jeff Evarts wrote: > On Sun, 20 Nov 2011 11:34:27 -0500, Tim Prince wrote: > > On 11/20/2011 11:10 AM, Basile Starynkevitch wrote: > >> On Sun, 20 Nov 2011 03:43:20 -0800 Jeff Evarts wrote: > >>> I posted this question at irc://irc.oftc.net/#gcc and they suggested > >>> that I pose it here instead. > >> > >> I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps > >> gcc-h...@gcc.gnu.org might > >> be a better place. FWIW, it was I who suggested gcc@ and not gcc-help@ because the question was with regards to profiling of gcc (not with gcc). Besides, I vaguely recall (right or wrong) there had been some related work with reported results, which you perhaps didn't find using your favorite search engine. > Apparently my question "Has anyone done X and what were the results" > has been mysteriously translated into "The GCC compiler is way too > slow and what are you lazy developers going to do to speed up my > compiles?!?". You have yet too few replies to make that conclusion, IMHO. I'd suggest waiting a few days. brgds, H-P
Re: Bootstrap fails in 32bit libjava on x86_64 Fedora 16 with undefined reference to `__cxa_call_unexpected'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/11 16:53, Uros Bizjak wrote: > Hello! > > For some reason bootstrap on Fedora 16 fails when compiling 32bit > libjava with undefined reference to `__cxa_call_unexpected': This is (arguably) a glibc issue. I'm still investigating. Attached you'll find the hack from the gcc46 srpms we're using to work around the problem right now. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOyc/PAAoJEBRtltQi2kC78UoH/RtKNZoNFxV0bkaaDzH5iTWs QWIxLWc8i4cH+otvrGa7qSPnhdtjQ9dp/vsyc3lEz3NS60q/Up7zGeVZYrIGZtC/ eO36ygsd+OO+gsEiKFGEL94yzUWTkRhbsfUewz3VgrwKLwqALhy1zGQxAAq4QtJI yhxbbJJUPz7qMaPJ7EHHSFy/ISjoKA3rjhRqqf9pgeoK8DmYGpSCD+ffJfUI3ohP o18XAwI7BIU2u6pXolFPv4zKnOxASLhlJut8gF4Ty+WB2J58rg3YoyPtu9/625Wj QzNp3eigBz1uq6uLKo6Mpn8drUgzspXAm+eSRnsrp+4u/J/gnoAbgNDe8m9Lwuk= =/DjI -END PGP SIGNATURE- 2011-10-27 Jakub Jelinek * prims.cc (__NO_CTYPE): For glibc define this before including ctype.h. --- libjava/prims.cc2009-04-28 06:02:30.0 +0200 +++ libjava/prims.cc2011-10-27 12:57:42.748752380 +0200 @@ -38,6 +38,14 @@ details. */ #endif #ifndef DISABLE_GETENV_PROPERTIES +#ifdef __GLIBC__ +/* glibc 2.15+ provides even for C++ inline optimized ::isspace etc. + Unfortunately those inlines are throw (), and call a function pointer + (which is throw () too, but with -fnon-call-exceptions this results + in a __cxa_call_unexpected call. This macro disables the optimized + version. */ +#define __NO_CTYPE 1 +#endif #include #include #define PROCESS_GCJ_PROPERTIES process_gcj_properties()
Re: Issues with building gcc trunk with ada on cygwin
On 20 November 2011 12:06, Eric Botcazou wrote: >> Now, are there anyones here that recognise the issue and perhaps have >> an idea of how to address it? > > Take a look at gcc/ada/Makefile.in lines 279 and below: > > ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),) > # On Windows native the tconfig.h files used by C runtime files needs to have > # the gcc source dir in its include dir list > INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. -iquote > $(fsrcdir)/ada \ > -I$(fsrcdir)/../include -I$(fsrcdir) > endif > > It's probably only a matter of adjusting the regexp. I haven't tried it yet but the 'cygwin32' looks suspicsious to me, i.e., the 32, to my understanding that '32' was removed years ago.. weird. -- Cheers, /ChJ
