[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
Joey Ye joey.ye at arm dot com changed:
What|Removed |Added
CC||joey.ye at arm dot com
--- Comment #1 from Joey Ye joey.ye at arm dot com ---
I cannot reproduce the issue you described with my arm-none-eabi GCC 4.7.4.
Here is my case:
#include stdio.h
void foo() noexcept
{
printf(This is in foo\n);
}
void bar() noexcept
{
printf(This is in bar\n);
foo();
}
int main()
{
bar();
return 0;
}
When I break and stp at foo, here is the successful backtrace:
(gdb) back
#0 foo () at n.cpp:4
#1 0x81e0 in bar () at n.cpp:10
#2 0x81ec in main () at n.cpp:15
Can you please share a small case to reproduce the issue?
[Bug c/61123] New: With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123
Bug ID: 61123
Summary: With LTO, -fno-short-enums is ignored, resulting in
ABI mis-matching in linking.
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hale.Wang at arm dot com
I have two trivial source files
obj1.cc:
int x(int y)
{
return y - 10;
}
obj2.cc:
int foo(int bar)
{
return bar*10;
}
If I link them without -flto, link time optimization is not invoked, and I get
an object file marked as having int-sized enums:
$ arm-none-eabi-g++ -fno-short-enums -mcpu=arm946e-s obj1.cc obj2.cc
-Wl,-Ur -o partial_link_result.o -nostdlib -Os
$ arm-none-eabi-readelf -a partial_link_result.o | grep enum
Tag_ABI_enum_size: int
But if I simply add -flto to the linker invocation, the output claims that it
has small enums:
$ arm-none-eabi-g++ -fno-short-enums -mcpu=arm946e-s obj1.cc obj2.cc
-Wl,-Ur -o partial_link_result.o -nostdlib -Os -flto
$ arm-none-eabi-readelf -a partial_link_result.o | grep enum
Tag_ABI_enum_size: small
It sure looks to me like something removed `-fno-short-enums` from
`COLLECT_GCC_OPTIONS` during the LTO step. I have reproduced the same behavior
on several different gcc 4.8 distributions (Mentor's Sourcery 4.8.1, Ubuntu's
4.8.2, and now the gcc-arm-embedded 4.8.3).
(The commands above are from Bobby Moretti)
The reason is that: if we add -flto option, link time optimization is invoked.
And the lto need to call the function run_gcc(unsigned argc, char *argv[]) in
lto-wrapper.c. The options in *argv[] are filtered by the following commands:
if(!(cl_options[option-opt_index].flags (CL_COMMON | CL_TARGET |
CL_DRIVER | CL_LTO)))
continue;
So all the options which do not belong to the
CL_COMMON|CL_TARGET|CL_DRIVER|CL_LTO groups will be ignored by LTO. And
-fno-short-enums is one of these options.
I think it is a bug of LTO. Because the option flag_short_enums can change the
enum size in the generated object file. We should allow the users to disable
this optimization as they like.
I suggest we can add the option flag_short_enums to the CL_COMMON group(or
CL_LTO group, I am not sure which group is more reasonable). And I have
confirmed that this change works.
There are several other options that are similar with flag_short_enums which
may change the ABI interface. And these options may cause the similar failure
in LTO. So how should we deal with these options? Should we develop a new
option group which could not be ignored by LTO?
[Bug target/59904] [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 wangzheyu tony.wang at arm dot com changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #2 from wangzheyu tony.wang at arm dot com --- Hi, I'm trying to reproduce this bug on the panda board(cortex-a9). With the same configuration, the case does meet some execution failure, but in order to clarify what happened on earth, could you please provide your own elf? (In reply to christophe.lyon from comment #0) Since commit 206897 (LRA fix PR rtl-optimization/59858) I have noticed that: gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fPIE execution test gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fpie execution test the compiler used to ICE, but after the LRA fix the generated code is not functional. I have tested with qemu-arm, target arm-none-linux-gnueabi, --with-mode=thumb --with-cpu=cortex-a9, using RUNTESTFLAGS=-march=armv5t gcc.log contains: qemu: uncaught target signal 6 (Aborted) - core dumped
[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 jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
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 mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri May 9 08:24:37 2014 New Revision: 210262 URL: http://gcc.gnu.org/viewcvs?rev=210262root=gccview=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 mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- 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 thomas.preudhomme at arm dot com changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #14 from Thomas Preud'homme thomas.preudhomme at arm dot com --- (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 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 thomas.preudhomme at arm dot com changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #14 from Thomas Preud'homme thomas.preudhomme at arm dot com --- (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 rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- 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 dvyukov at google dot com --- 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 redi at gcc dot gnu.org 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 redi at gcc dot gnu.org --- 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 f.heckenb...@fh-soft.de --- 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=32766action=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_castMyObj*(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 rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- 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 ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- *** 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 redi at gcc dot gnu.org ---
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 int b1[] { { } };
^
in.cc:11:26: error: array bound cannot be deduced from an in-class initializer
std::vector int b2[] { { 1, 2, 3 } };
^
in.cc:12:26: error: array bound cannot be deduced from an in-class initializer
std::vector int b3[] { std::vector int () };
^
in.cc:13:26: error: array bound cannot be deduced from an in-class initializer
std::vector int b4[] { std::vector int (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 rguenth at gcc dot gnu.org --- 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 rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- 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 gjl at gcc dot gnu.org --- Author: gjl Date: Fri May 9 11:20:43 2014 New Revision: 210267 URL: http://gcc.gnu.org/viewcvs?rev=210267root=gccview=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 gjl at gcc dot gnu.org --- Author: gjl Date: Fri May 9 11:25:11 2014 New Revision: 210268 URL: http://gcc.gnu.org/viewcvs?rev=210268root=gccview=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 zadeck at naturalbridge dot com changed: What|Removed |Added CC||zadeck at naturalbridge dot com --- Comment #8 from Kenneth Zadeck zadeck at naturalbridge dot com --- Created attachment 32767 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32767action=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 gjl at gcc dot gnu.org --- Author: gjl Date: Fri May 9 11:29:58 2014 New Revision: 210269 URL: http://gcc.gnu.org/viewcvs?rev=210269root=gccview=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 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 zadeck at naturalbridge dot com changed: What|Removed |Added CC||zadeck at naturalbridge dot com --- Comment #8 from Kenneth Zadeck zadeck at naturalbridge dot com --- Created attachment 32767 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32767action=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 gjl at gcc dot gnu.org --- Author: gjl Date: Fri May 9 11:34:46 2014 New Revision: 210270 URL: http://gcc.gnu.org/viewcvs?rev=210270root=gccview=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 gjl at gcc dot gnu.org 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 gjl at gcc dot gnu.org --- 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 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=210274root=gccview=rev Log: 2014-05-06 Kenneth Zadeck zad...@naturalbridge.com 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 belagod at gcc dot gnu.org ---
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 zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Kenneth Zadeck zadeck at naturalbridge dot com --- 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 glisse at gcc dot gnu.org --- (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 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 belagod at gcc dot gnu.org ---
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 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 glisse at gcc dot gnu.org --- (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 belagod at gcc dot gnu.org ---
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 senthil_kumar.selvaraj at atmel dot com changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
||l.com
--- Comment #2 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot
com ---
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 stdlib.h
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 rguenth at gcc dot gnu.org ---
(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 senthil_kumar.selvaraj at atmel dot com --- 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,%A1CR_TAB std Y+62,%B1CR_TAB std Y+63,%C1CR_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 rguenth at gcc dot gnu.org ---
(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 rguenth at gcc dot gnu.org --- Created attachment 32768 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32768action=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 dominiq at lps dot ens.fr 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 dominiq at lps dot ens.fr --- 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 dominiq at lps dot ens.fr 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 dominiq at lps dot ens.fr --- 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 dominiq at lps dot ens.fr 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 dominiq at lps dot ens.fr --- 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 paolo.carlini at oracle dot com 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 paolo.carlini at oracle dot com --- 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 dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-09 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-05-09 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 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=210277root=gccview=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 mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from mrs at gcc dot gnu.org 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=32769action=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 hubicka at ucw dot cz --- 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 dominiq at lps dot ens.fr changed: What|Removed |Added Target||*-apple-darwin* Component|fortran |target Known to work||4.5.0 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 hubicka at gcc dot gnu.org 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 hubicka at gcc dot gnu.org --- 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 barry.j.mcinnes at noaa dot gov --- 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=210278root=gccview=rev Log: Backport from mainline 2014-05-08 Uros Bizjak ubiz...@gmail.com 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 ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.1 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org, ||manu at gcc dot gnu.org --- Comment #2 from Matthias Klose doko at gcc dot gnu.org --- -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 fweimer at redhat dot com ---
(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 burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- (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 doko at gcc dot gnu.org --- -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 dje at gcc dot gnu.org --- (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 dominiq at lps dot ens.fr --- 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 dje at gcc dot gnu.org --- Created attachment 32770 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32770action=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 burnus at gcc dot gnu.org --- (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 manu at gcc dot gnu.org --- (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 manu at gcc dot gnu.org --- (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 doko at ubuntu dot com --- 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 ebotcazou at gcc dot gnu.org --- 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 manu at gcc dot gnu.org --- (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 yaozhen_guo at yahoo dot com changed: What|Removed |Added CC||yaozhen_guo at yahoo dot com --- Comment #3 from YaoZhenGuo yaozhen_guo at yahoo dot com --- (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 unwind.h
#include iostream
_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 manu at gcc dot gnu.org --- 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=210279root=gccview=rev Log: Backport r210254 from trunk for Google b/14380607. 2014-05-08 Jeff Law l...@redhat.com 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 tejohnson at google dot com --- 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 gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #11 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri May 9 04:54:00 2014 New Revision: 210254 URL: http://gcc.gnu.org/viewcvs?rev=210254root=gccview=rev Log: 2014-05-08 Jeff Law l...@redhat.com 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 ppluzhnikov at google dot com --- (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 law at redhat dot com --- 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 mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri May 9 17:50:25 2014 New Revision: 210280 URL: http://gcc.gnu.org/viewcvs?rev=210280root=gccview=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 mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- 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.
[Bug c++/60019] [C++11] Bogus error: use of deleted function unique_ptr(const unique_ptr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60019 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri May 9 18:16:11 2014 New Revision: 210284 URL: http://gcc.gnu.org/viewcvs?rev=210284root=gccview=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 jason at gcc dot gnu.org --- Author: jason Date: Fri May 9 18:16:18 2014 New Revision: 210285 URL: http://gcc.gnu.org/viewcvs?rev=210285root=gccview=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 jason at gcc dot gnu.org --- Author: jason Date: Fri May 9 18:16:05 2014 New Revision: 210283 URL: http://gcc.gnu.org/viewcvs?rev=210283root=gccview=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 jason at gcc dot gnu.org --- Author: jason Date: Fri May 9 18:15:57 2014 New Revision: 210282 URL: http://gcc.gnu.org/viewcvs?rev=210282root=gccview=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 jason at gcc dot gnu.org --- Author: jason Date: Fri May 9 18:15:57 2014 New Revision: 210282 URL: http://gcc.gnu.org/viewcvs?rev=210282root=gccview=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 jason at gcc dot gnu.org --- Author: jason Date: Fri May 9 18:15:46 2014 New Revision: 210281 URL: http://gcc.gnu.org/viewcvs?rev=210281root=gccview=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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- 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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- 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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- Fixed to just say different types.
[Bug c++/60019] [C++11] Bogus error: use of deleted function unique_ptr(const unique_ptr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60019 Jason Merrill jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- 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 jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Jason Merrill jason at gcc dot gnu.org --- 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 jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- G++ will now say wa.C:3:17: error: operands to ?: have different types ‘main(int, char**)::lambda(int)’ and ‘main(int, char**)::lambda(int)’ 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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- 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 jakub at gcc dot gnu.org --- 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 glisse at gcc dot gnu.org ---
template typename struct A {
unsigned _width, _height, _depth, _spectrum;
template typename t 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 *);
Aint *fn2();
void fn3() {
int b;
for (;;) {
Achar 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 sezeroz at gmail dot com ---
(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 21
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 21
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
[Bug sanitizer/61130] 4.9 branch (r210278) bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- It could be far earlier than this, look for previous *** in the build log.
