[Bug tree-optimization/50213] [4.6 Regression] Regression in space-optimized code relative to 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213 Eduardo Tongson propolice at gmail dot com changed: What|Removed |Added CC||propolice at gmail dot com --- Comment #9 from Eduardo Tongson propolice at gmail dot com 2011-10-17 06:47:31 UTC --- Seems trivial to backport to 4.6.1 (at least) or it is not?
[Bug fortran/50752] New: [4.7 Regression] ICE in match_kind_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50752 Bug #: 50752 Summary: [4.7 Regression] ICE in match_kind_param Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch This one-liner leads to a segfault in 4.7: vondele@pcihopt3:/data03/vondele/bugs/ice cat bug.f90 rPos=0.0_dp vondele@pcihopt3:/data03/vondele/bugs/ice gfortran bug.f90 f951: internal compiler error: Segmentation fault 60*is_iso_c = sym-attr.is_iso_c; (gdb) bt #0 0x0056db6f in match_kind_param (is_iso_c=0x7fffd51c) at ../../gcc/gcc/fortran/primary.c:60 #1 get_kind (is_iso_c=0x7fffd51c) at ../../gcc/gcc/fortran/primary.c:103 #2 0x0056de7b in match_real_constant (result=0x7fffd660, signflag=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/primary.c:625 #3 0x0056ed6c in gfc_match_literal_constant (result=0x7fffd660, signflag=0) at ../../gcc/gcc/fortran/primary.c:1367 #4 0x0055994e in match_primary (result=0x7fffd6c0) at ../../gcc/gcc/fortran/matchexp.c:149 #5 match_level_1 (result=0x7fffd6c0) at ../../gcc/gcc/fortran/matchexp.c:210 #6 match_mult_operand (result=0x7fffd6c0) at ../../gcc/gcc/fortran/matchexp.c:264 #7 0x00559c3d in match_add_operand (result=0x7fffd718) at ../../gcc/gcc/fortran/matchexp.c:353 #8 0x00559f65 in match_level_2 (result=0x7fffd760) at ../../gcc/gcc/fortran/matchexp.c:477 #9 0x0055a005 in match_level_3 (result=0x7fffd7c0) at ../../gcc/gcc/fortran/matchexp.c:548 #10 0x0055a13a in match_level_4 (result=0x7fffd810) at ../../gcc/gcc/fortran/matchexp.c:596
[Bug fortran/50753] New: dshiftl/dshiftr: Rejects valid BOZ, accepts double BOZ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50753 Bug #: 50753 Summary: dshiftl/dshiftr: Rejects valid BOZ, accepts double BOZ Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ka...@gcc.gnu.org Found when checking PR fortran/50514: gfortran rejects: integer :: I, J print *, dshiftl(z'FFF', J, (bit_size(j)+1)) end with Error: 'j' argument of 'dshiftl' intrinsic at (1) must be the same type and kind as 'i' Expected: a) The BOZ is accepted b) There is a diagnostic as SHIFT is larger than BIT_SIZE(J). The same applies to DSHIFTR. From Fortran 2008's 13.7.50 DSHIFTL (I, J, SHIFT) Arguments. I shall be of type integer or a boz-literal-constant. J shall be of type integer or a boz-literal-constant. If both I and J are of type integer, they shall have the same kind type parameter. I and J shall not both be boz-literal-constants. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I) if I is of type integer; otherwise, it shall be less than or equal to BIT SIZE (J). Result Value. If either I or J is a boz-literal-constant, it is first converted as if by the intrinsic function INT to type integer with the kind type parameter of the other. * * * Additionally, the following is accepted but invalid: Only one BOZ is allowed: print *, dshiftl(z'FFF', z'AAA', 0) end I am not sure whether it should be allowed with -std=gnu, but none of my compilers diagnoses it correctly. (Well, except for ifort, which even rejects the example of the Fortran 2008 standard.)
[Bug middle-end/50754] New: [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Bug #: 50754 Summary: [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch somewhere in the last 3 days the following regression appeared in trunk: gfortran -march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -g -O3 -ffast-math -funroll-loops -ftree-vectorize -ffree-form bug.f90 vec_perm_expr 0x7fcf671e41f8 type vector_type 0x7fcf67110540 type real_type 0x7fcf670aef18 real(kind=8) DF size integer_cst 0x7fcf6709eec0 constant 64 unit size integer_cst 0x7fcf6709eee0 constant 8 align 64 symtab 0 alias set 2 canonical type 0x7fcf670aef18 precision 64 pointer_to_this pointer_type 0x7fcf670bc150 V2DF size integer_cst 0x7fcf670b1400 constant 128 unit size integer_cst 0x7fcf670b1420 constant 16 align 128 symtab 0 alias set 2 canonical type 0x7fcf67110540 nunits 2 pointer_to_this pointer_type 0x7fcf67117c78 arg 0 ssa_name 0x7fcf671d8cd0 type vector_type 0x7fcf67110540 visited var var_decl 0x7fcf671df1e0 vect_var_.27def_stmt vect_var_.27_126 = MEM[(real(kind=8)[3] *)respos + 8B]; version 126 arg 1 ssa_name 0x7fcf671d8cd0 arg 2 vector_cst 0x7fcf671cc5a0 type vector_type 0x7fcf671c1c78 type integer_type 0x7fcf670ae7e0 unsigned V2DI size integer_cst 0x7fcf670b1400 128 unit size integer_cst 0x7fcf670b1420 16 align 128 symtab 0 alias set -1 canonical type 0x7fcf671c1c78 nunits 2 constant elt0: integer_cst 0x7fcf671c6400 constant 1 elt1: integer_cst 0x7fcf670b1300 constant 0 bug.f90:9:0 bug.f90: In function ‘calcbox’: bug.f90:4:0: internal compiler error: in expand_debug_expr, at cfgexpand.c:3341 cat bug.f90 MODULE gauss_colloc INTEGER, PARAMETER :: dp=8 CONTAINS FUNCTION calcBox() RESULT(res) REAL(dp) :: cci0, cci1, cci2, delta_i, m(0:2,0:2), maxr2, r_0, sqDi REAL(dp), DIMENSION(0:2):: l, resPos r_0=0.0_dp DO i=0,2 r_0=r_0-0.5*resPos(2-i)*l(i) END DO cci0 = -((-4.0_dp * m(2,2) * r_0 * m(1,1) + m(2,2) * l(1) ** 2 + l(2) ** 2 * m(1,1) - 2.0_dp * l(1) * m(1,2) * l(2) + 4.0_dp * r_0 * m(1,2) ** 2) / (m(2,2) * m(1,1) - m(1,2) ** 2)) / 4.0_dp-maxr2 delta_i=cci1*cci1-4.0_dp*cci2*cci0 IF (delta_i0.0_dp) THEN imin=fullShift(2)+CEILING((-cci1-sqDi)/(2.0_dp*cci2)) END IF END FUNCTION END MODULE
[Bug c/25975] Problems with -ffast-math and isnan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25975 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||ejtttje at gmail dot com --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 07:12:38 UTC --- *** Bug 50724 has been marked as a duplicate of this bug. ***
[Bug lto/50747] [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50747 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Target Milestone|--- |4.7.0
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 07:12:38 UTC --- (In reply to comment #17) Richard said: math.h is not part of GCC But the point is there is value in consistency between math.h and cmath regardless of who owns math.h. I'm asserting that this value is greater than that gained by 'optimizing away' the classification functions in cmath. Inconsistency leads to confused users and therefore bugs, missed optimization is only going to cause slower code. You get the same inconsistency if math.h implements isnan as #define isnan(x) (!((x)==(x))) which is a valid implementation. That would be optimized with your suggested -ffinite-math-only implementation, but not when the library implements isnan as #define isnan(x) __builtin_isnan(x) So what's your point again? I get that you want to make the most of -ffast-math, and if it were a big speedup it could be worthwhile, but it seems reasonable that if someone is serious about optimizing away their classification sanity checks in a release build, they would be better served by using assert() or an #ifdef instead of relying of the vagaries of -ffast-math for this purpose. The only way out I see that not breaks other users uses would be a new flag, like -fpreserve-ieee-fp-classification that, ontop of -ffinite-math-only, I'm not opposed to a new flag, but I'd suggest the reverse semantics. Disabling classification is an extra degree of non-compliance beyond ignoring non-finite math operations. I'd rather users add flags to progressively become less compliant, rather than add a flag to get some compliance back. The point is backward-compatible behavior of -ffast-math. We can't and should not break this without a very very very good reason. Which this isn't. But to rewind a second, I want to address the breaks other users comment... here is the status AFAIK: 1) Older versions (4.1, 4.2) of gcc did not do this optimization of classification functions. Thus, legacy code expects classification to work even in the face of -ffast-math, which was changed circa 4.3/4.4 Sure they did. 2) Removing classification 'breaks' code because it fundamentally strips execution paths which may otherwise be used. 3) Leaving classification in could be considered a missed optimization, but is at worst only a performance penalty, not a change in execution values. 4) Personal conjecture: I doubt the classification routines are a performance bottleneck in the areas where -ff-m-o is being applied, so (3) is pretty minimal. And I seriously doubt anyone is relying on the removal of classification in a code-correctness context, that doesn't make any sense. I have written code that you can switch between using FP exceptions and explicit checks at certain points. I expect the checks to be optimized away when using the FP exception path. Are we on the same page with these points? So if you are concerned with the breakage of existing code, isn't the solution to revert to the previous scope of the -ff-m-o optimization ASAP, and then if there is a desire to extend the finite-only optimization to classification functions, *that* would be a new feature request, perhaps with its own flag? (Note that they are folded to arithmetic, !(x==x), so that transform has to be disabled as well, and on some architectures you might get library calls because of this instead of inline expansions). I'd rather leave comparison optimizations as they are under -ff-m-o, that seems a sensible expectation of the 'arithmetic' scope, and is relatively well-known, long-standing effect of -ffast-math. It's only the 5 explicit fp classification calls which I think deserve protection to allow data validation in a non-hacky manner before doing core computations with the finite invariant. Unless you are saying things like std::isnan cannot be implemented separately from !(x==x)? That has not been my understanding. No, I said that GCC itself unconditionally transforms isnan to !(x == x) (independent of -ffinite-math-only). If you really want to go forward you have to produce a patch, test it and post it to gcc-patc...@gcc.gnu.org. *** This bug has been marked as a duplicate of bug 25975 ***
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50744] [4.7 Regression] ice in good_cloning_opportunity_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50744 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC|rguenth at gcc dot gnu.org |jamborm at gcc dot gnu.org Component|c++ |tree-optimization Target Milestone|--- |4.7.0 Summary|ice in |[4.7 Regression] ice in |good_cloning_opportunity_p |good_cloning_opportunity_p
[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC|rguenth at gcc dot gnu.org |matz at gcc dot gnu.org Component|c++ |middle-end Target Milestone|--- |4.7.0 Summary|remove_unused_locals causes |[4.7 Regression] |seg fault |remove_unused_locals causes ||seg fault --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 07:17:07 UTC --- Probably a dup.
[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-17 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 07:21:16 UTC --- Confirmed. (gdb) call debug_tree (t) var_decl 0x101cde780 __FUNCTION__ type array_type 0x1424de5e8 type integer_type 0x14232cc78 char readonly sizes-gimplified string-flag type_6 QI size integer_cst 0x14230db80 constant 8 unit size integer_cst 0x14230dba0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x14232cc78 precision 8 min integer_cst 0x14230db40 -128 max integer_cst 0x14230dc20 127 pointer_to_this pointer_type 0x14232cd20 reference_to_this reference_type 0x101bc67e0 while walking CONSTRUCTOR elements of DECL_INITIAL of var_decl 0x101cde6e0 _rL_53 ... addressable used static tree_1 tree_3 decl_5 decl_6 BLK file bug36.cc line 8706 col 80 size integer_cst 0x14252d820 512 unit size integer_cst 0x101a362e0 64 align 256 context function_decl 0x101cd4200 CompressedMagic attributes tree_list 0x1424f5780 initial constructor 0x101a38360 thus a function-local static.
[Bug fortran/50752] [4.7 Regression] ICE in match_kind_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50752 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-invalid-code Last reconfirmed||2011-10-17 CC||janus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-10-17 08:08:59 UTC --- This is clearly due to http://gcc.gnu.org/viewcvs?view=revisionrevision=180062 which was my fix for PR47023. It's easy to fix this, however. To offending line should just came a bit too soon: Index: gcc/fortran/primary.c === --- gcc/fortran/primary.c(revision 180062) +++ gcc/fortran/primary.c(working copy) @@ -57,11 +57,11 @@ match_kind_param (int *kind, int *is_iso_c) if (gfc_find_symbol (name, NULL, 1, sym)) return MATCH_ERROR; - *is_iso_c = sym-attr.is_iso_c; - if (sym == NULL) return MATCH_NO; + *is_iso_c = sym-attr.is_iso_c; + if (sym-attr.flavor != FL_PARAMETER) return MATCH_NO; Sorry for the breakage. Will commit as obvious.
[Bug libstdc++/50703] std::stringstream not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703 --- Comment #7 from hoenle2...@kayser-threde.com 2011-10-17 08:17:21 UTC --- @Jonathan: You ask was gcc built with a non-default value for --enable-clocale ?. I don't think so. We perform cross development on Windows with MinGW as supported out-of-the-box by the RTEMS operating system distribution. With that distribution the cross compilation tools come already pre-compiled. Maybe the following gcc output helps: $ sparc-rtems-gcc -v Reading specs from c:/opt/rtems-4.8-mingw/bin/../lib/gcc/sparc-rtems/4.2.4/specs Target: sparc-rtems Configured with: ../gcc-4.2.4/configure --target=sparc-rtems --host i686-mingw32 --build i486-slackware-linux --with-gnu-as --with-gnu-ld --with-newlib --verbose --enable-threads --enable-languages=c,c++ --disable-nls --prefix=/opt/rtems-4.8-mingw --enable-version-specific-runtime-libs --with-system-zlib --disable-libstdcxx-pch --disable-win32-registry --without-included-gettext Thread model: rtems gcc version 4.2.4 - @Paolo: We never access a std::stringstream object from different threads but always from a single thread. When we share objects between threads, we protect them by a pthread mutex. I will perform a test with a new GCC/libstdc++ probably mid November. In case the problem persists I will try to set up a short, self contained reproducer. - Regards Alfred
[Bug c++/50755] New: [ICE]: tree check: expected class 'constant', have 'unary' (convert_expr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755 Bug #: 50755 Summary: [ICE]: tree check: expected class 'constant', have 'unary' (convert_expr) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: ja...@gcc.gnu.org Target: avr Build: x86-pc-linux-gnu Following test case runs into ICE with trunk r180076: avr-g++ -v ./gcc/testsuite/g++.dg/template/constant2.C -S -mmcu=atmega128 -o constant2.s Using built-in specs. Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared --enable-languages=c,c++ --with-dwarf2 --disable-lto --enable-checking=yes,rtl Thread model: single gcc version 4.7.0 20111017 (experimental) (GCC) GNU C++ (GCC) version 4.7.0 20111017 (experimental) (avr) compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 ./gcc/testsuite/g++.dg/template/constant2.C:6:35: internal compiler error: tree check: expected class 'constant', have 'unary' (convert_expr) in warnings_for_convert_and_check, at c-family/c-common.c:2211
[Bug tree-optimization/50698] pretending to create versioning for alias when not required
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de
2011-10-17 09:26:05 UTC ---
On Sat, 15 Oct 2011, vincenzo.innocente at cern dot ch wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-10-15 13:40:31 UTC ---
I now moved to a more realistic case that can be reduced to this:
void loop(float * x, int n) {
for (int i=0;i!=n; ++i)
x[i]=x[i+n]+x[i+2*n];
}
and it creates aliases even if the memory region are clearly disjoint:
(used gcc version 4.7.0 20111015 (experimental) (GCC) )
keep here or open an other enhancement request?
The problem is that x[i] and x[i+n] may alias for n == 0. So this
is a completely different issue - that we miss to account for the
fact that n is the loop bound for the induction variable i and that
because i is signed, n has to be = 0. Still we won't be able to
compute a meaningful distance vector, as it depends on n, thus
we have to version the loop anyway (the distance vector is n and 2 * n).
Thus I'd say open a separate enhancement request stating that we need
to handle non-constant distance vectors in a better way (do not hold
your breath).
[Bug tree-optimization/50213] [4.6 Regression] Regression in space-optimized code relative to 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de 2011-10-17 09:33:49 UTC --- On Mon, 17 Oct 2011, propolice at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213 Eduardo Tongson propolice at gmail dot com changed: What|Removed |Added CC||propolice at gmail dot com --- Comment #9 from Eduardo Tongson propolice at gmail dot com 2011-10-17 06:47:31 UTC --- Seems trivial to backport to 4.6.1 (at least) or it is not? We don't backport this kind of patches generally, they may expose more serious bugs on release branches.
[Bug fortran/50752] [4.7 Regression] ICE in match_kind_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50752 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug middle-end/50754] [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-17 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-17 09:38:03 UTC --- Confirmed on x86_64-apple-darwin10 revision 180062 with '-O2 -ftree-vectorize -ffast-math -g', slightly reduced (valid?) test MODULE gauss_colloc INTEGER, PARAMETER :: dp=8 CONTAINS FUNCTION calcBox() RESULT(res) implicit none integer :: i, imin REAL(dp) :: r_0, res REAL(dp), DIMENSION(0:2):: l, resPos l = 1.0 resPos = [1.0,2.0,3.0] r_0=0.0_dp DO i=0,2 r_0=r_0-0.5*resPos(2-i)*l(i) END DO imin =0 IF (r_00.0_dp) THEN imin=1 END IF res=imin END FUNCTION END MODULE
[Bug fortran/50752] [4.7 Regression] ICE in match_kind_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50752 --- Comment #2 from janus at gcc dot gnu.org 2011-10-17 09:46:34 UTC --- Author: janus Date: Mon Oct 17 09:46:30 2011 New Revision: 180079 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180079 Log: 2011-10-17 Janus Weil ja...@gcc.gnu.org PR fortran/47023 PR fortran/50752 * primary.c (match_kind_param): Avoid segfault. 2011-10-17 Janus Weil ja...@gcc.gnu.org PR fortran/47023 PR fortran/50752 * gfortran.dg/kind_tests_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/kind_tests_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #12 from janus at gcc dot gnu.org 2011-10-17 09:46:33 UTC --- Author: janus Date: Mon Oct 17 09:46:30 2011 New Revision: 180079 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180079 Log: 2011-10-17 Janus Weil ja...@gcc.gnu.org PR fortran/47023 PR fortran/50752 * primary.c (match_kind_param): Avoid segfault. 2011-10-17 Janus Weil ja...@gcc.gnu.org PR fortran/47023 PR fortran/50752 * gfortran.dg/kind_tests_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/kind_tests_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48489] Invalid error message 'has no member named' when referring directly to the base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-17 09:48:06 UTC --- Author: paolo Date: Mon Oct 17 09:48:02 2011 New Revision: 180080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180080 Log: /cp 2011-10-17 Paolo Carlini paolo.carl...@oracle.com PR c++/48489 * typeck.c (finish_class_member_access_expr): Fix error call for TREE_CODE (access_path) == TREE_BINFO. /testsuite 2011-10-17 Paolo Carlini paolo.carl...@oracle.com PR c++/48489 * g++.dg/inherit/error5.C: New. Added: trunk/gcc/testsuite/g++.dg/inherit/error5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48489] Invalid error message 'has no member named' when referring directly to the base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 09:50:18 UTC --- Fixed for 4.7.0.
[Bug c++/50742] tree check fail in check_previous_goto_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50742 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 09:52:53 UTC --- Let's add Jason for this one.
[Bug tree-optimization/50756] New: request to better handle non-constant distance vectors to avoid unnecessary alias check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50756
Bug #: 50756
Summary: request to better handle non-constant distance vectors
to avoid unnecessary alias check
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
this is a follow up to PR50698
this snippet
void loop(float * x, int n) {
for (int i=0;i!=n; ++i)
x[i]=x[i+n]+x[i+2*n];
}
generates aliasing checks even if memory regions are clearly disjoint
(see analysis in comments 6 and 7 of PR50698)
I'm now experimenting with structure of arrays in place of array of
structures to make better use of vectorization (and cpu-caches). Reducing
unecessary aliasing will further improve performance (and reduce code size).It
will also avoid the need to set --param vect-max-version-for-alias-checks=100
or so.
[Bug c++/50755] [ICE]: tree check: expected class 'constant', have 'unary' (convert_expr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-17 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 09:55:35 UTC --- Testcase missing.
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #33 from Iain Sandoe iains at gcc dot gnu.org 2011-10-17 09:58:53 UTC --- Created attachment 25518 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25518 test of a foreign except thrown from a sig handler in c++ 1. the code for the D10 libSystem unwind library is available from here: http://www.opensource.apple.com/tarballs/libunwind/ (the D9 unwinder is just that of gcc-4.0). 2. Looking at a build of this, the order of the assignments (R newRegisters = register) seems generally scrambled when the getCFA function is inlined. This is reproducible with the vendor's tools and the source in 1 at optimization levels 0 and not Os. 3. The scrambling is consistent (in and out) - and I'm not 100% sure about whether this is the fault... ISTM that so long as the re-ordering is local (and consistent) to optimized code, it could be harmless. 4. the code attached tries to simplify things by emulating the effect from c++. I hope that it tries to test the the Right Thing - i.e. that register that should be preserved across the call to do_fail () are, indeed, preserved to the catch. 5. I find that the test code succeeds on i386 (D9 and D10). 6. I find that the test code fails on x86-64 (D9 - using the _current_ libgcc_s unwinder - DYLD_LIBRARY_PATH inserted). Fails on x86-64 D10 using the libSystem unwinder (with the scrambling as noted). ... i.e. it fails on two different unwinders. On both rbx seems to end up as 0. any comments on the validity of the test would be appreciated.
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263 --- Comment #40 from Dodji Seketeli dodji at gcc dot gnu.org 2011-10-17 09:59:02 UTC --- Author: dodji Date: Mon Oct 17 09:58:56 2011 New Revision: 180081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180081 Log: Linemap infrastructure for virtual locations This is the first instalment of a set which goal is to track locations of tokens across macro expansions. Tom Tromey did the original work and attached the patch to PR preprocessor/7263. This opus is a derivative of that original work. This patch modifies the linemap module of libcpp to add virtual locations support. A virtual location is a mapped location that can resolve to several different physical locations. It can always resolve to the spelling location of a token. For tokens resulting from macro expansion it can resolve to: - either the location of the expansion point of the macro. - or the location of the token in the definition of the macro - or, if the token is an argument of a function-like macro, the location of the use of the matching macro parameter in the definition of the macro The patch creates a new type of line map called a macro map. For every single macro expansion, there is a macro map that generates a virtual location for every single resulting token of the expansion. The good old type of line map we all know is now called an ordinary map. That one still encodes spelling locations as it has always had. As a result linemap_lookup as been extended to return a macro map when given a virtual location resulting from a macro expansion. The layout of structs line_map has changed to support this new type of map. So did the layout of struct line_maps. Accessor macros have been introduced to avoid messing with the implementation details of these datastructures directly. This helped already as we have been testing different ways of arranging these datastructure. Having to constantly adjust client code that is too tied with the internals of line_map and line_maps would have been even more painful. Of course, many new public functions have been added to the linemap module to handle the resolution of virtual locations. This patch introduces the infrastructure but no part of the compiler uses virtual locations yet. However the client code of the linemap data structures has been adjusted as per the changes. E.g, it's not anymore reliable for a client code to manipulate struct line_map directly if it just wants to deal with spelling locations, because struct line_map can now represent a macro map as well. In that case, it's better to use the convenient API to resolve the initial (possibly virtual) location to a spelling location (or to an ordinary map) and use that. This is the reason why the patch adjusts the Java, Ada and Fortran front ends. Also, note that virtual locations are not supposed to be ordered for relations '' and '' anymore. To test if a virtual location appears before another one, one has to use a new operator exposed by the line map interface. The patch updates the only spot (in the diagnostics module) I have found that was making the assumption that locations were ordered for these relations. This is the only change that introduces a use of the new line map API in this patch, so I am adding a regression test for it only. Added: trunk/gcc/testsuite/gcc.dg/cpp/pragma-diagnostic-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/trans.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-lex.c trunk/gcc/c-family/c-ppoutput.c trunk/gcc/diagnostic.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c trunk/gcc/input.c trunk/gcc/input.h trunk/gcc/java/ChangeLog trunk/gcc/java/jcf-parse.c trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/files.c trunk/libcpp/include/line-map.h trunk/libcpp/init.c trunk/libcpp/internal.h trunk/libcpp/line-map.c trunk/libcpp/macro.c
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263 --- Comment #41 from Dodji Seketeli dodji at gcc dot gnu.org 2011-10-17 10:26:42 UTC --- Most of the work done in the patches in attachment was finally checked in to support tracking locations across macro expansions. The summary of the submission is at http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01461.html. This bug is still not fixed yet, though. To properly fix it, I need to change the FEs so that declspecs have their own location. With that, I'll modify the patch that I sent to http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01043.html. For the record here is the end of the email thread that gives insight into this: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00264.html.
[Bug fortran/50752] [4.7 Regression] ICE in match_kind_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50752 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from janus at gcc dot gnu.org 2011-10-17 10:53:37 UTC --- Fixed with r180079. Closing. Thanks for catching this so quickly, Joost!
[Bug c++/50473] [C++0x] ICE in type_has_nontrivial_copy_init, at cp/tree.c:2574
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50473 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 10:53:44 UTC --- Jason, the call chain here is set_up_extended_ref_temp - get_target_expr - get_target_expr_sfinae - build_target_expr_with_type - type_has_nontrivial_copy_init, which hits gcc_assert (COMPLETE_TYPE_P (t)). Looks like tweaking, eg, build_target_expr_with_type, to check for the offending situation and return error_mark_node avoids the ICE, but I don't know at the moment if something deeper is actually going on...
[Bug tree-optimization/50213] [4.6 Regression] Regression in space-optimized code relative to 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213 --- Comment #11 from Peter A. Bigot bigotp at acm dot org 2011-10-17 11:16:16 UTC --- Richard: Thanks for the fix. For my non-integrated target I don't need it backported to 4.6 since I have a separate way to provide the patch. As I recall, the original patch didn't apply to 4.6 cleanly due to subsequent changes to tree-ssa-forwprop.c; a patch at the fork of gcc-4_6-branch from trunk is available at: http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gcc;a=commit;h=21a41ea517c2e60d3a910aca8012a2c0d57b1005
[Bug bootstrap/50709] stage3 bootstrap comparison failure with --disable-checking config option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-17 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 11:21:55 UTC --- /* Be sure that caches are maintained consistent. */ #ifdef ENABLE_CHECKING reset_edge_growth_cache (edge); reset_node_growth_cache (edge-callee); #endif in inline_small_functions - that for sure looks bogus (the conditional on ENABLE_CHECKING). If, then it should be an assert the caches are empty. Does making the above unconditional fix the issue?
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-17 11:30:24 UTC --- Bernd, IRIX 6.5 bootstrap is now broken for more than a week. How should we proceed with this? Thanks. Rainer
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #7 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17 11:40:25 UTC --- AFAIK there's no IRIX6.5 machine in the compile farm. Can you debug a bit at the point of the crash to see what's going on? Configure won't let me build the target without --neable-obsolete anyway, so is it a serious issue?
[Bug c++/50755] [ICE]: tree check: expected class 'constant', have 'unary' (convert_expr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-17 11:44:15 UTC --- Created attachment 25519 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25519 ./gcc/testsuite/g++.dg/template/constant2.C It is the testcase from the GCC source tree: ./gcc/testsuite/g++.dg/template/constant2.C added by Jason in r179813: http://gcc.gnu.org/viewcvs?view=revisionrevision=179813
[Bug c++/50757] New: Cannot turn off -Wnonnull when using C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50757 Bug #: 50757 Summary: Cannot turn off -Wnonnull when using C++ Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: roman.fie...@telemotive.de When using gcc e.g. in embedded systems it can happen that valid memory regions start at address 0x0. E.g. in our System a huge DDR2 starts at 0x0, and we cannot move it easily or even reserve page 0. Although it is almost impossible, that the start address of a format string will be at address 0, there's still the possibility, that this is normal memory that has to be used by the application, e.g as a buffer. Therefore it might happen that one wants to write something like memset(myptr, 0, mysize); or memcpy(myptr, mydata, datasize); with myptr beeing 0, or even worse, constant 0 (char * const myptr = 0x0;) Trying to turn -Wnonnull off (which is being turned on automatically using -Wall/-Wformat) using e.g. this command line g++-4.6 -Wall [-Werror] -Wno-nonnull ... causes an error cc1plus: warning: command line option ‘-Wno-nonnull’ is valid for C/ObjC but not for C++ ... If it is allowed to implicitly turn on -Wnonnull it must also be allowed to turn it off again. Even in C++.
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Attachment #25518|0 |1 is obsolete|| --- Comment #34 from Iain Sandoe iains at gcc dot gnu.org 2011-10-17 12:13:53 UTC --- Created attachment 25520 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25520 revised some bad constraints in the last version (there are some odd cases, like this where it would be nice to be able to force r8..r15). - now this passes everywhere (m32/m64 on D9 and D10). ... not sure how to interpret that presently (likely more asm mistakes on my part). It would be easy if one could write the asm separately - but we're trying to trick the compiler into making the unwind tables etc. ...
[Bug middle-end/50716] Segmentation fault caused by misaligned vector access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50716 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 12:21:11 UTC --- Candidate patch: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01508.html
[Bug tree-optimization/50729] [4.7 Regression] Silent code gen fault: Value range propagation seems to propagate values across narrowing/widening
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50729 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 12:23:04 UTC --- Author: rguenth Date: Mon Oct 17 12:22:54 2011 New Revision: 180087 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180087 Log: 2011-10-17 Richard Guenther rguent...@suse.de PR tree-optimization/50729 * tree-vrp.c (extract_range_from_unary_expr_1): Remove redundant test. (simplify_conversion_using_ranges): Properly test the intermediate result. * gcc.dg/torture/pr50729.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr50729.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c++/44524] improve diagnostic for . vs - typo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44524 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 12:23:23 UTC --- Seems doable.
[Bug c++/50757] Cannot turn off -Wnonnull when using C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50757
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-10-17
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-17
12:23:34 UTC ---
Confirmed, the diagnostic says it is controlled by -Wnonnull, but that's not a
valid option for G++
extern void *f (void *__s) __attribute__ ((__nonnull__ (1)));
int main()
{
void* const s = 0;
f(s);
}
w.cc:6:8: warning: null argument where non-null required (argument 1)
[-Wnonnull]
For G++ that warning is controlled by -Wformat/-Wno-format
[Bug c++/50757] Cannot turn off -Wnonnull when using C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50757 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-17 12:33:41 UTC --- Could be fixed by adding C++ and ObjC++ to the Wnonnull definition in c-family/c.opt, or by adjusting the warning() in c-family/c-common.c to use Wformat when compiling C++
[Bug c++/50757] Cannot turn off -Wnonnull when using C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50757 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 12:43:13 UTC --- Thanks for the analysis Jon, I can do it (quite similar to the Wformat-zero-length issue, eh?)
[Bug tree-optimization/50729] [4.7 Regression] Silent code gen fault: Value range propagation seems to propagate values across narrowing/widening
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50729 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 12:57:18 UTC --- Fixed.
[Bug bootstrap/50715] [4.7 regression] bootstrap fails in libstdc++-v3 with error on symbol versioning linker script when using Sun ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50715 --- Comment #10 from Sean McGovern gseanmcg at gmail dot com 2011-10-17 13:18:51 UTC --- Successfully bootstrapped 180071 this morning -- not sure which change fixed this though.
[Bug bootstrap/50758] New: [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50758 Bug #: 50758 Summary: [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: do...@gcc.gnu.org At revision 180087 bootstrap fails at stage 2 on x86_64-apple-darwin10: /opt/gcc/build_w/./prev-gcc/g++ -B/opt/gcc/build_w/./prev-gcc/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/bin/ -nostdinc++ -B/opt/gcc/build_w/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/build_w/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -I/opt/gcc/build_w/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/opt/gcc/build_w/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/include -I/opt/gcc/work/libstdc++-v3/libsupc++ -L/opt/gcc/build_w/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/opt/gcc/build_w/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -I../../work/libcpp -I. -I../../work/libcpp/../include -I../../work/libcpp/include -I/opt/sw64/include -g -O2 -mdynamic-no-pic -gtoggle -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../work/libcpp -I. -I../../work/libcpp/../include -I../../work/libcpp/include -I/opt/sw64/include -c -o line-map.o -MT line-map.o -MMD -MP -MF .deps/line-map.Tpo ../../work/libcpp/line-map.c ../../work/libcpp/line-map.c: In function 'source_location linemap_macro_map_loc_to_exp_point(const line_map*, source_location)': ../../work/libcpp/line-map.c:628:12: error: variable 'token_no' set but not used [-Werror=unused-but-set-variable] cc1plus: all warnings being treated as errors This code was introduced at revision 180081. AFAIU the code, the warning seems bogus.
[Bug c++/50755] [ICE]: tree check: expected class 'constant', have 'unary' (convert_expr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 14:23:51 UTC --- Oops, sorry I didn't notice it's already in the testsuite, failing for this target.
[Bug bootstrap/50758] [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50758 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-17 14:34:30 UTC --- I don't see this issue at r180087 on x86_64-apple-darwin11 with... ../gcc-4.7-20111017/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl and an lto-bootstrap.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 --- Comment #15 from ak at gcc dot gnu.org 2011-10-17 14:43:45 UTC --- Author: ak Date: Mon Oct 17 14:43:37 2011 New Revision: 180093 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180093 Log: Use MADV_DONTNEED for freeing in garbage collector Use the Linux MADV_DONTNEED call to unmap free pages in the garbage collector.Then keep the unmapped pages in the free list. This avoid excessive memory fragmentation on large LTO bulds, which can lead to gcc bumping into the Linux vm_max_map limit per process. gcc/: 2011-10-08 Andi Kleen a...@linux.intel.com PR other/50636 * config.in, configure: Regenerate. * configure.ac (madvise): Add to AC_CHECK_FUNCS. * ggc-page.c (USING_MADVISE): Add. (page_entry): Add discarded field. (alloc_page): Check for discarded pages. (release_pages): Add USING_MADVISE branch. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/ggc-page.c
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-10-17 14:52:49 UTC ---
--- Comment #7 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17
11:40:25 UTC ---
AFAIK there's no IRIX6.5 machine in the compile farm. Can you debug a bit at
I think they've got an SGI machine, but were having trouble aquiring the
OS or setting it up.
the point of the crash to see what's going on?
You'll probably need to tell me in some detail what to look for. At the
point of the assertion failure, I find
(gdb) p *remember
$1 = {offset = 0, base_offset = 0, reg = 4294967295, indirect = 0, in_use = 0}
(gdb) p/x remember-reg
and the following stacktrace:
#0 fancy_abort (file=0x1451a068 /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c,
line=595, function=0x1451b100 lookup_cfa_1) at
/vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:893
#1 0x10e1ae04 in lookup_cfa_1 (cfi=0x5f19338, loc=0x7ffb79b8,
remember=0x7ffb79d0) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:595
#2 0x117a61f8 in convert_cfa_to_fb_loc_list (offset=0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:15296
#3 0x117ac410 in gen_subprogram_die (decl=0x4f89600, context_die=0x4048030) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:17413
#4 0x117b3d2c in gen_decl_die (decl=0x4f89600, origin=0x0,
context_die=0x4048030) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:19474
#5 0x117b4d6c in dwarf2out_decl (decl=0x4f89600) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:19848
#6 0x117b4e38 in dwarf2out_function_decl (decl=0x4f89600) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:19856
#7 0x11180394 in rest_of_handle_final () at
/vol/gcc/src/hg/trunk/local/gcc/final.c:4252
#8 0x120fe46c in execute_one_pass (pass=0x14701e70) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2064
#9 0x120fe7c4 in execute_pass_list (pass=0x14701e70) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2119
#10 0x120fe7f8 in execute_pass_list (pass=0x14702b90) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2120
#11 0x120fe7f8 in execute_pass_list (pass=0x14702b58) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2120
#12 0x12f8ac80 in tree_rest_of_compilation (fndecl=0x4f89600) at
/vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:420
#13 0x11f1c8a4 in cgraph_expand_function (node=0x511adf0) at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1805
#14 0x11f1cba0 in cgraph_expand_all_functions () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1864
#15 0x11f1d86c in cgraph_optimize () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2141
#16 0x11f1af10 in cgraph_finalize_compilation_unit () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1312
#17 0x10320e48 in cp_write_global_declarations () at
/vol/gcc/src/hg/trunk/local/gcc/cp/decl2.c:4008
#18 0x12ba7bac in compile_file () at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:581
#19 0x12bab3b8 in do_compile () at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1925
#20 0x12bab66c in toplev_main (argc=6, argv=0x7ffb7f04) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:2001
#21 0x1089e3ac in main (argc=6, argv=0x7ffb7f04) at
/vol/gcc/src/hg/trunk/local/gcc/main.c:36
Configure won't let me build the target without --neable-obsolete anyway, so
is it a serious issue?
It is: this is just meant as an advance warning to users that the port
*might* be removed in 4.8, depending on demand/user feedback, with the
intention of making 4.7 the best gcc release ever on the platform :-)
Rainer
[Bug bootstrap/50715] [4.7 regression] bootstrap fails in libstdc++-v3 with error on symbol versioning linker script when using Sun ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50715 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-17 14:55:14 UTC --- --- Comment #10 from Sean McGovern gseanmcg at gmail dot com 2011-10-17 13:18:51 UTC --- Successfully bootstrapped 180071 this morning -- not sure which change fixed this though. Really strange: a bootstrap of r180087 just failed for me in the same way, and none of the patches since last week even remotely touched the affected area. Rainer
[Bug bootstrap/50715] [4.7 regression] bootstrap fails in libstdc++-v3 with error on symbol versioning linker script when using Sun ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50715 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg01537.htm ||l AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #12 from Rainer Orth ro at gcc dot gnu.org 2011-10-17 15:02:56 UTC --- Patch submitted.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #9 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17 15:04:17 UTC --- Well, shooting in the dark, let's get a few preliminaries out of the way - what are the return values of dwarf2out_do_cfi_asm() and targetm.debug_unwind_info ()? Also, a few of the last RTL dumps (there ought to be a dwarf2 one) would be helpful.
[Bug bootstrap/50758] [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50758 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-17 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-17 15:12:20 UTC --- Confirmed.
[Bug bootstrap/50715] [4.7 regression] bootstrap fails in libstdc++-v3 with error on symbol versioning linker script when using Sun ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50715 --- Comment #13 from Rainer Orth ro at gcc dot gnu.org 2011-10-17 15:15:08 UTC --- Author: ro Date: Mon Oct 17 15:14:54 2011 New Revision: 180097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180097 Log: Remove duplicate symbol in gnu.ver (PR bootstrap/50715) PR bootstrap/50715 * config/abi/pre/gnu.ver (CXXABI_1.3.6): Remove duplicate __cxa_get_exception_ptr. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug bootstrap/50715] [4.7 regression] bootstrap fails in libstdc++-v3 with error on symbol versioning linker script when using Sun ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50715 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Rainer Orth ro at gcc dot gnu.org 2011-10-17 15:16:39 UTC --- Fixed for 4.7.0.
[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2011-10-17 15:18:08
UTC ---
Reducable to:
% cat x.cc
struct PublishLo
{
const char *functionName;
~PublishLo();
};
struct A { A(); };
A::A()
{
static PublishLo _rL_53 = {__FUNCTION__};
}
The problem doesn't happen when A::A is instead a normal top-level function,
which leads me to believe that somehow for member functions something forgets
to walk the initializers in add_referenced_var.
[Bug bootstrap/50758] [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50758 --- Comment #3 from dodji at seketeli dot org dodji at seketeli dot org 2011-10-17 15:26:54 UTC --- Are you still seing this with commit r180090?
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 --- Comment #12 from Paulo J. Matos Paulo.Matos at csr dot com 2011-10-17 15:26:51 UTC --- Sorry for the time taken to reply. I have tested snapshots of 4.6 and 4.7 and both seem happy now. Looks like it's sorted. Thanks.
[Bug middle-end/50741] [4.7 Regression] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Michael Matz matz at gcc dot gnu.org 2011-10-17 15:28:47 UTC --- And of course, it's the ctor cloning: DECL_CONTEXT of _rL_53 is function_decl 0x753db000 A, but current_function_decl is function_decl 0x753db200 __base_ctor. So it's similar to PR50640, in that the initializers of statics declared in different functions aren't walked. That's reasonable assuming that such initializers are walked when the declaring function is handled (which is reasonable to expect, as otherwise the initializer couldn't have been known). But here the cloning and rewriting gets into our way.
[Bug libstdc++/50724] cmath's floating-point classification implementations inconsistent with math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Ethan Tira-Thompson ejtttje at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Component|middle-end |libstdc++
Resolution|DUPLICATE |
Summary|isnan broken by |cmath's floating-point
|-ffinite-math-only in g++ |classification
||implementations
||inconsistent with math.h
Severity|enhancement |normal
--- Comment #19 from Ethan Tira-Thompson ejtttje at gmail dot com 2011-10-17
15:31:12 UTC ---
Richard said:
1) Older versions (4.1, 4.2) of gcc did not do this optimization
Sure they did.
Dude, I tested this in my very first post. I'm only here because we had
working code which has broken on the upgrade to Ubuntu 10.04. There's no point
in discussing with you if you're just going to deny the state of the world and
not offer any data to back up your side. But before you start coding a test
case, read on, turns out I've already done this for you below.
I expect the checks to be optimized away when using the FP exception path.
I hate using this rationale, but have you considered that this is not a
required or portable behavior and you shouldn't rely on it? And what happens
if the checks are left in? Is anything actually 'broken' by this? You keep
using that word, I do not think it means what you think it means. I lose data
validation when the classifications are disabled. My code does something
fundamentally different as a result. This is demonstrable 'breakage'. To
quote a wise man, We should not break this without a very very very good
reason. Which this isn't. ;)
[isnan implementation ...] So what's your point again?
There are various ways to define isnan and friends. I'm requesting one which
is consistent with math.h's isnan and also previous behavior. That could be
bitmask operations, it could be calling __isnan or math.h's isnan(), etc.
I think we need some new data to move this along...
I did a little investigation on how these functions have been defined over
time:
In 4.1 and 4.2, cmath provides:
std::isnan() forwards to __gnu_cxx::__capture_isnan()
__gnu_cxx::__capture_isnan() forwards to math.h ::isnan()
math.h ::isnan forwards to __isnan()
as of this patch:
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/c_std/cmath?r1=119611r2=130443
This has changed to simply:
std::isnan() forwards to __builtin_isnan()
Huh, that's interesting, let's cut out the middle men and see what these
underlying functions do across history:
const float qNaN = std::numeric_limitsfloat::quiet_NaN();
std::cout __builtin_isnan(qNaN) ' '
__isnan(qNaN) ' '
!(qNaN==qNaN) '\n';
Compiled with -ffast-math on 3 different machines
0 1 0 // Fedora 9, gcc 4.1.2
0 1 0 // Apple 10.7, gcc 4.2.1
0 1 0 // Ubuntu 10.04, gcc 4.4.3
Hey, you're right insofar as the 'internal' implementations haven't changed at
all. What changed is where cmath sends its implementation (and fyi, I did
originally file this under libstdc++, just by lucky guess ;). cmath used to
explicitly call the math.h definition (aka __isnan), which is not optimized by
-ffast-math.
For reference, I checked the headers on the Apple machine as well, and found
some relevant results. cmath starts the same with std::isnan → __capture_isnan
→ ::isnan, but the abridged math.h ::isnan definition is:
#if defined( __GNUC__ ) 0 == __FINITE_MATH_ONLY__
#define isnan(x) __inline_isnanT((T)(x))
inline int __inline_isnanT( T __x ) { return __x != __x; }
#else
#define isnan(x) __isnanT((T)(x))
extern int __isnanT(T);
#endif
(full source
http://www.opensource.apple.com/source/Libm/Libm-315/Source/Intel/math.h)
Which is all prepended by this comment:
Yes, that's right. You only get the fast iswhatever() macros if you do NOT
turn on -ffast-math. These inline functions require the compiler to be
compiling to standard in order to work. -ffast-math, among other things,
implies that NaNs don't happen. The compiler can in that case optimize
x != x to be false always, wheras it would be true for NaNs. That breaks
__inline_isnan() below.
So, to whatever degree you care what major users are doing, at least one
popular platform considers it breakage to disable fp classification, and falls
back on a function call to preserve it in the face of -ffast-math.
The point is backward-compatible behavior of -ffast-math.
I agree! And I even found the exact patch that broke it. So would anyone (Hi
Paolo :)) like to chime in on the rationale of the linked patch above and how
best to restore consistency of the user-facing classification functions?
In particular, can
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #13 from uros at gcc dot gnu.org 2011-10-17 15:36:36 UTC --- Author: uros Date: Mon Oct 17 15:36:28 2011 New Revision: 180098 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180098 Log: libgcc/ChangeLog: 2011-10-16 Uros Bizjak ubiz...@gmail.com Eric Botcazou ebotca...@adacore.com PR target/50737 * config/alpha/linux-unwind.h (alpha_fallback_frame_state): Set fs-signal_frame to 1. libjava/ChangeLog: 2011-10-16 Uros Bizjak ubiz...@gmail.com Eric Botcazou ebotca...@adacore.com PR target/50737 * include/dwarf2-signal.h [__alpha__]: Remove MAKE_THROW_FRAME definition. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/alpha/linux-unwind.h trunk/libjava/ChangeLog trunk/libjava/include/dwarf2-signal.h
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #35 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-17
15:36:11 UTC ---
1. the code for the D10 libSystem unwind library is available from here:
http://www.opensource.apple.com/tarballs/libunwind/
Thanks for the pointer.
2. Looking at a build of this, the order of the assignments (R newRegisters =
register) seems generally scrambled when the getCFA function is inlined. This
is reproducible with the vendor's tools and the source in 1 at optimization
levels 0 and not Os.
3. The scrambling is consistent (in and out) - and I'm not 100% sure about
whether this is the fault... ISTM that so long as the re-ordering is local
(and consistent) to optimized code, it could be harmless.
It wasn't so much the order of assignments as the difference in the offsets
between the contexts. But, you're right, this isn't the problem as the local
variable newRegisters is very likely scalarized, so the final offsets are
entirely meaningless. In any case, the problem is elsewhere, namely in the
unwind info for the _sigtramp function of the libc:
(gdb) b *0x7fff85b9b1b8
Breakpoint 1 at 0x7fff85b9b1b8
(gdb) run
Starting program: /nfs/nas/homes/botcazou/c52104y_0
C52104Y CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,
THE LENGTHS MUST MATCH.
- C52104Y NO CONSTRAINT_ERROR FOR NON-NULL ARRAY SUBTYPE WHEN ONE
DIMENSION HAS INTEGER'LAST + 3 COMPONENTS.
Program received signal SIGSEGV, Segmentation fault.
0x00012428 in c52104y_0 ()
(gdb) continue
Continuing.
Breakpoint 1, signal handler called
(gdb) disass
Dump of assembler code for function _sigtramp:
0x7fff85b9b1a0 +0: push %rbp
0x7fff85b9b1a1 +1: mov%rsp,%rbp
0x7fff85b9b1a4 +4: mov%rdi,%rax
0x7fff85b9b1a7 +7: incl -0x15261b75(%rip)#
0x7fff70939638
0x7fff85b9b1ad +13:mov%r8,%rbx
0x7fff85b9b1b0 +16:mov%edx,%edi
0x7fff85b9b1b2 +18:mov%rcx,%rsi
0x7fff85b9b1b5 +21:mov%r8,%rdx
= 0x7fff85b9b1b8 +24:callq *%rax
0x7fff85b9b1ba +26:decl -0x15261b88(%rip)#
0x7fff70939638
0x7fff85b9b1c0 +32:mov%rbx,%rdi
0x7fff85b9b1c3 +35:mov$0x1e,%esi
0x7fff85b9b1c8 +40:jmpq 0x7fff85b9b1d0 __sigreturn
0x7fff85b9b1cd +45:nop
0x7fff85b9b1ce +46:nop
0x7fff85b9b1cf +47:nop
End of assembler dump.
The CFI of the unwind info for _sigtramp is at this address:
(gdb) x/167bx 0x7fff85ccff59
0x7fff85ccff59: 0x100x000x050x730x300x060x230x10
0x7fff85ccff61: 0x100x010x050x730x300x060x230x18
0x7fff85ccff69: 0x100x020x050x730x300x060x230x20
0x7fff85ccff71: 0x100x030x050x730x300x060x230x28
0x7fff85ccff79: 0x100x040x050x730x300x060x230x38
0x7fff85ccff81: 0x100x050x050x730x300x060x230x30
0x7fff85ccff89: 0x100x060x050x730x300x060x230x40
0x7fff85ccff91: 0x100x070x050x730x300x060x230x48
0x7fff85ccff99: 0x100x080x050x730x300x060x230x50
0x7fff85ccffa1: 0x100x090x050x730x300x060x230x58
0x7fff85ccffa9: 0x100x0a0x050x730x300x060x230x60
0x7fff85ccffb1: 0x100x0b0x050x730x300x060x230x68
0x7fff85ccffb9: 0x100x0c0x050x730x300x060x230x70
0x7fff85ccffc1: 0x100x0d0x050x730x300x060x230x78
0x7fff85ccffc9: 0x100x0e0x060x730x300x060x230x80
DW_CFA_expression reg_num len DW_OP_breg3 off deref DW_OP_plus_uconst offset
So, for example, register 1 is at offset 0x18 of the deref of (%rdx + 0x30):
(gdb) x/gx ($rdx + 0x30)
0x100038958:0x0001000384bc
(gdb) x/gx 0x0001000384bc + 0x18
0x1000384d4:0x7fff5fbff910
And register 3 is at offset 0x18 of the deref of (%rdx + 0x30):
(gdb) x/gx 0x0001000384bc + 0x28
0x1000384e4:0x1000
The former is the saved %rbx and the latter is the saved %rdx. The problem is
that they are numbered differently by libunwind.h:
// 64-bit x86_64 registers
enum {
UNW_X86_64_RAX = 0,
UNW_X86_64_RDX = 1,
UNW_X86_64_RCX = 2,
UNW_X86_64_RBX = 3,
UNW_X86_64_RSI = 4,
UNW_X86_64_RDI = 5,
UNW_X86_64_RBP = 6,
UNW_X86_64_RSP = 7,
UNW_X86_64_R8 = 8,
UNW_X86_64_R9 = 9,
UNW_X86_64_R10 = 10,
UNW_X86_64_R11 = 11,
UNW_X86_64_R12 = 12,
UNW_X86_64_R13 = 13,
UNW_X86_64_R14 = 14,
UNW_X86_64_R15 = 15
};
so %rbx is register 3 and %rdx is register 1 for libunwind. Therefore, if you
swap the saved values, the program works fine:
(gdb) set { unsigned long } 0x1000384d4 = 0x1000
(gdb) set { unsigned long } 0x1000384e4 =
[Bug libstdc++/50724] cmath's floating-point classification implementations inconsistent with math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 15:40:52 UTC --- No way the library is going to do anything else but forward to the builtins here.
[Bug bootstrap/50758] [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50758
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-17
15:42:09 UTC ---
Are you still seing this with commit r180090?
I have bootstrapped revision 180087 with the following patch
--- /opt/gcc/_clean/libcpp/line-map.c2011-10-17 12:04:41.0 +0200
+++ /opt/gcc/work/libcpp/line-map.c2011-10-17 15:36:30.0 +0200
@@ -625,7 +625,7 @@ source_location
linemap_macro_map_loc_to_exp_point (const struct line_map *map,
source_location location)
{
- unsigned token_no;
+ unsigned token_no __attribute__ ((__unused__));
linemap_assert (linemap_macro_expansion_map_p (map)
location = MAP_START_LOCATION (map));
I guess that revision 180090 is a similar fix that should work (I'll have the
answer in a couple hours;-).
Last question: is the warning bogus or not? If no, why? If yes, I'll open a new
PR.
[Bug target/50725] [4.7 regression] -O3 -mstackrealign -march=core2 generates invalid prologue code in callee procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50725 --- Comment #9 from gee jojelino at gmail dot com 2011-10-17 15:42:21 UTC --- here is more specific option for reproduce this bug. $ g++ -fverbose-asm -c -O1 -finline-small-functions -ftree-vectorize -finline-functions -mstackrealign -march=core2 ./pseudo-reloc.ii -save-temps;cat pseudo-reloc.s|grep (%ecx) movl(%ecx), %eax # u, u pushl -4(%ecx) # leal-4(%ecx), %esp #, using -fverbose-asm, i got following equivalant option to above but it doesn't emit same one as above. the only difference on RTL generated between two is do_pseudo_reloc is inlined in above but below. $ g++ -fverbose-asm -c -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdefer-pop -fforward-propagate -fguess-branch-probability -fif-conversion -fif-conversion2 -finline -finline-functions-called-once -fipa-profile -fipa-pure-const -fipa-reference -fmerge-constants -fomit-frame-pointer -fshrink-wrap -fsplit-wide-types -ftoplevel-reorder -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-sink -ftree-sra -ftree-ter -finline-small-functions -ftree-vectorize -finline-functions -mstackrealign -march=core2 ./pseudo-reloc.ii -save-temps;cat pseudo-reloc.s|grep (%ecx)
[Bug c/25975] Problems with -ffast-math and isnan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25975 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 15:43:58 UTC --- *** Bug 50724 has been marked as a duplicate of this bug. ***
[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Component|libstdc++ |middle-end Resolution||DUPLICATE --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 15:43:57 UTC --- . *** This bug has been marked as a duplicate of bug 25975 ***
[Bug middle-end/50754] [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-17 15:45:12 UTC --- Revision 179960 is OK and the ICE does not show for compilers configured with --enable-checking=release.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-17 15:50:06 UTC --- --- Comment #9 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17 15:04:17 UTC --- Well, shooting in the dark, let's get a few preliminaries out of the way - what are the return values of dwarf2out_do_cfi_asm() and targetm.debug_unwind_info ()? The first returns false since MIPS_DEBUGGING_INFO is defined, the second UI_DWARF2. Also, a few of the last RTL dumps (there ought to be a dwarf2 one) would be helpful. I'm including the last 3 ones since they are huge even compressed: nothrow, dwarf2, final. Rainer
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #11 from Rainer Orth ro at gcc dot gnu.org 2011-10-17 15:52:15 UTC --- Created attachment 25521 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25521 nothrow dump
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #12 from Rainer Orth ro at gcc dot gnu.org 2011-10-17 15:53:11 UTC --- Created attachment 25522 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25522 dwarf2 dump
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #13 from Rainer Orth ro at gcc dot gnu.org 2011-10-17 15:54:02 UTC --- Created attachment 25523 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25523 final dump
[Bug bootstrap/50758] [4.7 Regression] Bootstrap fails at stage 2 on x86_64-apple-darwin10: error: variable 'token_no' set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50758
--- Comment #5 from dodji at seketeli dot org dodji at seketeli dot org
2011-10-17 15:56:05 UTC ---
dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org a écrit:
I guess that revision 180090 is a similar fix that should work (I'll
have the answer in a couple hours;-).
OK, thanks.
Last question: is the warning bogus or not? If no, why? If yes, I'll
open a new PR.
The warning is not bogus when you are compiling with --disable-checking
or when your GCC_VERSION is 2007. This is because the way
linemap_assert is defined:
/* Assertion macro to be used in line-map code. */
#define linemap_assert(EXPR)\
do {\
if (! (EXPR))\
abort ();\
} while (0)
/* Assert that MAP encodes locations of tokens that are not part of
the replacement-list of a macro expansion. */
#define linemap_check_ordinary(LINE_MAP) __extension__\
({linemap_assert (!linemap_macro_expansion_map_p (LINE_MAP)); \
(LINE_MAP);})
#else
#define linemap_assert(EXPR)
#define linemap_check_ordinary(LINE_MAP) (LINE_MAP)
#endif
In those cases token_no is not used. Hence the fix committed to
revision 180090.
Sorry for the inconvenience.
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #13 from janus at gcc dot gnu.org 2011-10-17 15:59:37 UTC --- Author: janus Date: Mon Oct 17 15:59:32 2011 New Revision: 180099 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180099 Log: 2011-10-17 Janus Weil ja...@gcc.gnu.org PR fortran/47023 * primary.c (match_kind_param): Detect ISO_C_BINDING kinds. (get_kind): Pass on 'is_iso_c' flag. (match_integer_constant,match_real_constant,match_logical_constant): Set 'ts.is_c_interop'. 2011-10-17 Janus Weil ja...@gcc.gnu.org PR fortran/47023 * gfortran.dg/c_kind_tests_3.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/c_kind_tests_3.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/primary.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/47023] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 regression]|C_Sizeof: Rejects valid |C_Sizeof: Rejects valid |code |code| --- Comment #14 from janus at gcc dot gnu.org 2011-10-17 16:15:44 UTC --- The regression of comment #2 is fixed on 4.6 and trunk (the fix will be in 4.6.2), so I'll remove the regression marker. However, there are some more open problems in this PR: * the error in comment #0 could be downgraded to a warning (which one gets in other cases similar to this) * treat BT_CLASS in decl.c (comment #1) * reject proc-pointers for SIZEOF and C_SIZEOF (comment #7)
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #38 from Mikael Pettersson mikpe at it dot uu.se 2011-10-17 16:26:28 UTC --- (In reply to comment #36) With this patch, a trivial forward-port of the gcc-4.5.3 Ada/m68k patch, and a … r178834) I was finally able to successfully bootstrap Ada on m68k-linux. I'll test this patch on more archs over the next couple of days, then if no regressions appeared I'll submit it to gcc-patches. Thanks, greatly appreciated! few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955, Do you think those could help with the gcj-4.6 showstopper, too? cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 I checked, they didn't; with them on top of 4.6.1 I got a SEGV while compiling Random.java just like PR49847 described. My next step wrt GNAT/m68k is to bisect the 4.5-4.6 changes to see what broke GNAT/m68k in the first place.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #14 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17 16:34:42 UTC --- Ok, so there are two restore_state notes following each other; note 374 and note 375. We'll want a breakpoint in add_cfi to catch the two calls where these notes are added. I'd expect it's from connect_traces, and at cfi-dw_cfi_opc = DW_CFA_restore_state; add_cfi (cfi); in that function I'd like to see some state: p debug_rtx (prev_ti-head) p debug_rtx (ti-head) p debug_cfi_row (ti-beg_row) for each time we reach this code.
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-17 16:38:28 UTC --- To check: - Pointer attribute in the part ref - or an allocate attribute. - Whether there is already some initialization. If one uses a constructor, it affects the whole variable, but mixing different data statements is OK as long as different parts are initialized. - If one directly access the variable: Pointer init is only OK for null() Example for the last item: integer, pointer :: u data u /1/ ! Accepted, but probably shouldn't ! data u/null()/ ! Probably OK (and currently accepted). end I think it could be sufficient to check decl.c's var_element though it might fail if one initializes a DT piecewise; if so, one needs to add a check to data.c or modify something else in decl.c
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2011-10-17 16:45:51 UTC --- The pr37482.c problem, at least, is a buffer overrun.
[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Ethan Tira-Thompson ejtttje at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Comment #22 from Ethan Tira-Thompson ejtttje at gmail dot com 2011-10-17 16:46:27 UTC --- Paolo: thanks for the quick reply, but it would help if you could explain why that is the case? Also, a follow-up, is __builtin_isnan and friends used anywhere except cmath? It appears not, other than tr1/special_function_util.h, which is also providing an __isnan.
[Bug c/25975] Problems with -ffast-math and isnan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25975 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 16:49:03 UTC --- *** Bug 50724 has been marked as a duplicate of this bug. ***
[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 16:49:03 UTC --- . *** This bug has been marked as a duplicate of bug 25975 ***
[Bug other/50759] New: [4.7 Regression] @table ended by @end quotation at line 595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50759 Bug #: 50759 Summary: [4.7 Regression] @table ended by @end quotation at line 595 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 180099 gave @table ended by @end quotation at line 595 @table ended by @end quotation at line 595 make[6]: [cpp.pod] Error 25 (ignored) make[6]: [gcc.pod] Error 25 (ignored)
[Bug bootstrap/50760] New: [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50760
Bug #: 50760
Summary: [4.7 Regression] bootstrap failure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
On Linux/ia32, revision 180099 gave
../../src-trunk/gcc/input.c: In function 'void dump_line_table_statistics()':
../../src-trunk/gcc/input.c:103:33: error: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}'
[-Werror=format]
../../src-trunk/gcc/input.c:106:56: error: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}'
[-Werror=format]
cc1plus: all warnings being treated as errors
make[6]: *** [input.o] Error 1
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 --- Comment #4 from Richard Henderson rth at gcc dot gnu.org 2011-10-17 17:02:12 UTC --- Author: rth Date: Mon Oct 17 17:02:05 2011 New Revision: 180100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180100 Log: PR 50746 * optabs.c (expand_vec_perm_expr): Fix indexing error. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #5 from Richard Henderson rth at gcc dot gnu.org 2011-10-17 17:03:06 UTC --- I've fixed the buffer overrun. Please re-check your respective hosts.
[Bug bootstrap/50760] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50760 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-10-17 17:05:42 UTC --- Another error: ../../src-trunk/libcpp/macro.c:1344:17: error: 'from.macro_arg_token_iter::location_ptr' may be used uninitialized in this function [-Werror=maybe-uninitialized] ../../src-trunk/libcpp/macro.c:1533:28: note: 'from.macro_arg_token_iter::location_ptr' was declared here
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-17 17:13:10 UTC --- --- Comment #14 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17 16:34:42 UTC --- Ok, so there are two restore_state notes following each other; note 374 and note 375. We'll want a breakpoint in add_cfi to catch the two calls where these notes are added. I'd expect it's from connect_traces, and at cfi-dw_cfi_opc = DW_CFA_restore_state; add_cfi (cfi); in that function I'd like to see some state: p debug_rtx (prev_ti-head) p debug_rtx (ti-head) p debug_cfi_row (ti-beg_row) for each time we reach this code. Here's the complete (slightly sanitized) output: (note 229 161 230 NOTE_INSN_EPILOGUE_BEG) (code_label 243 324 162 31 [1 uses]) .cfi_def_cfa 29, 80 .cfi_offset 16, -72 .cfi_offset 17, -64 .cfi_offset 18, -56 .cfi_offset 19, -48 .cfi_offset 20, -40 .cfi_offset 21, -32 .cfi_offset 22, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (code_label 397 258 259 51 [1 uses]) (code_label 283 348 61 48 [1 uses]) .cfi_def_cfa 29, 112 .cfi_offset 16, -88 .cfi_offset 17, -80 .cfi_offset 18, -72 .cfi_offset 19, -64 .cfi_offset 20, -56 .cfi_offset 21, -48 .cfi_offset 22, -40 .cfi_offset 23, -32 .cfi_offset 28, -24 .cfi_offset 30, -16 .cfi_offset 64, -8 (note 115 88 105 NOTE_INSN_EPILOGUE_BEG) (code_label 110 139 49 62 [1 uses]) .cfi_def_cfa 29, 32 .cfi_offset 16, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 114 122 97 NOTE_INSN_EPILOGUE_BEG) (code_label 23 127 24 59 [1 uses]) .cfi_def_cfa 29, 32 .cfi_offset 16, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 139 64 106 NOTE_INSN_EPILOGUE_BEG) (code_label 199 46 48 73 [1 uses]) .cfi_def_cfa 29, 32 .cfi_offset 16, -32 .cfi_offset 17, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 120 50 87 NOTE_INSN_EPILOGUE_BEG) (code_label 31 151 32 76 [1 uses]) .cfi_def_cfa 29, 32 .cfi_offset 16, -32 .cfi_offset 17, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (code_label 391 327 297 113 [1 uses]) (code_label 311 370 118 109 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -48 .cfi_offset 17, -40 .cfi_offset 18, -32 .cfi_offset 19, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (code_label 393 326 281 114 [1 uses]) (code_label 45 367 46 90 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -48 .cfi_offset 17, -40 .cfi_offset 18, -32 .cfi_offset 19, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (code_label 389 325 156 112 [1 uses]) (code_label 312 358 173 110 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -48 .cfi_offset 17, -40 .cfi_offset 18, -32 .cfi_offset 19, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 324 223 253 NOTE_INSN_EPILOGUE_BEG) (code_label 310 341 172 108 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -48 .cfi_offset 17, -40 .cfi_offset 18, -32 .cfi_offset 19, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 323 226 262 NOTE_INSN_EPILOGUE_BEG) (code_label 31 340 171 95 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -48 .cfi_offset 17, -40 .cfi_offset 18, -32 .cfi_offset 19, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 160 96 141 NOTE_INSN_EPILOGUE_BEG) (code_label 152 174 44 122 [1 uses]) .cfi_def_cfa 29, 64 .cfi_offset 16, -56 .cfi_offset 17, -48 .cfi_offset 18, -40 .cfi_offset 19, -32 .cfi_offset 20, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 41 26 43 NOTE_INSN_EPILOGUE_BEG) (code_label 48 62 13 125 [1 uses]) .cfi_def_cfa 29, 16 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 182 92 129 NOTE_INSN_EPILOGUE_BEG) (code_label 177 228 22 135 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -40 .cfi_offset 17, -32 .cfi_offset 18, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 143 124 128 NOTE_INSN_EPILOGUE_BEG) (code_label 136 174 13 144 [1 uses]) .cfi_def_cfa 29, 32 .cfi_offset 16, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 142 107 117 NOTE_INSN_EPILOGUE_BEG) (code_label 62 159 63 142 [2 uses]) .cfi_def_cfa 29, 32 .cfi_offset 16, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 179 207 159 NOTE_INSN_EPILOGUE_BEG) (code_label 170 213 53 155 [1 uses]) .cfi_def_cfa 29, 64 .cfi_offset 16, -32 .cfi_offset 17, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 178 193 144 NOTE_INSN_EPILOGUE_BEG) (code_label 169 199 10 154 [1 uses]) .cfi_def_cfa 29, 64 .cfi_offset 16, -32 .cfi_offset 17, -24 .cfi_offset 28, -16 .cfi_offset 64, -8 (note 105 81 93 NOTE_INSN_EPILOGUE_BEG) (code_label 37 132 38 160 [1 uses]) .cfi_def_cfa 29, 48 .cfi_offset 16, -40 .cfi_offset 17, -32 .cfi_offset 18, -24
[Bug c++/50761] New: g++ internal compiler error using std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50761 Bug #: 50761 Summary: g++ internal compiler error using std::initializer_list Classification: Unclassified Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: steph...@magnenat.net Created attachment 25524 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25524 broken code The C++11 code in attachment generates an internal compiler error in g++: test.cpp: In function ‘int main()’: test.cpp:19:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 --- Comment #10 from SK santoshkumar.a at gmail dot com 2011-10-17 17:16:36 UTC --- Please let me know if I have to add or remove any GCC options while configuring it or while compiling Linux. Any comment which can help me move further will be helpful.
[Bug c++/50761] g++ internal compiler error using std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50761 --- Comment #1 from Stéphane Magnenat stephane at magnenat dot net 2011-10-17 17:16:56 UTC --- Created attachment 25525 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25525 correct code
[Bug c++/50761] g++ internal compiler error using std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50761 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-17 17:21:22 UTC --- already fixed in 4.6 and 4.7 when testing the experimental C++0x mode, please use the latest releases - there are hundreds of fixes since the 4.5 release series was branched
[Bug middle-end/50731] [4.7 Regression] FAIL: gcc.dg/torture/vector-shift2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50731 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-10-17 17:25:53 UTC --- CC'd author of suspected commit.
[Bug c++/50761] g++ internal compiler error using std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50761 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.6.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-17 17:28:57 UTC --- .
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #7 from kargl at gcc dot gnu.org 2011-10-17 17:36:33 UTC ---
(In reply to comment #2)
The following produces a Segmentation fault in gfc_conv_structure (r178925)
type t
integer g
end type
type(t) :: u=t(1)
data u%g /2/
end
The following patch removes the seqfault. If one adds
'print *, u%g' before end and compiles the resulting
program, then one gets 1. This is acceptable, IMHO,
because the code is invalid.
Index: trans-expr.c
===
--- trans-expr.c(revision 180099)
+++ trans-expr.c(working copy)
@@ -4747,7 +4747,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
cm = expr-ts.u.derived-components;
for (c = gfc_constructor_first (expr-value.constructor);
- c; c = gfc_constructor_next (c), cm = cm-next)
+ c cm; c = gfc_constructor_next (c), cm = cm-next)
{
/* Skip absent members in default initializers and allocatable
components. Although the latter have a default initializer
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #16 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-17 17:37:11 UTC --- Sorry, I was being imprecise - only the instances where we generate notes 374 and 375 are interesting. Can you identify these two?
[Bug target/50683] GCC compiles MPFR 3.1.0 wrongly on sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-17 17:40:30 UTC --- I would suggest against a gcc workaround, let's just fix binutils. I have posted a fix to the binutils list for testing. OK, I don't have a strong opinion. What do the Debian folks think about it?
[Bug c++/50757] Cannot turn off -Wnonnull when using C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50757 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-17 17:44:47 UTC --- Author: paolo Date: Mon Oct 17 17:44:42 2011 New Revision: 180101 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180101 Log: /gcc 2011-10-17 Paolo Carlini paolo.carl...@oracle.com PR c++/50757 * c-family/c.opt ([Wnonnull]): Add C++ and Objective-C++. * doc/invoke.texi: Update. /testsuite 2011-10-17 Paolo Carlini paolo.carl...@oracle.com PR c++/50757 * g++.dg/warn/format7.C: New. * obj-c++.dg/warn7.mm: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/format7.C trunk/gcc/testsuite/obj-c++.dg/warn7.mm Modified: trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/50757] Cannot turn off -Wnonnull when using C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50757 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-17 17:46:54 UTC --- Fixed for 4.7.0.
