[Bug target/70110] [6 Regression] ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70110 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Mar 8 08:05:26 2016 New Revision: 234057 URL: https://gcc.gnu.org/viewcvs?rev=234057&root=gcc&view=rev Log: PR target/70110 * config/i386/i386.c (scalar_chain::make_vector_copies, scalar_chain::convert_reg): Call end_sequence in between get_insns and emit_conversion_insns rather than after both calls. * gcc.dg/pr70110.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr70110.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/70110] [6 Regression] ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70110 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
As #c0 mentions, this has been broken also in older releases, and r196781 has
fixed this, and Honza's commit reverted this again.
The thread that leads to this is
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02567.html
Adjusted testcase:
struct S { int f; signed int g : 2; } a[1], c = {5, 1}, d;
short b;
__attribute__((noinline, noclone)) void
foo (int x)
{
if (x != 1)
__builtin_abort ();
}
int
main ()
{
while (b++ <= 0)
{
struct S e = {1, 1};
d = e = a[0] = c;
}
foo (a[0].g);
return 0;
}
[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Component|c |target --- Comment #1 from ktkachov at gcc dot gnu.org --- I'll have a look
[Bug c/70136] New: -march=native causes SIGABRT due to double close of FILE on certain ARM systems (BCM2834, armv8 cortex-a53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70136
Bug ID: 70136
Summary: -march=native causes SIGABRT due to double close of
FILE on certain ARM systems (BCM2834, armv8
cortex-a53)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
gcc 4.9.1 (Raspbian Linux)
gcc 5.3.0 (Arch Linux)
gcc 6-20160306 (Arch Linux)
all crash on Raspberry Pi 3 (BCM2834, armv8 cortex-a53) when using
-march=native compiler flag.
To reproduce:
echo "int main(void) {return0;}" | gcc -c -x c -march=native -
Example output (gcc 5.3.0):
[alarm@alarmp ~]$ echo "int main(void) {return 0;}" | gcc -c -x c -march=native
-
*** Error in `gcc': double free or corruption (!prev): 0x016486d8 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x649a4)[0x76e399a4]
/usr/lib/libc.so.6(+0x6ad2c)[0x76e3fd2c]
/usr/lib/libc.so.6(+0x6b6bc)[0x76e406bc]
/usr/lib/libc.so.6(fclose+0x110)[0x76e2f118]
gcc[0x20898]
gcc[0x1da3c]
gcc[0x1bfb4]
gcc[0x1e484]
gcc[0x1c6a0]
gcc[0x1d4c8]
gcc[0x1e808]
gcc[0x1ed08]
gcc[0x127a0]
gcc[0x12834]
/usr/lib/libc.so.6(__libc_start_main+0x114)[0x76debcf8]
=== Memory map:
0001-000b9000 r-xp b3:02 1201092/usr/bin/gcc
000c8000-000ca000 rw-p 000a8000 b3:02 1201092/usr/bin/gcc
000ca000-000cc000 rw-p 00:00 0
0164-01665000 rw-p 00:00 0 [heap]
76b0-76b21000 rw-p 00:00 0
76b21000-76c0 ---p 00:00 0
76c06000-76c22000 r-xp b3:02 1198730/usr/lib/libgcc_s.so.1
76c22000-76c32000 ---p 0001c000 b3:02 1198730/usr/lib/libgcc_s.so.1
76c32000-76c33000 rw-p 0001c000 b3:02 1198730/usr/lib/libgcc_s.so.1
76c3d000-76dd5000 r--p b3:02 1317130/usr/lib/locale/locale-archive
76dd5000-76efc000 r-xp b3:02 1198747/usr/lib/libc-2.23.so
76efc000-76f0c000 ---p 00127000 b3:02 1198747/usr/lib/libc-2.23.so
76f0c000-76f0e000 r--p 00127000 b3:02 1198747/usr/lib/libc-2.23.so
76f0e000-76f0f000 rw-p 00129000 b3:02 1198747/usr/lib/libc-2.23.so
76f0f000-76f12000 rw-p 00:00 0
76f12000-76f82000 r-xp b3:02 1198805/usr/lib/libm-2.23.so
76f82000-76f91000 ---p 0007 b3:02 1198805/usr/lib/libm-2.23.so
76f91000-76f92000 r--p 0006f000 b3:02 1198805/usr/lib/libm-2.23.so
76f92000-76f93000 rw-p 0007 b3:02 1198805/usr/lib/libm-2.23.so
76f93000-76fb3000 r-xp b3:02 1198581/usr/lib/ld-2.23.so
76fb6000-76fb7000 rw-p 00:00 0
76fc-76fc2000 rw-p 00:00 0
76fc2000-76fc3000 r--p 0001f000 b3:02 1198581/usr/lib/ld-2.23.so
76fc3000-76fc4000 rw-p 0002 b3:02 1198581/usr/lib/ld-2.23.so
7e828000-7e849000 rw-p 00:00 0 [stack]
7eede000-7eedf000 r-xp 00:00 0 [sigpage]
7eedf000-7eee r--p 00:00 0 [vvar]
7eee-7eee1000 r-xp 00:00 0 [vdso]
-1000 r-xp 00:00 0 [vectors]
Aborted (core dumped)
Reproduced on:
Arch Linux Arm for Raspberry Pi 3
uname -a
Linux alarmpi 4.1.19-2-ARCH #1 SMP Sat Mar 5 22:22:01 MST 2016 armv7l GNU/Linux
cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 76.80
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4
processor : 1
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 76.80
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4
processor : 2
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 76.80
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4
processor : 3
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 76.80
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4
Hardware: BCM2709
Revision: a02082
Serial :
Host Compiler:
[alarm@alarmpi ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: /build/gcc/src/gcc-5-20160209/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/
[Bug driver/70132] ARM -mcpu=native can cause a double free abort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||andrewm.roberts at sky dot com --- Comment #1 from ktkachov at gcc dot gnu.org --- *** Bug 70136 has been marked as a duplicate of this bug. ***
[Bug c/70136] -march=native causes SIGABRT due to double close of FILE on certain ARM systems (BCM2834, armv8 cortex-a53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70136 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from ktkachov at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 70132 ***
[Bug driver/70132] ARM -mcpu=native can cause a double free abort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed by inspecting the code. The fix should be easy
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
On this testcase, the only case (2 times) where operand_equal_p returns 1 on
*MEM_REF even when !types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
is during predcom, one argument is the whole a:
unit size
align 32 symtab 0 alias set 2 canonical type 0x718171f8 fields
context
pointer_to_this chain >
DI size unit size
align 32 symtab 0 alias set 2 canonical type 0x718173f0
domain
DI size unit size
align 64 symtab 0 alias set -1 canonical type 0x71735930
precision 64 min max >
pointer_to_this >
arg 0
public unsigned DI size unit size
align 64 symtab 0 alias set -1 canonical type 0x7183f3f0>
constant
arg 0
used public static common DI file pr70127.c line 1 col 39 size
unit size
align 32 context
chain >>
arg 1
constant 0>>
and the other one its first element:
unit size
align 32 symtab 0 alias set 2 canonical type 0x718171f8
fields
SI file pr70127.c line 1 col 16
size
unit size
align 32 offset_align 128
offset
bit offset context
chain > context
pointer_to_this chain >
arg 0
public unsigned DI size unit size
align 64 symtab 0 alias set -1 canonical type 0x7183f3f0>
constant
arg 0
used public static common DI file pr70127.c line 1 col 39 size
unit size
align 32 context
chain >>
arg 1
constant 0>
pr70127.c:17:13 start: pr70127.c:17:11 finish: pr70127.c:17:22>
The first one is base object from
a[0] = c;
stmt and the second one from
e$g_20 = MEM[(struct S[1] *)&a].g;
(in the other call the first stmt is e = a[0]; and the second one is the same).
Looking at the tree dumps, I see weirdo behavior in early SRA (CCing Martin),
where it changes:
e.f = 1;
e.g = 1;
a[0] = c;
e = a[0];
d = e;
e ={v} {CLOBBER};
into:
e$f_4 = 1;
e$g_18 = 1;
a[0] = c;
e = a[0];
e$f_17 = MEM[(struct S[1] *)&a];
e$g_19 = MEM[(struct S[1] *)&a].g;
MEM[(struct S *)&e] = e$f_17;
e.g = e$g_19;
d = e;
e ={v} {CLOBBER};
(the weird thing is that e = a[0] assignment remains, and then it is done once
again for each element).
And then the effect of the (IMHO broken, but I haven't seen the IRC discussion
Honza refers to) operand_equal_p change in predcom is:
:
+ a__g_lsm0.13_36 = BIT_FIELD_REF ;
:
# prephitmp_16 = PHI <_24(4), _6(6)>
a[0] = c;
e = a[0];
e_1 = MEM[(struct S[1] *)&a];
- e$g_20 = MEM[(struct S[1] *)&a].g;
+ e$g_20 = a__g_lsm0.13_36;
MEM[(struct S *)&e] = e_1;
e.g = e$g_20;
d = e;
So, shall we revert the operand_equal_p change (wonder why the pr56635.C test
now passes?), or change initialize_data_dependence_relation to also check
types_compatible_p next to operand_equal_p, or change something in predcom?
What about the SRA case?
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |6.0 --- Comment #4 from Jakub Jelinek --- The difference in *.pcom dump between operand_equal_p with types_compatible_p and without is: (compute_affine_dependence stmt_a: a[0] = c; stmt_b: e$g_20 = MEM[(struct S[1] *)&a].g; -) -> dependence analysis failed +(analyze_overlapping_iterations + (chrec_a = 0) + (chrec_b = 32) +(analyze_ziv_subscript +) + (overlap_iterations_a = no dependence) + (overlap_iterations_b = no dependence)) +) -> no dependence and similarly with the e = a[0]; stmt.
[Bug tree-optimization/70137] New: internal compiler error: in add_phi_arg_for_new_expr, at graphite-isl-ast-to-gimple.c:2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70137
Bug ID: 70137
Summary: internal compiler error: in add_phi_arg_for_new_expr,
at graphite-isl-ast-to-gimple.c:2331
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: spop at gcc dot gnu.org
Target Milestone: ---
The following testcase ICEs for my on aarch64 with ISL 0.15 with -Ofast
-floop-interchange:
int a, b, c, e, f, g;
int d[6];
void
fn1 ()
{
long h;
char i;
for (; g; g++)
{
c = 0;
for (; c <= 5; c++)
{
char *j = (char *)&e;
short *k = (short *)&f;
i = a + g;
h = i ?: b % i;
*j = h;
*k ^= d[c];
}
}
}
mycrash.c: In function 'fn1':
mycrash.c:4:1: internal compiler error: in add_phi_arg_for_new_expr, at
graphite-isl-ast-to-gimple.c:2331
fn1 ()
^~~
0x105f862 translate_isl_ast_to_gimple::add_phi_arg_for_new_expr(tree_node**,
tree_node**, edge_def*, edge_def*, gphi*, gphi*, basic_block_def*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2331
0x1060007 translate_isl_ast_to_gimple::copy_cond_phi_args(gphi*, gphi*,
vec, bool)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2470
0x10623d1 translate_isl_ast_to_gimple::copy_cond_phi_nodes(basic_block_def*,
basic_block_def*, vec)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2506
0x1062d9e
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2788
0x106355b
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:935
0x106370b translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1039
0x1063c22 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:964
0x1063721 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1043
0x1063839 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:685
0x1063b81 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:854
0x10636df translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1032
0x1063c22 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:964
0x1063721 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1043
0x10641c2 graphite_regenerate_ast_isl(scop*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:3185
0x105b870 graphite_transform_loops()
$SRC/gcc/graphite.c:329
0x105b9d0 graphite_transforms
$SRC/gcc/graphite.c:356
0x105b9d0 execute
$SRC/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/70138] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138
Bug ID: 70138
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-O3 only in both 32-bit and 64-bit modes.
It should be a 6 regression.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160307 (experimental) [trunk revision 234026] (GCC)
$ gcc-trunk -O3 abc.c
$ ./a.out
Aborted (core dumped)
$ gcc-trunk abc.c
$ ./a.out
$ cat abc.c
double u[1782225];
int a, b, d, e;
static void foo(int *p1) {
double c = 0.0;
for (; a < 1335; a++) {
b = 0;
for (; b < 1335; b++)
c = c + u[a + 1335 * a];
u[1336 * a] *= 2;
}
*p1 = c;
}
void abort();
int main() {
for (; d < 1782225; d++)
u[d] = 2;
foo(&e);
if (e != 3564450)
abort();
}
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||mpolacek at gcc dot gnu.org Known to work||5.3.0 Target Milestone|--- |6.0 Summary|wrong code at -O3 on|[6 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu Ever confirmed|0 |1 Known to fail||6.0 --- Comment #1 from Marek Polacek --- Confirmed. Bisecting...
[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-03-08 Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- You're using a Linaro GCC, please report the problem to them. -mtune=native should not be getting rewritten to an -march option and I don't see that happening with the /proc/cpuinfo contents you provided. I see it rewritten to -mtune=cortex-a53. The malformed -march option should not be getting passed down to the assembler as of commit r227028 on trunk. I can't reproduce this with a recent trunk. Can you please try with a recent clean snapshot from trunk?
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138 --- Comment #2 from Marek Polacek --- r229172: commit 71de77d8ba195e98400cd3fd2498e1c2c82a7ed1 Author: rguenth Date: Thu Oct 22 13:33:17 2015 + 2015-10-22 Richard Biener PR tree-optimization/19049 PR tree-optimization/65962 * tree-vect-data-refs.c (vect_analyze_group_access_1): Fall back to strided accesses if single-element interleaving doesn't work.
[Bug tree-optimization/70128] Linux kernel div patching optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128
Marcin Juszkiewicz changed:
What|Removed |Added
CC||mjuszkiewicz at redhat dot com
--- Comment #9 from Marcin Juszkiewicz ---
Nicolas Pitre (author of kernel patch) wrote to me:
OK. I played with the reduced test case a bit. Here's an even smaller
test case you could add to the bug entry:
extern void bar(void);
void foo(void)
{
unsigned long fn_addr = ((unsigned long)&bar) & 3;
((unsigned int *)fn_addr)[0] = 5;
((unsigned int *)fn_addr)[1] = 6;
}
The generated assembly is:
ldr r3, .L2
mov r2, #6
and r3, r3, #3
str r2, [r3, #4]
bx lr
.L3:
.align 2
.L2:
.word bar
As you can see, the value 5 is dropped.
Let's hope gcc will be fixed.
[Bug tree-optimization/70128] Linux kernel div patching optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128 --- Comment #11 from Jakub Jelinek --- (In reply to Marcin Juszkiewicz from comment #9) > Nicolas Pitre (author of kernel patch) wrote to me: > As you can see, the value 5 is dropped. > > Let's hope gcc will be fixed. This assumes this is a gcc bug, which is not something that has been agreed on. The code is not valid C, and the only question we are discussing is whether we want to accept it as an extension with -fno-strict-aliasing, or not. Because at least GCC 4.6 to current trunk behave this way, I strongly believe the kernel needs to be adjusted, because even if we decide now we want to accept it as extension, there are 5 major releases of gcc that behave this way.
[Bug tree-optimization/70128] Linux kernel div patching optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #10 from Marek Polacek ---
It looks like such code really calls for using the asm("") stuff.
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #17 from john.frankish at outlook dot com --- This is perhaps worse than I thought - I went back and re-compiled libsigc++, glibmm, atkmm, cairomm, pangomm and gtkmm using gcc-5.2.0 without "-flto -fuse-linker-plugin". I then compiled inkscape-0.91 again and it fails at the final linking stage in a similar fashion as that when I compiled all of the above using lto: CXXLDinkscape widgets/gradient-selector.o: In function `Gtk::TreeViewColumn::TreeViewColumn(Glib::ustring const&, Gtk::TreeModelColumn const&)': gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x29): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x65): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x81): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x91): undefined reference to `vtable for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x9a): undefined reference to `vtable for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0xa8): undefined reference to `vtable for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0xda): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0xef): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x104): undefined reference to `VTT for Gtk::TreeViewColumn' ... input.cpp:(.text._ZN3Gtk14TreeViewColumnC1IN4Glib6RefPtrIN3Gdk6PixbufERKNS2_7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IN4Glib6RefPtrIN3Gdk6PixbufERKNS2_7ustringERKNS_15TreeModelColumnIT_EE]+0x104): undefined reference to `VTT for Gtk::TreeViewColumn' collect2: error: ld returned 1 exit status Makefile:6891: recipe for target 'inkscape' failed make[3]: *** [inkscape] Error 1 make[3]: Leaving directory '/usr/src/inkscape-0.91/src' Makefile:5048: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/usr/src/inkscape-0.91/src' Makefile:1401: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/usr/src/inkscape-0.91' Makefile:1096: recipe for target 'all' failed make: *** [all] Error 2
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 --- Comment #5 from Jakub Jelinek --- If I replace all a[1] and a[0] with a in the testcase, then it works fine; the thing is that dr_analyze_indices adds DR_ACCESS_FNS elements for each handled_component_p level, so if we have a[0], it has DR_NUM_DIMENSIONS == 1 - constant 0. If we have ((struct S *)&a).g, it has also DR_NUM_DIMENSIONS == 1 - constant 32 - the bit offset of field g. The problem is that in each case these are counting something different, in one case it is offset into the array, in the other case it is field bitoffset. But, as operand_equal_p returned non-zero, because it didn't compare the types, tree-data-ref.c thinks both access fns count the same thing. With single element arrays and/or fields that have the same size as the containing struct/union the access fns can differ substantially.
[Bug c++/70139] New: -fno-ellide-constructor makes static std::regex to throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
Bug ID: 70139
Summary: -fno-ellide-constructor makes static std::regex to
throw
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Following code:
#include
namespace
{
const std::regex HTTP_START_HEADER_RE("^HTTP\\/\\d.\\d\\s+(\\d+)\\s+([\\w\\t
]+)\\r\\n");
}
int main()
{
}
compiles and works perfectly with GCC 4.9 with and without
-fno-ellide-constructor.
However, with GCC 5.3.1 20160216 and with -fno-ellide-constructor it got
aborted due to exception:
terminate called after throwing an instance of 'std::regex_error'
what(): regex_error
GDB backtrace:
(gdb) bt
#0 0x003ceb632625 in raise () from /lib64/libc.so.6
#1 0x003ceb633e05 in abort () from /lib64/libc.so.6
#2 0x77cbda2d in __gnu_cxx::__verbose_terminate_handler() () from
gcc5/lib/libstdc++.so.6
#3 0x77cbba86 in ?? () from gcc5/lib/libstdc++.so.6
#4 0x77cbbad1 in std::terminate() () from gcc5/lib/libstdc++.so.6
#5 0x77cbbce8 in __cxa_throw () from gcc5/lib/libstdc++.so.6
#6 0x77ce4635 in
std::__throw_regex_error(std::regex_constants::error_type) ()
fromgcc5/lib/libstdc++.so.6
#7 0x004085bb in
std::__detail::_BracketMatcher, false,
false>::_M_add_character_class (this=0x7fffd920, __s=..., __neg=)
at gcc5/include/c++/5.3.1/bits/regex_compiler.h:431
#8 0x0040c580 in std::__detail::_Compiler
>::_M_expression_term (this=this@entry=0x7fffe280,
__last_char=..., __matcher=...)
at gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:507
#9 0x0040e1a2 in std::__detail::_Compiler
>::_M_insert_bracket_matcher (this=this@entry=0x7fffe280,
__neg=)
at gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:427
#10 0x0040f796 in std::__detail::_Compiler
>::_M_bracket_expression (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:355
#11 0x00410ec6 in std::__detail::_Compiler
>::_M_atom (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:341
#12 0x004113f8 in std::__detail::_Compiler
>::_M_term (this=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:139
#13 std::__detail::_Compiler >::_M_alternative
(this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:121
#14 0x00411559 in std::__detail::_Compiler
>::_M_disjunction (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:97
#15 0x004110a6 in std::__detail::_Compiler
>::_M_atom (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:334
#16 0x004113f8 in std::__detail::_Compiler
>::_M_term (this=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:139
#17 std::__detail::_Compiler >::_M_alternative
(this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:121
#18 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#19 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#20 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#21 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#22 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#23 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#24 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#25 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#26 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#27 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#28 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/include/c++/5.3.1/bits/regex_compiler.tcc:124
#29 0x00411364 in std::__detail::_Compiler
>::_M_alternative (this=this@entry=0x7fffe280) at
gcc5/inclu
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 37895 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37895&action=edit gcc6-pr70127.patch Given this I think it is safest to restore the types_compatible_p check for initialize_data_dependence_relation (which has been done before inside of operand_equal_p). Perhaps for GCC 7 we might slightly change that, e.g. to do a less strict type compatibility comparison, but unless we stop adding access fn elements for ARRAY_REFs for single element arrays (but, what to do about trailing arrays that could be flexible-like) and for fields that cover the whole struct, we need to at least verify the same levels of ARRAY_TYPEs and same levels of RECORD_TYPEs with field decl covering the whole struct.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/70094] Missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- > Confirmed. This is quite hard for us as GIMPLE doesn't allow arbitrary > constant literals as function arguments and at RTL we can't remove the stack > local anymore. RTL DSE theoretically has the machinery to do it though. Does your remark hint at a specific issue?
[Bug middle-end/26461] liveness of thread local references across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461 --- Comment #11 from Giovanni Deretta --- In the last few years it has been clear that threads are not enough and coroutines have seen a resurgence in many languages. Go, which is directly supported by GCC, make them a first class construct; boost has had them for a while (and it is affecte by this issue); the HPX library uses them to great effects for HPC work; it even seem that C++ standard will eventually include them officially [1]. Any chance this resolution will be reviewed? Note that an opt-in flag would be enough, and it should have very little effect on x86, where the compiler doesn't bother to cache TLS address computations, as it has fast TLS access, unless the address is explicitly taken. [1] If MS get it its way, stackless coroutines shouldn't be affected by this issue as the switch point can be statically identified by the compiler. But there is still a chance that we will get proper non-crippled stackfull coroutines.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #2 from Marek Polacek --- -fsanitize=bounds is enough.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #3 from Marek Polacek --- Would be nice to have this reduced :/. Markus, are you by any chance reducing this one or shall I?
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #4 from Markus Trippelsdorf --- (In reply to Marek Polacek from comment #3) > Would be nice to have this reduced :/. Markus, are you by any chance > reducing this one or shall I? I'm on it... Thanks.
[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70138
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly cleaned up testcase from creduce mess:
double u[1782225];
static void
foo (int *x)
{
double c = 0.0;
int a, b;
for (a = 0; a < 1335; a++)
{
for (b = 0; b < 1335; b++)
c = c + u[1336 * a];
u[1336 * a] *= 2.0;
}
*x = c;
}
int
main ()
{
int d, e;
for (d = 0; d < 1782225; d++)
u[d] = 2.0;
foo (&e);
if (e != 3564450)
__builtin_abort ();
return 0;
}
[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195 --- Comment #18 from Zdenek Sojka --- (In reply to Bernd Schmidt from comment #17) > Is this reproducible on trunk? What are the exact flags required to pass to > cc1? I'm not getting a difference in REG_EQUIV notes between -fdce and > -fno-dce. Yes, it still fails in trunk (r234047). cc1 commandline is: /repo/gcc-trunk/binary-trunk-234047-checking-yes-rtl-df-nographite-powerpc64/libexec/gcc/powerpc64-unknown-linux-gnu/6.0.0/cc1 -quiet -iprefix /repo/gcc-trunk/binary-trunk-234047-checking-yes-rtl-df-nographite-powerpc64/bin/../lib/gcc/powerpc64-unknown-linux-gnu/6.0.0/ -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix testcase.c -quiet -dumpbase testcase.c -auxbase testcase -O3 -fno-dce -fno-forward-propagate -o /tmp/ccnx8kGq.s
[Bug middle-end/70140] New: Inefficient expansion of __builtin_mempcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140 Bug ID: 70140 Summary: Inefficient expansion of __builtin_mempcpy Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: wdijkstr at arm dot com Target Milestone: --- The expansion of __builtin_mempcpy is inefficient on many targets (eg. AArch64, ARM, PPC). The issue is due to not using the same expansion options that memcpy uses in builtins.c. As a result GCC6 produces for __builtin_mempcpy(x, y, 32): PPC: 0: 38 a0 00 20 li r5,32 4: 48 00 00 00 b 4 4: R_PPC_REL24 mempcpy 8: 60 00 00 00 nop c: 60 42 00 00 ori r2,r2,0 AArch64: mov x2, 32 b mempcpy A second issue is that GCC always calls mempcpy. mempcpy is not supported or implemented efficiently in many (if not most) library/target combinations. GLIBC only has 3 targets which implement an optimized mempcpy, so GLIBC currently inlines mempcpy into memcpy by default unless a target explicitly disables this. It seems better to do this in GCC so it works for all libraries.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #5 from Markus Trippelsdorf --- Created attachment 37896 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37896&action=edit somewhat reduced testcase Creduce has a hard time reducing these Boost meta libs.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #6 from Marek Polacek --- Ugh, a combination of a nested function and a VLA-in-a-struct. We're trying to allocate variable-sized temporary. Guess that's a wrong thing to do, we should generate __builtin_alloca or __builtin_alloca_with_align when expanding the call.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #6 from Marek Polacek --- So in finish_static_assert without ubsan we have: boost::detail::operators::operator==, boost::tuple >, boost::tuple >, boost::tuple::_, boost::type_impl::_>, boost::range, boost::tuple > >, boost::tuple, boost::tuple >, boost::tuple >, boost::tuple::_, boost::type_impl::_>, boost::range, boost::tuple > > > (TARGET_EXPR , TARGET_EXPR ::operator(), boost::tuple >, boost::tuple >, boost::tuple::_, boost::type_impl::_>, boost::range, boost::tuple > > (&make_tuple, TARGET_EXPR ::operator(), boost::tuple > (&make_tuple, TARGET_EXPR ::operator() (&make_tuple, 1, 2, 3)>, TARGET_EXPR ::operator() (&make_tuple, 120, 121, 122)>)>, TARGET_EXPR ::operator() > (&make_tuple, TARGET_EXPR ;, <<< Unknown tree: empty_class_expr >>>;)>, TARGET_EXPR ::operator()::_, boost::type_impl::_>, boost::range, boost::tuple > (&make_tuple, TARGET_EXPR , TARGET_EXPR ;, <<< Unknown tree: empty_class_expr >>>;, TARGET_EXPR ::operator() (&make_tuple, 1.23405684341886080801486968994140625e+2, 0)>)>)>) which gets folded to 1 and with -fsanitize=bounds: boost::detail::operators::operator==, boost::tuple >, boost::tuple >, boost::tuple::_, boost::type_impl::_> > >, boost::tuple, boost::tuple >, boost::tuple >, boost::tuple::_, boost::type_impl::_>, boost::range, boost::tuple > > > (TARGET_EXPR , TARGET_EXPR ::operator(), boost::tuple >, boost::tuple >, boost::tuple::_, boost::type_impl::_>, boost::range, boost::tuple > > (&make_tuple, TARGET_EXPR ::operator(), boost::tuple > (&make_tuple, TARGET_EXPR ::operator() (&make_tuple, 1, 2, 3)>, TARGET_EXPR ::operator() (&make_tuple, 120, 121, 122)>)>, TARGET_EXPR ::operator() > (&make_tuple, TARGET_EXPR ;, <<< Unknown tree: empty_class_expr >>>;)>, TARGET_EXPR ::operator()::_, boost::type_impl::_>, boost::range, boost::tuple > (&make_tuple, TARGET_EXPR , TARGET_EXPR ;, <<< Unknown tree: empty_class_expr >>>;, TARGET_EXPR ::operator() (&make_tuple, 1.23405684341886080801486968994140625e+2, 0)>)>)>) which gets folded to 0. That doesn't tell much, eh.
[Bug c/70085] False positive -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70085 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- The warning is gone; marking as fixed.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Maybe we need to treat functions returning VL types similarly to how we treat functions returning C++ non-PODs, make sure the lhs of the call is always present.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093
--- Comment #8 from Marek Polacek ---
Probably. Because this doesn't (to my surprise) ICE:
void
foo (int n)
{
struct S { int a[n]; };
struct S
fn (void)
{
struct S s;
s.a[0] = 1;
return s;
}
struct S x;
x = fn (); // just "fn();" ICEs
}
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #7 from Thomas Braun ---
> The three cases (L, P, R) where GCC is "better" is actually non-conforming.
Could you elaborate on that?
For example case L is:
X nrvo_two_different_tern()
{
trace t("nrvo_two_different_tern");
const bool param = true;
X a, b;
return param ? a : b;
}
which always returns a.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #9 from Marek Polacek --- So that would mean creating a TARGET_EXPR in the C FE I suppose...
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #8 from TC --- The standard specifies when copy elision is allowed (http://eel.is/c++draft/class.copy#31). "return param ? a : b;" is not one of them. "param ? a : b" is hardly "the name of a non-volatile automatic object..."
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #7 from Markus Trippelsdorf --- This what you get when you implement functional programming for C++ at compile time.
[Bug target/70123] [6 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70123 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #3 from Bernd Schmidt --- Investigating.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #8 from Jakub Jelinek --- I see -fsanitize=bounds replaces bs[i++] with bs[UBSAN_BOUNDS (0B, SAVE_EXPR , 4), SAVE_EXPR ] I believe the constexpr folding is properly removing the UBSAN_BOUNDS stuff, but the problem is most likely in the SAVE_EXPR. At least, if I by hand replace bs[i++] with just bs[SAVE_EXPR ] then the static assertion fails too.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #39 from Matthew Woehlke --- (In reply to Jonathan Wakely from comment #38) > (In reply to Matthew Woehlke from comment #37) > > [[fallthrough]] was approved for C++17 [...] It's a shame that gcc is behind > > the curve here. > > It was approved less than a week ago. So? People have been asking for it for at least *13+ years* (this report was opened in August 2002). Compared to clang which has had this feature for some years already, gcc is lagging. I'm also not sure how to react to "less than a week ago". The *wording* was approved last week. The *feature* was approved (by EWG¹, which is the approval that matters most for something like this) at Kona, a few months back. If you're claiming you can't implement without wording, that's one thing. If you didn't see it coming, then you didn't do your homework. (¹ ...about as strongly as you ever see out of EWG, at that: SF=15, F=5, N=0, A=0, SA=0) > It will get implemented. I do hope so, but given that a) it hasn't been implemented in over a decade of people asking for it, and b) isn't actually required for conformance, I'm not holding my breath.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |6.0
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 37897 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37897&action=edit gcc6-pr70135.patch Untested fix. The first testcase shows this is not really specific to sanitizer.
[Bug testsuite/70009] test case libgomp.oacc-c-c++-common/vprop.c fails starting with its introduction in r233607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009 --- Comment #6 from cesar at gcc dot gnu.org --- Created attachment 37898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37898&action=edit test fix I've tested this patch on an arm target and it passes now. All this patch does is make the type macro signed. So the intent behind this test was to make sure that vector propagation works on integral types less than 32-bits on nvptx targets. I was using a signed values explicitly because the nvptx backend uses a shuffle instruction to propagate variables, and that instruction only takes unsigned registers. So the signed values added a little more test coverage. I didn't realize that chars aren't signed on targets. This patch should fix this issue.
[Bug testsuite/70009] test case libgomp.oacc-c-c++-common/vprop.c fails starting with its introduction in r233607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009 --- Comment #7 from Jakub Jelinek --- (In reply to cesar from comment #6) > Created attachment 37898 [details] > test fix > > I've tested this patch on an arm target and it passes now. All this patch > does is make the type macro signed. > > So the intent behind this test was to make sure that vector propagation > works on integral types less than 32-bits on nvptx targets. I was using a > signed values explicitly because the nvptx backend uses a shuffle > instruction to propagate variables, and that instruction only takes unsigned > registers. So the signed values added a little more test coverage. I didn't > realize that chars aren't signed on targets. > > This patch should fix this issue. Preapproved for trunk.
[Bug c++/70141] New: [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Bug ID: 70141
Summary: [6.0 regression] template parameter not deducible in
partial specialization of template inside template
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kholdstare0.0 at gmail dot com
Target Milestone: ---
Created attachment 37899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37899&action=edit
Preprocessed source
The code below works on gcc 4.8, 5.2, and clang 3.6, but fails to compile on
gcc 6:
template
struct outer
{
template
struct inner
{
};
};
template
struct is_inner_for
{
template
struct predicate
{
static constexpr bool value = false;
};
template
struct predicate::template inner>
{
static constexpr bool value = true;
};
};
static_assert(
is_inner_for::template predicate<
outer::inner
>::value,
"Yay!"
);
The commandline:
g++ -std=c++1y -c main.cpp
Here is the error:
main.cpp:22:9: error: template parameters not deducible in partial
specialization:
struct predicate::template inner> :
std::true_type
^~~
main.cpp:22:9: note: 'U'
main.cpp:26:1: error: static assertion failed: Yay!
static_assert(
^
Another thing I noticed is that *I get the error even if I don't use the
"is_inner_for" template*. It looks like some rule that gets applied before
template instantiation - maybe it's too strict...
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r229628.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #40 from Manuel López-Ibáñez --- (In reply to Matthew Woehlke from comment #39) > So? People have been asking for it for at least *13+ years* (this report was > opened in August 2002). Compared to clang which has had this feature for > some years already, gcc is lagging. Unfortunately, Clang has more developers working on just its C-family FE than GCC has developers working on all C-family, Ada, Fortran FEs plus middle-end (optimizations, LTO) and all its back-ends combined. Thus, lagging behind Clang w.r.t. C++ features is normal. What is your solution? (In fact, it is only a testament to how hard GCC C++ developers work that the gap is not much wider.) > I do hope so, but given that a) it hasn't been implemented in over a decade > of people asking for it, and b) isn't actually required for conformance, I'm > not holding my breath. Features get implemented when someone implements them. People implement features because a) they get paid for it (are you paying someone who is not delivering?) or b) they have the time and motivation to do it (do you think this is important enough to dedicate your time to implement this?). If the answer to those questions is no, then this cannot be such a critical feature, since nobody has bothered to get it implemented (or paid to do so) in the last decade.
[Bug c++/70142] New: Class members not in scope in exception-specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70142
Bug ID: 70142
Summary: Class members not in scope in exception-specification
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
The following code fails to compile, with an error about y not being in scope:
struct X {
X() noexcept(noexcept(y+1)) { }
int y;
};
int main() { }
However, [basic.scope.class]/1 says that the scope of class members includes
exception-specifications.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
--- Comment #4 from Markus Trippelsdorf ---
I'm not sure this is a compiler bug at all.
Even clang warns:
foo.ii:10:32: warning: class template partial specialization contains a
template parameter that cannot be deduced; this partial specialization will
never be used
template struct predicate::template inner>
{
^~~
foo.ii:10:22: note: non-deducible template parameter 'U'
template struct predicate::template inner>
{
^
1 warning generated.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #3 from Alexander Kondratskiy --- Sorry, I take the "fishy" comment back. I'm not familiar enough with the code.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P3 --- Comment #5 from Jakub Jelinek --- Setting back P3, until we agree if this is a compiler bug or not.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #2 from Alexander Kondratskiy --- Looking at the diffs in r229628 linked by Jakub, I find the changes to lines 8791 and 8793 in pt.c to be kinda fishy: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/pt.c?r1=229628&r2=229627&pathrev=229628
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||trippels at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #6 from Markus Trippelsdorf ---
template struct X {};
template struct X {};
is another example were clang just warns, but an error is clearly indicated.
Closing bug as invalid.
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
--- Comment #5 from Vladimir Makarov ---
(In reply to Anton Blanchard from comment #0)
> I hit the following ICE when building eigen:
>
> # g++ -O3 -c test2.cpp
> test2.cpp: In function ‘void fn3(Matrix)’:
> test2.cpp:59:1: error: unable to generate reloads for:
> }
> ^
> (jump_insn 17 12 18 2 (parallel [
> (set (pc)
> (if_then_else (ne (reg:DI 3 3)
> (const_int 1 [0x1]))
> (label_ref 25)
> (pc)))
> (set (reg:DI 156 [ _4 ])
> (plus:DI (reg:DI 3 3)
> (const_int -1 [0x])))
> (clobber (reg:CC 172))
> (clobber (reg:DI 173))
> ]) test2.cpp:46 775 {*ctrdi_internal1}
> (expr_list:REG_UNUSED (reg:DI 173)
> (expr_list:REG_UNUSED (reg:CC 172)
> (expr_list:REG_DEAD (reg:DI 3 3)
> (int_list:REG_BR_PROB 2900 (nil)
> -> 25)
> test2.cpp:59:1: internal compiler error: in curr_insn_transform, at
> lra-constraints.c:3552
> 0x10a711b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
> ../../gcc/gcc/rtl-error.c:108
> 0x1093d313 curr_insn_transform
> ../../gcc/gcc/lra-constraints.c:3552
> 0x1093e4df lra_constraints(bool)
> ../../gcc/gcc/lra-constraints.c:4494
> 0x10923513 lra(_IO_FILE*)
> ../../gcc/gcc/lra.c:2286
> 0x108c3ffb do_reload
> ../../gcc/gcc/ira.c:5396
> 0x108c3ffb execute
> ../../gcc/gcc/ira.c:5580
Sorry, I can not understand. As I know PPC64 uses the reload pass by default.
It will not use LRA as default for GCC6. Although the dump indicates LRA using
I don't see -mlra on your commnad line.
Should I use -mlra to reproduce the bug?
In any case, it will be a lower priority task for me because LRA is not a
default for ppc64. May be I can start to work on it in a week or two.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093
--- Comment #10 from Marek Polacek ---
Well, seems like the following fixes the ICEs! I'm still not quite sure if
this makes sense at all, but the C FE testsuite still passes. Needs a comment
and a bunch of tests.
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -3068,6 +3068,15 @@ build_function_call_vec (location_t loc, vec
arg_loc,
result = build_call_array_loc (loc, TREE_TYPE (fntype),
function, nargs, argarray);
+ if (fundecl
+ && decl_function_context (fundecl)
+ && variably_modified_type_p (TREE_TYPE (fntype), NULL_TREE))
+{
+ tree tmp = create_tmp_var_raw (TREE_TYPE (fntype));
+ result = build4 (TARGET_EXPR, TREE_TYPE (fntype), tmp, result,
NULL_TREE,
+ NULL_TREE);
+}
+
if (VOID_TYPE_P (TREE_TYPE (result)))
{
if (TYPE_QUALS (TREE_TYPE (result)) != TYPE_UNQUALIFIED)
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
--- Comment #7 from Alexander Kondratskiy ---
To add some color, maybe this is related to non-deduced contexts from
14.8.2.5p5 in the standard:
The non-deduced contexts are:
— The nested-name-specifier of a type that was specified using a qualified-id.
So I agree that this should not work for code like the following, where the T
in outer is being deduced:
template
struct outer
{
template
struct inner
{
};
};
// doesn't work, because non-deduced context
template
void foo(typename outer::template inner val)
{ }
void bar()
{
foo(typename outer::template inner{});
}
But in the situation mentioned here, outer is a concrete type, so anything
within it should be deducible. If I get rid of the template parameter on outer,
everything works fine, and the following code compiles:
// no outer template!
struct outer
{
template
struct inner
{
};
};
struct is_inner_for
{
template
struct predicate
{
static constexpr bool value = false;
};
template
struct predicate>
{
static constexpr bool value = true;
};
};
static_assert(
is_inner_for::predicate<
outer::inner
>::value,
"Yay!"
);
This simplified case where outer has no template parameter, in my mind should
not be any different from the original problem - it's just that we had a
template parameter but it was fully specified.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #11 from Marek Polacek --- (The decl_function_context is probably redundant since I don't see how a non-nested function could return VM type.)
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
--- Comment #8 from Alexander Kondratskiy ---
I'm sorry Markus, but "clang issues a warning" is not a good enough reason to
mark this invalid. By the same token, the warning in clang could have been
introduced "because gcc issues an error". What happened to independent
implementations?
The example you gave:
template struct X {};
template struct X {};
is not the same situation as I posted originally. Here, the nested type foo is
nested inside a type trying to be deduced. I would never expect this to work,
and I agree with clang that it should be an error
My original example is closer to something like:
struct outer{ template struct foo { }; };
template struct X {};
template struct X> {};
The outer type is concrete here, and in my original example.
Please, take another look.
Thank you.
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #1 from Bill Schmidt --- It's not clear to me from the report whether you have run this only on big-endian systems, or whether little-endian has been tried for Power8 (with -mcpu=power8). Can you please clarify? I ask because the -mcpu=power7 causes the versioned loop to use __builtin_altivec_mask_for_load to do the lvx/lvx/lvsl/vperm trick, whereas with -mcpu=power8 we would just have done unaligned loads. If there is a difference in endian behavior with -mcpu=power8 for BE and LE, that might be a clue to a back end problem.
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #2 from Pat Haugen --- The benchmark behaves the same on BE/LE, passes with -mcpu=power8, fails with -mcpu=power7.
[Bug tree-optimization/27394] double -> char conversion varies with optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394 Bug 27394 depends on bug 28144, which changed state. Bug 28144 Summary: floating point constant -> byte/char/short conversion is wrong for java https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 28144, which changed state. Bug 28144 Summary: floating point constant -> byte/char/short conversion is wrong for java https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2016-03-08 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #7 from Jorn Wolfgang Rennecke --- PR 27394 was closed on the grounds that the code was exhibited undefined behaviour and that alternate facilities had been added in the meantime which mitigate the impact of the inconsistent implemented behaviour on debugging. However, this PR (28144) is about the impact on Java; an updated link to the quoted spec above is: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.3 where it defines the exact behaviour of conversions. The comment at the start of fold_convert_const_int_from_real claims that the code implements the floating point to integer conversion rules required by the Java Language Specification, but due to the problem discussed here, that is not true when it comes to conversion to types narrower than int.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #9 from Markus Trippelsdorf --- There is really no need to take another look. When your testcase generates a warning under clang and also gets rejected by MSVC, it is obvious that there is something wrong with it.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #10 from Alexander Kondratskiy --- My issue is that this code was accepted since gcc 4.8 completely fine. Unless there is a specific line in the standard that prevents this from working, I don't understand how appealing to potential failures in other compilers is a valid argument.
[Bug rtl-optimization/29854] reload_combine looses track of uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854 --- Comment #8 from Jorn Wolfgang Rennecke --- revision 149282: 2009-07-06 J"orn Rennecke Kaz Kojima PR rtl-optimization/30807 * postreload.c (reload_combine): For every new use of REG_SUM, record the use of BASE.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #11 from Markus Trippelsdorf --- (In reply to Alexander Kondratskiy from comment #10) > My issue is that this code was accepted since gcc 4.8 completely fine. > Unless there is a specific line in the standard that prevents this from > working, I don't understand how appealing to potential failures in other > compilers is a valid argument. The standard is available, e.g.: http://eel.is/c++draft/. You may ask on stackoverflow for pointers to the specific line. The burden of proof is on your side. If your testcase would be accepted by all compilers except gcc-6 then you have a valid case.
[Bug target/70010] powerpc: -flto forgets 'no-vsx' function attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70010
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor ---
I'm not an expert but from your description and based on my own testing it
isn't clear to me what you believe is wrong. no-vsx disables the VSX
extensions to Altivec, no-altivec disables all vectorization. In my testing it
seems to behave as expected. For the following reduced test case:
#define vector __attribute__ ((vector_size (16)))
#define no_altivec __attribute__((__target__("no-altivec")))
#define no_vsx __attribute__((__target__("no-vsx")))
vector int a, b, c;
void no_vsx vadd_no_vsx (void) {
c = a + b;
}
void no_altivec vadd_no_altivec (void) {
c = a + b;
}
void vadd (void) {
c = a + b;
}
GCC 5.x emits the following with -O2 (regardless of -flto). AFAICT, none of
the no-vsx instructions are VSX. VSX instructions are used in the unadorned
vadd function which is expected.
<.vadd_no_vsx>:
a70: 60 00 00 00 nop
a74: e9 42 80 38 ld r10,-32712(r2)
a78: 60 00 00 00 nop
a7c: e9 22 80 40 ld r9,-32704(r2)
a80: 7c 00 50 ce lvx v0,0,r10
a84: 60 00 00 00 nop
a88: 7c 20 48 ce lvx v1,0,r9
a8c: e9 22 80 30 ld r9,-32720(r2)
a90: 10 00 08 80 vadduwm v0,v0,v1
a94: 7c 00 49 ce stvxv0,0,r9
a98: 4e 80 00 20 blr
<.vadd_no_altivec>:
(not vectorized)
<.vadd>:
9b0: 60 00 00 00 nop
9b4: e9 42 80 38 ld r10,-32712(r2)
9b8: 60 00 00 00 nop
9bc: e9 22 80 40 ld r9,-32704(r2)
9c0: 7c 00 56 19 lxvw4x vs32,0,r10
9c4: 60 00 00 00 nop
9c8: 7c 20 4e 19 lxvw4x vs33,0,r9
9cc: e9 22 80 30 ld r9,-32720(r2)
9d0: 10 00 08 80 vadduwm v0,v0,v1
9d4: 7c 00 4f 19 stxvw4x vs32,0,r9
9d8: 4e 80 00 20 blr
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #6 from Bill Schmidt --- The title mischaracterizes the problem. There is a problem in IRA, which causes a failure to show up either in LRA or in reload.
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #12 from Alexander Kondratskiy --- Ok, I will ask stackoverflow. Thanks.
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #9 from Jeffrey A. Law --- So if I take my code to renumber SSA_NAMES so they they're consistent irrespective how SSA_NAMEs were recycled and apply that on top of r216304 and r216305 the net result is I get the same code from those two compilers. That argues that ultimately this is another case of SSA_NAME_VERSION differences causing coalescing to make different decisions in a semi-random way which leads to random performance changes. That means this BZ and 68654 are likely manifestations of the same underlying issue. I'm still having some problems with getting consistent results across a larger codebase comparing before/after the SSA_NAME freelist flushing change, so clearly something isn't getting renumbered properly. But it's promising.
[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799 --- Comment #1 from Casey Carter --- This bug is present in both 5.3 and 6.0; it should probably be attached to the friend meta-bug 65608 since it is a "friend" issue.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Tue Mar 8 20:05:21 2016 New Revision: 234064 URL: https://gcc.gnu.org/viewcvs?rev=234064&root=gcc&view=rev Log: PR c++/70135 * constexpr.c (cxx_eval_loop_expr): Forget saved values of SAVE_EXPRs even after the last iteration of the loop. * g++.dg/cpp1y/constexpr-loop4.C: New test. * g++.dg/ubsan/pr70135.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-loop4.C trunk/gcc/testsuite/g++.dg/ubsan/pr70135.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 --- Comment #7 from Anton Blanchard --- Sorry, blame my limited understanding of gcc. It fails with both with and without -mlra.
[Bug c/70143] New: [6 Regression?] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
Bug ID: 70143
Summary: [6 Regression?] false strict-aliasing warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
struct a {
int i;
};
struct b {
struct a a;
int j;
};
int main(void) {
static struct b b;
struct a *ap=(struct a *)&b;
return ((struct b *)&ap->i)->j;
}
---
-Wall -O2
aliasing.c: In function ‘main’:
aliasing.c:11:19: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
return ((struct b *)&ap->i)->j;
^
FAIL:
gcc (GCC) 6.0.0 20160308 (experimental)
gcc-6.0.0-0.15.fc24
gcc-6.0.0-0.15.fc25
PASS:
gcc-6.0.0-0.14.fc24
gcc-5.3.1-2.fc23.x86_64
Pedro Alves said it is a GCC Bug so I am filing it here.
https://sourceware.org/ml/binutils/2016-03/msg00120.html
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment #13 from Barry Revzin ---
Markus - note that clang warns about the specialization, but compiles the
example anyway which actually requires the selection of the supposedly
unselectable specialization.
This example:
template struct X {};
template struct X {};
isn't related, since here T is a non-deduced context (nested-name-specifier),
but OP's example is:
template
struct predicate::template inner>
U is not in the nested-name-specifier, T is... but T isn't being deduced.
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #10 from rguenther at suse dot de --- On March 8, 2016 8:39:34 PM GMT+01:00, law at redhat dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 > >--- Comment #9 from Jeffrey A. Law --- >So if I take my code to renumber SSA_NAMES so they they're consistent >irrespective how SSA_NAMEs were recycled and apply that on top of >r216304 and >r216305 the net result is I get the same code from those two compilers. > >That argues that ultimately this is another case of SSA_NAME_VERSION >differences causing coalescing to make different decisions in a >semi-random way >which leads to random performance changes. > >That means this BZ and 68654 are likely manifestations of the same >underlying >issue. > >I'm still having some problems with getting consistent results across a >larger >codebase comparing before/after the SSA_NAME freelist flushing change, >so >clearly something isn't getting renumbered properly. But it's >promising. How is renumbering promising if it doesn't address the underlying randomness in the coalescing decision?
[Bug tree-optimization/70144] New: g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70144
Bug ID: 70144
Summary: g++ ICE at -O1 and above on valid code on
x86_64-linux-gnu in "copy_reference_ops_from_ref"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The following valid code causes an ICE when compiled with the current g++ trunk
at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It affects versions later than g++-4.7. g++-4.6.4 works fine.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160308 (experimental) [trunk revision 234060] (GCC)
$ g++-trunk abc.cc -c
$ g++-trunk abc.cc -c -O1
abc.cc: In function ‘void fn1()’:
abc.cc:6:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:880
}
^
0xed8283 copy_reference_ops_from_ref
../../gcc/gcc/tree-ssa-sccvn.c:880
0xed93f5 valueize_shared_reference_ops_from_ref
../../gcc/gcc/tree-ssa-sccvn.c:1501
0xed9d0a vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../gcc/gcc/tree-ssa-sccvn.c:2250
0xedd901 visit_reference_op_load
../../gcc/gcc/tree-ssa-sccvn.c:3355
0xedd901 visit_use
../../gcc/gcc/tree-ssa-sccvn.c:3748
0xedff74 process_scc
../../gcc/gcc/tree-ssa-sccvn.c:3968
0xedff74 extract_and_process_scc_for_name
../../gcc/gcc/tree-ssa-sccvn.c:4055
0xedff74 DFS
../../gcc/gcc/tree-ssa-sccvn.c:4107
0xee082d sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-sccvn.c:4574
0x13ac242 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:265
0xee1662 run_scc_vn(vn_lookup_kind)
../../gcc/gcc/tree-ssa-sccvn.c:4685
0xeb3c54 execute
../../gcc/gcc/tree-ssa-pre.c:4895
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ cat abc.cc
void fn1() {
__builtin_constant_p(__builtin_constant_p) ?: ({
unsigned tmp;
tmp;
});
}
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #14 from Alexander Kondratskiy --- Stackoverflow question/answer: http://stackoverflow.com/questions/35875829/template-parameters-not-deducible-in-partial-specialization-in-gcc6-for-a-case
[Bug c++/70145] New: g++-5 and g++-6: invalid code generated for -fno-elide-constructors and constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70145 Bug ID: 70145 Summary: g++-5 and g++-6: invalid code generated for -fno-elide-constructors and constexpr array Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: robert-gcc at debian dot org Target Milestone: --- Created attachment 37900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37900&action=edit Simplified test case The attached simplified code gives different results when compiled with -fno-elide-constructors with g++-6: The expected behaviour: /tmp/tst> g++-6 -Wall -Wextra --std=c++1y ./test.cpp -o test /tmp/tst> ./test; echo $? 1 The incorrect output with -fno-elide-constructors: /tmp/tst> g++-6 -Wall -Wextra --std=c++1y -fno-elide-constructors ./test.cpp -o test /tmp/tst> ./test; echo $? 0 The same issue exists in g++-5. The issue is not reproducible in g++-4.9. Versions: * g++-6: Using built-in specs. COLLECT_GCC=g++-6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/6/lto-wrapper Target: i586-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6-20160228-1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --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-6-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i586-linux-gnu --host=i586-linux-gnu --target=i586-linux-gnu Thread model: posix gcc version 6.0.0 20160228 (experimental) [trunk revision 233789] (Debian 6-20160228-1) COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/lib/gcc/i586-linux-gnu/6/cc1plus -quiet -v -imultiarch i386-linux-gnu -D_GNU_SOURCE ./test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=i586 -auxbase test -std=c++11 -version -o /tmp/user/1000/ccOuyw8T.s GNU C++11 (Debian 6-20160228-1) version 6.0.0 20160228 (experimental) [trunk revision 233789] (i586-linux-gnu) compiled by GNU C version 6.0.0 20160228 (experimental) [trunk revision 233789], GMP version 6.1.0, MPFR version 3.1.4-rc1, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "/usr/include/i386-linux-gnu/c++/6" ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i586-linux-gnu/6/../../../../i586-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/6 /usr/include/i386-linux-gnu/c++/6 /usr/include/c++/6/backward /usr/lib/gcc/i586-linux-gnu/6/include /usr/local/include /usr/lib/gcc/i586-linux-gnu/6/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list. GNU C++11 (Debian 6-20160228-1) version 6.0.0 20160228 (experimental) [trunk revision 233789] (i586-linux-gnu) compiled by GNU C version 6.0.0 20160228 (experimental) [trunk revision 233789], GMP version 6.1.0, MPFR version 3.1.4-rc1, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 36ae62cc8c2555d6cda1e59f88303dae COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=i586' as -v --32 -o /tmp/user/1000/ccJITulw.o /tmp/user/1000/ccOuyw8T.s GNU assembler version 2.26 (i686-linux-gnu) using BFD version (GNU Binutils for Debian) 2.26 COMPILER_PATH=/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/:/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/6/../../../i386-linux-gnu/:/usr/lib/gcc/i586-linux-gnu/6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i586-linux-gnu/6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/lib/gcc/i586-linux-gnu/6/collect2 -plugin /usr/lib/gcc/i586-linux-gnu/6/liblto_plugin.so -plugin
[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68953 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||vries at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/70146] New: missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
Bug ID: 70146
Summary: missed-optimization: i386 hidden references should use
PC32 relocations instead of GOTOFF
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
If I compile:
extern char foo[] __attribute__((visibility("hidden")));
char *get_foo(void)
{
return foo;
}
with gcc -m32 -O2 -fPIC, I get (annocataions trimmed for brevity):
get_foo:
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
lealfoo@GOTOFF(%eax), %eax
ret
I think this should generate:
get_foo:
call__x86.get_pc_thunk.ax
.Lpcbase:
lealfoo-.Lpcbase(%eax), %eax
ret
That would be smaller, faster, and result in fewer relocations and thus less
time spend linking.
[Bug tree-optimization/70045] [6 Regression] ICE error: mismatching comparison operand types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70045 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from vries at gcc dot gnu.org --- Confirmed on x86_64.
[Bug fortran/69520] Implement reversal of -fcheck options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520 --- Comment #6 from Harald Anlauf --- Hi Jerry, do you think my suggested patch could be applied before the 6 release? Thanks, Harald On 01/28/16 00:31, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520 > > Jerry DeLisle changed: > >What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org >Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot > gnu.org > > --- Comment #2 from Jerry DeLisle --- > Harald, if you have commits rights or are interested in getting such, let me > know and we can let you take this one. (Otherwise I will do so) >
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 --- Comment #11 from Markus Trippelsdorf --- Thanks for the quick fix. I can now build the entire boot.hana testsuite with -fsanitize=undefined. One testcase gets miscompiled however: markus@x4 printable % g++ -g -O2 -I/var/tmp/hana/include metafunction.cpp markus@x4 printable % ./a.out markus@x4 printable % clang++ -std=c++14 -g -O2 -fsanitize=undefined -I/var/tmp/hana/include metafunction.cpp markus@x4 printable % ./a.out markus@x4 printable % g++ -g -O2 -fsanitize=undefined -I/var/tmp/hana/include metafunction.cpp markus@x4 printable % gdb ./a.out Reading symbols from ./a.out...done. (gdb) run Starting program: /var/tmp/hana/test/experimental/printable/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00410522 in std::basic_istream >::basic_istream (__vtt_parm=, this=, __in_chrg=) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/istream:606 606 basic_istream() (gdb) bt #0 0x00410522 in std::basic_istream >::basic_istream (__vtt_parm=, this=, __in_chrg=) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/istream:606 #1 std::__cxx11::basic_istringstream, std::allocator >::basic_istringstream (__mode=std::_S_in, __str="2", this=0x7fffd910, __in_chrg=, __vtt_parm=) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/sstream:423 #2 std::__cxx11::regex_traits::value (this=this@entry=0x7fffdb30, __ch=__ch@entry=50 '2', __radix=__radix@entry=10) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.tcc:347 #3 0x004122b7 in std::__cxx11::match_results<__gnu_cxx::__normal_iterator, std::allocator > >, std::allocator, std::allocator > > > > >::format, std::allocator > > > (this=this@entry=0x7fffdd00, __out=..., __fmt_first=, __fmt_first@entry=0x4833f4 "$2<", __fmt_last=__fmt_last@entry=0x4833f7 "", __flags=, __flags@entry=(unknown: 0)) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.tcc:437 #4 0x0044a80c in std::regex_replace, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, std::__cxx11::regex_traits, char> (__out=__out@entry=..., __first=, __first@entry=98 'b', __last=, __e=..., __fmt=__fmt@entry=0x4833f4 "$2<", __flags=__flags@entry=(unknown: 0)) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.tcc:481 #5 0x004055ab in std::regex_replace, char, std::char_traits, std::allocator > (__flags=(unknown: 0), __fmt=0x4833f4 "$2<", __e=..., __s="boost::hana::template_t") at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.h:2366 #6 boost::hana::experimental::print_detail::strip_type_junk (str="boost::hana::template_t") at /var/tmp/hana/include/boost/hana/experimental/printable.hpp:90 #7 0x00403a4d in boost::hana::experimental::print_impl, void>::apply > () at /var/tmp/hana/include/boost/hana/experimental/printable.hpp:228 #8 boost::hana::experimental::print_t::operator() > (this=, t=) at /var/tmp/hana/include/boost/hana/experimental/printable.hpp:74 #9 main () at metafunction.cpp:22
[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #15 from Markus Trippelsdorf --- OK. Thanks. I will let Jason decide.
[Bug tree-optimization/70144] [4.9/5/6 Regression] g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70144 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-08 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|g++ ICE at -O1 and above on |[4.9/5/6 Regression] g++ |valid code on |ICE at -O1 and above on |x86_64-linux-gnu in |valid code on |"copy_reference_ops_from_re |x86_64-linux-gnu in |f" |"copy_reference_ops_from_re ||f" Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r171450.
[Bug sanitizer/70135] -fsanitize=undefined causes static_assert to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70135 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Markus Trippelsdorf --- I will open a new bug for this issue.
[Bug sanitizer/70147] New: testcase from hana testsuite gets miscompiled with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147 Bug ID: 70147 Summary: testcase from hana testsuite gets miscompiled with -fsanitize=undefined Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 37901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37901&action=edit unreduced testcase markus@x4 printable % g++ -g -O2 metafunction.ii markus@x4 printable % ./a.out markus@x4 printable % clang++ -std=c++14 -g -O2 -fsanitize=undefined metafunction.ii markus@x4 printable % ./a.out markus@x4 printable % g++ -g -O2 -fsanitize=undefined metafunction.ii markus@x4 printable % gdb ./a.out Reading symbols from ./a.out...done. (gdb) run Starting program: /var/tmp/hana/test/experimental/printable/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00410522 in std::basic_istream >::basic_istream (__vtt_parm=, this=, __in_chrg=) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/istream:606 606 basic_istream() (gdb) bt #0 0x00410522 in std::basic_istream >::basic_istream (__vtt_parm=, this=, __in_chrg=) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/istream:606 #1 std::__cxx11::basic_istringstream, std::allocator >::basic_istringstream (__mode=std::_S_in, __str="2", this=0x7fffd910, __in_chrg=, __vtt_parm=) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/sstream:423 #2 std::__cxx11::regex_traits::value (this=this@entry=0x7fffdb30, __ch=__ch@entry=50 '2', __radix=__radix@entry=10) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.tcc:347 #3 0x004122b7 in std::__cxx11::match_results<__gnu_cxx::__normal_iterator, std::allocator > >, std::allocator, std::allocator > > > > >::format, std::allocator > > > (this=this@entry=0x7fffdd00, __out=..., __fmt_first=, __fmt_first@entry=0x4833f4 "$2<", __fmt_last=__fmt_last@entry=0x4833f7 "", __flags=, __flags@entry=(unknown: 0)) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.tcc:437 #4 0x0044a80c in std::regex_replace, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, std::__cxx11::regex_traits, char> (__out=__out@entry=..., __first=, __first@entry=98 'b', __last=, __e=..., __fmt=__fmt@entry=0x4833f4 "$2<", __flags=__flags@entry=(unknown: 0)) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.tcc:481 #5 0x004055ab in std::regex_replace, char, std::char_traits, std::allocator > (__flags=(unknown: 0), __fmt=0x4833f4 "$2<", __e=..., __s="boost::hana::template_t") at /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/regex.h:2366 #6 boost::hana::experimental::print_detail::strip_type_junk (str="boost::hana::template_t") at /var/tmp/hana/include/boost/hana/experimental/printable.hpp:90 #7 0x00403a4d in boost::hana::experimental::print_impl, void>::apply > () at /var/tmp/hana/include/boost/hana/experimental/printable.hpp:228 #8 boost::hana::experimental::print_t::operator() > (this=, t=) at /var/tmp/hana/include/boost/hana/experimental/printable.hpp:74 #9 main () at metafunction.cpp:22
[Bug sanitizer/70147] testcase from hana testsuite gets miscompiled with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147 --- Comment #1 from Markus Trippelsdorf --- -fsanitize=vptr is enough.
[Bug target/70010] powerpc: -flto forgets 'no-vsx' function attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70010
--- Comment #4 from Martin Sebor ---
I think I see the problem. The no-vsx function needs to be inlined into a
function that itself uses VSX, like in this test case. I don't know if this is
supposed to work. I vaguely recall inlining and target (amnd other similar)
attributes not meshing together.
$ cat ~/tmp/t.c && /build/gcc-5.x/gcc/xgcc -B/build/gcc-5.x/gcc -O2 -Wall
-Wextra -flto -fpic -maltivec -mcpu=power8 -mno-allow-movmisalign -shared -o
t.so ~/tmp/t.c && objdump -d t.so | sed -n "/<\.call_vadd_no_vsx>:/,/^$/p"
#define vector __attribute__ ((vector_size (16)))
#define no_altivec __attribute__((__target__("no-altivec")))
#define no_vsx __attribute__((__target__("no-vsx")))
vector int a, b, c;
vector int d, e, f;
static void no_vsx vadd_no_vsx (void) {
c = a + b;
}
void call_vadd_no_vsx (void) {
vadd_no_vsx ();
f = d + e;
}
09f0 <.call_vadd_no_vsx>:
9f0: 60 00 00 00 nop
9f4: e9 42 80 50 ld r10,-32688(r2)
9f8: 60 00 00 00 nop
9fc: e9 22 80 58 ld r9,-32680(r2)
a00: 60 00 00 00 nop
a04: e8 e2 80 38 ld r7,-32712(r2)
a08: 60 00 00 00 nop
a0c: e9 02 80 40 ld r8,-32704(r2)
a10: 7c 00 56 19 lxvw4x vs32,0,r10
a14: 7d a0 4e 19 lxvw4x vs45,0,r9
a18: 60 00 00 00 nop
a1c: e9 42 80 30 ld r10,-32720(r2)
a20: 60 00 00 00 nop
a24: e9 22 80 48 ld r9,-32696(r2)
a28: 7c 20 3e 19 lxvw4x vs33,0,r7
a2c: 7d 80 46 19 lxvw4x vs44,0,r8
a30: 10 00 68 80 vadduwm v0,v0,v13
a34: 10 21 60 80 vadduwm v1,v1,v12
a38: 7c 00 4f 19 stxvw4x vs32,0,r9
a3c: 7c 20 57 19 stxvw4x vs33,0,r10
a40: 4e 80 00 20 blr
...
a54: 00 01 f6 a0 .long 0x1f6a0
[Bug target/70148] New: Feature request: allow overriding the SSP canary location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70148 Bug ID: 70148 Summary: Feature request: allow overriding the SSP canary location Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- The 32-bit x86 Linux kernel jumps through ridiculous hoops to but the SSP canary where GCC expects it. (If I had been paying attention when that code was written, I would have NAKed it outright -- it's a disaster.) The 64-bit kernel jumps through less ridiculous hoops. Can we have the ability to tell GCC what segment override to use and what offset to use? It would be even better if we could tell GCC what segment override to use and make GCC emit an absolute symbol reference for the offset so we could relocate it. (The 32-bit issue is that GCC insists on using %gs, and Linux would *much* prefer %fs.)
[Bug target/9552] accepts invalid code for attribute section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #25 from Martin Sebor --- I can't reproduce this using the attached translation unit with an s390 cross-compiler for a i686 build/host. I tried adding the const qualifier as suggested in comment #8 but that didn't change anything. I'm not sure I understand correctly comment #20 and later as saying that the problem was due to the configuration of the reporter's compiler. In any case, since the bug hasn't been updated in over 10 years, I'm going to take the liberty of resolving it. Please feel free to reopen it if the problem can be reproduced (and if so, please provide steps to do it).
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #3 from Bill Schmidt --- I looked at the test case under the debugger today. Both the SLP-vectorized version of the loop, and the unvectorized version, appear to work correctly. The code is straightforward and not input-dependent, so I'm confident in this statement. As we discussed, this does seem to be likely to be something moving slightly and tickling a linker bug with the newer linkers.
[Bug target/70010] powerpc: -flto forgets 'no-vsx' function attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70010 --- Comment #5 from Cyril Bur --- Hi Martin, (After forgetting -O2 and wondering why everything changed: conclusion -O2 is important for this) I added -fno-inline (so: -O2 -Wall -Wextra -flto -fno-inline) to my cases and while optimisations may have caused altivec_touch_fn() to be a bit strange: 1650 <.altivec_touch_fn>: 1650: 60 00 00 00 nop 1654: 10 00 04 c4 vxorv0,v0,v0 1658: 39 22 80 90 addir9,r2,-32624 165c: 7c 00 49 ce stvxv0,0,r9 1660: 4e 80 00 20 blr It does use Altivec and not VSX. I believe this confirms your statement.
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #11 from Jeffrey A. Law --- The underlying randomness of coalescing is inherently due to the instability of SSA_NAME_VERSION. If we make SSA_NAME_VERSION stable, then the randomness of coalescing goes away. So I essentially toss away the existing version #s and rebuild them in a walk over the IL. First assignment gets #1, second assignment gets #2, and so-on. That brings relative stability to the version #s, which in turn brings stability to the coalescer. I suspect the existing cases that aren't stable are probably due to default defs or somesuch. Those don't have assignments and thus are still getting a pseudo-random SSA_NAME_VERSION after my renumbering.
