[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Ivan D Vasin changed: What|Removed |Added CC||nisavid at gmail dot com --- Comment #57 from Ivan D Vasin --- This issue appears to have resurfaced on macOS 10.13 using GCC 4.9.4: https://github.com/rvm/rvm/issues/4200#issuecomment-338546674 I'm uncertain whether the reappearance of this issue is something to be handled in GCC, nor whether commenting on this old report is an appropriate way to (re)open the issue. If nothing else, I'm hoping that this comment finds someone who might provide some helpful insight into the nature of the issue or the fix, so that its reappearance can be fixed as well. If it would be better to open a new report, I'd gladly do so. In any case, please advise.
[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- Comment #6 from Alexander Cherepanov ---
Here are simplified testcases. With a union (C and C++):
--
#include
union u {
long x;
long long y;
};
static long test(long *px, long long *py, union u *pu)
{
pu->x = 0;// make .x active member (for C++)
*px = 0; // access .x via pointer
pu->y = pu->x;// switch active member to .y (for C++)
*py = 1; // access .y via pointer
pu->x = pu->y;// switch active member back to .x
return *px; // access .x via pointer
}
int main(void)
{
union u u;
printf("%ld\n", test(&u.x, &u.y, &u));
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
1
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
0
--
And with allocated memory (C; add placement new's for C++):
--
#include
#include
#include
static long test(long *px, long long *py, void *pu)
{
*px = 0;
*py = 1;
// change effective type from long long to long
long tmp;
memcpy(&tmp, pu, sizeof(tmp));
memcpy(pu, &tmp, sizeof(tmp));
return *px;
}
int main(void)
{
void *p = malloc(10);
printf("%ld\n", test(p, p, p));
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
1
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
0
--
gcc version: gcc (GCC) 8.0.0 20171023 (experimental)
[Bug bootstrap/82670] New: UBSAN bootstrap broken after recent libsanitizer merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82670 Bug ID: 82670 Summary: UBSAN bootstrap broken after recent libsanitizer merge 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 CC: jakub at gcc dot gnu.org Target Milestone: --- Looks they recently added wrappers for signal-related functions: /home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/./gcc/xgcc -B/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/./gcc/ -dumpspecs > tmp-specs /bin/sh: line 1: 7075 Segmentation fault (core dumped) /home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/./gcc/xgcc -B/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-ubsan/build/builddir/./gcc/ -dumpspecs > tmp-specs make[3]: *** [Makefile:2037: specs] Error 139 It fails here: │0x60335b <__interceptor_signal(int, void*)+11> callq 0x605010 <__sanitizer::GetHandleSignalMode(int)> │0x603360 <__interceptor_signal(int, void*)+16> cmp$0x2,%eax │0x603363 <__interceptor_signal(int, void*)+19> je 0x603376 <__interceptor_signal(int, void*)+38> │0x603365 <__interceptor_signal(int, void*)+21> add$0x8,%rsp │0x603369 <__interceptor_signal(int, void*)+25> mov%rbp,%rsi │0x60336c <__interceptor_signal(int, void*)+28> mov%ebx,%edi │0x60336e <__interceptor_signal(int, void*)+30> pop%rbx │0x60336f <__interceptor_signal(int, void*)+31> pop%rbp >│0x603370 <__interceptor_signal(int, void*)+32> jmpq *0x3e9f22(%rip)# 0x9ed298 <_ZN14__interception11real_signalE> It's strange because it should basically jump to _ZN14__interception11real_signalE, but it's somehow zeroed: Program received signal SIGSEGV, Segmentation fault. 0x in ?? ()
[Bug tree-optimization/82669] ICE at -Os on valid code on x86_64-linux-gnu: in bitmap_check_index, at sbitmap.h:105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82669 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-23 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it fails with newly added sanity checks. Let me take it.
[Bug tree-optimization/82666] [7/8 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Created attachment 42437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42437&action=edit Reproducer (micro benchmark) Confirmed, I'm attaching micro-benchmark that I run on my Haswell machine. In time between GCC 6.x and current trunk we first improved performance in r239414 from 1.392704s -> 1.228814s. Then we significantly regressed in r242832 from 1.209454s -> 1.929302s.
[Bug tree-optimization/82666] [7/8 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-23 CC||bernds at gcc dot gnu.org Target Milestone|--- |7.3 Ever confirmed|0 |1
[Bug c++/82664] Internal Compiler Error when using Match7 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82664 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-23 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Yes, please attach *.ii file. I can help with reduction.
[Bug tree-optimization/82671] New: [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82671 Bug ID: 82671 Summary: [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4412 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at ucw dot cz Target Milestone: --- Starting from r253910 we ICE on: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr57676.c -freorder-blocks-and-partition -fmodulo-sched -O1 /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr57676.c: In function ‘f’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr57676.c:8:6: warning: type of ‘p1’ defaults to ‘int’ [-Wimplicit-int] void f(p1) ^ /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr57676.c:12:22: warning: division by zero [-Wdiv-by-zero] if(p1 ? : (c /= 0)) ^~ during RTL pass: sms /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr57676.c:28:1: internal compiler error: in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4412 } ^ 0x7667ce cfg_layout_redirect_edge_and_branch ../../gcc/cfgrtl.c:4412 0x7667f8 cfg_layout_redirect_edge_and_branch_force ../../gcc/cfgrtl.c:4422 0x750673 redirect_edge_and_branch_force(edge_def*, basic_block_def*) ../../gcc/cfghooks.c:477 0x751385 make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void (*)(basic_block_def*)) ../../gcc/cfghooks.c:892 0x75f9d3 create_preheader(loop*, int) ../../gcc/cfgloopmanip.c:1524 0x75fc1e create_preheaders(int) ../../gcc/cfgloopmanip.c:1575 0xa0198e apply_loop_flags ../../gcc/loop-init.c:64 0xa0246c loop_optimizer_init(unsigned int) ../../gcc/loop-init.c:123 0x13c7346 sms_schedule ../../gcc/modulo-sched.c:1351 0x13c9bff execute ../../gcc/modulo-sched.c:3342
[Bug tree-optimization/82672] [8 Regression][GRAPHITE] ICE in verify_gimple_in_cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82672 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/82672] New: [8 Regression][GRAPHITE] ICE in verify_gimple_in_cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82672 Bug ID: 82672 Summary: [8 Regression][GRAPHITE] ICE in verify_gimple_in_cfg Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Starting from r253705 we ICE on: $ gfortran /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90 -O2 -floop-nest-optimize /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:33:0: end Error: invalid address operand in MEM_REF MEM[(character(kind=4) *)&MEM[(void *)&s4 + 28B]]; /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:33:0: Error: invalid first operand of MEM_REF &MEM[(void *)&s4 + 28B] /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:24:0: s4 = 4_"foo bar" note: in statement # .MEM_122 = VDEF <.MEM_71> MEM[(character(kind=4) *)&MEM[(void *)&s4 + 28B]] = 32; /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:33:0: end Error: invalid address operand in MEM_REF MEM[(character(kind=4) *)&MEM[(void *)&s4 + 32B]]; /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:33:0: Error: invalid first operand of MEM_REF &MEM[(void *)&s4 + 32B] /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:26:0: s4 = 4_"\x00\x96" note: in statement # .MEM_131 = VDEF <.MEM_75> MEM[(character(kind=4) *)&MEM[(void *)&s4 + 32B]] = 32; during GIMPLE pass: graphite /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/widechar_1.f90:33:0: end internal compiler error: verify_gimple failed 0xc5db4d verify_gimple_in_cfg(function*, bool) ../../gcc/tree-cfg.c:5395 0xb30036 execute_function_todo ../../gcc/passes.c:1994 0xb310b2 execute_todo ../../gcc/passes.c:2048
[Bug target/82673] New: [8 Regression] ICE in ix86_finalize_stack_frame_flags at gcc/config/i386/i386.c:12695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82673
Bug ID: 82673
Summary: [8 Regression] ICE in ix86_finalize_stack_frame_flags
at gcc/config/i386/i386.c:12695
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: uros at gcc dot gnu.org
Target Milestone: 8.0
Target Milestone: 8.0
Starting from r251075 we ICE one:
$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr9771-1.c
-fvar-tracking-assignments-toggle
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr9771-1.c: In
function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr9771-1.c:17:1:
error: bp cannot be used in asm here
}
^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr9771-1.c:14:6:
error: frame pointer required, but reserved
void bar(void)
^~~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr9771-1.c:9:16:
note: for ‘B’
register long *B asm ("ebp");
^
during RTL pass: pro_and_epilogue
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr9771-1.c:17:1:
internal compiler error: Segmentation fault
}
^
0xba5f2f crash_signal
../../gcc/toplev.c:326
0xf0e580 ix86_finalize_stack_frame_flags
../../gcc/config/i386/i386.c:12695
0xf17524 ix86_expand_prologue()
../../gcc/config/i386/i386.c:12845
0x114d78a gen_prologue()
../../gcc/config/i386/i386.md:13077
0xefca18 target_gen_prologue
../../gcc/config/i386/i386.md:19373
0x8c8da9 make_prologue_seq
../../gcc/function.c:5879
0x8c8f84 thread_prologue_and_epilogue_insns()
../../gcc/function.c:5996
0x8c9712 rest_of_handle_thread_prologue_and_epilogue
../../gcc/function.c:6487
0x8c9712 execute
../../gcc/function.c:6529
[Bug target/82673] [8 Regression] ICE in ix86_finalize_stack_frame_flags at gcc/config/i386/i386.c:12695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82673 --- Comment #1 from Uroš Bizjak --- (In reply to Martin Liška from comment #0) > Starting from r251075 we ICE one: Are you sure you got the correct revision? The one you referred to deals with thread pointers and address spaces.
[Bug target/82674] New: ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 Bug ID: 82674 Summary: ICE with -fstack-clash-protection Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: ppc64-linux-gnu Following ICEs: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c --param stack-clash-protection-probe-interval=16 -fstack-clash-protection /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c: In function ‘foo1’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c:12:1: error: unrecognizable insn: } ^ (insn 39 69 40 5 (parallel [ (set (mem:DI (plus:DI (reg/f:DI 1 1) (const_int -65536 [0x])) [0 S8 A8]) (reg:DI 144)) (set (reg/f:DI 1 1) (plus:DI (reg/f:DI 1 1) (const_int -65536 [0x]))) ]) "/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c":9 -1 (nil)) during RTL pass: vregs /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c:12:1: internal compiler error: in extract_insn, at recog.c:2305 0xe90dbd _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:108 0xe90dfe _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:116 0xe3a661 extract_insn(rtx_insn*) ../../gcc/recog.c:2305 0xb2fcac instantiate_virtual_regs_in_insn ../../gcc/function.c:1639 0xb31172 instantiate_virtual_regs ../../gcc/function.c:1959 0xb3123c execute ../../gcc/function.c:2008
[Bug tree-optimization/82675] ICE in duplicate_loop_to_header_edge at gcc/cfgloopmanip.c:1207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82675 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/82675] New: ICE in duplicate_loop_to_header_edge at gcc/cfgloopmanip.c:1207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82675
Bug ID: 82675
Summary: ICE in duplicate_loop_to_header_edge at
gcc/cfgloopmanip.c:1207
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
After we've added sbitmap checking, we hit:
$ cat ice.i
char a[1];
int *b;
int e();
void c ()
{
char *d = a;
while (*b && d < a + 300)
*d++ = e ();
}
$ ./xgcc -B. ~/Programming/testcases/ice.i -fno-tree-loop-optimize -O1
-funroll-all-loops
during RTL pass: loop2_unroll
/home/marxin/Programming/testcases/ice.i: In function ‘c’:
/home/marxin/Programming/testcases/ice.i:11:1: internal compiler error: in
bitmap_check_index, at sbitmap.h:105
}
^
0x75d239 bitmap_check_index
../../gcc/sbitmap.h:105
0x75d25c bitmap_bit_p
../../gcc/sbitmap.h:120
0x760500 duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int,
simple_bitmap_def*, edge_def*, vec*, int)
../../gcc/cfgloopmanip.c:1207
0xa1493e unroll_loop_constant_iterations
../../gcc/loop-unroll.c:554
0xa15610 unroll_loops(int)
../../gcc/loop-unroll.c:289
0xa0586f execute
../../gcc/loop-init.c:584
1207scale_step[i - 1] = bitmap_bit_p (wont_exit, i)
(gdb) p *wont_exit
$1 = {n_bits = 5, size = 1, elms = {28}}
(gdb) p i
$2 = 5
[Bug target/82673] [8 Regression] ICE in ix86_finalize_stack_frame_flags at gcc/config/i386/i386.c:12695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82673 --- Comment #2 from Martin Liška --- (In reply to Uroš Bizjak from comment #1) > (In reply to Martin Liška from comment #0) > > Starting from r251075 we ICE one: > > Are you sure you got the correct revision? The one you referred to deals > with thread pointers and address spaces. Sorry, it's revision r251076 :)
[Bug tree-optimization/82129] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82129 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Oct 23 09:20:14 2017 New Revision: 253998 URL: https://gcc.gnu.org/viewcvs?rev=253998&root=gcc&view=rev Log: 2017-10-23 Richard Biener PR tree-optimization/82129 * tree-ssa-pre.c (bitmap_set_and): Remove. (compute_antic_aux): Compute ANTIC_OUT intersection in a way canonicalizing expressions in the set to those with lowest ID rather than taking that from the first edge. * gcc.dg/torture/pr82129.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr82129.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/82129] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82129 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug rtl-optimization/82671] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82671 Richard Biener changed: What|Removed |Added Component|tree-optimization |rtl-optimization Version|unknown |8.0 Target Milestone|--- |8.0
[Bug tree-optimization/82672] [8 Regression][GRAPHITE] ICE in verify_gimple_in_cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82672 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-23 Version|unknown |8.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug rtl-optimization/82675] ICE in duplicate_loop_to_header_edge at gcc/cfgloopmanip.c:1207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82675 Richard Biener changed: What|Removed |Added Component|tree-optimization |rtl-optimization Version|unknown |8.0 Target Milestone|8.0 |---
[Bug rtl-optimization/82675] ICE in duplicate_loop_to_header_edge at gcc/cfgloopmanip.c:1207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82675 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-23 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I'll try to fix it.
[Bug tree-optimization/82627] [8 regression] r253809 breaks test cases gcc.dg/graphite/interchange-3.c -7.c, -9.c, and uns-interchange-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82627 --- Comment #5 from Richard Biener --- What ISL version are you using? We have the same IL before ISL but the transformed schedule is different and for some reason the AST generator biases one IV by one. Before the rev. ISL did even more weird stuff to this testcase for you. Please make sure to use ISL 0.18.
[Bug testsuite/82415] FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415 --- Comment #2 from Tom de Vries --- Created attachment 42438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42438&action=edit patch that filters out comment lines in scan-assembler* Alternative approach.
[Bug tree-optimization/82676] New: GRAPHITE doesn't handle niter with may_be_zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82676 Bug ID: 82676 Summary: GRAPHITE doesn't handle niter with may_be_zero Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Blocks: 59859 Target Milestone: --- $summary. It should use number_of_iterations_exit and only reject assumptions (even that could go into a versioning condition). may_be_zero can be added as an additional constraint on the domain. Needs some refactoring for handling of condition / constraint generation for conditions. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 [Bug 59859] [meta-bug] GRAPHITE issues
[Bug target/82268] [8 regression] i386/pr82196-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82268 --- Comment #3 from Sebastian Peryt --- It passes with the provided modification.
[Bug target/82268] [8 regression] i386/pr82196-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82268 --- Comment #4 from Andrey Guskov --- The command line (broken into several lines for the sake of readability): spawn -ignore SIGHUP /build/gcc/xgcc -B/build/gcc/ /source/gcc/testsuite/gcc.target/i386/pr82196-1.c -B/build/x86_64-pc-linux-gnu/./libmpx/ -B/build/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/build/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/build/x86_64-pc-linux-gnu/./libmpx/ -B/build/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/build/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -msse -mcall-ms2sysv-xlogues -O2 -ffat-lto-objects -S -o pr82196-1.s PASS: gcc.target/i386/pr82196-1.c (test for excess errors) FAIL: gcc.target/i386/pr82196-1.c scan-assembler call.*__sse_savms64f?_12 FAIL: gcc.target/i386/pr82196-1.c scan-assembler jmp.*__sse_resms64f?x_12
[Bug bootstrap/82610] [8 Regression] Bootstrap fails on macOS 10.13 and FreeBSD 11.1 because of abort redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82610 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #4 from Pedro Alves --- I think it makes sense to keep including in unique-ptr.h, because the header needs that, and projects other than GCC will want to use this file. Including it in both system.h and leaving it in unique-ptr.h should work fine for GCC, assuming has proper include guards? (IMO, #pragma poison should ignore references in system headers and then these weird contortions GCC goes through in system.h would no longer be necessary.)
[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Mon Oct 23 11:10:28 2017 New Revision: 254004 URL: https://gcc.gnu.org/viewcvs?rev=254004&root=gcc&view=rev Log: PR libstdc++/82644 document IS 29124 support Also fix declarations of special functions in C++17, to import them into the global namespace in , and to prevent defining the non-standard hypergeometric functions in strict mode. PR libstdc++/82644 * doc/xml/manual/intro.xml: Include new section. * doc/xml/manual/status_cxxis29124.xml: New section on IS 29124 status. * include/bits/specfun.h [__STRICT_ANSI__] (hyperg, hypergf, hypergl) (conf_hyperg, conf_hypergf, conf_hypergl): Don't declare. * include/c_compatibility/math.h: Import special functions into global namespace for C++17. * testsuite/26_numerics/headers/cmath/82644.cc: New test. * testsuite/26_numerics/headers/cmath/functions_global_c++17.cc: New test. Added: trunk/libstdc++-v3/doc/xml/manual/status_cxxis29124.xml trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/82644.cc trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_global_c++17.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/specfun.h trunk/libstdc++-v3/include/c_compatibility/math.h
[Bug tree-optimization/54027] [4.8 Regression] possible mis-optimization of signed left shift in c89 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54027 --- Comment #8 from rguenther at suse dot de --- On Sat, 21 Oct 2017, info at learnthreejs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54027 > > Tristan changed: > >What|Removed |Added > > CC||info at learnthreejs dot com > > --- Comment #7 from Tristan --- > Still having an issue with the VRP shift. > > New here, where can I check out this patch? Might need a refresh! > > https://www.learnthreejs.com/beginners-tutorial/ > > Above is a resource I tested it on (my site). Still experiencing > difficulties. Sorry, but your problem is likely not related plus the description of your issue is not complete. See https://gcc.gnu.org/bugs.html Please open a new bug if you have a testcase.
[Bug tree-optimization/82129] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82129 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Oct 23 11:14:40 2017 New Revision: 254005 URL: https://gcc.gnu.org/viewcvs?rev=254005&root=gcc&view=rev Log: 2017-10-23 Richard Biener PR tree-optimization/82129 Revert 2017-08-01 Richard Biener PR tree-optimization/81181 * tree-ssa-pre.c (compute_antic_aux): Defer clean() to ... (compute_antic): ... end of iteration here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/81181] [7 Regression] ICE in compute_antic, at tree-ssa-pre.c:2410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81181 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Oct 23 11:14:40 2017 New Revision: 254005 URL: https://gcc.gnu.org/viewcvs?rev=254005&root=gcc&view=rev Log: 2017-10-23 Richard Biener PR tree-optimization/82129 Revert 2017-08-01 Richard Biener PR tree-optimization/81181 * tree-ssa-pre.c (compute_antic_aux): Defer clean() to ... (compute_antic): ... end of iteration here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug inline-asm/82677] New: Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
Bug ID: 82677
Summary: Many projects (linux, coreutils, GMP, gcrypt, openSSL,
etc) are misusing asm(divq/divl) etc, potentially
resulting in faulty/unintended optimisations
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: infinity0 at pwned dot gg
Target Milestone: ---
Created attachment 42439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42439&action=edit
Basic optimisation example, C-reduced from flint test code
If I understood the issue correctly, this is strictly speaking not a GCC bug.
But I'm filing this here so there is a central place to have the discussion.
There is also the possibility of GCC developers discussing a central fix for
this issue in GCC itself, rather than patching 20+ FOSS projects.
Background
==
When using asm() it is vital that the dependencies are expressed correctly,
otherwise GCC can optimise stuff in an unintended way. Those new to the topic
(e.g. me a few days ago) can read:
- https://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html for a nice
intro
- https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html for details
The Intel instruction manual [0] for the "div" and "idiv" instructions states
that:
- "The CF, OF, SF, ZF, AF, and PF flags are undefined."
- raises a #DE (Divide error) (#a) "If the source operand (divisor) is 0" and
(#b) "If the quotient is too large for the designated register."
Therefore, if you want to write a general-purpose "div" utility in GCC asm,
that assumes nothing about its inputs or outputs, the correct syntax would be
something along the lines of:
__asm__ __volatile__("divq %4" : "=a"(q), "=d"(r) : "0"((ulong)n0),
"1"((ulong)n1), "rm"((ulong)d) : "cc");
- __volatile__ because raising an exception is a "side-effect", i.e. affects
something outside of the declared inputs and outputs, and
- "cc" because it might clobber the FLAGS register.
Note that __volatile__ is necessary even if the divisor "cannot be 0" in most
cases. (Therefore, it is necessary for a general-purpose "div" utility.) For
example, (##) if the code is unreachable for reasons unrelated to the division
operands, then the instruction will never raise a DE, but if __volatile__ is
not declared then GCC might optimise the code in a way such that the div
operation *is* reachable sometimes when the divisor is zero.
To demonstrate that example concretely, see udiv.c as a test case, where "if
(g)" should prevent the div from running, but GCC 7.2 -O2 lifts the asm() out
of the inner loop and the if(), causing a DE (SIGFPE) at run time. (udiv.c was
minimised from the real-world example at [1] using C-Reduce [2] - which I
couldn't have done this without.)
One way to make __volatile__ *actually* unnecessary, is to do an explicit
unconditional check (i.e. not based on a removeable macro) for divisor != 0
before the operation, and branch away if = 0. In this case, since divisor is an
input to the asm() instruction, GCC will then know not to reorder it with
respect to the branch.
Also, I am not sure if this sort of unexpected SIGFPE could potentially result
in a security problem. If so then perhaps the priority should be raised.
[0] https://software.intel.com/en-us/articles/intel-sdm
[1] https://github.com/fredrik-johansson/arb/issues/194
[2] https://embed.cs.utah.edu/creduce/
Problem
===
Lots of people copied the same code (longlong.h), with the same definition of
udiv_qrnnd, into their own projects. [3] At the time of writing this includes:
linux, grub2, coreutils, GMP, gcrypt, mpfr, and even older versions of GCC
itself. The code seems to originate from GMP, but I didn't confirm this or
investigate in great detail.
Now technically it is possible to use this correctly, by doing an unconditional
explicit check for divisor != 0 as mentioned above. However, this complexity is
*not* documented in the description, e.g. [4], which even describes the *other*
condition (#b) above, for the instruction not to raise an exception -
"HIGH_NUMERATOR must be less than DENOMINATOR for correct operation.". Even if
it was documented naively ("divisor must be zero"), one can imagine someone
interpreting this as (##) above, which would still be incorrect and still cause
faulty optimisations.
Also, there is a fallback macro __udiv_qrnnd_c [5] defined which reimplements
the instruction in C for platforms that don't have it, and in this case GCC
knows that the C "/" operation can cause div-by-zero errors, and optimises
everything as intended, as one can see by compiling the udiv-alt.c attached
with -DNOOPT_UDIV. So this suggests that the original author of udiv_qrnnd was
not aware of these issues either - since the correctness requirements between
udiv_qrnnd and __udiv_qrnnd_c ar
[Bug inline-asm/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #1 from infinity0 at pwned dot gg --- Created attachment 42440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42440&action=edit Similar test case using macros from GMP et. al.
[Bug inline-asm/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #2 from infinity0 at pwned dot gg --- More immutable version of [5]: [5] https://gmplib.org/repo/gmp/annotate/046bc83644a3/longlong.h#l1574
[Bug c++/77555] unused inline function in-function static variable accessed from outside leads to linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77555 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Oct 23 11:39:20 2017 New Revision: 254006 URL: https://gcc.gnu.org/viewcvs?rev=254006&root=gcc&view=rev Log: 2017-10-23 Paolo Carlini PR c++/77555 * g++.dg/torture/pr77555.C: New. Added: trunk/gcc/testsuite/g++.dg/torture/pr77555.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/77555] unused inline function in-function static variable accessed from outside leads to linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77555 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|marmoo1024 at gmail dot com| Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Paolo Carlini --- Fixed in 7.1.0.
[Bug target/82668] could use BMI2 rorx for unpacking struct { int a,b }; from a register (SysV ABI)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82668 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Not sure where we would have the necessary infrastructure for this. To be able to use rorx instead of the right shift, the requirement is that the only use (or all uses) of the shift destination are ignoring the upper bits, i.e. only use lowpart SImode of it. But combine apparently can't help here, I see only: Failed to match this instruction: (parallel [ (set (reg:SI 91) (plus:SI (subreg:SI (zero_extract:DI (reg/v:DI 90 [ s ]) (const_int 32 [0x20]) (const_int 32 [0x20])) 0) (subreg:SI (reg/v:DI 90 [ s ]) 0))) (clobber (reg:CC 17 flags)) ]) Failed to match this instruction: (set (reg:SI 91) (plus:SI (subreg:SI (zero_extract:DI (reg/v:DI 90 [ s ]) (const_int 32 [0x20]) (const_int 32 [0x20])) 0) (subreg:SI (reg/v:DI 90 [ s ]) 0))) Failed to match this instruction: (set (reg:SI 91) (plus:SI (subreg:SI (lshiftrt:DI (reg/v:DI 90 [ s ]) (const_int 32 [0x20])) 0) (subreg:SI (reg/v:DI 90 [ s ]) 0))) Having a myriad of SImode arithmetics define_insn_and_split that would match one of the operands to be a subreg of lshiftrt or zero_extract is not maintainable. Or very specialized peephole2 that would handle this. Or handle it at expansion time, though the problem is that the extvdi/extzvdi patterns are expected to extract DImode value from DImode source, not SImode from DImode source, and rorx $32 obviously doesn't provide that.
[Bug inline-asm/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #3 from Marc Glisse --- On x86, by default, the compiler already assumes that flags are clobbered. That's explained in a comment in GMP's longlong.h at least.
[Bug target/82673] [8 Regression] ICE in ix86_finalize_stack_frame_flags at gcc/config/i386/i386.c:12695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82673 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-23 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01475.html
[Bug target/82659] Unnecessary ENDBR in static/local functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82659 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-23 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01411.html
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-23
CC||rguenth at gcc dot gnu.org
Component|inline-asm |rtl-optimization
Ever confirmed|0 |1
--- Comment #4 from Richard Biener ---
This is RTL invariant motion hoisting the non-volatile asm out of the loop even
though it is _not_ unconditionally executed.
I think it is against the spirit of asm()s to be treated this way. We're
handling possible NULL pointer dereferences correctly (just not in asm()s)
as well.
So I think LIM needs to be conservative with not always executed asm()s.
It's still safe to move the asm in
int main() {
ulong d = 0;
for (ulong i = 0; i < 3; i++)
for (ulong j = 0; j < 3; j++)
{
ulong r;
__asm__("" : "=r"(d) : "rm"((ulong)0));
udiv_qrnnd(q, r, 0, 0, (i << d));
}
}
thus without the if ().
[Bug c++/77771] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #4 from Paolo Carlini --- Likely related to PR57335.
[Bug c++/82678] New: g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678
Bug ID: 82678
Summary: g++ crashes on wrong lamda
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stergios.zissakis at silixa dot com
Target Milestone: ---
Please see: https://bugzilla.redhat.com/show_bug.cgi?id=1504185
As CentOS7 suggested I reported the bug on RedHat's website...
Pasting the description in:
Sterge 2017-10-19 11:50:35 EDT
Created attachment 1340826 [details]
Preprocessed source code
Description of problem:
Compiler (g++) crash
Version-Release number of selected component (if applicable):
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
How reproducible:
Preprocessed source attached
Steps to Reproduce:
1. Use the attached preprocessed code
2. If not good, please contact me for initial srouce code
3.
Actual results:
c++ -g -std=c++11 -I. -I/home/szis/dev/cppInfrastructure/src/
-I/home/szis/dev/cppInfrastructure/include/ -fpermissive -c
/home/szis/dev/cppInfrastructure/src/main.cpp -o
/home/szis/dev/cppInfrastructure/src/main.o
In file included from /usr/include/c++/4.8.2/thread:39:0,
from
/home/szis/dev/cppInfrastructure/include/utils/Logger.h:10,
from /home/szis/dev/cppInfrastructure/src/main.cpp:8:
/usr/include/c++/4.8.2/functional: In instantiation of ‘typename
std::result_of<_Functor(_ArgTypes ...)>::type std::_Bind_simple<_Callable(_Args
...)>::_M_invoke(std::_Index_tuple<_Indices ...>) [with long unsigned int
..._Indices = {}; _Callable = FileReader::Go() const [with T =
double]::__lambda2; _Args = {}; typename std::result_of<_Functor(_ArgTypes
...)>::type = void]’:
/usr/include/c++/4.8.2/functional:1720:36: required from
‘std::_Bind_simple<_Callable(_Args ...)>::result_type
std::_Bind_simple<_Callable(_Args ...)>::operator()() [with _Callable =
FileReader::Go() const [with T = double]::__lambda2; _Args = {};
std::_Bind_simple<_Callable(_Args ...)>::result_type = void]’
/usr/include/c++/4.8.2/thread:115:13: required from ‘void
std::thread::_Impl<_Callable>::_M_run() [with _Callable =
std::_Bind_simple::Go() const [with T = double]::__lambda2()>]’
/home/szis/dev/cppInfrastructure/src/main.cpp:79:1: required from here
/usr/include/c++/4.8.2/functional:1731:63: internal compiler error: in
tsubst_copy, at cp/pt.c:12137
return std::forward<_Callable>(std::get<0>(_M_bound))(
^
Expected results:
An object file.
Please also find attached a preprocessed code file from gcc.
Cheers,
Sterge
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
--- Comment #5 from infinity0 at pwned dot gg ---
(In reply to Richard Biener from comment #4)
> [..]
> It's still safe to move the asm in
>
> int main() {
> ulong d = 0;
> for (ulong i = 0; i < 3; i++)
> for (ulong j = 0; j < 3; j++)
> {
> ulong r;
> __asm__("" : "=r"(d) : "rm"((ulong)0));
> udiv_qrnnd(q, r, 0, 0, (i << d));
> }
> }
>
> thus without the if ().
For the specific case of asm(div) I suppose it's safe because raising a DE is
pretty much similar to raising it several times in a loop, but it is correct to
assume that for all types of side effects?
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 --- Comment #2 from Sterge --- Created attachment 42442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42442&action=edit preprocessed code
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 --- Comment #1 from Sterge --- Created attachment 42441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42441&action=edit preprocessed code
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 --- Comment #3 from Sterge --- Created attachment 42443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42443&action=edit preprocessed code
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 --- Comment #4 from Sterge --- Created attachment 42444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42444&action=edit preprocessed code
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #6 from infinity0 at pwned dot gg --- What I mean is, even if you do change GCC to fix the unintended optimisation, other projects' code are *still wrong* - it's only correct if you can assume the C compiler is optimising your code in a very specific way, that happens to safe for the specific sorts of "side effects" that div instructions do.
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-23 Ever confirmed|0 |1 --- Comment #5 from Paolo Carlini --- 4.8.x is no longer maintained: please check if you can reproduce the issue with 6.x or 7.x.
[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- Hi Marek, are you still working on this?
[Bug target/82667] SSE2 redundant pcmpgtd for sign-extension of values known to be >= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82667
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
So, either the vectorizer needs to know that on this target signed vector
extension (vec_unpack_{lo,hi}_expr) is more expensive than unsigned one
(through costs, other means) and if there is a cost difference between them,
try to look at VRP info whether it is known to have zero MSB and thus both sign
and zero extension do the same thing and based on that choose the cheaper
extension.
Unfortunately we don't have that VRP info available right now, we have only
_ifc__30 = _4 > 127 ? _24 : 0;
# RANGE [0, 9223372036854775807] NONZERO 9223372036854775807
prephitmp_27 = sum_19 + _ifc__30;
because ifc__30 is created during ifcvt pass and VRP info hasn't been computed
for that.
So, it would have to be smarts in the on-demand VRP if we ever get that.
Or, to optimize this later on, e.g. during expansion, we'd need value ranges
for integral vectors, either precise ones which would have a separate value
range for each element, or at least one conservative one that would cover all
elements (easier/smaller to preserve, but VRP would need to be changed to also
handle these conservative or full ranges for vector elements).
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 --- Comment #6 from Sterge --- Thanks mate and apologies for the spam! Didn't know that's the version that comes with CentOS 7. I am closing it.
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 Sterge changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sterge --- Version not supported.
[Bug c++/82678] g++ crashes on wrong lamda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82678 Sterge changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Hi, not right now, and I won't get to this soon. Sorry.
[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot com| --- Comment #7 from Paolo Carlini --- Thanks Marek, no problem. Just wanted to avoid somebody else (not me, at the moment) to be prevented from working on a fix.
[Bug bootstrap/82610] [8 Regression] Bootstrap fails on macOS 10.13 and FreeBSD 11.1 because of abort redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82610 --- Comment #5 from David Malcolm --- I posted fxcoudert's patch from comment 0 for review here: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01478.html
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #7 from rguenther at suse dot de --- On Mon, 23 Oct 2017, infinity0 at pwned dot gg wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 > > --- Comment #6 from infinity0 at pwned dot gg --- > What I mean is, even if you do change GCC to fix the unintended optimisation, > other projects' code are *still wrong* - it's only correct if you can assume > the C compiler is optimising your code in a very specific way, that happens to > safe for the specific sorts of "side effects" that div instructions do. You still have to mark stmts with side-effects as volatile. Conditional side-effects are tricky to get correct of course.
[Bug c/82679] New: Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679
Bug ID: 82679
Summary: Uses of typedefs of arrays of _Atomic-qualified types
are rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: olivier.delande.spam at googlemail dot com
Target Milestone: ---
Created attachment 42445
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42445&action=edit
minimal example reproducing the problem
Consider the following minimal program (also attached to this report):
typedef _Atomic int my_array[42];
my_array x;
int main(void) {
return 0;
}
When compiling this program with
gcc -std=c11 test.c
I get the output:
test.c:2:10: error: ‘_Atomic’-qualified array type
my_array x;
^
GCC complains that x's array type is qualified with _Atomic, but I believe that
what is so qualified is the element type, not the array type (which would
indeed be illegal). The program should be compiled without generating any
error.
For completeness, here is the output of gcc -v -std=c11 test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.5' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
COLLECT_GCC_OPTIONS='-v' '-std=c11' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -v -imultiarch x86_64-linux-gnu
test.c -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test
-std=c11 -version -fstack-protector-strong -Wformat -Wformat-security -o
/tmp/ccnPUUlu.s
GNU C11 (Ubuntu 5.4.0-6ubuntu1~16.04.5) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/5/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (Ubuntu 5.4.0-6ubuntu1~16.04.5) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 20effb81769d6418d1599a71173c569c
test.c:2:10: error: ‘_Atomic’-qualified array type
my_array x;
^
[Bug tree-optimization/82672] [8 Regression][GRAPHITE] ICE in verify_gimple_in_cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82672 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Oct 23 13:49:24 2017 New Revision: 254009 URL: https://gcc.gnu.org/viewcvs?rev=254009&root=gcc&view=rev Log: 2017-10-23 Richard Biener PR tree-optimization/82672 * graphite-isl-ast-to-gimple.c (graphite_copy_stmts_from_block): Fold the stmt if we propagated into it. * gfortran.dg/graphite/pr82672.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/graphite/pr82672.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug target/81924] [6 Regression] ICE: in simplify_binary_operation_1, at simplify-rtx.c:3678 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81924 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Bill Schmidt --- I've backported the fix for the latent bug here: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01388.html I'm going to go ahead and close this since GCC 5 is no longer in service, and all known related issues for later releases are resolved. Matthias, feel free to work with me offline if you want to investigate anything further for 5 out of tree.
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- GCC is correct here, and this behavior is intentional: /* Applying the _Atomic qualifier to an array type (through the use of typedefs or typeof) must be detected here. If the qualifier is introduced later, any appearance of applying it to an array is actually applying it to an element of that array. */ if (atomicp && TREE_CODE (type) == ARRAY_TYPE) error_at (loc, "%<_Atomic%>-qualified array type");
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Mon Oct 23 14:58:23 2017 New Revision: 254011 URL: https://gcc.gnu.org/viewcvs?rev=254011&root=gcc&view=rev Log: PR target/82628 * config/i386/predicates.md (x86_64_dwzext_immediate_operand): New. * config/i386/constraints.md (Wf): New constraint. * config/i386/i386.md (UNSPEC_SBB): New unspec. (cmp_doubleword): Removed. (sub3_carry_ccc, *sub3_carry_ccc_1): New patterns. (sub3_carry_ccgz): Use unspec instead of compare. * config/i386/i386.c (ix86_expand_branch) : Don't expand with cmp_doubleword. For LTU and GEU use sub3_carry_ccc instead of sub3_carry_ccgz and use CCCmode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/constraints.md trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-23 CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com Ever confirmed|0 |1
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679
--- Comment #2 from olivier.delande.spam at googlemail dot com ---
(In reply to Marek Polacek from comment #1)
> GCC is correct here, and this behavior is intentional:
I don't understand. The comment you are quoting mentions detecting
qualifications of the array type, whereas my example qualifies the element
type. This is made clearer in the following variant of my example, which
produces the same error:
typedef _Atomic int my_atomic_int;
typedef my_atomic_int my_array[42];
my_array x;
int main(void) {
return 0;
}
This additional typedef makes it clearer that int is qualified, not the array
type.
You write that GCC is correct, but my interpretation of the C standard is that
it is not. Could you elaborate and provide a reference to the part of the
standard supporting GCC's behavior?
(For comparison, clang 3.8.0 accepts both my examples, and does reject _Atomic
qualifications of array types.)
[Bug middle-end/39218] a surprising instance of -fstack-protector not protecting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39218 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Someone brought this up on the gcc-help mailing list here: https://gcc.gnu.org/ml/gcc-help/2017-10/msg00134.html
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679 Marek Polacek changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Marek Polacek --- Sorry, I probably shouldn't have closed this. I guess what we want to reject is typedef int T[10]; _Atomic T a; but not your example.
[Bug target/82680] New: Use cmpXXss and cmpXXsd for setcc boolean compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82680
Bug ID: 82680
Summary: Use cmpXXss and cmpXXsd for setcc boolean compare
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Both, ICC and clang use cmpXXss and cmpXXsd instructions for setcc boolean
compare:
int g(double x, double y)
{
return x == y;
}
ICC:
cmpeqsd %xmm1, %xmm0
movd %xmm0, %eax
negl %eax
ret
clang:
cmpeqsd %xmm1, %xmm0
movq%xmm0, %rax
andl$1, %eax
retq
gcc w/ -ffast-math:
xorl%eax, %eax
comisd %xmm1, %xmm0
sete%al
ret
Versions with direct moves avoid partial register stalls.
[Bug target/82673] [8 Regression] ICE in ix86_finalize_stack_frame_flags at gcc/config/i386/i386.c:12695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82673 --- Comment #4 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Oct 23 15:49:19 2017 New Revision: 254013 URL: https://gcc.gnu.org/viewcvs?rev=254013&root=gcc&view=rev Log: i386: Skip DF_REF_INSN if DF_REF_INSN_INFO is false We should check DF_REF_INSN_INFO before accessing DF_REF_INSN. gcc/ PR target/82673 * config/i386/i386.c (ix86_finalize_stack_frame_flags): Skip DF_REF_INSN if DF_REF_INSN_INFO is false. gcc/testsuite/ PR target/82673 * gcc.target/i386/pr82673.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr82673.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679 --- Comment #4 from olivier.delande.spam at googlemail dot com --- (In reply to Marek Polacek from comment #3) > Sorry, I probably shouldn't have closed this. I guess what we want to > reject is > > typedef int T[10]; > _Atomic T a; > > but not your example. Indeed, that is exactly what I would expect (from my understanding of the standard), and, as far as I can tell, that is what clang does. I have not tested other compilers. To anyone else is affected by this: a workaround (besides not using typedef for such array types) is to wrap the atomic element type in a struct. Thanks!
[Bug target/82680] Use cmpXXss and cmpXXsd for setcc boolean compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82680 Uroš Bizjak changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #1 from Uroš Bizjak --- Maybe Peter knows which version is the best.
[Bug target/82673] [8 Regression] ICE in ix86_finalize_stack_frame_flags at gcc/config/i386/i386.c:12695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82673 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from H.J. Lu --- Fixed.
[Bug fortran/82622] [PDT] ICE in structure_alloc_comps, at fortran/trans-array.c:8963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82622 --- Comment #3 from G. Steinmetz --- Backtrace for example z2 from comment 1 : (with new snapshot, configured with --enable-checking=yes) $ gfortran-8-20171022 -c z2.f90 z2.f90:1:0: program p internal compiler error: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.c:5881 0x60eaa1 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9098 0x76c493 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3094 0x76c493 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.c:5881 0x7a4dd0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6805 0x7a5621 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7708 0x7a4fb1 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6840 0x78945c gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1819 0x78d1d7 generate_local_decl ../../gcc/fortran/trans-decl.c:5493 0x744f4b do_traverse_symtree ../../gcc/fortran/symbol.c:4157 0x78dfa2 generate_local_vars ../../gcc/fortran/trans-decl.c:5693 0x78dfa2 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6357 0x712e40 translate_all_program_units ../../gcc/fortran/parse.c:6088 0x712e40 gfc_parse_file() ../../gcc/fortran/parse.c:6291 0x75819f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug c/82681] New: c-warn.c:1218: typo in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82681 Bug ID: 82681 Summary: c-warn.c:1218: typo in warning message 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: --- $ fgrep -n chages */*.c c-family/c-warn.c:1218: "chages value from %qE to %qE", c-family/c-warn.c:1223: "chages the value of %qE", $ Should be "changes", shouldn't it ? svn blame says: $ svn blame c-family/c-warn.c | fgrep chages 248431 msebor "chages value from %qE to %qE", 248431 msebor "chages the value of %qE", $
[Bug c/82681] c-warn.c:1218: typo in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82681 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-23 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Of course, will fix.
[Bug middle-end/82062] [8 regression] simple conditional expressions no longer folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062 --- Comment #4 from Eric Botcazou --- Any progress on this? We only need to partially revert the change it seems.
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #15 from Paul Thomas ---
Hi DIL,
On reflection, this is OK and agrees with your diagnosis:
> val_p._vptr = (struct __vtype__STAR * {ref-all}) &__vtab__STAR;
> val_p._len = 0;
> val_p._data = 0B;
> cep._vptr = (struct __vtype_gfc_base_Gfc_cont_elem_t * {ref-all})
> &__vtab_gfc_base_Gfc_cont_elem_t;
> cep._data = 0B;
> {
> struct __class_gfc_base_Gfc_cont_elem_t_p rhs.69;
>
> rhs.69 = this->_vptr->element ((struct
> __class_gfc_vector_Vector_iter_t_t *) this, (integer(kind=8) *) offset,
> &errc);
> cep._vptr = rhs.69._vptr;
> cep._data = rhs.69._data;
> }
> if ((logical(kind=4)) (errc == 0 && cep._data != 0B))
> {
> {
> struct __class_gfc_base_Gfc_cont_elem_t_t this.70;
> struct __class__STAR_p rhs.71;
>
> this.70 = VIEW_CONVERT_EXPR __class_gfc_base_Gfc_cont_elem_t_t>(cep);
> rhs.71 = cep._vptr->get_value (&this.70, &errc);
> val_p._vptr = rhs.71._vptr;
> val_p._len = 0;
> val_p._data = rhs.71._data;
> }
> }
The vtable pointed to by rhs.69._vptr and so cep._vptr is clearly not the right
one.
I am on a business trip right now and so cannot work on this bug (back on
Thursday). However, it would help me get back up to speed if you could give me
a few pointers, if you will excuse the pun.
It should be possible to tell from your debug session which type's vtable is
being pointed to and MAYBE where the wrong assignment to the vpointer is being
made.
BTW is this the first visit to this bit of code? I didn't run a debug session
yet because the crash is so spectacular that I had to restart the terminal each
time! After three or four such, the system falls over :-)
I'll get back to this problem later on this week. I regard it as being a
serious bug and want to get on top of it asap.
Paul
[Bug c/82681] c-warn.c:1218: typo in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82681
--- Comment #2 from David Binderman ---
I counted five uses of the word "chages" in the original patch.
Seemingly, the word is searched for in output from the testsuite.
$ pwd
/home/dcb/gcc/trunk/gcc/testsuite
$ fgrep chages `find . -name \*.c -print`
./gcc.dg/overflow-warn-8.c: int i6 = (double)1.0 + INT_MAX; /* { dg-warning
"overflow in conversion from .double. to .int. chages value" } */
./gcc.dg/c90-const-expr-11.c: struct t c = { DBL_MAX }; /* { dg-warning
"overflow in conversion from .double. to .int. chages value " } */
./gcc.dg/overflow-warn-5.c:return p & 512; /* { dg-warning "overflow in
conversion from .int. to .unsigned char. chages value" } */
$
[Bug c/82681] c-warn.c:1218: typo in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82681 --- Comment #3 from Marek Polacek --- Yeah, I'm fixing those too.
[Bug c++/82664] Internal Compiler Error when using Match7 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82664 --- Comment #2 from Furkan --- Created attachment 42446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42446&action=edit .ii file for example03 Sorry, about the tar file but .ii file was bigger than 1MB
[Bug c++/82664] Internal Compiler Error when using Match7 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82664 --- Comment #3 from Furkan --- Created attachment 42447 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42447&action=edit Other two test cases that are failing as well Again, sorry about the split submit but I remembered that I've found 2 more test cases after submitting the previous one. They are rather lengthy test cases, but I've added them as well. If you want to check the original code, they are: test/unit/prolog.cpp test/unit/type_switchN-decl.cpp
[Bug target/82682] New: [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682 Bug ID: 82682 Summary: [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Starting with this revision, on i686-linux (or x86_64-linux with -m32) there are 3 movzbls instead of 2. Are the cost changes correct? If they are, shall we adjust the testcase?
[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-23 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Honza, this is yours r253958.
[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c/82681] c-warn.c:1218: typo in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82681 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Mon Oct 23 17:03:11 2017 New Revision: 254014 URL: https://gcc.gnu.org/viewcvs?rev=254014&root=gcc&view=rev Log: PR c/82681 * c-warn.c (warnings_for_convert_and_check): Fix typos. * gcc.dg/c90-const-expr-11.c: Fix typos in dg-warning. * gcc.dg/overflow-warn-5.c: Likewise. * gcc.dg/overflow-warn-8.c: Likewise. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/c90-const-expr-11.c trunk/gcc/testsuite/gcc.dg/overflow-warn-5.c trunk/gcc/testsuite/gcc.dg/overflow-warn-8.c
[Bug c/82681] c-warn.c:1218: typo in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82681 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug libstdc++/81395] [6/7 Regression] basic_filebuf::overflow recurses and overflows stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395 --- Comment #18 from Jonathan Wakely --- Author: redi Date: Mon Oct 23 17:16:38 2017 New Revision: 254015 URL: https://gcc.gnu.org/viewcvs?rev=254015&root=gcc&view=rev Log: PR libstdc++/81395 fix crash when write follows large read Backport from mainline 2017-07-18 Jonathan Wakely PR libstdc++/81395 * include/bits/fstream.tcc (basic_filebuf::xsgetn): Don't set buffer pointers for write mode after reading. * testsuite/27_io/basic_filebuf/sgetn/char/81395.cc: New. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_filebuf/sgetn/char/81395.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/fstream.tcc
[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #16 from DIL --- Hi Paul, Thanks for looking into this issue. I ran the debugger again. The vtab corruption occurs upon the first encounter in function VectorIterElement() in line 720 of gfc_vector.F90. Just to make sure, that line begins with: elem_p=>this%container%vec_tile(q(4))%... Before that line, the elem_p (cep) vtab looks fine. After that line it gets bad. Please let me know if you need more information from the debugger.
[Bug libstdc++/81395] [6/7 Regression] basic_filebuf::overflow recurses and overflows stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395 --- Comment #19 from Jonathan Wakely --- Author: redi Date: Mon Oct 23 17:47:10 2017 New Revision: 254018 URL: https://gcc.gnu.org/viewcvs?rev=254018&root=gcc&view=rev Log: PR libstdc++/81395 fix crash when write follows large read Backport from mainline 2017-07-18 Jonathan Wakely PR libstdc++/81395 * include/bits/fstream.tcc (basic_filebuf::xsgetn): Don't set buffer pointers for write mode after reading. * testsuite/27_io/basic_filebuf/sgetn/char/81395.cc: New. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/27_io/basic_filebuf/sgetn/char/81395.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/fstream.tcc
[Bug tree-optimization/82627] [8 regression] r253809 breaks test cases gcc.dg/graphite/interchange-3.c -7.c, -9.c, and uns-interchange-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82627 seurer at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from seurer at gcc dot gnu.org --- I checked and there were two copies of ISL in the source tree, .16 something and .18. I got rid of the earlier one and rebuilt and those failures went away. Oddly a new one popped up (same revision) but that is probably something else.
[Bug libstdc++/81395] [6/7 Regression] basic_filebuf::overflow recurses and overflows stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Jonathan Wakely --- Fixed for 6.5 and 7.3
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679 --- Comment #5 from joseph at codesourcery dot com --- Probably in grokdeclarator the test for _Atomic-qualified array types should check declspecs->atomic_p rather than atomicp. (The check in the parser in the case of _Atomic (type-name) is fine as-is.)
[Bug target/82683] New: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 Bug ID: 82683 Summary: GCC generates bad code with -tune=thunderx2t99 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Target Milestone: --- Created attachment 42448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42448&action=edit Test case I am compiling the GCC spec 2017 benchmark on aarch64. If I compile it with -tune=thunderxt88 it works and if I compile with -tune=thunderx2t99 it fails. The tune option should affect the speed of a program on different architectures but it should never result in bad code. I have attached a cutdown testcase (compilable but not runnable) to show the problem. In the good case you should see two sxtw sign extend instructions: sxtwx20, w0 cbz x1, .L2 ldr w0, [x1, x20, lsl 2] sxtwx20, w0 // 21 .L2: In the bad case we only get one: sxtwx20, w0 cbz x1, .L2 ldr w0, [x1, x20, lsl 2] .L2 If I insert the missing sxtw by hand everything works fine for me. The sxtw seems to go missing during combine but I do not know why. Notice that in addition to not doing the sxtw, we leave the loaded value in w0 and do not put it in x20 like the good code does. In addition to the -tune argument I am compiling with: -std=c11 -O2 -fno-inline -fno-schedule-insns -fno-schedule-insns2 -fno-strict-aliasing
[Bug libstdc++/82684] New: std::complex template specializations require C99 Complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82684 Bug ID: 82684 Summary: std::complex template specializations require C99 Complex Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: web at cjhanks dot name Target Milestone: --- Tested on Ubuntu 16.04 using GLIBCXX_3.4. The template specializations for std::complex require the presence of the C99 complex type even though the primary class template is designed to work without it. Putting the specializations and forward declarations in an `#if _GLIBCXX_USE_C99_COMPLEX` block appears to allow code to compile as expected. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #7 from seurer at gcc dot gnu.org --- Shouldn't the new test case have been marked XFAIL for powerpc64 and s390? It fails on powerpc64 for sure.
[Bug libstdc++/82685] New: basic_string_view operator""sv(const char*, size_t) should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82685 Bug ID: 82685 Summary: basic_string_view operator""sv(const char*, size_t) should be noexcept Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pavel.kryukov at phystech dot edu Target Milestone: --- `string_view` literal operators should have 'noexcept' specifier according to the C++17 standard: https://github.com/cplusplus/draft/blob/4ba4e9c2c04b7680ac2a56b65c241ec10c427c3f/source/strings.tex#L4611 Currently GCC implements the literal operators via `basic_string_view<_charT>(const _charT*, size_t)` ctor which may throw an exception according to the same standard. https://github.com/gcc-mirror/gcc/blob/0f6374027d3cd77f80f353eb1c2c61c5ad2b6dfd/libstdc%2B%2B-v3/include/std/string_view#L638
[Bug rtl-optimization/82662] ifcvt is not performed on double-word compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82662 --- Comment #1 from uros at gcc dot gnu.org --- Author: uros Date: Mon Oct 23 19:01:38 2017 New Revision: 254020 URL: https://gcc.gnu.org/viewcvs?rev=254020&root=gcc&view=rev Log: PR target/82662 * gcc.target/i386/pr82662.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr82662.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/82662] ifcvt is not performed on double-word compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82662 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|rtl-optimization|target Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from Uroš Bizjak --- Fixed by r254011.
