Failing bootstraps --with-build-config=bootstrap-lto
Hi, I have added a line to my "Failing bootstrap" mails, that indicates what configure options I passed. For instance, the last entry reads (at the end): Configured by: configure --prefix=/tmp/c --with-gnu-as --with-gnu-ld --enable-languages=c++ --with-build-config=bootstrap-lto --disable-libmudflap --disable-multilib --disable-nls --with-arch=native --with-tune=native I hope this helps. I still have to figure out how to include the target triple (probably x86_64-unknown-linux-gnu) in the subject. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
gcc-4.8-20120520 is now available
Snapshot gcc-4.8-20120520 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120520/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 187696 You'll find: gcc-4.8-20120520.tar.bz2 Complete GCC MD5=bf2fa8dba870f9bfffe5f4a1047cf0e2 SHA1=c32ac35d661b5e7714f2a76697f013556a4bb2ed Diffs from 4.8-20120513 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
Jonathan Wakely writes: > On 19 May 2012 12:36, Gabriel Dos Reis wrote: >> On Fri, May 18, 2012 at 10:53 PM, Jay K wrote: >>> >>> /src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go >>> >>> >>> book2:gccgo-4.7 jay$ g++ -v >>> Using built-in specs. >>> Target: i686-apple-darwin9 >>> Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking >>> -enable-werror --prefix=/usr --mandir=/share/man >>> --enable-languages=c,objc,c++,obj-c++ >>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ >>> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib >>> --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic >>> --host=i686-apple-darwin9 --target=i686-apple-darwin9 >>> Thread model: posix >>> gcc version 4.0.1 (Apple Inc. build 5493) >>> >>> >>> a lot of: >>> >>> /usr/include/c++/4.0.0/tr1/functional_iterate.h:912: error: cannot use >>> typeid with -fno-rtti >>> /src/gcc-4.7.0/gcc/go/gofrontend/string-dump.h: At global scope: >> >> This is using TR1. So the question is whether the Go front-end is using >> it just as a convenience whether it really needs TR1 and the implied >> RTTI (typeid). > > In later releases tr1::function guards the code using RTTI with > __GXX_RTTI so it can be used with -no-rtti. > > I think the right answer is to use a later GCC or don't use > --disable-bootstrap. 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 . Ian
Re: tree-nomudflap.c dependency on gt-tree-mudflap.h not needed
Jay K writes:
> gcc-4.6.2/gcc/Makefile.in:
>
>
> tree-nomudflap.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TREE_INLINE_H) \
> $(C_TREE_H) $(C_COMMON_H) $(GIMPLE_H) $(DIAGNOSTIC_H) $(HASHTAB_H) \
> output.h langhooks.h tree-mudflap.h $(TM_H) coretypes.h \
> $(GGC_H) gt-tree-mudflap.h $(TREE_PASS_H) $(DIAGNOSTIC_CORE_H)
>
>
> gcc-4.6.2/gcc/tree-nomudflap.c
>
> /* Instead of:
> #include "gt-tree-mudflap.h"
> We prepare a little dummy struct here.
> */
>
> EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gt_tree_mudflap_h[] = {
> LAST_GGC_ROOT_TAB
> };
>
>
> so I don't believe gt-tree-mudflap.h should be in the dependencies of
> tree-nomudflap.o.
I agree.
Ian
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
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++? -- Gaby
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
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. Ian
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
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. The reason I am suggesting this is that will save you from all the vaguaries of partial support of anything after C++03. I suspect that could be made to work even with --disable-bootstrap, or am I off? -- Gaby
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
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: About trees and expanded code by macros
Alberto Lozano Alelu a écrit: > Hello. Hello Alberto, > I'am developing an statement detector for c++ and I would like to > detect if an statement is expanded from macro. I guess you are doing this from a plugin? > Can I detect in ast tree if an statement is expanded code from macro? As Manuel has said in another thread, if you are using GCC 4.7, you need to have the option -ftrack-macro-expansion turned on. Then, in the code, you need to get a handle on a token (instance of cp_token, defined in gcc/cp/parser.h) of your statement. The information you are looking for is basically encoded in the cp_token::location field. The function you want to use on that cp_token::location field is line_map_location_from_macro_expansion_p, declared and commented in libcpp/include/line-map.h. The argument for the first parameter of that function is the global variable named "line_table". If you are using the current development version of GCC from trunk (that is going to be 4.8), then you don't even need to pass -ftrack-macro-expansion to the compiler as it is turned on by default. For versions earlier than 4.7, I am afraid you cannot have the information you want without (at least) patching the interface between the parser and the pre-processor. I hope this helps. -- Dodji
