[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #73 from rguenther at suse dot de --- On Mon, 27 Mar 2017, jason at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 > > --- Comment #72 from Jason Merrill --- > (In reply to rguent...@suse.de from comment #69) > > As I noted elsewhere union members in C++ seem to be pure convenience and a > > union contains implicit members of all types (well, somehow factor in > > alignment). Of course Jason argues char[] is special and introduces this > > but I can't find text anywhere to support that or require char[] and not, > > say int[]. > > This is clarified somewhat in C++17, by > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html > > Note that this wording makes only unsigned char[] special, not signed or plain > char[]. Ah, I remember seeing this. So this introduces object size as a way to allow some TBAA to happen. Specifically it forbids creating a series of float sub-objects inside a char[sizeof(float)*4] sub-object due to "there is no smaller array object that satisfies these constraints"(?). One would need to use sth like struct { unsigned char storage[sizeof(float)]; } st[4]; to work around that "limitation". Not if it's really possible to take advantage of that size restriction in alias analysis though... If we'd want to implement sth like this in the middle-end I'd suggest to force frontends to mark these storage areas in some way. In the C++ case all unsigned char arrays -- does the "array of N unsigned char" wording allow for struct C {} to be created within a unsigned char (no array!) member or has it to be unsigned char[1]?). I suggest sth like /* For an ARRAY_TYPE, indicates that when the dynamic type of the storage it provides differs from the declard type it is still valid to access it via the declared type or the type of a containing object. */ #define ARRAY_TYPE_IS_STORAGE (NODE) \ (ARRAY_TYPE_CHECK (NODE)->type_common.array_type_is_storage)
[Bug target/68028] [5/6/7 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.5
[Bug preprocessor/36453] [DR 412] PR36320 breaks boost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453 Richard Biener changed: What|Removed |Added CC||sbansal at ciena dot com --- Comment #16 from Richard Biener --- *** Bug 80231 has been marked as a duplicate of this bug. ***
[Bug preprocessor/80231] Error missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80231 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- The PR suggests you write #elif (LINUX || ME_BSD_LIKE) && defined(KERNEL_VERSION) #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) ... #endif *** This bug has been marked as a duplicate of bug 36453 ***
[Bug c++/80230] error accessing struct member, error says it's size_t, but it is int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80230 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- The compiler says 'vecstruct[vecstructfromi(5ll)]' is of non-class type 'size_t'.
[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80229 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug c++/80227] [5/6/7 Regression] SFINAE ambiguity with a pointer to array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80227 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.5 Summary|[4.6/5/6/7 Regression] |[5/6/7 Regression] SFINAE |SFINAE ambiguity with a |ambiguity with a pointer to |pointer to array argument |array argument
[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80229 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Tue Mar 28 07:35:04 2017 New Revision: 246520 URL: https://gcc.gnu.org/viewcvs?rev=246520&root=gcc&view=rev Log: PR libstdc++/80229 restore support for shared_ptr PR libstdc++/80229 * include/bits/shared_ptr_base.h (__shared_ptr::_M_enable_shared_from_this_with): Change parameters to non-const and then use remove_cv to get unqualified type. * testsuite/20_util/enable_shared_from_this/members/const.cc: Don't cast away constness on object created const. * testsuite/20_util/shared_ptr/cons/80229.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/80229.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/members/const.cc
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #74 from Bernd Edlinger --- (In reply to rguent...@suse.de from comment #73) > > Ah, I remember seeing this. So this introduces object size as a way > to allow some TBAA to happen. Specifically it forbids creating > a series of float sub-objects inside a char[sizeof(float)*4] sub-object > due to "there is no smaller array object that satisfies these > constraints"(?). One would need to use sth like > > struct { unsigned char storage[sizeof(float)]; } st[4]; > I think that is meant differently, but I am not sure if I understand this kind of english good enough..., the sample uses: template struct AlignedUnion { alignas(T...) unsigned char data[max(sizeof(T)...)]; }; so that data array is max of sizeof(int) and sizeof(char) ... the more they write the less clear it becomes :) > to work around that "limitation". Not if it's really possible to > take advantage of that size restriction in alias analysis though... > > If we'd want to implement sth like this in the middle-end I'd suggest > to force frontends to mark these storage areas in some way. > In the C++ case all unsigned char arrays -- does the "array of N unsigned > char" > wording allow for struct C {} to be created within a unsigned char > (no array!) member or has it to be unsigned char[1]?). > > I suggest sth like > > /* For an ARRAY_TYPE, indicates that when the dynamic type of the storage >it provides differs from the declard type it is still valid to access >it via the declared type or the type of a containing object. */ > #define ARRAY_TYPE_IS_STORAGE (NODE) \ > (ARRAY_TYPE_CHECK (NODE)->type_common.array_type_is_storage)
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #75 from rguenther at suse dot de --- On Tue, 28 Mar 2017, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 > > --- Comment #74 from Bernd Edlinger --- > (In reply to rguent...@suse.de from comment #73) > > > > Ah, I remember seeing this. So this introduces object size as a way > > to allow some TBAA to happen. Specifically it forbids creating > > a series of float sub-objects inside a char[sizeof(float)*4] sub-object > > due to "there is no smaller array object that satisfies these > > constraints"(?). One would need to use sth like > > > > struct { unsigned char storage[sizeof(float)]; } st[4]; > > > > I think that is meant differently, but I am not sure if I > understand this kind of english good enough..., the sample uses: > > template > struct AlignedUnion { > alignas(T...) unsigned char data[max(sizeof(T)...)]; > }; > > so that data array is max of sizeof(int) and sizeof(char) > > ... the more they write the less clear it becomes :) I was thinking about how to arrange for _multiple_ objects to be constructed inside a memory area, the interesting size clause seems to require workarounds like above. Otherwise the "array element" choice doesn't make much sense I guess.
[Bug tree-optimization/80232] New: Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 Bug ID: 80232 Summary: Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch Target Milestone: --- on my machine after the usual mkdir scimark2TMP cd scimark2TMP wget http://math.nist.gov/scimark2/scimark2_1c.zip . unzip scimark2_1c.zip gcc -v I get Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/afs/cern.ch/work/i/innocent/public/w5/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk//configure --prefix=/afs/cern.ch/user/i/innocent/w5 -enable-languages=c,c++,lto,fortran --enable-lto -enable-libitm -disable-multilib Thread model: posix gcc version 7.0.1 20170326 (experimental) [trunk revision 246485] (GCC) [innocent@vinavx3 scimark2TMP]$ gcc -O2 -march=haswell *.c -lm [innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 3271.69(N=1000, nz=5000) [innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 2946.76(N=10, nz=100) [innocent@vinavx3 scimark2TMP]$ gcc -Ofast -march=nehalem *.c -lm [innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 3281.93(N=1000, nz=5000) [innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 2859.34(N=10, nz=100) [innocent@vinavx3 scimark2TMP]$ gcc -Ofast -march=corei7-avx *.c -lm [innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 2987.40(N=1000, nz=5000) [innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 2869.35(N=10, nz=100) [innocent@vinavx3 scimark2TMP]$ gcc -Ofast -march=haswell *.c -lm [innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 2579.52(N=1000, nz=5000) [innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 2381.40(N=10, nz=100) so O2 and sse4.2 are the fastest, avx is already slower, avx2 is dramatically slower par of the difference can be due to gather operation as in #57796: not sure the difference w/r/t O2 interesting to note that on KNL it makes almost not difference (not sure if this is positive or negative...) with a hint of speedup for the large problem... [innocent@vinknl0 scimark2TMP]$ gcc -Ofast -march=knl *.c -lm [innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 348.13(N=1000, nz=5000) [innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 358.67(N=10, nz=100) [innocent@vinknl0 scimark2TMP]$ gcc -O2 -march=knl *.c -lm [innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 329.33(N=1000, nz=5000) [innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 321.51(N=10, nz=100) [innocent@vinknl0 scimark2TMP]$ gcc -Ofast -march=corei7-avx *.c -lm [innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 343.12(N=1000, nz=5000) [innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 323.03(N=10, nz=100) [innocent@vinknl0 scimark2TMP]$ gcc -Ofast -march=nehalem *.c -lm ./a.out 5 | grep "Sparse matmult" [innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult" Sparse matmult Mflops: 343.57(N=1000, nz=5000) [innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult" Sparse matmult Mflops: 321.00(N=10, nz=100)
[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80229 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed.
[Bug c++/80230] error accessing struct member, error says it's size_t, but it is int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80230 --- Comment #4 from Jonathan Wakely --- Please stop reporting a bug every time your code doesn't compile.
[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80067 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Tue Mar 28 08:13:04 2017 New Revision: 246521 URL: https://gcc.gnu.org/viewcvs?rev=246521&root=gcc&view=rev Log: PR sanitizer/80067 * fold-const.c (fold_comparison): Use protected_set_expr_location instead of SET_EXPR_LOCATION. * c-c++-common/ubsan/shift-10.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/shift-10.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80067 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Mar 28 08:16:27 2017 New Revision: 246522 URL: https://gcc.gnu.org/viewcvs?rev=246522&root=gcc&view=rev Log: PR sanitizer/80067 * fold-const.c (fold_comparison): Use protected_set_expr_location instead of SET_EXPR_LOCATION. * c-c++-common/ubsan/shift-10.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/shift-10.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/fold-const.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80067 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79931 --- Comment #4 from Martin Liška --- I can confirm that, it's not Ubuntu specific, easily reproducible on current trunk. Issues is that ODR type graph is built dynamically, starting just with types of methods. During gimplification of functions, possible_polymorphic_call_targets is asked and known results are put into polymorphic_call_target_hash. Problem comes when a type receives a new derived type which can add possible target. This happens in your test-case. I prepared a simple patch validating that # of targets does not change during time in the cache and there's example that fails: class b { protected: enum { c }; virtual void d (int a) const; bool e (); char f; }; bool b::e () { d (123); } class g : b { void d (int a) const { } }; >From possible 2 targets, new result would be 1. Still it's partial list and that can probably just make worse decisions. But still, the inconsistency should be probably handled. Honza?
[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79931 --- Comment #5 from Martin Liška --- Created attachment 41061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41061&action=edit Verification patch
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #2 from Martin Liška --- May I ask you Marek what would be use-case of such attribute? Thanks
[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 --- Comment #9 from Thomas Schwinge --- You could further optimize the script to omit "." locations: if the "dg-*" directive actually is placed on the appropriate line already.
[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- (In reply to Mike Stump from comment #6) > The . and .-1, .+1, .-2 forms are fine. The .-62 forms are as problematic > as the original I suspect. I think we should exclude any number greater > than some small int, say, 9. So, .-9 .. .+9 in the new form only. If > outside that range, I think I'd rather punt. The idea is that the absolute > number at least has a line number that in an editor you can go directly to, > and it corresponds with the number in the error messages directly, aiding > understanding which one is referred to without having to ungoop the relative > number first. I would guess that a lange number of these are actually cases where all the "dg-*" directives have been assembled at the end of the file? In such cases, it would perhaps make sense to move them onto or next to the lines they apply to -- unless that doesn't make sense for other reasons (when they are grouped together for a reason).
[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-28 Blocks||53947 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- So vectorization related. gathers are known to be notoriously slow but cost-wise they are not properly represented, in this case they are just accounted as unaligned load... It would be more appropriate to account them as VMAT_ELEMENTWISE I suppose (N scalar loads plus gathering into a vector). Thus: Index: gcc/tree-vect-stmts.c === --- gcc/tree-vect-stmts.c (revision 246500) +++ gcc/tree-vect-stmts.c (working copy) @@ -929,7 +929,8 @@ vect_model_store_cost (stmt_vec_info stm tree vectype = STMT_VINFO_VECTYPE (stmt_info); /* Costs of the stores. */ - if (memory_access_type == VMAT_ELEMENTWISE) + if (memory_access_type == VMAT_ELEMENTWISE + || memory_access_type == VMAT_GATHER_SCATTER) /* N scalar stores plus extracting the elements. */ inside_cost += record_stmt_cost (body_cost_vec, ncopies * TYPE_VECTOR_SUBPARTS (vectype), @@ -938,7 +939,8 @@ vect_model_store_cost (stmt_vec_info stm vect_get_store_cost (dr, ncopies, &inside_cost, body_cost_vec); if (memory_access_type == VMAT_ELEMENTWISE - || memory_access_type == VMAT_STRIDED_SLP) + || memory_access_type == VMAT_STRIDED_SLP + || memory_access_type == VMAT_GATHER_SCATTER) inside_cost += record_stmt_cost (body_cost_vec, ncopies * TYPE_VECTOR_SUBPARTS (vectype), vec_to_scalar, stmt_info, 0, vect_body); @@ -1056,7 +1058,8 @@ vect_model_load_cost (stmt_vec_info stmt } /* The loads themselves. */ - if (memory_access_type == VMAT_ELEMENTWISE) + if (memory_access_type == VMAT_ELEMENTWISE + || memory_access_type == VMAT_GATHER_SCATTER) { /* N scalar loads plus gathering them into a vector. */ tree vectype = STMT_VINFO_VECTYPE (stmt_info); @@ -1069,7 +1072,8 @@ vect_model_load_cost (stmt_vec_info stmt &inside_cost, &prologue_cost, prologue_cost_vec, body_cost_vec, true); if (memory_access_type == VMAT_ELEMENTWISE - || memory_access_type == VMAT_STRIDED_SLP) + || memory_access_type == VMAT_STRIDED_SLP + || memory_access_type == VMAT_GATHER_SCATTER) inside_cost += record_stmt_cost (body_cost_vec, ncopies, vec_construct, stmt_info, 0, vect_body); changes cost-model for haswell from SparseCompRow.c:37:17: note: Cost model analysis: Vector inside of loop cost: 13 Vector prologue cost: 25 Vector epilogue cost: 26 Scalar iteration cost: 5 Scalar outside cost: 7 Vector outside cost: 51 prologue iterations: 4 epilogue iterations: 4 Calculated minimum iters for profitability: 10 to SparseCompRow.c:37:17: note: Cost model analysis: Vector inside of loop cost: 23 Vector prologue cost: 25 Vector epilogue cost: 26 Scalar iteration cost: 5 Scalar outside cost: 7 Vector outside cost: 51 prologue iterations: 4 epilogue iterations: 4 Calculated minimum iters for profitability: 10 SparseCompRow.c:37:17: note: Runtime profitability threshold = 9 SparseCompRow.c:37:17: note: Static estimate profitability threshold = 15 so no change in overall profitability... We seem to peel for alignment which makes the runtime cost check quite expensive: [12.75%]: _114 = (unsigned int) rowRp1_34; _112 = (unsigned int) rowR_33; niters.6_54 = _114 - _112; _92 = (long unsigned int) rowR_33; _91 = _92 * 4; vectp.7_93 = col_38(D) + _91; _89 = (unsigned long) vectp.7_93; _88 = _89 >> 2; _87 = -_88; _86 = (unsigned int) _87; prolog_loop_niters.8_90 = _86 & 7; _44 = (unsigned int) rowRp1_34; _43 = (unsigned int) rowR_33; _27 = _44 - _43; _26 = _27 + 4294967295; _25 = prolog_loop_niters.8_90 + 7; _24 = MAX_EXPR <_25, 8>; if (_26 < _24) given that rowRp1 - rowR is 5 for the small case and 10 for the large runtime profitability is not given for the small and on the border for the large case... also the col[] setup is so that the accesses to x are continguous which means gather is overkill here. Of course we have no way to vectorize it otherwise (we don't "open-code" gather). My first suggestion would be to split the profitability check from the prologue niter computation. And of course fix the cost computation like suggested above. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #16 from Jerry DeLisle --- > (In reply to Rainer Orth from comment #15) > > Can you change line: > > if (imsg.ne."End of record") call abort > > to: > > if (imsg.ne."End of record") print *, imsg > > and lets see what its saying. Sure. I see ro@colima 27 > LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs ./dtio_26.exe Program aborted. Backtrace: Abort matching the 256 x ' ' printed by gdb. Rainer
[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 --- Comment #10 from Thomas Schwinge --- (In reply to Martin Sebor from comment #7) > A more robust solution that wouldn't have to subject to a limit would be to > add an annotation to dg-{error,message,warning} to indicate that the next > dg-{bogus,error,message,warning} directive is meant to be applied to the > same line as the current one. For instance, something like this: Instead of working "into the future"... > foobar; > /* { dg-warning "warning for foobar" continue } > { dg-warning "another warning for foobar" continue } > { dg-error "error for foobar" } */ > > (For brevity I omitted the comment and the { target ... } parts of the > directives above. It would also be nice to be able to do away with those > when they're not necessary.) ..., perhaps it's easier to implement that idea the other way round: at the end of a "dg-*" handling routine, store the current location into a global variable, and if a later "dg-*" directive uses a "continue" location, use the value of the global variable instead. That is: foobar; /* { dg-warning "warning for foobar" .-1 } Bla, bla, reasoning. { dg-warning "another warning for foobar" continue } Bla, bla, more reasoning. { dg-error "error for foobar" continue } */
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #3 from Marek Polacek --- E.g. if you have an application that is usually just busy waiting, waiting for something to happen, but you're not interested in profiling that function, or some function runs in a context where it is not safe to call into runtime support code.
[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80104 --- Comment #2 from Martin Liška --- Author: marxin Date: Tue Mar 28 09:01:57 2017 New Revision: 246525 URL: https://gcc.gnu.org/viewcvs?rev=246525&root=gcc&view=rev Log: Fix calls.c for a _complex type (PR ipa/80104). 2017-03-28 Martin Liska PR ipa/80104 * cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a thunk call as DECL_GIMPLE_REG_P when vector or complex type. 2017-03-28 Martin Liska PR ipa/80104 * gcc.dg/ipa/pr80104.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr80104.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #76 from Bernd Edlinger --- FYI this is also on the same topic: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US27 Question: "Related to core issue 1027, consider: int f() { union U { double d; } u1, u2; (int&)u1.d = 1; u2 = u1; return (int&)u2.d; } Does this involve undefined behavior? 3.8/4 seems to say that it's OK to clobber u1 with an int object. Then union assignment copies the object representation, possibly creating an int object in u2 and making the return statement well-defined. If this is well-defined, compilers are significantly limited in the assumptions they can make about type aliasing. On the other hand, the variant where U has an array of unsigned char member must be well-defined in order to support std::aligned_storage." Proposed Resolution: "Clarify that this testcase is undefined, but that adding an array of unsigned char to union U would make it well-defined--if a storage location is allocated with a particular type, it should be undefined to create an object in that storage if it would be undefined to access the stored value of the object through the allocated type." Disposition: "REJECTED Resolving this question was not deemed essential for this revision of the Standard, but core issues 1116 remains open for possible consideration in a future revision." Does this mean that the boost code is still invalid because there is no array of unsigned char ? Or does it not count because it was REJECTED ?
[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71922 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |INVALID --- Comment #9 from Ramana Radhakrishnan --- This appears to be a binutils issue - please take it up there. http://sourceware.org/bugzilla/
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #4 from Martin Liška --- I see. Simplest solution is to propagate the attribute to callers, or don't allow inlining between a pair of function one w/ and second w/o the attribute? Richi?
[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498 Ramana Radhakrishnan changed: What|Removed |Added Target|arm-none-eabi | CC||ramana at gcc dot gnu.org --- Comment #14 from Ramana Radhakrishnan --- I don't think arm is a valid target for this given PR80155 was opened as a consequence of fixing PR77498..
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #77 from Jonathan Wakely --- It was rejected in 2010, but see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1116 for the later discussion, and: "[Adopted at the June, 2016 meeting as document P0137R1.]" Which Jason already pointed to in Comment 72.
[Bug testsuite/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org Component|lto |testsuite --- Comment #34 from Ramana Radhakrishnan --- This is really a testsuite issue.
[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 --- Comment #2 from Richard Biener --- --param vect-max-peeling-for-alignment=0 disables peeling for alignment (but also makes the runtime profitability trigger at 6 loop iterations already). I suspect gather has a quite high latency and the loop just doesn't have enough work to compensate for that (given we have two gathers in the loop as well). We're also using vect__15.18_120 = VEC_PERM_EXPR ; for the index vector of the upper half of the gather but the upper half of the vector is likely ignored and thus a representation with half of the vector size and using a BIT_FIELD_REF would be more appropriate here. .L10: vmovdqa (%r15,%rax), %ymm2 vmovapd %ymm5, %ymm6 vmovapd %ymm5, %ymm7 addl$1, %edi vgatherdpd %ymm6, (%r9,%xmm2,8), %ymm3 vperm2i128 $17, %ymm2, %ymm2, %ymm2 vmovdqa %xmm2, %xmm4 vgatherdpd %ymm7, (%r9,%xmm4,8), %ymm2 vmulpd 32(%r11,%rax,2), %ymm2, %ymm2 vfmadd231pd (%r11,%rax,2), %ymm3, %ymm2 addq$32, %rax vaddpd %ymm2, %ymm0, %ymm0 cmpl%edi, %r14d ja .L10 eventually the x86 cost hook needs to consider overall instruction count to properly penaltize gather use. I suspect two xmm loads from %r15/%rax feeding the two gathers would be easier to pipeline. The fma is likely also pessimizing pipelining.
[Bug testsuite/79418] ERROR: gcc.dg/torture/stackalign/builtin-apply-2.c -O0 : syntax error in targe t selector "target arm_hf_eabi || avr-*-* || riscv*-*-*" for "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79418 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Ramana Radhakrishnan --- Fixed I think by r245240
[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 Richard Biener changed: What|Removed |Added Depends on||57796 --- Comment #3 from Richard Biener --- The gather issue is a duplicate btw (by yourself), PR57796. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 [Bug 57796] AVX2 gather vectorization: code bloat and reduction of performance
[Bug middle-end/80222] may_alias folded away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80222 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Mar 28 10:10:01 2017 New Revision: 246527 URL: https://gcc.gnu.org/viewcvs?rev=246527&root=gcc&view=rev Log: 2017-03-28 Richard Biener PR middle-end/80222 * gimple-fold.c (gimple_fold_indirect_ref): Do not touch TYPE_REF_CAN_ALIAS_ALL references. * fold-const.c (fold_indirect_ref_1): Likewise. * g++.dg/pr80222.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr80222.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/80222] may_alias folded away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80222 Richard Biener changed: What|Removed |Added Known to work||7.0.1 --- Comment #2 from Richard Biener --- Fixed on trunk sofar.
[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 --- Comment #8 from vincenzo Innocente --- My understanding of the gather latency is that it essentially corresponds to a load per cacheline: fast if all items are closeby, slower than scalar loads if items are all in different cachelines. Not sure how this can be turned in a "cost model"
[Bug rtl-optimization/80233] New: [7 Regression] ICE in combine_instructions w/ -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233 Bug ID: 80233 Summary: [7 Regression] ICE in combine_instructions w/ -O2 (and above) Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu* gcc-7.0.0-alpha20170326 snapshot ICEs on the following snippet w/ -O2 (-Os, -O3, -Ofast): int xg; void t4 (int o9) { int it; if (o9 == 0) { int fx; xg *= it; if (xg == 0) it /= 0; fx = (it != 0) ? (xg < 0) : (xg / o9); if (fx != 0) xg = 0; } } % powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20170326 -O2 -w -c hzfu8xgw.c hzfu8xgw.c: In function 't4': hzfu8xgw.c:20:1: internal compiler error: Segmentation fault } ^ (gdb) where #0 0x02aaaba73033 in combine_instructions (nregs=, f=) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:1258 #1 rest_of_handle_combine () at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:14650 #2 (anonymous namespace)::pass_combine::execute (this=) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:14695 #3 0x02aaab2d8ec6 in execute_one_pass (pass=pass@entry=0x2aaac493020) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2465 #4 0x02aaab2d98b8 in execute_pass_list_1 (pass=0x2aaac493020) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2554 #5 0x02aaab2d98ca in execute_pass_list_1 (pass=0x2aaac492480) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2555 #6 0x02aaab2d995c in execute_pass_list (fn=, pass=) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2565 #7 0x02f2a87a in cgraph_node::expand (this=0x3fff72ab000) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2038 #8 0x02f2c4ca in expand_all_functions () at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2174 #9 symbol_table::compile (this=0x3fff7127000) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2531 #10 0x02f2eb03 in symbol_table::finalize_compilation_unit (this=0x3fff7127000) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2621 #11 0x02aaab3d9dfb in compile_file () at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/toplev.c:492 #12 0x02d4b9c2 in do_compile () at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/toplev.c:2000 #13 toplev::main (this=0x3ffc940, argc=23, argv=0x3ffca48) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/toplev.c:2134 #14 0x02d4e258 in main (argc=23, argv=0x3ffca48) at /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/main.c:39
[Bug target/47847] PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47847 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Segher Boessenkool --- So, not a bug.
[Bug target/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Segher Boessenkool --- Not a bug.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #78 from Bernd Edlinger --- Ah, adopted is the opposite of rejected, fine. Does this mean that the boost code is still incorrect, because it is not using an array of unsigned char ?
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #79 from Jonathan Wakely --- That's a new change for C++17, and I don't think today's GCC will treat it any differently if it uses unsigned char[] instead of char[].
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #15 from Andreas Schwab --- Author: schwab Date: Tue Mar 28 10:29:34 2017 New Revision: 246528 URL: https://gcc.gnu.org/viewcvs?rev=246528&root=gcc&view=rev Log: Support for Ada on aarch64 with -mabi=ilp32 PR ada/80117 * system-linux-aarch64-ilp32.ads: New file. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename from LIBGNAT_TARGET_PAIRS. (LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define. (LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64 or -mabi=ilp32, resp. Added: trunk/gcc/ada/system-linux-aarch64-ilp32.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in
[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232 --- Comment #4 from Richard Biener --- I have (broadwell CPU) with -Ofast -march=native [-mno-avx] Sparse matmult Mflops: 2481.77(N=1000, nz=5000) -mno-avx Sparse matmult Mflops: 2043.19(N=1000, nz=5000) Sparse matmult Mflops: 2248.71(N=10, nz=100) -mno-avx Sparse matmult Mflops: 1664.08(N=10, nz=100) for the small system it's the overhead when not taking the vectorized code-path at runtime while for the large it is the overhead when taking the vectorized code-path. With -mno-avx we are not vectorizing the loop. Note broadwell does not yet reach optimal latency/throughput for gathers (2 lanes / cycle saturating the two load ports). I don't have a skylake machine for comparison though.
[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug rtl-optimization/45498] Optimisations fail above arbitrary level of complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45498 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Segher Boessenkool --- At least as far back as 4.9, GCC does not touch the stack in the inner loop (except for stfiwx insns). Closing as fixed.
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- Mine.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #80 from Bernd Edlinger --- but they use just: "mutable char data;"
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 Katsunori Kumatani changed: What|Removed |Added CC||katsunori.kumatani at gmail dot co ||m --- Comment #24 from Katsunori Kumatani --- I think this bug should be reopened because the current behavior is restricting. Andy is right. The compiler should be a tool and the developer using it should be allowed to shoot himself in the foot if that's what he wants. In this particular case it restricts freedom and the compiler should be the developer's tool not the other way around. Simply remove the TARGET_SSE check and let the actual developer decide if he wants the stack realigned instead of the compiler? There's even an attribute for that (to force stack realignment). I don't understand why such a check is even there, it servers NO purpose except to imply that the compiler knows better than the person using it, which is just wrong -- if someone wants to use SSE *and* 8-byte aligned stack, then let him do it. This will simply force GCC to realign the stack if and *only if* it needs to use an aligned SSE variable on the stack, just as it does with AVX already. So if 99% of your functions *do not* use SSE, they won't use 16-byte alignment. For that odd function that does use aligned SSE (or AVX), it will simply realign the stack to 16 or 32-bytes in that function's prolog. Nothing special and it won't crash. (as long as you don't call into library functions obviously) Just let the developer decide please, without having to recompile a custom modified GCC to remove that check that screams "I'm the compiler and I know better than you do what your code needs"...
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #81 from Jonathan Wakely --- (In reply to Bernd Edlinger from comment #80) > but they use just: "mutable char data;" No, actually it doesn't, see comment 45. The original testcase that this reprot came from is https://bugzilla.redhat.com/show_bug.cgi?id=1422456 which uses Boost 1.63 and that has an array of char. Jakub used the wrong version of Boost to create the code attached here.
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #16 from Eric Botcazou --- Feel free to backport it onto the 6 branch.
[Bug ipa/80205] [5/6/7 Regression] ICE in walk_ssa_copies at ipa-polymorphic-call.c:835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80205 --- Comment #1 from Martin Liška --- Author: marxin Date: Tue Mar 28 11:37:22 2017 New Revision: 246530 URL: https://gcc.gnu.org/viewcvs?rev=246530&root=gcc&view=rev Log: Handle PHI nodes w/o a argument (PR ipa/80205). 2017-03-28 Martin Liska PR ipa/80205 * g++.dg/ipa/pr80205.C: New test. 2017-03-28 Richard Biener PR ipa/80205 * tree-inline.c (copy_phis_for_bb): Do not create PHI node without arguments, generate default definition of a SSA name. Added: trunk/gcc/testsuite/g++.dg/ipa/pr80205.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug ipa/80205] [5/6/7 Regression] ICE in walk_ssa_copies at ipa-polymorphic-call.c:835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80205 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2017-03-27 00:00:00 |2017-03-28 Known to work||7.0 Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #2 from Martin Liška --- Fixed on trunk so far.
[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80104 Martin Liška changed: What|Removed |Added Known to work||7.0 Known to fail|7.0 | --- Comment #3 from Martin Liška --- Fixed on trunk so far.
[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79993 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug sanitizer/80168] [5/6 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80168 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||7.0.1 Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in |make_decl_rtl, at |make_decl_rtl, at |varasm.c:1311 w/ VLA and|varasm.c:1311 w/ VLA and |-fsanitize=address |-fsanitize=address --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/80179] [6/7 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80179 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4
[Bug c++/80179] [6/7 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80179 Richard Biener changed: What|Removed |Added Keywords|error-recovery | Priority|P4 |P2
[Bug target/79262] [6/7 Regression] load gap with store gap causing performance regression in 462.libquantum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #82 from Richard Biener --- Btw, for the attached patch it would fail to handle the case of passing the aggregate by value and the inliner introducing the aggregate copy: inline void* operator new(__SIZE_TYPE__, void* __p) { return __p; } struct X { union { int i; char s[4]; } u; }; static float foo (X y) { return reinterpret_cast (y.u.s); } int main () { X x; new (&x.u.s) float (1.0); if (foo (x) != 1.0) __builtin_abort (); } generates at -O2 after inlining: int main() () { void * D.2385; float D.2383; struct X y; struct X x; float _7; bool retval.0_8; [100.00%]: MEM[(float *)&x] = 1.0e+0; y = x; _7 = MEM[(float &)&y]; ...
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #25 from Uroš Bizjak --- (In reply to Katsunori Kumatani from comment #24) > I think this bug should be reopened because the current behavior is > restricting. [...] I agree. Let's remove this artificial dependency on -msse. Patch in testing: --cut here-- Index: config/i386/i386.c === --- config/i386/i386.c (revision 246531) +++ config/i386/i386.c (working copy) @@ -5927,9 +5927,8 @@ ix86_option_override_internal (bool main_args_p, ix86_preferred_stack_boundary = PREFERRED_STACK_BOUNDARY_DEFAULT; if (opts_set->x_ix86_preferred_stack_boundary_arg) { - int min = (TARGET_64BIT_P (opts->x_ix86_isa_flags) -? (TARGET_SSE_P (opts->x_ix86_isa_flags) ? 4 : 3) : 2); - int max = (TARGET_SEH ? 4 : 12); + int min = TARGET_64BIT_P (opts->x_ix86_isa_flags)? 3 : 2; + int max = TARGET_SEH ? 4 : 12; if (opts->x_ix86_preferred_stack_boundary_arg < min || opts->x_ix86_preferred_stack_boundary_arg > max) --cut here--
[Bug c++/80234] New: ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234 Bug ID: 80234 Summary: ICE in splice_child_die at dwarfout.c:5265 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tim at array dot ca Target Milestone: --- Created attachment 41062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41062&action=edit preprocessed source In the fedora rawhide GCC 7.0.1-0.12 build (x86_64), I'm getting an ICE in the following code when generating debug info: class foo { public: static constexpr const char name_str[] = "foo"; virtual ~foo(); }; constexpr const char foo::name_str[]; foo::~foo() { } % /usr/bin/c++ -g -std=gnu++17 -Wall -Wextra -o /home/tim/tmp/foo.o -c /home/tim/Projects/ugp/src/ugp/UGF/Core/src/component/foo.cc /home/tim/Projects/ugp/src/ugp/UGF/Core/src/component/foo.cc:18:1: internal compiler error: in splice_child_die, at dwarf2out.c:5265 The code snippet is about as minimal as I can get it and still reproduce the error. If I make the destructor non-virtual or get rid of the definition of foo::name_str, the error disappears.
[Bug c++/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-28 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE in splice_child_die at |[7 Regression] ICE in |dwarfout.c:5265 |splice_child_die at ||dwarfout.c:5265 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r241753.
[Bug fortran/80235] New: ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235 Bug ID: 80235 Summary: ICE: coarrays, submodule Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mexas at bristol dot ac.uk Target Milestone: --- Created attachment 41063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41063&action=edit module file $ caf -c m.f90 $ caf -c sm.f90 sm.f90:22:0: maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 ) internal compiler error: Segmentation fault m.f90 - module, sm.f90 - submodule, both attached.
[Bug fortran/80235] ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235 --- Comment #1 from Anton Shterenlikht --- Created attachment 41064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41064&action=edit submodule file
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 Richard Biener changed: What|Removed |Added Known to work||6.3.1 Target Milestone|--- |7.0 Summary|10% performance drop in |[7 Regression] 10% |SciMark2 LU after r242550 |performance drop in ||SciMark2 LU after r242550 --- Comment #12 from Richard Biener --- On more recent trunk -fno-split-paths makes only a tiny difference (4882 vs. 4779 Mflops) while -ftree-loop-if-convert still results in 5432 Mflops. GCC 6 scores 5523 Mflops for me (-O3 -march=native on a Broadwell CPU). Marking as regression.
[Bug fortran/80235] ICE: coarrays, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80235 --- Comment #2 from Anton Shterenlikht --- Can be triggered also with gfortran7 directly: $ gfortran7 -c -fcoarray=lib m.f90 $ gfortran7 -c -fcoarray=lib sm.f90 sm.f90:22:0: maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 ) internal compiler error: Segmentation fault
[Bug c++/80236] New: ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 Bug ID: 80236 Summary: ARM NEON: Crash in std::map Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: d...@dominik-schmidt.de Target Milestone: --- Created attachment 41065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41065&action=edit part 1 of minimal example Hey, we are facing a crash when compiling the attached cpp files with: `arm-oe-linux-gnueabi-g++ -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/build/openembedded_sdk/tmp/sysroots/raspberrypi3 -O0 ../bar.cpp ../main.cpp -o crashTest` The crash only happens with optimizations disabled, it already doesn't happen anymore with `-O1`. Also we could not trigger the faulty behavior in a single file, so this example is really the bare minimum we could find. gcc is installed from openembedded standard repository in version 6.3.0. Full `--version --verbose` output is provided via attachments. We could also reproduce this for another ARM target with GCC 5.4. I'm currently lacking more information on that myself, but I will try to provide it later on. The bt for 6.3 looks like this: (gdb) run Starting program: /tmp/crashTest Program received signal SIGSEGV, Segmentation fault. 0x000121bc in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) () (gdb) bt #0 0x000121bc in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) () #1 0x000120e0 in void std::allocator_traits > > >::construct, std::pair const&>(std::allocator > >&, std::pair*, std::pair const&) () #2 0x00011ffc in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_construct_node const&>(std::_Rb_tree_node >*, std::pair const&) () #3 0x00011df0 in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node const&>(std::pair const&) () #4 0x00011c0c in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node::operator() const&>(std::pair const&) const () #5 0x00011728 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) () #6 0x00010f7c in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_const_iterator >, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) () #7 0x00010c8c in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) () #8 0x00010a90 in std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&) () #9 0x0001227c in main ()
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #1 from Dominik Schmidt --- Created attachment 41066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41066&action=edit part 2 of minimal example: bar.cpp
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #2 from Dominik Schmidt --- Created attachment 41067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41067&action=edit g++ --version --verbose
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #18 from Richard Biener --- (In reply to Thomas Preud'homme from comment #17) > (In reply to rguent...@suse.de from comment #16) > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote: > > > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the patch > > > in > > > comment #13 applied we can still see a difference in the push (one > > > register > > > pushed Vs 0). > > > > I can't reproduce zero pushes here I get three with/without > > -fno-code-hoisting. code hoisting hoists the two loads inside > > the switch before it so we have > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops shows > 2 registers pushed Vs 1 when -fno-code-hoisting is added. Still can't reproduce. I've configured with /space/rguenther/src/svn/gcc-7-branch/configure --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch --enable-languages=c,c++ and am using ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all -funroll-all-loops -fno-code-hoisting seeing 3 pushes: fn1: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 movsr3, #0 push{r4, r5, lr} I see softfp being used, not sure how I could change that (if that's what I'm missing). Btw, -funroll-all-loops disqualifies this testcase ;)
[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Marek Polacek --- In store_init_value, we have decl: a type: const struct A & value: D.2291.p = (void *) &;, (const struct A &) &D.2291; but because type isn't CLASS_TYPE_P, we're not calling replace_placeholders. We cannot just call replace_placeholders, that would crash, because obj has type "const struct A &" whereas *t is "".
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-03-28 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Usually this happens when you return a reference to an automatic variable thus invalidly extend an objects lifetime after destruction. Did you try -fsanitize=address or -fsanitize=undefined?
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #19 from Thomas Preud'homme --- (In reply to Richard Biener from comment #18) > (In reply to Thomas Preud'homme from comment #17) > > (In reply to rguent...@suse.de from comment #16) > > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote: > > > > > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the > > > > patch in > > > > comment #13 applied we can still see a difference in the push (one > > > > register > > > > pushed Vs 0). > > > > > > I can't reproduce zero pushes here I get three with/without > > > -fno-code-hoisting. code hoisting hoists the two loads inside > > > the switch before it so we have > > > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops shows > > 2 registers pushed Vs 1 when -fno-code-hoisting is added. > > Still can't reproduce. I've configured with > > /space/rguenther/src/svn/gcc-7-branch/configure > --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch > --enable-languages=c,c++ > > and am using > > ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I > include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all > -funroll-all-loops -fno-code-hoisting Oh my bad, I was still not clear enough. I meant using the Cortex-M0+ testcase but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you should see a difference between with and without code hoisting.
[Bug debug/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80234 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|c++ |debug
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #20 from Richard Biener --- (In reply to Thomas Preud'homme from comment #19) > (In reply to Richard Biener from comment #18) > > (In reply to Thomas Preud'homme from comment #17) > > > (In reply to rguent...@suse.de from comment #16) > > > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote: > > > > > > > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the > > > > > patch in > > > > > comment #13 applied we can still see a difference in the push (one > > > > > register > > > > > pushed Vs 0). > > > > > > > > I can't reproduce zero pushes here I get three with/without > > > > -fno-code-hoisting. code hoisting hoists the two loads inside > > > > the switch before it so we have > > > > > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops > > > shows > > > 2 registers pushed Vs 1 when -fno-code-hoisting is added. > > > > Still can't reproduce. I've configured with > > > > /space/rguenther/src/svn/gcc-7-branch/configure > > --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch > > --enable-languages=c,c++ > > > > and am using > > > > ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I > > include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all > > -funroll-all-loops -fno-code-hoisting > > Oh my bad, I was still not clear enough. I meant using the Cortex-M0+ > testcase but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you > should see a difference between with and without code hoisting. I do. Two pushes with code hoisting and three without. Changed -mcpu above to -mcpu=cortex-m7.
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 --- Comment #9 from Richard Biener --- Author: rguenth Date: Tue Mar 28 13:57:43 2017 New Revision: 246534 URL: https://gcc.gnu.org/viewcvs?rev=246534&root=gcc&view=rev Log: 2017-03-28 Richard Biener PR tree-optimization/78644 * tree-ssa-ccp.c (evaluate_stmt): When we may not use the value of a simplification result we may not use it at all. * gcc.dg/pr78644-1.c: New testcase. * gcc.dg/pr78644-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr78644-1.c trunk/gcc/testsuite/gcc.dg/pr78644-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug tree-optimization/78542] [6 Regression] wrong code at -Og results in endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78542 Bug 78542 depends on bug 78644, which changed state. Bug 78644 Summary: [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #17 from Andreas Schwab --- Author: schwab Date: Tue Mar 28 14:22:29 2017 New Revision: 246536 URL: https://gcc.gnu.org/viewcvs?rev=246536&root=gcc&view=rev Log: Backport "Support for Ada on aarch64 with -mabi=ilp32" from trunk PR ada/80117 * system-linux-aarch64-ilp32.ads: New file. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename from LIBGNAT_TARGET_PAIRS. (LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define. (LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64 or -mabi=ilp32, resp. Added: branches/gcc-6-branch/gcc/ada/system-linux-aarch64-ilp32.ads Modified: branches/gcc-6-branch/gcc/ada/ChangeLog branches/gcc-6-branch/gcc/ada/gcc-interface/Makefile.in
[Bug target/80225] ICE when using =@cc output operand incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80225 jwjagersma at gmail dot com changed: What|Removed |Added Target|x86_64-w64-mingw32 |x86_64-w64-mingw32, ||i686-w64-mingw32, ||i586-pc-msdosdjgpp --- Comment #1 from jwjagersma at gmail dot com --- I should mention I also reproduced this issue on i686-w64-mingw32 and i586-pc-msdosdjgpp (where I first encountered it). Since the error occurs in a function called "print_reg", I imagine this would be reproducible on any x86/amd64 target, as the flags register doesn't have a printable name.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #4 from Dominik Schmidt --- AddressSanitizer output: = ==597==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7e842bd0 at pc 0x00013d20 bp 0x7e8428dc sp 0x7e8428d4 READ of size 16 at 0x7e842bd0 thread T0 #0 0x13d1f in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) (/tmp/crashTest+0x13d1f) #1 0x13b0f in void std::allocator_traits > > >::construct, std::pair const&>(std::allocator > >&, std::pair*, std::pair const&) (/tmp/crashTest+0x13b0f) #2 0x13a27 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_construct_node const&>(std::_Rb_tree_node >*, std::pair const&) (/tmp/crashTest+0x13a27) #3 0x1381b in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node const&>(std::pair const&) (/tmp/crashTest+0x1381b) #4 0x1352f in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node::operator() const&>(std::pair const&) const (/tmp/crashTest+0x1352f) #5 0x12b23 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) (/tmp/crashTest+0x12b23) #6 0x11953 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_const_iterator >, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) (/tmp/crashTest+0x11953) #7 0x11337 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) (/tmp/crashTest+0x11337) #8 0x110a7 in std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&) (/tmp/crashTest+0x110a7) #9 0x13e87 in main (/tmp/crashTest+0x13e87) #10 0x766cb83f in __libc_start_main (/test/crosscan-test/lib/libc.so.6+0x1683f) Address 0x7e842bd0 is located in stack of thread T0 at offset 112 in frame #0 0x13d8f in main (/tmp/crashTest+0x13d8f) This frame has 2 object(s): [32, 56) 'j1' [96, 120) 'j3' <== Memory access at offset 112 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow (/tmp/crashTest+0x13d1f) in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) Shadow bytes around the buggy address: 0x2fd08520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd08530: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x2fd08540: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x2fd08550: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 0x2fd08560: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 =>0x2fd08570: 00 00 00 f4 f2 f2 f2 f2 00 00[00]f4 f3 f3 f3 f3 0x2fd08580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd08590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd085a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd085b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd085c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==597==ABORTING
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #5 from Dominik Schmidt --- -fsanitize=undefined does not make any difference.
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #6 from Jonathan Wakely --- Are you using the right libstdc++.so that matches the gcc 6.3.0 compiler? What does "ldd /tmp/crashTest" show?
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #7 from Jonathan Wakely --- Also please build with -g so the backtraces and stack info are more useful.
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 --- Comment #5 from jwjagersma at gmail dot com --- Bumping this, I hope it will be resolved someday. I found a reference to the same issue, with another test case using posix signal handlers: https://cygwin.com/ml/cygwin/2010-07/msg00195.html This claims it used to work on 3.3.4, and failed from 4.3.4 on.
[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 --- Comment #11 from Martin Sebor --- That would work too. Yet another possibility is to surround all the dg-message directives that apply to the same line in a pair of new directives (analogously to dg-{begin,end}-multiline-output): foobar; /* { dg-begin-same-line-output .-1 } ... { dg-warning "warning for foobar" } ... { dg-message "note for foobar" } ... { dg-error "error for foobar" } ... { dg-end-same-line-output } */
[Bug tree-optimization/80218] [6/7 Regression] tree-call-cdce does not update block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80218 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Tue Mar 28 15:14:36 2017 New Revision: 246538 URL: https://gcc.gnu.org/viewcvs?rev=246538&root=gcc&view=rev Log: gcc/ PR tree-optimization/80218 * tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): Update block frequencies and counts. gcc/testsuite/ PR tree-optimization/80218 * gcc.dg/pr80218.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr80218.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-call-cdce.c
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 --- Comment #22 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #20) > Also, I assume this is only a problem for -std=c++98 or -std=gnu++98, > because if the system headers don't declare those functions for C++11 and > later dialects then that's a bug in those system headers. That's not true, because we (rather bizarrely) do this: #if _GLIBCXX_HAVE_WCSTOF #undef wcstof #endif namespace std { #if _GLIBCXX_HAVE_WCSTOF using ::wcstof #endif } #if __cplusplus >= 201103L namespace std { #if _GLIBCXX_HAVE_WCSTOF using std::wcstof #endif } #endif This means we unconditionally try to declare them in namespace std, then for C++11 redeclare std::wcstof as std:wcstof (???).
[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 --- Comment #23 from Jonathan Wakely --- Created attachment 41068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41068&action=edit Use dynamic checks for C99 functions This fixes it and passes the testsuite on GNU/Linux and FreeBSD 11.0-RELEASE. Even though this bug is a regression, this is too late in the gcc-7 process to make a change like this. I'll commit it early for gcc-8 and backport it if it doesn't cause any problems.
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #18 from Jerry DeLisle --- (In reply to r...@cebitec.uni-bielefeld.de from comment #17) > > ro@colima 27 > > LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs > ./dtio_26.exe > > > > Program aborted. Backtrace: > Abort I am sorry, I was not being clear. There are four similar lines that need to replace abort with the print. We are invoking the Fortran ABORT procedure when ever a test condition is not met. So I need to see what the condition is saved in the iomsg variable and which line without aborting. So something like this in place of the lines starting at line 57: read(unit=10, fmt='(dt)', iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 57, imsg rewind(10) read(unit=10, fmt=*, iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 60, imsg s = "hello" read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 63, imsg read( unit=s, fmt=*, iostat=istat, iomsg=imsg) foo if (imsg.ne."End of record") print *, 65 end program p
[Bug c/80237] New: float to double conversion is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80237 Bug ID: 80237 Summary: float to double conversion is not optimized away Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- i get suboptimal code for __attribute__((noinline)) static float f(float x) { return x*x; } static double g(float x) { return x>0 ? f(x) : x+1.0; } float foo(float x) { return g(x); } i expected a tail call because for float x, (float)(double)x conversion is a nop, but with -O3 i get f: mulss %xmm0, %xmm0 ret foo: ucomiss .LC0(%rip), %xmm0 jbe .L8 callf / why not tail call? cvtss2sd%xmm0, %xmm0 cvtsd2ss%xmm0, %xmm0 ret .L8: cvtss2sd%xmm0, %xmm0 addsd .LC1(%rip), %xmm0 cvtsd2ss%xmm0, %xmm0 ret .LC0: .long 0 .LC1: .long 0 .long 1072693248
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- Ah, I tried that but not halving the epsilon, and so got a different result that I wasn't happy with. I sugested _RealType(0) because if the analysis at http://stackoverflow.com/a/25669510 is correct then the current code is biased against 0, so using it when we round up to 1.0 would offset that, to a greater or lesser extent. I don't know which :-) I'll go with your suggestion, thanks.
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from Jerry DeLisle --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #17) >> >> ro@colima 27 > >> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs >> ./dtio_26.exe >> >> >> >> Program aborted. Backtrace: >> Abort > > I am sorry, I was not being clear. There are four similar lines that need to > replace abort with the print. We are invoking the Fortran ABORT procedure when > ever a test condition is not met. So I need to see what the condition is saved > in the iomsg variable and which line without aborting. Ah, I see. > So something like this in place of the lines starting at line 57: [...] Here's the output I get: 63 65 Rainer
[Bug target/80211] ICE in curr_insn_transform, at lra-constraints.c:3816
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80211 --- Comment #1 from Vladimir Makarov --- I can not reproduce it. With the mentioned options I have warning: implicit declaration of function '__builtin_dfp_dtstsfi_ov'; did you mean '__builtin_fpclassify`? The option set has no sense for me too. -mpower9-dform-vector implements new load insns for power9 but -mcpu=401 sets up an ancient ppc architecture. They are exclusive options. Even if the bug is reproducable, the PR should be marked as P4, IMHO.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #83 from Jason Merrill --- (In reply to Jonathan Wakely from comment #81) > Boost 1.63 has an array of char. Seems they should change that to unsigned char (or std::byte).
[Bug c++/80236] ARM NEON: Crash in std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 --- Comment #8 from Dominik Schmidt --- -fsanitize=address -g: ==539==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ebcac10 at pc 0x00013d20 bp 0x7ebca90c sp 0x7ebca904 READ of size 16 at 0x7ebcac10 thread T0 #0 0x13d1f in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120 #1 0x13b0f in void std::allocator_traits > > >::construct, std::pair const&>(std::allocator > >&, std::pair*, std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/alloc_traits.h:455 #2 0x13a27 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_construct_node const&>(std::_Rb_tree_node >*, std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:543 #3 0x1381b in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node const&>(std::pair const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:560 #4 0x1352f in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node::operator() const&>(std::pair const&) const /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:473 #5 0x12b23 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:1535 #6 0x11953 in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node>(std::_Rb_tree_const_iterator >, std::pair const&, std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_Alloc_node&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2004 #7 0x11337 in void std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2250 #8 0x110a7 in std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&) /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_map.h:215 #9 0x13e87 in main ../main.cpp:15 #10 0x7670783f in __libc_start_main (/lib/libc.so.6+0x1683f) Address 0x7ebcac10 is located in stack of thread T0 at offset 112 in frame #0 0x13d8f in main ../main.cpp:11 This frame has 2 object(s): [32, 56) 'j1' [96, 120) 'j3' <== Memory access at offset 112 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120 in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&) Shadow bytes around the buggy address: 0x2fd79530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd79540: f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 0x2fd79550: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 0x2fd79560: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd79570: 00 00 00 00 f1 f1 f1 f1 00 00 00 f4 f2 f2 f2 f2 =>0x2fd79580: 00 00[00]f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x2fd79590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x2fd795d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contain
[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80137 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Tue Mar 28 16:09:49 2017 New Revision: 246542 URL: https://gcc.gnu.org/viewcvs?rev=246542&root=gcc&view=rev Log: PR libstdc++/80137 use std::nextafter instead of looping PR libstdc++/80137 * include/bits/random.tcc (generate_canonical): Use std::nextafter or numeric_limits::epsilon() to reduce out-of-range values. * testsuite/26_numerics/random/uniform_real_distribution/operators/ 64351.cc: Verify complexity requirement is met. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc