[Bug c++/61121] -ftree-parallelize-loops=n (n as value) not accepted in 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61121
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek ---
To me the manual looks clear, the documentation uses further
-ftree-parallelize-loops=@var{n} so if you e.g. look at pdf version the n there
is written in different font, and the error message is clear as well.
[Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Fri May 9 08:24:37 2014 New Revision: 210262 URL: http://gcc.gnu.org/viewcvs?rev=210262&root=gcc&view=rev Log: PR c/50459 c-family/ * c-common.c (check_user_alignment): Return -1 if alignment is error node. (handle_aligned_attribute): Don't call default_conversion on FUNCTION_DECLs. (handle_vector_size_attribute): Likewise. (handle_tm_wrap_attribute): Handle case when wrap_decl is error node. (handle_sentinel_attribute): Call default_conversion and allow even integral types as an argument. c/ * c-parser.c (c_parser_attributes): Parse the arguments as an expression-list if the attribute takes identifier. testsuite/ * c-c++-common/attributes-1.c: Move test line to a new test. * c-c++-common/attributes-2.c: New test. * c-c++-common/pr50459.c: New test. * c-c++-common/pr59280.c: Add "undeclared" to dg-error. * gcc.dg/nonnull-2.c: Likewise. * gcc.dg/pr55570.c: Modify dg-error. * gcc.dg/tm/wrap-2.c: Likewise. Added: trunk/gcc/testsuite/c-c++-common/attributes-2.c trunk/gcc/testsuite/c-c++-common/pr50459.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/pr59280.c trunk/gcc/testsuite/gcc.dg/nonnull-2.c trunk/gcc/testsuite/gcc.dg/pr55570.c trunk/gcc/testsuite/gcc.dg/tm/wrap-2.c
[Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 Thomas Preud'homme changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #14 from Thomas Preud'homme --- (In reply to Steven Bosscher from comment #12) > Annotated "bad expansion": > ;; _40 = Arr_2_Par_Ref_22(D) + _12; > 22: r138=r128+r121 > 23: r127=r132+r138 // r127=Arr_2_Par_Ref+r128+r121 > > ;; _32 = _20 + 1000; > 29: r124=r121+1000 > > ;; MEM[(int[25] *)_51 + 20B] = _34; > 32: r141=r132+r124 // r141=Arr_2_Par_Ref+r121+1000 > 33: r142=r141+r128 // r142=Arr_2_Par_Ref+r128+r121+1000 (==r127+1000) > 34: [r142+20]=r126 So in gimple the two offsets are added first and then added to the pointer while after expansion the first offset is added to the pointer and then the second offset. Is it normal that the order of operations seems to change?
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #15 from rguenther at suse dot de --- On Fri, 9 May 2014, thomas.preudhomme at arm dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 > > Thomas Preud'homme changed: > >What|Removed |Added > > CC||thomas.preudhomme at arm dot > com > > --- Comment #14 from Thomas Preud'homme --- > (In reply to Steven Bosscher from comment #12) > > Annotated "bad expansion": > > ;; _40 = Arr_2_Par_Ref_22(D) + _12; > > 22: r138=r128+r121 > > 23: r127=r132+r138 // r127=Arr_2_Par_Ref+r128+r121 > > > > ;; _32 = _20 + 1000; > > 29: r124=r121+1000 > > > > ;; MEM[(int[25] *)_51 + 20B] = _34; > > 32: r141=r132+r124 // r141=Arr_2_Par_Ref+r121+1000 > > 33: r142=r141+r128 // r142=Arr_2_Par_Ref+r128+r121+1000 (==r127+1000) > > 34: [r142+20]=r126 > > So in gimple the two offsets are added first and then added to the pointer > while after expansion the first offset is added to the pointer and then the > second offset. Is it normal that the order of operations seems to change? Yes, that's TER at work
[Bug other/61124] New: GCC manual has 68HC11/68HC12 info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61124 Bug ID: 61124 Summary: GCC manual has 68HC11/68HC12 info Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: john.s.kallal at gmail dot com Bug description: In the GCC version 4.8.3 manual pages 379, and 389 (PDF file version) talks about the 68HC11/68HC12 micro-controllers. This support for the 68HC11/68HC12 micro-controllers was declared obsolete in GCC v4.6.
[Bug tree-optimization/43491] Unnecessary temporary for global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- As said, the fix in comment #6 isn't really effective and I intend to basically revert it. But I'd like to have guidance on what transforms people think are ok for global register vars - esp. what is "true redundancy elimination"? Any redundancy elimination can cause the extension of the lifetime of the temporaries we create and thus increase register pressure. Ideally we'd treat global register variables by rewriting them into SSA form but avoiding overlapping life ranges. At the moment we get those extra "temporaries" by means of gimple restrictions which see global register vars as memory. Note that you can reliably prevent any "disturbing" transforms of global register vars by declaring them volatile. I suppose the real issue is that GCC inserts/moves sets of the global register variable. CSE across function calls could be easily inhibited as well.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #46 from Dmitry Vyukov --- Roland, why do you think that what you see is false positives? I think these are real, potentially harmful, races. Please test with gcc 4.9, and file bugs if you still see any races.
[Bug c++/61122] "too many initializers" for NSDMI for array of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61122 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 Summary|too many initializers |"too many initializers" for ||NSDMI for array of unknown ||bound Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I don't think you can specify an array bound from an NSDMI, but the diagnostic is not very helpful.
[Bug c++/61122] "too many initializers" for NSDMI for array of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61122 --- Comment #2 from Frank Heckenbach --- If it's not allowed, it should also fail at file-scope or function-scope, shouldn't it?
[Bug c++/61125] New: static_cast of null pointer return invalid pointer (not null)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61125 Bug ID: 61125 Summary: static_cast of null pointer return invalid pointer (not null) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: slorents at gmail dot com Created attachment 32766 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32766&action=edit Bug example The standard indicates that if a null pointer value is being cast that the result will be a null pointer value (5.2.9/8 Static cast). See attachment. gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 64 bit Output: hook = 7fffe504obj = 7fffe500 right=7fffe500 hook = obj = fffc right= MyObj *obj = static_cast(hook) Expected instead fffc.
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Before tunks we never bothered to compute [tailcall] before inlining completed, but now explicitely setting the flag for thunks (and not letting it be computed - why wouldn't that work?) breaks this. So not setting the flag explicitely in expand_thunk looks like a better fix to me?
[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- > Note how the load at insn 28 is guarded by comparing ax against #2837. CE3 > transforms that into an unconditional load and we blow up reading the > out-of-range stack slot. > > This isn't a threading issue, but a latent bug in CE as far as I can tell. Right, see PR rtl-optimization/60452 for an earlier example. IMO a pretty useless series of artificial testcases...
[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123 Richard Biener changed: What|Removed |Added Keywords||lto --- Comment #1 from Richard Biener --- All ABI changing options should be also enabled for LTO and they also deserve handling in lto-opts.c (always stream, not only if explicitely set) and lto-wrapper.c (diagnose mismatches and force a setting for the link stage). At least enabling them for LTO is minimally required, like you suggest.
[Bug driver/61120] wide-int merge causes segfault in cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61120 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 6 ***
[Bug middle-end/61111] [4.10 regression] Infinite recursion between fold_build2_stat_loc and fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Richard Biener changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #7 from Richard Biener --- *** Bug 61120 has been marked as a duplicate of this bug. ***
[Bug c++/61122] "too many initializers" for NSDMI for array of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61122
--- Comment #3 from Jonathan Wakely ---
No. At file or function scope the initializer is definitely used, and can
provide the array bound. On a non-static data member it is not used until the
object is constructed (and then might be ignored if there's a mem-initializer
for the member) and that's too late, the array bound for non-static data
members must be known at class definition time to know sizeof(s).
That's my understanding, and I've just checked clang agrees, with a better
diagnostic:
in.cc:10:26: error: array bound cannot be deduced from an in-class initializer
std::vector b1[] { { } };
^
in.cc:11:26: error: array bound cannot be deduced from an in-class initializer
std::vector b2[] { { 1, 2, 3 } };
^
in.cc:12:26: error: array bound cannot be deduced from an in-class initializer
std::vector b3[] { std::vector () };
^
in.cc:13:26: error: array bound cannot be deduced from an in-class initializer
std::vector b4[] { std::vector (1) };
^
4 errors generated.
[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119 --- Comment #4 from Richard Biener --- Tricky case, but fold also handles REALPART / IMAGPART of +, - and conjugate and of a cexpi call. Of course that may not matter in the end, as "easily decompose" probably doesn't apply to those simplifications (as shown here).
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I think that you simply have a wrong idea of how vectors work. Vectors in GENERIC/GIMPLE don't have an "endianess" dependent element order. That we mis-use BIT_FIELD_REF for vector extraction may confuse you here.
[Bug target/61055] [avr] wrong test instruction after increment with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61055 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Fri May 9 11:20:43 2014 New Revision: 210267 URL: http://gcc.gnu.org/viewcvs?rev=210267&root=gcc&view=rev Log: gcc/config/avr PR target/61055 * config/avr/avr.md (cc): Add new attribute set_vzn. (addqi3, addqq3, adduqq3, subqi3, subqq3, subuqq3, negqi2) [cc]: Set cc insn attribute to set_vzn instead of set_zn for alternatives with INC, DEC or NEG. * config/avr/avr.c (avr_notice_update_cc): Handle SET_VZN. (avr_out_plus_1): ADIW sets cc0 to CC_SET_CZN. INC, DEC and ADD+ADC set cc0 to CC_CLOBBER. gcc/testsuite/ PR target/61055 * gcc.target/avr/torture/pr61055.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr61055.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug target/61055] [avr] wrong test instruction after increment with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61055 --- Comment #3 from Georg-Johann Lay --- Author: gjl Date: Fri May 9 11:25:11 2014 New Revision: 210268 URL: http://gcc.gnu.org/viewcvs?rev=210268&root=gcc&view=rev Log: gcc/config/avr Backport from 2014-05-09 trunk r210267 PR target/61055 * config/avr/avr.md (cc): Add new attribute set_vzn. (addqi3, addqq3, adduqq3, subqi3, subqq3, subuqq3, negqi2) [cc]: Set cc insn attribute to set_vzn instead of set_zn for alternatives with INC, DEC or NEG. * config/avr/avr.c (avr_notice_update_cc): Handle SET_VZN. (avr_out_plus_1): ADIW sets cc0 to CC_SET_CZN. INC, DEC and ADD+ADC set cc0 to CC_CLOBBER. gcc/testsuite/ Backport from 2014-05-09 trunk r210267 PR target/61055 * gcc.target/avr/torture/pr61055.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/torture/pr61055.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr.c branches/gcc-4_9-branch/gcc/config/avr/avr.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/61111] [4.10 regression] Infinite recursion between fold_build2_stat_loc and fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Kenneth Zadeck changed: What|Removed |Added CC||zadeck at naturalbridge dot com --- Comment #8 from Kenneth Zadeck --- Created attachment 32767 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32767&action=edit patch to fix. I agree with richi that the mask should have been w bits wide. I test the patch on x86_64 last night and it causes no harm. ok to commit?
[Bug target/61055] [avr] wrong test instruction after increment with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61055 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Fri May 9 11:29:58 2014 New Revision: 210269 URL: http://gcc.gnu.org/viewcvs?rev=210269&root=gcc&view=rev Log: gcc/ Backport from 2014-05-09 trunk r210267 PR target/61055 * config/avr/avr.md (cc): Add new attribute set_vzn. (addqi3, addqq3, adduqq3, subqi3, subqq3, subuqq3, negqi2) [cc]: Set cc insn attribute to set_vzn instead of set_zn for alternatives with INC, DEC or NEG. * config/avr/avr.c (avr_notice_update_cc): Handle SET_VZN. (avr_out_plus_1): ADIW sets cc0 to CC_SET_CZN. INC, DEC and ADD+ADC set cc0 to CC_CLOBBER. gcc/testsuite/ Backport from 2014-05-09 trunk r210267 PR target/61055 * gcc.target/avr/torture/pr61055.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/avr/torture/pr61055.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/avr/avr.c branches/gcc-4_8-branch/gcc/config/avr/avr.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/61111] [4.10 regression] Infinite recursion between fold_build2_stat_loc and fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #9 from rguenther at suse dot de --- On Fri, 9 May 2014, zadeck at naturalbridge dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 > > Kenneth Zadeck changed: > >What|Removed |Added > > CC||zadeck at naturalbridge dot > com > > --- Comment #8 from Kenneth Zadeck --- > Created attachment 32767 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32767&action=edit > patch to fix. > > I agree with richi that the mask should have been w bits wide. > I test the patch on x86_64 last night and it causes no harm. > > ok to commit? Ok.
[Bug target/61055] [avr] wrong test instruction after increment with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61055 --- Comment #5 from Georg-Johann Lay --- Author: gjl Date: Fri May 9 11:34:46 2014 New Revision: 210270 URL: http://gcc.gnu.org/viewcvs?rev=210270&root=gcc&view=rev Log: gcc/ Backport from 2014-05-09 trunk r210267 PR target/61055 * config/avr/avr.md (cc): Add new attribute set_vzn. (addqi3, negqi2) [cc]: Set cc insn attribute to set_vzn instead of set_zn for alternatives with INC, DEC or NEG. * config/avr/avr.c (avr_notice_update_cc): Handle SET_VZN. (avr_out_plus_1): ADIW sets cc0 to CC_SET_CZN. INC, DEC set cc0 to CC_CLOBBER. gcc/testsuite/ Backport from 2014-05-09 trunk r210267 PR target/61055 * gcc.target/avr/torture/pr61055.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.target/avr/torture/pr61055.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr.c branches/gcc-4_7-branch/gcc/config/avr/avr.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/61055] [avr] wrong test instruction after increment with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61055 Georg-Johann Lay changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED Known to work||4.7.4, 4.8.3, 4.9.1 Resolution|--- |FIXED Target Milestone|--- |4.9.1 Known to fail||4.7.3, 4.8.2, 4.9.0 --- Comment #6 from Georg-Johann Lay --- Fixed in 4.7.4, 4.8.3, 4.9.1 and trunk.
[Bug middle-end/61111] [4.10 regression] Infinite recursion between fold_build2_stat_loc and fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #10 from zadeck at gcc dot gnu.org --- Author: zadeck Date: Fri May 9 12:21:23 2014 New Revision: 210274 URL: http://gcc.gnu.org/viewcvs?rev=210274&root=gcc&view=rev Log: 2014-05-06 Kenneth Zadeck PR middle-end/6 * fold-const.c (fold_binary_loc): Changed width of mask. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #3 from Tejas Belagod ---
Thanks for the clarification. In that case, what element does bit positions
96..127 correspond to in { 120, 0, 0, 0 }?
[Bug middle-end/61111] [4.10 regression] Infinite recursion between fold_build2_stat_loc and fold_binary_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Kenneth Zadeck changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Kenneth Zadeck --- Patch committed.
[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119 --- Comment #5 from Marc Glisse --- (In reply to Richard Biener from comment #4) > Tricky case, but fold also handles REALPART / IMAGPART of +, - and conjugate > and of a cexpi call. Of course that may not matter in the end, as > "easily decompose" probably doesn't apply to those simplifications (as shown > here). That was my point. Replacing cexp with exp*expi does not gain anything in itself, the hope is that either exp or expi gets further simplifications (possibly because it is a constant). In most (of the rare) cases where the folding of realpart of + helps, we probably missed an optimization where we could have folded + to something better (likely a complex_expr in the end). Anyway, except possibly for the constant folding, the transformation should eventually move to gimple-only where there won't be those save_expr issues.
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #4 from rguenther at suse dot de ---
On Fri, 9 May 2014, belagod at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
>
> --- Comment #3 from Tejas Belagod ---
> Thanks for the clarification. In that case, what element does bit positions
> 96..127 correspond to in { 120, 0, 0, 0 }?
The last 0
[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119 --- Comment #6 from rguenther at suse dot de --- On Fri, 9 May 2014, glisse at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119 > > --- Comment #5 from Marc Glisse --- > (In reply to Richard Biener from comment #4) > > Tricky case, but fold also handles REALPART / IMAGPART of +, - and conjugate > > and of a cexpi call. Of course that may not matter in the end, as > > "easily decompose" probably doesn't apply to those simplifications (as shown > > here). > > That was my point. Replacing cexp with exp*expi does not gain anything in > itself, the hope is that either exp or expi gets further simplifications > (possibly because it is a constant). In most (of the rare) cases where the > folding of realpart of + helps, we probably missed an optimization where we > could have folded + to something better (likely a complex_expr in the end). > > Anyway, except possibly for the constant folding, the transformation should > eventually move to gimple-only where there won't be those save_expr issues. Of course.
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #5 from Tejas Belagod ---
So, does that mean the folded value 120 is in the wrong place? The fix that I'm
testing swaps the first and last elements of the const vector {120, 0, 0, 0}.
PS: Sorry, my statement "The final folded value is extracted from the LSB which
are bits 32:96 on BE systems" should have read "The final folded value is
extracted from the LSB which are bits 96..127 on BE systems" if that caused
confusion.
[Bug fortran/61126] New: gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Bug ID: 61126 Summary: gfortran does not enable -Wununused-parameter with -Wextra Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fweimer at redhat dot com The gfortran.dg/wextra_1.f test case assumes that -Wextra enables -Wununused-parameter, but this does not happen. No warning is printed on line 4, leading to a test failure.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
Senthil Kumar Selvaraj changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
||l.com
--- Comment #2 from Senthil Kumar Selvaraj ---
Here's a simplified dejagnu testcase.
/* { dg-do run } */
/* { dg-options "-O1" } */
/* This testcase (simplified from the original bug report) exposes
PR60991. The code generated for writing the __int24 value corrupts
the frame pointer if the offset is <= 63 + MAX_LD_OFFSET */
#include
int main(void)
{
volatile char junk[62];
junk[0] = 5;
volatile __int24 staticConfig = 0;
if (junk[0] != 5)
abort();
exit(0);
return 0;
}
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #6 from Richard Biener ---
(In reply to Tejas Belagod from comment #5)
> So, does that mean the folded value 120 is in the wrong place? The fix that
> I'm testing swaps the first and last elements of the const vector {120, 0,
> 0, 0}.
>
> PS: Sorry, my statement "The final folded value is extracted from the LSB
> which are bits 32:96 on BE systems" should have read "The final folded value
> is extracted from the LSB which are bits 96..127 on BE systems" if that
> caused confusion.
But that's the bug. The final value should _always_ be extracted from
0..31. That is, the folding is perfectly ok given the description of
REDUC_PLUS_EXPR.
So - it looks like the target does something wrong for expansion of
REDUC_PLUS_EXPR.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
--- Comment #3 from Senthil Kumar Selvaraj ---
The OP's suspicion/analysis was right. Here's a "trivial" patch that fixes the
problem.
diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c
index 2edc78a..e96691e 100644
--- gcc/config/avr/avr.c
+++ gcc/config/avr/avr.c
@@ -3993,7 +3993,7 @@ avr_out_store_psi (rtx insn, rtx *op, int *plen)
"std Y+61,%A1"CR_TAB
"std Y+62,%B1"CR_TAB
"std Y+63,%C1"CR_TAB
-"sbiw r28,%o0-60", op, plen, -5);
+"sbiw r28,%o0-61", op, plen, -5);
return avr_asm_len ("subi r28,lo8(-%o0)" CR_TAB
"sbci r29,hi8(-%o0)" CR_TAB
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> (In reply to Tejas Belagod from comment #5)
> > So, does that mean the folded value 120 is in the wrong place? The fix that
> > I'm testing swaps the first and last elements of the const vector {120, 0,
> > 0, 0}.
> >
> > PS: Sorry, my statement "The final folded value is extracted from the LSB
> > which are bits 32:96 on BE systems" should have read "The final folded value
> > is extracted from the LSB which are bits 96..127 on BE systems" if that
> > caused confusion.
>
> But that's the bug. The final value should _always_ be extracted from
> 0..31. That is, the folding is perfectly ok given the description of
> REDUC_PLUS_EXPR.
>
> So - it looks like the target does something wrong for expansion of
> REDUC_PLUS_EXPR.
That is, all code conditional on BYTES/WORDS_BIG_ENDIAN in tree-vect* is
suspicious.
[Bug ada/61127] New: GNAT incorrectly accepts <> as a second association of a generic formal package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61127 Bug ID: 61127 Summary: GNAT incorrectly accepts <> as a second association of a generic formal package Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: georggcc at googlemail dot com Assuming that in generic associations, a box needs to have "others =>" before it unless it is the sole item, GNAT should reject: with Ada.Containers.Vectors; generic with package G is new Ada.Containers.Vectors (Natural, Positive, <>); package Gen_Pak is end Gen_Pak; $ gnatmake -gnatwa -gnatg gen_pak.ads gcc -c -gnatwa gen_pak.ads $ gcc -v COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/Volumes/Macintosh\ HD/Users/bauhaus/4.9/bin/../libexec/gcc/x86_64-apple-darwin13.1.0/4.9.0/lto-wrapper Target: x86_64-apple-darwin13.1.0 Configured with: /Macintosh_HD/Users/bauhaus/src/GCC-trunk/configure --prefix=/Macintosh_HD/Users/bauhaus/4.9 --disable-nls --enable-languages=c,ada,c++ CC=gcc Thread model: posix gcc version 4.9.0 20140331 (experimental) (GCC)
[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #2 from Richard Biener --- Created attachment 32768 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32768&action=edit partly reduced I stopped reducing, it's very slow (because compiling the testcase is so slow). Attached what I have sofar.
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 CC||doko at cs dot tu-berlin.de Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Likely caused by r210246 (see http://gcc.gnu.org/ml/gcc-regression/2014-05/msg00091.html).
[Bug fortran/61115] ICE with generic type bound proc => non_overridable type bound proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61115 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.7.4. 'fortran/class.c:236' is gcc_assert((*tail)->u.c.component);
[Bug fortran/61109] [4.10 Regression] ICE in fortran/trans-array.c on dimension 0 arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61109 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 CC||mikestump at comcast dot net Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- r210042 (2014-05-03) is OK, r210124 (2014-05-06) gives the ICE. Wide-int (r210113) fallout: gcc_assert (wtmp != 0);
[Bug c++/58614] [c++11] ICE with undeclared variable in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58614 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-09 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug fortran/61073] -fcheck='do' leads to twice the amount of GDB steps in a do loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61073 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I can reproduce it on x86_64-apple-darwin13 with gdb, but not with lldb, for 4.8.3, but not with 4.9.0 nor trunk (4.10.0).
[Bug fortran/61028] [4.9/4.10 Regression] -g3 -g leads to spurious warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- r205111 is OK, r205305 gives the spurious warnings. I remember some posts about the order of -gx -gy, but cannot find it right now.
[Bug fortran/60953] configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60953 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-05-09 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Any progress?
[Bug fortran/61109] [4.10 Regression] ICE in fortran/trans-array.c on dimension 0 arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61109 --- Comment #2 from mrs at gcc dot gnu.org --- Author: mrs Date: Fri May 9 14:06:15 2014 New Revision: 210277 URL: http://gcc.gnu.org/viewcvs?rev=210277&root=gcc&view=rev Log: PR fortran/61109 * trans-array.c (gfc_conv_array_initializer): Fix wide-int conversion bug. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c
[Bug fortran/61109] [4.10 Regression] ICE in fortran/trans-array.c on dimension 0 arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61109 mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from mrs at gcc dot gnu.org --- Fixed.
[Bug target/61128] New: [cr16] Incorrect code generated for udivmodsi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61128 Bug ID: 61128 Summary: [cr16] Incorrect code generated for udivmodsi4 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stefan at astylos dot dk Target: cr16 Created attachment 32769 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32769&action=edit Preprocessed source When a cr16 crosscompiler builds gcc, the return sequence of udivmodsi4 looks like this: ... movwr2, r0 movwr3, r1 cmpw$0, r6 bne .L10 movwra, r0 movwra, r1 .L10: pop $1, r7 popret ra The last two movw instructions tries to move the 32 bits in ra to the pair of 16 bit registers r0 and r1, but this will only move the low order 16 bits to both of them. This should probably be a 'movd (ra),(r1,r0)' instruction instead. This is in 4.8, 4.9 and current trunk. Configuration options: --target=cr16-none-elf --enable-languages=c --without-headers --disable-libssp
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973 --- Comment #5 from Jan Hubicka --- > Before tunks we never bothered to compute [tailcall] before inlining > completed, but now explicitely setting the flag for thunks (and not letting > it be computed - why wouldn't that work?) breaks this. > > So not setting the flag explicitely in expand_thunk looks like a better fix > to me? We always had this explicit set of tailcall in thunk expansion code - originally in C++ frontend and at early LTO times I just literaly moved it to cgraphunit. This patch http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01035.html makes it possible that tunks are inlined since we lower them to gimple bodies early and it is why things breaks now as inliner does not expect it. My initial reaction (written in previously comment) was also that tailcall should discover the flags themself and we could avoid setting them in the thunk expansion. Sadly I think it is not quite the case; tailcall is very conservative and I believe it will give up in cases where thunks are possible. Also it is not run at -O0 and for thunks we want the tailcall to happen since it only improves debugging exprience and saves codegen time... So I would probably say we should fix that in tree-inline as your patch propose.
[Bug target/61099] Mac 2GB file limit error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61099 Dominique d'Humieres changed: What|Removed |Added Target||*-apple-darwin* Component|fortran |target Known to work||4.5.0 --- Comment #5 from Dominique d'Humieres --- zerofill has been introduced at r167242 and AFACT is darwin specific.
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #19 from Jan Hubicka --- What seems to go wrong is that we try to analyze builtin_unreachable size/time that should not happen. It would help to know the dump_cgraph_node of the node of builtin_unreachable (or have full cgraph dump). I will try to reproduce it at the gcc farm, probably after my arrival back to calgary, at 13th of May.
[Bug target/61099] Mac 2GB file limit error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61099 --- Comment #6 from Barry McInnes --- Is there any documentation on the arguments -Wa,-q ? With a link from Macports to /usr/bin/clang one program works without -Wa,-q, but others still need those parameters to get rid of the zero fill error.
[Bug target/61092] [4.10 Regression]: wide-int merge broke alpha bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61092 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Fri May 9 15:02:09 2014 New Revision: 210278 URL: http://gcc.gnu.org/viewcvs?rev=210278&root=gcc&view=rev Log: Backport from mainline 2014-05-08 Uros Bizjak PR target/61092 * config/alpha/alpha.c: Include gimple-iterator.h. (alpha_gimple_fold_builtin): New function. Move ALPHA_BUILTIN_UMULH folding from ... (alpha_fold_builtin): ... here. (TARGET_GIMPLE_FOLD_BUILTIN): New define. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/alpha/alpha.c
[Bug target/61092] [4.10 Regression]: wide-int merge broke alpha bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61092 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.1 --- Comment #11 from Uroš Bizjak --- Fixed.
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org, ||manu at gcc dot gnu.org --- Comment #2 from Matthias Klose --- -Wunused-parameter is enabled by -Wall. I'm surprised that -Wextra is used without -Wall, but it happens in the testsuite in more places.
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #3 from Florian Weimer ---
(In reply to Matthias Klose from comment #2)
> -Wunused-parameter is enabled by -Wall. I'm surprised that -Wextra is used
> without -Wall, but it happens in the testsuite in more places.
This is not what the documentation says:
@item -Wextra
@opindex @code{Wextra}
@cindex extra warnings
@cindex warnings, extra
Enables some warning options for usages of language features which
may be problematic. This currently includes @option{-Wcompare-reals}
and @option{-Wunused-parameter}.
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to Matthias Klose from comment #2) > -Wunused-parameter is enabled by -Wall. No, according to the manual it isn't. I think one reason for confusion is the naming of things in the different languages. Named constants are called in Fortran "PARAMETER" and the thing you pass to a procedure (function, subroutine) are called "(actual) arguments" - those get associated with "dummy arguments"/"formal arguments". In C, you call arguments "parameters". Thus, taking about "parameter" is highly confusing. I think it neither really fits to named constants nor to arguments, but since languages have chosen the term ... From the gfortran man page: "-Wunused-parameter Contrary to gcc’s meaning of -Wunused-parameter, gfortran’s implementation of this option does not warn about unused dummy arguments (see -Wunused-dummy-argument), but about unused "PARAMETER" values. -Wunused-parameter is not included in -Wall but is implied by -Wall -Wextra."
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #5 from Matthias Klose --- "-Wunused-parameter is not included in -Wall but is implied by -Wall -Wextra" would mean that the test case assumes that it it is implied by -Wextra only.
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #20 from David Edelsohn --- (gdb) print debug_cgraph_node(node) __builtin_unreachable/1630 (void __builtin_unreachable()) @700099c0 Type: function Visibility: external public visibility_specified artificial References: Referring: Availability: not_available First run: 0 Function flags: Called by: _ZN10vec_prefix20calculate_allocationEPS_jb/554 (can throw external) Calls: $1 = 10
[Bug target/61099] Mac 2GB file limit error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61099 --- Comment #7 from Dominique d'Humieres --- > Is there any documentation on the arguments -Wa,-q ? -Wa,* is documented somewhere in the manual as the way to tell the assembler to use the option *. AFAIR 'as -q' is documented (otherwise I won't have guessed it), but I don't have a pointer. Note that another workaround is to make the array allocatable.
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #21 from David Edelsohn --- Created attachment 32770 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32770&action=edit full cgraph dump gzipped
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #6 from Tobias Burnus --- (In reply to Florian Weimer from comment #3) > (In reply to Matthias Klose from comment #2) > > -Wunused-parameter is enabled by -Wall. I'm surprised that -Wextra is used > > without -Wall, but it happens in the testsuite in more places. Actually, looking at gcc/common.opt, one finds: Wunused-parameter Common Var(warn_unused_parameter) Warning EnabledBy(Wunused && Wextra) Thus, in GCC - whether Fortran or C - it is enabled with -Wextra, but only if also -Wunused is used. The latter is implied by -Wall.
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #7 from Manuel López-Ibáñez --- (In reply to Florian Weimer from comment #0) > The gfortran.dg/wextra_1.f test case assumes that -Wextra enables > -Wununused-parameter, but this does not happen. No warning is printed on > line 4, leading to a test failure. I don't understand how it was working before. What is exactly the command-line passed to that testcase?
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Tobias Burnus from comment #6) > Thus, in GCC - whether Fortran or C - it is enabled with -Wextra, but only > if also -Wunused is used. The latter is implied by -Wall. This is not necessarily true for gfortran, since it doesn't use the common options machinery and it fiddles with the options directly. I'm not sure if this is the case or not for this particular option, but it could be a possibility (one more reason to move gfortran to use the common machinery).
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #9 from Matthias Klose --- Am 09.05.2014 18:02, schrieb manu at gcc dot gnu.org: > I don't understand how it was working before. What is exactly the > command-line passed to that testcase? the test passes just -Wextra, adding either a -Wunused or a -Wall lets the warning re-appear.
[Bug debug/53927] wrong value for DW_AT_static_link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #11 from Eric Botcazou --- > OK, I'm attaching the patchlet. I can submit it when stage #1 opens. I obviously missed one stage #1, but this is now done: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00573.html
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #10 from Manuel López-Ibáñez --- (In reply to Manuel López-Ibáñez from comment #7) > (In reply to Florian Weimer from comment #0) > > The gfortran.dg/wextra_1.f test case assumes that -Wextra enables > > -Wununused-parameter, but this does not happen. No warning is printed on > > line 4, leading to a test failure. > > I don't understand how it was working before. What is exactly the > command-line passed to that testcase? I think in Fortran, -Wextra just generates -Wunused-parameter because of this: Index: options.c === --- options.c (revision 209347) +++ options.c (working copy) @@ -672,16 +672,11 @@ gfc_handle_option (size_t scode, const c case OPT_Wconversion_extra: gfc_option.warn_conversion_extra = value; break; case OPT_Wextra: - handle_generated_option (&global_options, &global_options_set, - OPT_Wunused_parameter, NULL, value, - gfc_option_lang_mask (), kind, loc, - handlers, global_dc); set_Wextra (value); - break; case OPT_Wfunction_elimination: gfc_option.warn_function_elimination = value; break; If you want to have the same behavior in Fortran as in the rest of GCC, then delete the above. The above was enabling -Wunused-parameter just with -Wextra (only in Fortran), and because of the existing bug fixed by r210246, this was never overriden by the general machinery.
[Bug bootstrap/57494] [4.9 regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57494 YaoZhenGuo changed: What|Removed |Added CC||yaozhen_guo at yahoo dot com --- Comment #3 from YaoZhenGuo --- (In reply to Richard Biener from comment #2) > patch was reverted. Where can get the patch?
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
--- Comment #2 from npl at chello dot at ---
I cant easily make a simple reproducible testcase as this is a custom realtime
OS for a very specific CPU. And I can only test this example next week at work
where I have hardware to run it.
And I certainly wasnt talking about debugging with gdb (which uses some rather
advanced heuristics AFAIK), but the library funtions within libgcc (unwind.h
header). I reworked your example to show the issue:
#include
#include
_Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
{
void *ip = (void *)_Unwind_GetIP(context);
/* I have a check here to test if the ip is the same as last time, else this
would be called endlessly */
std::cout << "Address: " << ip << std::endl;
return _URC_NO_REASON;
}
void bar()
{
std::cout << "This is in bar" << std::endl;
_Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, nullptr);
}
void foo() noexcept
{
bar();
}
int main()
{
foo();
return 0;
}
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #11 from Manuel López-Ibáñez --- Note that the above code is broken in other ways: -Wno-unused-parameter -Wextra will enable -Wunused-parameter, which is not what should happen.
[Bug tree-optimization/61009] [4.9 Regression] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #12 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Fri May 9 16:59:56 2014 New Revision: 210279 URL: http://gcc.gnu.org/viewcvs?rev=210279&root=gcc&view=rev Log: Backport r210254 from trunk for Google b/14380607. 2014-05-08 Jeff Law PR tree-optimization/61009 * tree-ssa-threadedge.c (thread_through_normal_block): Return a tri-state rather than a boolean. When a block is too big to thread through, inform caller via negative return value. (thread_across_edge): If a block was too big for normal threading, then it's too big for a joiner too, so remove temporary equivalences and return immediately. PR tree-optimization/61009 * g++.dg/tree-ssa/pr61009.C: New test. Added: branches/google/gcc-4_9/gcc/testsuite/g++.dg/tree-ssa/pr61009.C Modified: branches/google/gcc-4_9/gcc/tree-ssa-threadedge.c
[Bug tree-optimization/61009] [4.9 Regression] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #13 from Teresa Johnson --- Jeff, Thanks for the fix! Confirming that it does indeed fix the application issues we hit. Teresa On Thu, May 8, 2014 at 9:54 PM, law at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 > > --- Comment #11 from Jeffrey A. Law --- > Author: law > Date: Fri May 9 04:54:00 2014 > New Revision: 210254 > > URL: http://gcc.gnu.org/viewcvs?rev=210254&root=gcc&view=rev > Log: > 2014-05-08 Jeff Law > > PR tree-optimization/61009 > * tree-ssa-threadedge.c (thread_through_normal_block): Return a > tri-state rather than a boolean. When a block is too big to > thread through, inform caller via negative return value. > (thread_across_edge): If a block was too big for normal threading, > then it's too big for a joiner too, so remove temporary equivalences > and return immediately. > > PR tree-optimization/61009 > * g++.dg/tree-ssa/pr61009.C: New test. > > Added: > trunk/gcc/testsuite/g++.dg/tree-ssa/pr61009.C > Modified: > trunk/gcc/ChangeLog > trunk/gcc/testsuite/ChangeLog > trunk/gcc/tree-ssa-threadedge.c > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/61009] [4.9 Regression] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #14 from Paul Pluzhnikov --- (In reply to Teresa Johnson from comment #13) > Thanks for the fix! Indeed. > Confirming that it does indeed fix the application > issues we hit. I will add that we've had at least two separate miscompile instances due to this bug, resulting in several thousand of our unit test failing. Back-porting this to gcc-4_9-branch should be a relatively high priority.
[Bug tree-optimization/61009] [4.9 Regression] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #15 from Jeffrey A. Law --- Paul, it is. I'd be surprised if both threading fixes aren't in by Monday.
[Bug c/61096] error_init lacks a location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61096 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri May 9 17:50:25 2014 New Revision: 210280 URL: http://gcc.gnu.org/viewcvs?rev=210280&root=gcc&view=rev Log: PR c/61096 * c-parser.c (c_parser_braced_init): Pass brace_loc to push_init_level. (c_parser_initelt): Pass location to set_init_label. Pass array index location to set_init_index. * c-tree.h (push_init_level): Update declaration. (pop_init_level): Likewise. (set_init_index): Likewise. (set_init_label): Likewise. * c-typeck.c (error_init): Add location parameter. Call error_at instead of error. (digest_init): Pass init_loc to error_init. (really_start_incremental_init): (push_init_level): Add location parameter. Pass loc to pop_init_level and error_init. (pop_init_level): Likewise. (set_designator): Add location parameter. Pass loc to pop_init_level, push_init_level, and error_init. (set_init_index): Add location parameter. Pass loc to error_init and set_designator. (set_init_label): Likewise. (output_init_element): Pass loc to error_init. (process_init_element): Pass loc to error_init, pop_init_level, pedwarn_init, and push_init_level. * gcc.dg/pr61096-1.c: New test. * gcc.dg/pr61096-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61096-1.c trunk/gcc/testsuite/gcc.dg/pr61096-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/61096] error_init lacks a location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61096 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c/61129] New: Feature request: integer-overflow-detecting arithmetic intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61129 Bug ID: 61129 Summary: Feature request: integer-overflow-detecting arithmetic intrinsics Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: luto at mit dot edu Clang has a fairly complete family of intrinsics to do integer arithmetic with overflow detection. They include function like __builtin_uadd_overflow, and they are described here: http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins Please consider supporting these in GCC as well.
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60019 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri May 9 18:16:11 2014 New Revision: 210284 URL: http://gcc.gnu.org/viewcvs?rev=210284&root=gcc&view=rev Log: DR 5 PR c++/60019 * call.c (build_user_type_conversion_1): The copy-init temporary is cv-unqualified. Added: trunk/gcc/testsuite/g++.dg/init/copy7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/51317] [C++0x] [DR 587] Wrong value category of conditional expression where lvalue operands differ only in cv-qualification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51317 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri May 9 18:16:18 2014 New Revision: 210285 URL: http://gcc.gnu.org/viewcvs?rev=210285&root=gcc&view=rev Log: DR 587 PR c++/51317 * call.c (build_conditional_expr_1, conditional_conversion): Handle non-class lvalues and xvalues that differ only in cv-qualifiers. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-cond2.C trunk/gcc/testsuite/g++.dg/expr/cond14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/warn/return-reference.C
[Bug c++/58714] Bogus overload resolution for the assignment operator in assignment to a conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri May 9 18:16:05 2014 New Revision: 210283 URL: http://gcc.gnu.org/viewcvs?rev=210283&root=gcc&view=rev Log: PR c++/58714 * tree.c (stabilize_expr): A stabilized prvalue is an xvalue. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-cond1.C trunk/gcc/testsuite/g++.dg/expr/cond12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/32019] Conditional operator ?: and ambiguous convertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32019 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri May 9 18:15:57 2014 New Revision: 210282 URL: http://gcc.gnu.org/viewcvs?rev=210282&root=gcc&view=rev Log: PR c++/32019 * call.c (build_conditional_expr_1): Improve ambiguity diagnostic. PR c++/54348 * call.c (build_conditional_expr_1): If overload resolution finds no match, just say "different types". Added: trunk/gcc/testsuite/g++.dg/expr/cond10.C trunk/gcc/testsuite/g++.dg/expr/cond11.C trunk/gcc/testsuite/g++.dg/expr/cond13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/cpp0x/explicit3.C trunk/gcc/testsuite/g++.dg/parse/crash41.C
[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348 --- Comment #10 from Jason Merrill --- Author: jason Date: Fri May 9 18:15:57 2014 New Revision: 210282 URL: http://gcc.gnu.org/viewcvs?rev=210282&root=gcc&view=rev Log: PR c++/32019 * call.c (build_conditional_expr_1): Improve ambiguity diagnostic. PR c++/54348 * call.c (build_conditional_expr_1): If overload resolution finds no match, just say "different types". Added: trunk/gcc/testsuite/g++.dg/expr/cond10.C trunk/gcc/testsuite/g++.dg/expr/cond11.C trunk/gcc/testsuite/g++.dg/expr/cond13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/cpp0x/explicit3.C trunk/gcc/testsuite/g++.dg/parse/crash41.C
[Bug c++/22434] [3.4/4.0/4.1 regression] ICE in simplify_{,gen_}subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434 --- Comment #10 from Jason Merrill --- Author: jason Date: Fri May 9 18:15:46 2014 New Revision: 210281 URL: http://gcc.gnu.org/viewcvs?rev=210281&root=gcc&view=rev Log: PR c++/22434 * call.c (build_conditional_expr_1): Don't try to pool cv-quals if we didn't find a conversion. Don't accept a bad conversion too early. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/expr/cond8.C trunk/gcc/testsuite/g++.old-deja/g++.jason/conversion10.C
[Bug c++/32019] Conditional operator ?: and ambiguous convertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32019 Jason Merrill changed: What|Removed |Added Keywords|accepts-invalid |diagnostic Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #3 from Jason Merrill --- The type of "1" is not const char *, it is const char[2], and there is no conversion from C to that type. So the only issue here is that the diagnostic we give could be clearer that the problem is ambiguity. Fixed.
[Bug c++/58714] Bogus overload resolution for the assignment operator in assignment to a conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58714 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- Fixed on trunk currently.
[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #11 from Jason Merrill --- Fixed to just say "different types".
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60019 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-09 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jason Merrill --- Fixed on trunk currently. Is this important to get into 4.9?
[Bug c++/53000] Conditional operator does not behave as standardized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Jason Merrill --- Should be fixed by patch for bug 58714.
[Bug c++/52288] Trouble with operator?: and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52288 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- G++ will now say wa.C:3:17: error: operands to ?: have different types ‘main(int, char**)::’ and ‘main(int, char**)::’ I think that addresses the ?: part of this issue. I'll leave it open for now in case we want to keep it as a question about how to name lambdas in error messages. It seems to me that we might want to omit the function scope if we're currently in the same function. Do we want to give them numbers to distinguish them?
[Bug c++/51317] [C++0x] [DR 587] Wrong value category of conditional expression where lvalue operands differ only in cv-qualification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51317 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-09 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jason Merrill --- Fixed on trunk.
[Bug sanitizer/61130] New: 4.9 branch (r210278) bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130
Bug ID: 61130
Summary: 4.9 branch (r210278) bootstrap failure
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sezeroz at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
$ ../gcc49.r210278/configure --enable-checking=yes --enable-languages=c,c++
--enable-lto --enable-shared --enable-threads --with-local-prefix=/usr
--prefix=/home/myname/opt/gcc490 --program-suffix=49 --bindir=/home/myname/bin
--disable-nls --disable-multilib
[...]
$ make -j2 bootstrap
[...]
libtool: compile: /home/myname/gcc49.build/./gcc/xgcc -shared-libgcc
-B/home/myname/gcc49.build/./gcc -nostdinc++
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/bin/
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/lib/ -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/include -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../gcc49.r210278/libsanitizer/ubsan -I.. -I
../../../../gcc49.r210278/libsanitizer -I
../../../../gcc49.r210278/libsanitizer/include -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/i686-pc-linux-gnu
-I../../../../gcc49.r210278/libsanitizer/../libstdc++-v3/libsupc++ -g -O2
-D_GNU_SOURCE -MT ubsan_handlers.lo -MD -MP -MF .deps/ubsan_handlers.Tpo -c
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers.cc -fPIC -DPIC -o
.libs/ubsan_handlers.o
In file included from
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers.cc:13:0:
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_diag.h: In function 'void
handleTypeMismatchImpl(__ubsan::TypeMismatchData*, __ubsan::ValueHandle,
__ubsan::Location)':
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_diag.h:192:72: warning:
'Loc.__ubsan::Location::MemoryLoc' may be used uninitialized in this function
[-Wmaybe-uninitialized]
: Loc(Loc), Level(Level), Message(Message), NumArgs(0), NumRanges(0) {}
^
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers.cc:29:12: note:
'Loc.__ubsan::Location::MemoryLoc' was declared here
Location Loc = Data->Loc.acquire();
^
Host bootstrap compiler:
$ gcc -v
Host bootstrap compiler:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/myname/b1/../opt/gcc480/libexec/gcc/i686-pc-linux-gnu/4.8.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc48.r210266/configure --enable-checking=yes
--enable-languages=c,c++ --enable-lto --enable-shared --enable-threads
--with-local-prefix=/usr --prefix=/home/myname/opt/gcc480 --program-suffix=48
--bindir=/home/myname/bin --disable-nls --disable-multilib
Thread model: posix
gcc version 4.8.3 20140509 (prerelease) (GCC)
The host i686-Linux using an old fedora9.
[Bug sanitizer/61130] 4.9 branch (r210278) bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130 --- Comment #1 from Jakub Jelinek --- That is a warning, not the reason for bootstrap failure.
[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #3 from Marc Glisse ---
template struct A {
unsigned _width, _height, _depth, _spectrum;
template A(t p1) {
int a = p1.size();
if (a) {
_width = p1._width;
_depth = _height = _spectrum = p1._spectrum;
}
}
long size() { return (long)_width * _height * _depth * _spectrum; }
};
int d;
void fn1(void *);
A *fn2();
void fn3() {
int b;
for (;;) {
A c(*fn2());
fn1(&c);
if (d || !b)
throw;
}
}
a.ii: In function 'void fn3()':
a.ii:24:1: error: insn does not satisfy its constraints:
}
^
(insn 67 20 62 3 (set (reg:DI 21 xmm0)
(reg:DI 2 cx)) 89 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 2 cx)
(nil)))
a.ii:24:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:775
[Bug sanitizer/61130] 4.9 branch (r210278) bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130
--- Comment #2 from Ozkan Sezer ---
(In reply to Jakub Jelinek from comment #1)
> That is a warning, not the reason for bootstrap failure.
Well it eventually results in an error:
In file included from
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers.cc:13:0:
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_diag.h: In function 'void
handleTypeMismatchImpl(__ubsan::TypeMismatchData*, __ubsan::ValueHandle,
__ubsan::Location)':
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_diag.h:192:72: warning:
'Loc.__ubsan::Location::MemoryLoc' may be used uninitialized in this function
[-Wmaybe-uninitialized]
: Loc(Loc), Level(Level), Message(Message), NumArgs(0), NumRanges(0) {}
^
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers.cc:29:12: note:
'Loc.__ubsan::Location::MemoryLoc' was declared here
Location Loc = Data->Loc.acquire();
^
libtool: compile: /home/myname/gcc49.build/./gcc/xgcc -shared-libgcc
-B/home/myname/gcc49.build/./gcc -nostdinc++
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/bin/
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/lib/ -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/include -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../gcc49.r210278/libsanitizer/ubsan -I.. -I
../../../../gcc49.r210278/libsanitizer -I
../../../../gcc49.r210278/libsanitizer/include -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/i686-pc-linux-gnu
-I../../../../gcc49.r210278/libsanitizer/../libstdc++-v3/libsupc++ -g -O2
-D_GNU_SOURCE -MT ubsan_diag.lo -MD -MP -MF .deps/ubsan_diag.Tpo -c
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_diag.cc -o ubsan_diag.o
>/dev/null 2>&1
libtool: compile: /home/myname/gcc49.build/./gcc/xgcc -shared-libgcc
-B/home/myname/gcc49.build/./gcc -nostdinc++
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/bin/
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/lib/ -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/include -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../gcc49.r210278/libsanitizer/ubsan -I.. -I
../../../../gcc49.r210278/libsanitizer -I
../../../../gcc49.r210278/libsanitizer/include -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/i686-pc-linux-gnu
-I../../../../gcc49.r210278/libsanitizer/../libstdc++-v3/libsupc++ -g -O2
-D_GNU_SOURCE -MT ubsan_handlers.lo -MD -MP -MF .deps/ubsan_handlers.Tpo -c
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers.cc -o
ubsan_handlers.o >/dev/null 2>&1
mv -f .deps/ubsan_diag.Tpo .deps/ubsan_diag.Plo
/bin/sh ../libtool --tag=CXX --mode=compile
/home/myname/gcc49.build/./gcc/xgcc -shared-libgcc
-B/home/myname/gcc49.build/./gcc -nostdinc++
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/myname/gcc49.build/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/bin/
-B/home/myname/opt/gcc490/i686-pc-linux-gnu/lib/ -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/include -isystem
/home/myname/opt/gcc490/i686-pc-linux-gnu/sys-include-D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../gcc49.r210278/libsanitizer/ubsan -I.. -I
../../../../gcc49.r210278/libsanitizer -I
../../../../gcc49.r210278/libsanitizer/include -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/i686-pc-linux-gnu
-I../../../../gcc49.r210278/libsanitizer/../libstdc++-v3/libsupc++ -frtti -g
-O2 -D_GNU_SOURCE -MT ubsan_handlers_cxx.lo -MD -MP -MF
.deps/ubsan_handlers_cxx.Tpo -c -o ubsan_handlers_cxx.lo
../../../../gcc49.r210278/libsanitizer/ubsan/ubsan_handlers_cxx.cc
libtool: comp
[Bug sanitizer/61130] 4.9 branch (r210278) bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130 --- Comment #3 from Jakub Jelinek --- It could be far earlier than this, look for previous *** in the build log.
[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 Tony Theodore changed: What|Removed |Added Target||i686-w64-mingw32 Host||x86_64-apple-darwin13.1.0 Build||x86_64-apple-darwin13.1.0 --- Comment #3 from Tony Theodore --- I'm building a cross compiler with: Host: x86_64-apple-darwin13.1.0 Targets: i686-pc-mingw32 x86_64-w64-mingw32 i686-w64-mingw32 Build: x86_64-apple-darwin13.1.0 The configure line is: configure \ --target='$(TARGET)' \ --build='$(BUILD)' \ --prefix='$(PREFIX)' \ --libdir='$(PREFIX)/lib' \ --enable-languages='c,c++,objc,fortran' \ --enable-version-specific-runtime-libs \ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ --disable-nls \ --disable-shared \ --disable-multilib \ --without-x \ --disable-win32-registry \ --enable-threads=win32 \ --disable-libgomp \ --disable-libmudflap \ --with-cloog='$(PREFIX)' \ --with-gmp='$(PREFIX)' \ --with-isl='$(PREFIX)' \ --with-mpc='$(PREFIX)' \ --with-mpfr='$(PREFIX)' \ --with-as='$(PREFIX)/bin/$(TARGET)-as' \ --with-ld='$(PREFIX)/bin/$(TARGET)-ld' \ --with-nm='$(PREFIX)/bin/$(TARGET)-nm' \ LDFLAGS='-Wl,-no_pie' Compiler details: $ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix $ clang -v Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 --- Comment #12 from Andreas Schwab --- FAIL: gfortran.dg/wextra_1.f -O (test for warnings, line 4)
[Bug c/61131] New: [4.8 regression] ARM -Os: incorrect code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61131
Bug ID: 61131
Summary: [4.8 regression] ARM -Os: incorrect code generation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: swarren at nvidia dot com
Created attachment 32771
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32771&action=edit
Source sample that exhibits the issue when compiled
When running gcc 4.8 for ARM with -Os, the following function:
int count_entries(struct s *p)
{
int i = 0;
while (p->fd[i] >= 0 && i < MAX_COUNT) {
i++;
}
return i;
}
... gets compiled to essentially a no-op:
83f8 :
83f8:e590 ldrr0, [r0]
83fc:e1e0 mvnr0, r0
8400:e1a00fa0 lsrr0, r0, #31
8404:e12fff1e bxlr
If I don't use -Os, then I get much larger, and working, code.
If I swap the order of the two conditions in the while expression, I get
working code:
while (i < MAX_COUNT && p->fd[i] >= 0) {
If I use gcc-4.7 insteaad, I get working code.
A complete source sample is attached.
The bug is NOT present in
gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux.tar.xz, which is
apparently GCC 4.7.2+svn197188.
The bug IS present in gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz,
which is apparently GCC 4.8.3+svn208968.
I wasn't able to quickly track down any more recent gcc-4.8.x binaries, or
gcc-4.9.x binaries.
The bug IS present in some toolchain I received from a customer in directory
name yocto/gcc-4.8.1-glibc-2.18-hard/.
