[Bug tree-optimization/87245] [missed optimization] switching on indices of struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87245 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug tree-optimization/14799] [tree-ssa] convert a sequence of "if"s to a "switch" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799 Andrew Pinski changed: What|Removed |Added CC||eyalroz at technion dot ac.il --- Comment #5 from Andrew Pinski --- *** Bug 87925 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87925] [missed-optimization] Distinct-value if-then-else chains treated differently than switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- Dup of a much older bug (PR 14799) ... *** This bug has been marked as a duplicate of bug 14799 ***
[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> /* (m1 CMP m2) * d -> (m1 CMP m2) ? d : 0 */
> (for cmp (gt lt ge le)
> (simplify
> (mult (convert (cmp @0 @1)) @2)
> (cond (cmp @0 @1) @2 { build_zero_cst (type); })))
>
>
> Should have caught that ...
We do get:
_1 = c_5(D) < d_6(D);
_2 = (int) _1;
_7 = a_3(D) < b_4(D) ? _2 : 0;
[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
--- Comment #4 from Andrew Pinski ---
/* (m1 CMP m2) * d -> (m1 CMP m2) ? d : 0 */
(for cmp (gt lt ge le)
(simplify
(mult (convert (cmp @0 @1)) @2)
(cond (cmp @0 @1) @2 { build_zero_cst (type); })))
Should have caught that ...
NOTE I think that might have been broken for floating point
[Bug c++/87961] crash at goto label inside sizeof of a statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87961 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 17913 which was fixed in the C front-end in 2005 but it was never fixed in the C++ front-end (the front-ends share some code but not all).
[Bug middle-end/87941] by_pieces infra does not use movmisalign optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87941 Andrew Pinski changed: What|Removed |Added Target||arm*-*-* Component|rtl-optimization|middle-end Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- by_pieces was written before movmisalign_optab even was thought of.
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 --- Comment #3 from Eric Gallager --- (In reply to David Malcolm from comment #2) > (In reply to richard.earnshaw from comment #1) > > On 09/08/18 21:08, dmalcolm at gcc dot gnu.org wrote: > [...snip...] > > > Maybe: > > > -fdiagnostics-x-coord=bytes : count of bytes > > > -fdiagnostics-x-coord=characters : count of characters (not > > > special-casing > > > tab) > > > -fdiagnostics-x-coord=columns : count of columns: as per characters, > > > but with > > > tabs doing tabstops > > > > how about -fdiagnostics-x-coord=visual-[n] > > > > Where n is the size of a hard tab? Some folks change the tab stop to 4, > > for example. Or maybe ...coord=tab[-n], where -n defaults to "-8". > > The C family of frontends already has: > -ftabstop= Distance between tab stops for column reporting. > which IIRC is currently only used by -Wmisleading-indentation. I guess it > could be moved to common.opt. Yeah, using -ftabstop makes sense
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #9 from Gary Mills --- Okay, I'm compiling it with -O0 right now. It might take a couple of days.
[Bug c/87964] c-attribs.c:3965: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87964 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-10 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Yes, that's a cut & paste mistake, thanks. I'll take care of it.
[Bug libfortran/87966] [9 regression] The SPEC2006 tests 416.gamess and 481.wrf fail starting with r265946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87966
--- Comment #1 from Jerry DeLisle ---
I had a leftover printf statement for debugging in the initial commit last
night which I fixed this morning.
Let me know if the problem persists. The line was:
printf("allow_std=%d\n", compile_options.warn_std);
Which would have generated some extraneous output to stdout during a read.
The patch does not touch any floating point operations.
[Bug testsuite/87965] [9 regression] Test cases c-c++-common/pr60226.c and gcc.dg/pr39323-1.c fail starting with r265977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87965 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Nov 9 23:15:59 2018 New Revision: 265998 URL: https://gcc.gnu.org/viewcvs?rev=265998=gcc=rev Log: gcc/testsuite/ChangeLog: PR testsuite/87965 * c-c++-common/pr60226.c: Adjust text of expected diagnostic. * gcc.dg/pr39323-1.c: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr60226.c trunk/gcc/testsuite/gcc.dg/pr39323-1.c
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #8 from Eric Botcazou --- > That's the immediate cause of the ICE. I haven't identified the root cause > yet. I'm wondering, though, why the compiler built and ran on x86 hardware, > but failed on SPARC hardware. One difference is that the configuration on > SPARC hardware uses the native assembler. On x86 hardware, it uses the GNU > assembler. That's the only configuration difference. One possibility is that the base compiler miscompiles the stage #1 compiler. In order to rule it out, we need to make sure that the base compiler is invoked with optimization disabled, hence my request about the flags...
[Bug testsuite/87965] [9 regression] Test cases c-c++-common/pr60226.c and gcc.dg/pr39323-1.c fail starting with r265977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87965 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Martin Sebor --- Fixed in r265998.
[Bug testsuite/87965] [9 regression] Test cases c-c++-common/pr60226.c and gcc.dg/pr39323-1.c fail starting with r265977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87965 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-09 Component|c |testsuite Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. The failures are due to changing the text of the warning. Somehow I missed them in my testing.
[Bug c++/87967] New: ice in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967
Bug ID: 87967
Summary: ice in slpeel_duplicate_current_defs_from_edges
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
void h();
template struct k { using d = b; };
template class> using e = k;
template class f>
using g = typename e::d;
struct l {
template using ab = typename i::j;
};
struct n : l {
using j = g;
};
class o {
public:
long r();
};
char m;
char s() {
if (m)
return '0';
return 'A';
}
class t {
public:
typedef char *ad;
ad m_fn2();
};
void fn3() {
char *a;
t b;
bool p = false;
while (*a) {
h();
o c;
if (*a)
a++;
if (c.r()) {
n::j q;
for (t::ad d = b.m_fn2(), e; d != e; d++) {
char f = *q;
*d = f + s();
}
p = true;
}
}
if (p)
throw;
}
compiled with recent gcc trunk and compiler flag -O3, does this:
during GIMPLE pass: vect
bug476.cc: In function ‘void fn3()’:
bug476.cc:27:6: internal compiler error: Segmentation fault
27 | void fn3() {
| ^~~
0xfa4967 crash_signal
../../trunk/gcc/toplev.c:325
0x12185e4 contains_struct_check(tree_node*, tree_node_structure_enum, char
const
*, int, char const*)
../../trunk/gcc/tree.h:3267
0x12185e4 slpeel_duplicate_current_defs_from_edges
../../trunk/gcc/tree-vect-loop-manip.c:985
The bug seems to have appeared between revision 265790 and 265846.
[Bug libfortran/87966] New: [9 regression] The SPEC2006 tests 416.gamess and 481.wrf fail starting with r265946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87966 Bug ID: 87966 Summary: [9 regression] The SPEC2006 tests 416.gamess and 481.wrf fail starting with r265946 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The test trigger some floating point exceptions when they are run after being compiler with gcc built from r265946. /home/seurer/gcc/cpu2006/bin/specinvoke -E -d /home/seurer/gcc/cpu2006/benchspec/CPU2006/416.gamess/run/run_base_ref_ppc64.0018 -c 1 -e compare.err -o compare.stdout -f compare.cmd Contents of h2ocu2+.gradient.err Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG Contents of triazolium.err Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG r265946 | jvdelisle | 2018-11-08 20:46:03 -0600 (Thu, 08 Nov 2018) | 7 lines 2018-11-08 Jerry DeLisle PR libfortran/78351 * io/transfer.c (read_sf_internal): Add support for early comma termination of internal unit formatted reads. * gfortran.dg/read_legacy_comma.f90: New test.
[Bug c/87965] New: [9 regression] Test cases c-c++-common/pr60226.c and gcc.dg/pr39323-1.c fail starting with r265977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87965 Bug ID: 87965 Summary: [9 regression] Test cases c-c++-common/pr60226.c and gcc.dg/pr39323-1.c fail starting with r265977 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- > FAIL: c-c++-common/pr60226.c -Wc++-compat (test for errors, line 14) > FAIL: c-c++-common/pr60226.c -Wc++-compat (test for errors, line 8) > FAIL: c-c++-common/pr60226.c -Wc++-compat (test for excess errors) > FAIL: c-c++-common/pr60226.c -std=gnu++14 (test for errors, line 14) > FAIL: c-c++-common/pr60226.c -std=gnu++14 (test for errors, line 8) > FAIL: c-c++-common/pr60226.c -std=gnu++14 (test for excess errors) > FAIL: c-c++-common/pr60226.c -std=gnu++17 (test for errors, line 14) > FAIL: c-c++-common/pr60226.c -std=gnu++17 (test for errors, line 8) > FAIL: c-c++-common/pr60226.c -std=gnu++17 (test for excess errors) > FAIL: c-c++-common/pr60226.c -std=gnu++98 (test for errors, line 14) > FAIL: c-c++-common/pr60226.c -std=gnu++98 (test for errors, line 8) > FAIL: c-c++-common/pr60226.c -std=gnu++98 (test for excess errors) > FAIL: gcc.dg/pr39323-1.c (test for errors, line 4) > FAIL: gcc.dg/pr39323-1.c (test for errors, line 5) > FAIL: gcc.dg/pr39323-1.c (test for excess errors) They look like alignment errors. spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -Wc++-compat -Wno-c++-compat -S -o pr60226.s /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c:7:1: error: alignment of array elements is greater than element size /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c:8:1: error: requested alignment '536870912' exceeds maximum 2147483648 /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c: In function 'f': /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c:14:10: error: requested alignment '536870912' exceeds maximum 2147483648 compiler exited with status 1 PASS: c-c++-common/pr60226.c -Wc++-compat (test for errors, line 7) FAIL: c-c++-common/pr60226.c -Wc++-compat (test for errors, line 8) FAIL: c-c++-common/pr60226.c -Wc++-compat (test for errors, line 14) FAIL: c-c++-common/pr60226.c -Wc++-compat (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c:8:1: error: requested alignment '536870912' exceeds maximum 2147483648 /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/pr60226.c:14:10: error: requested alignment '536870912' exceeds maximum 2147483648 spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr39323-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -ansi -pedantic-errors -S -o pr39323-1.s /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr39323-1.c:4:1: error: requested alignment '536870912' exceeds object file maximum 268435456 /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr39323-1.c:5:1: error: requested alignment '536870912' exceeds maximum 2147483648 compiler exited with status 1 FAIL: gcc.dg/pr39323-1.c (test for errors, line 4) FAIL: gcc.dg/pr39323-1.c (test for errors, line 5) FAIL: gcc.dg/pr39323-1.c (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr39323-1.c:4:1: error: requested alignment '536870912' exceeds object file maximum 268435456 /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr39323-1.c:5:1: error: requested alignment '536870912' exceeds maximum 2147483648
[Bug c++/87947] Symbol Does Not Appear in Object File
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87947 --- Comment #2 from comm+gnu at squotd dot net --- Thanks. I had no idea that had changed.
[Bug c++/87850] Add fix-it hint for "invalid conversion from 'X' to 'X*'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87850 David Malcolm changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-11/msg00802.ht ||ml Last reconfirmed||2018-11-09 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00802.html
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #7 from Gary Mills --- I'm still waiting for information on how to use gdb to check the alignment of the structures involved in this ICE. I had to RTFM and experiment. Here's the result: $ /usr/bin/sparcv7/gdb build/sparcv7/./gcc/cc1 core ... (gdb) bt ... #9 #10 et_splay (occ=occ@entry=0x0) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:311 #11 0x00361834 in et_set_father (t=0xeaf810, father=0xeaf808) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:525 #12 0x00301e6c in calculate_dominance_info (dir=dir@entry=CDI_DOMINATORS) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/dominance.c:658 #13 0x006701cc in cleanup_tree_cfg_noloop () at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:759 #14 cleanup_tree_cfg () at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:818 #15 0x0066ab88 in execute_build_cfg () at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:360 #16 (anonymous namespace)::pass_build_cfg::execute (this=) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:389 #17 0x0056a7e0 in execute_one_pass (pass=pass@entry=0xe30408) ---Type to continue, or q to quit--- at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2336 #18 0x0056ad80 in execute_pass_list_1 (pass=0xe30408, pass@entry=0xe2e938) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2420 #19 0x0056ae1c in execute_pass_list (fn=0xfb410068, pass=0xe2e938) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2431 #20 0x002c8e18 in cgraph_node::analyze (this=this@entry=0xfb4a6000) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:636 #21 0x002cc2b0 in analyze_functions (first_time=first_time@entry=true) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:1086 #22 0x002cc9d0 in symbol_table::finalize_compilation_unit (this=0xfb41) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:2554 #23 0x006321e4 in compile_file () at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:488 #24 0x00633f28 in do_compile () at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:2014 ---Type to continue, or q to quit--- #25 toplev::main (this=this@entry=0xffbff91e, argc=, argc@entry=19, argv=, argv@entry=0xffbff984) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:2123 #26 0x00adcc28 in main (argc=19, argv=0xffbff984) at /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/main.c:39 (gdb) q So, it wasn't an alignment error after all. It was the most common thing that causes a bus error: dereferencing a null pointer. The backtrace shows that et_splay() was called with a NULL operand, occ. That NULL pointer was dereferenced by this line: 311 while (occ->parent) In et_set_father(), the et_splay() function was called with the operand rmost, which must also be NULL. That's the immediate cause of the ICE. I haven't identified the root cause yet. I'm wondering, though, why the compiler built and ran on x86 hardware, but failed on SPARC hardware. One difference is that the configuration on SPARC hardware uses the native assembler. On x86 hardware, it uses the GNU assembler. That's the only configuration difference. The hardware is different, of course.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #12 from Segher Boessenkool --- Wow, this works! Mine :-)
[Bug libstdc++/87963] libstdc++-v3/src/c++17/memory_resource.cc:515:31: error: static assertion failed for mingw-w64 target since r265853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87963 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-09 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at redhat dot com
[Bug c/87964] New: c-attribs.c:3965: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87964
Bug ID: 87964
Summary: c-attribs.c:3965: possible cut'n'paste error ?
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Source code is
else if (!strcmp ("const", namestr))
{
if (expr && DECL_P (expr))
found_match = TREE_READONLY (expr);
}
else if (!strcmp ("const", namestr))
{
if (expr && DECL_P (expr))
found_match = DECL_PURE_P (expr);
}
svn blame says
265980 msebor else if (!strcmp ("const", namestr))
265980 msebor {
265980 msebor if (expr && DECL_P (expr))
265980 msebor found_match = TREE_READONLY (expr);
265980 msebor }
265980 msebor else if (!strcmp ("const", namestr))
265980 msebor {
265980 msebor if (expr && DECL_P (expr))
265980 msebor found_match = DECL_PURE_P (expr);
265980 msebor }
[Bug driver/41179] Documentation for "-fno-toplevel-reorder" is confusing (and wrong)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41179 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- Fixed on trunk, at least for the 3 cases explicitly mentioned in this issue.
[Bug middle-end/65703] -fdefer-pop documentation is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65703 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- I've fixed the problem with the wording of the -fno-defer-pop documentation. The other problem raised in this issue was the difficulty in locating documentation for the positive form -fdefer-pop. I'm going to address this in general by adding an @opindex entry for the positive form of all "no-" options so searching the document will at least turn up a hit in the index that will get you to the right place.
[Bug target/87221] cannot build with -pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Should be fixed on the trunk.
[Bug target/87221] cannot build with -pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221 --- Comment #4 from Jeffrey A. Law --- Author: law Date: Fri Nov 9 20:55:39 2018 New Revision: 265994 URL: https://gcc.gnu.org/viewcvs?rev=265994=gcc=rev Log: PR target/87221 * config/netbsd-elf.h (NETBSD_STARTFILE_SPEC): Use crtbeginS.o for PIE. (NETBSD_ENDFILE_SPEC): Use crtendS.o for PIE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/netbsd-elf.h
[Bug driver/41179] Documentation for "-fno-toplevel-reorder" is confusing (and wrong)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41179 --- Comment #4 from sandra at gcc dot gnu.org --- Author: sandra Date: Fri Nov 9 20:45:06 2018 New Revision: 265993 URL: https://gcc.gnu.org/viewcvs?rev=265993=gcc=rev Log: 2018-11-09 Sandra Loosemore PR driver/41179 PR middle-end/65703 gcc/ * doc/invoke.texi (Optimize Options): Clarify default behavior for -fno-toplevel-reorder, -fno-defer-pop, and -fno-branch-count-reg. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug middle-end/65703] -fdefer-pop documentation is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65703 --- Comment #3 from sandra at gcc dot gnu.org --- Author: sandra Date: Fri Nov 9 20:45:06 2018 New Revision: 265993 URL: https://gcc.gnu.org/viewcvs?rev=265993=gcc=rev Log: 2018-11-09 Sandra Loosemore PR driver/41179 PR middle-end/65703 gcc/ * doc/invoke.texi (Optimize Options): Clarify default behavior for -fno-toplevel-reorder, -fno-defer-pop, and -fno-branch-count-reg. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug tree-optimization/87940] [9 Regression] FAIL: gcc.dg/warn-strlen-no-nul.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87940 Bernd Edlinger changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Bernd Edlinger --- Fixed. Thanks!
[Bug tree-optimization/87940] [9 Regression] FAIL: gcc.dg/warn-strlen-no-nul.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87940 --- Comment #2 from Bernd Edlinger --- Author: edlinger Date: Fri Nov 9 20:38:07 2018 New Revision: 265992 URL: https://gcc.gnu.org/viewcvs?rev=265992=gcc=rev Log: 2018-11-09 Bernd Edlinger PR tree-optimization/87940 * expr.c (string_constant): Don't strip NOPS in subexpressions. Fold PLUS_EXPR correctly. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug libstdc++/87963] New: libstdc++-v3/src/c++17/memory_resource.cc:515:31: error: static assertion failed for mingw-w64 target since r265853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87963
Bug ID: 87963
Summary: libstdc++-v3/src/c++17/memory_resource.cc:515:31:
error: static assertion failed for mingw-w64 target
since r265853
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateuszb at poczta dot onet.pl
Target Milestone: ---
When I build cross compiler (trunk) for mingw-w64 x86_64 target (long is
4-bytes, pointer is 8-bytes), there are errors since r265853
libtool: compile: /home/ma/m/build/bc_gcc/./gcc/xgcc -shared-libgcc
-B/home/ma/m/build/bc_gcc/./gcc -nostdinc++
-L/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/home/ma/m/cross/x86_64-w64-mingw32/lib -L/home/ma/m/cross/mingw/lib -isystem
/home/ma/m/cross/x86_64-w64-mingw32/include -isystem
/home/ma/m/cross/mingw/include -B/home/ma/m/cross/x86_64-w64-mingw32/bin/
-B/home/ma/m/cross/x86_64-w64-mingw32/lib/ -isystem
/home/ma/m/cross/x86_64-w64-mingw32/include -isystem
/home/ma/m/cross/x86_64-w64-mingw32/sys-include
-I/home/ma/m/source/gcc-9/libstdc++-v3/../libgcc
-I/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/ma/m/source/gcc-9/libstdc++-v3/libsupc++ -std=gnu++17
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=memory_resource.lo -g -O2 -fimplicit-templates -c
/home/ma/m/source/gcc-9/libstdc++-v3/src/c++17/memory_resource.cc -o
memory_resource.o
/home/ma/m/source/gcc-9/libstdc++-v3/src/c++17/memory_resource.cc:515:31:
error: static assertion failed
515 | static_assert(sizeof(chunk) == (4 * sizeof(void*)), "");
| ~~^~
/home/ma/m/source/gcc-9/libstdc++-v3/src/c++17/memory_resource.cc:526:48:
warning: left shift count >= width of type [-Wshift-count-overflow]
526 | static constexpr size_t all_ones = (1ul << _S_sizebits) - 1u;
|^~~
/home/ma/m/source/gcc-9/libstdc++-v3/src/c++17/memory_resource.cc:526:45:
error: right operand of shift expression '(1 << 58)' is >= than the precision
of the left operand [-fpermissive]
526 | static constexpr size_t all_ones = (1ul << _S_sizebits) - 1u;
|~^~~
/home/ma/m/source/gcc-9/libstdc++-v3/src/c++17/memory_resource.cc: In member
function 'std::size_t std::pmr::{anonymous}::big_block::size() const':
/home/ma/m/source/gcc-9/libstdc++-v3/src/c++17/memory_resource.cc:548:5:
warning: control reaches end of non-void function [-Wreturn-type]
548 | }
| ^
Makefile:735: recipe for target 'memory_resource.lo' failed
make[4]: *** [memory_resource.lo] Error 1
[Bug target/87762] [9 Regression] extract_constrain_insn, at recog.c:2206 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762 --- Comment #4 from iii at gcc dot gnu.org --- Author: iii Date: Fri Nov 9 20:33:19 2018 New Revision: 265991 URL: https://gcc.gnu.org/viewcvs?rev=265991=gcc=rev Log: S/390: Allow relative addressing of literal pool entries r265490 allowed the compiler to choose in a more flexible way whether to use load or load-address-relative-long (LARL) instruction. When it chose LARL for literal pool references, the latter ones were rewritten by pass_s390_early_mach to use UNSPEC_LTREF, which assumes base register usage, which in turn is not compatible with LARL. The end result was an ICE because of unrecognizable insn. UNSPEC_LTREF and friends are necessary in order to communicate the dependency on the base register to pass_sched2. When relative addressing is used, no base register is necessary, so in such cases the rewrite must be avoided. gcc/ChangeLog: 2018-11-09 Ilya Leoshkevich PR target/87762 * config/s390/s390.c (s390_safe_relative_long_p): New function. (annotate_constant_pool_refs): Skip insns which support relative addressing. (annotate_constant_pool_refs_1): New helper function. (find_constant_pool_ref): Skip insns which support relative addression. (find_constant_pool_ref_1): New helper function. (replace_constant_pool_ref): Skip insns which support relative addressing. (replace_constant_pool_ref_1): New helper function. (s390_mainpool_start): Adapt to the new signature. (s390_mainpool_finish): Likewise. (s390_chunkify_start): Likewise. (s390_chunkify_finish): Likewise. (pass_s390_early_mach::execute): Likewise. (s390_prologue_plus_offset): Likewise. (s390_emit_prologue): Likewise. (s390_emit_epilogue): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #11 from Segher Boessenkool --- Trying that out now.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #10 from Segher Boessenkool --- (In reply to David Edelsohn from comment #7) > This sounds like the general problem of the first RA pass creating > excessively long live ranges. Yeah. > Does GCC know how to re-materialize a comparison? Not sure... Maybe secondary reloads can help? But there also is TARGET_SELECT_EARLY_REMAT_MODES nowadays, that sounds like just what we need here!
[Bug libstdc++/87787] [9 Regression][UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Nov 9 20:14:07 2018 New Revision: 265984 URL: https://gcc.gnu.org/viewcvs?rev=265984=gcc=rev Log: PR libstdc++/87787 fix UBsan error in std::vector PR libstdc++/87787 * include/bits/stl_uninitialized.h (__relocate_a_1): Do not call memmove when there's nothing to copy (and pointers could be null). Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_uninitialized.h
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #9 from Segher Boessenkool --- (In reply to meissner from comment #6) - Comment #4 from Bill Schmidt --- > > Seems like a potential opportunity for shrink-wrap separate on the CRs. I'm > > not sure whether that's implemented yet. > > Not really, since shrink wrap only occurs if the program has an early exit > condition. Separate shrink-wrapping can help in all cases where not all saves or restores are needed on every path through the function, not just in cases where on some path through the function *no* save/restore is needed.
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951
--- Comment #6 from Jonathan Wakely ---
(In reply to Vitali from comment #5)
> Jonathan, I think the defect report here does actually apply to this
> example.
I didn't say otherwise.
> I agree the argument could be made that if there's gaps in the enum
> values that it's arguable that the current GCC behaviour is standards
> compliant (clearly clang & GCC disagree on this for both C & C++ so unclear
> who's right or wrong in their interpretation of what's allowed).
No, it has nothing to do with "gaps" in the enum. This is a myth.
All that matters is the range of representable values, which (for an
enumeration without a fixed underlying type) depends on the number of bits
required to represent the minimum and maximum enumerator values. It doesn't
make any difference whatsoever whether there are "gaps" between those minimum
and maximum
values.
> However, in the example posted this is a "dense" enum.
What matters is that all the values of the enum can be represented in a single
bit, and so the only valid values are 0 and 1, which happen to have
enumerators. But the only valid values would still be 0 and 1 if your enum was
defined as
enum Enum { B=1 }; and so a switch that failed to handle the possibility of
Enum(0) would be wrong (even with -fstrict-enums)
The mental model of "dense" vs "gaps" is WRONG.
> There's no integer
> value possible that's not outside the range & yet GCC still continues to
> treat that as a possibility & thus missing optimization opportunities &
> generating false-positive warnings.
Yes, that's what -fstrict-enums is for.
The default (without -fstrict-enums) assumes most code is buggy and doesn't
follow the rules. If you do not use values outside the valid range of values
for the enumeration, use -fstrict-enums.
I can see some value in the suggestion to annotate a specific enumeration type
as strict, but that might not be the right solution. What matters is how the
enumeration type is used (whether invalid values are ever created) and that
isn't something you can guarantee when the enum is declared.
You *can* annotate the uses of a specific enum, but telling the compiler that
no other values will ever be used in the switch, by adding:
default:
__builtin_unreachable();
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #8 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #4) > Seems like a potential opportunity for shrink-wrap separate on the CRs. I'm > not sure whether that's implemented yet. It isn't; there are some technical problems to implement it. Nothing that cannot be overcome though. The benefit wouldn't be huge; a much bigger benefit can be had by not using non-volatile CR fields in the first place.
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #5 from Vitali --- Jonathan, I think the defect report here does actually apply to this example. I agree the argument could be made that if there's gaps in the enum values that it's arguable that the current GCC behaviour is standards compliant (clearly clang & GCC disagree on this for both C & C++ so unclear who's right or wrong in their interpretation of what's allowed). However, in the example posted this is a "dense" enum. There's no integer value possible that's not outside the range & yet GCC still continues to treat that as a possibility & thus missing optimization opportunities & generating false-positive warnings.
[Bug fortran/87960] [9 Regression] Miscompilation of 527.cam4_r benchmark from SPEC2017 w/ -O2 since r265946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87960 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-11-09 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- From the description, this should be fixed with r265979. Is that the case?
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #4 from Vitali --- Is there a way to annotate a specific enum as strict?
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951
--- Comment #3 from Jonathan Wakely ---
(In reply to Vitali from comment #0)
> If a function has a single switch statement that handles all enum values &
> returns a value GCC will warn about the function not returning a value
> whereas clang does not. GCC requires an explicit __builtin_unreachable()
> annotation after the switch. As of C++17 it seems to now be undefined
> behaviour rather than unspecified behaviour for an enum to have a value
> that's not enumerated.
No, that's not what the defect report says. I wish this myth would die.
Outside the range of the enumerated values does not mean not enumerated.
Given enum E { e0=0, e10=7 } there is nothing undefined about E(1) or E(4).
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
>
> > cat test.c
>
> enum Enum {
> A,
> B,
> };
>
> int CoverMyBases(enum Enum x) {
> switch (x) {
> case A:
> return 1;
> case B:
> return 0;
> }
> }
>
> int main(int argc, const char **argv) {
> CoverMyBases(A);
> CoverMyBases(B);
> return 0;
> }
>
> > g++-8 -Wall --std=c++17 test.c
>
> test.c: In function 'CoverMyBases':
> test.c:16:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> }
> ^
This is what -fstrict-enums is for.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 David Edelsohn changed: What|Removed |Added Target|powerpc |powerpc-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-09 Ever confirmed|0 |1 --- Comment #7 from David Edelsohn --- This sounds like the general problem of the first RA pass creating excessively long live ranges. Does GCC know how to re-materialize a comparison?
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #6 from meissner at linux dot ibm.com --- On Fri, Nov 09, 2018 at 02:47:31PM +, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 > > --- Comment #4 from Bill Schmidt --- > Seems like a potential opportunity for shrink-wrap separate on the CRs. I'm > not sure whether that's implemented yet. Not really, since shrink wrap only occurs if the program has an early exit condition. In this case, I don't think it is early exit, but instead the compiler is just lengthening the lifetime of the CR and moving it out of loops, etc.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #5 from meissner at linux dot ibm.com --- On Fri, Nov 09, 2018 at 02:28:28AM +, bergner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 > > --- Comment #3 from Peter Bergner --- > What do you think we can do about that? The call clobbers the ABI defined > non-volatile CR regs, so we have to save/restore them. I don't think we have > any other option, other than telling GCC to never use the non-volatile CR regs > so they never have to be saved/restored. Does using -ffixed-cr2 -ffixed-cr3 > -ffixed-cr4 help? I should clarify what I would like. Yes, if the compiler needs to preserve the CRs the current code works. But it would be helpful if instead of trying to preserve the CR across calls, that we re-do the initial comparison, instead of trying to keep the CR live for so long.
[Bug libstdc++/87520] [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87520 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > @@ -513,7 +512,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >alignas(type_info) static constexpr _Sp_make_shared_tag __tag; This needs to be fixed to have the right size as well as alignment, so the reference binds to suitable storage (as per core DR 453).
[Bug c/81824] Warn for missing attributes with function aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 Severity|normal |enhancement --- Comment #11 from Martin Sebor --- Committed in r265980.
[Bug libstdc++/85930] [8/9 Regression] Misaligned reference created in shared_ptr_base.h with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85930 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED URL||https://bugzilla.redhat.com ||/show_bug.cgi?id=1643318 Resolution|FIXED |--- --- Comment #6 from Jonathan Wakely --- Clang's UBsan still complains about this, because the object at the type-punned address is not large enough to be a type_info.
[Bug tree-optimization/18501] [7/8/9 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #88 from Eric Gallager --- This came up again on the gcc-help mailing list here: https://gcc.gnu.org/ml/gcc-help/2018-11/msg7.html
[Bug c/87962] ice in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87962 David Binderman changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from David Binderman --- svn blame says 263129 rsandifo gcc_assert (vec_stmt_info);
[Bug c/87962] New: ice in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87962
Bug ID: 87962
Summary: ice in vect_get_vec_def_for_operand_1, at
tree-vect-stmts.c:1485
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
int a, b;
int c() {
long d, e;
while (a) {
a++;
b = 0;
for (; b++ - 2; d = d >> 1)
e += d;
}
return e;
}
compiled by recent gcc trunk and flags -O3 -march=native, does this:
bug474.c:4:5: internal compiler error: in vect_get_vec_def_for_operand_1, at
tree-vect-stmts.c:1485
This code used to work at revision 265846, but fails at revision 265907.
/proc/cpuinfo says
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD FX(tm)-8350 Eight-Core Processor
[Bug c/81824] Warn for missing attributes with function aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824 --- Comment #10 from Martin Sebor --- Author: msebor Date: Fri Nov 9 17:32:52 2018 New Revision: 265980 URL: https://gcc.gnu.org/viewcvs?rev=265980=gcc=rev Log: PR middle-end/81824 - Warn for missing attributes with function aliases gcc/c-family/ChangeLog: PR middle-end/81824 * c-attribs.c (handle_copy_attribute): New function. gcc/cp/ChangeLog: PR middle-end/81824 * pt.c (warn_spec_missing_attributes): Move code to attribs.c. Call decls_mismatched_attributes. gcc/ChangeLog: PR middle-end/81824 * attribs.c (has_attribute): New helper function. (decls_mismatched_attributes, maybe_diag_alias_attributes): Same. * attribs.h (decls_mismatched_attributes): Declare. * cgraphunit.c (handle_alias_pairs): Call maybe_diag_alias_attributes. (maybe_diag_incompatible_alias): Use OPT_Wattribute_alias_. * common.opt (-Wattribute-alias): Take an argument. (-Wno-attribute-alias): New option. * doc/extend.texi (Common Function Attributes): Document copy. (Common Variable Attributes): Same. * doc/invoke.texi (-Wmissing-attributes): Document enhancement. (-Wattribute-alias): Document new option argument. gcc/testsuite/ChangeLog: PR middle-end/81824 * gcc.dg/Wattribute-alias.c: New test. * gcc.dg/Wmissing-attributes.c: New test. * gcc.dg/attr-copy.c: New test. * gcc.dg/attr-copy-2.c: New test. * gcc.dg/attr-copy-3.c: New test. * gcc.dg/attr-copy-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wattribute-alias.c trunk/gcc/testsuite/gcc.dg/Wmissing-attributes.c trunk/gcc/testsuite/gcc.dg/attr-copy-2.c trunk/gcc/testsuite/gcc.dg/attr-copy-3.c trunk/gcc/testsuite/gcc.dg/attr-copy-4.c trunk/gcc/testsuite/gcc.dg/attr-copy.c Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/attribs.h trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/cgraphunit.c trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/libgomp/libgomp.h
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #26 from Jerry DeLisle --- Author: jvdelisle Date: Fri Nov 9 17:29:33 2018 New Revision: 265979 URL: https://gcc.gnu.org/viewcvs?rev=265979=gcc=rev Log: 2018-11-09 Jerry DeLisle PR libfortran/78351 * io/transfer.c (read_sf_internal): Delete leftover debug code. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[Bug c/87795] Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Known to fail||8.2.0 --- Comment #9 from Martin Sebor --- Fixed for GCC 9 in 265977.
[Bug c/87795] Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 --- Comment #8 from Martin Sebor --- Author: msebor Date: Fri Nov 9 17:17:47 2018 New Revision: 265977 URL: https://gcc.gnu.org/viewcvs?rev=265977=gcc=rev Log: PR c/87795 - Excessive alignment permitted for functions and labels gcc/c-family/ChangeLog: PR c/87795 * c-common.c (check_user_alignment): Use MAX_OFILE_ALIGNMENT. gcc/testsuite/ChangeLog: PR c/87795 * gcc.dg/attr-aligned.c: New test. Added: trunk/gcc/testsuite/gcc.dg/attr-aligned.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/c-decl.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/testsuite/ChangeLog
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #25 from Jerry DeLisle --- Author: jvdelisle Date: Fri Nov 9 17:07:39 2018 New Revision: 265976 URL: https://gcc.gnu.org/viewcvs?rev=265976=gcc=rev Log: 2018-11-09 Jerry DeLisle Backport from trunk PR libfortran/78351 * io/transfer.c (read_sf_internal): Add support for early comma termination of internal unit formatted reads. Backported from mainline PR libfortran/78351 * gfortran.dg/read_legacy_comma.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/read_legacy_comma.f90 Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/io/transfer.c
[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Status|RESOLVED|NEW
Last reconfirmed||2018-11-09
CC||msebor at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #12 from Martin Sebor ---
I do agree there is room for improvement here. Consider the following test
case:
$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wswitch-enum
-fdump-tree-optimized=/dev/stdout t.c
enum E { e0 } e;
int f (void)
{
switch (e)
case e0: return 0;
}
t.c: In function ‘f’:
t.c:7:1: warning: control reaches end of non-void function [-Wreturn-type]
7 | }
| ^
;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=1)
f ()
{
E e.0_1;
[local count: 1073741824]:
e.0_1 = e;
if (e.0_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
return 0;
[local count: 536870913]:
return;
}
The -Wswitch-enum option doesn't warn about the switch statement not handling
switch values that don't correspond to any of the enumerators. To have it
diagnosed the -Wswitch-default option has to be explicitly specified (it's off
by default).
Given that, I believe the same logic should apply to the -Wreturn-type warning:
it should not trigger for the snippet above or for the test case in comment #0
unless explicitly requested somehow (perhaps it should consider
-Wswitch-default).
In addition, note the comparison to zero in the optimized GIMPLE. It's
unnecessary because the function returns no value when the value of e is
non-zero. Clang notices that and avoids the comparison. But perhaps a better
example to illustrate the missed optimization opportunity than the contrived
test case above is this:
enum E { e0, e1, e2 } e;
int f (void)
{
switch (e)
{
case e0: return 1;
case e1: return 2;
case e2: return 3;
}
}
Here, GCC also emits the same pointless comparison/branch:
f:
movle(%rip), %eax
cmpl$2, %eax
ja .L2
addl$1, %eax
ret
.L2:
ret
[Bug libstdc++/87787] [9 Regression][UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 --- Comment #4 from Tobias Burnus --- (In reply to Marc Glisse from comment #1) > That would be my recent commit. Namely, the commit r265485 of 2018-10-25: "Relocation (= move+destroy)" PR libstdc++/87106
[Bug libstdc++/87787] [9 Regression][UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Summary|[9 Regression] runtime |[9 Regression][UBSAN]
|error: null pointer passed |runtime error: null pointer
|as argument 2, which is |passed as argument 2, which
|declared to never be null |is declared to never be
||null
--- Comment #3 from Tobias Burnus ---
(In reply to Marc Glisse from comment #2)
> (In reply to Marc Glisse from comment #1)
> > That would be my recent commit. We will probably need to add if(size!=0) in
> > front of the call to memmove...
>
> That's what we already do in stl_algobase.h and fstream.tcc. I notice that
> we do not do it in char_traits.h for the generic version (we do for each
> specialization). I don't know if memcpy in locale_facets.h is safe either.
As that comment talks about char_traits.h, only, it is not clear whether the
following would be covered by the fix as well or not. In any case, the
following is a simple reproducer:
#include
int main() {
int *ip = NULL;
std::vector vec;
vec.push_back(ip);
return 1;
}
With gives with ubsan (-fsanitize=undefined) at run time:
stl_uninitialized.h:907:24: runtime error: null pointer passed as argument 2,
which is declared to never be null
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #4 from Bill Schmidt --- Seems like a potential opportunity for shrink-wrap separate on the CRs. I'm not sure whether that's implemented yet.
[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87892 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed.
[Bug c++/87961] New: crash at goto label inside sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87961
Bug ID: 87961
Summary: crash at goto label inside sizeof
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugvelesevich at gmail dot com
Target Milestone: ---
source.cpp:
int main() {
sizeof(({M:0;}));
goto M;
}
output:
In function ‘int main()’:
:1:5: internal compiler error: Segmentation fault
int main() {
^~~~
Code is a little strange... clang gets sigsegv too :)
[Bug target/81585] fastcall/stdcall attribute conflict not detected on distinct declarations of the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81585 Eric Gallager changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||ubizjak at gmail dot com --- Comment #3 from Eric Gallager --- cc-ing i386 maintainers
[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936 Eric Gallager changed: What|Removed |Added CC||ghazi at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Comment in builtins.def says: /* bcmp, bcopy and bzero have traditionally accepted NULL pointers when the length parameter is zero, so don't apply attribute "nonnull". */ svn blame says Kaveh Ghazi wrote that comment; cc-ing him
[Bug tree-optimization/80512] missing -Wformat-overfow on a numbered directive with width specified by "*m$"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80512 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug c++/79605] attribute [[noreturn]] accepted in explicit instantiation directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79605 Eric Gallager changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||nathan at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing C++ FE maintainers
[Bug driver/31351] gcc -v --help has poor documentation for some shared Ada/C options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31351 --- Comment #2 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #1) > This is a bug yes, but it won't get fixed unless someone that cares about it > steps up to fix it. I'd do this but I don't know the Ada FE well enough since I never build it
[Bug middle-end/35903] false Warray-bounds warning when passing quoted string to function strcmp(arg,"no");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903 --- Comment #11 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #4) > (In reply to comment #3) > > This bug has no changed for months, I think it is still active. > > Newer higher priority bugs often make us forget about old inactive bugs. > Going through old bugs and testing whether they still exist in a recent GCC > would be extremely helpful. > This is what I've been doing ever since I got my bugzilla account
[Bug c/87942] every int seems to be unaligned in packed structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87942 --- Comment #4 from Alexander Monakov --- (In reply to Johannes Vetter from comment #3) > My problem now: in how many other cases is the same behavior? I cannot check > every global variable/struct by hand. I recommend to open a new bugreport for this aspect (diagnostics enhancement). There's -Wpacked-not-aligned now, but it doesn't capture this specific issue. Why was it necessary to use a packed struct for device memory at all?
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Martin Liška ---
There's patch candidate:
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 4676bdbdf93..71cd35caf0c 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1048,7 +1048,11 @@ warn_odr (tree t1, tree t2, tree st1, tree st2,
}
else
return;
- inform (DECL_SOURCE_LOCATION (decl2), reason);
+
+ location_t loc = (TYPE_NAME (t1) && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL
+ ? DECL_SOURCE_LOCATION (TYPE_NAME (t1))
+ : UNKNOWN_LOCATION);
+ inform (loc, reason);
if (warned)
*warned = true;
But now I see repeated Wodr:
$ g++ -flto [12].ii -shared
1.ii:3:3: warning: type ‘struct YYSTYPE’ violates the C++ One Definition Rule
[-Wodr]
3 | } YYSTYPE;
| ^
1.ii:3:3: note: a type with different alignment is defined in another
translation unit
1.ii:4:7: warning: type ‘union yyalloc’ violates the C++ One Definition Rule
[-Wodr]
4 | union yyalloc {
| ^
1.ii:4:7: note: a different type is defined in another translation unit
1.ii:6:11: note: the first difference of corresponding definitions is field
‘yyvs’
6 | YYSTYPE yyvs;
| ^
1.ii:4:7: note: a field of same name but different type is defined in another
translation unit
4 | union yyalloc {
| ^
1.ii:3:3: note: type ‘struct YYSTYPE’ itself violates the C++ One Definition
Rule
3 | } YYSTYPE;
| ^
1.ii:3:3: warning: type ‘struct YYSTYPE’ violates the C++ One Definition Rule
[-Wodr]
2.ii:1:16: note: a different type is defined in another translation unit
1 | typedef struct YYSTYPE {
|^
1.ii:2:7: note: the first difference of corresponding definitions is field ‘a’
2 | int a;
| ^
1.ii:3:3: note: a type with different number of fields is defined in another
translation unit
3 | } YYSTYPE;
| ^
Leaving to Honza.
[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87955 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-09 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Sorry about that. Confirmed; I'm working on a fix.
[Bug tree-optimization/87954] VRP can transform a * b where a,b are [0,1] to a & b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87954 --- Comment #4 from Marc Glisse --- (In reply to Martin Liška from comment #3) > Marc, are you planning to implement that in the future? Not in the near future, no. It is all yours if you want it ;-)
[Bug target/87867] [7/8 regression] ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867 --- Comment #2 from Ramana Radhakrishnan --- Author: ramana Date: Fri Nov 9 12:50:51 2018 New Revision: 265965 URL: https://gcc.gnu.org/viewcvs?rev=265965=gcc=rev Log: [PATCH, arm] Backport -- Fix ICE during thunk generation with -mlong-calls For Mihail Ionescu. 2018-11-09 Mihail Ionescu PR target/87867 Backport from mainline 2018-09-17 Eric Botcazou * g++.dg/other/thunk2a.C: New test. * g++.dg/other/thunk2b.C: Likewise. 2018-11-09 Mihail Ionescu Backport from mainiline 2018-09-17 Eric Botcazou * g++.dg/other/thunk2a.C: New test. * g++.dg/other/thunk2b.C: Likewise. * g++.dg/other/vthunk1.C: Rename as thunk1.C Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/other/thunk1.C - copied unchanged from r265964, branches/gcc-8-branch/gcc/testsuite/g++.dg/other/vthunk1.C branches/gcc-8-branch/gcc/testsuite/g++.dg/other/thunk2a.C branches/gcc-8-branch/gcc/testsuite/g++.dg/other/thunk2b.C Removed: branches/gcc-8-branch/gcc/testsuite/g++.dg/other/vthunk1.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/arm/arm.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/87954] VRP can transform a * b where a,b are [0,1] to a & b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87954 --- Comment #3 from Martin Liška --- Marc, are you planning to implement that in the future?
[Bug fortran/87960] [9 Regression] Miscompilation of 527.cam4_r benchmark from SPEC2017 w/ -O2 since r265946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87960 Martin Liška changed: What|Removed |Added Known to work||8.2.0 Blocks||26163 Target Milestone|--- |9.0 Known to fail||9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug fortran/87960] New: [9 Regression] Miscompilation of 527.cam4_r benchmark from SPEC2017 w/ -O2 since r265946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87960 Bug ID: 87960 Summary: [9 Regression] Miscompilation of 527.cam4_r benchmark from SPEC2017 w/ -O2 since r265946 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jvdelisle at gcc dot gnu.org Target Milestone: --- I see: Error with '/home/marxin/Programming/cpu2017/bin/specinvoke -d /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/run/run_peak_refrate_gcc7-m64. -f compare.cmd -E -e compare.err -o compare.stdout'; no non-empty output files exist Command returned exit code 1 *** Miscompare of cam4_validate.txt; for details see /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/run/run_peak_refrate_gcc7-m64./cam4_validate.txt.mis $ cat /home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/run/run_peak_refrate_gcc7-m64./cam4_validate.txt.mis 0001: PASS: 4 points. allow_std=0 ^ 'cam4_validate.txt' long
[Bug ipa/87959] ICE in tree check: expected enumeral_type, have record_type in free_enum_values, at ipa-devirt.c:2265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87959 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-09 Known to work||6.4.0, 7.2.0, 8.2.0, 9.0 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r265875, before the revision there was a different back-trace: lto1: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have enumeral_type in add_type_duplicate, at ipa-devirt.c:1710
[Bug testsuite/87958] scan-tree-dump-times vs. (foo|bar)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87958 --- Comment #2 from Jakub Jelinek --- Ah, ok, thanks. Perhaps we should just mention it in our scan-tree-dump-times documentation and close then.
[Bug ipa/87959] New: ICE in tree check: expected enumeral_type, have record_type in free_enum_values, at ipa-devirt.c:2265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87959
Bug ID: 87959
Summary: ICE in tree check: expected enumeral_type, have
record_type in free_enum_values, at ipa-devirt.c:2265
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The ICE is as old as -Wodr warning:
$ cat a.ii
enum Type {};
void a(Type) {}
$ cat b.ii
struct Type;
void a(Type *) {}
$ g++ [ab].ii -flto
a.ii:1:6: warning: type ‘Type’ violates the C++ One Definition Rule [-Wodr]
1 | enum Type {};
| ^
lto1: note: a different type is defined in another translation unit
during IPA pass: pure-const
lto1: internal compiler error: tree check: expected enumeral_type, have
record_type in free_enum_values, at ipa-devirt.c:2265
0x6c9738 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9623
0x800276 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3154
0xa1f582 free_enum_values
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2265
0xa1f5c5 build_type_inheritance_graph()
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2281
0xa62bb2 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/ipa.c:310
0x79efb2 read_cgraph_and_symbols
/home/marxin/Programming/gcc/gcc/lto/lto.c:3017
0x79efb2 lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:3401
[Bug testsuite/87958] scan-tree-dump-times vs. (foo|bar)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87958 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- I guess we are supposed to use non-capturing groups, i.e. (?:123|456)
[Bug c/87953] asan: stack-buffer-overflow in vectorizable_reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87953 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Nov 9 12:29:51 2018 New Revision: 265964 URL: https://gcc.gnu.org/viewcvs?rev=265964=gcc=rev Log: 2018-11-09 Richard Biener PR tree-optimization/87953 * tree-vect-loop.c (vectorizable_reduction): For analysis always pass ops[0] to vectorizable_condition. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug c/87953] asan: stack-buffer-overflow in vectorizable_reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87953 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86997
Jan Engelhardt changed:
What|Removed |Added
CC||jengelh at inai dot de
--- Comment #4 from Jan Engelhardt ---
>Is it trying to construct an 'a' object and pass that to the NoDestructor? Or
>just default construct the NoDestructor object?
As I read it, it's definitely the 1-arg form (always), not the default ctor.
auto a = NoDestructor(); // NoDestructor a;
auto b = NoDestructor{}; // NoDestructor b{};
auto c = NoDestructor({}); // NoDestructor c({});
auto d = NoDestructor{{}}; // NoDestructor d{{}};
The actual chromium code is something like
template class NoDestructor { ... }
and is used as
NoDestructor> google_tlds({"foo"});
which means ({}), if it appears, was intended to mean the empty set, and this
empty set is passed as the first and only parameter to the NoDestructor 1-arg
ctor.
[Bug target/87867] [7/8 regression] ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-09 CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |7.4 Summary|ICE on virtual destructor |[7/8 regression] ICE on |(-mlong-calls |virtual destructor |-ffunction-sections) on |(-mlong-calls |arm-none-eabi |-ffunction-sections) on ||arm-none-eabi Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Right, as you found you it was fixed by: 2018-09-26 Eric Botcazou * config/arm/arm.c (arm_reorg): Skip Thumb reorg pass for thunks. (arm32_output_mi_thunk): Deal with long calls.
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I've got patch for it, let me take it.
[Bug testsuite/87958] New: scan-tree-dump-times vs. (foo|bar)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87958
Bug ID: 87958
Summary: scan-tree-dump-times vs. (foo|bar)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Anyone knows why (foo|bar) works for e.g. scan-tree-dump, but not for
scan-tree-dump-times?
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
/* { dg-final { scan-tree-dump "call(123|456)fn" "optimized" } } */
/* { dg-final { scan-tree-dump-times "call(123|456)fn" 1 "optimized" } } */
void call123fn (void);
void
baz (void)
{
call123fn ();
}
fails the scan-tree-dump-times test, but succeeds scan-tree-dump, even when
there is just one such call in the dump. Surprisingly it succeeds if I change
the 1 to 2. Are ()s in scan-tree-dump-times unsupported, or does one need to
adjust the count, so that it is not the number of times the whole string
matched, but number of times the whole string as well as any of those ()s
matched? So e.g.
/* { dg-final { scan-tree-dump-times "b(a|b)z" 6 "optimized" } } */
succeeds on the testcase, because there are 3 baz strings and no bbz strings in
the dump.
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-11-9 Known to work||8.2.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug ipa/87957] New: [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
Bug ID: 87957
Summary: [9 Regression] ICE tree check: expected tree that
contains ‘decl minimal’ structure, have
‘identifier_node’ in warn_odr, at ipa-devirt.c:1051
since r265519
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Following is causing a new ICE:
$ cat 1.ii
typedef struct {
int a;
} YYSTYPE;
union yyalloc {
short yyss;
YYSTYPE yyvs;
};
void b() { yyalloc c; }
$ cat 2.ii
typedef struct YYSTYPE {
} YYSTYPE;
union yyalloc {
short yyss;
YYSTYPE yyvs;
};
void a() { yyalloc b; }
$ g++ -flto [12].ii
1.ii:3:3: warning: type ‘struct YYSTYPE’ violates the C++ One Definition Rule
[-Wodr]
3 | } YYSTYPE;
| ^
lto1: internal compiler error: tree check: expected tree that contains ‘decl
minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051
0x6b540e tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:9790
0x614bd4 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3268
0x614bd4 warn_odr
../../gcc/ipa-devirt.c:1051
0xa01c9e type_variants_equivalent_p
../../gcc/ipa-devirt.c:651
0xa07f68 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:697
0xa08faa odr_types_equivalent_p
../../gcc/ipa-devirt.c:1576
0xa05ea4 add_type_duplicate
../../gcc/ipa-devirt.c:1878
0xa05ea4 get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2058
0x7894d6 lto_read_decls
../../gcc/lto/lto.c:1900
0x78a78e lto_file_finalize
../../gcc/lto/lto.c:2134
0x78a78e lto_create_files_from_ids
../../gcc/lto/lto.c:2144
0x78a78e lto_file_read
../../gcc/lto/lto.c:2185
0x78a78e read_cgraph_and_symbols
../../gcc/lto/lto.c:2865
0x78a78e lto_main()
../../gcc/lto/lto.c:3401
[Bug tree-optimization/87954] VRP can transform a * b where a,b are [0,1] to a & b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87954 --- Comment #2 from Richard Biener --- (In reply to Aldy Hernandez from comment #1) > Indeed, if you compile imul() with -fdump-tree-all-details-alias -O2 and > look at the vrp1 dump, one can see: > > # RANGE [0, 1] NONZERO 1 > is_rec_12 = (int) _4; > ... > # RANGE [0, 1] NONZERO 1 > _6 = (int) _15; > # RANGE [0, 1] NONZERO 1 > _7 = _6 * is_rec_12; > > This pattern persists throughout the optimization pipeline, so any remaining > optimizer could potentially see the range of the operands and strength > reduce this. > > What would be the best place to do this? The best place to do this is a pattern in match.pd (simplify (mult @1 @2) (if (INTEGRAL_TYPE_P (type) && wi::eq_p (get_nonzero_bits (@1), wi::one (TYPE_PRECISION (type)) && wi::eq_p (get_nonzero_bits (@2), wi::one (TYPE_PRECISION (type))) (and @1 @2)) maybe even think of tricks like requiring only one operand to be [0,1] and sign-extending that from bit 0 before the and? Thus [0,1] * b -> (a ? -1 : 0) & b. But that's probably sth to do at RTL expansion time because it depends on costs to do the sign extension. if nonzero-bits is 2 then we can do b + (a == 2 ? 1 : -1) * b. Thus transfer the bit to the sign bit and do an add. This is similarly sth for RTL expansion. I guess any power-of-two or zero duality can be optimized a bit.
[Bug c/87953] asan: stack-buffer-overflow in vectorizable_reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87953 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-09 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- valgrind reports ==21312== Conditional jump or move depends on uninitialised value(s) ==21312==at 0x14BB78D: vectorizable_condition(_stmt_vec_info*, gimple_stmt_iterator*, _stmt_vec_info**, tree_node*, int, _slp_tree*, vec*) (tree-vect-stmts.c:8718) ==21312==by 0x14DCDC0: vectorizable_reduction(_stmt_vec_info*, gimple_stmt_iterator*, _stmt_vec_info**, _slp_tree*, _slp_instance*, vec*) (tree-vect-loop.c:6531) so that's probably the very same thing. reduc_index is -1 here. I have a fix.
[Bug c/87942] every int seems to be unaligned in packed structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87942 --- Comment #3 from Johannes Vetter --- Ok, thanks a lot. I haven't expected that an initializer could change the alignment of a variable. "-fno-common" does not work in my case (perhaps because the variable already has a attribute "section"). If i set the alignment of the variable AND the exported variable in the header file, it works fine. My problem now: in how many other cases is the same behavior? I cannot check every global variable/struct by hand.
[Bug fortran/87943] [6 regression] severe regression on iso_varying_string (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87943 --- Comment #2 from Jürgen Reuter --- Yep, I know that 6 is no longer supported. Nevertheless I wanted to at least report that bug. It is only in 6.5 , 7/8/9 are ok.
[Bug tree-optimization/87621] outer loop auto-vectorization fails for exponentiation code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri Nov 9 10:53:31 2018 New Revision: 265959 URL: https://gcc.gnu.org/viewcvs?rev=265959=gcc=rev Log: 2018-11-09 Richard Biener PR tree-optimization/87621 * tree-vect-loop.c (vectorizable_reduction): Handle reduction op with only phi inputs. * tree-ssa-loop-ch.c: Include tree-ssa-sccvn.h. (ch_base::copy_headers): Run CSE on copied loop headers. (pass_ch_vect::process_loop_p): Simplify. * g++.dg/vect/pr87621.cc: New testcase. Added: trunk/gcc/testsuite/g++.dg/vect/pr87621.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ch.c trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 87621, which changed state. Bug 87621 Summary: outer loop auto-vectorization fails for exponentiation code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/87621] outer loop auto-vectorization fails for exponentiation code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87621 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/87952] Missed optimization for std::get_if on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87952 --- Comment #1 from Richard Biener --- I belive I've seen dups for this. We merely isolate those paths but do not remove them (removing them might end up as a security issue).
[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Richard Biener --- .
