[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 Martin Liška changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-31 CC||kyrylo.tkachov at arm dot com, ||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Summary|wrong code at -O2 and -O3 |[7 Regression] wrong code |on x86_64-linux-gnu |at -O2 and -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r241649.
[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78169 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-31 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce on native x86_64-linux-gnu compiler. Are you using a cross-compilation (guessing because you have it called crosstool-ng)?
[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78163 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-31 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- For: $ gcc --version gcc (SUSE Linux) 6.2.1 20160830 [gcc-6-branch revision 239856] $ gcc pr78163.c pr78163.c:1:16: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token void f(void () &); ^ pr78163.c:2:19: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token void g(void (*)() &); ^ pr78163.c:3:14: error: expected ‘)’ before ‘&’ token void h(void (&)() &); ^ pr78163.c:4:22: error: expected ‘)’ before ‘&’ token void i(void (* const &)() &); ^ Same for all releases I have, all of declarations are rejected. What's wrong?
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- I'll take a look.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Created attachment 39928 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39928&action=edit Minimized test-case Confirmed, adding minimized test-case.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-31 Ever confirmed|0 |1
[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 --- Comment #7 from Yuri Rumyantsev --- Compiler was configures with: Configured with: /configure --enable-languages=c,c++ --enable-clocale=gnu --enable-cloog-backend=isl --enable-shared --disable-libsanitizer --disable-bootstrap --disable-nls --with-system-zlib --with-demangler-in-ld --with-arch=corei7 --with-cpu=corei7 --with-fpmath=sse --prefix=/install Thread model: posix gcc version 7.0.0 20161014 (experimental) (GCC) I assume that arch and cpu are not essential.
[Bug fortran/78059] Pointer to variable length array, debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78059 --- Comment #5 from Bernhard Heckel --- Hi Dominique, did my comment help to figure out if the bug report is valid?
[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78086 --- Comment #8 from Martin Liška --- Thanks for testing. Patch has been just sent to ML: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02439.html
[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78163 --- Comment #2 from TC --- (In reply to Martin Liška from comment #1) > For: > $ gcc --version > gcc (SUSE Linux) 6.2.1 20160830 [gcc-6-branch revision 239856] > > $ gcc pr78163.c > pr78163.c:1:16: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token > void f(void () &); > ^ > pr78163.c:2:19: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token > void g(void (*)() &); >^ > pr78163.c:3:14: error: expected ‘)’ before ‘&’ token > void h(void (&)() &); > ^ > pr78163.c:4:22: error: expected ‘)’ before ‘&’ token > void i(void (* const &)() &); > ^ > Same for all releases I have, all of declarations are rejected. What's wrong? This report is for C++, not C?
[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78163 Martin Liška changed: What|Removed |Added Status|WAITING |NEW CC||jason at redhat dot com Target Milestone|--- |7.0 --- Comment #3 from Martin Liška --- You're right, thus I'm confirming that. Started with r225272, where we switch to std=c++14. -std=c++11 works fine.
[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed. Oddly I don't see -1 on aarch64. Will investigate
[Bug tree-optimization/33707] scev not handling unsigned conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33707 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||amker at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from amker at gcc dot gnu.org --- This has been fixed as added test case.
[Bug other/78161] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78161 --- Comment #1 from Richard Biener --- The issue with the current script is probably relying too much on wget internals (the -O option). It would probably be better to simply cd into the destination directory and do wget w/o -O.
[Bug other/78161] [7 Regression] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78161 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-31 CC||rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Summary|contrib/download_prerequisi |[7 Regression] |tes fails on MacOS, |contrib/download_prerequisi |Lubuntu, and Windows|tes fails on MacOS, ||Lubuntu, and Windows Ever confirmed|0 |1
[Bug tree-optimization/78151] Fail to vectorize *min_element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78151 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-31 CC||rguenth at gcc dot gnu.org Blocks||53947 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Time to play a bit with fold_stmt applying to PHIs using match.pd via folding a COND_EXPR composed of the dominating controlling condition plus the PHI arguments ... at least if-conversion could do that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug fortran/78152] [6/7 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.3
[Bug tree-optimization/78154] memcpy et al can be assumed to return non-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78154 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-31 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed. Improve gimple_stmt_nonzero_warnv_p.
[Bug tree-optimization/78162] [7 Regression] ICE on invalid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78162 Richard Biener changed: What|Removed |Added Version|unknown |7.0 Target Milestone|--- |7.0 Summary|ICE on invalid code at -Os |[7 Regression] ICE on |and above on|invalid code at -Os and |x86_64-linux-gnu: |above on x86_64-linux-gnu: |Segmentation fault |Segmentation fault
[Bug target/78166] [6 Regression] hash.c:1887:1: error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.3
[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77834 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Apparently on the v_lsm.5 variable we trigger cfgexpand.c (set_rtl)'s /* If we have something recorded and it's not the same place as we want to record now, we have multiple partitions for the same base variable, with different places. We can't just randomly chose one, hence we have to say that we don't know. This only happens with optimization, and there var-tracking will figure out the right thing. */ else if (DECL_RTL (var) != x) SET_DECL_RTL (var, pc_rtx); hunk, because set_rtl is once called with (mem/c:BLK (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -64 [0xffc0])) [1 v_lsm.5+0 S64 A512]) on v_lsm.5_24 and then (mem/c:BLK (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -128 [0xff80])) [1 v_lsm.5+0 S64 A512]) on v_lsm.5_20 and then in pass_expand::execute /* If this decl was marked as living in multiple places, reset this now to NULL. */ tree var = SSA_NAME_VAR (name); if (var && DECL_RTL_IF_SET (var) == pc_rtx) SET_DECL_RTL (var, NULL);
[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 --- Comment #3 from Richard Biener --- Btw, I see at -Os: Starting new chain with statement: c.f6 = -1; The base object is: c Volatile access terminates all chains Processing basic block <4>: : e = *.LC0; c = e; c.f6 = -1; e ={v} {CLOBBER}; a.1_1 = a; b = a.1_1; the e ={v} {CLOBBER}; isn't a "volatile" stmt. Clobbers only should terminate aliasing chains.
[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77834 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 39929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39929&action=edit gcc7-pr77834.patch Untested fix. Will bootstrap/regtest this with additional statistics gathering, to see if this shouldn't be extended (e.g. allow DECL_RTL to be used on TREE_STATIC vars or whatever make_decl_rtl allows).
[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > Btw, I see at -Os: > > Starting new chain with statement: > c.f6 = -1; > The base object is: > c > Volatile access terminates all chains > Processing basic block <4>: > > : > e = *.LC0; > c = e; > c.f6 = -1; > e ={v} {CLOBBER}; > a.1_1 = a; > b = a.1_1; > > the e ={v} {CLOBBER}; isn't a "volatile" stmt. Clobbers only should > terminate > aliasing chains. Yes, that's what I'm seeing on aarch64. I'll look into implementing that once the bugs are squashed out
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 --- Comment #2 from Richard Biener --- Created attachment 39930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39930&action=edit patch Does the attached fix it? (I lack a testcase to easily reproduce a failing WPA stage after it has written some ltrans file) OTOH I wonder where we emit errors during lto_wpa_write_files ...
[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 --- Comment #5 from ktkachov at gcc dot gnu.org --- The problem is in encode_tree_to_bitpos. It needs to take into account the padding that native_encode_expr may introduce for sign-extended values for little-endian as well as big-endian. Testing a patch
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 57206, which changed state. Bug 57206 Summary: Auto-vectorization fails when array index is an unsigned int expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/57206] Auto-vectorization fails when array index is an unsigned int expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||amker at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from amker at gcc dot gnu.org --- Test case added. Fixed.
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 --- Comment #3 from Richard Biener --- Ah - I think a simpler pass would be diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c index 7256ff9..c1567ca 100644 --- a/gcc/lto/lto.c +++ b/gcc/lto/lto.c @@ -3092,6 +3092,10 @@ do_whole_program_analysis (void) execute_ipa_pass_list (g->get_passes ()->all_regular_ipa_passes); + /* When WPA analysis raises errors, do not bother to output anything. */ + if (seen_error ()) +return; + if (symtab->dump_file) { fprintf (symtab->dump_file, "Optimized ");
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 --- Comment #4 from Richard Biener --- The attached would be still needed in case the ltrans writing is terminated by, say, ctrl-c (but then there's a race because WPA doesn't write the ltrans output list before finishing writing all ltrans objects).
[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77860 --- Comment #3 from Jakub Jelinek --- Reproduceable also on current trunk with -O2 -fno-tree-forwprop -fno-tree-vrp typedef unsigned short V __attribute__((vector_size (16))); V foo (V x, V y) { V a = -x; V b = -y; return a * b; }
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Oct 31 12:52:23 2016 New Revision: 241698 URL: https://gcc.gnu.org/viewcvs?rev=241698&root=gcc&view=rev Log: 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #28 from Bernd Edlinger --- With my latest patch I bootstrapped a configuration with --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard I noticed a single regression in gcc.target/arm/pr53447-*.c That is caused by disabling the adddi3 expansion. void t0p(long long * p) { *p += 0x10001; } used to get compiled to this at -O2: ldrdr2, [r0] addsr2, r2, #1 adc r3, r3, #1 strdr2, [r0] bx lr but without the adddi3 pattern I have at -O2: ldr r3, [r0] ldr r1, [r0, #4] cmn r3, #1 add r3, r3, #1 movcc r2, #0 movcs r2, #1 add r1, r1, #1 str r3, [r0] add r3, r2, r1 str r3, [r0, #4] bx lr Note that also the ldrd instructions are not there. Unfortunaltely also the other di3 pattern make the ldrd go away: void t0p(long long * p) { *p |= 0x10001; } was with iordi3 like this: ldrdr2, [r0] orr r2, r2, #1 orr r3, r3, #1 strdr2, [r0] bx lr and without iordi3: ldm r0, {r2, r3} orr r2, r2, #1 orr r3, r3, #1 stm r0, {r2, r3} bx lr but void t0p(long long * p) { p[1] |= 0x10001; } gets two loads instead: ldr r2, [r0, #8] ldr r3, [r0, #12] orr r2, r2, #1 orr r3, r3, #1 str r2, [r0, #8] str r3, [r0, #12] bx lr however: void t0p(long long * p) { p[1] <<= 11; } gets compiled into this: ldr r3, [r0, #12] ldr r2, [r0, #8] lsl r3, r3, #11 lsl r1, r2, #11 orr r3, r3, r2, lsr #21 str r1, [r0, #8] str r3, [r0, #12] bx lr already before my patch. I think this is the effect on the ldrd that you already mentioned, and it gets worse when the expansion breaks the di registers up into two si registers.
[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77860 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 39931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39931&action=edit gcc7-pr77860.patch Untested fix.
[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 --- Comment #9 from Pierre-Marie de Rodat --- Back to business. ;-) Thank you very much, Jakub! During investigation, I managed to reduce this even further: void run (int *int_p, void(*func)(int *)) { func (int_p); } namespace foo { struct Foo { int a; Foo() { run (&a, [](int *int_p) { *int_p = 0; }); } }; } int main (void) { foo::Foo f; } With today’s trunk (gcc/cc1plus -g -dA foo.C) and this reproducer, I see three DW_TAG_subprogram having two DW_AT_object_pointer each. Disclaimer: to be perfectly honnest, I have a very partial understanding of how dwarf2out.c:gen_subprogram_die is supposed to work. It has a good share of explaining comments, but it is still hard to grasp as it does quite complex things. That being said… My analysis so far is that gen_subprogram_die is supposed to be called a very specific number of times for each function and my change from 2016-10-12 made it run more times, so it unintentionally added some attributes more than just once. The following patch seems to restore call count to what we had previously: diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 78a2979..a85ab3b 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -23909,11 +23909,11 @@ dwarf2out_early_global_decl (tree decl) if (!DECL_STRUCT_FUNCTION (decl)) goto early_decl_exit; - /* For nested functions, emit DIEs for the parents first so that all -nested DIEs are generated at the proper scope in the first -shot. */ + /* For nested functions, make sure we have DIEs for the parents first +so that all nested DIEs are generated at the proper scope in the +first shot. */ tree context = decl_function_context (decl); - if (context != NULL) + if (context != NULL && lookup_decl_die (context) == NULL) { current_function_decl = context; dwarf2out_decl (context); I’m currently bootstrapping+regtesting it on x86_64-linux. I tried to come up with a regression testcase for it, but I can’t find a human-friendly regexp for scan-assembler-times to check that we don’t have multiple attributes per tag. So for local testing, I wrote a Python3 script to use the pyelftools library. I’ll file it right after sending this message if others need to use it. Something bugs me, though: with Jakub’s reproducer, I get multiple DW_AT_object_pointer attributes even at r241022 (i.e. right before my 2016-10-12 patch): $ gcc/cc1plus -g -dA pr78112.ii && gcc -c pr78112.s && ./check.py pr78112.o In (0x3c4) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times In (0x46a) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times In (0x4fe) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times In (0x55a) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times In (0x5cf) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times In (0x668) DW_TAG_subprogram: DW_AT_object_pointer appears 2 times So I’m surprised Rainer hasn’t spotted this kind of error before. Thoughts?
[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 --- Comment #10 from Pierre-Marie de Rodat --- Created attachment 39932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39932&action=edit pyelftools-based Python3 script to check duplicate attributes in ELF/DWARF info
[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77872 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #4 from vehre at gcc dot gnu.org --- Can someone explain the code to me? What is it supposed to do? Is this not modelling an endless recursion? What is "s" and "f" in the type definition? I understand that "pass" and "deferred" mean to transport meta-data of an array, right?
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Mon Oct 31 13:39:49 2016 New Revision: 241700 URL: https://gcc.gnu.org/viewcvs?rev=241700&root=gcc&view=rev Log: PR c++/77886 * pt.c (tsubst_expr) Copy over FALLTHROUGH_LABEL_P flag to the new LABEL_DECL. (tsubst_expr) : Likewise. * g++.dg/warn/Wimplicit-fallthrough-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug middle-end/78047] [7 Regression] Chromium apparently gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- (In reply to Markus Trippelsdorf from comment #5) > : > > MEM[(struct &)&builder] ={v} {CLOBBER}; > > _53 = MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + > 8B].fPtr; > > if (_53 != &MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + > 8B].D.47025.fTStorage) So X.fPtr != &X.D.47025.fTStorage. This probably means a latent wrong-code PTA bug. : MEM[(struct &)&gQuadIndexBufferKey_storage + 8] ={v} {CLOBBER}; MEM[(struct &)&gQuadIndexBufferKey_storage + 8] ={v} {CLOBBER}; MEM[(struct &)&gQuadIndexBufferKey_storage + 8] ={v} {CLOBBER}; MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + 8B].fPtr = &MEM[(void *)&gQuadIndexBufferKey_storage + 16B]; MEM[(unsigned int &)&gQuadIndexBufferKey_storage + 16] = 0; MEM[(unsigned int &)&gQuadIndexBufferKey_storage + 20] = 0; MEM[(struct &)&gQuadIndexBufferKey_storage + 48] ={v} {CLOBBER}; MEM[(struct sk_sp *)&gQuadIndexBufferKey_storage + 48B].fPtr = 0B; # USE = nonlocal null { D.124671 D.124724 D.124797 D.124805 } (nonlocal, escaped) # CLB = nonlocal null { D.124671 D.124724 D.124797 D.124805 } (nonlocal, escaped) _49 = GrUniqueKey::GenerateDomain (); : MEM[(struct &)&builder] ={v} {CLOBBER}; MEM[(struct Builder *)&builder].fKey = &MEM[(void *)&gQuadIndexBufferKey_storage + 8B]; # PT = null _53 = MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + 8B].fPtr; # PT = null { D.124724 } (nonlocal, escaped) _54 = &MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + 8B].D.47035.fTStorage; if (_53 != &MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + 8B].D.47035.fTStorage) ... we fail to add a constraint for _53 = ... at all. We add: _49 = NONLOCAL builder = &_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage _54 = &_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage ESCAPED = _53 ESCAPED = &_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #29 from wilco at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #28) > With my latest patch I bootstrapped a configuration with > --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 > --with-float=hard > > I noticed a single regression in gcc.target/arm/pr53447-*.c > > That is caused by disabling the adddi3 expansion. > > void t0p(long long * p) > { > *p += 0x10001; > } > > used to get compiled to this at -O2: > > ldrdr2, [r0] > addsr2, r2, #1 > adc r3, r3, #1 > strdr2, [r0] > bx lr > > but without the adddi3 pattern I have at -O2: > > ldr r3, [r0] > ldr r1, [r0, #4] > cmn r3, #1 > add r3, r3, #1 > movcc r2, #0 > movcs r2, #1 > add r1, r1, #1 > str r3, [r0] > add r3, r2, r1 > str r3, [r0, #4] > bx lr That's because your patch disables adddi3 completely, which is not correct. We want to use the existing integer sequence, just expanded earlier. Instead of your change, removing the "&& reload_completed" from the arm_adddi3 instruction means we expand before register allocation: ldr r3, [r0] ldr r2, [r0, #4] addsr3, r3, #1 str r3, [r0] adc r2, r2, #16 str r2, [r0, #4] bx lr > Note that also the ldrd instructions are not there. Yes that's yet another bug... > I think this is the effect on the ldrd that you already mentioned, > and it gets worse when the expansion breaks the di registers up > into two si registers. Indeed, splitting early means we end up with 2 loads. However in most cases we should be able to gather the loads and emit LDRD/STRD on Thumb-2 (ARM's LDRD/STRD is far more limited so not as useful). Combine could help with merging 2 loads/stores into a single instruction.
[Bug c/78000] -Wimplicit-function-declaration inhibited with macro from system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78000 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-31 Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- I'm testing a patch to disable inhibiting such warnings for macros from system headers globally. I've failed to come up with anything better so far.
[Bug middle-end/78047] [7 Regression] Chromium apparently gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 --- Comment #8 from Richard Biener --- Because (gdb) p *$54 $55 = {id = 30, is_artificial_var = 0, is_special_var = 0, is_unknown_size_var = 0, is_full_var = 1, is_heap_var = 0, may_have_pointers = 0, only_restrict_pointers = 0, is_restrict_var = 0, is_global_var = 1, is_ipa_escape_point = 0, is_fn_info = 0, ruid = 0, next = 0, head = 30, offset = 0, size = 448, fullsize = 448, name = 0x7264dd68 "_ZZN18GrResourceProviderC4EP5GrGpuP15GrResourceCacheP13GrSingleOwnerE27gQuadIndexBufferKey_storage", decl = , solution = 0x37f54e0, oldsolution = 0x0} thus it is noted as !may_have_pointers. Ok, this is because we first generate "sth" at offset zero: /* If there isn't anything at offset zero, create sth. */ if (!pair && offset + foff != 0) { fieldoff_s e = {0, offset + foff, false, false, false, false, NULL_TREE}; pair = fieldstack->safe_push (e); } (note may_have_pointers = false) and then end up simply merging: /* If adjacent fields do not contain pointers merge them. */ must_have_pointers_p = field_must_have_pointers (field); if (pair && !has_unknown_size && !must_have_pointers_p && !pair->must_have_pointers && !pair->has_unknown_size && pair->offset + (HOST_WIDE_INT)pair->size == offset + foff) { pair->size += tree_to_uhwi (DECL_SIZE (field)); may_have_pointers should be conservative these days (should be removed from fieldoff I guess). diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c index fb364f1..2880382 100644 --- a/gcc/tree-ssa-structalias.c +++ b/gcc/tree-ssa-structalias.c @@ -5566,7 +5568,7 @@ push_fields_onto_fieldstack (tree type, vec *fieldstack, && offset + foff != 0) { fieldoff_s e - = {0, offset + foff, false, false, false, false, NULL_TREE}; + = {0, offset + foff, false, false, true, false, NULL_TREE}; pair = fieldstack->safe_push (e); } fixes it: MEM[(struct Builder *)&builder].fKey = &MEM[(void *)&gQuadIndexBufferKey_storage + 8B]; # PT = nonlocal escaped null { D.124724 } (nonlocal, escaped) _53 = MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + 8B].fPtr; if (_53 != &MEM[(struct SkAutoSTMalloc *)&gQuadIndexBufferKey_storage + 8B].D.47035.fTStorage) goto ;
[Bug fortran/78171] New: example with undefined symbol compiles with '-O1 -fcheck=pointer'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78171 Bug ID: 78171 Summary: example with undefined symbol compiles with '-O1 -fcheck=pointer' Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patrick.seewald at gmail dot com Target Milestone: --- This should not compile because 'foo' is undefined: PROGRAM example IMPLICIT NONE REAL, ALLOCATABLE, DIMENSION(:) :: array CALL foo(array) END PROGRAM example However it compiles with 'gfortran -O1 -fcheck=pointer example.f90'. If I run the executable, I get: At line 4 of file example.f90 Fortran runtime error: Allocatable actual argument 'array' is not allocated
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #5 from Segher Boessenkool --- Cannot reproduce on 32-bit Linux, will try a plain powerpc-elf build.
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #6 from Martin Liška --- (In reply to Segher Boessenkool from comment #5) > Cannot reproduce on 32-bit Linux, will try a plain powerpc-elf build. I did that on a x86_64-linux-gnu with --target=powerpc-rtems4.12
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #7 from Sebastian Huber --- A git bisect indicates this as the bad commit: commit 14fdd09f470dea253089d6a5b27d7a2c3ab7d67a Author: segher Date: Wed Oct 12 15:34:39 2016 + rs6000: Separate shrink-wrapping This implements the hooks for separate shrink-wrapping for rs6000. It handles GPRs and LR. The GPRs get a component number corresponding to their register number; LR gets component number 0. * config/rs6000/rs6000.c (machine_function): Add new fields gpr_is_wrapped_separately and lr_is_wrapped_separately. (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define. (rs6000_get_separate_components): New function. (rs6000_components_for_bb): New function. (rs6000_disqualify_components): New function. (rs6000_emit_prologue_components): New function. (rs6000_emit_epilogue_components): New function. (rs6000_set_handled_components): New function. (rs6000_emit_prologue): Don't emit LR save if lr_is_wrapped_separately. Don't emit GPR saves if gpr_is_wrapped_separately for that register. (restore_saved_lr): Don't restore LR if lr_is_wrapped_separately. (rs6000_emit_epilogue): Don't emit GPR restores if gpr_is_wrapped_separately for that register. Don't make a REG_CFA_RESTORE note for registers we did not restore, either. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241065 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 93015f5b1887799cdee7723b46455953bf087911 61a2a5a9e1f078a49af4930e0f62f5269f18ad86 M gcc
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #8 from Sebastian Huber --- On RTEMS I think -mspe is enabled for -mcpu=8540.
[Bug go/78172] New: gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 Bug ID: 78172 Summary: gen-sysinfo.go vs AIX cred.h Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dje at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Target: powerpc-ibm-aix* Linux has a fairly simple ucred, but AIX has a large, complicated one with multiple variations that appears to be too much for sysinfo.go. /opt/freeware/src/packages/BUILD/gcc-build-6.2.0/./gcc/gccgo -B/opt/freeware/src/packages/BUILD/gcc-build-6.2.0/./gcc/ -B/opt/freeware/powerpc-ibm-aix6.1.0.0/bin/ -B/opt/freeware/powerpc-ibm-aix6.1.0.0/lib/ -isystem /opt/freeware/powerpc-ibm-aix6.1.0.0/include -isystem /opt/freeware/powerpc-ibm-aix6.1.0.0/sys-include -g -O2 -I. -c -fgo-pkgpath=syscall ../../../gcc-6.2.0/libgo/go/syscall/env_unix.go ../../../gcc-6.2.0/libgo/go/syscall/syscall_errno.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_support.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_posix.go ../../../gcc-6.2.0/libgo/go/syscall/msan0.go ../../../gcc-6.2.0/libgo/go/syscall/socket.go ../../../gcc-6.2.0/libgo/go/syscall/sockcmsg_unix.go ../../../gcc-6.2.0/libgo/go/syscall/str.go ../../../gcc-6.2.0/libgo/go/syscall/syscall.go ../../../gcc-6.2.0/libgo/go/syscall/syscall_stubs.go ../../../gcc-6.2.0/libgo/go/syscall/exec_unix.go ../../../gcc-6.2.0/libgo/go/syscall/exec_bsd.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_wait4.go ../../../gcc-6.2.0/libgo/go/syscall/sleep_select.go ../../../gcc-6.2.0/libgo/go/syscall/errstr.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_posix_regfile.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_bsd.go ../../../gcc-6.2.0/libgo/go/syscall/socket_bsd.go ../../../gcc-6.2.0/libgo/go/syscall/socket_posix.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_uname.go ../../../gcc-6.2.0/libgo/go/syscall/libcall_posix_utimesnano.go libcalls.go sysinfo.go syscall_arch.go -fPIC -o .libs/syscall.o sysinfo.go:10171:307: error: expected ';' or newline after top level declaration id uint32; Cr_sgid uint32; Cr_ngrps int16; Cr_caps int16; Cr_groupset _groupset_t; Cr_mpriv _priv_t; Cr_ipriv _priv_t; Cr_epriv _priv_t; Cr_bpriv _priv_t; Cr_pag int32; } type _ucred_43 struct { ocr_ref int32; Ocr_ruid uint32; Ocr_uid uint32; Ocr_suid uint32; Ocr_luid uint32; Ocr_acctid uint32; Ocr_gid uint32; Ocr_rgid uint32; Ocr_sgid uint32; Ocr_ngrps int16; Ocr_groups [31+1]uint32; Ocr_mpriv _priv_t; Ocr_ipriv _priv_t; Ocr_epriv _priv_t; Ocr_bpriv _priv_t; Ocr_pag int32; } type _ucred_ext struct { crx_ruid uint32; Crx_uid uint32; Crx_suid uint32; Crx_luid uint32; Crx_acctid uint32; Crx_gid uint32; Crx_rgid uint32; Crx_sgid uint32; Crx_ngrps int32; Crx_groups [127+1]uint32; Crx_reserved_1 int32; Crx_caps ___cap_t; Crx_mpriv _priv_t; Crx_ipriv _priv_t; Crx_epriv _priv_t; Crx_bpriv _priv_t; Crx_npags int32; Crx_pagids [15+1]uint8; Crx_pags [15+1]int32; Crx_reserved_2 int32; Crx_roles [7+1]uint32; Crx_nroles int16; Crx_reserved_3 int16; Crx_flags uint32; Crx_effpriv _privg_t; Crx_maxpriv _privg_t; Crx_inhpriv _privg_t; Crx_limpriv _privg_t; Crx_usedpriv _privg_t; Crx_pad [31+1]int32; } type _ucred_ext2_t struct { crx2_labels _sec_labels_t; Crx_pad [147+1]int32; } ^ sysinfo.go:10171:346: error: expected declaration Could this be a complaint about missing declaration of the _priv_t type, defined by priv.h on AIX?
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #9 from Segher Boessenkool --- Ah, that might be the difference. My powerpc-elf build worked just fine; trying to build powerpc-rtems4.12 now.
[Bug fortran/77872] [5/6/7 Regression] ICE in gfc_conv_descriptor_token, at fortran/trans-array.c:305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77872 --- Comment #5 from vehre at gcc dot gnu.org --- Created attachment 39933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39933&action=edit Fix the ICE The patch fixes the ICE. Albeit I am not happy with it. I fear it is too short and will open other deficiencies.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #10 from Segher Boessenkool --- Doesn't fail with powerpc-rtems4.12 either. Are you sure you built trunk? A clean build?
[Bug c/78000] -Wimplicit-function-declaration inhibited with macro from system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78000 --- Comment #4 from Marek Polacek --- No, that won't work, there are some fails.
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from vehre at gcc dot gnu.org --- Now closing.
[Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCE=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51864 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #17 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug fortran/61376] Error using private statement in polymorphic derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61376 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from vehre at gcc dot gnu.org --- No complaints so far, closing.
[Bug tree-optimization/77860] [7 Regression] ICE in gimple_build_assign_1, at gimple.c:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77860 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon Oct 31 16:36:53 2016 New Revision: 241706 URL: https://gcc.gnu.org/viewcvs?rev=241706&root=gcc&view=rev Log: PR tree-optimization/77860 * tree-ssa-reassoc.c (eliminate_using_constants): Handle also integral complex and vector constants. * gcc.dg/pr77860.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr77860.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug c++/77948] Option processing of -std=c++11 -std=gnu++11 doesn't reset ext_numeric_literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77948 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Oct 31 16:38:21 2016 New Revision: 241707 URL: https://gcc.gnu.org/viewcvs?rev=241707&root=gcc&view=rev Log: PR c++/77948 * c.opt (fext-numeric-literals): Add Var and Init. * c-opts.c (c_common_handle_option): Don't clear cpp_opts->ext_numeric_literals for -std=c++{11,14,1z}. (c_common_post_options): Clear it here if not set explicitly. * g++.dg/cpp0x/pr77948-1.C: New test. * g++.dg/cpp0x/pr77948-2.C: New test. * g++.dg/cpp0x/pr77948-3.C: New test. * g++.dg/cpp0x/pr77948-4.C: New test. * g++.dg/cpp0x/pr77948-5.C: New test. * g++.dg/cpp0x/pr77948-6.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-1.C trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-3.C trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-4.C trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-5.C trunk/gcc/testsuite/g++.dg/cpp0x/pr77948-6.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/testsuite/ChangeLog
[Bug c++/78089] __builtin_shuffle parsing bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78089 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Mon Oct 31 17:08:36 2016 New Revision: 241710 URL: https://gcc.gnu.org/viewcvs?rev=241710&root=gcc&view=rev Log: PR c++/78089 * parser.c (cp_parser_postfix_expression): Replace return statement in the first switch with setting postfix_expression to the return expression and break;. * c-c++-common/builtin-shuffle-1.c: New test. * g++.dg/cpp0x/addressof3.C: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-shuffle-1.c trunk/gcc/testsuite/g++.dg/cpp0x/addressof3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Mon Oct 31 17:10:30 2016 New Revision: 241711 URL: https://gcc.gnu.org/viewcvs?rev=241711&root=gcc&view=rev Log: PR c++/77886 * pt.c (tsubst_expr) Copy over FALLTHROUGH_LABEL_P flag to the new LABEL_DECL. (tsubst_expr) : Likewise. * g++.dg/warn/Wimplicit-fallthrough-2.C: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug c++/78173] New: Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 Bug ID: 78173 Summary: Hard error subtracting pointers to incomplete type in SFINAE context Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Casey at Carter dot net Target Milestone: --- Created attachment 39934 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39934&action=edit Minimal repro This TU, which should compile without errors: template T&& declval(); template using void_t = void; template struct foo { static const bool value = false; }; template struct foo() - declval())>> { static const bool value = true; }; struct A; #define STATIC_ASSERT(...) static_assert(__VA_ARGS__, #__VA_ARGS__) STATIC_ASSERT(!foo::value); // error: invalid use of 'void' STATIC_ASSERT(!foo::value); // error: invalid use of incomplete type 'struct A' instead produces diagnostics (http://melpon.org/wandbox/permlink/EwcDiz7ZuqpFXdHZ): prog.cc: In substitution of 'template struct foo() - declval()))> > [with T = void*]': prog.cc:22:1: required from here prog.cc:10:44: error: invalid use of 'void' struct foo() - declval())>> { ~^~ prog.cc: In substitution of 'template struct foo() - declval()))> > [with T = A*]': prog.cc:23:1: required from here prog.cc:10:44: error: invalid use of incomplete type 'struct A' prog.cc:14:8: note: forward declaration of 'struct A' struct A; ^
[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[6 Regression] |[6/7 Regression] |hash.c:1887:1: error: |hash.c:1887:1: error: |unrecognizable insn |unrecognizable insn --- Comment #2 from Jeffrey A. Law --- ISTM this fails on the trunk as well and thus is a regression for gcc-7 as well. I think tracking down why we generate the (plus (mult)) variant is probably wiser than adding the patterns back. Based on insn 424 being recognized, I would hazard a guess it's something in the predicate that didn't get changed/fixed during the transition.
[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166 --- Comment #3 from Jeffrey A. Law --- Hmm, clearly it helps to read the old thread. Canonicalization rules are that outside a MEM we use ASHIFT and within a MEM we use MULT. So recognizing the MULT seems reasonable. So presumably what's happening is we want to reload the address expression. That means emitting something like (set (temp) (address expression)) Which means we want to emit using the ASHIFT rather than the MULT form. Ugh. I'm not sure teaching reload about that is wise. Let me think a bit. And, no LEGITIMIZE_RELOAD_ADDRESS is not the answer ;-)
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #30 from Richard Earnshaw --- (In reply to wilco from comment #29) > Combine could help with > merging 2 loads/stores into a single instruction. No, combine works strictly on dataflow dependencies. Two stores cannot be dataflow related so won't be combined. Loads would only be dataflow related if both loads fed into *exactly* one data-processing instruction after the split. That's unlikely to happen so I very much dobut it would happen there either.
[Bug fortran/78171] example with undefined symbol compiles with '-O1 -fcheck=pointer'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78171 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Patrick Seewald from comment #0) > This should not compile because 'foo' is undefined: > > PROGRAM example > IMPLICIT NONE > REAL, ALLOCATABLE, DIMENSION(:) :: array > CALL foo(array) > END PROGRAM example > > However it compiles with 'gfortran -O1 -fcheck=pointer example.f90'. If I > run the executable, I get: > > At line 4 of file example.f90 > Fortran runtime error: Allocatable actual argument 'array' is not allocated A Fortran processor is not required to diagnosis this problem. It is the programmers responsibility to ensure that 'array' has been allocated before it is referenced. F2008, p. 129 An allocatable variable has a status of "unallocated" if it is not allocated. The status of an allocatable variable becomes unallocated if it is deallocated (6.7.3) or if it is given that status by the allocation transfer procedure. An allocatable variable with this status shall not be referenced or defined. It shall not be supplied as an actual argument corresponding to a nonallocatable dummy argument, except to certain intrinsic inquiry functions. Those "shall not"s in the above passage from the standard are prohibitions on the programmer. While the above code is trivial and doing a compile-time check may seem easy, it is rather daunting in a general case and can to lead to a substantial performance impact for correctly written code. This is why '-fcheck = ' exists. It allows a programmer to turn on additional checking, and should be used during development and testing.
[Bug target/78166] [6/7 Regression] hash.c:1887:1: error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166 --- Comment #4 from dave.anglin at bell dot net --- On 2016-10-31 1:32 PM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78166 > > --- Comment #3 from Jeffrey A. Law --- > Hmm, clearly it helps to read the old thread. > > Canonicalization rules are that outside a MEM we use ASHIFT and within a MEM > we > use MULT. So recognizing the MULT seems reasonable. So presumably what's > happening is we want to reload the address expression. That means emitting > something like Currently,we allow scaled-indexed DFmode memory operands for 32-bit targets. So, the address needs reloading when the value needs loading to an integer register. We don't allow these for DImode as reloading would almost always be needed. Still, we have the shift-add instructions to handle this case, so maybe this would generate better code in the end. Probably, I changed this causing the regression. > > (set (temp) (address expression)) We could change pa_emit_move_sequence, but it's already very complex. Essentially, the stuff that you added to hppa_legitimize_address would be needed > > Which means we want to emit using the ASHIFT rather than the MULT form. Ugh. > I'm not sure teaching reload about that is wise. Let me think a bit. And, > no > LEGITIMIZE_RELOAD_ADDRESS is not the answer ;-) > Thought's what I thought. I don't know how to direct reload to generate ASHIFT instead of MULT. Adding the MULT patterns fixes the compile error. Dave
[Bug fortran/71902] [5/6 Regression] Unneeded temporary on reallocatable character assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71902 --- Comment #10 from Thomas Koenig --- Author: tkoenig Date: Mon Oct 31 18:28:11 2016 New Revision: 241717 URL: https://gcc.gnu.org/viewcvs?rev=241717&root=gcc&view=rev Log: 2016-10-31 Thomas Koenig Backport from trunk PR fortran/71902 * frontend-passes.c (realloc_string_callback): Also check for the lhs being deferred. Name temporary variable "realloc_string". 2016-10-31 Thomas Koenig Backport from trunk PR fortran/71902 * gfortran.dg/dependency_47.f90: New test. * gfortran.dg/dependency_49.f90: New test Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/dependency_47.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/dependency_49.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/frontend-passes.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/78171] example with undefined symbol compiles with '-O1 -fcheck=pointer'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78171 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Just for clarification, since checking was called for, internally gfortran generates the following: array.data = 0B; if ((integer(kind=8)) ((real(kind=4)[0:] * restrict) array.data == 0B)) { _gfortran_runtime_error_at (&"At line 4 of file pr78171.f90"[1]{lb: 1 sz: 1}, &"Allocatable actual argument \'array\' is not allocated"[1]{lb: 1 sz: 1}); } foo ((real(kind=4)[0:] * restrict) array.data); The optimizer, which comes after, knows array.dat is NULL. Therefore, no matter what, _gfortran_runtime_error_at will always be executed. The optimizer also knows that _gfortran_runtime_error_at does not return, it exits with a status value of 2. As a consequence, foo will never be called and it is optimized away. So this is really not a bug in the compiler.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #31 from Bernd Edlinger --- Sure, combine cant help, especially because it runs before split1. But I wondered why this peephole2 is not enabled: (define_peephole2 ; ldrd [(set (match_operand:SI 0 "arm_general_register_operand" "") (match_operand:SI 2 "memory_operand" "")) (set (match_operand:SI 1 "arm_general_register_operand" "") (match_operand:SI 3 "memory_operand" ""))] "TARGET_LDRD && current_tune->prefer_ldrd_strd && !optimize_function_for_size_p (cfun)" [(const_int 0)] I have -march=armv7-a / -mcpu=cortex-a9 and thus for me current_tune-> prefer_ldrd_strd is FALSE. Furthermore, if I want to do -Os the third condition is FALSE too. But one ldrd must be shorter than two ldr ? That seems wrong...
[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||carll at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Carl Love --- Issue is resolved. Closing bug.
[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Carl Love --- Closing issue
[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Mon Oct 31 19:59:04 2016 New Revision: 241720 URL: https://gcc.gnu.org/viewcvs?rev=241720&root=gcc&view=rev Log: 2016-10-31 Jerry DeLisle PR fortran/54679 * io.c (check_format): Adjust checks for FMT_L to treat a zero width as an extension, giving warnings or error as appropriate. Improve messages. PR libgfortran/54679 * io/format.c (parse_format_list): Adjust checks for FMT_L to treat a zero width as an extension, giving warnings or error as appropriate. Improve messages. PR fortran/54679 * gfortran.dg/fmt_l.f90: Update test. * gfortran.dg/fmt_l0.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_l0.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_l.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerry DeLisle --- Closing, fixed on trunk. I dont see a strong need to backport this, but if someelse does, just let me know.
[Bug libstdc++/78167] experimental/filesystem calls behave differently between Linux gcc 5.3.0 and Windows Visual Studio 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78167 --- Comment #2 from David Bjornbak --- gcc 6.2.0 is Ok for this issue, my unit tests pass. Is there's patch available to address this issue with the 5.x versions of gcc?
[Bug debug/77315] emit DW_OP_form_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315 --- Comment #2 from Tom Tromey --- Author: tromey Date: Mon Oct 31 20:08:44 2016 New Revision: 241721 URL: https://gcc.gnu.org/viewcvs?rev=241721&root=gcc&view=rev Log: PR debug/77315: * dwarf2out.c (mem_loc_descriptor): Use DW_OP_form_tls_address. (resolve_args_picking_1): Move DW_OP_form_tls_address case next to DW_OP_GNU_push_tls_address case. (loc_list_from_tree_1): Use DW_OP_form_tls_address. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug c++/55958] vtable hidden when compiling with -fvisibility-ms-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55958 Andrew Sayman changed: What|Removed |Added CC||andrew.sayman at gmail dot com --- Comment #3 from Andrew Sayman --- I can confirm that this is still an issue with GCC 6.1. The default behavior in visibility-ms-compat is not compatible with visual studio. It should not be required to annotate the class when in this mode.
[Bug debug/77315] emit DW_OP_form_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315 Tom Tromey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Tom Tromey --- Fixed.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #32 from Wilco --- (In reply to Bernd Edlinger from comment #31) > Sure, combine cant help, especially because it runs before split1. > > But I wondered why this peephole2 is not enabled: > > (define_peephole2 ; ldrd > [(set (match_operand:SI 0 "arm_general_register_operand" "") > (match_operand:SI 2 "memory_operand" "")) >(set (match_operand:SI 1 "arm_general_register_operand" "") > (match_operand:SI 3 "memory_operand" ""))] > "TARGET_LDRD > && current_tune->prefer_ldrd_strd > && !optimize_function_for_size_p (cfun)" > [(const_int 0)] > > > I have -march=armv7-a / -mcpu=cortex-a9 and thus for me > current_tune-> prefer_ldrd_strd is FALSE. > > Furthermore, if I want to do -Os the third condition is FALSE too. > But one ldrd must be shorter than two ldr ? > > That seems wrong... Indeed, on a target that supports LDRD you want to use LDRD if legal. LDM should only be tried on Thumb-1. Emitting LDRD from a peephole when the offset is in range will never increase code size so should always be enabled.
[Bug libfortran/78123] Short reads with T edit descriptor not padding correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78123 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Mon Oct 31 20:57:16 2016 New Revision: 241722 URL: https://gcc.gnu.org/viewcvs?rev=241722&root=gcc&view=rev Log: 2016-10-31 Jerry DeLisle Backport from trunk PR libgfortran/78123 * io/transfer.c (formatted_transfer_scalar_read): Clear seen_eor only if we have tabbed to left of current position. Backport from trunk PR fortran/78123 * gfortran.dg/fmt_t_9.f: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/fmt_t_9.f Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/libgfortran/ChangeLog branches/gcc-6-branch/libgfortran/io/transfer.c
[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78169 --- Comment #2 from Daniel Black --- Yes, using a x86_84 -> x86_64 cross compiler. Built with `ct-ng x86_64-unknown-linux-gnu`
[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78169 Daniel Black changed: What|Removed |Added Target||x86_64-unknown-linux-gnu-gc ||c / ||powerpc64le-unknown-linux-g ||nu-gcc --- Comment #3 from Daniel Black --- also fails in powerpc64le (cross compile to same arch)
[Bug c/78174] New: out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174 Bug ID: 78174 Summary: out of bounds array subscript in rtl.h NOTE_DATA macro Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- As discussed in https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02498.html: A patch to enhance buffer overflow warnings (and c/53562) exposed a problem in the definition of the NOTE_DATA macro defined in the GCC rtl.h header. The macro expands to a reference to a non-existent element 3 of the one-element rtx_note::rtx_insn::rtx_def::u.fld array, like so: memset (&((note)->u.fld[3]), 0, sizeof (((note)->u.fld[3]))); note is a pointer to rtx_note. The computed address, while outside the array, is within the boundaries of the larger rtx_note object in which the array is declared and so it is not invalid in and of itself, but deriving the address this way is undefined. The patch, which enhances memcpy and other functions to detect and warn on writes past the end of an object (similarly to __builtin___memcpy_chk et al.), detects that the subscript is out of bounds of the array from which it was derived and issues a warning. To avoid the warning the address should be computed/derived not from the array but rather from the surrounding object, for example like so: char *p = (char*) &(note)->u.fld[0]; p += sizeof (((note)->u.fld[0])) * 3; memset (p, 0, sizeof *p);
[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174 --- Comment #1 from Andrew Pinski --- I think the warning is not called for and here is why. There is no way in both C89 and C++ (in C99 there is) to say the array at the end of a struct (even inside an union) is a variable length. So GCC decided that any array at the end of a structure (even inside an union or another stucture) can be considered a variable length array. See https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Zero-Length.html .
[Bug ada/78175] New: [Ada] Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78175 Bug ID: 78175 Summary: [Ada] Storage_Error stack overflow or erroneous memory access Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: kendall at bellsoft dot net Target Milestone: --- Created attachment 39935 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39935&action=edit bug source gnatmake -gnatwa -I../src list_words gcc-5 -c -gnatwa -I../src list_words.adb +===GNAT BUG DETECTED==+ | 5.2.1 20151010 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous memory access| | Error detected at list_words.adb:25:4| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). list_words.adb ../src/bragi.ads ../src/bragi-translate_words.ads compilation abandoned gnatmake: "list_words.adb" compilation error gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
[Bug libfortran/78123] Short reads with T edit descriptor not padding correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78123 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Mon Oct 31 23:40:40 2016 New Revision: 241727 URL: https://gcc.gnu.org/viewcvs?rev=241727&root=gcc&view=rev Log: 2016-10-31 Jerry DeLisle Backport from trunk PR libgfortran/78123 * io/transfer.c (formatted_transfer_scalar_read): Clear seen_eor only if we have tabbed to left of current position. Backport from trunk PR fortran/78123 * gfortran.dg/fmt_t_9.f: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/fmt_t_9.f Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/libgfortran/ChangeLog branches/gcc-5-branch/libgfortran/io/transfer.c
[Bug libfortran/78123] Short reads with T edit descriptor not padding correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78123 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerry DeLisle --- Fixed on 5, 6, and 7, Closing, thanks for the report
[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174 --- Comment #2 from Martin Sebor --- The problem can be reduced to the following test case that triggers the warning even with unpatched GCC (and prior releases). $ cat b.c && g++ -O2 -S -Wall b.c struct A { int i, j; }; struct B { int i0, j0, i1, j1, i2, j2, i3, j3, i4, j4; }; struct C { union { struct A a[1]; struct B b; } u; }; struct D: C { }; void f (struct D *d) { struct A *p = &d->u.a[3]; __builtin___memset_chk (p, 0, sizeof *p, __builtin_object_size (p, 1)); } b.c: In function ‘void f(D*)’: b.c:17:73: warning: call to void* __builtin___memset_chk(void*, int, long unsigned int, long unsigned int) will always overflow destination buffer __builtin___memset_chk (p, 0, sizeof *p, __builtin_object_size (p, 1)); ^ Such code is undefined under the C++ (and C) standard rules. (Curiously, GCC doesn't issue the warning for an equivalent function that takes struct C* as an argument.) The same warning is also emitted when the memset call in emit-rtl.c is replaced with a __builtin___memset_chk call corresponding to the one above. The patch that triggers the warning simply enables the same compile-time checking for memset as is done by __builtin___memset_chk with type-1 object size checking. I see that Glibc uses type-0 checking for memset even with _FORTIFY_SOURCE=2, so the patch could either be changed to do the same or enhanced to let users specify the __builtin_object_size checking type, and perhaps even a different type for raw memory functions like memset and for string functions, to make it possible to fine-tune the checking to the state of the code base and avoid issuing warnings for this kind of code in legacy software. I think those would be enhancements worth considering, but I also think that GCC itself should try to avoid relying on undefined behavior. GCC provides zero-length arrays as a substitute for flexible array members. In this case, the array has one (not zero) element. It would be nice if changing it to a zero-element array would let GCC treat it as a flexible array member on steroids so that users would have to opt in to relying on an extension to avoid the warning here, but that's not the case. I realize that GCC sometimes treats even one element arrays (and even bigger if they're last) as zero-length even though that's not documented anywhere (AFAIK), but it would be nice to get away from that.
[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174 --- Comment #3 from Andrew Pinski --- (In reply to Martin Sebor from comment #2) > I realize > that GCC sometimes treats even one element arrays (and even bigger if > they're last) as zero-length even though that's not documented anywhere > (AFAIK), but it would be nice to get away from that. It was a decision not to document it as it was more of an extension which does not need to be documented (maybe it should be documented in an internals GCC documentation but it should not be documented in an external facing one as it is not recommended one to do). Also the other reason why it needs to be work still is that old code needs to work and we support many other code. Do we really have a class structure here in GCC's code?
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #1 from Ian Lance Taylor --- What does that whole line look like? It seems to be truncated in the output for some reason. Is _priv_t defined elsewhere in the file? That is, is there a line that starts with "type _priv_t "? If not, that will be a problem.
[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174 --- Comment #4 from Martin Sebor --- Yes, rtx_note derives from rtx_insn which derives from rtx_def which is where the union containing the one-element fld array is defined.
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #2 from David Edelsohn --- The error message is the complete line -- or at least the entire line that was communicated to me. priv_t is a type defined in AIX /usr/include/priv.h, which is included by cred.h. uid_t, gid_t and pid_t all are defined in types.h, as on Linux.
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #3 from Ian Lance Taylor --- If that is the complete line, then something has gone badly wrong. Can you get a copy of the complete generated sysinfo.go file?
[Bug libstdc++/78167] experimental/filesystem calls behave differently between Linux gcc 5.3.0 and Windows Visual Studio 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78167 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.2 --- Comment #3 from Andrew Pinski --- (In reply to David Bjornbak from comment #2) > gcc 6.2.0 is Ok for this issue, my unit tests pass. > > Is there's patch available to address this issue with the 5.x versions of > gcc? You can dig into what changes happened to this source but since this is an experimental part of the libstdc++ library I doubt we are going to fix it. We have no guarantees that this library part will even be part of C++17.
[Bug target/78118] xtensa: ICE in gcc-6.1.0/libgcc/libgcc2.c:1992:1: error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78118 --- Comment #3 from jcmvbkbc at gcc dot gnu.org --- Created attachment 39936 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39936&action=edit tentative patch