[Bug middle-end/86172] New: [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug ID: 86172 Summary: [meta-bug] issues with -Wnull-dereference Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: diagnostic, meta-bug Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Depends on: 71157, 77432, 84316, 84315 Target Milestone: --- Split off from bug 16351 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157 [Bug 71157] -Wnull-dereference false alarm in wrong function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77432 [Bug 77432] warn about null check after pointer dereference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84315 [Bug 84315] missing -Wnonnull for trivial null pointer dereference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84316 [Bug 84316] missing -Wnull-dereference on a variable null array reference with LTO
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #59 from Eric Gallager --- (In reply to Martin Sebor from comment #58) > It's fine with me, just as long as we don't lose track of any outstanding > bugs. The meta-bug is now bug 86172; closing this one.
[Bug middle-end/77432] warn about null check after pointer dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77432 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77425, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77421, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=16351 --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Hmm, there was a warning for this specific thing, I thought but I could be > wrong. Maybe it only happens with optimization. > > Oh that is -Wnull-dereference which is slightly different, this case is when > eliminating the conditional due to dereferencing rather than having a path > which might deference a null pointer. They could still be grouped under the same flag though.
[Bug tree-optimization/86159] [6/7/8 Regression] g++ ICE at -O1 and above on valid code: incorrect type of vector CONSTRUCTOR elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86159 Richard Biener changed: What|Removed |Added Keywords|needs-bisection | --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Jun 15 11:08:30 2018 New Revision: 261622 URL: https://gcc.gnu.org/viewcvs?rev=261622=gcc=rev Log: 2018-06-15 Richard Biener PR middle-end/86159 * tree-cfg.c (gimplify_build3): Do not strip sign conversions, leave useless conversion stripping to force_gimple_operand_gsi. (gimplify_build2): Likewise. (gimplify_build1): Likewise. * g++.dg/pr86159.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr86159.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #5) > The problem is in cross-jumping, we have a landing pad with one > EDGE_CROSSING and some EH predecessor edges. The DF code treats the > bb_has_eh_pred specially and creates artificial generation of the > EH_RETURN_DATA_REGNO blocks at the start of those blocks, rather than making > those regs visible on the in edge. > > I've tried: > --- gcc/bb-reorder.c.jj 2018-05-31 21:51:18.508292965 +0200 > +++ gcc/bb-reorder.c 2018-06-15 12:57:34.501095317 +0200 > @@ -1507,8 +1507,11 @@ dw2_fix_up_crossing_landing_pad (eh_land >new_lp->landing_pad = gen_label_rtx (); >LABEL_PRESERVE_P (new_lp->landing_pad) = 1; > > + e = split_block_after_labels (old_bb); > + old_bb = e->src; > + >/* Create the forwarder block. */ > - basic_block new_bb = create_forwarder_block (new_lp->landing_pad, old_bb); > + basic_block new_bb = create_forwarder_block (new_lp->landing_pad, > e->dest); > >/* Fix up the edges. */ >for (ei = ei_start (old_bb->preds); (e = ei_safe_edge (ei)) != NULL; ) > to make sure we don't have bbs with both EDGE_CROSSING and EH incoming edges. > Another possibility is to disallow cross-jumping of the bb_has_eh_pred basic > blocks, like: > --- gcc/cfgcleanup.c.jj 2018-04-25 09:41:37.753686037 +0200 > +++ gcc/cfgcleanup.c 2018-06-15 13:18:43.173257421 +0200 > @@ -1976,6 +1976,12 @@ try_crossjump_to_edge (int mode, edge e1 >if (!outgoing_edges_match (mode, src1, src2)) > return false; > > + /* The DF uses magic for EH landing pads where the EH_RETURN_DATA_REGNO > + regs are artificially defined at the start. Avoid cross-jumping in > + between the EH landing pads and other bbs. */ > + if (bb_has_eh_pred (src1) != bb_has_eh_pred (src2)) > +return false; > + >/* ... and part the second. */ >nmatch = flow_find_cross_jump (src1, src2, , , ); > > Either of the patches fix the testcase, there is some code growth though, > but maybe it is mainly about adding the missing register moves that are > incorrectly missing without them. Without the patches main has 3259 bytes > and main.cold 1276 bytes, with the first path it is 3337/1371 bytes and with > the second patch instead 3337/1374 bytes. > Conceptually, I think the first patch is better, the DF info isn't incorrect > then (if we have bbs with both crossing and EH predecessors, we don't > mention the EH regs in lr/live in on the EH pad nor in lr/live out on the EH > pad in the other partition that just branches to it. You mean without splitting the block the DF info is incorrect? If so should we add sth to verify-flow-info that makes sure we do not have EDGE_CROSSING and EH incoming edges? Can't an EH edge be EDGE_CROSSING itself?
[Bug c++/86164] New: std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
Bug ID: 86164
Summary: std::regex crashes when matching long lines
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.seelig at yahoo dot de
Target Milestone: ---
std::regex crashes when matching long lines.
Here is an example:
#include
#include
int main()
{
std::string s (100'000, '*');
std::smatch m;
std::regex r ("^(.*?)$");
std::regex_search (s, m, r);
std::cout << s .substr (0, 10) << std::endl;
std::cout << m .str (1) .substr (0, 10) << std::endl;
}
It turns out that std::regex_search operator .* is implemented recursively
which result in this example in a stack overflow.
[Bug tree-optimization/86159] [6/7/8 Regression] g++ ICE at -O1 and above on valid code: incorrect type of vector CONSTRUCTOR elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86159 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[6/7/8/9 Regression] g++|[6/7/8 Regression] g++ ICE |ICE at -O1 and above on |at -O1 and above on valid |valid code: incorrect type |code: incorrect type of |of vector CONSTRUCTOR |vector CONSTRUCTOR elements |elements| --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/86163] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86163 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from ktkachov at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 86164 ***
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108
--- Comment #8 from Jakub Jelinek ---
It is not about crossing or not crossing, but rather about EH predecessors
mixed with non-{EH,abnormal} edges or so.
Without the patch we have:
;; basic block 289, loop depth 0, count 0, probably never executed
;; prev block 288, next block 290, flags: (REACHABLE, COLD_PARTITION, RTL,
MODIFIED)
;; pred: 285 [always] count:0 (CROSSING)
;; 288 [never] count:0 (FALLTHRU)
;; 282 [always] count:0
;; 280 [always] count:0 (CROSSING)
...
;; bb 289 artificial_defs: { }
;; bb 289 artificial_uses: { u-1(6){ }u-1(7){ }}
;; lr in0 [ax] 1 [dx] 6 [bp] 7 [sp] 16 [argp] 20 [frame]
;; lr use 0 [ax] 1 [dx] 6 [bp] 7 [sp]
;; lr def 3 [bx] 43 [r14]
;; live in 0 [ax] 1 [dx] 6 [bp] 7 [sp] 20 [frame]
;; live gen 3 [bx] 43 [r14]
;; live kill
(code_label 1443 2474 1444 289 1738 (nil) [28 uses])
(note 1444 1443 1445 289 [bb 289] NOTE_INSN_BASIC_BLOCK)
(insn 1445 1444 1446 289 (set (reg:DI 43 r14 [464])
(reg:DI 0 ax [468])) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax [468])
(nil)))
(insn 1446 1445 2297 289 (set (reg:DI 3 bx [466])
(reg:DI 1 dx [470])) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 1 dx [470])
(nil)))
(jump_insn 2297 1446 2298 289 (set (pc)
(label_ref 1447)) 683 {jump}
(nil)
-> 1447)
;; succ: 291 [always] count:0
;; lr out 3 [bx] 6 [bp] 7 [sp] 16 [argp] 20 [frame] 43 [r14]
;; live out 3 [bx] 6 [bp] 7 [sp] 20 [frame] 43 [r14]
;; basic block 290, loop depth 0, count 0, probably never executed
;; prev block 289, next block 291, flags: (REACHABLE, COLD_PARTITION, RTL,
MODIFIED)
;; pred: 311 [always] count:0 (CROSSING)
;; 94 [never] count:0 (ABNORMAL,ABNORMAL_CALL,EH)
;; bb 290 artificial_defs: { d32(0){ }d384(1){ }}
;; bb 290 artificial_uses: { u-1(6){ }u-1(7){ }u-1(16){ }u-1(20){ }}
;; lr in6 [bp] 7 [sp] 16 [argp] 20 [frame]
;; lr use 6 [bp] 7 [sp] 16 [argp] 20 [frame]
;; lr def 0 [ax] 1 [dx] 3 [bx] 43 [r14]
;; live in 6 [bp] 7 [sp] 20 [frame]
;; live gen 0 [ax] 1 [dx] 3 [bx] 43 [r14]
;; live kill
(code_label/s 1739 2298 1744 290 1798 (nil) [2 uses])
(note 1744 1739 1740 290 [bb 290] NOTE_INSN_BASIC_BLOCK)
(insn 1740 1744 1741 290 (set (reg:DI 43 r14 [464])
(reg:DI 0 ax)) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(insn 1741 1740 1447 290 (set (reg:DI 3 bx [466])
(reg:DI 1 dx)) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 1 dx)
(nil)))
;; succ: 291 [always] count:0 (FALLTHRU)
;; lr out 3 [bx] 6 [bp] 7 [sp] 16 [argp] 20 [frame] 43 [r14]
;; live out 3 [bx] 6 [bp] 7 [sp] 20 [frame] 43 [r14]
and
;; basic block 311, loop depth 0, count 0, probably never executed
;; prev block 310, next block 1, flags: (REACHABLE, HOT_PARTITION, RTL,
MODIFIED)
;; pred: 77 [never] count:0 (ABNORMAL,ABNORMAL_CALL,EH)
;; 80 [never] count:0 (ABNORMAL,ABNORMAL_CALL,EH)
;; 95 [never] count:0 (ABNORMAL,ABNORMAL_CALL,EH)
;; bb 311 artificial_defs: { d1(0){ }d359(1){ }}
;; bb 311 artificial_uses: { u-1(6){ }u-1(7){ }u-1(16){ }u-1(20){ }}
;; lr in6 [bp] 7 [sp] 16 [argp] 20 [frame]
;; lr use 6 [bp] 7 [sp] 16 [argp] 20 [frame]
;; lr def 0 [ax] 1 [dx]
;; live in 6 [bp] 7 [sp] 20 [frame]
;; live gen 0 [ax] 1 [dx]
;; live kill
(code_label/s 2028 2505 2030 311 1833 (nil) [1 uses])
(note 2030 2028 2029 311 [bb 311] NOTE_INSN_BASIC_BLOCK)
(jump_insn/j 2029 2030 2031 311 (set (pc)
(label_ref 1739)) 683 {jump}
(nil)
-> 1739)
;; succ: 290 [always] count:0 (CROSSING)
;; lr out 6 [bp] 7 [sp] 16 [argp] 20 [frame]
;; live out 6 [bp] 7 [sp] 20 [frame]
so the fact that ax and dx need to be live on the edge from bb 311 to bb 290 is
not visible to DF and if cross-jumping decides to cross-jump bb 289 to 290, DF
will think the ax/dx registers are artificially generated at the start of that
bb, which is the case when arriving there from the EH edges, but not the case
when arriving there from other edges.
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 --- Comment #5 from Jakub Jelinek --- The problem is in cross-jumping, we have a landing pad with one EDGE_CROSSING and some EH predecessor edges. The DF code treats the bb_has_eh_pred specially and creates artificial generation of the EH_RETURN_DATA_REGNO blocks at the start of those blocks, rather than making those regs visible on the in edge. I've tried: --- gcc/bb-reorder.c.jj 2018-05-31 21:51:18.508292965 +0200 +++ gcc/bb-reorder.c2018-06-15 12:57:34.501095317 +0200 @@ -1507,8 +1507,11 @@ dw2_fix_up_crossing_landing_pad (eh_land new_lp->landing_pad = gen_label_rtx (); LABEL_PRESERVE_P (new_lp->landing_pad) = 1; + e = split_block_after_labels (old_bb); + old_bb = e->src; + /* Create the forwarder block. */ - basic_block new_bb = create_forwarder_block (new_lp->landing_pad, old_bb); + basic_block new_bb = create_forwarder_block (new_lp->landing_pad, e->dest); /* Fix up the edges. */ for (ei = ei_start (old_bb->preds); (e = ei_safe_edge (ei)) != NULL; ) to make sure we don't have bbs with both EDGE_CROSSING and EH incoming edges. Another possibility is to disallow cross-jumping of the bb_has_eh_pred basic blocks, like: --- gcc/cfgcleanup.c.jj 2018-04-25 09:41:37.753686037 +0200 +++ gcc/cfgcleanup.c2018-06-15 13:18:43.173257421 +0200 @@ -1976,6 +1976,12 @@ try_crossjump_to_edge (int mode, edge e1 if (!outgoing_edges_match (mode, src1, src2)) return false; + /* The DF uses magic for EH landing pads where the EH_RETURN_DATA_REGNO + regs are artificially defined at the start. Avoid cross-jumping in + between the EH landing pads and other bbs. */ + if (bb_has_eh_pred (src1) != bb_has_eh_pred (src2)) +return false; + /* ... and part the second. */ nmatch = flow_find_cross_jump (src1, src2, , , ); Either of the patches fix the testcase, there is some code growth though, but maybe it is mainly about adding the missing register moves that are incorrectly missing without them. Without the patches main has 3259 bytes and main.cold 1276 bytes, with the first path it is 3337/1371 bytes and with the second patch instead 3337/1374 bytes. Conceptually, I think the first patch is better, the DF info isn't incorrect then (if we have bbs with both crossing and EH predecessors, we don't mention the EH regs in lr/live in on the EH pad nor in lr/live out on the EH pad in the other partition that just branches to it.
[Bug middle-end/86095] [8/9 Regression] documentation for -Wunsafe-loop-optimizations references options which have no effect any more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86095 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||amker at gcc dot gnu.org, ||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Indeed, PR81408 r250304 removed the only remaining case of -Wunsafe-loop-optimizations warning, so the warning option doesn't do anything. We should remove its documentation at least, and make it Common Ignore Warning Does nothing. Preserved for backward compatibility. in common.opt.
[Bug c/86093] [8/9 Regression] volatile ignored on pointer in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86093
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Started with r255021.
genmatch emits all checks as x == y || operand_equal_p (x, y, 0), the reason
why e.g.
long volatile i;
long foo (void) { return i - i; }
isn't optimized into 0 is that we actually wrap i into a NOP_EXPR to remove
quals and only do MINUS_EXPR on the result of those NOP_EXPRs, which don't
compare equal as pointers. So I think we should just do the same with
POINTER_DIFF_EXPR, cast the operands to unqualified pointers.
[Bug c++/86163] New: std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86163
Bug ID: 86163
Summary: std::regex crashes when matching long lines
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.seelig at yahoo dot de
Target Milestone: ---
std::regex crashes when matching long lines.
Here is an example:
#include
#include
int main()
{
std::string s (100'000, '*');
std::smatch m;
std::regex r ("^(.*?)$");
std::regex_search (s, m, r);
std::cout << s .substr (0, 10) << std::endl;
std::cout << m .str (1) .substr (0, 10) << std::endl;
}
[Bug c++/86165] std::regex crashes when matching long lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86165 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from ktkachov at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 86164 ***
[Bug c++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 --- Comment #2 from ktkachov at gcc dot gnu.org --- *** Bug 86165 has been marked as a duplicate of this bug. ***
[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 --- Comment #7 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 > > --- Comment #6 from Richard Biener --- > (In reply to Jakub Jelinek from comment #5) > > The problem is in cross-jumping, we have a landing pad with one > > EDGE_CROSSING and some EH predecessor edges. The DF code treats the > > bb_has_eh_pred specially and creates artificial generation of the > > EH_RETURN_DATA_REGNO blocks at the start of those blocks, rather than making > > those regs visible on the in edge. > > > > I've tried: > > --- gcc/bb-reorder.c.jj 2018-05-31 21:51:18.508292965 +0200 > > +++ gcc/bb-reorder.c2018-06-15 12:57:34.501095317 +0200 > > @@ -1507,8 +1507,11 @@ dw2_fix_up_crossing_landing_pad (eh_land > >new_lp->landing_pad = gen_label_rtx (); > >LABEL_PRESERVE_P (new_lp->landing_pad) = 1; > > > > + e = split_block_after_labels (old_bb); > > + old_bb = e->src; > > + > >/* Create the forwarder block. */ > > - basic_block new_bb = create_forwarder_block (new_lp->landing_pad, > > old_bb); > > + basic_block new_bb = create_forwarder_block (new_lp->landing_pad, > > e->dest); > > > >/* Fix up the edges. */ > >for (ei = ei_start (old_bb->preds); (e = ei_safe_edge (ei)) != NULL; ) > > to make sure we don't have bbs with both EDGE_CROSSING and EH incoming > > edges. > > Another possibility is to disallow cross-jumping of the bb_has_eh_pred basic > > blocks, like: > > --- gcc/cfgcleanup.c.jj 2018-04-25 09:41:37.753686037 +0200 > > +++ gcc/cfgcleanup.c2018-06-15 13:18:43.173257421 +0200 > > @@ -1976,6 +1976,12 @@ try_crossjump_to_edge (int mode, edge e1 > >if (!outgoing_edges_match (mode, src1, src2)) > > return false; > > > > + /* The DF uses magic for EH landing pads where the EH_RETURN_DATA_REGNO > > + regs are artificially defined at the start. Avoid cross-jumping in > > + between the EH landing pads and other bbs. */ > > + if (bb_has_eh_pred (src1) != bb_has_eh_pred (src2)) > > +return false; > > + > >/* ... and part the second. */ > >nmatch = flow_find_cross_jump (src1, src2, , , ); > > > > Either of the patches fix the testcase, there is some code growth though, > > but maybe it is mainly about adding the missing register moves that are > > incorrectly missing without them. Without the patches main has 3259 bytes > > and main.cold 1276 bytes, with the first path it is 3337/1371 bytes and with > > the second patch instead 3337/1374 bytes. > > Conceptually, I think the first patch is better, the DF info isn't incorrect > > then (if we have bbs with both crossing and EH predecessors, we don't > > mention the EH regs in lr/live in on the EH pad nor in lr/live out on the EH > > pad in the other partition that just branches to it. > > You mean without splitting the block the DF info is incorrect? If so should > we add sth to verify-flow-info that makes sure we do not have EDGE_CROSSING > and EH incoming edges? Can't an EH edge be EDGE_CROSSING itself? With dwarf debug info EH edges needs to be non-crossing because they are represented by relative relocations. AFAIK Honza > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug target/86155] std::thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86155 RJE changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from RJE --- Compilers Build on my machine wont build executable code
[Bug c++/86165] New: std::regex crashes when matching long lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86165
Bug ID: 86165
Summary: std::regex crashes when matching long lines.
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.seelig at yahoo dot de
Target Milestone: ---
std::regex crashes when matching long lines.
Here is an example:
#include
#include
int main()
{
std::string s (100'000, '*');
std::smatch m;
std::regex r ("^(.*?)$");
std::regex_search (s, m, r);
std::cout << s .substr (0, 10) << std::endl;
std::cout << m .str (1) .substr (0, 10) << std::endl;
}
It turns out that std::regex_search operator .* is implemented recursively
which result in this example in a stack overflow.
[Bug other/86153] [9 regression] test case g++.dg/pr83239.C fails starting with r261585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 Christophe Lyon changed: What|Removed |Added Target|powerpc64*-*-* |powerpc64*-*-* aarch64 CC||clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- Seen on aarch64 too.
[Bug libstdc++/86138] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-06-15 Ever confirmed|0 |1
[Bug c++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 --- Comment #1 from ktkachov at gcc dot gnu.org --- *** Bug 86163 has been marked as a duplicate of this bug. ***
[Bug fortran/86167] New: allocation variable length character array in derived type incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86167 Bug ID: 86167 Summary: allocation variable length character array in derived type incorrect Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: simon.kluepfel at gmail dot com Target Milestone: --- Created attachment 44285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44285=edit main.f03 Allocation of a member of the form type a character(len=:),dimension(:),allocatable :: a1 end type a is not handled correctly. ---8<--- program main implicit none type a character(len=:),dimension(:),allocatable :: a1 end type a character(len=:),dimension(:),allocatable :: a1,a2 type(a) :: ta type(a) :: tb allocate(character(len=2) :: a1(2)) allocate(a2,source=a1) allocate(character(len=2) :: ta%a1(2)) allocate(tb%a1,source=a2) write(*,*) size(a1),len(a1),len(a1(1)) write(*,*) size(a2),len(a2),len(a1(1)) write(*,*) size(ta%a1),len(ta%a1),len(ta%a1(1)) write(*,*) size(tb%a1),len(tb%a1),len(tb%a1(1)) end program main ---8<--- $ ./a.out 2 2 2 2 2 2 2 0 2 2 0 2 the last two lines should be all 2's gcc version 8.1.0 (Debian 8.1.0-5)
[Bug c/82013] better error message for missing semicolon in prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82013 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Eric Gallager --- Changing status to ASSIGNED because David marked himself as the assignee.
[Bug target/86139] [7 Regression] ICE in in store_constructor, at expr.c:6849 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86139 Matthias Klose changed: What|Removed |Added Target|arm-linux-gnueabihf,|arm-linux-gnueabihf |aarch64-linux-gnu | Summary|[7 Regression] ICE in in|[7 Regression] ICE in in |store_constructor, at |store_constructor, at |expr.c:6849 on |expr.c:6849 on |aarch64-linux-gnu and |arm-linux-gnueabihf |arm-linux-gnueabihf | --- Comment #6 from Matthias Klose --- not seen on aarch64, different issue reported as PR86166.
[Bug target/85945] [6/7 Regression] ICE in resolve_subreg_use, at lower-subreg.c:751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85945 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8/9 Regression] ICE in |[6/7 Regression] ICE in |resolve_subreg_use, at |resolve_subreg_use, at |lower-subreg.c:751 |lower-subreg.c:751 --- Comment #7 from Jakub Jelinek --- Fixed for 8.2+ so far.
[Bug target/86019] [8/9 Regression] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86019 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 CC||amonakov at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- This broke with r251377 aka PR80640 fix.
[Bug middle-end/86166] ICE in convert_move, at expr.c:299 on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86166 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed with GCC 5 and 6 branches.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #57 from Eric Gallager --- (In reply to Martin Sebor from comment #56) > I'd say any warning option with more than just a handful of pr's against it > would benefit from having a meta-bug. On second thought I think actually a meta-bug for -Wnull-dereference should be a new, separate bug. There's a large cc-list for this bug and making it a meta-bug would result in everyone on it getting way more emails than they signed up for. So, with a new, separate meta-bug for remaining issues with -Wnull-dereference, would it be okay to close this one?
[Bug libstdc++/86168] New: [9 regression] libstdc++ tests fail with error: call of overloaded 'random_device()' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86168 Bug ID: 86168 Summary: [9 regression] libstdc++ tests fail with error: call of overloaded 'random_device()' is ambiguous Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- New failures: FAIL: 25_algorithms/make_heap/complexity.cc (test for excess errors) FAIL: 25_algorithms/pop_heap/complexity.cc (test for excess errors) FAIL: 25_algorithms/push_heap/complexity.cc (test for excess errors) FAIL: 25_algorithms/sort_heap/complexity.cc (test for excess errors) FAIL: 26_numerics/random/random_device/cons/default.cc (test for excess errors) FAIL: experimental/random/randint.cc (test for excess errors) Typical output is: build/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/experimental/random:45: error: call of overloaded 'random_device()' is ambiguous
[Bug c/86093] [8/9 Regression] volatile ignored on pointer in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86093 --- Comment #3 from Jakub Jelinek --- Created attachment 44284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44284=edit gcc9-pr86093.patch Untested fix.
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 --- Comment #4 from Nick Clifton --- Author: nickc Date: Fri Jun 15 15:25:16 2018 New Revision: 261633 URL: https://gcc.gnu.org/viewcvs?rev=261633=gcc=rev Log: Force user provided warning and error messages to only occupy one line. PR 84195 gcc:* tree.c (escaped_string): New class. Converts an unescaped string into its escaped equivalent. (warn_deprecated_use): Use the new class to convert the deprecation message, if present. (test_escaped_strings): New self test. (test_c_tests): Add test_escaped_strings. * doc/extend.texi (deprecated): Add a note that the deprecation message is affected by the -fmessage-length option, and that control characters will be escaped. (#pragma GCC error): Document this pragma. (#pragma GCC warning): Likewise. * doc/invoke.texi (-fmessage-length): Document this option's effect on the #warning and #error preprocessor directives and the deprecated attribute. testsuite; * gcc.c-torture/compile/pr84195.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr84195.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug fortran/85701] [openacc] ICE in mark_scope_block_unused, at tree-ssa-live.c:364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85701 --- Comment #5 from cesar at gcc dot gnu.org --- Author: cesar Date: Fri Jun 15 13:59:14 2018 New Revision: 261629 URL: https://gcc.gnu.org/viewcvs?rev=261629=gcc=rev Log: PR fortran/85701 Backport from mainline 2018-06-05 Cesar Philippidis PR fortran/85701 gcc/fortran/ * openmp.c (gfc_resolve_oacc_declare): Error on functions and subroutine data clause arguments. gcc/testsuite/ * gfortran.dg/goacc/pr85701.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/goacc/pr85701.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/openmp.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/86166] New: ICE in convert_move, at expr.c:299 on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86166
Bug ID: 86166
Summary: ICE in convert_move, at expr.c:299 on
aarch64-linux-gnu
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
seen with 5.5.0 and the gcc-6-branch on aarch64-linux-gnu, works with newer
versions
$ cat Transform.c
typedef unsigned short a;
# 0 "" 3
__attribute__((__vector_size__(4 * sizeof(a a b;
c() { b = b << 8 | b >> 8; }
$ aarch64-linux-gnu-gcc-6 -c Transform.c
: In function 'c':
:1:18: internal compiler error: in convert_move, at expr.c:299
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug middle-end/85878] [6/7/8/9 Regression] ICE in convert_mode_scalar, at expr.c:287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85878 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 44286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44286=edit gcc9-pr85878.patch Untested fix.
[Bug target/85860] [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r257751.
[Bug fortran/85702] [openacc] ICE in gfc_format_decoder, at fortran/error.c:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702 --- Comment #4 from cesar at gcc dot gnu.org --- Author: cesar Date: Fri Jun 15 14:01:00 2018 New Revision: 261630 URL: https://gcc.gnu.org/viewcvs?rev=261630=gcc=rev Log: PR fortran/85702 Backport from mainline 2018-06-13 Cesar Philippidis PR fortran/85702 gcc/fortran/ * openmp.c (gfc_match_oacc_wait): Use %C to report error location. gcc/testsuite/ * gfortran.dg/goacc/pr85702.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/goacc/pr85702.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/openmp.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/85703] [openacc] ICE in resolve_fntype, at fortran/resolve.c:16313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703 --- Comment #6 from cesar at gcc dot gnu.org --- Author: cesar Date: Fri Jun 15 14:03:00 2018 New Revision: 261631 URL: https://gcc.gnu.org/viewcvs?rev=261631=gcc=rev Log: PR fortran/85703 Backport from mainline 2018-06-13 Cesar Philippidis PR fortran/85703 gcc/fortran/ * parse.c (decode_oacc_directive): Set gfc_matching_function to false. (decode_omp_directive): Likewise. gcc/testsuite/ * gfortran.dg/goacc/pr85703.f90: New test. * gfortran.dg/gomp/pr85703.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/goacc/pr85703.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/gomp/pr85703.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/parse.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- A revised form of the patch has now been apoplied.
[Bug target/86155] std::thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86155 Jonathan Wakely changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #4 from Jonathan Wakely --- Then I think "INVALID" is the right resolution. Thanks for the follow-up.
[Bug libstdc++/86169] .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-15 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |7.4 Ever confirmed|0 |1
[Bug libstdc++/86169] New: .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169
Bug ID: 86169
Summary: .data() fails to unshare strings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
const std::string s0{"hello world"};
std::string s1 {s0};
std::string s2 {s0};
char* p = s1.data();
*p = ' ';
if (s0.compare ("hello world") != 0)
__builtin_abort ();
if (s2.compare ("hello world") != 0)
__builtin_abort ();
return 0;
}
$ g++ a.cpp -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=1; ./a.out
$ g++ a.cpp -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0; ./a.out
Aborted (core dumped)
[Bug libstdc++/86168] [9 regression] libstdc++ tests fail with error: call of overloaded 'random_device()' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86168 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-15 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- My fault, patch on the way ...
[Bug libstdc++/86168] [9 regression] libstdc++ tests fail with error: call of overloaded 'random_device()' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86168 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Jun 15 16:11:12 2018 New Revision: 261636 URL: https://gcc.gnu.org/viewcvs?rev=261636=gcc=rev Log: PR libstdc++/86168 fix ambiguous default constructor PR libstdc++/86168 * include/bits/random.h (random_device(const string&)): Remove default argument. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h
[Bug lto/48200] linking shared library with LTO results in different exported symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=57703 --- Comment #24 from Eric Gallager --- (In reply to Richard Biener from comment #16) > (In reply to Xi Ruoyao from comment #15) > > (In reply to Jan Hubicka from comment #13) > > > Concerning comment #11, if you have toplevel asms you need to disable LTO > > > for that unit, as there is no way to tell for gcc what the asm statement > > > is > > > doing. Perhaps attribute would be better way to do this? > > > > Well then this is PR 57703. Should we mark duplicate? :( > > I think the bug is sufficiently different and should have different > workarounds. > Still worth putting under "See Also" at least...
[Bug libstdc++/86168] [9 regression] libstdc++ tests fail with error: call of overloaded 'random_device()' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86168 --- Comment #3 from Jonathan Wakely --- Should be fixed at r261635
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- Did you file a new PR?
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #9 from Manuel López-Ibáñez --- That makes sense as well. Adding further logic to silence the warning or to make the warning not become an error is what I think is a bad idea. I like also your more explicit wording.
[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 CC||ryxi at stu dot xidian.edu.cn Ever confirmed|0 |1 --- Comment #5 from Eric Gallager --- This came up on gcc-help, which I'll take as confirmation: https://gcc.gnu.org/ml/gcc-help/2018-06/msg00060.html
[Bug other/49194] Trivially stupid inlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (In reply to Jan Hubicka from comment #8) > GCC 4.7 has now shrink wrapping that should reduce effect of inlining large > cold functions called once. Realistic testcases where we still kill code > quality would be welcome. > > I tested patch to disable inlining once for cold calls, but it does not help > in general. What happens is that we stop inlining > constructors/destructors/initialization loops that eventually kills code > quality of some benchmarks since known values are no longer propagated. I > will do more tunning of this for 4.8. > > Honza So are you still working on this then?
[Bug testsuite/86170] New: New test case gcc.c-torture/compile/pr84195.c added in r261633 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86170 Bug ID: 86170 Summary: New test case gcc.c-torture/compile/pr84195.c added in r261633 fails Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make -k check-gcc RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/pr84195.c . . . # of unexpected failures14 FAIL: gcc.c-torture/compile/pr84195.c -O0 (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/pr84195.c -O1 (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/pr84195.c -O2 (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr84195.c -O3 -g (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr84195.c -Os (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/pr84195.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/pr84195.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) The excess warnings all seem to be this: /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.c-torture/compile/pr84195.c:13:12: note: declared here FAIL: gcc.c-torture/compile/pr84195.c -O0 (test for warnings, line 15) FAIL: gcc.c-torture/compile/pr84195.c -O0 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.c-torture/compile/pr84195.c:15:3: warning: 'i' is deprecated: foo bar [-Wdeprecated-declarations]
[Bug libstdc++/86169] .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Jun 15 18:47:29 2018 New Revision: 261642 URL: https://gcc.gnu.org/viewcvs?rev=261642=gcc=rev Log: PR libstdc++/86169 unshare COW string when non-const data() called PR libstdc++/86169 * include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI] (basic_string::data()): Unshare string. * testsuite/21_strings/basic_string/operations/data/char/86169.cc: New. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/operations/data/char/86169.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h
[Bug middle-end/86123] [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jun 15 19:30:58 2018 New Revision: 261647 URL: https://gcc.gnu.org/viewcvs?rev=261647=gcc=rev Log: PR middle-end/86123 * match.pd ((X / Y) == 0 -> X < Y): Don't transform complex divisions. Fix up comment formatting. * gcc.c-torture/compile/pr86123.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr86123.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #10 from joseph at codesourcery dot com ---
On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote:
> Joseph, do you agree that the following shouldn't fail the compilation?
>
> > echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
> > -Wno-error=return-type -
> : In function ‘main’:
> :1:1: warning: control reaches end of non-void function [-Wreturn-type]
> : At top level:
> cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
> [-Werror]
> cc1: all warnings being treated as errors
Yes.
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #6 from Marek Polacek ---
(In reply to Tony E Lewis from comment #5)
> Thanks to all for all work on this.
>
> (Apologies if this isn't helpful but just in case it is...) I notice that
> the original Godbolt snippet ( https://godbolt.org/g/JnrZss ) has regressed
> from a rejects-valid in 8.1 to an ICE on trunk ("9.0.0 20180610") :
I don't see that. This compiles fine with trunk:
struct dummy {
void nonnull() {};
};
typedef void (dummy::*safe_bool)();
constexpr safe_bool a = ::nonnull;
static_assert( static_cast( a ), "" );
int main () { return 0; }
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 --- Comment #14 from Jason Merrill --- Author: jason Date: Fri Jun 15 20:23:13 2018 New Revision: 261658 URL: https://gcc.gnu.org/viewcvs?rev=261658=gcc=rev Log: PR c++/82882 - ICE with lambda in template default argument. * lambda.c (record_null_lambda_scope): New. * pt.c (tsubst_lambda_expr): Use it. * name-lookup.c (do_pushtag): Don't give a lambda DECL_CONTEXT of a function that isn't open. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg8.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/lambda.c branches/gcc-8-branch/gcc/cp/name-lookup.c branches/gcc-8-branch/gcc/cp/pt.c
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 --- Comment #13 from Jason Merrill --- Author: jason Date: Fri Jun 15 20:22:44 2018 New Revision: 261654 URL: https://gcc.gnu.org/viewcvs?rev=261654=gcc=rev Log: PR c++/82882 - ICE with lambda in template default argument. * lambda.c (record_null_lambda_scope): New. * pt.c (tsubst_lambda_expr): Use it. * name-lookup.c (do_pushtag): Don't give a lambda DECL_CONTEXT of a function that isn't open. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/lambda.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 --- Comment #16 from Jason Merrill --- Er, a new PR.
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 --- Comment #15 from Jason Merrill --- A new testcase would have been good, but those testcases are also fixed, now.
[Bug target/85961] scratch register rsi used after function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961 --- Comment #6 from joseph at codesourcery dot com --- On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote: > So - all process_options () option post-processing should go away and be moved > to finish_options ()? I think reducing the amount done in process_options makes sense, yes (watch out for any interations with lang_hooks.post_options or targetm.target_option.override if you move anything to be executed before the calls to those hooks).
[Bug middle-end/85878] [6/7/8/9 Regression] ICE in convert_mode_scalar, at expr.c:287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85878 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Jun 15 20:36:38 2018 New Revision: 261659 URL: https://gcc.gnu.org/viewcvs?rev=261659=gcc=rev Log: PR middle-end/85878 * expr.c (expand_assignment): Remove now redundant COMPLEX_MODE_P check from first store_expr, use to_mode instead of GET_MODE (to_rtx). Only call store_expr for halves if the mode is the same. * gfortran.fortran-torture/compile/pr85878.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr85878.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/85878] [6/7/8/9 Regression] ICE in convert_mode_scalar, at expr.c:287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85878 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jun 15 20:37:46 2018 New Revision: 261660 URL: https://gcc.gnu.org/viewcvs?rev=261660=gcc=rev Log: PR middle-end/85878 * expr.c (expand_assignment): Remove now redundant COMPLEX_MODE_P check from first store_expr, use to_mode instead of GET_MODE (to_rtx). Only call store_expr for halves if the mode is the same. * gfortran.fortran-torture/compile/pr85878.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr85878.f90 Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/86093] [8/9 Regression] volatile ignored on pointer in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86093 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jun 15 20:53:54 2018 New Revision: 261663 URL: https://gcc.gnu.org/viewcvs?rev=261663=gcc=rev Log: PR c/86093 * c-typeck.c (pointer_diff): Cast both pointers to unqualified types before doing POINTER_DIFF_EXPR. * c-c++-common/pr86093.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr86093.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/86147] [8/9 Regression] Lambda is capturing a non-ODR-used constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86147 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-15 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/34484] libgcc should check if feclearexcept (and others) available for BID support on uclibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484 H.J. Lu changed: What|Removed |Added Assignee|hjl.tools at gmail dot com |unassigned at gcc dot gnu.org --- Comment #14 from H.J. Lu --- Unassign myself.
[Bug libstdc++/86169] .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Jun 15 19:01:39 2018 New Revision: 261644 URL: https://gcc.gnu.org/viewcvs?rev=261644=gcc=rev Log: PR libstdc++/86169 unshare COW string when non-const data() called PR libstdc++/86169 * include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI] (basic_string::data()): Unshare string. * testsuite/21_strings/basic_string/operations/data/char/86169.cc: New. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/21_strings/basic_string/operations/data/char/86169.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/basic_string.h
[Bug libstdc++/86169] .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Jun 15 19:19:04 2018 New Revision: 261646 URL: https://gcc.gnu.org/viewcvs?rev=261646=gcc=rev Log: PR libstdc++/86169 unshare COW string when non-const data() called PR libstdc++/86169 * include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI] (basic_string::data()): Unshare string. * testsuite/21_strings/basic_string/operations/data/char/86169.cc: New. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string/operations/data/char/86169.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/basic_string.h
[Bug libstdc++/86169] .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for 7.4, 8.2 and 9.0
[Bug middle-end/86123] [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Jun 15 19:34:11 2018 New Revision: 261648 URL: https://gcc.gnu.org/viewcvs?rev=261648=gcc=rev Log: PR middle-end/86123 * match.pd ((X / Y) == 0 -> X < Y): Don't transform complex divisions. Fix up comment formatting. * gcc.c-torture/compile/pr86123.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr86123.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/match.pd branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/86123] [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 8.2+.
[Bug target/34484] libgcc should check if feclearexcept (and others) available for BID support on uclibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- (In reply to H.J. Lu from comment #9) > DFP needs floating point exception support. If your C library doesn't > support it, you can disable DFP. Are you planning on staying the Assignee for this, H.J.?
[Bug c++/86171] New: g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171
Bug ID: 86171
Summary: g++ ICE on valid code: tree check: expected var_decl
or function_decl, have type_decl in duplicate_decls,
at cp/decl.c:2291
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
It appears to be a recent regression.
g++-8.1 compiles. g++-4.8 also compiles with "-std=c++11"
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180615 (experimental) [trunk revision 261626] (GCC)
$ g++-trunk abc.c
abc.c: In substitution of ‘template using B = typename A::A [with T =
short int]’:
abc.c:4:8: required from here
abc.c:2:46: internal compiler error: tree check: expected var_decl or
function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
template using B = typename A::A;
^
0x78a200 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9336
0x88f372 tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc/gcc/tree.h:3136
0x88f372 duplicate_decls(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/decl.c:2291
0x951389 register_specialization
../../gcc/gcc/cp/pt.c:1625
0x96a81e tsubst_decl
../../gcc/gcc/cp/pt.c:13778
0x95efe7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14193
0x97b7f2 instantiate_template_1
../../gcc/gcc/cp/pt.c:19234
0x97b7f2 instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:19290
0x95f38b instantiate_alias_template
../../gcc/gcc/cp/pt.c:19314
0x95f38b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14220
0x970637 lookup_template_class_1
../../gcc/gcc/cp/pt.c:9391
0x970637 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9646
0x9a069d finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3240
0x91e0a4 cp_parser_template_id
../../gcc/gcc/cp/parser.c:15943
0x91e1a8 cp_parser_class_name
../../gcc/gcc/cp/parser.c:22478
0x92a90f cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:6564
0x92a90f cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6250
0x933509 cp_parser_constructor_declarator_p
../../gcc/gcc/cp/parser.c:26629
0x933509 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13694
0x938c7f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat abc.c
template struct A;
template using B = typename A::A;
template struct A { typedef B U; };
B b;
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #58 from Martin Sebor --- It's fine with me, just as long as we don't lose track of any outstanding bugs.
[Bug target/85961] scratch register rsi used after function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- (In reply to Alexander Monakov from comment #3) > You'd need to disable IPA-RA after forcing -O2 with the pragma, i.e.: > > #pragma GCC optimize "O2" > #pragma GCC optimize "no-ipa-ra" > > We already have logic to disable IPA-RA when instrumentation/profiling is > active, but it's done once in toplev.c. Here the pragma re-enables IPA-RA > after toplev.c:process_options() has disabled it. > > Do we want to adjust it given that "pragma optimized" is documented as "not > suitable for production use"? Hmm, given that -pg -O2 on the command-line doesn't get you IPA-RA enabled I would argue that the #pragma optimize behavior is bogus ... The issue here is that all "special" processing in toplev.c is lost. I'm not sure why we do all this in process_options () rather than in finish_options () because that is called again after applying optimize options AFAICS. So - all process_options () option post-processing should go away and be moved to finish_options ()? Note that process_options () is only called from do_compile and we do the postprocessing after lang_hooks.post_options which is applied only after finish_options () post-processing...
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with my r259378.
[Bug tree-optimization/86159] [7/8/9 Regression] g++ ICE at -O1 and above on valid code: incorrect type of vector CONSTRUCTOR elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86159 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Known to work||6.4.1 Version|unknown |8.1.1 Keywords||ice-on-valid-code, ||needs-bisection Last reconfirmed||2018-06-15 Component|c++ |tree-optimization Ever confirmed|0 |1 Summary|g++ ICE at -O1 and above on |[7/8/9 Regression] g++ ICE |valid code: incorrect type |at -O1 and above on valid |of vector CONSTRUCTOR |code: incorrect type of |elements|vector CONSTRUCTOR elements Target Milestone|--- |7.4 Known to fail||7.3.1 --- Comment #1 from Richard Biener --- Confirmed. Works on the GCC 6 branch. We have a mismatch between signed int vector and unsigned int elements in the constructor. I will have a looksee.
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c/86156] ffmpeg clean clone fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86156 --- Comment #3 from Richard Biener --- Or a support library like gmp or mpfr or mpc is built for a different architecture.
[Bug bootstrap/86162] [6 Regression] ppc64le bootstrap fails with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86162 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-15 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |6.5 Ever confirmed|0 |1
[Bug bootstrap/86162] New: [6 Regression] ppc64le bootstrap fails with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86162 Bug ID: 86162 Summary: [6 Regression] ppc64le bootstrap fails with GCC 8 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- It's clone of: https://bugzilla.suse.com/show_bug.cgi?id=1097283=1 [ 171s] g++ -fmessage-length=0 -grecord-gcc-switches -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -U_FORTIFY_SOURCE -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/gentarget-def \ [ 171s] build/gentarget-def.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o build/read-md.o build/errors.o ../build-powerpc64le-suse-linux/libiberty/libiberty.a [ 171s] build/genmatch --gimple ../../gcc/match.pd \ [ 171s] > tmp-gimple-match.c [ 171s] ../../gcc/match.pd:120:1 error: expected (, got NAME [ 171s]negative value by 0 gives -0, not +0. */ We are missing lex.c hunk from r256656.
[Bug other/86153] [9 regression] test case g++.dg/pr83239.C fails starting with r261585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. The testcase says the absence of the warning depends on the inlining but it seems it doesn't (no extra diagnostic reported). So maybe just remove this dump-scanning.
[Bug tree-optimization/86159] [6/7/8/9 Regression] g++ ICE at -O1 and above on valid code: incorrect type of vector CONSTRUCTOR elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86159 Richard Biener changed: What|Removed |Added Target Milestone|7.4 |6.5 Summary|[7/8/9 Regression] g++ ICE |[6/7/8/9 Regression] g++ |at -O1 and above on valid |ICE at -O1 and above on |code: incorrect type of |valid code: incorrect type |vector CONSTRUCTOR elements |of vector CONSTRUCTOR ||elements --- Comment #2 from Richard Biener --- The issue is just latent on the GCC 6 branch.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #7 from Manuel López-Ibáñez --- What I'm suggesting is to add an option to control this warning, which is currently enabled by default. Then you can use -Wno-error or even -Wno- to make it always a warning or completely disable it. This what clang does.
[Bug middle-end/86123] [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123 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 44283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44283=edit gcc9-pr86123.patch Untested fix.
[Bug tree-optimization/86144] GCC is not generating vector math calls to svml/acml functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86144
--- Comment #3 from vekumar at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Note a workaround would be to re-arrange the vectorizer calls to
> vectorizable_simd_clone_call and vectorizable_call. Can you check if
> the following works? It gives precedence to what the target hook
> (and thus -mveclibabi) provides.
>
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 9f365e31e49..bdef56bf65e 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -9543,13 +9543,13 @@ vect_analyze_stmt (gimple *stmt, bool
> *need_to_vectorize, slp_tree node,
>if (!bb_vinfo
>&& (STMT_VINFO_RELEVANT_P (stmt_info)
> || STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def))
> -ok = (vectorizable_simd_clone_call (stmt, NULL, NULL, node, cost_vec)
> +ok = (vectorizable_call (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_conversion (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_shift (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_operation (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_assignment (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_load (stmt, NULL, NULL, node, node_instance,
> cost_vec)
> - || vectorizable_call (stmt, NULL, NULL, node, cost_vec)
> + || vectorizable_simd_clone_call (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_store (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_reduction (stmt, NULL, NULL, node, node_instance,
> cost_vec)
> @@ -9559,14 +9559,14 @@ vect_analyze_stmt (gimple *stmt, bool
> *need_to_vectorize, slp_tree node,
>else
> {
>if (bb_vinfo)
> - ok = (vectorizable_simd_clone_call (stmt, NULL, NULL, node, cost_vec)
> + ok = (vectorizable_call (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_conversion (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_shift (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_operation (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_assignment (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_load (stmt, NULL, NULL, node, node_instance,
> cost_vec)
> - || vectorizable_call (stmt, NULL, NULL, node, cost_vec)
> + || vectorizable_simd_clone_call (stmt, NULL, NULL, node,
> cost_vec)
> || vectorizable_store (stmt, NULL, NULL, node, cost_vec)
> || vectorizable_condition (stmt, NULL, NULL, NULL, 0, node,
> cost_vec)
Checked the patch now it give preference to -mveclibabi= option and generating
expected calls.
[Bug tree-optimization/86076] [7/8 Regression] ICE: verify_gimple failed (error: location references block not in block tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86076 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Jun 15 07:25:13 2018 New Revision: 261620 URL: https://gcc.gnu.org/viewcvs?rev=261620=gcc=rev Log: 2018-06-15 Richard Biener PR middle-end/86076 * tree-cfg.c (move_stmt_op): unshare invariant addresses before adjusting their block. * gcc.dg/pr86076.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr86076.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug middle-end/86122] [8/9 Regression] ICE in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86122 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 8.2+.
[Bug middle-end/86123] [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r253218.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #6 from Richard Biener ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to rguent...@suse.de from comment #4)
> > fails the compile but with the warning not emitted the error isn't
> > emitted. Also we do know the warning is guarded by -Wreturn-type
> > so I see no point in warning that it wasn't silenced by
> > -Wno-unknown-warning-option?
>
> I see what you mean: The warning that could have been silenced did not
> prevent compilation but the warning about the unknown option did. However,
>
> 1) Given -Wno-foo, there is no way to know if you actually meant -Wno-f
> or, -Wfoo is an alias for -Wreturn-type in some other version of GCC. Maybe
> you really meant to write -Wno-return-type but you mistyped it as -Wno-foo.
> The current behavior means "There is at least one diagnostic that could
> have been silenced by -Wno-foo, but this GCC does not recognize -Wfoo, maybe
> you gave the wrong option?"
>
> 2) The warning behaves like any other warning: It gets converted to an error
> with -Werror. Imagine an example where GCC gives both a warning [-Wfooo] and
> a warning converted to an error [-Werror=f], what should we report for
> -Wno-fo ?
>
> We can alleviate (2) by giving it a name (clang uses
> -Wunknown-warning-option) so that you can do:
>
> gcc -S -x c -Wall -Werror -Wno-error=return-type
> -Wno-error=unknown-warning-option -Wno-foo
There is no way to specify that the diagnostic about the unknown
-Wno-unknown-warning-option should not be promoted to an error.
-Wno-error=unknown-warning-option and variants do not work because
the option isn't known. The diagnostic lists [-Werror] so the only
option is to disable -Werror.
In general I question that we raise a diagnostic at all here but
I can live with that. But this diagnostic about unknown options
should never be promoted to errors from warnings IMHO.
> Another example:
>
> gcc -S -x c -Wall -Werror -Wno-misleading-identation -Wno-future
>
> If there is no warning emitted, there is no harm in the above -Wno- options.
>
> If there is a warning emitted, it will get converted to an error, and GCC
> does not know if you actually meant -Wno-misleading-indentation. And maybe
> you really want to use -Wno-future for a future -Wfuture enabled by -Wall,
> and you don't care but you want the same command-line to work on previous
> GCC versions so giving an extra warning (or error) or may be you really
> meant the warning used to be called -Wmisleading-identation, but it got
> renamed.
Sure. But if you come back to my case where I had -Werror and specifically
disabled promoting a specific warning to an error then I got what I wanted
and there's no point in erroring for the unknown warning option.
I guess a solution would be to not emit a warning about the unknown option
but a note (using inform).
Joseph, do you agree that the following shouldn't fail the compilation?
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
> -Wno-error=return-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
[-Werror]
cc1: all warnings being treated as errors
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #8 from rguenther at suse dot de ---
On Fri, 15 Jun 2018, lopezibanez at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
>
> --- Comment #7 from Manuel López-Ibáñez ---
> What I'm suggesting is to add an option to control this warning, which is
> currently enabled by default. Then you can use -Wno-error or even -Wno- to
> make it always a warning or completely disable it. This what clang does.
That sounds reasonable but then don't you have a chicken-and-egg
issue because you'd need to say
-Wno-unknown-warning-option
which when not known in old compilers will cause the very same issue
with -Werror ...
What's bad about changing the diagnostic to be emitted as a note
after the very first warning that is emitted? So
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall
-Werror -Wno-error=return-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function
[-Wreturn-type]
: note: unrecognized command line option "-Wno-unknown-warning-option"
may have silenced this or further diagnostics
...
? Which also makes the intent of the warning more explicit.
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #5 from Tony E Lewis ---
Thanks to all for all work on this.
(Apologies if this isn't helpful but just in case it is...) I notice that the
original Godbolt snippet ( https://godbolt.org/g/JnrZss ) has regressed from a
rejects-valid in 8.1 to an ICE on trunk ("9.0.0 20180610") :
g++: internal compiler error: Segmentation fault signal terminated program as
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- The problem appeared between r261472 and r261580
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #3 from Jan Hubicka --- The dumps contains addresses of tree nodes streamed. I will work out how to silence them. Honza
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108
--- Comment #3 from Jakub Jelinek ---
The IL seems to be still correct in *.csa dump, where we have:
(code_label/s 1755 2240 1758 246 1802 (nil) [1 uses])
(note 1758 1755 1756 246 [bb 246] NOTE_INSN_BASIC_BLOCK)
(insn 1756 1758 1757 246 (set (reg:DI 41 r12 [469])
(reg:DI 0 ax)) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(insn 1757 1756 2081 246 (set (reg:DI 43 r14 [471])
(reg:DI 1 dx)) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 1 dx)
(nil)))
(jump_insn/j 2081 1757 2082 246 (set (pc)
(label_ref 1284)) 683 {jump}
(nil)
...
(code_label 1284 2082 1285 247 1737 (nil) [1 uses])
(note 1285 1284 1286 247 [bb 247] NOTE_INSN_BASIC_BLOCK)
(insn 1286 1285 1287 247 (set (reg:DI 4 si)
(const_int 48 [0x30])) "pr86108.C":1553 85 {*movdi_internal}
(nil))
(insn 1287 1286 1288 247 (set (reg:DI 5 di)
(reg/f:DI 3 bx [orig:94 rLoad ] [94])) "pr86108.C":1553 85
{*movdi_internal}
(expr_list:REG_DEAD (reg/f:DI 3 bx [orig:94 rLoad ] [94])
(nil)))
(call_insn 1288 1287 1289 247 (call (mem:QI (symbol_ref:DI ("_ZdlPvm") [flags
0x41] ) [0 operator de
(const_int 0 [0])) "pr86108.C":1553 689 {*call}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:DI 4 si)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("_ZdlPvm") [flags 0x41]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)
(expr_list:DI (use (reg:DI 5 di))
(expr_list:DI (use (reg:DI 4 si))
(nil
(insn 1289 1288 1290 247 (set (reg:DI 0 ax [468])
(reg:DI 41 r12 [469])) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 41 r12 [469])
(nil)))
(insn 1290 1289 2241 247 (set (reg:DI 1 dx [470])
(reg:DI 43 r14 [471])) 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 43 r14 [471])
(nil)))
(jump_insn 2241 1290 2242 247 (set (pc)
(label_ref 1443)) 683 {jump}
(nil)
-> 1443)
But *.jump2 breaks it by throwing away the saving/restoring of rax/rdx to/from
r12/r14, apparently during RTL fast DCE during that pass.
[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108 --- Comment #4 from Jakub Jelinek --- Looking at csa dump in more detail, from the block with abnormal predecessor we have a long series of quite short bbs ending with unconditional jumps, often containing some call. The bb with abnormal predecessor gets the two EH regs in ax/dx and copies them over to r12/r14. The next bb copies those back into ax/dx. Next bb copies those to r14/bx. Next 6 do useless ax=r14;r14=ax, then next bb does di=r14 and finally there is a bb that compares bx and conditionally calls _Unwind_Resume with the di argument. DF info looks ok to me in this dump. This chain of copying around the EH values is what the fast RTL DCE during jump2 breaks.
[Bug bootstrap/86162] [6 Regression] ppc64le bootstrap fails with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86162 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|unknown |6.4.1 Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Fixed.
