[Bug middle-end/48493] [4.6/4.7 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #14 from Mikael Pettersson 2012-05-31 07:08:35 UTC --- (In reply to comment #11) > Can somebody test ... > on arm? Testing 4.7 + proposed fix on armv5tel-linux-gnueabi right now, expect results in about 30 hours.
[Bug java/53527] 4.7.0 release can't enable java language
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53527 licheng.1...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from licheng.1212 at gmail dot com 2012-05-31 07:37:29 UTC --- (In reply to comment #2) > (In reply to comment #1) > > mips-unknown-elf is not a hosted platform and thus does not support Java. > > But why the GCC 4.4.2 is OK,and I want to build a corss compiler that support > java for embedded system. sorry,you are right, I had been add a java patch for 4.4.2 gcc,I forgat it Thanks for your reply!!
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Memory leak with zero-sized array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED Summary|[4.5/4.6/4.7/4.8|[4.5/4.6/4.7/4.8 |Regression] Zero-byte |Regression] Memory leak |"memory leak" with |with zero-sized array |zero-sized array|constructor |constructor (valgrind | |warning)| --- Comment #7 from Tobias Burnus 2012-05-31 08:12:09 UTC --- (In reply to comment #6) > needs 25Gb of memory after a while (notice the endless loop around CALL T2). I had tried it with a finite loop and valgrind, but the latter then only showed: ==32236==definitely lost: 0 bytes in 10,000 blocks However, I could reproduce it, when looking at the memory consumption in "top". (In reply to comment #5) > That is clearly a bug in the Fortran FE. > D.1888 = __builtin_realloc (atmp.0.data, D.1887); ... > if (D.1887 == 0) > D.1888 = 0B; > means that D.1888 isn't freed. Well spotted! I got distracted by the valgrind result of 0 bytes - and by the later FREE check, which should be okay. The problem is in gcc/fortran/trans.c's gfc_call_realloc.
[Bug c++/33661] template methods forget explicit local reg vars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661 --- Comment #10 from Aleksandrs Saveljevs 2012-05-31 08:16:41 UTC --- Confirming that the bug still exists on ARM, x86 and x86_64 as of GCC 4.6.3.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Memory leak with zero-sized array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #8 from Jakub Jelinek 2012-05-31 08:19:34 UTC --- (In reply to comment #7) > (In reply to comment #5) > > That is clearly a bug in the Fortran FE. > > D.1888 = __builtin_realloc (atmp.0.data, D.1887); > ... > > if (D.1887 == 0) > > D.1888 = 0B; > > means that D.1888 isn't freed. > > Well spotted! I got distracted by the valgrind result of 0 bytes - and by the > later FREE check, which should be okay. > > The problem is in gcc/fortran/trans.c's gfc_call_realloc. I guess passing MAX (D.1887, 1) as second argument to realloc above and omitting that if (D.1887 == 0) D.1888 = 0B; stmt would be easiest and hopefully not much slower (both sequences have one conditional). Because, I believe you still have free at the end anyway.
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #23 from rguenther at suse dot de 2012-05-31 08:41:00 UTC --- On Wed, 30 May 2012, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 > > --- Comment #22 from Eric Botcazou 2012-05-30 > 15:28:14 UTC --- > > Bootstrapped on x86_64-unknown-linux-gnu. > > This also needs to be tested on 32-bit and strict-alignment platforms. I'll test it on i?85-linux as well. I don't have access to a strict-alignment platform - but the patch is essentially the same as on trunk. Can you give it a shot on sparc or do you forsee any issues and thus would rather not backport this kind of change? The idea was that 4.7.1 would still be ok but later this kind of change is obviously too intrusive. Thanks, Richard.
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-31 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-05-31 09:21:09 UTC --- Please do not use any of the Graphite optimization flags. Can you produce a simple testcase please?
[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53093 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Hans-Peter Nilsson 2012-05-31 09:59:17 UTC --- fixed
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #24 from Eric Botcazou 2012-05-31 10:36:10 UTC --- > I'll test it on i?85-linux as well. I don't have access to a > strict-alignment platform - but the patch is essentially the same > as on trunk. Can you give it a shot on sparc or do you forsee any > issues and thus would rather not backport this kind of change? The > idea was that 4.7.1 would still be ok but later this kind of change > is obviously too intrusive. Yes, I think it's appropriate for 4.7.1 if all the follow-ups are backported as well. I'll give it a whirl on SPARC.
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #24 from Eric Botcazou 2012-05-31 10:36:10 UTC --- > I'll test it on i?85-linux as well. I don't have access to a > strict-alignment platform - but the patch is essentially the same > as on trunk. Can you give it a shot on sparc or do you forsee any > issues and thus would rather not backport this kind of change? The > idea was that 4.7.1 would still be ok but later this kind of change > is obviously too intrusive. Yes, I think it's appropriate for 4.7.1 if all the follow-ups are backported as well. I'll give it a whirl on SPARC. --- Comment #25 from rguenther at suse dot de 2012-05-31 10:38:23 UTC --- On Thu, 31 May 2012, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 > > --- Comment #24 from Eric Botcazou 2012-05-31 > 10:36:10 UTC --- > > I'll test it on i?85-linux as well. I don't have access to a > > strict-alignment platform - but the patch is essentially the same > > as on trunk. Can you give it a shot on sparc or do you forsee any > > issues and thus would rather not backport this kind of change? The > > idea was that 4.7.1 would still be ok but later this kind of change > > is obviously too intrusive. > > Yes, I think it's appropriate for 4.7.1 if all the follow-ups are backported > as > well. I'll give it a whirl on SPARC. I think I have included them all in the patch I attached. Meanwhile multilib testing has finished on x86_64, a pure i?86 bootstrap still pending (I'm also testing on arm and ppc/ppc64 now, but that may take a while)
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #26 from Jakub Jelinek 2012-05-31 10:42:10 UTC --- (In reply to comment #25) > On Thu, 31 May 2012, ebotcazou at gcc dot gnu.org wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 > > > > --- Comment #24 from Eric Botcazou > > 2012-05-31 10:36:10 UTC --- > > > I'll test it on i?85-linux as well. I don't have access to a > > > strict-alignment platform - but the patch is essentially the same > > > as on trunk. Can you give it a shot on sparc or do you forsee any > > > issues and thus would rather not backport this kind of change? The > > > idea was that 4.7.1 would still be ok but later this kind of change > > > is obviously too intrusive. > > > > Yes, I think it's appropriate for 4.7.1 if all the follow-ups are > > backported as > > well. I'll give it a whirl on SPARC. > > I think I have included them all in the patch I attached. Meanwhile > multilib testing has finished on x86_64, a pure i?86 bootstrap still > pending (I'm also testing on arm and ppc/ppc64 now, but that may > take a while) http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186819 is kind of a follow-up too.
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #27 from rguenther at suse dot de 2012-05-31 10:48:19 UTC --- On Thu, 31 May 2012, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 > > --- Comment #26 from Jakub Jelinek 2012-05-31 > 10:42:10 UTC --- > (In reply to comment #25) > > On Thu, 31 May 2012, ebotcazou at gcc dot gnu.org wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 > > > > > > --- Comment #24 from Eric Botcazou > > > 2012-05-31 10:36:10 UTC --- > > > > I'll test it on i?85-linux as well. I don't have access to a > > > > strict-alignment platform - but the patch is essentially the same > > > > as on trunk. Can you give it a shot on sparc or do you forsee any > > > > issues and thus would rather not backport this kind of change? The > > > > idea was that 4.7.1 would still be ok but later this kind of change > > > > is obviously too intrusive. > > > > > > Yes, I think it's appropriate for 4.7.1 if all the follow-ups are > > > backported as > > > well. I'll give it a whirl on SPARC. > > > > I think I have included them all in the patch I attached. Meanwhile > > multilib testing has finished on x86_64, a pure i?86 bootstrap still > > pending (I'm also testing on arm and ppc/ppc64 now, but that may > > take a while) > > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186819 > is kind of a follow-up too. Yes, that's what motivated me to look again at a possible backport of the DECL_BIT_FIELD_REPRESENTATIVE patch. I'd backport that separately though.
[Bug fortran/53537] New: Abstract interface with import interferes with only-clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537 Bug #: 53537 Summary: Abstract interface with import interferes with only-clause Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl The program below gives errors on the use of the parameter wp. If the interface is not present, the program gets compiled. It is probably possible to reduce it even further, but the error disappears when the "only: wp => dp" clause is commented out. module select_precision implicit none integer, parameter :: sp = kind( 1.0 ) integer, parameter :: dp = kind( 1.0d0 ) integer, parameter :: wp = sp end module select_precision module ode_types use select_precision, only: wp => dp implicit none private public :: wp type, abstract, public :: ode_system_t real(wp), dimension(:), allocatable :: x, x1, x2, x3, x4 real(wp):: time, deltt integer :: size = 0 end type ode_system_t interface function ode_derivative( this, x, time ) result(deriv) import :: ode_system_t, wp class(ode_system_t):: this real(wp), dimension(:) :: x real(wp) :: time real(wp), dimension(size(x)) :: deriv end function ode_derivative end interface end module ode_types
[Bug middle-end/48493] [4.6/4.7 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #15 from Richard Guenther 2012-05-31 11:02:32 UTC --- Author: rguenth Date: Thu May 31 11:02:29 2012 New Revision: 188056 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188056 Log: 2012-05-31 Richard Guenther PR middle-end/48493 * expr.c (expand_assignment): Do not use movmisalign on non-memory. * gcc.dg/torture/pr48493.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48493.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/expr.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/48493] [4.6/4.7 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #16 from Richard Guenther 2012-05-31 11:06:39 UTC --- Author: rguenth Date: Thu May 31 11:06:35 2012 New Revision: 188058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188058 Log: 2012-05-31 Richard Guenther PR middle-end/48493 * gcc.dg/torture/pr48493.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48493.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48493] [4.6 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 Richard Guenther changed: What|Removed |Added Known to work||4.7.1 Summary|[4.6/4.7 Regression] ice in |[4.6 Regression] ice in |expand_expr_addr_expr_1 |expand_expr_addr_expr_1 |with complex types and |with complex types and |mem_ref |mem_ref --- Comment #16 from Richard Guenther 2012-05-31 11:06:39 UTC --- Author: rguenth Date: Thu May 31 11:06:35 2012 New Revision: 188058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188058 Log: 2012-05-31 Richard Guenther PR middle-end/48493 * gcc.dg/torture/pr48493.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48493.c Modified: trunk/gcc/testsuite/ChangeLog --- Comment #17 from Richard Guenther 2012-05-31 11:07:27 UTC --- Thanks andrew for testing. Fixed on the 4.7 branch as well.
[Bug middle-end/48493] [4.6 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 Richard Guenther changed: What|Removed |Added Known to work||4.7.1 Summary|[4.6/4.7 Regression] ice in |[4.6 Regression] ice in |expand_expr_addr_expr_1 |expand_expr_addr_expr_1 |with complex types and |with complex types and |mem_ref |mem_ref --- Comment #17 from Richard Guenther 2012-05-31 11:07:27 UTC --- Thanks andrew for testing. Fixed on the 4.7 branch as well.
[Bug c/53538] New: Compile error with ARM NEON intrinsics and certain compile flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53538 Bug #: 53538 Summary: Compile error with ARM NEON intrinsics and certain compile flags Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ah...@gmx.net Created attachment 27529 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27529 test program The attached test program fails to compile with the following command line (cross compiling for ARM neon on Ubuntu): gcc -c test_an_bug.c -o test_an_bug.o -O2 -g -Wall -march=armv7-a -mlittle-endian -mfloat-abi=hard -mfpu=neon -mtp=cp15 -mthumb Error message: In file included from test_an_bug.c:2:0: [...]/4.5/include/arm_neon.h: In function 'main': [...]/4.5/include/arm_neon.h:4968:49: error: argument must be a constant [...]/4.5/include/arm_neon.h:4968: confused by earlier errors, bailing out However it builds without warning when either: 1) use -O3 instead of -O2 or 2) use -funroll-loops 3) if you move the intrinsic (vget_lane_u16) outside the for loop 4) if you use literals instead of the variable j I haven't found any detailed documentation on the use of this intrinsic, but it looks a bit odd if it only accepts literals as parameters. At what point did we give up pass-by-value for int? And it certainly is odd that it compiles fine with different optimization levels... Note 1: This is not the original code, it is the minimum test program I derived from it. Note 2: It seems to fail on all compiler versions from 4.5 to 4.7 I've tried.
[Bug c/53532] function call ignored when called with argument of incompatible, undefined structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53532 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-31 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2012-05-31 11:12:56 UTC --- Created attachment 27530 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27530 gcc48-pr53532.patch Untested fix. Not a regression though, at least not recent, already 3.2 is silent on it.
[Bug middle-end/53510] [4.8 Regression] OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek 2012-05-31 12:10:09 UTC --- Fixed.
[Bug tree-optimization/53336] [4.8 Regression] invalid types in nop conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-05-31 12:17:28 UTC --- Fixed.
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2012-05-27 00:00:00 |2012-05-31 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #11 from Jakub Jelinek 2012-05-31 12:28:58 UTC --- Fixed by PR52905 fix. If this one is ice-on-valid-code, probably it should be backported (which it wasn't because the other bug is just ice-on-invalid-code).
[Bug target/53539] New: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53539 Bug #: 53539 Summary: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com From http://gcc.gnu.org/ml/gcc/2012-05/msg00397.html On Linux/i386: [hjl@gnu-29 ~]$ echo __WCHAR_TYPE__ | gcc -E - # 1 "" # 1 "" # 1 "" # 1 "" long int [hjl@gnu-29 ~]$ On Linux/x86-64: [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E - # 1 "" # 1 "" # 1 "" # 1 "" int [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -mx32 -E - # 1 "" # 1 "" # 1 "" # 1 "" int [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m64 -E - # 1 "" # 1 "" # 1 "" # 1 "" int [hjl@gnu-6 include]$ http://gcc.gnu.org/ml/gcc/2012-05/msg00398.html That's a bug. Not a very serious one - it doesn't affect C++ name mangling because wchar_t is a built-in type in C++, with its own mangling - but still a bug. The choice of underlying type for wchar_t should not depend on what the compiler defaults to like that. (Actually, it looks like a 32-bit-default compiler built --enable-targets=all also uses "int" here.)
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #12 from Jakub Jelinek 2012-05-31 13:15:39 UTC --- Created attachment 27531 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27531 pr53500.ii Somewhat reduced testcase for -std=c++11, though not really small.
[Bug libstdc++/43852] Embedded systems friendly libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|redi at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #18 from Jonathan Wakely 2012-05-31 13:50:52 UTC --- Sorry for not finding time to work on this. I'm unassigning myself in case anyone else wants to do it, as I've got several higher priority items and am unlikely to work on this any time soon.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Memory leak with zero-sized array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 --- Comment #9 from Tobias Burnus 2012-05-31 14:28:46 UTC --- Author: burnus Date: Thu May 31 14:28:41 2012 New Revision: 188062 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188062 Log: 2012-05-31 Tobias Burnus PR fortran/53521 * trans.c (gfc_deallocate_scalar_with_status): Properly handle the case size == 0. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #13 from Jason Merrill 2012-05-31 14:28:45 UTC --- Author: jason Date: Thu May 31 14:28:41 2012 New Revision: 188063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188063 Log: PR c++/53500 PR c++/52905 * call.c (joust): Handle comparing list and non-list ctors. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/initlist-ctor1.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/52905] [C++0x] ice on invalid brace-enclosed initializer of vector of enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52905 --- Comment #5 from Jason Merrill 2012-05-31 14:28:46 UTC --- Author: jason Date: Thu May 31 14:28:41 2012 New Revision: 188063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188063 Log: PR c++/53500 PR c++/52905 * call.c (joust): Handle comparing list and non-list ctors. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/initlist-ctor1.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Jason Merrill 2012-05-31 14:28:45 UTC --- Author: jason Date: Thu May 31 14:28:41 2012 New Revision: 188063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188063 Log: PR c++/53500 PR c++/52905 * call.c (joust): Handle comparing list and non-list ctors. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/initlist-ctor1.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog --- Comment #14 from Jason Merrill 2012-05-31 14:29:39 UTC --- Fixed by 52905 backport.
[Bug c++/52905] [C++0x] ice on invalid brace-enclosed initializer of vector of enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52905 Jason Merrill changed: What|Removed |Added Target Milestone|4.8.0 |4.7.1 --- Comment #5 from Jason Merrill 2012-05-31 14:28:46 UTC --- Author: jason Date: Thu May 31 14:28:41 2012 New Revision: 188063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188063 Log: PR c++/53500 PR c++/52905 * call.c (joust): Handle comparing list and non-list ctors. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/initlist-ctor1.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/53540] New: C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540
Bug #: 53540
Summary: C++11: using fails to be equivalent to typedef
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com
Created attachment 27532
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27532
test case
Hi all,
I hope this is not a bogus bug report, I apologize if there is something I
misunderstood. I observed the following with both 4.7.0 and "4.8":
g++-mp-4.7 (MacPorts gcc47 4.7.0_3) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++-mp-4.8 (MacPorts gcc48 4.8-20120527_1) 4.8.0 20120527 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In the following example, I import a type name from a templates struct with
"using", and do the same with "typedef". The latter works, but "using" does
not seem to find the definition. clang finds it though (but then again, my
understanding might be wrong).
If "function" is not templated, there is no problem.
$ cat foo.cc
template
struct context
{
typedef int type;
};
template
void function()
{
using ctx1 = context;
typename ctx1::type f1;
typedef context ctx2;
typename ctx2::type f2;
}
int main()
{
function();
}
$ g++-mp-4.8 -Wall -std=c++11 foo.cc
foo.cc: In instantiation of 'void function() [with T = int]':
foo.cc:19:17: required from here
foo.cc:11:23: error: no type named 'type' in 'using ctx1 = struct context'
typename ctx1::type f1;
^
foo.cc:14:23: warning: unused variable 'f2' [-Wunused-variable]
typename ctx2::type f2;
^
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 --- Comment #44 from tlknv at yandex dot ru 2012-05-31 14:43:14 UTC --- Thanks Marc. I have posted my patch at http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02086.html This is essentially a couple of line change so I hope I don't need to find and sign the contributor agreement.
[Bug c/53541] New: gcc-4.6.2 segfaults on dumping tree information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53541
Bug #: 53541
Summary: gcc-4.6.2 segfaults on dumping tree information
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantin.vladimi...@gmail.com
consider simple reproduction:
{code}
struct atexit {
struct atexit *next;
};
struct atexit *__atexit;
void *
test(void *dso)
{
struct atexit *p = 0, *q = 0;
if (dso == (void *)0)
{
for (p = __atexit; p != ((void *)0); )
{
q = p;
p = p->next;
}
}
return (void *)p;
}
{code}
We will use gcc-4.6.2 on x86:
tilir@kivladimirov ~/research/5368 $ ~/4.6-toolset/bin/gcc --version
gcc (GCC) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiling with appropriate command line and see segfault:
$ gcc -m32 -O2 -fomit-frame-pointer -fdump-tree-all-lineno-details -flto
repro.c -S
repro.c: In function ‘test’:
repro.c:20:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Lets look some deeper:
run cc1 with
{noformat}
$ /home/tilir/4.6-toolset/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/cc1 -m32
-march=x86-64 -O2 -fomit-frame-pointer -fdump-tree-all-lineno-details -flto
repro.c
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
repro.c: In function ‘test’:
repro.c:20:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
{noformat}
using GDB it is easy to see, that segfault is on line tree-pretty-print.c:1176
When GCC trying to calculate TREE_TYPE (TREE_TYPE (TREE_OPERAND (op0, 0)) it
segfaults because TREE_CODE( TREE_OPERAND (op0, 0)) is SSA_NAME, thus TREE_TYPE
(TREE_OPERAND (op0, 0) is 0, thus double TREE_TYPE is segfault.
I not sure how to correct it better -- may be add explicit check of SSA_NAME
case? But what is reason of SSA_NAME node arising here?
[Bug middle-end/53541] gcc-4.6.2 segfaults on dumping tree information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53541 Richard Guenther changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-31 Component|c |middle-end Known to work||4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-05-31 14:55:18 UTC --- TREE_TYPE should not be NULL for a valid SSA_NAME - it's NULL when the SSA name is freed, but that's invalid. Works with 4.7, confirmed on the 4.6 branch, but only with LTO.
[Bug middle-end/53541] gcc-4.6.2 segfaults on dumping tree information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53541 --- Comment #2 from Richard Guenther 2012-05-31 15:02:00 UTC --- Hm, we dump from remove_bb - such BB can obviously contain invalid stmts. The 4.7 branch has /* Released SSA_NAMES have no TREE_TYPE. */ && TREE_TYPE (TREE_OPERAND (op0, 0)) != NULL_TREE in the dumping code.
[Bug middle-end/53541] gcc-4.6.2 segfaults on dumping tree information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53541 --- Comment #3 from Richard Guenther 2012-05-31 15:03:44 UTC --- Author: rguenth Date: Thu May 31 15:03:37 2012 New Revision: 188066 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188066 Log: 2012-05-31 Richard Guenther PR middle-end/53541 * tree-pretty-print.c (dump_generic_node): Guard against NULL_TREE TREE_TYPE when dumping MEM_REF offset type. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-pretty-print.c
[Bug middle-end/53541] gcc-4.6.2 segfaults on dumping tree information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53541 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2012-05-31 15:03:44 UTC --- Author: rguenth Date: Thu May 31 15:03:37 2012 New Revision: 188066 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188066 Log: 2012-05-31 Richard Guenther PR middle-end/53541 * tree-pretty-print.c (dump_generic_node): Guard against NULL_TREE TREE_TYPE when dumping MEM_REF offset type. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-pretty-print.c --- Comment #4 from Richard Guenther 2012-05-31 15:04:03 UTC --- Fixed.
[Bug middle-end/53541] gcc-4.6.2 segfaults on dumping tree information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53541 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2012-05-31 15:04:03 UTC --- Fixed.
[Bug fortran/53537] [4.5/4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-31 CC||burnus at gcc dot gnu.org Target Milestone|--- |4.5.4 Summary|Abstract interface with |[4.5/4.6/4.7/4.8 |import interferes with |Regression] Explicit IMPORT |only-clause |of renamed USE-associated ||symbol fails Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus 2012-05-31 15:11:32 UTC --- Confirmed. The ingredients are: - The use associated symbol is renamed - IMPORT explicitly lists the renamed symbol The following program compiles with GCC 4.3 and 4.4 but not with 4.5/4.6/4.7/4.8: Error: Parameter 'wp' at (1) has not been declared or is a variable, which does not reduce to a constant expression At the "IMPORT :: wp" line (gfc_match_import), the "wp" is found and gets imported as st->name == "dp", st->n.sym->name == "dp". In check_init_expr, e->symtree->n.sym is a FL_VARIABLE with name "wp". module select_precision integer, parameter :: dp = kind(1.0) end module select_precision module ode_types use select_precision, only: wp => dp implicit none interface subroutine ode_derivative(x) import :: wp real(wp) :: x end subroutine ode_derivative end interface end module ode_types Draft patch (lightly tested): --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -3188 +3188 @@ gfc_match_import (void) - if (gfc_find_symtree (gfc_current_ns->sym_root,name)) + if (gfc_find_symtree (gfc_current_ns->sym_root, name)) @@ -3195 +3195 @@ gfc_match_import (void) - st = gfc_new_symtree (&gfc_current_ns->sym_root, sym->name); + st = gfc_new_symtree (&gfc_current_ns->sym_root, name);
[Bug fortran/53542] New: Diagnostic of USE-associated variables shows original instead of renamed symbol name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53542 Bug #: 53542 Summary: Diagnostic of USE-associated variables shows original instead of renamed symbol name Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Found during the PR 53537 investigation. Renamed USE associated variables have for symtree->name the renamed name but for symtree->n.sym->name the original name. That leads to error messages such as the following; note the "dp" vs. "wp": real(wp) :: x 1 Error: Parameter 'dp' at (1) has not been declared or is a variable, which does not reduce to a constant expression Test case: module select_precision integer :: dp = kind(1.0) end module select_precision module ode_types use select_precision, only: wp => dp contains subroutine ode_derivative(x) real(wp) :: x end subroutine ode_derivative end module ode_types
[Bug fortran/53537] [4.5/4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537 --- Comment #2 from Tobias Burnus 2012-05-31 15:22:37 UTC --- Side effect of that patch: In error messages, the original instead of the renamed symbol name appears. That's independent of this PR and due to the way USE handles renames. I have now filled PR 53542.
[Bug c++/53484] [4.7/4.8 Regression] [c++11] Wrong auto in lambdas in function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53484 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 --- Comment #45 from Jonathan Wakely 2012-05-31 15:54:05 UTC --- Thanks for the patch, I'll take a look asap. Just to answer this older comment ... (In reply to comment #35) > Who said that calling begin() on a non const std::string should be thread safe > ? For the record, as it hasn't been mentioned here explicitly, C++11 says it: 23.2.2 Container data races [container.requirements.dataraces] -1- For purposes of avoiding data races (17.6.5.9), implementations shall consider the following functions to be const: begin, end, rbegin, rend, front, back, data, find, lower_bound, upper_bound, equal_range, at and, except in associative or unordered associative containers, operator[]. So in C++11 this is definitely a bug (but then a COW string is non-conforming in other ways too, which is why it will go away when the ABI is changed.)
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 --- Comment #46 from tlknv at yandex dot ru 2012-05-31 16:13:15 UTC --- Thanks Jonathan. I didn't know about the new 23.2.2 requirements. > but then a COW string is non-conforming in other ways too Which ways? I know that I should read the standard but you might have a quick answer.
[Bug target/53538] Compile error with ARM NEON intrinsics and certain compile flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53538 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-05-31 16:24:43 UTC --- They are defined by the ARM compiler which has them documented here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/BABJFCGC.html With either -funroll-loops or -O3 (which enables sometimes full unrolling), the compiler is able to figure out the argument j is a constant as it duplicates it 4 times.
[Bug target/53538] Compile error with ARM NEON intrinsics and certain compile flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53538 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2012-05-31 16:28:32 UTC --- Well, that confused by earlier errors, bailing out (i.e. ICE without release checking) is still a compiler bug, bad error recovery.
[Bug fortran/53537] [4.5/4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537
--- Comment #3 from Tobias Burnus 2012-05-31
16:30:53 UTC ---
The patch of comment 1 fails for testsuite/gfortran.dg/import7.f90:
TYPE(T3) X
1
Error: The type of 'x' at (1) has not been declared within the interface
The following patch - on top of the one in comment 1 - does *not* help:
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3206,3 +3206,3 @@ gfc_match_import (void)
gfc_get_string ("%c%s",
- (char) TOUPPER ((unsigned char) sym->name[0]),
+ (char) TOUPPER ((unsigned char) name[0]),
&sym->name[1]));
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #47 from Jonathan Wakely 2012-05-31
16:42:27 UTC ---
21.4.1 [string.require] says that the non-const forms of operator[], at, front,
back, begin, rbegin, end and rend may not invalidate references, pointers and
iterators (so must not reallocate or modify the string)
This example shows that requirement is not met:
std::string s("str");
const char* p = s.data();
{
std::string s2(s);
(void) s[0];
}
std::cout << *p << '\n'; // p is dangling
Also the copy constructor requirements in Table 64 require the new object to
have a copy of the data. I think there are other reasons too.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #15 from Lawrence Crowl 2012-05-31 17:18:49 UTC --- > When we emit the warning, arg2_type and arg3_type are the types > of arg2 and arg3, thus, post PR16603, exactly the types of the > two initializing expressions, because we are still defining the > enumerator NumLowBitsAvailable of the same enum and the enum > is not complete. And indeed, those types are *different* as > the warning says. The types of PointerLikeTypeTraits < PT1 >::NumLowBitsAvailable and PointerLikeTypeTraits < PT2 >::NumLowBitsAvailable are enums, but the types of PT1BitsAv and PT2BitsAv are the underlying type, some form of int. The normal integral promotion should provide the ?: result type. That is, we cannot just copy the type of the initializer for PT1BitsAv, we need to determine the underlying type corresponding to the converted value. > Thus, it seems to me, the warning is behaving as designed, just, > post PR16603, it triggers also while we are defining individual > enumerators basing on other enumerators of the same enum. I agree that the basic warning is right. I am not convinced that the enumerator types are handled as per the standard. > Of course this didn't happen before PR16603 because we weren't > honoring the two-phase typing mechanism. Then it seems to me that > we have nothing to strictly-speaking "fix", but only to agree > on how we want to put the warning under control. I'm tempted to > propose again just to add a -Wenum-mismatch, I note that the EDG > front-end doesn't warn with -Wall for the reference very simple > case discussed in Comments #7 and #8. I *do* understand that > ideally we would like to tell the code in build_conditional_expr_1: > "hey we are comparing the types of the initializing expressions > of two enumerators of the same enum, which are different, but the > difference will go away at the end of the enum when we'll have a > single underlying type, thus please don't warn now" but I don't > see a simple way to do this: if, for example, we just compare > underlying types, we suppress a lot of other warnings, like the > one in Comment #7. Given what I see for EDG (what about CLANG?), > I'm not sure we should spend a lot of time right now tuning the > mechanism of the warning itself. I see two approaches. First as you suggest above, which requires passing context into the comparison. Second, set each enumerator type at the point of its definition to its unique underlying type, and at the end of the enumeration, update all the enumerators to have the enumeration's underlying type.
[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345 --- Comment #8 from Georg-Johann Lay 2012-05-31 17:32:48 UTC --- Author: gjl Date: Thu May 31 17:32:42 2012 New Revision: 188070 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188070 Log: PR target/51345 * config/avr/avr.opt (-msp8): Document it. * doc/invoke.texi (AVR Options): Ditto. And document related built-in macros. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.opt trunk/gcc/doc/invoke.texi
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-31 CC||dodji at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-05-31 17:42:41 UTC --- I think it's valid, CC'ing Dodji for confirmation.
[Bug libstdc++/53543] New: [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 Bug #: 53543 Summary: [unordered_map] conflict with __is_convertible clang intrinsic Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com The trunk implementation of unordered_map uses the following alias template at class scope: template using __is_convertible = std::is_convertible<_Pair, value_type>; Clang cannot compile this because __is_convertible is a clang intrinsic (much like how __is_base_of is a gcc intrinsic). I asked on the clang mailing list what can be done about this, and they suggested: "Since GCC 4.8 is not yet released, and Clang versions with the __is_convertible intrinsic are, the best solution would be to politely ask the libstdc++ maintainers to change this name." Would it be possible to entertain this request?
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #16 from Paolo Carlini 2012-05-31 17:48:06 UTC --- In any case I recommend not mixing together here different issues: the first one, subject of this report, is overeager warning in open enum context with conditional operators (I understand that by now we agree that the warning is behaving as designed, only it seems sensible to have a way to at least controlling it, cmp C front end, EDG); the second one is about speculative defects in the way the C++ front end handles enumerated types. For the latter we need testcases in Bugzilla, actually a separate PR should be opened.
[Bug libstdc++/53543] [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-31 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-05-31 18:04:57 UTC --- Sounds reasonable, thanks for noticing and pointing it out.
[Bug fortran/53544] New: Derived-type components in namelist group declaration produces error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53544 Bug #: 53544 Summary: Derived-type components in namelist group declaration produces error Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu Created attachment 27533 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27533 Example program illustrating namelist problem In the attached example program, the use of derived-type components in the namelist group declaration causes the following errors: foo.f90:12.19: namelist /bar/ ct%a, ct%b 1 Error: Syntax error in NAMELIST statement at (1) foo.f90:14.17: read(*, NML=bar) 1 Error: Symbol 'bar' at (1) must be a NAMELIST group name It is my understanding that the variables in a namelist group declaration must not be a dummy array with non-constant bound, a variable with non-constant character length, an automatic object, an allocatable array, a pointer, or have a component at any depth that is a pointer or is inaccessible. The case in the example program falls into none of these categories, and therefore should be accepted by the compiler as valid code.
[Bug target/51007] [4.7 Regression] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #10 from Benjamin Kosnik 2012-05-31 18:51:34 UTC --- Author: bkoz Date: Thu May 31 18:51:27 2012 New Revision: 188076 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188076 Log: 2012-05-31 Benjamin Kosnik PR libstdc++/51007 * configure.ac: Allow gnu, gnu* variants for --enable-symvers argument. * configure: Regenerated. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libquadmath/ChangeLog trunk/libquadmath/configure trunk/libquadmath/configure.ac trunk/libssp/ChangeLog trunk/libssp/configure trunk/libssp/configure.ac
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #12 from Benjamin Kosnik 2012-05-31 18:58:06 UTC --- Author: bkoz Date: Thu May 31 18:57:56 2012 New Revision: 188077 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188077 Log: 2012-05-31 Benjamin Kosnik PR libstdc++/52007 * configure.ac: Allow gnu, gnu* variants for --enable-symvers argument. * configure: Regenerated. Modified: branches/gcc-4_7-branch/libquadmath/ChangeLog branches/gcc-4_7-branch/libquadmath/configure branches/gcc-4_7-branch/libquadmath/configure.ac
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #13 from Benjamin Kosnik 2012-05-31 18:59:38 UTC --- Author: bkoz Date: Thu May 31 18:59:34 2012 New Revision: 188078 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188078 Log: 2012-05-31 Benjamin Kosnik PR libstdc++/52007 * configure.ac: Allow gnu, gnu* variants for --enable-symvers argument. * configure: Regenerated. Modified: branches/gcc-4_7-branch/libssp/ChangeLog branches/gcc-4_7-branch/libssp/configure branches/gcc-4_7-branch/libssp/configure.ac
[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52007 --- Comment #14 from Benjamin Kosnik 2012-05-31 19:01:01 UTC --- Author: bkoz Date: Thu May 31 19:00:58 2012 New Revision: 188079 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188079 Log: 2012-05-31 Benjamin Kosnik PR libstdc++/52007 * configure.ac: Allow gnu, gnu* variants for --enable-symvers argument. * configure: Regenerated. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/configure branches/gcc-4_7-branch/libgfortran/configure.ac
[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #6 from Harald Anlauf 2012-05-31 19:39:57 UTC --- (In reply to comment #2) > FWIW, if it is decided to change this, one could also consider changing > runtime_error() and internal_error() in the same way, though one would need to > audit the usage in libgfortran so that we don't generate a backtrace for a > "file not found" or similar "benign" error. Or in other words, "error > termination", as specified in the Fortran standard, should not lead to a > backtrace. See also the comment in runtime/error.c that talks about this. The patch in comment #1 changes only runtime_error_at, which appears to be generated by the front-end only. BTW: The program program test open(unit=10, file="/no/such/file", action='read') end program test gives with 4.7 and the patch in comment #1: At line 2 of file test.f90 (unit = 10, file = '') Fortran runtime error: File '/no/such/file' does not exist while 4.6.2 with -fbacktrace produces: At line 2 of file test.f90 (unit = 10, file = '') Fortran runtime error: File '/no/such/file' does not exist Backtrace for this error: + function test (0x80485F9) at line 3 of file test.f90 + /lib/libc.so.6(__libc_start_main+0xf3) [0xb73be003] The latter error is generated by a call to runtime_error_at in the compiled program, while the former error in open must be generated somewhere in st_open and descendants. Not relevant here, but note the missing file name in the first line of the error message.
[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #7 from Harald Anlauf 2012-05-31 19:41:03 UTC --- (In reply to comment #2) > FWIW, if it is decided to change this, one could also consider changing > runtime_error() and internal_error() in the same way, though one would need to > audit the usage in libgfortran so that we don't generate a backtrace for a > "file not found" or similar "benign" error. Or in other words, "error > termination", as specified in the Fortran standard, should not lead to a > backtrace. See also the comment in runtime/error.c that talks about this. The patch in comment #1 changes only runtime_error_at, which appears to be generated by the front-end only. BTW: The program program test open(unit=10, file="/no/such/file", action='read') end program test gives with 4.7 and the patch in comment #1: At line 2 of file test.f90 (unit = 10, file = '') Fortran runtime error: File '/no/such/file' does not exist while 4.6.2 with -fbacktrace produces: At line 2 of file test.f90 (unit = 10, file = '') Fortran runtime error: File '/no/such/file' does not exist Backtrace for this error: + function test (0x80485F9) at line 3 of file test.f90 + /lib/libc.so.6(__libc_start_main+0xf3) [0xb73be003] The latter error is generated by a call to runtime_error_at in the compiled program, while the former error in open must be generated somewhere in st_open and descendants. Not relevant here, but note the missing file name in the first line of the error message.
[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #8 from Harald Anlauf 2012-05-31 19:46:02 UTC --- (In reply to comment #7) > The latter error is generated by a call to runtime_error_at in > the compiled program, while the former error in open must be > generated somewhere in st_open and descendants. Forget the first half of that statement, confusion on my side. The error in open must always be generated somewhere in st_open and descendants.
[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #18 from Aldy Hernandez 2012-05-31 19:46:49 UTC --- Author: aldyh Date: Thu May 31 19:46:43 2012 New Revision: 188081 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188081 Log: PR tree-optimization/52558 * cfg.c (alloc_aux_for_edge): Fix comment. (alloc_aux_for_edge): Remove static. * basic-block.h (alloc_aux_for_edge): Protoize. * tree-ssa-loop-im.c (execute_sm_if_changed): New. (execute_sm_if_changed_flag): New. (execute_sm_if_changed_flag_set): New. (execute_sm): Do not generate data races unless requested. (tree_ssa_lim_initialize): Call alloc_aux_for_edges. (tree_ssa_lim_finalize): Call free_aux_for_edges. * gimple.h (block_in_transaction): New. (gimple_in_transaction): Use block_in_transaction. Added: trunk/gcc/testsuite/gcc.dg/pr52558-1.c trunk/gcc/testsuite/gcc.dg/pr52558-2.c trunk/gcc/testsuite/gcc.dg/tm/reg-promotion.c Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/cfg.c trunk/gcc/gimple.h trunk/gcc/tree-ssa-loop-im.c
[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Aldy Hernandez 2012-05-31 19:55:17 UTC --- Fixed on mainline. I doubt this will be fixed on 4.7, as this is too intrusive-- unless one of the RMs really wants it on 4.7.
[Bug fortran/53544] Derived-type components in namelist group declaration produces error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53544 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf 2012-05-31 20:07:37 UTC --- Why don't you simply write namelist /bar/ ct ? Anyway, neither the NAG nor the Intel compiler accept your program: % nagfor pr53544.f90 NAG Fortran Compiler Release 5.3(854) Error: pr53544.f90, line 12: Syntax error detected at CT@% ***Malformed statement [NAG Fortran Compiler pass 1 error termination, 1 error] % ifort pr53544.f90 -V Intel(R) Fortran Compiler XE for applications running on IA-32, Version 12.1.4.319 Build 20120410 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY Intel(R) Fortran 12.1-2100 pr53544.f90(12): error #5082: Syntax error, found '%' when expecting one of: , ; / namelist /bar/ ct%a, ct%b ---^ pr53544.f90(12): error #5082: Syntax error, found '%' when expecting one of: , ; / namelist /bar/ ct%a, ct%b -^ pr53544.f90(12): error #6404: This name does not have a type, and must have an explicit type. [A] namelist /bar/ ct%a, ct%b ^ pr53544.f90(12): error #6404: This name does not have a type, and must have an explicit type. [B] namelist /bar/ ct%a, ct%b --^ compilation aborted for pr53544.f90 (code 1)
[Bug c++/53545] New: g++ 4.70 --std=c++11 generates no object file, issues no errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545 Bug #: 53545 Summary: g++ 4.70 --std=c++11 generates no object file, issues no errors Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: squidbidn...@yahoo.com Created attachment 27534 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27534 Self-contained test case .cpp When I compile the attached, self-contained test-case source file testScratch.cpp, g++ does not generate an output .obj file. If I comment out lines 45-47 of testScratch.cpp, compilation is successful, and the .obj file is generated as expected. My compilation command is: g++ -o testScratch.obj -O2 -Wall -std=c++11 -c testScratch.cpp -fno-strict-aliasing -Wextra (I've also tried without the -O2 optimization option, with the same results) I am using the Mingw-builds distribution at http://code.google.com/p/mingw-builds/downloads/detail?name=x86_64-mingw32-gcc-4.7.0-release-c%2Cc%2B%2B%2Cfortran-sjlj.zip to cross-compile to Windows 7, 64-bit, running on the same. The output of g++ -v is: Using built-in specs. COLLECT_GCC=e:\stdalone\mingw\bin\g++.exe COLLECT_LTO_WRAPPER=e:/stdalone/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../mingw-src/gcc-4.7.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --enable-targets=all --enable-multilib --prefix=/./mingw-x64 --with-sysroot=/./mingw-x64 --with-tune=generic --enable-languages=c,c++,lto,fortran --enable-libstdcxx-time=yes --with-host-libstdcxx='-static -lstdc++' --enable-shared --enable-static --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-cloog-backend=isl --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-gmp=/./mingw-libs-x64 --with-mpfr=/./mingw-libs-x64 --with-mpc=/./mingw-libs-x64 --with-ppl=/./mingw-libs-x64 --with-cloog=/./mingw-libs-x64 --with-pkgversion='niXman\'\''s build' --with-bugurl=http://code.google.com/p/mingw-builds/issues/list CFLAGS='-O3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -I/./mingw-libs-x64/include' CXXFLAGS='-O3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer' CPPFLAGS= LDFLAGS='-pipe -s -L/./mingw-libs-x64/lib' Thread model: posix gcc version 4.7.0 (niXman's build)
[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #20 from torvald at gcc dot gnu.org 2012-05-31 20:23:51 UTC --- (In reply to comment #19) > Fixed on mainline. I doubt this will be fixed on 4.7, as this is too > intrusive-- unless one of the RMs really wants it on 4.7. OTOH, it would be good if we could avoid those races in 4.7 too. Can you gather the RMs' opinions please?
[Bug fortran/53544] Derived-type components in namelist group declaration produces error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53544 --- Comment #2 from Harald Anlauf 2012-05-31 20:27:26 UTC --- (In reply to comment #0) > It is my understanding that the variables in a namelist group declaration must > not be a dummy array with non-constant bound, a variable with non-constant > character length, an automatic object, an allocatable array, a pointer, or > have > a component at any depth that is a pointer or is inaccessible. The case in the > example program falls into none of these categories, and therefore should be > accepted by the compiler as valid code. >From the F2008 draft standard: R564 namelist-group-object is variable-name R603 variable-name is name C603 (R603) variable-name shall be the name of a variable. I think that ct%a is a structure component and does not qualify as the name of a variable.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #17 from Lawrence Crowl 2012-05-31 21:08:51 UTC --- > In any case I recommend not mixing together here different issues: > the first one, subject of this report, is overeager warning in open > enum context with conditional operators (I understand that by now > we agree that the warning is behaving as designed, only it seems > sensible to have a way to at least controlling it, cmp C front end, > EDG); the second one is about speculative defects in the way the > C++ front end handles enumerated types. For the latter we need > testcases in Bugzilla, actually a separate PR should be opened. I think this bug report is on how the C++ front end handles enums. Its test case is very focussed on the problem. The other test cases WRT this error message seem to be working correctly. So, I think any new PR should be an RFE for the warning option.
[Bug libstdc++/53543] [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 Paolo Carlini changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #2 from Paolo Carlini 2012-05-31 21:13:39 UTC --- If I'm not mistaken, Benjamin added these alias templates, thus let's politely ask him which name he prefers.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 Paolo Carlini changed: What|Removed |Added AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #18 from Paolo Carlini 2012-05-31 21:17:29 UTC --- Really? If that's the case, I'm learning that now, then I don't think I can help.
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug target/52971] gcc ICE with an sh64 cross-compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52971 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo 2012-05-31 21:31:10 UTC --- Could you please try these patches? http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00208.html http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00209.html http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00210.html
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #19 from Paul Pluzhnikov 2012-05-31
21:33:51 UTC ---
(In reply to comment #16)
> In any case I recommend not mixing together here different issues:
I don't believe there are separate issues here.
> the first
> one, subject of this report, is overeager warning in open enum context with
> conditional operators
Yes, that warning is overeager *in that context*, i.e. it fires on correct
code. Further, that code is quite common in template metaprogramming,
and we've had it fire in several different packages.
> (I understand that by now we agree that the warning is
> behaving as designed,
I don't believe we agree on that.
The warning itself is good (behaving as designed) in this context:
enum { A };
enum { B };
return 0 ? A : B; // bug
I wouldn't want to suppress that warning above.
But I would *have* to suppress it (we build with -Werror), if it also fires
in the open enum context, where it does *not* behave as designed.
And that would be quite undesireable.
> only it seems sensible to have a way to at least
> controlling it, cmp C front end, EDG); the second one is about speculative
> defects in the way the C++ front end handles enumerated types. For the latter
> we need testcases in Bugzilla, actually a separate PR should be opened.
The second issue you are referring to is really just an explanation of
why the code that generates the warning is doing so: it has been given
bad data.
In comment#15, Lawrence suggested an approach ("Second, ...") that would
avoid giving bad data to build_conditional_expr_1().
[Bug c++/52637] [4.7 regression] ICE producing debug info for c++11 code using local class as template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52637 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Depends on||53470 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|[4.7/4.8 regression] ICE|[4.7 regression] ICE |producing debug info for|producing debug info for |c++11 code using local |c++11 code using local |class as template argument |class as template argument --- Comment #2 from Jason Merrill 2012-05-31 21:41:55 UTC --- This was fixed on the trunk by r187106, which caused bug 53470.
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 Benjamin Kosnik changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Benjamin Kosnik 2012-05-31 21:55:29 UTC --- OK, saying fixed again on trunk and branch. Let me know if it's not right.
[Bug c++/53545] g++ 4.70 --std=c++11 generates no object file, issues no errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1 from Marc Glisse 2012-05-31 22:04:33
UTC ---
template
struct HasUpdateMethod {
template
static void test(U * u, V *... v,
decltype(u->update(*v...)) * = 0);
};
HasUpdateMethod x;
crashes g++-4.8 -std=c++11 from 1 month ago (can't test current right now).
[Bug libstdc++/53543] [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 Benjamin Kosnik changed: What|Removed |Added Status|NEW |ASSIGNED CC||bkoz at gcc dot gnu.org AssignedTo|unassigned at gcc dot |bkoz at gcc dot gnu.org |gnu.org | --- Comment #3 from Benjamin Kosnik 2012-05-31 22:07:12 UTC --- On it, this is a reasonable request. I've changed it to __is_conv to match the enable-if typedefs. -benjamin
[Bug c++/53545] g++ 4.70 --std=c++11 generates no object file, issues no errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545 Marc Glisse changed: What|Removed |Added CC|glisse at gcc dot gnu.org | --- Comment #2 from Marc Glisse 2012-05-31 22:14:52 UTC --- Looks like an infinite recursion between tsubst and tsubst_copy_and_build, does that ring a bell to someone?
[Bug target/52642] SH Target: libstdc++ failures due to call insn swapped before prologue frame insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52642 --- Comment #2 from Oleg Endo 2012-05-31 23:01:22 UTC --- Author: olegendo Date: Thu May 31 23:01:13 2012 New Revision: 188087 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188087 Log: Backport from mainline 2012-03-21 Kaz Kojima PR target/52642 * config/sh/sh.c (sh_expand_prologue): Emit blockage at the end of prologue for unwinder and profiler. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sh/sh.c
[Bug libstdc++/53543] [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 --- Comment #4 from Benjamin Kosnik 2012-05-31 23:02:24 UTC --- Author: bkoz Date: Thu May 31 23:02:18 2012 New Revision: 188088 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188088 Log: 2012-05-31 Benjamin Kosnik PR libstdc++/53543 * include/bits/hashtable_policy.h (_Insert::__is_convertible): Rename to __is_conv to avoid clash with clang built-in. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable_policy.h
[Bug target/52667] sh_reorg segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52667 --- Comment #4 from Oleg Endo 2012-05-31 23:04:08 UTC --- Author: olegendo Date: Thu May 31 23:04:02 2012 New Revision: 188089 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188089 Log: Backport from mainline 2012-03-27 Chung-Lin Tang PR target/52667 * config/sh/sh.c (find_barrier): Add equality check of last_got to avoid going above orig insn. Update comments. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sh/sh.c
[Bug libstdc++/53543] [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 Benjamin Kosnik changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Benjamin Kosnik 2012-05-31 23:55:46 UTC --- Fixed.
[Bug gcov-profile/53546] New: gcc ICEs when using -fripa at varpool.c:45
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53546 Bug #: 53546 Summary: gcc ICEs when using -fripa at varpool.c:45 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: asha...@gcc.gnu.org Created attachment 27535 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27535 Proposed patch to fix this problem. This only happens in -fripa compilation mode under some circumstances. The reason is that in dwarf2asm.c dw2_output_indirect_constant_1, we do not copy the TREE_STATIC() property from id to decl. I am attaching a patch that fixes this problem.
[Bug gcov-profile/53547] New: Changing the source file between -fprofile-generate and -fprofile-use can lead to performance degradation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53547 Bug #: 53547 Summary: Changing the source file between -fprofile-generate and -fprofile-use can lead to performance degradation Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: asha...@gcc.gnu.org Created attachment 27536 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27536 Test case. Please take a look at the attached test case. gcc -O2 -fprofile-generate test.c rm -rf test.gcda && ./a.out gcc -O2 -fprofile-use -DSTALE test.c Note that with -DSTALE, a function is added which changes the function id ordering within the module. With this re-ordering, the profile data no longer matches up with the updated source file. What is worse is that the performance actually *drops* below that of regular -O2 (without -fprofile-use). This is because the summary information (sum_max, etc.) is still valid while the edge count is considered to be 0 for all edges. This leads to pessimistic inlining decisions. Here is a patch that fixes solves the performance loss: http://codereview.appspot.com/5989046/
[Bug gcov-profile/53547] Changing the source file between -fprofile-generate and -fprofile-use can lead to performance degradation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53547 --- Comment #1 from asharif at gcc dot gnu.org 2012-06-01 00:22:06 UTC --- Created attachment 27537 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27537 Proposed fix.
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 --- Comment #17 from Jonathan Wakely 2012-06-01 00:38:41 UTC --- Updated patch at http://gcc.gnu.org/ml/gcc-patches/2012-06/msg1.html
[Bug c/53548] New: allow flexible array members in unions like zero-length arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
Bug #: 53548
Summary: allow flexible array members in unions like
zero-length arrays
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vap...@gentoo.org
gcc will accept this code:
struct {
short op;
union {
int i;
char foo[0];
};
};
but rejects this:
struct {
short op;
union {
int i;
char foo[];
};
};
with the error:
error: flexible array member in otherwise empty struct
[Bug c++/53545] g++ 4.70 --std=c++11 generates no object file, issues no errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545 --- Comment #3 from Anthony Hall 2012-06-01 04:29:26 UTC --- For what it's worth, I discovered the file will successfully compile (with the same compilation command as in original report) if I move the FirstStep, SecondStep, Yes, and No utility templates and specializations out of the HasUpdateMethod to file scope, or embed them in a file-level "detail" namespace, with no other code changes.
