Re: gcc 4.7: -march=corei7-avx bug?
On Thu, 29 Mar 2012 04:53:45 -0300 Dâniel Fraga wrote: > I tried to compile Firefox 11 with gcc 4.7 optimized with: > > -O3 -march=corei7-avx (I have a core i7 2700k) > > But Firefox segfaults (backtrace provided, although it seems > not very useful): > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762 > > If I compile with -march=corei7 it runs perfectly. > > Maybe a gcc bug? > > How can I help you to debug this? We've had to disable -mavx for firefox builds due to numerous issues like this. Search the mozilla bugzilla for stack alignment issues. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
GCC 4.7 build problems
hi, GCC 4.7.0 is a big step forward! Really a quantumleap. Works great at opensuse 11.3, both i386 and x64 here at AMD64 and intel Xeon i386 install. Fails to build at OpenSuse 11.2 as well as Scientific Linux 6.2 x64 hardware: dual socket Xeon L5420 in both cases. Build error: "configure: error: cannot compute suffix of object files: cannot compile" Exactly at same spot the same error like at opensuse 11.2 The building at Scientific Linux 6.2 x64 is pretty important - it's the same distro basically like RHEL 6.2 SL 6.2 runs a cluster for me. Performance there is crucial. Anyone knows a way how to get it to work there? Is this the correct list to report build errors? Thanks in Advance, Vincent
Re: GCC 4.7 build problems
On Sun, 15 Apr 2012, Vincent Diepeveen wrote: hi, GCC 4.7.0 is a big step forward! Really a quantumleap. Works great at opensuse 11.3, both i386 and x64 here at AMD64 and intel Xeon i386 install. Fails to build at OpenSuse 11.2 as well as Scientific Linux 6.2 x64 hardware: dual socket Xeon L5420 in both cases. Build error: "configure: error: cannot compute suffix of object files: cannot compile" Exactly at same spot the same error like at opensuse 11.2 The building at Scientific Linux 6.2 x64 is pretty important - it's the same distro basically like RHEL 6.2 SL 6.2 runs a cluster for me. Performance there is crucial. Anyone knows a way how to get it to work there? http://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F Is this the correct list to report build errors? No, please send any follow-up to gcc-h...@gcc.gnu.org only. -- Marc Glisse
Re: [gnat] reuse of ASTs already constructed
I looked into the second problem from http://gcc.gnu.org/ml/gcc/2009-08/msg00475.html , > 2) The 'X' lines in the ALI files are not what they should be. > This is due to the fact that Lib.Xref.Generate_(Definition|Reference) is > called during semantic analysis. However, when I discover that a > tree was already built for a main unit by a previous compilation, > Sem is not redone for that tree. [...] and I see two possible solutions: 1) Extend Lib.Xref.Generate_Reference, Sem_Util.Process_End_Label and others for the case "not In_Extended_Main_Source_Unit" in multi source compilation mode to buffer the generated references for possible later consumption by the main unit for which they are intended. If the main unit is not part of the main units given in the multi source compile job then the buffered data can be discarded. 2) Determine an ordering of the main units such that main units with little or no dependencies precede main units that depend on them. Submit units to semantic analysis in the determined order. Both approaches seem quite heavy. Solution 2 looks more elegant to me. OTOH this would require a separate analysis of the with clauses prior to invoking Sem proper. Oliver
Re: Switching to C++ by default in 4.8
On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu wrote: > > And I want to say that tree/gimple/rtl are compiler's data(or state), > not compiler's text(or logic), the most important thing about them is > how to access their fields. > Given the above assumption, now I doubt the necessity of accessor macros or C++ getter/setter method. Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or "tree->get_code()" ? -- Chiheng Xu
Re: [PATCH] Add StarPU on extensions.html
On Thu, 12 Apr 2012, Ludovic Courtès wrote: > As suggested by Gerald Pfeifer. Thanks, Ludovic. http://gcc.gnu.org/extensions.html now has this reference. Gerald
gcc-4.8-20120415 is now available
Snapshot gcc-4.8-20120415 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120415/ 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 186473 You'll find: gcc-4.8-20120415.tar.bz2 Complete GCC MD5=b9a4b99246cea0a8ea0f1a28d6d89554 SHA1=b65f47b3f13c51460ce323ac93dc0bbe0d7d8af8 Diffs from 4.8-20120408 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.
Maxim Kuvyrkov appointed Android sub-port reviewer
I am pleased to announce that the GCC Steering Committee has appointed Maxim Kuvyrkov as reviewer for the Android sub-port. Please join me in congratulating Maxim on his new role. Maxim, please update your listing in the MAINTAINERS file. Happy hacking! David
Re: Problems building 4.8 snapshot with CygWin
On 14/04/2012 14:58, Kai Tietz wrote: > 2012/4/14 Nicolai Josuttis: >> The first problem was that >> build/gcc/gengtype-lex.c >> was created with DOS-Newlines (CR-LF), >> which makes the following compiling fail: >> make[2]: Entering directory `/cygdrive/p/gcc480snap-install/build/gcc' >> gcc -c-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual >> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute >> -Wold-style-definition -fno-common -Wno-error -DHAVE_CONFIG_H >> -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-4.8-20120401/gcc >> -I../../src/gcc-4.8-20120401/gcc/build >> -I../../src/gcc-4.8-20120401/gcc/../include >> -I../../src/gcc-4.8-20120401/gcc/../libcpp/include >> -I/cygdrive/p/gcc480snap-install/build/./gmp >> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/gmp >> -I/cygdrive/p/gcc480snap-install/build/./mpfr >> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpfr >> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpc/src >> -I../../src/gcc-4.8-20120401/gcc/../libdecnumber >> -I../../src/gcc-4.8-20120401/gcc/../libdecnumber/bid -I../libdecnumber \ >>-o build/gengtype-lex.o gengtype-lex.c >> After SED-ing CR-LF to LF in that file the compilation continues. > About this SED issue I am not sure if this is for real a gcc bug. When this happens, it's usually a result of using a Windows GUI program to unpack the tarball rather than the command-line tar program. WinZIP in particular has a "helpful" option setting somewhere in the prefs that automatically converts LF-ending files to CR-LF on unpack, IIRC. Use "tar -xvfj gcc-4.8-20120401.tar.bz2" instead. cheers, DaveK
