[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Michael Davies changed: What|Removed |Added CC||nemykal at mercurylampe dot ||org --- Comment #3 from Michael Davies 2013-03-30 05:26:32 UTC --- I get this same error when trying to compile kernel 3.8.5 with the hardened grsecurity patch, and selecting CONFIG_PAX_CONSTIFY_PLUGIN: scripts/kconfig/conf --silentoldconfig Kconfig HOSTCXX -fPIC tools/gcc/colorize_plugin.o HOSTCXX -fPIC tools/gcc/constify_plugin.o tools/gcc/constify_plugin.c:35:20: fatal error: target.h: No such file or directory #include "target.h" ^ compilation terminated. make[1]: *** [tools/gcc/constify_plugin.o] Error 1 make: *** [gcc-plugins] Error 2 Worked fine in 4.7.2, doesn't work with 4.8.0
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #21 from Jerry DeLisle 2013-03-30 05:05:03 UTC --- Oops! Disregard Comment #20. There is a not so subtle effect when one mixes up the letter 'l' and the digit '1' in names.
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle 2013-03-30 04:08:19 UTC --- Agree, we should just audit list_read.c for this case.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #20 from Jerry DeLisle 2013-03-30 03:54:27 UTC --- Lets take namelist out of the picture here for the case of comment #6 program test_type_extension type t1_t real :: x end type t1_t type, extends(t1_t) :: t1e_t character(8) :: string end type t1e_t type(t1e_t) :: t1e tle%x = 5.678 end program test_type_extension $ gfc pr55117.f90 pr55117.f90:13.6: tle%x = 5.678 1 Error: Symbol 'tle' at (1) has no IMPLICIT type Ifort agrees with gfortran on this example So, I think this PR (55117) can be closed and if the example in this comment and #6 is another bug, lets open a new PR for it.
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle 2013-03-30 03:30:25 UTC --- This bug fixed by Tilo's patch. Closing.
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #25 from Jerry DeLisle 2013-03-30 03:18:49 UTC --- Lets close this one and carry forward on PR56660.
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle 2013-03-30 03:13:27 UTC --- Fixed on trunk, lets close this one and will carry forward on 56660.
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 --- Comment #24 from Jerry DeLisle 2013-03-30 02:58:25 UTC --- Created attachment 29751 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29751 Related test case This example fails with a runtime error and passes with ifort. The other cases in this PR are fixed.
[Bug libstdc++/56785] New: std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 Bug #: 56785 Summary: std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@doublewise.net #include class Empty { }; int main() { static_assert(sizeof(std::tuple>) == sizeof(std::tuple), "Too big"); } [david@localhost test]$ g++ source/test.cpp -std=c++11 -Wall -Wextra -pedantic source/test.cpp: In function ‘int main()’: source/test.cpp:23:2: error: static assertion failed: Too big The static_assert does not fail if I change it to be a std::tuple on both sides, however, or any number of int other than exactly 2. I also get this bug regardless of the type in the std::tuple (for instance, my own class type). Therefore, I have created a workaround, demonstrated such: #include class Empty { }; class Empty2 { }; int main() { static_assert(sizeof(std::tuple, Empty2>) == sizeof(std::tuple), "Too big"); static_assert(sizeof(std::tuple, Empty2>) == sizeof(int) * 2, "Too big"); } [david@localhost test]$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #5 from Jason Merrill 2013-03-30 00:31:50 UTC --- Fixed for 4.7.3/4.8.1/4.9.
[Bug c++/22488] [4.6/4.7/4.8/4.9 Regression] push_fields_onto_fieldstack calculates offset incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488 Jason Merrill changed: What|Removed |Added Priority|P5 |P2 Status|WAITING |NEW AssignedTo|jason at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #56 from Jason Merrill 2013-03-30 00:30:38 UTC --- I still hope to get to this, but I don't anticipate it being a high priority for me any time soon, so I'm going to unassign myself for now. I'm also going to bump up the priority again.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 --- Comment #2 from michael at talamasca dot ocis.net 2013-03-30 00:26:53 UTC --- The bug itself seems to have been silently fixed in 4.7.2 or earlier, maybe. My testcase no longer causes cmov to be emitted, although this could be an accidental side effect of other changes. However, there is a related bug that is definitely still present. I noticed the first bug because GCC itself is also an example of code that triggers it. This means that modern versions of GCC may fail to bootstrap themselves from older GCCs that have the original bug. Fixing this second bug is fairly simple, changing the ifdef that controls SSE use in libcpp/lex.c to require GCC_VERSION >= 4008 instead of 4005. (The exact value is not certain, but it must at least be 4007 since 4.6.0 is known to have the bug.) It would be a good idea to fix this in 4.7.3. As the last version compilable from C alone, it will be a likely intermediate stop for anyone trying to bootstrap up from an ancient GCC installation.
[Bug target/49880] SuperH: ICE when -m4 is used with -mdiv=call-div1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Oleg Endo 2013-03-29 23:18:50 UTC --- Fixed for 4.8 and 4.7.
[Bug fortran/41137] inefficient zeroing of an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #16 from Tobias Burnus 2013-03-29 22:38:58 UTC --- Possible off-topic remark - or hitting right on the nail: Looking at a(:,:,:,:)=0.0 and a(5:) = 0.0 I wonder whether it couldn't be handled via RANGE_REF, e.g. RANGE_REF(a,5,...) = { }; should work if I am not mistaken. Currently, we only do "a = 0.0" -> "a = {};". See ARRAY_RANGE_REF in trans-expr.c's class_array_data_assign (gfc_index_zero_node is the offset) for the usage; see also GCC internal manual and Ada.
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203 --- Comment #13 from Tobias Burnus 2013-03-29 22:35:01 UTC --- FIXED on the 4.9 trunk. Thanks Toon for pointing out this feature. The feature is handled in the same way as IBM: The hidden present argument is passed before the hidden string-length arguments.
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Tobias Burnus 2013-03-29 22:32:32 UTC --- Author: burnus Date: Fri Mar 29 22:26:17 2013 New Revision: 197252 URL: http://gcc.gnu.org/viewcvs?rev=197252&root=gcc&view=rev Log: 2013-03-29 Tobias Burnus PR fortran/35203 * trans-decl.c (create_function_arglist): Pass hidden argument for passed-by-value optional+value dummies. * trans-expr.c (gfc_conv_expr_present, gfc_conv_procedure_call): Handle those. 2013-03-29 Tobias Burnus PR fortran/35203 * gfortran.dg/optional_absent_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/optional_absent_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/41137] inefficient zeroing of an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 --- Comment #15 from Thomas Koenig 2013-03-29 22:19:05 UTC --- The patch from comment#12 causes memory failure of the following code: module zero implicit none contains subroutine foo(a) real, contiguous :: a(:,:) a(:,:) = 0 end subroutine foo end module zero program main use zero implicit none real, dimension(5,5) :: a a = 1. call foo(a(1:5:2,1:5:2)) write (*,'(5F12.5)') a end program main which is a bit strange.
[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 Joel Sherrill changed: What|Removed |Added Host||centos-6.4/i686 --- Comment #3 from Joel Sherrill 2013-03-29 22:18:26 UTC --- Adding another data point. This also fails on gcc63.fsffrance.org which is: $ ssh j...@gcc63.fsffrance.org Linux deluxe 2.6.26-2-sparc64-smp #1 SMP Sun Mar 4 22:02:58 UTC 2012 sparc64 $ cat /etc/issue Debian GNU/Linux 5.0 \n \l
[Bug fortran/56744] [meta-bug] Namelist bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 Ever Confirmed|0 |1
[Bug fortran/49232] Pointer assignment of stride to CONTIGUOUS pointer not diagnosed as invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1
[Bug fortran/56765] [OOP] compilation errors/ICE with unlimited polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 --- Comment #3 from janus at gcc dot gnu.org 2013-03-29 21:30:03 UTC --- With this patch ... Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 196862) +++ gcc/fortran/resolve.c(working copy) @@ -2538,7 +2538,9 @@ found: expr->ts = sym->ts; expr->value.function.name = sym->name; expr->value.function.esym = sym; - if (sym->as != NULL) + if (sym->result->ts.type == BT_CLASS && CLASS_DATA (sym->result)->as) +expr->rank = CLASS_DATA (sym->result)->as->rank; + else if (sym->as != NULL) expr->rank = sym->as->rank; return MATCH_YES; ... the behavior of the two test cases is swapped: The second one is (correctly) rejected, while the first one ends up with the ICE.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #7 from Dick Guertin 2013-03-29 21:22:54 UTC --- Is there a replacement for Apple's linker that would run on Snow Leopard?
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #6 from Dick Guertin 2013-03-29 21:19:47 UTC --- (In reply to comment #5) > (In reply to comment #4) > > > > Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with > > Snow Leopard. It was failing. I replaced it by version 4.7 obtained from > > SourceForge, and it fails in EXACTLY the same way. > > Then the problem is unlikely to be GCC. I'm fairly sure Apple's modified GCC > 4.2 should work with their own OS and linker. Maybe the problem is with your > GDB version, which you haven't stated. > > > Therefore, the linker must be adding the "signatures" to the linked module, > > probably by reading the object decks AND the source files. But that only > > seems > > to be happening with g++ 4.0.1 and associated linker. The linker with > > versions > > 4.2 and higher must have revised linkers that DO NOT create the > > "signatures". > > GCC doesn't have an associated linker, it is using the Apple linker that comes > with the OS. First, my apology for not giving the gdp version. I assume you meant this: GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011) Next, let me point out that this gdb works correctly with source modules compiled and linked on Tiger with g++ 4.0.1 and Mac OS X 10.4.11. It also worked on Leopard, system 10.5. But it now fails with the same sources compiled and link with g++ 4.2 or higher on Mac OS X 10.6. Therefore, it must be the Apple linker because if I use "vi" to view a linked module, I find path information to sources in the OS 10.4 system, but paths to objects in the 10.6 system. If gdb reads the 10.4 linked module, it then reads the sources and constructs the symbol-table with signatures. But if gdb reads the 10.6 linked modules, all it finds are references to the objects, which do NOT carry the signature information. So, I'm forced to agree with you, Unfortunately, Apple says they won't "fix" it in Snow Leopard (10.6), which is where the linker resides. Bummer.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #5 from Jonathan Wakely 2013-03-29 20:56:29 UTC --- (In reply to comment #4) > > Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with > Snow Leopard. It was failing. I replaced it by version 4.7 obtained from > SourceForge, and it fails in EXACTLY the same way. Then the problem is unlikely to be GCC. I'm fairly sure Apple's modified GCC 4.2 should work with their own OS and linker. Maybe the problem is with your GDB version, which you haven't stated. > Therefore, the linker must be adding the "signatures" to the linked module, > probably by reading the object decks AND the source files. But that only > seems > to be happening with g++ 4.0.1 and associated linker. The linker with > versions > 4.2 and higher must have revised linkers that DO NOT create the "signatures". GCC doesn't have an associated linker, it is using the Apple linker that comes with the OS.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #4 from Dick Guertin 2013-03-29 20:04:45 UTC --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Are you sure that this is not a bug in Apple's part of the toolchain and > > > not > > > g++? > > > > I'm almost positive. But you need to define the term "toolchain" since that > > doesn't make sense to me. > > http://en.wikipedia.org/wiki/Toolchain > > > I know if I compile withthe -g option using the g++ > > version 4.0.1 on Tiger, and link the executable module, it can be debugged > > with > > gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 > > or > > Is 4.2 a typo or are you really saying this applies to old versions and not > just 4.7? > > > above on Snow Leopard, the linked module can NOT be debugged. I've used the > > "maint" command with gdb to get the symbol-tables output on both Tiger and > > Snow > > Leopard, the the object decks don't contain the same information. > > > > Sorry to say, my research shows that the "g++" compiler on Snow Leopard no > > longer places symbols in the linked module that have any meaning to "gdb". > > The > > only symbols found are the made-up symbols created to make ALL symbols > > unique. > > Here is a brief sample: > > > > `_Z5DoSVCi', function, 0x151dd > > `_Z7SEBTrapv', function, 0x1383c > > > > Those same symbols in Tiger were like this: > > > > `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c > > `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 > > > > The "signature" is what "gdb" needs to resolve things like: break > > emsvc.c:DoSVC > > Furthermore, you must still have all the "object decks", like emsvc.o, > > because > > Snow Leopard's "g++" apparently does not carry the symbols in the linked > > module > > anymore. > > If the symbols are in emsvc.o then the problem is probably not with g++, > because after it creates a .o file GCC doesn't do anything else, it just > invokes the linker, which is Apple's part of the toolchain. > > Also, what is your gdb version? Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with Snow Leopard. It was failing. I replaced it by version 4.7 obtained from SourceForge, and it fails in EXACTLY the same way. As for the symbols, only the artificially created symbols are in the object decks, like _Z5DoSVCi, but the "signatures" are in the linked module (emg) because that's where gdb gets them on Tiger (g++ 4.0.1). Tiger doesn't need the object decks to debug a linked module. With g++ 4.2 OR 4.7, the linked module does NOT have the signatures, and gdb tries to obtain them from the object decks, therefore you must RETAIN the ojbect decks. But that doesn't help because gdb can't constuct the signatures. So debugging fails in the sense that you can't reference user-known symbols. The artificial symbols are not known to the user unless they've created a text file with the "maint" command using gdb. That's why I know the signatures are NOT in the linked module, because gdb reads the linked module to create the text file. Therefore, the linker must be adding the "signatures" to the linked module, probably by reading the object decks AND the source files. But that only seems to be happening with g++ 4.0.1 and associated linker. The linker with versions 4.2 and higher must have revised linkers that DO NOT create the "signatures".
[Bug middle-end/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 --- Comment #5 from David Edelsohn 2013-03-29 19:53:44 UTC --- Segher pointed out that the transformed code example is has a bug. The first revised loop should test j+1 < NZ. for (j = 0; j+1 < NZ; j += 2){ fValue += Q[j] / r[j]; fValue1 += Q[j+1] / r[j+1]; }
[Bug middle-end/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 Steven Bosscher changed: What|Removed |Added Keywords||missed-optimization Status|NEW |ASSIGNED Component|tree-optimization |middle-end AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #4 from Steven Bosscher 2013-03-29 19:38:21 UTC --- Interesting idea, I'll have a look.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #3 from Jonathan Wakely 2013-03-29 19:27:03 UTC --- (In reply to comment #2) > (In reply to comment #1) > > Are you sure that this is not a bug in Apple's part of the toolchain and not > > g++? > > I'm almost positive. But you need to define the term "toolchain" since that > doesn't make sense to me. http://en.wikipedia.org/wiki/Toolchain > I know if I compile withthe -g option using the g++ > version 4.0.1 on Tiger, and link the executable module, it can be debugged > with > gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 or Is 4.2 a typo or are you really saying this applies to old versions and not just 4.7? > above on Snow Leopard, the linked module can NOT be debugged. I've used the > "maint" command with gdb to get the symbol-tables output on both Tiger and > Snow > Leopard, the the object decks don't contain the same information. > > Sorry to say, my research shows that the "g++" compiler on Snow Leopard no > longer places symbols in the linked module that have any meaning to "gdb". The > only symbols found are the made-up symbols created to make ALL symbols unique. > Here is a brief sample: > > `_Z5DoSVCi', function, 0x151dd > `_Z7SEBTrapv', function, 0x1383c > > Those same symbols in Tiger were like this: > > `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c > `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 > > The "signature" is what "gdb" needs to resolve things like: break > emsvc.c:DoSVC > Furthermore, you must still have all the "object decks", like emsvc.o, because > Snow Leopard's "g++" apparently does not carry the symbols in the linked > module > anymore. If the symbols are in emsvc.o then the problem is probably not with g++, because after it creates a .o file GCC doesn't do anything else, it just invokes the linker, which is Apple's part of the toolchain. Also, what is your gdb version?
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jason Merrill 2013-03-29 18:43:55 UTC --- (In reply to comment #7) > So it seems the macro expansion tracking is what's causing a lot of extra > memory usage here. OK, that makes sense, as the compiler is keeping more information around in order to give better diagnostic context with macros.
[Bug c++/56749] [4.8/4.9 Regression] weird interaction between scoped enum used as non-type template parameter and template lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56749 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Jason Merrill 2013-03-29 18:38:44 UTC --- Fixed for 4.8.1.
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug libitm/56784] New: bootstrap broken by libitm on x86_64-unknown-freebsd10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56784 Bug #: 56784 Summary: bootstrap broken by libitm on x86_64-unknown-freebsd10.0 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: ka...@gcc.gnu.org Updated 4.9.0 to top-of-tree % svn info gcc4x Path: gcc4x Working Copy Root Path: /usr/home/sgk/gcc/gcc4x URL: svn+ssh://ka...@gcc.gnu.org/svn/gcc/trunk Repository Root: svn+ssh://ka...@gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 197239 Node Kind: directory Schedule: normal Last Changed Author: paolo Last Changed Rev: 197237 Last Changed Date: 2013-03-29 06:41:14 -0700 (Fri, 29 Mar 2013) % cd obj % ../gcc4x/configure --prefix=$HOME/work/4x --enable-languages=c,fortran,c++ % gmake bootstrap libtool: compile: /home/sgk/gcc/obj4x/./gcc/xg++ -B/home/sgk/gcc/obj4x/./gcc/ -nostdinc++ -nostdinc++ -I/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/include/x86_64-unknown-freebsd10.0 -I/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/include -I/home/sgk/gcc/gcc4x/libstdc++-v3/libsupc++ -I/home/sgk/gcc/gcc4x/libstdc++-v3/include/backward -I/home/sgk/gcc/gcc4x/libstdc++-v3/testsuite/util -L/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/src -L/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/lib/ -isystem /home/sgk/work/4x/x86_64-unknown-freebsd10.0/include -isystem /home/sgk/work/4x/x86_64-unknown-freebsd10.0/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc4x/libitm -I../../../gcc4x/libitm/config/x86 -I../../../gcc4x/libitm/config/posix -I../../../gcc4x/libitm/config/generic -I../../../gcc4x/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c ../../../gcc4x/libitm/aatree.cc -fPIC -DPIC -o .libs/aatree.o In file included from ../../../gcc4x/libitm/libitm_i.h:40:0, from ../../../gcc4x/libitm/aatree.cc:28: ../../../gcc4x/libitm/local_atomic:1580:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_clear(volatile atomic_flag* __a) noexcept ^ ../../../gcc4x/libitm/local_atomic:1576:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_clear(atomic_flag* __a) noexcept ^ ../../../gcc4x/libitm/local_atomic:1572:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_test_and_set(volatile atomic_flag* __a) noexcept ^ ../../../gcc4x/libitm/local_atomic:1568:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_test_and_set(atomic_flag* __a) noexcept ^ ../../../gcc4x/libitm/local_atomic:1563:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_clear_explicit(volatile atomic_flag* __a, ^ ../../../gcc4x/libitm/local_atomic:1559:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_clear_explicit(atomic_flag* __a, memory_order __m) noexcept ^ ../../../gcc4x/libitm/local_atomic:1554:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_test_and_set_explicit(volatile atomic_flag* __a, ^ ../../../gcc4x/libitm/local_atomic:1549:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_flag_test_and_set_explicit(atomic_flag* __a, ^ ../../../gcc4x/libitm/local_atomic:95:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_signal_fence(memory_order __m) noexcept ^ ../../../gcc4x/libitm/local_atomic:89:3: error: always_inline function might not be inlinable [-Werror=attributes] atomic_thread_fence(memory_order __m) noexcept ./../../gcc4x/libitm/local_atomic:79:3: error: always_inline function might not be inlinable [-Werror=attributes] __calculate_memory_order(memory_order __m) noexcept ^ ../../../gcc4x/libitm/local_atomic: In function 'bool std::atomic_flag_test_and_set(std::atomic_flag*)': ../../../gcc4x/libitm/local_atomic:1549:3: error: inlining failed in call to always_inline 'bool std::atomic_flag_test_and_set_explicit(std::atomic_flag*, std::memory_order) noexcept (true)': function body can be overwritten at link time atomic_flag_test_and_set_explicit(atomic_flag* __a, ^ ../../../gcc4x/libitm/local_atomic:1569:71: error: called from here { return atomic_flag_test_and_set_explicit(__a, memory_order_seq_cst); } ^ ../../../gcc4x/
[Bug tree-optimization/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 --- Comment #3 from David Edelsohn 2013-03-29 18:11:54 UTC --- I tried -funroll-loops -fvariable-expansion-in-unroller. I did not see any additional benefit from -fvariable-expansion-in-unroller. Unrolling helped somewhat, the intermediate sum was computed in each loop iteration instead of sunk after the loop.
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Jason Merrill changed: What|Removed |Added CC||dodji at gcc dot gnu.org Depends on||53609 --- Comment #2 from Jason Merrill 2013-03-29 17:59:18 UTC --- This seems to be an issue with Dodji's patch for bug 53609; we aren't using PACK_EXPANSION_EXTRA_ARGS for the partial instantiation of the tuple constructor, but we should be.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #2 from Dick Guertin 2013-03-29 17:57:43 UTC --- (In reply to comment #1) > Are you sure that this is not a bug in Apple's part of the toolchain and not > g++? I'm almost positive. But you need to define the term "toolchain" since that doesn't make sense to me. I know if I compile withthe -g option using the g++ version 4.0.1 on Tiger, and link the executable module, it can be debugged with gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 or above on Snow Leopard, the linked module can NOT be debugged. I've used the "maint" command with gdb to get the symbol-tables output on both Tiger and Snow Leopard, the the object decks don't contain the same information. Sorry to say, my research shows that the "g++" compiler on Snow Leopard no longer places symbols in the linked module that have any meaning to "gdb". The only symbols found are the made-up symbols created to make ALL symbols unique. Here is a brief sample: `_Z5DoSVCi', function, 0x151dd `_Z7SEBTrapv', function, 0x1383c Those same symbols in Tiger were like this: `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 The "signature" is what "gdb" needs to resolve things like: break emsvc.c:DoSVC Furthermore, you must still have all the "object decks", like emsvc.o, because Snow Leopard's "g++" apparently does not carry the symbols in the linked module anymore.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 Andrew Pinski changed: What|Removed |Added Component|c++ |debug --- Comment #1 from Andrew Pinski 2013-03-29 17:21:30 UTC --- Are you sure that this is not a bug in Apple's part of the toolchain and not g++?
[Bug c++/56783] New: g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 Bug #: 56783 Summary: g++ does not supply signatures for gdb on g++ 4.7 versions Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dick.guer...@gmail.com Steps to reproduce: On Snow Leopard, compile c-programs with -g option using g++ to create a linked module for execution. Use gdb to read the module, and attempt to set breakpoints. No symbols are found. g++ no longer places the "signatures" in the linked module, or the object decks, so gdb can't find the signatures to satisfy something like: break emsvc.c:DoSVC ; However, the same source compiled with g++ and linked on Tiger, when copied to Snow Leopard, can set breakpoints. Actual results: dickguertin$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper Target: x86_64-apple-darwin11.4.0 Configured with: ../gcc-4.7.1/configure --enable-languages=fortran Thread model: posix gcc version 4.7.1 (GCC) dickguertin$ gdb -q emg 2>/dev/null Reading symbols for shared libraries . done (gdb) maint print psymbols emg.sym (gdb) break emsvc.c:DoSVC Function "DoSVC" not defined in file emsvc.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) quit dickguertin$ Expected results: In the command sequence shown above, the breakpoint should have been set. The "maint" command creates a symbol-table text-file (emg.sym), which shows that the signatures are no longer included in either the object decks or linked module (emg). Similar commands on Tiger produce symbol-tables with signatures, and breakpoints can be found (and set) by gdb on Tiger, and even the gdb on Snow Leopard.
[Bug sanitizer/56781] boostrap-asan failure: fixincl fails to link (missing -lasan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56781 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2013-03-29 16:20:46 UTC --- Please try http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=61be6ebfe22f9ce5799dac2679541911eb744a86 http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b526a34a0bc852461cb50636c6e757bf8e27faf
[Bug tree-optimization/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #2 from Joost VandeVondele 2013-03-29 15:55:38 UTC --- well actually related to PR25621, I think, and partially implemented via -fvariable-expansion-in-unroller -ffast-math would be nice to have this enabled (and well working) at -O3 or so.
[Bug tree-optimization/54200] copyrename generates wrong debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54200 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek 2013-03-29 15:36:15 UTC --- This patch regressed code quality on find_vma function in Linux kernel on s390x: struct rb_node { unsigned long __rb_parent_color; struct rb_node *rb_right; struct rb_node *rb_left; } __attribute__ ((aligned (sizeof (long; struct rb_root { struct rb_node *rb_node; }; struct vm_area_struct { unsigned long vm_start; unsigned long vm_end; struct vm_area_struct *vm_next, *vm_prev; struct rb_node vm_rb; }; struct mm_struct { struct vm_area_struct *mmap; struct rb_root mm_rb; struct vm_area_struct *mmap_cache; }; struct vm_area_struct * find_vma (struct mm_struct *mm, unsigned long addr) { struct vm_area_struct *vma = ((void *) 0); static _Bool __attribute__ ((__section__ (".data.unlikely"))) __warned; int __ret_warn_once = !!(!mm); if (__builtin_expect (!!(__ret_warn_once), 0)) { int __ret_warn_on = !!(!__warned); if (__builtin_expect (!!(__ret_warn_on), 0)) asm volatile ("": :"i" (1920), "i" (((1 << 0) | ((9) << 8))), "i" (64)); if (__builtin_expect (!!(__ret_warn_on), 0)) __warned = 1; } if (__builtin_expect (!!(__ret_warn_once), 0)) return ((void *) 0); vma = mm->mmap_cache; if (!(vma && vma->vm_end > addr && vma->vm_start <= addr)) { struct rb_node *rb_node; rb_node = mm->mm_rb.rb_node; vma = ((void *) 0); while (rb_node) { struct vm_area_struct *vma_tmp; const typeof (((struct vm_area_struct *)0)->vm_rb) *__mptr = rb_node; vma_tmp = (struct vm_area_struct *) ((char *) __mptr - __builtin_offsetof (struct vm_area_struct, vm_rb)); if (vma_tmp->vm_end > addr) { vma = vma_tmp; if (vma_tmp->vm_start <= addr) break; rb_node = rb_node->rb_left; } else rb_node = rb_node->rb_right; } if (vma) mm->mmap_cache = vma; } return vma; } with: -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -O2 -m64 -mbackchain -msoft-float -march=z9-109 -mpacked-stack -mstack-size=16384 -fno-strength-reduce -fno-stack-protector -fomit-frame-pointer -fno-inline-functions-called-once -fconserve-stack The difference in *.optimized is just: - # vma_5 = PHI <0B(18), vma_2(15), vma_20(6), vma_2(16), 0B(7)> - return vma_5; + # _5 = PHI <0B(18), vma_2(15), vma_20(6), vma_2(16), 0B(7)> + return _5; but later on CSE2 decides to use REG_EQUAL somewhere for some reason, and we end up reading mm->mmap_cache twice, first into a register to do the comparisons of it, and then when we know it is the value we actually want to return, we just forget we have it in a pseudo and read it again from memory.
[Bug tree-optimization/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 Ever Confirmed|0 |1 --- Comment #1 from David Edelsohn 2013-03-29 15:29:38 UTC --- Currently not implemented in GCC.
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 CC||jason at gcc dot gnu.org Summary|[C++11] Regression with |[4.8/4.9 Regression] |empty pack expansions |Regression with empty pack ||expansions Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2013-03-29 13:51:01 UTC --- Confirmed.
[Bug c++/56782] New: [C++11] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Bug #: 56782 Summary: [C++11] Regression with empty pack expansions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com As of gcc 4.8.0 the following code is now rejected when compiled with flags -std=c++11 -Wall -W -pedantic //--- template T&& declval(); struct is_convertible_impl { template static void sink(T); template(declval()))> static auto test(int) -> char; template static auto test(...) -> char(&)[2]; }; template struct is_convertible : is_convertible_impl { static const bool value = sizeof(test(0)) == 1; }; template struct enable_if {}; template struct enable_if { typedef T type; }; template struct conditional { typedef If type; }; template struct conditional { typedef Else type; }; template struct and_; template<> struct and_<> { static const bool value = true; }; template struct and_ : P { }; template struct and_ : conditional::type { }; template struct Tuple { template... >::value, int>::type > Tuple(U&&...){} }; static_assert(is_convertible, Tuple>::value, "Ouch"); // OK static_assert(is_convertible, Tuple<>>::value, "Ouch"); // Error //--- The diagnostics being: " Compilation finished with errors: source.cpp:18:48: error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) substituting 'template static char (& is_convertible_impl::test(...))[2] [with = Tuple<>; = Tuple<>]' static const bool value = sizeof(test(0)) == 1; ^ source.cpp:55:5: recursively required from 'const bool is_convertible, Tuple<> >::value' source.cpp:55:5: required from 'const bool is_convertible, Tuple<> >::value' source.cpp:64:49: required from here source.cpp:18:48: error: no matching function for call to 'is_convertible, Tuple<> >::test(int)' source.cpp:18:48: note: candidates are: source.cpp:9:15: note: template static char is_convertible_impl::test(int) static auto test(int) -> char; ^ source.cpp:9:15: note: template argument deduction/substitution failed: source.cpp:12:15: note: template static char (& is_convertible_impl::test(...))[2] static auto test(...) -> char(&)[2]; ^ source.cpp:12:15: note: substitution of deduced template arguments resulted in errors seen above source.cpp:64:1: error: non-constant condition for static assertion static_assert(is_convertible, Tuple<>>::value, "Ouch"); // Error ^ source.cpp:64:1: error: the value of 'is_convertible, Tuple<> >::value' is not usable in a constant expression source.cpp:18:21: note: 'is_convertible, Tuple<> >::value' was not initialized with a constant expression static const bool value = sizeof(test(0)) == 1; ^ " The code is accepted with gcc 4.7.2 and with Clang 3.2. It seems that for empty expansions the compiler erroneously does enter into the actually empty expansion: is_convertible...
[Bug lto/56777] bad grammar in fwhole-program documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56777 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.1 --- Comment #1 from Paolo Carlini 2013-03-29 13:41:54 UTC --- Fixed mainline and 4.8.1.
[Bug sanitizer/56781] New: boostrap-asan failure: fixincl fails to link (missing -lasan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56781 Bug #: 56781 Summary: boostrap-asan failure: fixincl fails to link (missing -lasan) Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: al...@gcc.gnu.org CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org bootstrap on x86_64-linux-gnu fails with: /scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc -B/scratch/obj.x86_64/gcc-4.9.mine/./gcc/ -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/bin/ -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/lib/ -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/include -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/sys-include-Og -g3 -ggdb3 -static-libstdc++ -static-libgcc -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a ../libiberty/libiberty.a(regex.o): In function `byte_compile_range': /scratch/obj.x86_64/gcc-4.9.mine/libiberty/../../../src/gcc-4.9.mine/libiberty/regex.c:4499: undefined reference to `__asan_report_store1' /scratch/obj.x86_64/gcc-4.9.mine/libiberty/../../../src/gcc-4.9.mine/libiberty/regex.c:4499: undefined reference to `__asan_report_load1' [snip] we would obviously need to link against asan but it is not immediately obvious to me how to pass POSTSTAGE1_LDFLAGS to fixincludes/ $ /scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc -B/scratch/obj.x86_64/gcc-4.9.mine/./gcc/ -B/scratch/obj.x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/libsanitizer/asan -B/scratch/obj.x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/bin/ -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/lib/ -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/include -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/sys-include-Og -g3 -ggdb3 -static-libstdc++ -static-libgcc -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a -fsanitize=address -static-libasan produces the desired fixincl $ /scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc -v Using built-in specs. COLLECT_GCC=/scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../../src/gcc-4.9.mine/configure -v --enable-languages=c,lto,fortran,c++,go LD=/usr/bin/ld.bfd CFLAGS='-O2 -g3 -ggdb3' CXXFLAGS='-O2 -g3 -ggdb3' 'BOOT_CFLAGS=-O2 -g3 -ggdb3' 'BOOT_CXXFLAGS=-O2 -g3 -ggdb3' 'CFLAGS_FOR_TARGET=-Og -g3 -ggdb3' 'CXXFLAGS_FOR_TARGET=-Og -g3 -ggdb3' --prefix=/opt/x86_64/gcc-4.9.mine// --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.9.mine-HEAD --with-build-config=bootstrap-asan --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=yes --enable-debug -C --disable-intermodule --enable-multilib --disable-libstdcxx-pch --enable-bootstrap --enable-checking=release --with-cpu=native --with-tune=native --enable-plugin Thread model: posix gcc version 4.9.0 20130327 (experimental) [vnhoist revision 32ddde1:a851c38:065ec6e627efa59b32f9fb743368a4a55c4ac310] (GCC)
[Bug other/56780] New: --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Bug #: 56780 Summary: --disable-install-libiberty still installs libiberty.a Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: matt...@linuxfromscratch.org I'd like to build GCC with --disable-install-libiberty so that the version of libiberty.a provided by Binutils that is already installed will not be overwritten. However, the libiberty.a library is still installed even with that flag specified. My full configure invocation (run from within ~/gcc-build) is: ../gcc-4.8.0-version;/configure --prefix=/usr \ --libexecdir=/usr/lib \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-clocale=gnu\ --enable-languages=c,c++\ --disable-multilib \ --disable-bootstrap \ --disable-install-libiberty \ --with-system-zlib Additionally, libiberty's configure script's help output states: ' --enable-install-libiberty Install headers for end users' For clarity, that should probably read: 'Install headers and static library for end users'. That way, it's in agreement with what is also mentioned in libiberty.texi. Thanks, Matt.
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #3 from Adam Borowski 2013-03-29 13:20:53 UTC --- Re-tested: * gcc-4.7.2 works on amd64, armhf, x32, fails on i386 * gcc-4.8.0 works on all of the above (all Debian) So it appears to be fixed in 4.8, at least on architectures I tried. Regardless of whether you'll fix it in 4.7 or not, it may be worth adding to the test suite.
[Bug other/28315] gcc doesn't use locale for default input charset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28315 Laszlo Ersek changed: What|Removed |Added CC||bonzini at gnu dot org, ||lacos at caesar dot elte.hu --- Comment #1 from Laszlo Ersek 2013-03-29 13:17:21 UTC --- gcc has defaulted to UTF-8 rather than the locale's codeset in _cpp_default_encoding() [libcpp/charset.c] since the following 2004 hunk: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d856c8a6#patch25 ( The default encoding is selected for both "input_charset" (overrideable with -finput-charset) and "narrow_charset" (overrideable with -fexec-charset): cpp_create_reader() [libcpp/init.c] ~ narrow_charset = _cpp_default_encoding() ~ input_charset = _cpp_default_encoding() The "overrides" are implemented in c_common_handle_option() [gcc/c-family/c-opts.c]. ) Considering the encodings of source files "in the wild" that gcc has been used to compile in the last 8+ years (ie. while the "&& 0" has been in place): - UTF-8 (of which 7-bit ASCII is a subset) worked. - Any non-UTF-8 encoding that utilized the MSB (eg. ISO-8859-2) required the -finput-charset option. People who would have originally wanted gcc to take that codeset from the locale were probably *developing* the source code in question, hence they could easily add the -finput-charset to their makefiles. Much of the world must have migrated to UTF-8-encoded locales by now. Reverting the "&& 0" would: - not affect people with such a distro-default locale who build UTF-8 / ASCII sources: their locale codeset matches the current hardwired default, - not affect people building sources with non-UTF-8 8-bit codesets (eg. ISO-8859-2), since those projects already have to use the -finput-charset options in their makefiles, - affect people who have stuck to their 7-bit ASCII, or non-UTF-8 8-bit codesets in their locales, and compile real UTF-8 sources. People in the last group (which includes me :)) would be forced to (a) modify their locale when building such sources as end-users, or (b) to find out about -finput-charset=UTF-8 and pass it via (b1) Makefile hacking or (b2) ./configure settings (env vars, or command line options). I think that's unreasonable; building random projects from the tubes would break for this small but existent group of users. Therefore I suggest to keep the logic as-is, and update the docs instead ("gcc/doc/cppopts.texi"): "-finput-charset" should not refer to the locale.
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #2 from Adam Borowski 2013-03-29 13:13:21 UTC --- Created attachment 29750 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29750 updated testcase Updated testcase: it checks for invalid pointers (by freeing them), and returns an exit code (if it won't crash first).
[Bug libstdc++/56779] New: libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 Bug #: 56779 Summary: libstdc++.so: undefined reference to `libintl_textdomain' Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tre...@sourcemage.org Created attachment 29749 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29749 full compile log for gcc-4.8.0 libstdc++.so has references to libintl_textdomain, but intl is not listed as a needed library $ readelf -d /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so |grep NEEDED 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] $ readelf -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so |grep libintl 252: 0 NOTYPE GLOBAL DEFAULT UND libintl_gettext 1825: 0 NOTYPE GLOBAL DEFAULT UND libintl_textdomain 2592: 0 NOTYPE GLOBAL DEFAULT UND libintl_bindtextdomain 961: 0 NOTYPE GLOBAL DEFAULT UND libintl_gettext 2534: 0 NOTYPE GLOBAL DEFAULT UND libintl_textdomain 3301: 0 NOTYPE GLOBAL DEFAULT UND libintl_bindtextdomain This causes major problems when trying to link a C++ program eg: g++ -march=native -mtune=native -m64 -pipe -ffast-math -funroll-loops -O3 -s -Wl,--as-needed -lpthread -lintl -pthread -Wl,-rpath,'$ORIGIN/../lib' -Wl,-rpath,'$ORIGIN/../intl' -Wl,--version-script,empty.vers /var/git/x86_64/firebird3/temp/Release/gpre/hsh.o /var/git/x86_64/firebird3/temp/Release/gpre/jrdmet.o /var/git/x86_64/firebird3/temp/Release/gpre/cme.o /var/git/x86_64/firebird3/temp/Release/gpre/par.o /var/git/x86_64/firebird3/temp/Release/gpre/sqe.o /var/git/x86_64/firebird3/temp/Release/gpre/msc.o /var/git/x86_64/firebird3/temp/Release/gpre/c_cxx.o /var/git/x86_64/firebird3/temp/Release/gpre/exp.o /var/git/x86_64/firebird3/temp/Release/gpre/movg.o /var/git/x86_64/firebird3/temp/Release/gpre/pat.o /var/git/x86_64/firebird3/temp/Release/gpre/cmp.o /var/git/x86_64/firebird3/temp/Release/gpre/gpre.o /var/git/x86_64/firebird3/temp/Release/gpre/sql.o /var/git/x86_64/firebird3/temp/Release/gpre/int_cxx.o /var/git/x86_64/firebird3/temp/Release/gpre/cmd.o /var/git/x86_64/firebird3/temp/Release/gpre/boot/gpre_meta_boot.o /var/git/x86_64/firebird3/temp/Release/yvalve/gds.o /var/git/x86_64/firebird3/temp/Release/common.a -o /var/git/x86_64/firebird3/gen/Release/firebird/bin/gpre_boot -L/var/git/x86_64/firebird3/gen/Release/firebird/lib -lpthread -latomic_ops -lm -ldl -lcurses /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so: undefined reference to `libintl_gettext' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so: undefined reference to `libintl_textdomain' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so: undefined reference to `libintl_bindtextdomain' collect2: error: ld returned 1 exit status gettext In some cases this can be solved by setting LDFLAGS="-lintl", but in other cases the makefiles ignore this setting and fail. gcc was configure with --disable-nls, but gettext-0.18.2 was on the system,and installed /usr/lib/libasprintf.a /usr/lib/libasprintf.la /usr/lib/libasprintf.so /usr/lib/libasprintf.so.0 /usr/lib/libasprintf.so.0.0.0 /usr/lib/libgettextlib-0.18.2.so /usr/lib/libgettextlib.la /usr/lib/libgettextlib.so /usr/lib/libgettextpo.a /usr/lib/libgettextpo.la /usr/lib/libgettextpo.so /usr/lib/libgettextpo.so.0 /usr/lib/libgettextpo.so.0.5.2 /usr/lib/libgettextsrc-0.18.2.so /usr/lib/libgettextsrc.la /usr/lib/libgettextsrc.so /usr/lib/libintl.a /usr/lib/libintl.la /usr/lib/libintl.so /usr/lib/libintl.so.8 /usr/lib/libintl.so.8.1.2 The output from configure includes the following: checking whether NLS is requested... no checking build system type... checking for msgfmt... x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-gcc... gcc x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... /usr/bin/msgfmt checking for gmsgfmt... x86_64-pc-linux-gnu checking target system type... /usr/bin/msgfmt checking for xgettext... x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-ar... ar checking for x86_64-pc-linux-gnu-ranlib... ranlib checking for x86_64-pc-linux-gnu-gcc... gcc x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-gcc... gcc checking for a BSD-compatible install... /bin/install -c checking whether build en
[Bug tree-optimization/56778] New: ICE on several benchmarks after r196775.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56778 Bug #: 56778 Summary: ICE on several benchmarks after r196775. Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ysrum...@gmail.com We got ICE on several benchmarks that can be reproduced on the simple test-case: typedef struct { float a,b,c; } S; S * arr[100]; void bar (float *in[], int n) { int i; for (i=0; ib; } and compile on x86 with following options: -march=core-avx2 -O3
[Bug lto/56777] New: bad grammar in fwhole-program documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56777 Bug #: 56777 Summary: bad grammar in fwhole-program documentation Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jtaylor.deb...@gmail.com http://gcc.gnu.org/onlinedocs//gcc/Optimize-Options.html#Optimize-Options -fwhole-program ... In combination with -flto using this option should not be used. it should probably be : In combination with -flto this option should not be used. or This option should not be used in combination with -flto.
[Bug debug/35118] ICE in mem_loc_descriptor, at dwarf2out.c:8974
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35118 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #3 from Joost VandeVondele 2013-03-29 11:09:49 UTC --- testcase doesn't compile with trunk anymore. I suspect the original problem is fixed. If not, please provide an updated testcase.
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2006-04-23 17:57:20 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch Blocks||51119 Summary|missing transformations |graphite with loop blocking |lead to poorly optimized|and interchanging doesn't |code|optimize a matrix ||multiplication loop Known to fail|tree-ssa|4.9.0 --- Comment #17 from Joost VandeVondele 2013-03-29 11:03:40 UTC --- With 4.9 trunk using gfortran -ffast-math -O3 -march=native -fgraphite -floop-interchange -floop-block PR14741.f90 The testcase still runs about 8x slower than what ifort produces at -O3 -xHost. This is too bad, and in my opinion blocks as simple solution for PR51119
[Bug tree-optimization/40168] missing unrolling/scalarization/reassoc/free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2009-12-18 14:45:13 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #21 from Joost VandeVondele 2013-03-29 10:50:49 UTC --- So, the testcase in comment #14 is indeed still (4.9.0) yielding the 324 multiplies for subroutine S2, instead of the more optimal 192 as shown in S1. Ifort also results in 324 multiplies, but is able to do a couple of them with mulpd instead of mulsd. So the common subexpressions are still not found.
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Joost VandeVondele changed: What|Removed |Added Blocks||39304 CC||Huub.van-Dam at stfc dot ||ac.uk --- Comment #23 from Joost VandeVondele 2013-03-29 10:31:19 UTC --- *** Bug 39304 has been marked as a duplicate of this bug. ***
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304 Joost VandeVondele changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Depends on||34640 Resolution||DUPLICATE Known to fail||4.9.0 --- Comment #14 from Joost VandeVondele 2013-03-29 10:31:19 UTC --- This is fails with 4.9.0, but I think it has become a pure dup of PR34640 *** This bug has been marked as a duplicate of bug 34640 ***
[Bug fortran/36933] unneeded temporary with derived type containing an array as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933 Joost VandeVondele changed: What|Removed |Added Status|NEW |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #10 from Joost VandeVondele 2013-03-29 10:20:31 UTC --- The original problem is fixed. The problem in comment #3 seems not worth fixing, and would require alias analysis in the FE.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #7 from Joost VandeVondele 2013-03-29 10:17:20 UTC --- see part 2/3 in the message here: http://gcc.gnu.org/ml/fortran/2013-03/msg00125.html
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch Depends on||53947 --- Comment #12 from Joost VandeVondele 2013-03-29 10:07:06 UTC --- This has become much more a vectorizer problem. Basically ifort generates code that is twice as fast for routine S31 of the initial comment. Given that this is a common dot product, it might be good to see why that happens. Both compilers fail to notice that S32 is basically the same code hand-unrolled. Tested with the code in comment #6 (without inlining) > gfortran -march=native -ffast-math -O3 -fno-inline PR25621.f90 > ./a.out default loop 0.564915006 hand optimized loop 0.744886016 > ifort -xHost -O3 -fno-inline PR25621.f90 > ./a.out default loop 0.3779430 hand optimized loop 0.5799110
[Bug bootstrap/56752] GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when 32-bit libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 --- Comment #5 from David Starner 2013-03-29 10:00:04 UTC --- You could check that right after building the multilib compiler before trying to compile real code. That would at least give an error message that said what was wrong, instead of one that's opaque to the causal installer.
[Bug fortran/41137] inefficient zeroing of an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2009-11-01 16:21:21 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch Blocks||38654 --- Comment #14 from Joost VandeVondele 2013-03-29 09:46:53 UTC --- The code in comment #0 is actually a frontend optimization, PR38654. Noteworthy that the optimizers (ipa-cp plus others) do the right thing for the tester in comment #1 at -O3 (but can't do this in the general case).
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 --- Comment #6 from Tobias Burnus 2013-03-29 09:40:13 UTC --- Author: burnus Date: Fri Mar 29 09:39:47 2013 New Revision: 197230 URL: http://gcc.gnu.org/viewcvs?rev=197230&root=gcc&view=rev Log: 2012-03-29 Tobias Burnus PR fortran/56737 * io/format.c (parse_format_list): Also cache FMT_STRING. (parse_format): Update call. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 --- Comment #5 from Tobias Burnus 2013-03-29 09:38:20 UTC --- Author: burnus Date: Fri Mar 29 09:37:37 2013 New Revision: 197229 URL: http://gcc.gnu.org/viewcvs?rev=197229&root=gcc&view=rev Log: 2013-03-29 Tobias Burnus PR fortran/56737 * io/format.c (parse_format): With caching, copy dtp->format string. (save_parsed_format): Use dtp->format directly without copying. 2013-03-29 Tobias Burnus PR fortran/56737 * testsuite/gfortran.dg/fmt_cache_3.f90: New. (Plus: Move fortran/ChangeLog item to libgfortran/ChangeLog) Added: trunk/gcc/testsuite/gfortran.dg/fmt_cache_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #7 from Tobias Burnus 2013-03-29 09:34:29 UTC --- Author: burnus Date: Fri Mar 29 09:32:57 2013 New Revision: 197228 URL: http://gcc.gnu.org/viewcvs?rev=197228&root=gcc&view=rev Log: 2013-03-29 Tobias Burnus PR fortran/56735 * io/list_read.c (nml_query): Only abort when an error occured. (namelist_read): Add goto instead of falling through. 2013-03-29 Tobias Burnus PR fortran/56735 * gfortran.dg/namelist_80.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_80.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/libgfortran/io/list_read.c
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2010-08-19 09:47:08 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #12 from Joost VandeVondele 2013-03-29 09:27:23 UTC --- comment #11 still fails on 4.9 trunk.
[Bug rtl-optimization/56776] [4.8/4.9 Regression] valgrind errors within ira
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch Known to work||4.7.3 Summary|valgrind errors within ira |[4.8/4.9 Regression] ||valgrind errors within ira Known to fail||4.8.1, 4.9.0 --- Comment #1 from Joost VandeVondele 2013-03-29 09:23:00 UTC --- seems absent in 4.7
[Bug rtl-optimization/56776] New: valgrind errors within ira
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776 Bug #: 56776 Summary: valgrind errors within ira Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch The famously short Fortran program: > cat test.f90 END yields errors in ira: valgrind --tool=memcheck --trace-children=yes gfortran -c test.f90 ==7625== Conditional jump or move depends on uninitialised value(s) ==7625==at 0x882AF7: make_object_born(ira_object*) (sparseset.h:147) ==7625==by 0x882C3A: mark_pseudo_regno_live(int) (ira-lives.c:294) ==7625==by 0x883C34: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1321) ==7625==by 0x86D4A8: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1604) ==7625==by 0x884811: ira_create_allocno_live_ranges() (ira-lives.c:1595) ==7625==by 0x86DD84: ira_build() (ira-build.c:3198) ==7625==by 0x866792: rest_of_handle_ira() (ira.c:4473) ==7625==by 0x8F0626: execute_one_pass(opt_pass*) (passes.c:2330) ==7625==by 0x8F0A54: execute_pass_list(opt_pass*) (passes.c:2378) ==7625==by 0x8F0A66: execute_pass_list(opt_pass*) (passes.c:2379) ==7625==by 0x6C2637: expand_function(cgraph_node*) (cgraphunit.c:1640) ==7625==by 0x6C4749: compile() (cgraphunit.c:1833) ==7625== ==7625== Use of uninitialised value of size 8 ==7625==at 0x882C22: mark_pseudo_regno_live(int) (sparseset.h:147) ==7625==by 0x883C34: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1321) ==7625==by 0x86D4A8: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1604) ==7625==by 0x884811: ira_create_allocno_live_ranges() (ira-lives.c:1595) ==7625==by 0x86DD84: ira_build() (ira-build.c:3198) ==7625==by 0x866792: rest_of_handle_ira() (ira.c:4473) ==7625==by 0x8F0626: execute_one_pass(opt_pass*) (passes.c:2330) ==7625==by 0x8F0A54: execute_pass_list(opt_pass*) (passes.c:2378) ==7625==by 0x8F0A66: execute_pass_list(opt_pass*) (passes.c:2379) ==7625==by 0x6C2637: expand_function(cgraph_node*) (cgraphunit.c:1640) ==7625==by 0x6C4749: compile() (cgraphunit.c:1833) ==7625==by 0x6C4A74: finalize_compilation_unit() (cgraphunit.c:2119)
[Bug lto/47532] valgrind errors while compiling with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47532 Joost VandeVondele changed: What|Removed |Added Status|NEW |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #2 from Joost VandeVondele 2013-03-29 09:13:28 UTC --- seems fixed.
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362 --- Comment #15 from Joost VandeVondele 2013-03-29 09:11:10 UTC --- *** Bug 50175 has been marked as a duplicate of this bug. ***
[Bug libgomp/50175] data race with OMP barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||DUPLICATE --- Comment #2 from Joost VandeVondele 2013-03-29 09:11:10 UTC --- This is at best a dup of PR40362, and likely fixed for the linux futex version as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c38 *** This bug has been marked as a duplicate of bug 40362 ***
[Bug middle-end/40194] fortran rules for optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #11 from Joost VandeVondele 2013-03-29 09:07:25 UTC --- Fixed.
[Bug middle-end/41453] use INTENT(out) for optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2012-06-29 00:00:00 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #2 from Joost VandeVondele 2013-03-29 09:04:29 UTC --- and 4.9.0
[Bug tree-optimization/34940] contained subroutines called only once are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2012-06-29 11:27:01 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch Known to fail||4.9.0 --- Comment #16 from Joost VandeVondele 2013-03-29 08:58:42 UTC --- (In reply to comment #6) > Function is static, that seems OK. > We inline it with ./xgcc -B ./ -O2 t.f90 -S --param large-stack-frame=2000 > > We are somewhat stupid here, since the call happens all the time and thus > stack > frame growth limits don't need to apply. I can implement this if this is > common case for fortran. How commonly we run into these io structs? > We can also bump large stack limits to make fortran I/O to fit in. > > Honza I think it would make sense to implement this, if easy enough. It could be a common pattern for contained subroutines and private module procedures
[Bug libfortran/51119] MATMUL slow for large matrices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2011-11-14 00:00:00 |2013-03-29 --- Comment #10 from Joost VandeVondele 2013-03-29 08:47:39 UTC --- What about compiling the fortran runtime library with vectorization, and all the fancy options that come with graphite (loop-blocking in particular). If they don't work for a matrix multiplication pattern what's their use ? Further naivety would be to provide an lto'ed runtime, allowing matrix multiplication to be inlined for known small bounds ... kind of the ultimate dogfooding ?
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2009-04-06 10:57:29 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #22 from Joost VandeVondele 2013-03-29 08:40:06 UTC --- Still affects trunk 4.9.0 values => d(:)%value ^ 0x99687f crash_signal ../../gcc/gcc/toplev.c:332 0x610d2b gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/gcc/fortran/trans-expr.c:6337 0x5e0d4a trans_code ../../gcc/gcc/fortran/trans.c:1439 0x6083bd gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5392 0x5e19c1 gfc_generate_module_code(gfc_namespace*) ../../gcc/gcc/fortran/trans.c:1755 0x59efc8 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4453 0x59efc8 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4663 0x5dc355 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:189 Please submit a full bug report,
[Bug target/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #6 from Marc Girod 2013-03-29 08:39:38 UTC --- I can acknowledge that installing binutils 2.23.2 solved my problem with gcc 4.7.2
[Bug fortran/25708] [F95] Module loading is not good at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #22 from Joost VandeVondele 2013-03-29 08:33:31 UTC --- Improved in part by http://gcc.gnu.org/ml/fortran/2013-03/msg00143.html as r197124 for 4.9.0
[Bug middle-end/47341] unnecessary versioning in the vectorizer, not implemented affine-affine test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47341 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2012-06-30 11:21:06 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #5 from Joost VandeVondele 2013-03-29 08:29:53 UTC --- still versioning for trunk 4.9.0
[Bug fortran/56378] [4.6/4.7/4.8 Regression] ICE with C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378 Joost VandeVondele changed: What|Removed |Added Summary|[4.6/4.7/4.8/4.9|[4.6/4.7/4.8 Regression] |Regression] ICE with C_LOC |ICE with C_LOC --- Comment #10 from Joost VandeVondele 2013-03-29 08:23:59 UTC --- Fixed on trunk (4.9.0): PR56378.f90:13.23: call lat_to_c2 (c_loc(fvec2vec(ic, n1_ic))) 1 Error: Argument X at (1) to C_LOC shall have either the POINTER or the TARGET attribute
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021 Joost VandeVondele changed: What|Removed |Added Depends on||37150 --- Comment #16 from Joost VandeVondele 2013-03-29 08:15:30 UTC --- I believe this is actually testing the same kernel (maybe a slightly older variant) as in PR37150. I would rather revisit this once PR37150 has been fixed.
[Bug web/56063] [bugzilla] last reconfirmed : now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063 --- Comment #9 from Joost VandeVondele 2013-03-29 08:12:23 UTC --- (In reply to comment #7) > What I could do is to hide the calendar button and add a "Now" link instead. I think this would be really appreciated.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Joost VandeVondele changed: What|Removed |Added Summary|TSAN: Fortran/OMP yields|TSAN: provide a TSAN |false positives |instrumented libgomp --- Comment #40 from Joost VandeVondele 2013-03-29 08:11:17 UTC --- I'm updating the summary for this bug. It is my impression that tsan & omp now work well together, but in order for this to be useful, a tsan instrumented libgomp needs to be linked in. In my opinion, it would be great if gcc would build to versions of the runtime library (one standard, one tsan instrumented) and link the tsan instrumented libgomp as needed. As a side effect, it will provide good checking for the libgomp library. I also believe this is a more sustainable approach than writing wrappers for all omp functionality.