http://blog.gmane.org/gmane.comp.gcc.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.gcc.devel/126930 <pre>The avr backend auto-generates parts of GCC's texi documentation, namely the supported -mmcu= options, which are about 200. To generate the texi a small C program is used to print the texi to stdout, and that output is then compared against the already existing doc/avr-mmci.texi If the output is the same like in that file, nothing happens. If the output differs from that file, the user (someone building the avr compiler) is nagged to update the existing documentation so that the documentation says in sync with the compiler. The part of t-avr reads: s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext) $(RUN_GEN) $&lt; | sed -e 's:\r::g' &gt; avr-mmcu.texi &lt; at &gt;if cmp -s $(srcdir)/doc/avr-mmcu.texi avr-mmcu.texi; then \ $(STAMP) $&lt; at &gt;;\ else\ echo &gt;&amp;2 ;\ echo "***" &gt;&amp;2 ;\ echo "*** Verify that you have permission to grant a" &gt;&amp;2 ;\ echo "*** GFDL license for all new text in" &gt;&amp;2 ; \ echo "*** avr-mmcu.texi,then copy it to $(srcdir)/doc/avr-mmcu.texi" &gt;&amp;2 ; \ echo "***" &gt;&amp;2 ;\ false; \ fi The problem is comparing the new texi file avr-mmcu.texi against the already existing $(srcdir)/doc/avr-mmcu.texi and factor out different line endings that depend on the build system like LF vs. CRLF. What is the best way to do such a comparison on text level without getting a complaint if the original texi was built on linux and the user builds the compiler under, say, windows? How to cope with different line endings in that case? The sed -e 's:\r::g' from above that tries to fix line endings has the problem that not all sed implementations are the same, i.e. some just do sed -e 's:r::g' and remove all r's. I searched some time how to accomplish this but did not find a neat solution. Can tr from roff be used? Is it a valid prerequisite for GCC? Or open a binary file to write the test instead of printf+stdout? And just omit the sed and don't care at all? Is there a valid compare tool that compares text modulo line-endings? Setting an svn: property so that the texi is binary and not text? Thanks Johann </pre> Georg-Johann Lay 2012-05-26T10:01:58 http://comments.gmane.org/gmane.comp.gcc.devel/126929 <pre>The avr backend auto-generates a part of the texi documentation by means of a small C program. The relevant part of t-avr reads: s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext) $(RUN_GEN) $&lt; | sed -e 's:\r::g' &gt; avr-mmcu.texi There was a problem report that the executable cannot be found. When I wrote that I checked other uses of RUN_GEN (which is empty) in $(builddir)/gcc/Makefile that do calls like $(RUN_GEN) build/... What is the correct way to call the executable? Add ./ like so? s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext) $(RUN_GEN) ./$&lt; | sed -e 's:\r::g' &gt; avr-mmcu.texi Thanks for hints. Johann </pre> Georg-Johann Lay 2012-05-26T09:35:49 http://comments.gmane.org/gmane.comp.gcc.devel/126926 <pre> If I apply this patch, which checks for duplicate hard registers within -fira-share-save-slots, the following *-elf targets fail due to the assert: bfin cris m32c rl78 rx sh sh64 v850 The following succeed: frv h8300 i386 ia64 m32r mep mipsisa32 mipsisa64 mn10300 powerpc tx39 Without this patch, the failing targets eventually overflow the call_saved_regs[] array (size FIRST_PSEUDO_REGISTER) and corrupt other memory and data structures. I originally had an assert for that bounds check too, but this one caught all the cases sooner. Can someone who knows more about IRA and this optimization explain if and/or why duplicate hard regs are allowed at that point, and what if any changes should be made to avoid the array overflow? Thanks, DJ Index: caller-save.c =================================================================== --- caller-save.c(revision 187842) +++ caller-save.c(working copy) &lt; at &gt;&lt; at &gt; -504,12 +504,13 &lt; at &gt;&lt; at &gt; setup_save_areas (void) struct saved_hard_reg *saved_reg2, *saved_reg3; int call_saved_regs_num; struct saved_hard_reg *call_saved_regs[FIRST_PSEUDO_REGISTER]; int best_slot_num; int prev_save_slots_num; rtx prev_save_slots[FIRST_PSEUDO_REGISTER]; + rtx dj_saw[FIRST_PSEUDO_REGISTER]; /* Find saved hard register conflicts. */ saved_reg_conflicts = (char *) xmalloc (saved_regs_num * saved_regs_num); memset (saved_reg_conflicts, 0, saved_regs_num * saved_regs_num); for (chain = reload_insn_chain; chain != 0; chain = next) { &lt; at &gt;&lt; at &gt; -518,12 +519,14 &lt; at &gt;&lt; at &gt; setup_save_areas (void) insn = chain-&gt;insn; next = chain-&gt;next; if (!CALL_P (insn) || find_reg_note (insn, REG_NORETURN, NULL)) continue; + memset(dj_saw, 0, sizeof(dj_saw)); + cheap = find_reg_note (insn, REG_RETURNED, NULL); if (cheap) cheap = XEXP (cheap, 0); REG_SET_TO_HARD_REG_SET (hard_regs_to_save, &amp;chain-&gt;live_throughout); &lt; at &gt;&lt; at &gt; -560,13 +563,21 &lt; at &gt;&lt; at &gt; setup_save_areas (void) if (r &lt; 0 || regno_reg_rtx[regno] == cheap) continue; bound = r + hard_regno_nregs[r][PSEUDO_REGNO_MODE (regno)]; for (; r &lt; bound; r++) if (TEST_HARD_REG_BIT (used_regs, r)) - call_saved_regs[call_saved_regs_num++] = hard_reg_map[r]; + { + call_saved_regs[call_saved_regs_num++] = hard_reg_map[r]; + if (dj_saw[r]) + { +fprintf(stderr, "\033[31mDJERR: DUPLICATE HARD REG %d\033[0m\n", r); +gcc_assert (!dj_saw [r]); + } + dj_saw [r] = 1; + } } for (i = 0; i &lt; call_saved_regs_num; i++) { saved_reg = call_saved_regs[i]; for (j = 0; j &lt; call_saved_regs_num; j++) if (i != j) </pre> DJ Delorie 2012-05-25T23:18:54 http://comments.gmane.org/gmane.comp.gcc.devel/126924 <pre>Snapshot gcc-4.6-20120525 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120525/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 187900 You'll find: gcc-4.6-20120525.tar.bz2 Complete GCC MD5=b61c517c13afbfc306bebdfc33a2dd57 SHA1=758ede6ec739e7bb8206f52c2a67dc937d761d10 Diffs from 4.6-20120518 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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. </pre> gccadmin< at >gcc.gnu.org 2012-05-25T22:54:17 http://comments.gmane.org/gmane.comp.gcc.devel/126921 <pre>Hi, Just to let people know I have succeeded in building gcc-4.7.0 with --enable-build-with-cxx (All stages built as C++) on latest Cygwin with GCC 4.5.3 and on MinGW32 with a rebuilt GCC 4.6.2 as the GCC 4.6.2 that came with MinGW was missing stdarg.h and stddef.h and possibly other headers. Many thanks, Aaron </pre> Aaron Gray 2012-05-25T21:53:11 http://comments.gmane.org/gmane.comp.gcc.devel/126915 <pre>When --with-sysroot is used to configure gcc, build will usually fail if --with-build-sysroot isn't set. Should --with-build-sysroot be set to the same value as --with-sysroot by default if --with-sysroot is used? </pre> H.J. Lu 2012-05-25T18:33:48 http://comments.gmane.org/gmane.comp.gcc.devel/126910 <pre>Snapshot gcc-4.5-20120524 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120524/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 187858 You'll find: gcc-4.5-20120524.tar.bz2 Complete GCC MD5=987f323fd9b4de2df8bec010a85f9253 SHA1=aa914051b2e82adb1026a6f52f71665a05d4aa42 Diffs from 4.5-20120517 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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. </pre> gccadmin< at >gcc.gnu.org 2012-05-24T22:48:57 http://comments.gmane.org/gmane.comp.gcc.devel/126907 <pre>Hello, I'm not sure whether this is standard behaviour or not; nonetheless I was quite surprised: ----8&lt;----8&lt;----8&lt;---- void foo(long); void foo(const char*); void bar() { foo(0); foo(0+0); // ! foo(1-1); // ! foo(1); } ----8&lt;----8&lt;----8&lt;---- The first call to foo() in bar() is ambiguous, all right (integral or ptr), but the next two (marked w/ !) ? Shouldn't the compiler know that 0+0 or 1-1, etc can't be a null pointer? I tried all minor versions from 4.4 to 4.8. Somewhat connected question: if I use |-Wzero-as-null-pointer-constant to detect cases where 0 means null pointer, shouldn't there be a switch that forbids conversion from 0 to null ptr? I have a class that has operator() overloaded for size_t and for const char* (access elements by index or by name). All is well, except for the index 0: the call would be ambiguous. I tried to trick this with 0+0, etc, hence the whole post. 0.0 works, though. Any better ideas? Explicit cast? Supposing that I eliminated all 0's that meant null ptr, using the switch could eliminate this kind of ambiguity, and I could use 0 where I mean 0, without any trickery. Regards, Peter | </pre> Peter A. Felvegi 2012-05-24T19:26:46 http://comments.gmane.org/gmane.comp.gcc.devel/126906 <pre> I've merged trunk into gimple-front-end (rev 187836). I've added a manifest file to use with contrib/testsuite-management/validate_failures.py. Sandeep, this will be useful when we start having more gimple tests (see http://gcc.gnu.org/wiki/Testing_GCC#Using_validate_failures.py). You can use the validator to filter out all the "expected" FAIL/XPASS results from other parts of the testsuite. I will be posting the patches to add the basic dejagnu support for having gimple tests. Tested on x86_64. Diego. </pre> Diego Novillo 2012-05-24T18:32:29 http://comments.gmane.org/gmane.comp.gcc.devel/126905 <pre> For those of you attending the Cauldron meeting in Prague in July, RMS will be in town and will come by to give a talk on the first day of the meeting. See you there! </pre> Diego Novillo 2012-05-24T16:44:05 http://comments.gmane.org/gmane.comp.gcc.devel/126900 <pre>Hello! http://gcc.gnu.org/ml/gcc-help/2012-05/msg00043.html ping? </pre> niXman 2012-05-24T09:26:30 http://comments.gmane.org/gmane.comp.gcc.devel/126897 <pre>Hey everyone, I'm using gcc-4.6.3 as part of the YAGARTO toolchain (http://www.yagarto.de) with an STM32 ARM Cortex-M3 chip and was wondering: what are the math libraries (MPC, MPFR, and GMP) used for? Are they only required internally by gcc or are they implicitly added to the final binary produced by gcc? Thanks, Andrew </pre> Andrew Burks 2012-05-23T22:46:50 http://comments.gmane.org/gmane.comp.gcc.devel/126896 <pre>Dear GCC This is Colin Prior from Sunfreeware and UNIX Packages. Please would you be good enough to update http://gcc.gnu.org/install/binaries.html and add www.unixpackages.com We as you will see from the Sunfreeware site we have removed the majority of our packages including GCC (Solaris 2.5, 2.6 7, 8, and 9) over to the our new site. We may well be interested in doing some joint marketing with you. Let me know if that's of interest. BTW you may want to consider removing the Blastwave link as to all intents and purposes that site has been dead for some time now. Cheers Colin Colin Prior Unix Packages +1 206 310 4610 colin&lt; at &gt;unixpackages.com </pre> Colin Prior 2012-05-23T22:37:48 http://comments.gmane.org/gmane.comp.gcc.devel/126893 <pre> At the bottom of mkconfig.sh in 4.6.2 and 4.7.0: # Avoid changing the actual file if possible. if [ -f $output ] &amp;&amp; cmp ${output}T $output &gt;/dev/null 2&gt;&amp;1; then     echo $output is unchanged &gt;&amp;2     rm -f ${output}T else     mv -f ${output}T $output fi # Touch a stamp file for Make's benefit. rm -f cs-$output echo timestamp &gt; cs-$output Shouldn't the timestamp &gt; cs-$output only be a) mainly if the other file updated, by the mv and b) corner case, if it doesn't exist? Maybe rm -rf by the mv, and echo if not exist?  - Jay </pre> Jay K 2012-05-23T16:04:29 http://comments.gmane.org/gmane.comp.gcc.devel/126891 <pre>Hello All, I came across this issue while working with PowerPC GCC tool chain v4.5.2 for e500mc(64bit)/e5500. Test case compiled with '-O0 -g'. /************************** Test Case ************************/ 1: int main() 2: { 3:int i=0; 4: 5:register float f1 = 55.77f; 6:register double d1 = 22.99f; 7: 8:while (i &lt;= 100) -----------------------------------(A) 9:{ 10:i++; 11:f1 = (float)i / 177 + (float)d1; 12:d1 = (double)i / 155677 + f1; 13:i += (int)d1; 14:} 15: } /**************** Debug Info *************************************/ &lt;2&gt;&lt;5d&gt;: Abbrev Number: 3 (DW_TAG_variable) &lt;5e&gt; DW_AT_name : f1 &lt;61&gt; DW_AT_decl_file : 1 &lt;62&gt; DW_AT_decl_line : 5 &lt;63&gt; DW_AT_type : &lt;0x7f&gt; &lt;67&gt; DW_AT_location : 2 byte block: 90 3f (DW_OP_regx: 63) &lt;2&gt;&lt;6a&gt;: Abbrev Number: 3 (DW_TAG_variable) &lt;6b&gt; DW_AT_name : d1 &lt;6e&gt; DW_AT_decl_file : 1 &lt;6f&gt; DW_AT_decl_line : 6 &lt;70&gt; DW_AT_type : &lt;0x86&gt; &lt;74&gt; DW_AT_location : 2 byte block: 90 3f (DW_OP_regx: 63) /**************** Generated Assembly *************************/ ... .LCFI1: .cfi_def_cfa_register 31 # main.c:3 .loc 1 3 0 li 0,0 # tmp129, stw 0,48(31) # i, tmp129 # main.c:5 .loc 1 5 0 lfs 31,.LC0&lt; at &gt;toc(2) #, f1 --------------------- &gt; (variable F1) # main.c:6 .loc 1 6 0 lfd 31,.LC1&lt; at &gt;toc(2) #, d1 --------------------&gt; (variable D1) # main.c:8 .loc 1 8 0 b .L2 # ..... Looking at the debug info and the generated assembly, the values of variables 'f1' and 'd1' are stored in the same register. Due to this, while debugging, after setting the break point at (A) [line no 8], if we print the value of 'f1' i get the wrong value. /**************** Debugger Output *********************/ (gdb) n 5 register float f1 = 55.77f; (gdb) n 6 register double d1 = 22.99f; (gdb) n 8 while (i &lt;= 100) (gdb) p f1 $1 = 22.9899998 (gdb) p d1 $2 = 22.989999771118164 /************************************************************/ Q: Is this the side effect of using 'register' keyword? If 'f1' is getting optimized out, shouldn't we get that info while debugging? Also, using -fvar-tracking, i get this output while debugging the same code. /**************** Debugger Output *********************/ 5 register float f1 = 55.77f; (gdb) n 6 register double d1 = 22.99f; (gdb) n 8 while (i &lt;= 100) (gdb) p f1 $5 = &lt;optimized out&gt; (gdb) p d1 $6 = 22.989999771118164 /************************************************************/ Regards, Rohit </pre> Rohit Arul Raj 2012-05-23T13:22:57 http://comments.gmane.org/gmane.comp.gcc.devel/126886 <pre>I've put together the following description of C++98/11 ABI (in)compatibility, so people can tell which libraries need to be recompiled. This is useful when you've bought a library that didn't come with source code, and you're trying to figure out if you need to buy a new version. I think this belongs on the Wiki somewhere, but I wanted to run it by the list first to make sure it's accurate. You can probably skip the first section, since it's just a description of how to use the subsequent list. This page explains how to identify when your pre-compiled library (.a or .so) defines a symbol that has a different enough definition in C++98 vs C++11 that it could cause runtime problems if it's linked into a program compiled for the other version. First, get a list of demangled symbols from your .a or .so: $ (find . -name '*.a'|xargs nm -f posix; find . -name '*.so' | xargs nm -f posix -D)|cut -f1 -d' '|LANG=C sort -u|c++filt|sort (There may be better ways to get this list.) Next, find instances in this list of the ABI changes listed below. For example, you might find: std::_List_base&lt;FooBar, std::allocator&lt;FooBar&gt; &gt;::_M_clear() Since std::_List_base::_M_clear() destroys nodes, it's affected by the addition of the _M_size field and can't be used by C++11 code if it was compiled for C++98, or vice versa. If it's possible that code outside the library would use this instance of _List_base, then you have to recompile the library. On the other hand, if FooBar is a type used only inside this library, then code using the library is safe. If FooBar is defined by the library but exposed in one of the library's headers, then the library still needs to be recompiled, since code using it could wind up including the other version's implementation. === ABI Changes === complex::{real,imag}(), std::{real,imag}(complex) The non-const overloads go from returning _Tp&amp; to _Tp. [Since gcc-4.4] std::list, std::_List_impl, and std::_List_base New _M_size member, meaning any method that adds or removes nodes or inspects the size has a new ABI. [Since gcc-4.7] std::operator-(reverse_iterator) and std::operator-(__normal_iterator) may return a different type if reverse_iterator&lt;_IteratorL&gt;::difference_type (respectively, __normal_iterator&lt;_IteratorL, _Container&gt;::difference_type) isn't accurate. [Since gcc-4.4] map::erase(iterator), multimap::erase(iterator), set::erase(const_iterator), set::erase(const_iterator, const_iterator), multiset::erase(const_iterator), multiset::erase(const_iterator, const_iterator): Return type changes from void to iterator. [Since gcc-4.5] _Rb_tree&lt;T, T&gt;::erase(const_iterator), _Rb_tree&lt;T, T&gt;::erase(const_iterator, const_iterator), _Rb_tree&lt;T, pair&gt;::erase(iterator): Return type changes from void to iterator. these are instantiated from map and set. [Since gcc-4.5] vector::data()'s return type changes from pointer to _Tp* This is a no-op with most allocators, but any allocator that defines a non-default pointer typedef will be incompatible. [Since gcc-4.6] Probably safe: istreambuf_iterator::reference changes from _CharT&amp; to _CharT. This could affect return types if they mention 'reference', but they appear not to mention it when istreambuf_iterator is involved. [Since gcc-4.7] Probably safe: map::erase(iterator, iterator), multimap::erase(iterator, iterator) C++11 uses const_iterator, which doesn't collide. Other versions of gcc are unlikely to have defined this overload in C++98 mode, and C++11 is unlikely to have defined the iterator version. [Since gcc-4.5] Probably safe: Types with node allocators, like deque and tree C++11 uses _M_get_Node_allocator().construct(node, ...), while C++98 uses get_allocator().construct(node-&gt;_M_value_field, ...). The node's constructor forwards to the value_field's constructor, so this works by default. Can this cause problems with some mix of C++98/C++11 allocator compilations? I haven't analyzed the debug and profile headers. I found these differences by grepping for GXX_EXPERIMENTAL_CXX0X inside libstdc++, and examining each instance to see if there was an #else clause that had different behavior in C++11 vs C++98. === ABI non-changes === libstdc++'s binary component is nearly ABI-compatible between C++98 and C++11. Most incompatibilities are in the templates defined in headers, but the complex&lt;&gt; stream operators call the real() and imag() methods that change return type. If these calls aren't inlined, (and they're likely to be inlined), then libstdc++ (which is compiled in C++98 mode by default) could cause problems when linked into C++11 programs. (http://gcc.gnu.org/PR53429) There have been some claims that the change in the definition of POD types causes an ABI incompatibility, but apparently it doesn't in practice: http://gcc.gnu.org/ml/gcc/2012-01/msg00056.html. </pre> Jeffrey Yasskin 2012-05-22T14:04:46 http://comments.gmane.org/gmane.comp.gcc.devel/126881 <pre>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. </pre> Iyer, Balaji V 2012-05-21T22:52:12 http://comments.gmane.org/gmane.comp.gcc.devel/126877 <pre> http://www.youtube.com/watch?feature=youtu.be&amp;hl=ro&amp;v=_Sl3Ox7RMnE To unsubscribe please send email to unsubscribe&lt; at &gt;cc.psd-prahova.ro </pre> cramer< at >cc.psd-prahova.ro 2012-05-21T19:04:28 http://comments.gmane.org/gmane.comp.gcc.devel/126874 <pre>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-&gt; 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-&gt; 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 </pre> PERRONNET Alain 2012-05-21T14:25:44 http://comments.gmane.org/gmane.comp.gcc.devel/126863 <pre>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. </pre> gccadmin< at >gcc.gnu.org 2012-05-20T22:46:48 http://comments.gmane.org/gmane.comp.gcc.devel/126862 <pre>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, </pre> Toon Moene 2012-05-20T19:23:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gcc.devel