[Bug tree-optimization/83517] Missed optimization in math expression: (x+x)/x == 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83517 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Jan 8 08:16:19 2018 New Revision: 256328 URL: https://gcc.gnu.org/viewcvs?rev=256328&root=gcc&view=rev Log: 2018-01-08 Richard Biener PR middle-end/83517 * match.pd ((t * 2) / 2) -> t): Add missing :c. * gcc.dg/pr83517.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr83517.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug c++/83667] ICE in dump_function_decl on a thunk with variadic arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83667 --- Comment #4 from Martin Liška --- Thanks Nathan. Are you planning to backport that?
[Bug tree-optimization/83517] Missed optimization in math expression: (x+x)/x == 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83517 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|tree-ssa|8.0 Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/83580] [6/7 Regression] Wrong code caused by vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83580 --- Comment #10 from Richard Biener --- Author: rguenth Date: Mon Jan 8 08:24:51 2018 New Revision: 256329 URL: https://gcc.gnu.org/viewcvs?rev=256329&root=gcc&view=rev Log: 2018-01-08 Richard Biener PR middle-end/83580 * tree-data-ref.c (split_constant_offset): Remove STRIP_NOPS. * gcc.dg/torture/pr83580.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr83580.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c
[Bug tree-optimization/83580] [6/7 Regression] Wrong code caused by vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83580 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Known to work||8.0 Summary|[6/7/8 Regression] Wrong|[6/7 Regression] Wrong code |code caused by |caused by vectorization |vectorization | Known to fail|8.0 | --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #14 from Arseny Solokha ---
I believe the fix leads to the following ICE on trunk:
% gcc-8.0.0-alpha20180107 -O1 -fno-tree-ccp -Wmaybe-uninitialized -w -c
odqkzc8z.c
during GIMPLE pass: uninit
odqkzc8z.c: In function 'pc':
odqkzc8z.c:4:1: internal compiler error: Segmentation fault
pc (int *tt)
^~
0xd4e2cf crash_signal
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/toplev.c:325
0x722c54 gimple_code
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/gimple.h:1677
0x722c54 is_gimple_call
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/gimple.h:2788
0x722c54 convert_control_dep_chain_into_preds
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:676
0xefa535 convert_control_dep_chain_into_preds
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:648
0xefa535 find_def_preds
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:909
0xefa535 is_use_properly_guarded
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:2472
0xefae46 find_uninit_use
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:2531
0xefae46 warn_uninitialized_phi
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:2600
0xefae46 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180107/work/gcc-8-20180107/gcc/tree-ssa-uninit.c:2709
int oo;
void
pc (int *tt)
{
int cf = 0;
if (*tt != 0)
{
if (0)
{
int *qg;
int uj = 0;
t6:
tt = &cf;
if (oo != 0)
{
++uj;
*qg = !!oo && !!uj;
}
}
cf = 0;
goto t6;
}
if (oo != 0)
{
*tt = 1;
goto t6;
}
}
(as of r256324).
[Bug middle-end/82177] Alias analysis too aggressive with integer-to-pointer cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82177 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Richard Biener --- Let's mark it as duplicate. *** This bug has been marked as a duplicate of bug 65752 ***
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #56 from Richard Biener ---
Testcase from PR82177:
#include
#include
void f(int*, int*);
int main()
{
int a=0, y[1], x = 0;
uintptr_t pi = (uintptr_t) &x;
uintptr_t yi = (uintptr_t) (y+1);
uintptr_t n = pi != yi;
if (n) {
a = 100;
pi = yi;
}
if (n) {
a = 100;
pi = (uintptr_t) y;
}
*(int *)pi = 15;
printf("a=%d x=%d\n", a, x);
f(&x,y);
return 0;
}
[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82282 Bug 82282 depends on bug 82177, which changed state. Bug 82177 Summary: Alias analysis too aggressive with integer-to-pointer cast https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82177 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 Richard Biener changed: What|Removed |Added CC||nunoplopes at sapo dot pt --- Comment #55 from Richard Biener --- *** Bug 82177 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
--- Comment #3 from Richard Biener ---
Yes, it's not really sth new but a known issue with late value-numbering. Note
that FRE wouldn't know how to simplify this either, we'd need store-merging
to effectively vectorize the earlier sets. BB vectorization doesn't do this
because after unrolling we see
vect_cst__46 = { 5, 4, 3, 2 };
MEM[(int *)&arr] = vect_cst__46;
arr[4] = 1;
t_2 = arr[0];
arr[0] = 5;
arr[0] = t_2;
t_32 = arr[0];
_65 = arr[1];
arr[0] = _65;
arr[1] = t_32;
t_68 = arr[0];
_69 = arr[2];
arr[0] = _69;
arr[2] = t_68;
t_72 = arr[0];
_73 = arr[3];
arr[0] = _73;
arr[3] = t_72;
t_76 = arr[0];
_77 = arr[4];
arr[0] = _77;
arr[4] = t_76;
i_80 = 1;
ivtmp_81 = 4;
pretmp_82 = arr[0];
t_87 = arr[i_80];
arr[i_80] = pretmp_82;
...
and BB vectorization is confused by the dead stores (and DSE would be
by the missed constant propagations).
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 Richard Biener changed: What|Removed |Added Blocks||83665 --- Comment #21 from Richard Biener --- https://gcc.opensuse.org/gcc-old/c++bench-czerny/c-ray/ indeed shows it's fixed on trunk, likely by 2018-01-02 Richard Biener * ipa-inline.c (big_speedup_p): Fix expression. so let's watch if it regresses again if the fallout for this change is fixed... (PR83665). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 [Bug 83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018
[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #15 from Jakub Jelinek ---
The problem is in the:
@@ -671,11 +669,9 @@
e = one_cd_chain[j];
guard_bb = e->src;
gsi = gsi_last_bb (guard_bb);
- if (gsi_end_p (gsi))
- {
- has_valid_pred = false;
- break;
- }
+ /* Ignore empty BBs as they're basically forwarder blocks. */
+ if (empty_block_p (guard_bb) && single_succ_p (guard_bb))
+ continue;
cond_stmt = gsi_stmt (gsi);
if (is_gimple_call (cond_stmt) && EDGE_COUNT (e->src->succs) >= 2)
/* Ignore EH edge. Can add assertion on the other edge's flag. */
hunk. When guard_bb is a bb that contains one or more PHIs, but no other
statements, then gsi_stmt (gsi) returns NULL and is_gimple_call will ICE on it.
So, something like:
--- gcc/tree-ssa-uninit.c.jj2018-01-07 20:28:14.894731685 +0100
+++ gcc/tree-ssa-uninit.c 2018-01-08 09:48:11.327325457 +0100
@@ -672,6 +672,11 @@ convert_control_dep_chain_into_preds (ve
/* Ignore empty BBs as they're basically forwarder blocks. */
if (empty_block_p (guard_bb) && single_succ_p (guard_bb))
continue;
+ if (gsi_end_p (gsi))
+ {
+ has_valid_pred = false;
+ break;
+ }
cond_stmt = gsi_stmt (gsi);
if (is_gimple_call (cond_stmt) && EDGE_COUNT (e->src->succs) >= 2)
/* Ignore EH edge. Can add assertion on the other edge's flag. */
ought to fix it. Also note that for -fcompare-debug, the guard_bb could
contain just one or more PHIs and one or more debug stmts and nothing else, in
that case gsi_last_bb returns an iterator with the debug stmt, so cond_stmt
will be a DEBUG_STMT etc. in current code and will do has_valid_pred = false;
break;
PHIs have non-trivial effect though, so not really sure we can ignore them, but
I could be wrong. If we ignore them, we'd need to use gsi_last_nondebug_bb
though.
[Bug ipa/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706 Andrey Guskov changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #2 from Andrey Guskov --- Confirmed on Haswell and Silvermont X86-64.
[Bug c++/83713] [6/7/8 Regression] ICE in do_narrow at gcc/convert.c:474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83713 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2018-01-06 00:00:00 |2018-01-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.5 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug target/83681] epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681 --- Comment #2 from sh at gcc dot gnu.org --- Author: sh Date: Mon Jan 8 09:17:20 2018 New Revision: 256331 URL: https://gcc.gnu.org/viewcvs?rev=256331&root=gcc&view=rev Log: epiphany: Enable Ada run-time build gcc/ PR target/83681 * config/epiphany/epiphany.h (make_pass_mode_switch_use): Guard by not USED_FOR_TARGET. (make_pass_resolve_sw_modes): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/epiphany/epiphany.h
[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #16 from Arnd Bergmann ---
Created attachment 43056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43056&action=edit
linux/net/ipv6/route.c, preprocessed and compressed
To test the patch, I reverted the workaround that was added to the kernel when
I originally reported this. Unfortunately the warning is still there, only the
reduced version is fixed. I attached the preprocessed source now, test with
$ x86_64-linux-gcc-8.0.0 -fno-strict-aliasing -Wall -O2 -Wno-pointer-sign -c
route-1.i
/git/arm-soc/net/ipv6/route.c: In function 'inet6_rtm_getroute':
/git/arm-soc/net/ipv6/route.c:4350:9: warning: 'dst' may be used uninitialized
in this function [-Wmaybe-uninitialized]
goto errout;
^~
}
Reducing this with the latest gcc-8.0.0 snapshot gave me
enum { true } fn1();
int inet6_rtm_getroute_iif, inet6_rtm_getroute_rt, inet6_rtm_getroute_rtm_0;
int *inet6_rtm_getroute___trans_tmp_8;
int fn2();
void fn3() {
int *dst;
_Bool fibmatch = inet6_rtm_getroute_rtm_0 & 2;
if (inet6_rtm_getroute_iif) {
if (!fibmatch)
dst = inet6_rtm_getroute___trans_tmp_8;
static _Bool __warned;
fn2() && __warned &&fn1();
__warned = true;
} else if (!fibmatch)
dst = 0;
if (fibmatch)
dst = 0;
inet6_rtm_getroute_rt = *dst;
}
[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #30 from Eric Botcazou --- As pointed out by Segher in comment #14, the problem ultimately comes from the ambiguity of WORD_REGISTER_OPERATIONS. Quoting him: "WORD_REGISTER_OPERATIONS isn't well-defined. """ @defmac WORD_REGISTER_OPERATIONS Define this macro to 1 if operations between registers with integral mode smaller than a word are always performed on the entire register. Most RISC machines have this property and most CISC machines do not. """ What operations? For some operations it can never be true (rotates, shifts, all slightly more complex operations). For machines that have explicit operations in more than one size it cannot be true, either." I'm leaving out the second case (explicit operations in more than one size) and discussing the first case. It turns out that, in SPARC-V9 (64-bit architecture), the 3 32-bit shift operations (sll, srl, sra) do operate on the entire 64-bit registers with the expected semantics (e.g. srl clears the upper 32 bits and sra fills them with a copy of the sign bit of the lower part) so, on SPARC, you can apply WORD_REGISTER_OPERATIONS to shifts (there is no rotate instruction). So it appears that we have 2 classes of RISC machines, the ones supporting a strong version of WORD_REGISTER_OPERATIONS and the others only a weak one.
[Bug target/83681] epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681 Sebastian Huber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sebastian Huber --- Patch committed.
[Bug tree-optimization/83733] New: -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733
Bug ID: 83733
Summary: -Wformat-overflow false positive for %d on bounded
integer when inlining
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.vanholder at anubex dot com
Target Milestone: ---
Given code similar to
struct foo {
char buf[9];
};
void fun(struct foo* pfoo, int report) {
if (report < 0 || report >= 32)
return;
...
sprintf (pfoo->buf, "CMPRT%02d", report);
}
There is no diagnostic when compiling without inlining active (which is
correct, given that report is constrained to [0,31], which does not overflow
%02d).
However, with optimizations enabled, I get errors like the following reported
for some (but not all) of fun()'s callers:
src.c: In function ‘caller_of_fun()’:
src.c:123:45: error: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Werror=format-overflow=]
sprintf (pfoo->buf, "CMPRT%02d", report);
^~~~
src.c:123:45: note: directive argument in the range [-32768, 32767]
sprintf (pfoo->buf, "CMPRT%02d", report);
^~~
src.c:123:45: note: ‘sprintf’ output between 8 and 12 bytes into a destination
of size 9
sprintf (pfoo->buf, "CMPRT%02d", report);
^~~~
[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #17 from Arnd Bergmann ---
Created attachment 43057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43057&action=edit
linux/drivers/scsi/lpfc/lpfc_bsg.c, preprocessed and compressed
A possibly related warning I just saw this week, with and without the gcc
patch, and back to gcc-4.5+:
x86_64-linux-gcc-8.0.0 -fno-strict-aliasing -Wall -O2 -Wno-pointer-sign -m32 -c
-xc lpfc_bsg.i
/git/arm-soc/drivers/scsi/lpfc/lpfc_bsg.c: In function
'lpfc_bsg_rport_els_cmp':
/git/arm-soc/drivers/scsi/lpfc/lpfc_bsg.c:632:22: warning: 'bsg_reply' may be
used uninitialized in this function [-Wmaybe-uninitialized]
reduced to
8<
long current_stack_pointer, lpfc_bsg_rport_els_cmp_rsp_0;
long pv_irq_ops_1_0, pv_irq_ops_0_0;
struct bsg_job {
void *reply;
};
struct fc_bsg_reply {
int reply_payload_rcv_len;
struct bsg_job set_job;
} * lpfc_bsg_rport_els_cmp_dd_data;
static void check(long v)
{
if (v) {
asm("");
__builtin_unreachable();
}
}
void lpfc_bsg_rport_els_cmp(void) {
struct bsg_job *job;
struct fc_bsg_reply *bsg_reply;
job = &lpfc_bsg_rport_els_cmp_dd_data->set_job;
if (job)
bsg_reply = job->reply;
check(pv_irq_ops_0_0);
check(pv_irq_ops_1_0);
asm("" : "+r"(current_stack_pointer));
check(pv_irq_ops_0_0);
check(pv_irq_ops_1_0);
if (job) {
if (lpfc_bsg_rport_els_cmp_rsp_0 == 0)
bsg_reply->reply_payload_rcv_len = 0;
else if (lpfc_bsg_rport_els_cmp_rsp_0 == 1)
bsg_reply->reply_payload_rcv_len = 0;
}
}
>8
This looked similar to the originally reported symptom in the source code. The
reduced version looks quite a bit different, so no idea if this is something
else entirely or not.
[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
--- Comment #4 from Jakub Jelinek ---
Before store-merging we have:
MEM[(int *)&arr] = { 5, 4, 3, 2 };
t_2 = arr[0];
_65 = arr[1];
_69 = arr[2];
_73 = arr[3];
arr[0] = _69;
arr[1] = _73;
arr[2] = 1;
arr[3] = t_2;
vect__2.5_38 = MEM[(int *)&arr];
and all store-merging can do with this is what it does:
MEM[(int *)&arr] = { 5, 4, 3, 2 };
t_2 = arr[0];
_65 = arr[1];
_69 = arr[2];
_73 = arr[3];
_46 = MEM[(int *)&arr + 8B];
MEM[(int *)&arr] = _46;
arr[2] = 1;
arr[3] = t_2;
vect__2.5_38 = MEM[(int *)&arr];
where the _69 and _73 sets can be DCEd later. store-merging has no framework
like FRE to do analysis what memory location contains at which point.
So we'd need another late FRE pass to handle this?
[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
--- Comment #5 from rguenther at suse dot de ---
On Mon, 8 Jan 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
>
> --- Comment #4 from Jakub Jelinek ---
> Before store-merging we have:
> MEM[(int *)&arr] = { 5, 4, 3, 2 };
> t_2 = arr[0];
> _65 = arr[1];
> _69 = arr[2];
> _73 = arr[3];
> arr[0] = _69;
> arr[1] = _73;
> arr[2] = 1;
> arr[3] = t_2;
> vect__2.5_38 = MEM[(int *)&arr];
> and all store-merging can do with this is what it does:
> MEM[(int *)&arr] = { 5, 4, 3, 2 };
> t_2 = arr[0];
> _65 = arr[1];
> _69 = arr[2];
> _73 = arr[3];
> _46 = MEM[(int *)&arr + 8B];
> MEM[(int *)&arr] = _46;
> arr[2] = 1;
> arr[3] = t_2;
> vect__2.5_38 = MEM[(int *)&arr];
> where the _69 and _73 sets can be DCEd later. store-merging has no framework
> like FRE to do analysis what memory location contains at which point.
> So we'd need another late FRE pass to handle this?
Without enhancing FRE that wouldn't help. I think the best thing is
to try sanitizing the IL produced by unrolling so SLP vectorization
can do its job here.
Nothing for GCC 8 though.
[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||jakub at gcc dot gnu.org, ||wilco at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r254388.
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug testsuite/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706 Richard Biener changed: What|Removed |Added Component|ipa |testsuite --- Comment #3 from Richard Biener --- Probably a testsuite issue but annoying. Honza?
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #10 from Christophe Lyon --- (In reply to Jonathan Wakely from comment #6) > Author: redi > Date: Fri Jan 5 21:27:25 2018 > New Revision: 256287 > > URL: https://gcc.gnu.org/viewcvs?rev=256287&root=gcc&view=rev > Log: > PR libstdc++/83626 Don't report errors when removing non-existent files > > Backport from mainline > 2018-01-05 Jonathan Wakely > > PR libstdc++/83626 > * src/filesystem/ops.cc (remove(const path&, error_code&)): Do not > report an error for ENOENT. > (remove_all(const path&)): Fix type of result variable. > (remove_all(const path&, error_code&)): Use non-throwing increment > for directory iterator. Call POSIX remove directly to avoid redundant > calls to symlink_status. Do not report errors for ENOENT. > * testsuite/experimental/filesystem/operations/remove_all.cc: Test > throwing overload. > > Backport from mainline > 2018-01-04 Jonathan Wakely > > PR libstdc++/83626 > * src/filesystem/ops.cc (remove(const path&, error_code&))): Remove > redundant call to ec.clear(). > (remove_all(const path&, error_code&))): Do not return an error for > non-existent paths. > * testsuite/experimental/filesystem/operations/remove.cc: New test. > * testsuite/experimental/filesystem/operations/remove_all.cc: Fix > expected results for non-existent paths. > > Added: > > branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/ > operations/remove.cc > - copied, changed from r256286, > branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/ > operations/remove_all.cc > Modified: > branches/gcc-7-branch/libstdc++-v3/ChangeLog > branches/gcc-7-branch/libstdc++-v3/src/filesystem/ops.cc > > branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/ > operations/remove_all.cc In my testing, I have a new failure: FAIL:: experimental/filesystem/operations/remove.cc execution test on aarch64-linux-gnu and arm*linux* targets. I'm cross-testing using proot+qemu, so maybe there is a bad interaction. The log says: /libstdc++-v3/testsuite/experimental/filesystem/operations/remove.cc:81: void test01(): Assertion 'ec' failed. I don't have the results for trunk yet.
[Bug c++/83714] [8 Regression] ICE in build_address, at cp/typeck.c:5733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83714 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug tree-optimization/83715] Missed optimization in math expression: optimize double comparing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83715 --- Comment #2 from Richard Biener --- In theory DOM propagtes equivalences but appearantly not in this case.
[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |8.0
[Bug c++/83716] tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83716 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-08 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I get /home/uruwi/vane/discordpp/lib/nlohmannjson/nlohmann/json.hpp:870:45: error: static assertion failed: could not find from_json() method in T's namespace and the ICE doesn't reproduce for me (I am on r256329). So can you update and re-check?
[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Wonder if this isn't a LRA bug though, the insn in question is:
(define_insn "*movti_aarch64"
[(set (match_operand:TI 0
"nonimmediate_operand" "=r, w,r,w,r,m,m,w,m")
(match_operand:TI 1
"aarch64_movti_operand" " rn,r,w,w,m,r,Z,m,w"))]
"(register_operand (operands[0], TImode)
|| aarch64_reg_or_zero (operands[1], TImode))"
and aarch64_movti_operand doesn't allow CONST_WIDE_INT:
(define_predicate "aarch64_movti_operand"
(and (match_code "reg,subreg,mem,const_int")
(ior (match_operand 0 "register_operand")
(ior (match_operand 0 "memory_operand")
(match_operand 0 "const_int_operand")
and the legitimate_constant_p target hook doesn't allow that either, yet
simplify_operand_subreg will do
else if (CONSTANT_P (reg))
{
/* Try to simplify subreg of constant. It is usually result of
equivalence substitution. */
if (innermode == VOIDmode
&& (innermode = original_subreg_reg_mode[nop]) == VOIDmode)
innermode = curr_static_id->operand[nop].mode;
if ((new_reg = simplify_subreg (mode, reg, innermode,
SUBREG_BYTE (operand))) != NULL_RTX)
{
*curr_id->operand_loc[nop] = new_reg;
return true;
}
}
and nothing calls the predicate nor the legitimate_constant_p target hook for
it.
Is that because LRA operates only on constraints, not predicates, and seeing
"n" defined as:
(define_constraint "n"
"Matches a non-symbolic integer constant."
(and (match_test "CONST_SCALAR_INT_P (op)")
(match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))
doesn't indeed require anything?
If so, shouldn't *movti_aarch64 use a different constraint, that either
requires arbitrary "const_int", so just
(define_constraint "whatever"
"..."
(match_code "const_int"))
or requires a scalar int that satisfies target_legitimate_constant_p?
[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #31 from Eric Botcazou --- > So it appears that we have 2 classes of RISC machines, the ones supporting a > strong version of WORD_REGISTER_OPERATIONS and the others only a weak one. However I'm not sure whether exposing the distinction is really the way to go so I'm going to evaluate the pessimization that would be introduced on SPARC 64-bit by disregarding WORD_REGISTER_OPERATIONS for shift operations.
[Bug rtl-optimization/83723] [8 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2018-01-08
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Can't reproduce, neither with r256283 trunk i686-linux host/target, nor in
bisection seed (x86_64-linux) with additional -m32 and
-march={i386,i486,i586,i686}, both in r256268, r256273 nor r256321.
[Bug fortran/83731] PDT length parameter incorrectly rejected at run-time with -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas ---
total (struct Pdtvec & restrict a)
{
integer(kind=4) __result_total;
if (a->k != 10)
{
_gfortran_runtime_error_at (&"In file \'../pr83731/pr83731.f90\', around
line 15"[1]{lb: 1 sz: 1}, &"The value of the PDT LEN parameter \'%s\' does not
agree with that in the dummy declaration"[1]{lb: 1 sz: 1}, &"k"[1]{lb: 1 sz:
1});
}
.
Bother! It's comparing k with the default initializer.
I have taken it and will look at this once I have committed the fix for
PR83611.
Thanks for the report.
Paul
[Bug c++/83734] New: ice in cxx_eval _statement_list, at cp/constexpr.c:3869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83734 Bug ID: 83734 Summary: ice in cxx_eval _statement_list, at cp/constexpr.c:3869 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For the file gcc/testsuite/g++.dg/cpp0x/constexpr-type-decl1.C, when compiled by flags -g -O2, does this: ./g++.dg/cpp0x/constexpr-type-decl1.C:53:4: in ‘constexpr’ expansion of ‘s1.S1 ::S1()’ ./g++.dg/cpp0x/constexpr-type-decl1.C:53:4: internal compiler error: in cxx_eval _statement_list, at cp/constexpr.c:3869 S1 s1; ^~ 0x5a9dd2 cxx_eval_statement_list ../../trunk/gcc/cp/constexpr.c:3869 0x5a9dd2 cxx_eval_constant_expression ../../trunk/gcc/cp/constexpr.c:4598 0x949ca0 cxx_eval_constant_expression ../../trunk/gcc/cp/constexpr.c:4602 This bug seems to have been introduced between revision 255605 and 255660.
[Bug c++/81420] When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81420 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 Ever confirmed|0 |1
[Bug ipa/65654] [8 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jan Hubicka --- The inliner implementation has sufficiently changed so this sanity check makes no longer sense, thus closing this big as fixed :)
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #27 from Jan Hubicka --- I would still suggest here going with Martin's patch: it is incorrect to attempt to change the partition after BB order has been fixed. We can incrementally deal with the missed optimization in this quite rare scenario that code duplication makes it possible to transfer BB from hot to cold partition. Given it happens only sometimes during full bootstrap, I am not sure it is worth the effort.
[Bug testsuite/67905] running the libstdc++ testsuite as root removed /dev/null from my system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67905 --- Comment #4 from Jonathan Wakely --- I don't see anything in the libstdc++ testsuite that would remove it anyway, so I'm going to blame DejaGnu or OS X.
[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 Martin Liška changed: What|Removed |Added Target|i686-linux-gnu |i686-linux-gnu, ||x86_64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with Richi's r251220. One can reproduce it on x86_64 with empty file and: $ ./xg++ -B. pr83719.ii -c -std=c++11 -c -gsplit-dwarf -g -flto $ (gdb) p skeleton_debug_str_hash $2 = (hash_table *) 0x0 (gdb) bt #0 0x00a630e2 in hash_table::elements (this=0x0) at ../../gcc/hash-table.h:388 #1 0x00a5a511 in hash_table::traverse (this=0x0, argument=DW_FORM_strp) at ../../gcc/hash-table.h:987 #2 0x00a4790d in output_indirect_strings () at ../../gcc/dwarf2out.c:27799 #3 0x00a4e580 in dwarf2out_early_finish (filename=0x2481a50 "/home/marxin/Programming/testcases/pr83719.ii") at ../../gcc/dwarf2out.c:30894 #4 0x009b31f9 in symbol_table::finalize_compilation_unit (this=0x76817100) at ../../gcc/cgraphunit.c:2713 #5 0x00df359b in compile_file () at ../../gcc/toplev.c:480 #6 0x00625c25 in do_compile () at ../../gcc/toplev.c:2081 #7 toplev::main (this=this@entry=0x7fffd93e, argc=, argc@entry=16, argv=, argv@entry=0x7fffda38) at ../../gcc/toplev.c:2216 #8 0x0062806b in main (argc=16, argv=0x7fffda38) at ../../gcc/main.c:39
[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0
[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 Richard Biener changed: What|Removed |Added Target|i686-linux-gnu, |i686-linux-gnu |x86_64-linux-gnu| Status|NEW |ASSIGNED Last reconfirmed|2018-01-08 00:00:00 | Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Confirmed. It did work at one point but we have zero testing coverage for -gsplit-dwarf (even w/o LTO). The issue is we fail to index strings for early output plus we don't handle an empty skeleton_debug_str_hash (debg_str_hash is never empty). Mine.
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Target|avr |
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-08
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely ---
This happens on all targets, but only for a C++17 inline static member
variable.
There's no guard variable for the C++14 equivalent:
struct A {
A() = default;
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
static T mTop;
};
template T B::mTop{};
int main() {
B::foo();
}
[Bug middle-end/83721] [8 Regression] ICE: in generic_overlap, at gimple-ssa-warn-restrict.c:821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83721 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug lto/83720] [8 Regression] ICE: in mangle_decl, at cp/mangle.c:3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83720 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug preprocessor/83722] [8 Regression] the ICE dumper doesn't comment-out some error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug rtl-optimization/83723] [8 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83728 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/83714] [8 Regression] ICE in build_address, at cp/typeck.c:5733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83714 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Can't reproduce that bisection, this doesn't ICE even in 7.x, my bisection points to r253599 instead.
[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-08 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please attach a testcase that can be compiled that shows the warning.
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #11 from Jonathan Wakely --- (In reply to Christophe Lyon from comment #10) > In my testing, I have a new failure: > FAIL:: experimental/filesystem/operations/remove.cc execution test > on aarch64-linux-gnu and arm*linux* targets. > > I'm cross-testing using proot+qemu, so maybe there is a bad interaction. > > The log says: > /libstdc++-v3/testsuite/experimental/filesystem/operations/remove.cc:81: > void test01(): Assertion 'ec' failed. This means that remove(3) can remove a directory below a directory with mode 000. I'll adjust the test to account for such cases.
[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r254919.
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The warning might be using the old C++98 definition of POD.
[Bug c++/83734] [8 Regression] ice in cxx_eval _statement_list, at cp/constexpr.c:3869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83734 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0 Summary|ice in cxx_eval |[8 Regression] ice in |_statement_list, at |cxx_eval _statement_list, |cp/constexpr.c:3869 |at cp/constexpr.c:3869
[Bug fortran/83731] PDT length parameter incorrectly rejected at run-time with -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731 --- Comment #3 from Paul Thomas --- Hi Berke, The fix for this turns out to be so trivial that I will roll it in to the patch for pr83611. I know that this must be frustrating but please keep trying out PDTs. The bug reports that you are generating are invaluable at this stage. Thanks Paul
[Bug target/83735] New: [8 Regression] generating unaligned store to stack with vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735 Bug ID: 83735 Summary: [8 Regression] generating unaligned store to stack with vmovaps Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 43058 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43058&action=edit reduced testcase Similar to PR78585 and PR83330, but this one is for different target and needs a very small set of flags to reproduce. This particular testcase does not fail in gcc-7, but it might be just a luck. Output: $ x86_64-pc-linux-gnu-gcc -O3 -mavx512bw testcase.c $ ./a.out Segmentation fault The failing instruction is: 0x004003c4 <+52>:vmovdqu 0x200cb4(%rip),%xmm1# 0x601080 0x004003cc <+60>:vmovdqa 0x4ec(%rip),%ymm0# 0x4008c0 => 0x004003d4 <+68>:vmovaps %xmm1,-0x30(%rsp) 0x004003da <+74>:vmovdqu 0x200cae(%rip),%xmm1# 0x601090 0x004003e2 <+82>:mov0x200cb7(%rip),%rax# 0x6010a0 (gdb) p $rsp $1 = (void *) 0x7fffd678 rsp-0x30 is not correctly aligned. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-256323-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-256323-checking-yes-rtl-df-extra-nographite-amd64 Thread model: posix gcc version 8.0.0 20180107 (experimental) (GCC)
[Bug fortran/83731] PDT length parameter incorrectly rejected at run-time with -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731 --- Comment #4 from Paul Thomas --- Author: pault Date: Mon Jan 8 11:20:33 2018 New Revision: 256335 URL: https://gcc.gnu.org/viewcvs?rev=256335&root=gcc&view=rev Log: 2018-01-08 Paul Thomas PR fortran/83611 * decl.c (gfc_get_pdt_instance): If parameterized arrays have an initializer, convert the kind parameters and add to the component if the instance. * trans-array.c (structure_alloc_comps): Add 'is_pdt_type' and use it with case COPY_ALLOC_COMP. Call 'duplicate_allocatable' for parameterized arrays. Clean up typos in comments. Convert parameterized array initializers and copy into the array. * trans-expr.c (gfc_trans_scalar_assign): Do a deep copy for parameterized types. *trans-stmt.c (trans_associate_var): Deallocate associate vars as necessary, when they are PDT function results for example. PR fortran/83731 * trans-array.c (structure_alloc_comps): Only compare len parms when they are declared explicitly. 2018-01-08 Paul Thomas PR fortran/83611 * gfortran.dg/pdt_15.f03 : Bump count of 'n.data = 0B' to 8. * gfortran.dg/pdt_26.f03 : Bump count of '_malloc' to 9. * gfortran.dg/pdt_27.f03 : New test. PR fortran/83731 * gfortran.dg/pdt_28.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pdt_27.f03 trunk/gcc/testsuite/gfortran.dg/pdt_28.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_15.f03 trunk/gcc/testsuite/gfortran.dg/pdt_26.f03
[Bug fortran/83611] [PDT] Assignment of parameterized types causes double free error in runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83611 --- Comment #2 from Paul Thomas --- Author: pault Date: Mon Jan 8 11:20:33 2018 New Revision: 256335 URL: https://gcc.gnu.org/viewcvs?rev=256335&root=gcc&view=rev Log: 2018-01-08 Paul Thomas PR fortran/83611 * decl.c (gfc_get_pdt_instance): If parameterized arrays have an initializer, convert the kind parameters and add to the component if the instance. * trans-array.c (structure_alloc_comps): Add 'is_pdt_type' and use it with case COPY_ALLOC_COMP. Call 'duplicate_allocatable' for parameterized arrays. Clean up typos in comments. Convert parameterized array initializers and copy into the array. * trans-expr.c (gfc_trans_scalar_assign): Do a deep copy for parameterized types. *trans-stmt.c (trans_associate_var): Deallocate associate vars as necessary, when they are PDT function results for example. PR fortran/83731 * trans-array.c (structure_alloc_comps): Only compare len parms when they are declared explicitly. 2018-01-08 Paul Thomas PR fortran/83611 * gfortran.dg/pdt_15.f03 : Bump count of 'n.data = 0B' to 8. * gfortran.dg/pdt_26.f03 : Bump count of '_malloc' to 9. * gfortran.dg/pdt_27.f03 : New test. PR fortran/83731 * gfortran.dg/pdt_28.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pdt_27.f03 trunk/gcc/testsuite/gfortran.dg/pdt_28.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_15.f03 trunk/gcc/testsuite/gfortran.dg/pdt_26.f03
[Bug fortran/83731] PDT length parameter incorrectly rejected at run-time with -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed - thanks for the report. Paul
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 83731, which changed state. Bug 83731 Summary: PDT length parameter incorrectly rejected at run-time with -fcheck=bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83731 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 83611, which changed state. Bug 83611 Summary: [PDT] Assignment of parameterized types causes double free error in runtime https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83611 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/83611] [PDT] Assignment of parameterized types causes double free error in runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83611 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Paul Thomas --- Fixed.
[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83126 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83065 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- This must be with -flto at least too.
[Bug c/83736] New: ICE triggered by improper use of VLA and scanf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83736
Bug ID: 83736
Summary: ICE triggered by improper use of VLA and scanf
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: czirkos.zoltan at gmail dot com
Target Milestone: ---
Created attachment 43059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43059&action=edit
Compiler output
The following code causes an internal compiler error and segmentation fault in
the compiler:
#include
int main(void){
int n = 0;
char temp[n + 1];
scanf("%s", &temp);
}
Of course the code is invalid (the address-of operator is not needed), but it
should not cause an ICE.
Attached compiler output.
Version is "gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
(Ubuntu 7-20170407-0ubuntu2)".
Command line is "gcc test.c".
The compiler also crashes if the call is not scanf but printf. And it also
crashes when all warnings are turned off (gcc -w).
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
Wilhelm M changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #4 from Wilhelm M ---
If you change the example as below, you still get guards.
struct A {
A() = default;
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
static T mTop;
};
template T B::mTop; // change
int main() {
B::foo();
}
[Bug c/83736] ICE triggered by improper use of VLA and scanf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83736 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||7.2.0 Resolution|--- |FIXED --- Comment #1 from Richard Biener --- This was fixed in GCCC 7.2.
[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug preprocessor/83722] [8 Regression] the ICE dumper doesn't comment-out some error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Created attachment 43060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43060&action=edit gcc8-pr83722.patch I don't see why this PR is considered a regression, -freport-bug apparently behaves that way since 5 when -freport-bug has been introduced.
[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 Richard Biener changed: What|Removed |Added Target||ia64 Target Milestone|--- |7.3
[Bug target/82975] [6/7 Regression] ICE in baseness at rtlanal.c:6220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82975 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug tree-optimization/83552] [7 Regression] ICE in error: invalid argument to gimple call in during GIMPLE pass: strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83552 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |8.0 Target Milestone|--- |7.3
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
--- Comment #5 from Wilhelm M ---
Only for completeness: if you write the following, no guards are produced:
struct A {
A() = default; // if commented out, no guards are allocated
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
inline static T mTop{};
};
int main() {
B::foo();
}
So the c++14 an c++17 variants produce the same guards if
default-initialization is used. But produce no guards if value-initialization
ist used or the defaulted ctor is removed. Thats strange ...
[Bug c++/83734] [8 Regression] ice in cxx_eval _statement_list, at cp/constexpr.c:3869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83734 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r255569. I'll handle this.
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #24 from Janne Blomqvist --- Author: jb Date: Mon Jan 8 12:12:05 2018 New Revision: 256337 URL: https://gcc.gnu.org/viewcvs?rev=256337&root=gcc&view=rev Log: PR 78534 Regression on 32-bit targets By switching from int to size_t in order to handle larger values, r256322 introduced a bug that manifested itself on 32-bit targets. Fixed by using the correct type to store the result of a next_array_record call. Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu, committed to trunk as obvious. libgfortran/ChangeLog: 2018-01-08 Janne Blomqvist PR 78534, bugfix for r256322 * io/transfer.c (next_record_w): Use correct type for return value of next_array_record. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726 --- Comment #3 from Wilco --- This is related with PR82964/82974, looks like same underlying issue. I have a patch which changes the constraint, and that fixes this issue too. It's not obvious to me whether legitimate_constant_p should be a subset of the constraint or not. For rematerialization to work, it needs to return true for any constants that can be cheaply rematerialized. That includes literal loads, ie. constants that don't match immediate constraints.
[Bug target/83109] [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 --- Comment #1 from igor.v.tsimbalist at intel dot com --- It's fixed in revision r255164, http://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00881.html. The svn log is missing PR 83109 that's why the bug was not updated automatically.
[Bug target/83109] [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 igor.v.tsimbalist at intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from igor.v.tsimbalist at intel dot com --- Mark it as fixed.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 83109, which changed state. Bug 83109 Summary: [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83109 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 --- Comment #2 from Stas Sergeev --- (In reply to Jonathan Wakely from comment #1) > The warning might be using the old C++98 definition of POD. Lets specify -std explicitly then: $ g++ -std=c++11 pod.cpp pod.cpp:11:16: warning: ignoring packed attribute because of unpacked non-POD field 'ttt tst::a' struct ttt a;
[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572 --- Comment #6 from Richard Biener --- The issue here is we have a non SESE-region to start with.
[Bug c++/83734] [8 Regression] ice in cxx_eval _statement_list, at cp/constexpr.c:3869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83734 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 43061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43061&action=edit gcc8-pr83734.patch Untested fix.
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
--- Comment #3 from Jonathan Wakely ---
That doesn't change anything, the default is gnu++14 anyway. My point is not
that the compiler is in C++98 mode, just that the condition for the warning
uses the old definition. The code confirms it:
if (!layout_pod_type_p (type) && !TYPE_PACKED (type))
{
warning_at
(DECL_SOURCE_LOCATION (x), 0,
"ignoring packed attribute because of unpacked non-POD field
%q#D",
x);
cant_pack = 1;
}
layout_pod_type_p checks if the type is a "POD for the purpose of layout" which
is false for this type, even though it's a POD according to C++11 and later.
The definition of "POD for the purpose of layout" is fixed bythe ABI and so
independent of the -std option, because it must be stable across standard
versions.
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 --- Comment #4 from Jonathan Wakely --- I suppose since packed structs violate the ABI anyway, we don't need them to use the ABI-stable definition of POD for the purpose of layout.
[Bug lto/83720] [8 Regression] ICE: in mangle_decl, at cp/mangle.c:3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83720 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r251433.
[Bug c++/83714] [8 Regression] ICE in build_address, at cp/typeck.c:5733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83714 --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Can't reproduce that bisection, this doesn't ICE even in 7.x, my bisection > points to r253599 instead. Yes Jakus, I can confirm it started with the revision you identified.
[Bug c++/83667] ICE in dump_function_decl on a thunk with variadic arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83667 --- Comment #5 from Nathan Sidwell --- No plan. It's a p3 non-regression.
[Bug c++/83714] [8 Regression] ICE in build_address, at cp/typeck.c:5733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83714 --- Comment #3 from Martin Liška --- s/Jakus/Jakub
[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83065 --- Comment #5 from Martin Liška --- (In reply to Jakub Jelinek from comment #4) > This must be with -flto at least too. Even with -flto I can't reproduce. Can you please attach SPEC build log file?
[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Jan 8 13:13:48 2018 New Revision: 256338 URL: https://gcc.gnu.org/viewcvs?rev=256338&root=gcc&view=rev Log: 2018-01-08 Richard Biener PR lto/83719 * dwarf2out.c (output_indirect_strings): Handle empty skeleton_debug_str_hash. (dwarf2out_early_finish): Index strings for -gsplit-dwarf. * gcc.dg/lto/pr83719_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr83719_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733 --- Comment #2 from Tim Van Holder --- Created attachment 43062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43062&action=edit Testcase Testcase attached. Compiling with "gcc -c -Wall -Wextra -Werror -O3 gcc83733.c" yields: gcc83733.c: In function ‘caller1’: gcc83733.c:33:44: error: ‘%02d’ directive writing between 2 and 6 bytes into a region of size 4 [-Werror=format-overflow=] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ gcc83733.c:33:38: note: directive argument in the range [-32768, 32767] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~ gcc83733.c:33:7: note: ‘sprintf’ output between 8 and 12 bytes into a destination of size 9 sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ gcc83733.c: In function ‘caller2’: gcc83733.c:33:44: error: ‘%02d’ directive writing between 2 and 6 bytes into a region of size 4 [-Werror=format-overflow=] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ gcc83733.c:33:38: note: directive argument in the range [-32768, 32767] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~ gcc83733.c:33:7: note: ‘sprintf’ output between 8 and 12 bytes into a destination of size 9 sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ There seem to be several subtleties involved. For example, dropping the 'definition' struct (making 'ddname' a field directly in 'foo_t') changes the diagnostic, claiming there's 11 bytes in the target (slack space in the struct?).
[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-08 CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r250084.
[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735 --- Comment #2 from Jakub Jelinek --- But again succeeds with -mno-stv, so likely dup of PR83330.
[Bug tree-optimization/83685] [8 Regression] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83685 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Jan 8 13:22:56 2018 New Revision: 256339 URL: https://gcc.gnu.org/viewcvs?rev=256339&root=gcc&view=rev Log: 2018-01-08 Richard Biener PR tree-optimization/83685 * tree-ssa-pre.c (create_expression_by_pieces): Do not insert references to abnormals. * gcc.dg/torture/pr83685.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr83685.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/83685] [8 Regression] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83685 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug c++/83713] [6/7/8 Regression] ICE in do_narrow at gcc/convert.c:474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83713 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Jan 8 13:24:38 2018 New Revision: 256341 URL: https://gcc.gnu.org/viewcvs?rev=256341&root=gcc&view=rev Log: 2018-01-08 Richard Biener PR middle-end/83713 * convert.c (do_narrow): Properly guard TYPE_OVERFLOW_WRAPS checks. * g++.dg/torture/pr83713.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr83713.C Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83713] [6/7 Regression] ICE in do_narrow at gcc/convert.c:474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83713 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] ICE in |[6/7 Regression] ICE in |do_narrow at|do_narrow at |gcc/convert.c:474 |gcc/convert.c:474 Known to fail|8.0 | --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
