[Bug c++/69523] -Wliteral-suffix should not warn within namespace std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523 Eric Fiselier changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Eric Fiselier --- It appears as though this patch was never applied, or it was applied and then reverted. Re-opening for a new, permanent, solution.
[Bug c++/79556] [7 Regression] [C++1z] ICE: in unify_one_argument, at cp/pt.c:18928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79556 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c/79558] [5/6/7 Regression] ICE: Segfault in ubsan_type_descriptor, at ubsan.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79558 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/79559] [5/6/7 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P2 Target Milestone|--- |5.5
[Bug tree-optimization/79564] [missed optimization][x86] relaxed atomic counting compiled the same as seq_cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79564
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-17
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. atomics are basically black-box optimization barriers on GIMPLE.
I once had some patches to at least make alias-analysis not choke on them
too much but never got to the point submitting them...
Here you are asking to apply store-motion which isn't trivial given the IL
in its current form:
int count_relaxed(const char*) (const char * str)
{
static struct atomic_int counter = {.D.8730={._M_i=0}};
char _1;
unsigned int _7;
int _8;
char _14;
[15.00%]:
str_13 = str_4(D) + 1;
_14 = *str_4(D);
if (_14 != 0)
goto ; [85.00%]
else
goto ; [15.00%]
[85.00%]:
# str_17 = PHI
__atomic_fetch_add_4 (&MEM[(struct __atomic_base *)&counter]._M_i, 1, 0);
str_6 = str_17 + 1;
_1 = MEM[base: str_6, offset: -1B];
if (_1 != 0)
goto ; [85.00%]
else
goto ; [15.00%]
[15.00%]:
_7 = __atomic_load_4 (&MEM[(const struct __atomic_base *)&counter]._M_i, 5);
[tail call]
_8 = (int) _7;
return _8;
[Bug c++/79566] [6/7 Regression] elaborated-type-specifier incorrectly rejected in range-based for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79566 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.4
[Bug bootstrap/79567] Compiler-warning "unknown escape sequence '\x'" about genmatch-generated C-files on mingw-host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79567 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug ada/79542] [7 regression] GNAT bug box
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542 Pierre-Marie de Rodat changed: What|Removed |Added CC||derodat at adacore dot com --- Comment #3 from Pierre-Marie de Rodat --- Thank you for CCing me, Jakub. This is just to say that I will not be able to work on this until March. If this can wait until then, I’ll be happy to investigate and try to fix the crash.
[Bug c++/79551] Better caret position for not declared errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79551 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Martin Liška --- Thanks for investigation. As I build GCC with 6.x.y version, I haven't noticed that r236896 enhanced diagnostics. I'm going to close this as resolved.
[Bug target/79568] New: ICE in extract_insn, at recog.c:2311 for pr70325.c (with -mavx512bw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79568
Bug ID: 79568
Summary: ICE in extract_insn, at recog.c:2311 for pr70325.c
(with -mavx512bw)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: kirill.yukhin at intel dot com
Target Milestone: ---
Hello.
All releases supporting AVX512 ICE on gcc/testsuite/gcc.target/i386/pr70325.c:
gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c
-mavx512bw
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c: In
function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c:11:37:
warning: passing argument 1 of ‘__builtin_ia32_storedquqi256_mask’ from
incompatible pointer type [-Wincompatible-pointer-types]
__builtin_ia32_storedquqi256_mask((C*)f,(C)b,a); /* { dg-warning "implicit
declaration of function" } */
^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c:11:37:
note: expected ‘char *’ but argument is of type ‘__vector(32) char *’
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c:12:1:
error: unrecognizable insn:
}
^
(insn 12 11 16 2 (set (mem:V32QI (reg/f:DI 89) [0 S32 A16])
(vec_merge:V32QI (reg:V32QI 90)
(mem:V32QI (reg/f:DI 89) [0 S32 A16])
(reg:SI 91)))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c":11 -1
(nil))
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr70325.c:12:1:
internal compiler error: in extract_insn, at recog.c:2311
0xa072f8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xa07329 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0x9d68b1 extract_insn(rtx_insn*)
../../gcc/recog.c:2311
0x8204bb instantiate_virtual_regs_in_insn
../../gcc/function.c:1589
0x8204bb instantiate_virtual_regs
../../gcc/function.c:1957
0x8204bb execute
../../gcc/function.c:2006
[Bug target/79568] ICE in extract_insn, at recog.c:2311 for pr70325.c (with -mavx512bw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79568 --- Comment #1 from Martin Liška --- Same happens for: -mavx512vbmi.
[Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388 Richard Biener changed: What|Removed |Added Status|WAITING |NEW --- Comment #13 from Richard Biener --- I think it's still important to optimize such temporary uses of STL containers, esp. std::vector. And yes, I realize actually doing this will be quite a challenge.
[Bug driver/79569] New: Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569 Bug ID: 79569 Summary: Unrecognized command line option ‘-m3dnowa’ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I know that it's probably very legacy target option, however we still offer it, but don't accept: $ gcc --help=target -Q | grep 3dnowa -m3dnowa [disabled] $ gcc /tmp/empty.c -m3dnowa cc1: error: unrecognized command line option ‘-m3dnowa’ All releases I have behave the same.
[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 --- Comment #24 from Richard Biener --- (In reply to Jeffrey A. Law from comment #23) > The model of shortening as much as possible for gimple, then widening to > word mode at the gimple/RTL boundary is probably too simplistic. We really > need the ability to widen when doing so allows for simplification. But the key point here is "when doing so allows for simplification" ... > That's what the prototype pattern I posted was meant to show. By widening > we can expose the common subexpressions, and once the common subexpressions > are exposed, min/max can do its job. The problem is we don't have range > data, so we have to do masking of the result, nor do we know if the widened > operand is a common subexpression or not. Thus profitability is unknown at > transformation time. > > I was about to write off VRP again because it lacks much of the CSE > capability we want, but VRP has the information to know that the result is > value preserving if done in the wider mode. So at VRP time we could do the > widening without needing to mask the result, at which point widening is > known to be profitable. As written we have two casts + addition. VRP could > turn that into a addition with a single cast (both of which are common > subexpressions, but VRP doesn't need to detect that to ensure profitability). > > DOM/FRE have CSE infrastructure, but the range data presented to them is not > path sensitive and thus useless in this case. Note that mid-term I'd like our value-numbering infrastructure (VRP is also a kind of value-numbering) to improve to a point where we simply do VRP alongside CSE, constant, copy and known-zero/one-bits propagation. You "simply" track multiple lattices (configurable) from a common iteration (configurable as either non-iterating, pessimistically handling backedges, or iterating, optimistically handling them). > I'm hesitant to try to do all this in phi-opt -- phi-opt would have to look > through the casts, prove equivalences, etc. ick. Yeah, ICK. But still this case is very much about pattern matching (and getting min/max in the end). It _is_ a saturating operation which might be common enough to pattern-match (heh, some targets even have instruction support for them and the middle-end has saturating types!) So short-term pattern matching in phiopt is the way to go (I'd consider that even as a regression fix).
[Bug inline-asm/79552] [6 Regression] Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79552 Richard Biener changed: What|Removed |Added Depends on||43434 --- Comment #8 from Richard Biener --- TO not regress the fix depends on the fix for PR43434. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434 [Bug 43434] Missed vectorization: "not vectorized: data ref analysis": pointer incremented by a parameter
[Bug middle-end/79536] [5/6/7 Regression] ICE in fold_binary_loc, at fold-const.c:9060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79536 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Fri Feb 17 09:51:38 2017 New Revision: 245526 URL: https://gcc.gnu.org/viewcvs?rev=245526&root=gcc&view=rev Log: PR middle-end/79536 * fold-const.c (fold_negate_expr_1): Renamed from fold_negate_expr. (fold_negate_expr): New wrapper. * gcc.dg/torture/pr79536.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr79536.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug driver/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-17
CC||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
I bet this goes all the way down to r125180 or so, ix86_handle_option returns
false for OPT_3dnowa. So, either the option should not be recognized, then we
should add Ignore to it etc., or we should make it work (again?). Right now it
seems the effect of -m3dnowa happens only if -march= for a CPU that includes
3dnowa is included.
To make -m3dnowa work, perhaps something like following would DTRT (plus
testcases):
--- gcc/common/config/i386/i386-common.c.jj 2017-01-12 22:29:00.0
+0100
+++ gcc/common/config/i386/i386-common.c2017-02-17 10:55:20.023152107
+0100
@@ -35,6 +35,8 @@ along with GCC; see the file COPYING3.
#define OPTION_MASK_ISA_MMX_SET OPTION_MASK_ISA_MMX
#define OPTION_MASK_ISA_3DNOW_SET \
(OPTION_MASK_ISA_3DNOW | OPTION_MASK_ISA_MMX_SET)
+#define OPTION_MASK_ISA_3DNOW_A_SET \
+ (OPTION_MASK_ISA_3DNOW_A | OPTION_MASK_ISA_3DNOW_SET)
#define OPTION_MASK_ISA_SSE_SET OPTION_MASK_ISA_SSE
#define OPTION_MASK_ISA_SSE2_SET \
@@ -291,7 +293,17 @@ ix86_handle_option (struct gcc_options *
return true;
case OPT_m3dnowa:
- return false;
+ if (value)
+ {
+ opts->x_ix86_isa_flags |= OPTION_MASK_ISA_3DNOW_A_SET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_3DNOW_A_SET;
+ }
+ else
+ {
+ opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_3DNOW_A_UNSET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_3DNOW_A_UNSET;
+ }
+ return true;
case OPT_msse:
if (value)
[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #11 from amker at gcc dot gnu.org --- According to Pat's report, the proposed patch for PR77536 can resolve the second test regression, but introduces 4 additional copy instructions. https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01081.html I checked tree dump information, the only difference is frequency counters are now fixed, but IRA/reload still make bad choice with "correct" profiling information.
[Bug target/79559] [5/6/7 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 Uroš Bizjak changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #2 from Uroš Bizjak --- %R and %r are intended for AVX512F embedded rounding decorations. OTOH, we should produce some meaningful error message on invalid use of these modifiers. So, although this PR goes into "do not do that if it hurts" category, gcc_asserts in ix86_print_operand for 'R' and 'r' cases should be substituted with calls to output_operand_lossage.
[Bug middle-end/79536] [5/6 Regression] ICE in fold_binary_loc, at fold-const.c:9060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79536 --- Comment #9 from Marek Polacek --- Fixed on the trunk so far. I'll backport to 6, too, just dunno when.
[Bug driver/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569 --- Comment #2 from Richard Biener --- Or we can remove it completely (retaining the current error).
[Bug driver/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569 --- Comment #3 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #1) > I bet this goes all the way down to r125180 or so, ix86_handle_option > returns false for OPT_3dnowa. So, either the option should not be > recognized, then we should add Ignore to it etc., or we should make it work > (again?). Right now it seems the effect of -m3dnowa happens only if -march= > for a CPU that includes 3dnowa is included. This option is marked as Undocumented in i386.opt. Ages ago, it made sense to switch it only with -march= option. Nowadays we should handle it as we handle other options. So, your patch is OK in this regard, but please remove Undocumented from i386.opt and add this option to doc/invoke.texi.
[Bug target/79570] New: [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 Bug ID: 79570 Summary: [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Starting from GCC 4.9.0 I see following ICE: gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr69956.c -O2 -fselective-scheduling2 -fvar-tracking-assignments cc1: warning: var-tracking-assignments changes selective scheduling /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr69956.c: In function ‘fn1’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr69956.c:11:1: internal compiler error: Segmentation fault } ^ 0xa5f34f crash_signal ../../gcc/toplev.c:337 0x7196a0 bb_note(basic_block_def*) ../../gcc/cfgrtl.c:670 0xa20bc9 sel_bb_head(basic_block_def*) ../../gcc/sel-sched-ir.c:4534 0xa2c74b moveup_expr_cached ../../gcc/sel-sched.c:2532 0xa2f5fe move_op_ascend ../../gcc/sel-sched.c:6152 0xa31471 code_motion_path_driver ../../gcc/sel-sched.c:6649 0xa32383 move_op ../../gcc/sel-sched.c:6703 0xa32383 move_exprs_to_boundary ../../gcc/sel-sched.c:5226 0xa32383 schedule_expr_on_boundary ../../gcc/sel-sched.c:5439 0xa35a81 fill_insns ../../gcc/sel-sched.c:5581 0xa35a81 schedule_on_fences ../../gcc/sel-sched.c:7355 0xa35a81 sel_sched_region_2 ../../gcc/sel-sched.c:7493 0xa38659 sel_sched_region_1 ../../gcc/sel-sched.c:7535 0xa38659 sel_sched_region(int) ../../gcc/sel-sched.c:7636 0xa39041 run_selective_scheduling() ../../gcc/sel-sched.c:7712 0xa18de5 rest_of_handle_sched2 ../../gcc/sched-rgn.c:3722 0xa18de5 execute ../../gcc/sched-rgn.c:3866
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 --- Comment #1 from Martin Liška --- ICE for selective scheduling in be run as first pass (-fselective-scheduling): $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70252.c -fselective-scheduling -fschedule-insns -O -fvar-tracking-assignments cc1: warning: var-tracking-assignments changes selective scheduling /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70252.c: In function ‘foo’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70252.c:16:1: internal compiler error: Segmentation fault } ^ 0xa5f34f crash_signal ../../gcc/toplev.c:337 0x7196a0 bb_note(basic_block_def*) ../../gcc/cfgrtl.c:670 0xa20bc9 sel_bb_head(basic_block_def*) ../../gcc/sel-sched-ir.c:4534 0xa2c74b moveup_expr_cached ../../gcc/sel-sched.c:2532 0xa2f5fe move_op_ascend ../../gcc/sel-sched.c:6152 0xa31471 code_motion_path_driver ../../gcc/sel-sched.c:6649 0xa32383 move_op ../../gcc/sel-sched.c:6703 0xa32383 move_exprs_to_boundary ../../gcc/sel-sched.c:5226 0xa32383 schedule_expr_on_boundary ../../gcc/sel-sched.c:5439 0xa35a81 fill_insns ../../gcc/sel-sched.c:5581 0xa35a81 schedule_on_fences ../../gcc/sel-sched.c:7355 0xa35a81 sel_sched_region_2 ../../gcc/sel-sched.c:7493 0xa38659 sel_sched_region_1 ../../gcc/sel-sched.c:7535 0xa38659 sel_sched_region(int) ../../gcc/sel-sched.c:7636 0xa39041 run_selective_scheduling() ../../gcc/sel-sched.c:7712 0xa18d8d rest_of_handle_sched ../../gcc/sched-rgn.c:3708 0xa18d8d execute ../../gcc/sched-rgn.c:3818
[Bug bootstrap/79567] Compiler-warning "unknown escape sequence '\x'" about genmatch-generated C-files on mingw-host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79567 --- Comment #2 from Richard Biener --- Fixed on trunk.
[Bug target/79559] [5/6/7 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 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 40759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40759&action=edit gcc7-pr79559.patch Untested fix.
[Bug bootstrap/79567] Compiler-warning "unknown escape sequence '\x'" about genmatch-generated C-files on mingw-host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79567 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Feb 17 10:19:21 2017 New Revision: 245527 URL: https://gcc.gnu.org/viewcvs?rev=245527&root=gcc&view=rev Log: 2017-02-17 Richard Biener PR bootstrap/79567 * genmatch.c (output_line_directive): Handle DIR_SEPARATOR_2. Modified: trunk/gcc/ChangeLog trunk/gcc/genmatch.c
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 Richard Biener changed: What|Removed |Added Version|unknown |7.0 Target Milestone|--- |5.5
[Bug rtl-optimization/79571] New: [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
Bug ID: 79571
Summary: [5/6/7 Regression] ICE in Max. number of generated
reload insns per insn is achieved (90)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from 4.8.x we ICE:
$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/sh/torture/pr65505.c -O
-mno-sse
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/sh/torture/pr65505.c: In
function ‘fdget_raw’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/sh/torture/pr65505.c:62:22:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return (struct fd){(struct file *)(fd & ~3),fd & 3};
^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/sh/torture/pr65505.c: In
function ‘path_init’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/sh/torture/pr65505.c:121:1:
internal compiler error: Max. number of generated reload insns per insn is
achieved (90)
}
^
0x92fe86 lra_constraints(bool)
../../gcc/lra-constraints.c:4656
0x91f1f4 lra(_IO_FILE*)
../../gcc/lra.c:2397
0x8ddcdf do_reload
../../gcc/ira.c:5400
0x8ddcdf execute
../../gcc/ira.c:5584
A reduced test-case:
$ cat ice.c
struct a
{
int b;
int *c
} h;
struct d
{
struct a e
};
struct fd
{
struct d *d
} i;
g;
j ()
{
unsigned a = g;
i = (struct fd){a & 3};
struct fd f = i;
h = f.d->e;
}
[Bug rtl-optimization/58008] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58008 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Maybe related to PR79571.
[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79347 --- Comment #13 from amker at gcc dot gnu.org --- (In reply to Rainer Orth from comment #10) > The new testcase FAILs on sparc-sun-solaris2.12, both 32 and 64-bit: > > +FAIL: gcc.dg/vect/pr79347.c -flto -ffat-lto-objects scan-tree-dump-times > vect "Invalid sum of " 2 > +FAIL: gcc.dg/vect/pr79347.c scan-tree-dump-times vect "Invalid sum of " 2 > > "Invalid sum of " doesn't occur in the dump file at all. > > Rainer As noted in comment #12, though "Invalid sum " doesn't occur in this case, the counter is still wrong. This issue should be resolved by proposed patch at https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01057.html Thanks.
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571 --- Comment #1 from Martin Liška --- Maybe similar to PR58008.
[Bug driver/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569 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 40760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40760&action=edit gcc7-pr79569.patch Full patch I'm going to test.
[Bug inline-asm/79552] [6 Regression] Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79552 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||7.0 --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug inline-asm/79552] [6 Regression] Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79552 --- Comment #10 from Richard Biener --- Author: rguenth Date: Fri Feb 17 10:43:27 2017 New Revision: 245528 URL: https://gcc.gnu.org/viewcvs?rev=245528&root=gcc&view=rev Log: 2017-02-17 Richard Biener PR tree-optimization/79552 * tree-ssa-structalias.c (visit_loadstore): Properly verify default defs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571 Richard Biener changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Version|unknown |7.0 Target Milestone|--- |5.5 --- Comment #2 from Richard Biener --- Which architecture?
[Bug driver/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569
--- Comment #5 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 40760 [details]
> gcc7-pr79569.patch
>
> Full patch I'm going to test.
Please also update text in extend.texi (... or with a combination of
@option{-m3dnow} and @option{-march=athlon}." and "... when both
@option{-m3dnow} and @option{-march=athlon} are used."
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571 Martin Liška changed: What|Removed |Added Target||x86_64-pc-linux-gnu Host||x86_64-pc-linux-gnu Build||x86_64-pc-linux-gnu --- Comment #3 from Martin Liška --- x86_64, with: cc1 -quiet -v /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/sh/torture/pr65505.c -quiet -dumpbase pr65505.c -mno-sse -mtune=generic -march=x86-64 -auxbase pr65505 -O -version -o /tmp/ccFEDu7A.s
[Bug c++/79572] New: [6/7 Regression] Segfault with -O1 and higher on null reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572
Bug ID: 79572
Summary: [6/7 Regression] Segfault with -O1 and higher on null
reference
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Please consider this simple piece of code:
#include
void f(const int &iref) {
if (&iref)
std::cout << iref << std::endl;
else
std::cout << "iref is NULL" << std::endl;
}
int main () {
f(*((int*) NULL));
return 0;
}
It is accepted by GCC 5 (and all earlier versions I tried), printing at all
optimization levels:
iref is NULL
That is also the result I get with GCC 6.2.0 using -O0. However, at -O1 and
higher it runs into a segfault, both with GCC 6.2.0 and a recent trunk build
(7.0.1 20170212).
When using -Wall, GCC 6 also prints these warnings:
null_ref.cpp:4:12: warning: the compiler can assume that the address of ‘iref’
will always evaluate to ‘true’ [-Waddress]
null_ref.cpp:4:3: warning: nonnull argument ‘iref’ compared to NULL
[-Wnonnull-compare]
if (&iref)
I agree that this way of using null references is not very nice & clean, but
it's used extensively in large code bases out there (e.g.
https://github.com/tpaviot/oce).
I can see two ways to fix this and I'm fine with either:
1) Disable the optimization that generates the segfault.
2) Reject the code with a hard error (in particular with -O1 and above).
For the second option, what should be rejected is probably the dereferencing of
a NULL pointer in
f(*((int*) NULL))
[Bug c/79573] New: binutils make install fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79573 Bug ID: 79573 Summary: binutils make install fails Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- Host machine gcc version : -bash-4.2$ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) -bash-4.2$ I am compiling binutils 2.23.52.20130219 but getting below errors while doing make install. rm -rf $backupdir; exit $rc ../../../binutils-2013.11/gas/doc/c-arc.texi:223: table requires an argument: the formatter for @item ../../../binutils-2013.11/gas/doc/c-arm.texi:391: command @bullet not accepting argument in brace should not be on @table line ../../../binutils-2013.11/gas/doc/c-arm.texi:392: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:395: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:400: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:405: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:410: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:413: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:49: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:51: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:53: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:58: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:63: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:65: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-tic54x.texi:113: @code expected braces ../../../binutils-2013.11/gas/doc/c-tic54x.texi:130: @code expected braces ../../../binutils-2013.11/gas/doc/c-tic54x.texi:137: @code expected braces ../../../binutils-2013.11/gas/doc/c-tic54x.texi:313: @code expected braces ../../../binutils-2013.11/gas/doc/as.texinfo:4406: warning: node `Byte' is next for `Bundle directives' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/as.texinfo:4462: warning: node `Bundle directives' is prev for `Byte' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/as.texinfo:4470: warning: node `Comm' is next for `CFI directives' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/as.texinfo:4626: warning: node `CFI directives' is prev for `Comm' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-arm.texi:445: warning: node next `ARM-Regs' in menu `ARM-Relocations' and in sectioning `ARM-Neon-Alignment' differ ../../../binutils-2013.11/gas/doc/c-arm.texi:452: warning: node prev `ARM-Neon-Alignment' in menu `ARM-Relocations' and in sectioning `ARM-Regs' differ ../../../binutils-2013.11/gas/doc/c-arm.texi:474: warning: node `ARM-Neon-Alignment' is next for `ARM-Relocations' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-arm.texi:474: warning: node `ARM-Regs' is prev for `ARM-Relocations' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-arm.texi:474: warning: node up `ARM-Relocations' in menu `ARM Syntax' and in sectioning `ARM Floating Point' differ ../../../binutils-2013.11/gas/doc/c-arm.texi:467: node `ARM Floating Point' lacks menu item for `ARM-Relocations' despite being its Up target ../../../binutils-2013.11/gas/doc/c-i386.texi:411: warning: node `i386-Regs' is next for `i386-Mnemonics' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-i386.texi:511: warning: node `i386-Mnemonics' is prev for `i386-Regs' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-i386.texi:926: warning: node next `i386-16bit' in menu `i386-Arch' and in sectioning `i386-Bugs' differ ../../../binutils-2013.11/gas/doc/c-i386.texi:978:
[Bug c++/79572] [6/7 Regression] Segfault with -O1 and higher on null reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-17 Target Milestone|--- |6.4 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed for the missing diagnostic. I'm not sure we should count this as regression for the sefault - eventually the new behavior should be documented in porting_to.html or changes.html and maybe a -fallow-null-references compatibility option can be added (well, quite late now).
[Bug c++/79572] [6/7 Regression] Segfault with -O1 and higher on null reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf --- You can use -fno-delete-null-pointer-checks as a workaround for this issue. But the C++ standard makes it very clear that references cannot be null, otherwise you're invoking undefined behavior.
[Bug c++/79572] [6/7 Regression] Segfault with -O1 and higher on null reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #1) > Confirmed for the missing diagnostic. I'm not sure we should count this as > regression for the sefault - eventually the new behavior should be documented > in porting_to.html or changes.html and maybe a -fallow-null-references > compatibility option can be added (well, quite late now). Well, a warning is a diagnostic. Lets close the issue as invalid.
[Bug c/79573] binutils make install fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79573 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- I don't see how this is related to the C FE, or GCC at all. GCC 4.8 isn't supported anymore anyway.
[Bug c++/79572] [6/7 Regression] Segfault with -O1 and higher on null reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #4 from Markus Trippelsdorf --- BTW clang diagnoses the issue with -fsanitize=undefined, but gcc doesn't: runtime error: reference binding to null pointer of type 'const int'
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|c++ |sanitizer Resolution|INVALID |--- Summary|[6/7 Regression] Segfault |[6/7 Regression] reference |with -O1 and higher on null |binding to null pointer not |reference |reported with ||-fsanitize=undefined --- Comment #5 from Markus Trippelsdorf --- This is an -fsanitize=undefined regression. 5.4.1 gives: runtime error: reference binding to null pointer of type 'const int 6 and trunk: No runtime error is reported.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Let me have a look.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #2) > You can use -fno-delete-null-pointer-checks as a workaround for this issue. Thanks for the comment, that's very helpful. > But the C++ standard makes it very clear that references cannot be null, > otherwise you're invoking undefined behavior. Fully agree. I'm not trying to argue that GCC should adapt to cope with shitty code. But: There is a pretty dramatic change in behavior from version 5 to 6, in the sense that (bad) code that worked before suddenly stopped working. A warning is good, but I'd argue that in this case it's really not enough. So, yes, a runtime error would be the needed at least. I know that detecting such cases at compile time cannot be done in general, but for the case here, shouldn't it be possible to detect the dereferencing of a NULL pointer at compile time, simply by looking at this one line? f(*((int*) NULL));
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #8 from Richard Biener --- Btw, clang behaves the same: > clang++ t.C -O2 t.C:4:12: warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion] if (&iref) ~~ ^~~~ 1 warning generated. rguenther@e111:/tmp> ./a.out Segmentation fault (core dumped) and it doesn't diagnose *NULL either.
[Bug c/79573] binutils make install fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79573 --- Comment #2 from Jonathan Wakely --- binutils is not part of gcc, it has its own bug tracker at https://sourceware.org/bugzilla/
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Richard Biener from comment #8) > Btw, clang behaves the same: True. But at least clang 3.9 has some additional diagnostics: null_ref.cpp:11:5: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] f(*((int*) NULL)); ^~ Ideally GCC should yield the same warning, and maybe even turn it into an error with -std=c++14, as opposed to -std=gnu++14 ?
[Bug target/79568] ICE in extract_insn, at recog.c:2311 for pr70325.c (with -mavx512bw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79568 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-17 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 40761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40761&action=edit gcc7-pr79568.patch Untested fix. The issue is as the comment in def_builtin says, OPTION_MASK_ISA_AVX512VL and OPTION_MASK_ISA_64BIT behave specially in the builtin mask bitmask, while for others (not 100% sure) oring two isa bits together means enable on either this or that, for avx512vl and/or m64 in the bitmask it means honor these and any of the other bits. The full list of builtin masks with more than one bit is: OPTION_MASK_ISA_AVX512BW | OPTION_MASK_ISA_AVX512VL OPTION_MASK_ISA_AVX512CD | OPTION_MASK_ISA_AVX512VL OPTION_MASK_ISA_AVX512DQ | OPTION_MASK_ISA_AVX512VL OPTION_MASK_ISA_AVX512F | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_AVX512IFMA | OPTION_MASK_ISA_AVX512VL OPTION_MASK_ISA_AVX512VBMI | OPTION_MASK_ISA_AVX512VL OPTION_MASK_ISA_AVX512VL | OPTION_MASK_ISA_AVX512CD OPTION_MASK_ISA_BMI2 | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_BMI | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4 OPTION_MASK_ISA_FSGSBASE | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_FXSR | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_LWP | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_LZCNT | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_CRC32 OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_CRC32 | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_TBM | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_XSAVEC | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_XSAVE | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_XSAVEOPT | OPTION_MASK_ISA_64BIT OPTION_MASK_ISA_XSAVES | OPTION_MASK_ISA_64BIT out of these, only OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4 OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_CRC32 OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A are ones if I filter out the 2 special bits. I believe at least the last one really is supposed to be either -msse or -m3dnowa, no idea about the other two.
[Bug rtl-optimization/79574] New: ICE in want_to_gcse_p, at gcse.c:804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79574
Bug ID: 79574
Summary: ICE in want_to_gcse_p, at gcse.c:804
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from moment when the problematic param was added.
$ cat ice.c
void a ()
{
volatile int b;
for (;; b)
;
}
gcc -Os --param gcse-cost-distance-ratio=2147483647 -c ice.c -c
ice.c: In function ‘a’:
ice.c:6:1: internal compiler error: in want_to_gcse_p, at gcse.c:804
}
^
I've got patch for that.
[Bug tree-optimization/79575] New: [7 Regression] ICE in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79575
Bug ID: 79575
Summary: [7 Regression] ICE in
mark_stmt_if_obviously_necessary, at
tree-ssa-dce.c:270
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ysrumyan at gmail dot com
Target Milestone: ---
Running on x86_64:
gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr70396.c -O3
--param vect-epilogues-nomask=1 -mavx512er -mtune=generic -march=x86-64
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr70396.c: In
function ‘fn1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr70396.c:9:6:
internal compiler error: in mark_stmt_if_obviously_necessary, at
tree-ssa-dce.c:270
void fn1() {
^~~
0xb34ba5 mark_stmt_if_obviously_necessary
../../gcc/tree-ssa-dce.c:270
0xb34ba5 find_obviously_necessary_stmts
../../gcc/tree-ssa-dce.c:389
0xb34ba5 perform_tree_ssa_dce
../../gcc/tree-ssa-dce.c:1599
[Bug tree-optimization/79575] [7 Regression] ICE in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79575 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from Martin Liška --- Started with r242501.
[Bug c++/69523] -Wliteral-suffix should not warn within namespace std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523 --- Comment #11 from Jonathan Wakely --- Patch submitted to gcc-patches with docs: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01109.html
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-17 CC||amonakov at gcc dot gnu.org, ||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Well, selective scheduling is known not to play well with -fvar-tracking-assignments, that is why we warn about it and disable -fvar-tracking-assignments by default if selective scheduling is requested. if (flag_var_tracking_assignments == AUTODETECT_VALUE) flag_var_tracking_assignments = flag_var_tracking && !(flag_selective_scheduling || flag_selective_scheduling2); ... if (flag_var_tracking_assignments && (flag_selective_scheduling || flag_selective_scheduling2)) warning_at (UNKNOWN_LOCATION, 0, "var-tracking-assignments changes selective scheduling"); Perhaps it is time to just error instead. Anyway, r197930 still works, r197942 ICEs, so it is most likely r197942 or perhaps r197933.
[Bug tree-optimization/79576] New: [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576
Bug ID: 79576
Summary: [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p
in gcc/gimple-fold.c:6979
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: kugan at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
Running following test-case:
$ cat ice.c
a, b;
c ()
{
int d = 0;
for (;;)
if (b)
while (a)
d++;
}
$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/pr24716.c
--param max-ssa-name-query-depth=1000 -O2
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 --- Comment #3 from Jakub Jelinek --- The ICE is because on the DEBUG_INSN move_op_orig_expr_found removes it from the IL: remove_insn_from_stream and then move_op_ascend -> moveup_expr_cached 2531 if (DEBUG_INSN_P (EXPR_INSN_RTX (expr)) 2532 && (sel_bb_head (BLOCK_FOR_INSN (EXPR_INSN_RTX (expr))) 2533 == EXPR_INSN_RTX (expr))) ICEs on it. --- gcc/sel-sched.c.jj 2017-01-01 12:45:38.0 +0100 +++ gcc/sel-sched.c 2017-02-17 14:14:06.493525368 +0100 @@ -2529,6 +2529,7 @@ moveup_expr_cached (expr_t expr, insn_t } if (DEBUG_INSN_P (EXPR_INSN_RTX (expr)) + && BLOCK_FOR_INSN (EXPR_INSN_RTX (expr)) && (sel_bb_head (BLOCK_FOR_INSN (EXPR_INSN_RTX (expr))) == EXPR_INSN_RTX (expr))) /* Don't use cached information for debug insns that are heads of fixes the ICE, but as I know next to nothing about sel-sched, really don't know if it is appropriate to see deleted insns at this point, or why it doesn't want to use cached info for debug insns that are heads of bbs, whether removed debug insns shouldn't be perhaps treated the same (not cached).
[Bug tree-optimization/79576] [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576
--- Comment #1 from rguenther at suse dot de ---
On Fri, 17 Feb 2017, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576
>
> Bug ID: 79576
>Summary: [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p
> in gcc/gimple-fold.c:6979
>Product: gcc
>Version: unknown
> Status: UNCONFIRMED
> Keywords: ice-on-valid-code
> Severity: normal
> Priority: P3
> Component: tree-optimization
> Assignee: unassigned at gcc dot gnu.org
> Reporter: marxin at gcc dot gnu.org
> CC: kugan at gcc dot gnu.org, rguenth at gcc dot gnu.org
> Target Milestone: ---
>
> Running following test-case:
>
> $ cat ice.c
> a, b;
> c ()
> {
> int d = 0;
> for (;;)
> if (b)
> while (a)
> d++;
> }
> $ gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/pr24716.c
> --param max-ssa-name-query-depth=1000 -O2
^^^
"doctor it hurts" -- "don't do that then"
due to the --param and its low default we do not bother to do any
cycles detection (it would be costly like allocating a bitmap).
I suppose we should define a maximum for this param then, like ... 5?
(due to no limiting in search width this can be highly exponential)
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 --- Comment #4 from Jakub Jelinek --- Seems before r197942 sel_remove_insn with only_disconnect true actually kept BLOCK_FOR_INSN on the (temporarily) removed insn. But sel_bb_head would certainly not return that temporarily removed insn, so what the patch does preserves what we used to do before in that case.
[Bug tree-optimization/79576] [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/79576] [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|unknown |7.0 Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/79576] [7 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Feb 17 13:36:39 2017 New Revision: 245529 URL: https://gcc.gnu.org/viewcvs?rev=245529&root=gcc&view=rev Log: 2017-02-17 Richard Biener PR middle-end/79576 * params.def (max-ssa-name-query-depth): Limit to 10. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug tree-optimization/79576] [6 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576 Richard Biener changed: What|Removed |Added Status|RESOLVED|ASSIGNED Known to work||7.0 Resolution|FIXED |--- Target Milestone|7.0 |6.4 Summary|[7 Regression] ICE in |[6 Regression] ICE in |gimple_stmt_nonnegative_war |gimple_stmt_nonnegative_war |nv_p in |nv_p in |gcc/gimple-fold.c:6979 |gcc/gimple-fold.c:6979 --- Comment #5 from Richard Biener --- Also present on the branch.
[Bug tree-optimization/79576] [6 Regression] ICE in gimple_stmt_nonnegative_warnv_p in gcc/gimple-fold.c:6979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79576 --- Comment #6 from Martin Liška --- > > "doctor it hurts" -- "don't do that then" > :D Will you please create 'doctor-it-hurts=dont-do-that-then' keywords so that I can decorate the PR with it?
[Bug rtl-optimization/79577] New: Infinite loop with -fselective-scheduling2 -O2 --param selsched-max-sched-times=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79577
Bug ID: 79577
Summary: Infinite loop with -fselective-scheduling2 -O2 --param
selsched-max-sched-times=0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Running simple test-case:
$ cat ~/Programming/testcases/ice.c
a () {}
$ ./xgcc -B. -fselective-scheduling2 -O2 --param selsched-max-sched-times=0
~/Programming/testcases/ice.c
Runs in an infinite loop. All release I have are affected. I would recommend to
change minimum of the param to 1. Hope it makes sense?
[Bug rtl-optimization/79577] Infinite loop with -fselective-scheduling2 -O2 --param selsched-max-sched-times=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79577 --- Comment #1 from Martin Liška --- Loops in: #0 0x00a45e5f in init_expr (cant_move=true, needs_spec_check_p=false, was_renamed=, was_substituted=, target_available=1 '\001', history=..., orig_sched_cycle=0, spec_to_check_ds=0, spec_done_ds=0, orig_bb_index=2, sched_times=0, priority=2, use=1, spec=0, vi=0x1f9d1f0, expr=0x1f2ff20) at ../../gcc/sel-sched-ir.c:1651 #1 copy_expr (to=0x1f2ff20, from=) at ../../gcc/sel-sched-ir.c:1682 #2 0x00a4d21e in av_set_copy (set=) at ../../gcc/sel-sched-ir.c:2204 #3 0x00a5b8dd in compute_av_set_on_boundaries (fence=0x1f2fcf0, av_vliw_p=0x7fffd508, bnds=0x1f2fd58) at ../../gcc/sel-sched.c:5068 #4 fill_insns (scheduled_insns_tailpp=, seqno=-1, fence=0x1f2fcf0) at ../../gcc/sel-sched.c:5526 #5 schedule_on_fences (scheduled_insns_tailpp=, max_seqno=1, fences=0x1f2fce8) at ../../gcc/sel-sched.c:7355 #6 sel_sched_region_2 (orig_max_seqno=orig_max_seqno@entry=1) at ../../gcc/sel-sched.c:7493 #7 0x00a5ef7a in sel_sched_region_1 () at ../../gcc/sel-sched.c:7535 #8 sel_sched_region (rgn=0) at ../../gcc/sel-sched.c:7636 #9 0x00a5f962 in run_selective_scheduling () at ../../gcc/sel-sched.c:7712 #10 0x00a3f706 in rest_of_handle_sched2 () at ../../gcc/sched-rgn.c:3722 #11 (anonymous namespace)::pass_sched2::execute (this=) at ../../gcc/sched-rgn.c:3866 #12 0x009cb63e in execute_one_pass (pass=pass@entry=0x1dd8c60) at ../../gcc/passes.c:2465 #13 0x009cbe48 in execute_pass_list_1 (pass=0x1dd8c60) at ../../gcc/passes.c:2554 #14 0x009cbe5a in execute_pass_list_1 (pass=0x1dd8420) at ../../gcc/passes.c:2555 #15 0x009cbe5a in execute_pass_list_1 (pass=0x1dd7200) at ../../gcc/passes.c:2555 #16 0x009cbea5 in execute_pass_list (fn=, pass=) at ../../gcc/passes.c:2565 #17 0x0075815d in cgraph_node::expand (this=0x769ba000) at ../../gcc/cgraphunit.c:2038 #18 0x00759766 in expand_all_functions () at ../../gcc/cgraphunit.c:2174 #19 symbol_table::compile (this=this@entry=0x7687a100) at ../../gcc/cgraphunit.c:2531 #20 0x0075b195 in symbol_table::compile (this=0x7687a100) at ../../gcc/cgraphunit.c:2595 #21 symbol_table::finalize_compilation_unit (this=0x7687a100) at ../../gcc/cgraphunit.c:2621 #22 0x00a85eea in compile_file () at ../../gcc/toplev.c:492 #23 0x00632747 in do_compile () at ../../gcc/toplev.c:1984 #24 toplev::main (this=this@entry=0x7fffd8c0, argc=, argc@entry=22, argv=, argv@entry=0x7fffd9c8) at ../../gcc/toplev.c:2118 #25 0x00634ad7 in main (argc=22, argv=0x7fffd9c8) at ../../gcc/main.c:39
[Bug c++/79578] New: Unnecessary instructions in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578
Bug ID: 79578
Summary: Unnecessary instructions in generated code
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
When the following code is compiled with gcc-7 and earlier versions with flags
--std=c++14 -O3 -pthread:
#include
#include
struct A
{
std::uint16_t a, b;
};
A* f(char* b) __attribute__((noinline));
A* f(char* b) {
auto a = new(b) A{};
a->a = 1;
a->b = 2;
return a;
}
int main() {
char b[sizeof(A)] alignas(A);
f(b);
}
The generated code for f contains unnecessary instructions:
f(char*):
testq %rdi, %rdi <--- unnecessary code begin
movq%rdi, %rax
je .L2
movl$0, (%rdi) <--- unnecessary code end
.L2:
movl$131073, (%rax)
ret
I expect the generated code to be just:
f(char*):
movl$131073, (%rdi)
ret
Because:
1. operator new(size_t, void*) is an inline function, its definition is
available in this translation unit.
2. The code assigns through that pointer, so the pointer must be valid.
Therefore there is no need to test the result of new for 0.
3. Static single assignment form must notice that the assignment of 0 is
redundant.
[Bug rtl-optimization/79577] Infinite loop with -fselective-scheduling2 -O2 --param selsched-max-sched-times=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79577 --- Comment #2 from Richard Biener --- I guess so.
[Bug c++/79578] Unnecessary instructions in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578 --- Comment #1 from Maxim Egorushkin --- clang-3.9.1 generates code that I expect: f(char*): # @f(char*) movl$131073, (%rdi) # imm = 0x20001 movq%rdi, %rax retq
[Bug tree-optimization/79578] Unnecessary instructions in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-17
CC||law at gcc dot gnu.org
Component|c++ |tree-optimization
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Note that appearantly b is allowed to be NULL.
Confirmed for the partial dead code elimination issue. tree DSE sees
[100.00%]:
if (b_3(D) != 0B)
goto ; [0.00%]
else
goto ; [0.00%]
[0.00%]:
MEM[(struct A *)b_3(D)] = {};
[0.00%]:
MEM[(struct A *)b_3(D)].a = 1;
MEM[(struct A *)b_3(D)].b = 2;
return b_3(D);
and after store-merging we have (no further DSE):
[100.00%]:
if (b_2(D) != 0B)
goto ; [73.26%]
else
goto ; [26.74%]
[73.26%]:
MEM[(struct A *)b_2(D)] = {};
[100.00%]:
MEM[(short unsigned int *)b_2(D)] = 131073;
return b_2(D);
Jeff -- wasn't your "partial DSE" supposed to help here? Ah, it was to
trim partial stores rather than full stores followed by partial ones
making it dead?
[Bug tree-optimization/79578] Unnecessary instructions in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578 --- Comment #3 from Jonathan Wakely --- (In reply to Maxim Egorushkin from comment #0) > 2. The code assigns through that pointer, so the pointer must be valid. > Therefore there is no need to test the result of new for 0. In any case, we fixed the standard so that it's undefined to pass null to the placement new operator, so the check should never happen now, without needing to see the origin of the pointer or whether it is subsequently derferenced. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1748 (See also PR 35878 comment 2)
[Bug ipa/79579] New: [5/6/7 Regression] ICE in ipa_write_node_info (ipa-prop.c:4931)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79579 Bug ID: 79579 Summary: [5/6/7 Regression] ICE in ipa_write_node_info (ipa-prop.c:4931) Product: gcc Version: unknown 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: jamborm at gcc dot gnu.org Target Milestone: --- Starting from my commit r219005, we ICE on: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr59610.c -O1 -flto /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/pr59610.c:11:1: internal compiler error: Segmentation fault } ^ 0xa85d9f crash_signal ../../gcc/toplev.c:337 0x8f73b8 vec::operator[](unsigned int) ../../gcc/vec.h:733 0x8f73b8 ipa_write_node_info ../../gcc/ipa-prop.c:4931 0x8f73b8 ipa_prop_write_jump_functions() ../../gcc/ipa-prop.c:5067 0x9cada8 ipa_write_summaries_2 ../../gcc/passes.c:2609 0x9cc251 ipa_write_summaries_1 ../../gcc/passes.c:2640 0x9cc251 ipa_write_summaries() ../../gcc/passes.c:2702 0x7594bc ipa_passes ../../gcc/cgraphunit.c:2368 0x7594bc symbol_table::compile() ../../gcc/cgraphunit.c:2462 0x75b194 symbol_table::compile() ../../gcc/cgraphunit.c:2595 0x75b194 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2621
[Bug tree-optimization/79578] Unnecessary instructions in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578 --- Comment #4 from Jonathan Wakely --- Since the check comes from the front-end, and the DR says it's not needed, maybe this belongs to component c++ not tree-optimization. If the front-end didn't insert the check we wouldn't need to optimize it away.
[Bug tree-optimization/79529] [7 Regression] ICE in is_maybe_undefined (tree-ssa-loop-unswitch.c:162)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79529 --- Comment #3 from Martin Liška --- Author: marxin Date: Fri Feb 17 14:36:08 2017 New Revision: 245530 URL: https://gcc.gnu.org/viewcvs?rev=245530&root=gcc&view=rev Log: Introduce ssa_defined_default_def_p function (PR tree-optimization/79529). 2017-02-17 Martin Liska PR tree-optimization/79529 * tree-ssa-loop-unswitch.c (is_maybe_undefined): Use ssa_defined_default_def_p to handle cases which are implicitly defined. * tree-ssa.c (ssa_defined_default_def_p): New function. (ssa_undefined_value_p): Use ssa_defined_default_def_p to handle cases which are implicitly defined. * tree-ssa.h (ssa_defined_default_def_p): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c trunk/gcc/tree-ssa.c trunk/gcc/tree-ssa.h
[Bug ipa/79579] [5/6/7 Regression] ICE in ipa_write_node_info (ipa-prop.c:4931)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79579 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-17 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor --- Apparently the optimize(0) attribute suppresses a necessary call to ipa_check_create_edge_args somewhere. I'll add one at the beginning of ipa_prop_write_jump_functions, which should fix this.
[Bug rtl-optimization/79574] ICE in want_to_gcse_p, at gcse.c:804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79574 --- Comment #1 from Martin Liška --- Author: marxin Date: Fri Feb 17 14:46:14 2017 New Revision: 245531 URL: https://gcc.gnu.org/viewcvs?rev=245531&root=gcc&view=rev Log: Use HOST_WIDE_INT for a param calculation (PR rtl-optimization/79574). 2017-02-17 Martin Liska PR rtl-optimization/79574 * gcc.dg/pr79574.c: New test. 2017-02-17 Martin Liska PR rtl-optimization/79574 * gcse.c (want_to_gcse_p): Prevent integer overflow. Added: trunk/gcc/testsuite/gcc.dg/pr79574.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/79577] Infinite loop with -fselective-scheduling2 -O2 --param selsched-max-sched-times=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79577 --- Comment #3 from Martin Liška --- Author: marxin Date: Fri Feb 17 14:47:08 2017 New Revision: 245532 URL: https://gcc.gnu.org/viewcvs?rev=245532&root=gcc&view=rev Log: Increase minimum for a param (PR rtl-optimization/79577). 2017-02-17 Martin Liska PR rtl-optimization/79577 * params.def (selsched-max-sched-times): Increase minimum to 1. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug rtl-optimization/79574] ICE in want_to_gcse_p, at gcse.c:804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79574 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-17 Known to work||7.0 Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #2 from Martin Liška --- Fixed on trunk so far.
[Bug rtl-optimization/79577] Infinite loop with -fselective-scheduling2 -O2 --param selsched-max-sched-times=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79577 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-17 Known to work||7.0 Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #4 from Martin Liška --- Fixed on trunk so far.
[Bug tree-optimization/79529] [7 Regression] ICE in is_maybe_undefined (tree-ssa-loop-unswitch.c:162)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79529 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Comment #53 from janus at gcc dot gnu.org ---
Carrying over the test case from PR 79572:
#include
void f(const int &iref) {
if (&iref)
std::cout << iref << std::endl;
else
std::cout << "iref is NULL" << std::endl;
}
int main () {
f(*((int*) NULL));
return 0;
}
This dereferences a NULL pointer in a very explicit fashion, but is not being
caught by -Wnull-dereference, neither with 6.2 nor with current 7-trunk.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) > But at least clang 3.9 has some additional diagnostics: > > null_ref.cpp:11:5: warning: binding dereferenced null pointer to reference > has undefined behavior [-Wnull-dereference] > f(*((int*) NULL)); > ^~ > > Ideally GCC should yield the same warning See PR 16351. Lately GCC seems to have a -Wnull-dereference flag as well, but apparently it fails on the test case here.
[Bug fortran/79426] [5/6/7 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79426 --- Comment #3 from janus at gcc dot gnu.org --- Reduced test case ... subroutine gruppe implicit none type :: CGruppe class(*), dimension(:), pointer :: el end type type(CGruppe) :: group select type ( p => group%el(1) ) end select end subroutine ... with a slightly different ICE: internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
[Bug tree-optimization/79578] Unnecessary instructions in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 from Jeffrey A. Law ---
So at the first DSE pass the IL looks like:
;; basic block 2, loop depth 0
;;pred: ENTRY
if (b_3(D) != 0B)
goto ; [0.00%]
else
goto ; [0.00%]
;;succ: 3
;;4
;; basic block 3, loop depth 0
;;pred: 2
# .MEM_9 = VDEF <.MEM_5(D)>
MEM[(struct A *)b_3(D)] = {};
;;succ: 4
;; basic block 4, loop depth 0
;;pred: 3
;;2
# .MEM_2 = PHI <.MEM_9(3), .MEM_5(D)(2)>
# .MEM_12 = VDEF <.MEM_2>
MEM[(struct A *)b_3(D)].a = 1;
# .MEM_13 = VDEF <.MEM_12>
MEM[(struct A *)b_3(D)].b = 2;
# VUSE <.MEM_13>
return b_3(D);
;;succ: EXIT
The initialization looks like a fully dead store to me. And it is. The reason
it's not caught is we currently require pointer equality on the address
expression. Using operand_equal_p instead results in the initialization being
eliminated by DSE1. I think the only question is whether or not to fix this
during stage4 or wait for gcc-8. It's a 1-liner ;-)
Of course once the dead store is gone BB3 is pointless and we can eliminate the
test resulting in:
movq%rdi, %rax
movl$131073, (%rdi)
ret
[Bug c++/79510] #pragma GCC diagnostic pop/push/ignored doesn't work as expected in template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79510 --- Comment #2 from Pierre Chevalier --- (In reply to Martin Sebor from comment #1) > GCC doesn't define a __gcc__ macro. In C++ mode it defines __GNUC__ and > __GNUG__: > > https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html Silly me :| Thanks Martin!
[Bug rtl-optimization/79541] lra reads uninitialized memory (with invalid input)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79541 --- Comment #3 from Vladimir Makarov --- Author: vmakarov Date: Fri Feb 17 16:10:59 2017 New Revision: 245536 URL: https://gcc.gnu.org/viewcvs?rev=245536&root=gcc&view=rev Log: 2017-02-17 Vladimir Makarov PR rtl-optimization/79541 * lra-constraints.c (curr_insn_transform): Remove wrong asm insn instead of transforming it into USE. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug c++/69564] [5/6/7 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #35 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #34) > But as A + 8 >= B || A >= B + 8 is the same as ABS (A - B) >= 8 we might do > better re-writing the overlap test in terms of this (of course it all really > depends on whether that and the offset stripping handles arrays crossing the > "signed overlap" boundary in the address space correctly...) I had a patch doing this, will revise and send for review. Thanks.
[Bug tree-optimization/77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #6 from amker at gcc dot gnu.org --- Proposed patch @https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01057.html
[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 --- Comment #25 from Jeffrey A. Law --- "When doing so allows for simplification" is actually a pretty low bar here. We just have to prove the widening cast is a common subexpression. Once we do that, we know widening is a win. And that's relatively easy to discover. You go back to the SSA_NAME_DEF_STMT of the object you want to widen, then walk over its immediate uses to see if one is a proper widening op that dominates the expression we're trying to simplify. That's it, nothing else needed to prove profitability. We only get ~20 hits in a bootstrap, but I didn't expect this idiom to show up all that much. -- Trying to do all the pattern matching in phi-opt and ultimately generate the min/max is going to be *hideous* because we're trying to do too many things at once. We have components of CSE, VRP and DCE that we'd have to bring into phi-opt, which seems wrong to me. Contrast that to simplifying the IL like my match.pd pattern does. We make a simple, profitable, change to the IL. That one profitable change in the IL has ripple effects that allow subsequent passes to do their jobs with the final result that the minmax detection code is presented with exactly the IL it knows how to transform. -- Alternately (and I haven't prototyped this) we could try again to look at this as a redundancy elimination problem. Given X = A + B in DOM, where A comes from a narrowed operand (A'). Lookup a widened B in the expression table (B'). If found, then lookup A' + B'. If found (lhs), then replace X = A + B with X = (typeof X) ((lhs) & mask). That's essentially doing the same thing as the prototype match.pd pattern. Except that we know the operand widening as well as the widened arithmetic are both CSEs.
[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731 --- Comment #17 from uros at gcc dot gnu.org --- Author: uros Date: Fri Feb 17 16:35:37 2017 New Revision: 245537 URL: https://gcc.gnu.org/viewcvs?rev=245537&root=gcc&view=rev Log: PR target/76731 * config/i386/avx512fintrin.h (_mm512_i32gather_ps): Change __addr type to void const*. (_mm512_mask_i32gather_ps): Ditto. (_mm512_i32gather_pd): Ditto. (_mm512_mask_i32gather_pd): Ditto. (_mm512_i64gather_ps): Ditto. (_mm512_mask_i64gather_ps): Ditto. (_mm512_i64gather_pd): Ditto. (_mm512_mask_i64gather_pd): Ditto. (_mm512_i32gather_epi32): Ditto. (_mm512_mask_i32gather_epi32): Ditto. (_mm512_i32gather_epi64): Ditto. (_mm512_mask_i32gather_epi64): Ditto. (_mm512_i64gather_epi32): Ditto. (_mm512_mask_i64gather_epi32): Ditto. (_mm512_i64gather_epi64): Ditto. (_mm512_mask_i64gather_epi64): Ditto. (_mm512_i32scatter_ps): Change __addr type to void*. (_mm512_mask_i32scatter_ps): Ditto. (_mm512_i32scatter_pd): Ditto. (_mm512_mask_i32scatter_pd): Ditto. (_mm512_i64scatter_ps): Ditto. (_mm512_mask_i64scatter_ps): Ditto. (_mm512_i64scatter_pd): Ditto. (_mm512_mask_i64scatter_pd): Ditto. (_mm512_i32scatter_epi32): Ditto. (_mm512_mask_i32scatter_epi32): Ditto. (_mm512_i32scatter_epi64): Ditto. (_mm512_mask_i32scatter_epi64): Ditto. (_mm512_i64scatter_epi32): Ditto. (_mm512_mask_i64scatter_epi32): Ditto. (_mm512_i64scatter_epi64): Ditto. (_mm512_mask_i64scatter_epi64): Ditto. * config/i386/avx512pfintrin.h (_mm512_mask_prefetch_i32gather_pd): Change addr type to void const*. (_mm512_mask_prefetch_i32gather_ps): Ditto. (_mm512_mask_prefetch_i64gather_pd): Ditto. (_mm512_mask_prefetch_i64gather_ps): Ditto. (_mm512_prefetch_i32scatter_pd): Change addr type to void*. (_mm512_prefetch_i32scatter_ps): Ditto. (_mm512_mask_prefetch_i32scatter_pd): Ditto. (_mm512_mask_prefetch_i32scatter_ps): Ditto. (_mm512_prefetch_i64scatter_pd): Ditto. (_mm512_prefetch_i64scatter_ps): Ditto. (_mm512_mask_prefetch_i64scatter_pd): Ditto. (_mm512_mask_prefetch_i64scatter_ps): Ditto. * config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps): Change __addr type to void const*. (_mm_mmask_i32gather_ps): Ditto. (_mm256_mmask_i32gather_pd): Ditto. (_mm_mmask_i32gather_pd): Ditto. (_mm256_mmask_i64gather_ps): Ditto. (_mm_mmask_i64gather_ps): Ditto. (_mm256_mmask_i64gather_pd): Ditto. (_mm_mmask_i64gather_pd): Ditto. (_mm256_mmask_i32gather_epi32): Ditto. (_mm_mmask_i32gather_epi32): Ditto. (_mm256_mmask_i32gather_epi64): Ditto. (_mm_mmask_i32gather_epi64): Ditto. (_mm256_mmask_i64gather_epi32): Ditto. (_mm_mmask_i64gather_epi32): Ditto. (_mm256_mmask_i64gather_epi64): Ditto. (_mm_mmask_i64gather_epi64): Ditto. (_mm256_i32scatter_ps): Change __addr type to void*. (_mm256_mask_i32scatter_ps): Ditto. (_mm_i32scatter_ps): Ditto. (_mm_mask_i32scatter_ps): Ditto. (_mm256_i32scatter_pd): Ditto. (_mm256_mask_i32scatter_pd): Ditto. (_mm_i32scatter_pd): Ditto. (_mm_mask_i32scatter_pd): Ditto. (_mm256_i64scatter_ps): Ditto. (_mm256_mask_i64scatter_ps): Ditto. (_mm_i64scatter_ps): Ditto. (_mm_mask_i64scatter_ps): Ditto. (_mm256_i64scatter_pd): Ditto. (_mm256_mask_i64scatter_pd): Ditto. (_mm_i64scatter_pd): Ditto. (_mm_mask_i64scatter_pd): Ditto. (_mm256_i32scatter_epi32): Ditto. (_mm256_mask_i32scatter_epi32): Ditto. (_mm_i32scatter_epi32): Ditto. (_mm_mask_i32scatter_epi32): Ditto. (_mm256_i32scatter_epi64): Ditto. (_mm256_mask_i32scatter_epi64): Ditto. (_mm_i32scatter_epi64): Ditto. (_mm_mask_i32scatter_epi64): Ditto. (_mm256_i64scatter_epi32): Ditto. (_mm256_mask_i64scatter_epi32): Ditto. (_mm_i64scatter_epi32): Ditto. (_mm_mask_i64scatter_epi32): Ditto. (_mm256_i64scatter_epi64): Ditto. (_mm256_mask_i64scatter_epi64): Ditto. (_mm_i64scatter_epi64): Ditto. (_mm_mask_i64scatter_epi64): Ditto. * config/i386/i386-builtin-types.def (V16SF_V16SF_PCFLOAT_V16SI_HI_INT) (V8DF_V8DF_PCDOUBLE_V8SI_QI_INT, V8SF_V8SF_PCFLOAT_V8DI_QI_INT) (V8DF_V8DF_PCDOUBLE_V8DI_QI_INT, V16SI_V16SI_PCINT_V16SI_HI_INT) (V8DI_V8DI_PCINT64_V8SI_QI_INT, V8SI_V8SI_PCINT_V8DI_QI_INT) (V8DI_V8DI_PCINT64_V8DI_QI_INT, V2DF_V2DF_PCDOUBLE_V4SI_QI_INT) (V4DF_V4DF_PCDOUBLE_V4SI_QI_INT, V2DF_V2DF_PCDOUBLE_V2DI_QI_INT) (V4DF_V4DF_PCDOUBLE_V4DI_QI_
[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.5 --- Comment #18 from Uroš Bizjak --- Fixed everywhere.
[Bug c++/79533] [7 Regression] ICE in build_over_call under -std=c++17 in 'S s(static_cast(f()));'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79533 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Feb 17 16:50:16 2017 New Revision: 245538 URL: https://gcc.gnu.org/viewcvs?rev=245538&root=gcc&view=rev Log: PR c++/79533 - C++17 ICE with temporary cast to reference * call.c (build_over_call): Conversion to a reference prevents copy elision. Added: trunk/gcc/testsuite/g++.dg/init/elide6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/78690] [7 Regression] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78690 --- Comment #5 from Jakub Jelinek --- The #c0 testcase doesn't ICE anymore since r245440. The #c4 testcase still ICEs.
[Bug rtl-optimization/79541] lra reads uninitialized memory (with invalid input)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79541 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk
[Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388 --- Comment #14 from Martin Sebor --- I agree with the goal of making containers efficient so please take this as constructive criticism. Jonathan and I discussed this on IRC a bit yesterday and I've thought about it some more since then. I'm unconvinced the suggested optimization would be valid (conforming). To Marc's point in comment #11, the default vector was never intended to be stack-based and I'm not aware of any change in the standard that would make it valid to allocate it on the stack. To Jonathan's point in comment #12, "eventually" means that creating one or more non-empty vectors can be expected by a conforming program to cause at least one call to operator new. Beyond conformance, another, arguably even more important, point to consider is that vector is required to throw an exception when memory is exhausted. Implementing it to live on the stack (and allocate memory via alloca) would either violate that requirement, letting it exhaust the stack and crash the program, or mean checking the amount of available stack space on every allocation (or just the first allocation). Alternatively, it would mean gating the optimization on known sizes of the vector that were less than some small constant maximum (i.e., effectively turning std::vector into std::array.) Jonathan also reminded me that vectors A and B must satisfy the "i = A.begin(); A.swap (B); assert (i == B.begin())" postcondition, with swap having constant complexity. A vector allocated on the stack would not, in general, be able to satisfy these requirements. It couldn't be swapped with or moved in constant time to another vector with a different lifetime, further constraining the optimization. There may be clever ways to overcome these problems, either by making the implementation more complex, or by relaxing the standard requirements on implementations, or (likely both), but they would have costs of their own. The former likely in efficiency and significant complexity, and the latter in constraining programs (i.e., breaking some that are now valid). So in summary, while I would like to see STL containers be as efficient as they can be (and have, in fact, been thinking and talking with Jeff about how to improve them to this end), I don't think this optimization is viable. It may be unfortunate but it is the price of generality, customizability, and conformance.
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 Alexander Monakov changed: What|Removed |Added CC||abel at gcc dot gnu.org --- Comment #5 from Alexander Monakov --- It looks suspicious to me that the code tries to look at the original block of an expr being moved up, generally there can be more than one origin if an expr was "unified" at branches. Alexandre, do you recall why debug insns at heads of basic blocks are special? As a wild guess, perhaps the code meant to special-case that the insn we're moving the expr past is a debug insn? That is, to say 'insn' instead of 'EXPR_INSN_RTX (expr)' in all 3 lines quoted by Jakub?
[Bug c++/79548] [5/6/7 Regression] missing -Wunused-variable on a typedef'd variable in a function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79548 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- TREE_USED(decl) is set for a typedef in maybe_record_typedef_use() in c-family/warn.c. Let me see if there's an easy way to fix this.
[Bug c++/79580] New: [5/6/7 Regression] ICE in nested_anon_class_index, at cp/mangle.c:1604
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79580
Bug ID: 79580
Summary: [5/6/7 Regression] ICE in nested_anon_class_index, at
cp/mangle.c:1604
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at ucw dot cz, jason at gcc dot gnu.org
Target Milestone: ---
Following test-case:
$ cat ice.C
class a
{
static const double b;
};
const double a::b ((union { double c; }){}.c);
$ gcc ice.C -flto -std=c++98
ice.C:5:27: internal compiler error: in nested_anon_class_index, at
cp/mangle.c:1604
const double a::b ((union { double c; }){}.c);
^
0x7622cd nested_anon_class_index
../../gcc/cp/mangle.c:1604
0x7622cd write_unnamed_type_name
../../gcc/cp/mangle.c:1618
0x7622cd write_unqualified_name
../../gcc/cp/mangle.c:1380
0x7691f7 write_nested_name
../../gcc/cp/mangle.c:1077
0x7649b5 write_name
../../gcc/cp/mangle.c:976
0x76537c write_class_enum_type
../../gcc/cp/mangle.c:2781
0x76537c write_type
../../gcc/cp/mangle.c:2195
0x769938 mangle_decl_string
../../gcc/cp/mangle.c:3759
0x769a3b get_mangled_id
../../gcc/cp/mangle.c:3783
0x769a3b mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3853
0xdaa00e decl_assembler_name(tree_node*)
../../gcc/tree.c:671
0xdaa00e assign_assembler_name_if_needed(tree_node*)
../../gcc/tree.c:5920
0xdab514 free_lang_data_in_cgraph
../../gcc/tree.c:5969
0xdab514 free_lang_data
../../gcc/tree.c:6006
0xdab514 execute
../../gcc/tree.c:6055
