RE: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by > the way.) I don't know why. I'm getting them, at least via the list. > Since the OP is apparently seeing Go build in stage 1, I assume that the > OP is configuring with --disable-bootstrap or with Right. I thought I was clear on that. So I guess there is nothing to see here..move along..but..why the use of -fno-rtti? It seems like a guess of "more work for less good"? i.e. remove those lines in configure and more fairly reasonable stuff works? I can see maybe the opposite though. Maybe the point is to avoid poor rtti implementations in old gcc bootstrap?? Or maybe the point was to compile C, really C code, with g++, and turn off "gratituitous" C++ features that the code "doesn't even come near" (i.e. the bulk of gcc really is C that is compatible with gcc, vs. the go frontend that is currently a rare case of "actual C++". If that's the rationale, again, maybe the lines should just be removed. I understand this is much to do about very little. Heck maybe rtti and exceptions are decent enough out there that stage1 could use them?? I "always" use -disable-bootstrap. So much gain for acceptable pain. I know I'm cutting corners, but I'm in active development of very small changes. My bootstrap compiler isn't super wierd/bad, just a somewhat old gcc/g++. (I have relatively recently bootstrapped from K&R cc on HP-UX though gcc 3.x to get to gcc 4.x, and buggy compilers I think on Irix that slightly miscompile GNU make, forcing one to loop back with gcc and rebuild make and then rebuild gcc (maybe in-tree the first time, I forget..I should check my notes..).. But anyway... I don't want to change a header and have make go through and build the compiler multiple times. I have enough problems with incrementality building way too much..that I should look into.. I really just wanted to step through gccgo to understand its implementation to inform my own front end work. (Yes, go is certainly an interesting hybrid -- native code + static compilation + static typing + C-like syntax + garbage collection + fast compilation via a good module system instead of the C preprocessor toiling over the same million lines repeatedly... -- you don't see that often. :) Thank you, - Jay > From: i...@google.com > To: g...@integrable-solutions.net > CC: jwakely@gmail.com; jay.kr...@cornell.edu; gcc@gcc.gnu.org > Subject: Re: -fno-rtti in configure.ac breaks building go? (older g++, > -disable-bootstrap) > Date: Sun, 20 May 2012 22:41:08 -0700 > > Gabriel Dos Reis writes: > > > On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor wrote: > >> Gabriel Dos Reis writes: > >> > >>> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor > >>> wrote: > >>> > To be clear, as far as I can see the Go frontend isn't doing anything > wrong or dubious. It just happens to #include when > it is available but is not. It looks like in gcc 4.0 > you can not #include when using -fno-rtti. > > We could work around this by changing gcc/configure.ac to check whether > that #include works with -fno-rtti. If that fails, > the Go frontend will next try . > >>> > >>> Is it unacceptable for the Go front-end to use the stage1 g++, especially > >>> as we are moving toward switching to C++? > >> > >> The Go frontend does use the stage1 g++. > >> > >> I assume that this error can only occur when using --disable-bootstrap > >> or when building Go in stage 1. I don't see how this error could occur > >> when building stages 2 or 3 of a bootstrap. > > > > OK. In that case, maybe make Go build only in stage2. > > > By default, Go will only build in stages 2 and 3. > > Since the OP is apparently seeing Go build in stage 1, I assume that the > OP is configuring with --disable-bootstrap or with > --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by > the way.) > > That is, normally, everything should be fine. But if you use unusual > configure options you can definitely get into unusual cases. Ideally > those cases should be made to work if possible. It's not very > important, though. > > Ian
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
Jay K writes: >> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by >> the way.) > > I don't know why. > I'm getting them, at least via the list. For every e-mail I send to jay.kr...@cornell.edu, I'm getting a bounce from cashub03.exchange.cornell.edu saying - The following addresses had permanent fatal errors - jay.kr...@gmail.com (reason: 550 5.7.1 Unauthenticated email is not accepted from this domain. r15si1037948qct.2) (expanded from: ) I would send you more details off-list but you probably wouldn't get them. > So I guess there is nothing to see here..move along..but..why the use of > -fno-rtti? > It seems like a guess of "more work for less good"? GCC does not use RTTI information, and using -fno-rtti saves some space in the generated compiler. > I can see maybe the opposite though. > Maybe the point is to avoid poor rtti implementations in old gcc bootstrap?? > Or maybe the point was to compile C, really C code, with g++, and turn off > "gratituitous" > C++ features that the code "doesn't even come near" (i.e. the bulk of gcc > really is C > that is compatible with gcc, vs. the go frontend that is currently a rare > case of "actual C++". > If that's the rationale, again, maybe the lines should just be removed. I > understand this is > much to do about very little. No, that's not it. The Go frontend is actual C++, but it doesn't use RTTI either. What you are running into is a bug in the GCC 4.0 implementation of -fno-rtti. > I don't want to change a header and have make go through and build the > compiler multiple times. > I have enough problems with incrementality building way too much..that I > should look into.. The correct fix is the one I alluded to earlier: change the mainline gcc/configure.ac to test whether works correctly when using -fno-rtti. That would detect the buggy GCC 4.0 implementation, and avoid using in that case. Ian
Re: MULTILIB_OPTIONS and DRIVER_SELF_SPEC
On 05/11/2012 03:16 PM, Paulo J. Matos wrote:
> Hi,
>
> MULTILIB_OPTIONS containing options defined in DRIVER_SELF_SPEC seemed
> to be fine in GCC46 but fail in GCC47.
>
> For example, I have:
> xap.h:
> #define DRIVER_SELF_SPECS \
> "%{help:-v} % "%{mno-args-span-regs-and-mem:-mno-split-args}
> % "%{mno-inline-block-copy-mode:-mno-block-copy}
> % "%{mpu:-mno-block-copy -mfunction-ptr-pi} %
> t-xap:
> MULTILIB_OPTIONS= msmall-mode/mpu
>
> However, while building GCC I get that xgcc cannot understand -mpu:
> Running configure in multilib subdir mpu
> pwd:
> /home/pm18/p4ws/pm18_binutils/bc/main/result/linux/intermediate/FirmwareGcc47Package/xap-local-xap
> mkdir mpu
> configure: creating cache ./config.cache
> checking build system type... i686-pc-linux-gnu
> checking host system type... xap-local-xap
> checking for --enable-version-specific-runtime-libs... no
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for gawk... gawk
> xgcc: error: unrecognized command line option '-mpu'
>
>
> What happened in GCC47 for this to occur?
Options not explicitly described in the compiler before their use in a
spec rules are now rejected. So you probably need to describe it into
your target optimization file, (something like xap.opt).
Cheers
Christian
>
> Cheers,
>
Problem of gfortran compilation with -O option
My program and subroutines are mainly written in fortran 77 with blanck common of different sizes. The program contains the maximum byte declaration of the blanck common. 1% are written in C, compiled with gcc. -bash-> gfortran -v Utilisation des specs internes. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Modèle de thread: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) -bash-> If the program and subroutines are compiled with the option -g the load-module is OK. if the program and subroutines are compiled with the option -O the execution of the load-module gives errors. It seems that the blank common has not the same maximum length in bytes in all subroutines and the shift produces the errors. For 25 years, this maximum was respected in all subroutines. It seems that a modification for the -O option has been recently done. Have you an option for the compilation which imposes the same length in bytes (the maximum found during the separated compilations) to the blank common? or an other method to obtain that? Cordially Alain PERRONNET http://www.ann.jussieu.fr/~perronnet
Re: Extension to compare-elim
On 17/05/12 17:08, Richard Henderson wrote: My question is, why are you generating compares in two different modes early, before compare-elim runs? If you hadn't done that, your redundant compare would already be eliminated. I just looked at the rx code and it seems to be doing something similar as my port. The split of cbranch is done after reload but the split pass after reload still happens before compare-elim so I don't think you can commit to a mode _after_ compare-elim, only before. If so, rx suffers from the same problem as my port. Will try to reproduce it in rx. There's some amount of support for taking a full CCmode and using SELECT_CC_MODE to find one that fits all the uses, but that's only used in the places we're trying to replace a clobber. Is this the code in combine.c? Cheers, -- PMatos
Re: Problem of gfortran compilation with -O option
PERRONNET Alain wrote: My program and subroutines are mainly written in fortran 77 with blanck common of different sizes. If the program and subroutines are compiled with the option -g the load-module is OK. if the program and subroutines are compiled with the option -O the execution of the load-module gives errors. The question is not appropriate for gcc@ mailing list, which is about the development of GCC and not its usage. The gcc-help@ or the fortran@ lists would be more appropriate. I have to admit that I have no idea why you get different results for -g and -O. Additionally, it is unclear to me whether you get an error message of the compiler or whether your program fails at run time. Especially, if it is the former: Can you provide more information? For instance, a small test case, the exact compiler options you used, the error messages you get and the result you expect. If the latter, try the flag -fno-align-commons. (See description at http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html) For a per-version overview about the compiler changes, search for "common" at http://gcc.gnu.org/wiki/GFortran#news Tobias
cine castiga
http://www.youtube.com/watch?feature=youtu.be&hl=ro&v=_Sl3Ox7RMnE To unsubscribe please send email to unsubscr...@cc.psd-prahova.ro
RE: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
[again as plain text, sorry, with edits] I know gccgo is actually C++. But why was no-rtti specified? Maybe that is for the other code, the C code? But I see: > and using -fno-rtti saves some space in the generated compiler. Is it worth it? I guess you could configure with and without -fno-rtti + #include and use the combination that works? Kind of you said that, but alternatively, use unordered_hashmap either way, but only -fno-rtti if it works? I do realize though there is another factor, it might be interesting to use just map, for older compilers/libraries, since unordered is "new". Thank you, sorry, I'm in a rush right now, - Jay > From: i...@google.com > To: jay.kr...@cornell.edu > CC: g...@integrable-solutions.net; jwakely@gmail.com; gcc@gcc.gnu.org > Subject: Re: -fno-rtti in configure.ac breaks building go? (older g++, > -disable-bootstrap) > Date: Mon, 21 May 2012 06:48:08 -0700 > > Jay K writes: > > >> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by > >> the way.) > > > > I don't know why. > > I'm getting them, at least via the list. > > For every e-mail I send to jay.kr...@cornell.edu, I'm getting a bounce > from cashub03.exchange.cornell.edu saying > > - The following addresses had permanent fatal errors - > jay.kr...@gmail.com > (reason: 550 5.7.1 Unauthenticated email is not accepted from this domain. > r15si1037948qct.2) > (expanded from: ) > > I would send you more details off-list but you probably wouldn't get > them. > > > > So I guess there is nothing to see here..move along..but..why the use of > > -fno-rtti? > > It seems like a guess of "more work for less good"? > > GCC does not use RTTI information, and using -fno-rtti saves some space > in the generated compiler. > > > > I can see maybe the opposite though. > > Maybe the point is to avoid poor rtti implementations in old gcc bootstrap?? > > Or maybe the point was to compile C, really C code, with g++, and turn off > > "gratituitous" > > C++ features that the code "doesn't even come near" (i.e. the bulk of gcc > > really is C > > that is compatible with gcc, vs. the go frontend that is currently a rare > > case of "actual C++". > > If that's the rationale, again, maybe the lines should just be removed. I > > understand this is > > much to do about very little. > > No, that's not it. The Go frontend is actual C++, but it doesn't use > RTTI either. What you are running into is a bug in the GCC 4.0 > implementation of -fno-rtti. > > > > I don't want to change a header and have make go through and build the > > compiler multiple times. > > I have enough problems with incrementality building way too much..that I > > should look into.. > > The correct fix is the one I alluded to earlier: change the mainline > gcc/configure.ac to test whether works correctly > when using -fno-rtti. That would detect the buggy GCC 4.0 > implementation, and avoid using in that case. > > Ian
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
Jay K writes: > I know gccgo is actuall C++.But why was no-rtti specified? Maybe that > is for the other code, the C code? Thank you, sorry, I'm in a rush > right now, - Jay I thought I answered that earlier. When building C++ code that is part of GCC itself, we use -fno-rtti because GCC never uses RTTI, and using -fno-rtti causes the compiler to be smaller. So there is an advantage to using -fno-rtti, and there is no benefit to using -frtti. So we use -fno-rtti. You are running into a problem with that, but the problem has nothing to do with mainline GCC. It is a bug in GCC 4.0. It's unfortunate that GCC 4.0 has a bug with -fno-rtti, but there is no way that we retroactively fix that. Ian
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
Jay K writes: > I know gccgo is actually C++. > But why was no-rtti specified? Maybe that is for the other code, the C code? Answered previously. > But I see: > > > and using -fno-rtti saves some space in the generated compiler. > > > > Is it worth it? Sure, why not? We make similar changes for much smaller benefits. It's worth bearing in mind that it is causing you trouble because 1) you are not using the recommend and tested build procedure, and 2) you are using the non-recommended procedure starting with a compiler that is 7 years old. You have perfectly good reasons for doing that, but the reality is that if you want to do this kind of thing, you have to be prepared for problems. > I guess you could configure with and without -fno-rtti + #include > and use > > the combination that works? Kind of you said that, but alternatively, use > unordered_hashmap either way, > > but only -fno-rtti if it works? I do realize though there is another factor, > it might be > > interesting to use just map, for older compilers/libraries, since unordered > is "new". You don't need to try it either way, because if is unavailable the Go frontend will simply use . And if is unavailable, the Go frontend will use . In other words, the Go frontend is already prepared to fall back, based on the results of configure tests. The problem here is that the configure test sees that is available, but does not realize that although the header is available it does not actually work when using -fno-rtti. Ian
Enabling a function based on Language
Hello Everyone, Is there a #define in GCC that will turn on only for certain languages? I am trying to use build_array_ref but it is giving me a undefined reference for f951. This code that I am trying to use will ONLY execute if we have a C/C++ code. Is it possible for me to enclose this inside some #defines (or a combination of them)? Any help is greatly appreciated! Thanks, Balaji V. Iyer.
Re: Enabling a function based on Language
"Iyer, Balaji V" writes: > Is there a #define in GCC that will turn on only for certain languages? > I am trying to use build_array_ref but it is giving me a undefined reference > for f951. This code that I am trying to use will ONLY execute if we have a > C/C++ code. Is it possible for me to enclose this inside some #defines (or a > combination of them)? By definition, no, there isn't. The middle-end is compiled once, into a library. Then each frontend is linked against that library. Calling a frontend function like build_array_ref from the middle-end is always a mistake. In the middle-end you should probably be making a POINTER_PLUS_EXPR node or something along those lines. Ian
