[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912 --- Comment #9 from Kito Cheng --- Code gen in previous comment is output for riscv32-unknown-linux-gnu-gcc pr52750.c -S ARM got worse code gen too: configure: --target=arm-eabi $ arm-eabi-gcc pr52750.c -S For pr52750.c: $ diff before.arm.s after.arm.s 170c170 < ldrbr3, [fp, #-176] --- > ldr r3, [fp, #-176] 172c172 < ldrbr3, [fp, #-180] --- > ldr r3, [fp, #-180] 174c174 < ldrbr3, [fp, #-184] --- > ldr r3, [fp, #-184] 176c176 < ldrbr3, [fp, #-188] --- > ldr r3, [fp, #-188] 178c178 < ldrbr3, [fp, #-192] --- > ldr r3, [fp, #-192] 180c180 < ldrbr3, [fp, #-196] --- > ldr r3, [fp, #-196] 182c182 < ldrbr3, [fp, #-200] --- > ldr r3, [fp, #-200] 184c184 < ldrbr3, [fp, #-204] --- > ldr r3, [fp, #-204] 186c186 < ldrbr3, [fp, #-208] --- > ldr r3, [fp, #-208] 188c188 < ldrbr3, [fp, #-212] --- > ldr r3, [fp, #-212] 190c190 < ldrbr3, [fp, #-216] --- > ldr r3, [fp, #-216] 192c192 < ldrbr3, [fp, #-220] --- > ldr r3, [fp, #-220] 194c194 < ldrbr3, [fp, #-224] --- > ldr r3, [fp, #-224] 196c196 < ldrbr3, [fp, #-228] --- > ldr r3, [fp, #-228] 198c198 < ldrbr3, [fp, #-232] --- > ldr r3, [fp, #-232] 200c200 < ldrbr3, [fp, #-236] --- > ldr r3, [fp, #-236] 202c202 < ldrbr3, [fp, #-240] --- > ldr r3, [fp, #-240] 204c204 < ldrbr3, [fp, #-244] --- > ldr r3, [fp, #-244] 206c206 < ldrbr3, [fp, #-248] --- > ldr r3, [fp, #-248]
[Bug c++/79937] [5/6/7 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
The problem here is that we're messing with placeholders in an unrelated
object:
For
C c = bar(X{1});
store_init_value sees:
c = TARGET_EXPR )->i}>)>
We call replace_placeholders for the RHS. It's a TARGET_EXPR so we look at its
TARGET_EXPR_INITIAL, which is
bar (TARGET_EXPR )->i}>)
Then we walk this tree, find the
{.i=1, .n=(&)->i}
CONSTRUCTOR, and recursively replace_placeholders_r for each value. Eventually
we find the but that's for another object, so we
crash.
I.e., we shouldn't look into the second TARGET_EXPR, it has nothing to do with
"C c".
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 67520, which changed state. Bug 67520 Summary: libmpx should abort() instead of exit(255) on bound violation detection https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67520 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug other/67520] libmpx should abort() instead of exit(255) on bound violation detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67520 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Closing as fixed.
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #8 from Kito Cheng ---
Hi Matthew:
Oh, my fault, I just go another way[1] to fix this issue, but I got worse code
gen for both hard-float and soft-float after r245655, before.*.s is generate by
gcc with revert r245655, *rv32imafd.s for hard-float and *rv32ima.s for
soft-float, RISC-V define WORD_REGISTER_OPERATIONS as 1, but also provide qi/hi
load/store, I guess this may effect other RISC arch too.
$ diff before.rv32imafd.s after.rv32imafd.s
139c139,142
< lbu a5,-244(s0)
---
> flw fa5,-244(s0)
> fmv.x.s a5,fa5
> fmv.s.x fa5,a5
> fmv.x.s a5,fa5
141c144,147
< lbu a5,-248(s0)
---
> flw fa5,-248(s0)
> fmv.x.s a5,fa5
> fmv.s.x fa5,a5
> fmv.x.s a5,fa5
143c149,152
< lbu a5,-252(s0)
---
> flw fa5,-252(s0)
> fmv.x.s a5,fa5
> fmv.s.x fa5,a5
> fmv.x.s a5,fa5
145c154,157
< lbu a5,-256(s0)
---
> flw fa5,-256(s0)
> fmv.x.s a5,fa5
> fmv.s.x fa5,a5
> fmv.x.s a5,fa5
147c159,162
< lbu a5,-260(s0)
---
> flw fa5,-260(s0)
> fmv.x.s a5,fa5
> fmv.s.x fa5,a5
> fmv.x.s a5,fa5
173c188,191
< lbu a5,-264(s0)
---
> flw fa5,-264(s0)
> fmv.x.s a5,fa5
> fmv.s.x fa5,a5
> fmv.x.s a5,fa5
$ diff before.rv32ima.s after.rv32ima.s
143c143
< lbu a4,-244(s0)
---
> lw a4,-244(s0)
145c145
< lbu a4,-248(s0)
---
> lw a4,-248(s0)
147c147
< lbu a4,-252(s0)
---
> lw a4,-252(s0)
149c149
< lbu a4,-256(s0)
---
> lw a4,-256(s0)
151c151
< lbu a4,-260(s0)
---
> lw a4,-260(s0)
153c153
< lbu a4,-264(s0)
---
> lw a4,-264(s0)
[1]
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 89567f7..148967b 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3581,10 +3581,6 @@ riscv_hard_regno_mode_ok_p (unsigned int regno, enum
machine_mode mode)
if (!FP_REG_P (regno + nregs - 1))
return false;
- if (GET_MODE_CLASS (mode) != MODE_FLOAT
- && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT)
- return false;
-
/* Only use callee-saved registers if a potential callee is guaranteed
to spill the requisite width. */
if (GET_MODE_UNIT_SIZE (mode) > UNITS_PER_FP_REG
@@ -3634,7 +3630,7 @@ riscv_class_max_nregs (reg_class_t rclass, enum
machine_mode mode)
static reg_class_t
riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
{
- return reg_class_subset_p (FP_REGS, rclass) ? FP_REGS :
+ return reg_class_subset_p (FP_REGS, rclass) && TARGET_HARD_FLOAT ? FP_REGS :
reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
rclass;
}
[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270 Martin Liška changed: What|Removed |Added Known to work||7.0 --- Comment #6 from Martin Liška --- Fixed on trunk.
[Bug c/79834] c/c-parser.c: make code more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79834 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 40912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40912&action=edit gcc7-pr79834.patch Untested fix.
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912 --- Comment #7 from mpf at gcc dot gnu.org --- The same fix will resolve soft-float as well I think. In the soft-float case I believe it is reasonably logical that preferred_reload_class is wrong as there are no registers in FPR_REGS available at all.
[Bug c/79938] gcc unnecessarily spills xmm register to stack when inserting vector items
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938 --- Comment #2 from postmaster at raasu dot org --- (In reply to Richard Biener from comment #1) > The situation is slightly better with GCC 7, only two spill/loads are > remaining. > Possibly BIT_INSERT_EXPR helps here. With gcc 6.2.0 and gcc -msse4.1 -mtune=core2 -O3 -S hadd.c -Wall -Wextra -fno-strict-aliasing -fwrapv -o hadd.s The resulting assembler output is almost perfect, but adding -mtune=core2 kinda makes the code optimal only for Intel processors. --- ... pxor%xmm1, %xmm1 movl$1, %edi movd%eax, %xmm0 pshufb %xmm1, %xmm0 pextrb $1, %xmm0, %edx pextrb $0, %xmm0, %eax addl%edx, %eax pextrb $2, %xmm0, %edx addl%edx, %eax pextrb $4, %xmm0, %ecx pextrb $3, %xmm0, %edx addl%eax, %edx pextrb $5, %xmm0, %eax addl%eax, %ecx pextrb $6, %xmm0, %eax addl%eax, %ecx pextrb $9, %xmm0, %esi pextrb $7, %xmm0, %eax addl%eax, %ecx pextrb $8, %xmm0, %eax addl%esi, %eax pextrb $10, %xmm0, %esi addl%esi, %eax pextrb $11, %xmm0, %esi addl%esi, %eax pextrb $13, %xmm0, %esi movd%eax, %xmm1 pextrb $12, %xmm0, %eax addl%esi, %eax pextrb $14, %xmm0, %esi addl%eax, %esi pextrb $15, %xmm0, %eax movd%edx, %xmm0 addl%esi, %eax pinsrd $1, %ecx, %xmm0 movl$.LC0, %esi pinsrd $1, %eax, %xmm1 xorl%eax, %eax punpcklqdq %xmm1, %xmm0 ...
[Bug target/69034] ICE: RTL check: expected elt 1 type 'e' or 'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323 with -fPIC and "X" asm input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Segher Boessenkool --- So, it's a dup. I don't agree with your patch either, unfortunately. Inline asm should as much as possible work the same as all other RTL does, "X" should not mean something more restricted in inline asm. *** This bug has been marked as a duplicate of bug 59155 ***
[Bug inline-asm/59155] ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155 --- Comment #8 from Segher Boessenkool --- *** Bug 69034 has been marked as a duplicate of this bug. ***
[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270 --- Comment #5 from Martin Liška --- Author: marxin Date: Tue Mar 7 14:12:52 2017 New Revision: 245951 URL: https://gcc.gnu.org/viewcvs?rev=245951&root=gcc&view=rev Log: Use array_at_struct_end_p in tree-chkp.c (PR middle-end/68270). 2017-03-07 Martin Liska PR middle-end/68270 * tree-chkp.c (chkp_may_narrow_to_field): Add new argument ref. Use array_at_struct_end_p instead of DECL_CHAIN (field). (chkp_narrow_bounds_for_field): Likewise. (chkp_parse_array_and_component_ref): Pass one more argument to call. 2017-03-07 Martin Liska PR middle-end/68270 * g++.dg/pr68270.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr68270.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891
Martin Liška changed:
What|Removed |Added
CC||hubicka at ucw dot cz
--- Comment #3 from Martin Liška ---
Ok, there's a bit simplified test-case:
#include /* for exit() */
unsigned int
UuT (void)
{
unsigned int true_var = 1;
unsigned int false_var = 0;
unsigned int ret = 0;
if (true_var)
{
if (false_var)
ret = 111; /* issue */
}
else
ret = 999;
return ret;
}
int
main (int argc, char **argv)
{
UuT ();
return 0;
}
IPA profile outputs following CFG:
[0.00%]:
true_var_3 = 1;
false_var_4 = 0;
ret_5 = 0;
if (true_var_3 != 0)
goto ; [0.00%]
else
goto ; [0.00%]
[0.00%]:
if (false_var_4 != 0)
goto ; [0.00%]
else
goto ; [0.00%]
[0.00%]:
ret_7 = 111;
PROF_edge_counter_10 = __gcov0.UuT[0];
PROF_edge_counter_11 = PROF_edge_counter_10 + 1;
__gcov0.UuT[0] = PROF_edge_counter_11;
[0.00%]:
# ret_1 = PHI
goto ; [0.00%]
[0.00%]:
ret_6 = 999;
PROF_edge_counter_12 = __gcov0.UuT[1];
PROF_edge_counter_13 = PROF_edge_counter_12 + 1;
__gcov0.UuT[1] = PROF_edge_counter_13;
[0.00%]:
# ret_2 = PHI
_8 = ret_2;
[0.00%]:
PROF_edge_counter_14 = __gcov0.UuT[2];
PROF_edge_counter_15 = PROF_edge_counter_14 + 1;
__gcov0.UuT[2] = PROF_edge_counter_15;
return _8;
Problem is that BB 7 is used for both false_var == false and as a fallthru
block for BB 6.
Thus line 13 contains 2 blocks:
./gcov pr79891.c -a --debug
GCOV function: UuT
line 4: 1
BB 1 (0xfae1b8): 1
line 10: 1
BB 2 (0xfae200): 1
arc 0xfae200->0xfae248: 1
arc 0xfae200->0xfae320: 0
line 12: 1
BB 3 (0xfae248): 1
arc 0xfae248->0xfae290: 0
arc 0xfae248->0xfae2d8: 1
line 13: 0
BB 5 (0xfae2d8): 1
arc 0xfae2d8->0xfae368: 1
BB 4 (0xfae290): 0
arc 0xfae290->0xfae2d8: 0
line 16: 0
BB 6 (0xfae320): 0
arc 0xfae320->0xfae368: 0
line 17: 1
BB 7 (0xfae368): 1
arc 0xfae368->0xfae3b0: 1
And behavior with -a (all-blocks) behaves as described here:
/* The user expects the line count to be the number of times
a line has been executed. Simply summing the block count
will give an artificially high number. The Right Thing
is to sum the entry counts to the graph of blocks on this
line, then find the elementary cycles of the local graph
and add the transition counts of those cycles. */
That's why we end up with the wrong number.
Thoughts?
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912 --- Comment #6 from Kito Cheng --- Hi Matthew: Thanks for you feedback, I will disuses with other RISC-V maintainer for the GPR <-> FPR issue, however it's still hang on LRA for pr52750.c when use soft float[1] and work if revert r245655 too, do you have any idea for that? [1] $ riscv32-unknown-linux-gnu-gcc pr52750.c -march=rv32ima -mabi=ilp32
[Bug target/79939] [nvptx] gcc hangs in nvptx_assemble_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939
--- Comment #1 from Tom de Vries ---
With -O2 at .optimized, we have for gomp4:
...
main (int argc, char * * argv)
{
v4si x;
int _2;
:
_2 = MEM[(int *)&x + 16B];
x ={v} {CLOBBER};
return _2;
}
...
and for mainline:
...
main (int argc, char * * argv)
{
int _2;
[100.00%]:
_2 = VIEW_CONVERT_EXPR({ 3, 2, 1, 0 })[4];
return _2;
}
...
[Bug target/79939] New: [nvptx] gcc hangs in nvptx_assemble_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939
Bug ID: 79939
Summary: [nvptx] gcc hangs in nvptx_assemble_value
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
gcc hangs when trying to compile pr59037.c:
...
WARNING: program timed out.
FAIL: c-c++-common/pr59037.c -Wc++-compat (test for excess errors)
...
pr59037.c:
...
typedef int v4si __attribute__ ((vector_size (16)));
int
main (int argc, char** argv)
{
v4si x = {0,1,2,3};
x = (v4si) {(x)[3], (x)[2], (x)[1], (x)[0]};
return x[4];
}
...
To reproduce (also at -O1, -O3):
...
$ gcc src/gcc-mainline/gcc/testsuite/c-c++-common/pr59037.c -O2
...
The compiler is stuck in the loop in nvptx_assemble_value with arguments:
...
nvptx_assemble_value (val=8589934595, size=8)
...
This happens with trunk, not with gomp-4_0-branch.
The code is like this:
...
static void
nvptx_assemble_value (unsigned HOST_WIDE_INT val, unsigned size)
{
val &= ((unsigned HOST_WIDE_INT)2 << (size * BITS_PER_UNIT - 1)) - 1;
for (unsigned part = 0; size; size -= part)
{
val >>= part * BITS_PER_UNIT;
part = init_frag.size - init_frag.offset;
if (part > size)
part = size;
unsigned HOST_WIDE_INT partial
= val << (init_frag.offset * BITS_PER_UNIT);
init_frag.val |= partial & init_frag.mask;
init_frag.offset += part;
if (init_frag.offset == init_frag.size)
output_init_frag (NULL);
}
}
...
Both init_frag.size and init_frag.offset are 0, so part stays 0, so size stays
8, and the loop never terminates.
The only place where init_frag.size is set, is nvptx_assemble_decl_begin, but
that one is not called.
Backtrace when entering:
...
(gdb) bt
#0 nvptx_assemble_value (val=8589934595, size=8)
at src/gcc-mainline/gcc/config/nvptx/nvptx.c:1765
#1 0x00e647e9 in nvptx_assemble_integer (x=,
size=,
aligned_p=) at
src/gcc-mainline/gcc/config/nvptx/nvptx.c:1799
#2 0x00e379eb in assemble_integer (x=0x77426220,
size=size@entry=8, align=align@entry=64,
force=force@entry=0) at src/gcc-mainline/gcc/varasm.c:2721
#3 0x00e37a79 in assemble_integer (x=0x77423858, size=16,
align=, force=force@entry=1)
at src/gcc-mainline/gcc/varasm.c:2746
#4 0x00e37d66 in output_constant_pool_2 (mode=,
x=, align=)
at src/gcc-mainline/gcc/varasm.c:3848
#5 0x00e37ec7 in output_constant_pool_1
(desc=desc@entry=0x77326340, align=)
at src/gcc-mainline/gcc/varasm.c:3936
#6 0x00e4496b in output_constant_pool_contents (pool=)
at src/gcc-mainline/gcc/varasm.c:4073
#7 0x00b2080c in compile_file () at src/gcc-mainline/gcc/toplev.c:526
#8 0x005a60e2 in do_compile () at src/gcc-mainline/gcc/toplev.c:1984
#9 toplev::main (this=0x7fffddb0, argc=21, argv=0x7fffdeb8)
at src/gcc-mainline/gcc/toplev.c:2118
#10 0x005a7e67 in main (argc=21, argv=0x7fffdeb8)
at src/gcc-mainline/gcc/main.c:39
...
[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79347 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from amker at gcc dot gnu.org --- Fixed. The failure on sparc-sun-solaris2.12 should be resolved by patch to PR77536.
[Bug c/79938] gcc unnecessarily spills xmm register to stack when inserting vector items
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938 --- Comment #1 from Richard Biener --- The situation is slightly better with GCC 7, only two spill/loads are remaining. Possibly BIT_INSERT_EXPR helps here. For the testcase you want to add __attribute__((noinline)) to haddd_epu8 as otherwise eliding the result vector after inlining into main is desirable (but not done). Then with GCC 7 we get: haddd_epu8: .LFB4966: .cfi_startproc pextrb $1, %xmm0, %edx pextrb $0, %xmm0, %eax addl%edx, %eax pextrb $2, %xmm0, %edx addl%edx, %eax pextrb $3, %xmm0, %edx addl%edx, %eax pextrb $5, %xmm0, %edx movl%eax, -12(%rsp) pextrb $4, %xmm0, %eax movd-12(%rsp), %xmm1 addl%edx, %eax pextrb $6, %xmm0, %edx addl%edx, %eax pextrb $7, %xmm0, %edx addl%edx, %eax pextrb $9, %xmm0, %edx pinsrd $1, %eax, %xmm1 pextrb $8, %xmm0, %eax addl%edx, %eax pextrb $10, %xmm0, %edx addl%edx, %eax pextrb $11, %xmm0, %edx addl%edx, %eax pextrb $13, %xmm0, %edx pinsrd $2, %eax, %xmm1 pextrb $12, %xmm0, %eax addl%edx, %eax pextrb $14, %xmm0, %edx addl%eax, %edx pextrb $15, %xmm0, %eax addl%edx, %eax pinsrd $3, %eax, %xmm1 movdqa %xmm1, %xmm0 ret which looks optimial to me. The single stack use is because by default inter-unit moves are disabled. With -mtune=core-avx2 you'd get haddd_epu8: .LFB4966: .cfi_startproc pextrb $1, %xmm0, %edx pextrb $0, %xmm0, %eax addl%edx, %eax pextrb $2, %xmm0, %edx addl%edx, %eax pextrb $3, %xmm0, %edx addl%edx, %eax pextrb $5, %xmm0, %edx movd%eax, %xmm1 pextrb $4, %xmm0, %eax addl%edx, %eax pextrb $6, %xmm0, %edx addl%edx, %eax pextrb $7, %xmm0, %edx addl%edx, %eax pextrb $9, %xmm0, %edx pinsrd $1, %eax, %xmm1 pextrb $8, %xmm0, %eax addl%edx, %eax pextrb $10, %xmm0, %edx addl%edx, %eax pextrb $11, %xmm0, %edx addl%edx, %eax pextrb $13, %xmm0, %edx pinsrd $2, %eax, %xmm1 pextrb $12, %xmm0, %eax addl%edx, %eax pextrb $14, %xmm0, %edx addl%eax, %edx pextrb $15, %xmm0, %eax addl%edx, %eax pinsrd $3, %eax, %xmm1 movdqa %xmm1, %xmm0 ret
[Bug tree-optimization/66768] address space gets lost on literal pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from amker at gcc dot gnu.org --- Fxied.
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #5 from mpf at gcc dot gnu.org ---
I think there are some relatively serious issues in the riscv backend here.
What I understand so far:
1) Only floating point modes are allowed in FPRs
2) There is an alternative in the movqi_internal pattern that allows FPR to GPR
moves but from (1) this is impossible. The presence of this alternative skews
the error from LRA. Removing these alternatives changes the LRA error to max
reloads reached.
3) The preferred reload class for riscv is always FP_REGS if the requested
class is ALL_REGS but there is no check to ensure the mode of the expression
being reloaded can go in FP_REGS.
4) LRA always generates reloads as ALL_REGS to start with and refines
5) Therefore a QImode reload can end up trying to reload through an FP_REG
which is completely impossible. I expect similar FPR-GPR alternatives in other
integer move patterns may also be bugs.
Spilling non-eliminable hard regs: 8
Creating newreg=182, assigning class FP_REGS to slow mem r182
Creating newreg=183, assigning class FP_REGS to slow mem r183
194: r180:QI=r183:QI
REG_DEAD r102:SI
Inserting slow mem reload before:
196: r182:SI=[frame:SI-0x108]
197: r183:QI=r182:SI#0
Simply removing the preferred_reload_class hook allows LRA to succeed but
presumably it is desirable to try and reload through FPRs for float modes where
possible.
I suspect the preferred_reload_class should be:
static reg_class_t
riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
{
machine_mode mode = GET_MODE (x);
if ((GET_MODE_CLASS (mode) == MODE_FLOAT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
&& reg_class_subset_p (FP_REGS, rclass))
return FP_REGS;
return reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
rclass;
}
But it needs a riscv maintainer to comment on what they were trying to achieve
and the constraints on movqi_internal, movhi_internal, movsi_internal need
checking. From my read through of the backend I believe all the alternatives
involving 'f' on these are invalid but I can't be sure.
[Bug c++/79899] ICE in ctor_omit_inherited_parms at gcc/cp/method.c:576 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79899 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 40911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40911&action=edit gcc7-pr79899.patch Untested fix.
[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 --- Comment #4 from Jan Smets --- Created attachment 40910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40910&action=edit testcase pr79951 mips64-linux-gnuabi64-gcc -xc++ pr79951.i -o /dev/null -S -mlong-calls -mno-abicalls
[Bug c++/79896] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40909&action=edit gcc7-pr79896.patch Untested fix.
[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 Jan Smets changed: What|Removed |Added Target|mips|mips64-linux-gnuabi64 Summary|ICE in final_scan_insn, at |ICE in final_scan_insn, at |final.c:2982 on mips when |final.c:2982 (could not |compiling libstdc++ with|split insn) on mips* when |-mlong-calls|compiling libstdc++ with ||-mlong-calls -mno-abicalls --- Comment #3 from Jan Smets --- And that was because vxworks defaults to -mno-abicalls. Thus, the example reproduces on mips64-linux with -mno-abicalls
[Bug c++/79896] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-invalid-code |error-recovery Target|arm-linux-gnueabi | Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-07 Target Milestone|--- |7.0 Summary|ICE in gimplify_expr, at|[5/6/7 Regression] ICE in |gimplify.c:11950 on ARM |gimplify_expr, at |target |gimplify.c:11950 on ||non-int128 target Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started in between r104000 and r106000. ICEs also on x86_64 with -m32 and I guess all other non-int128 targets.
[Bug c++/79919] Warning specifies end of method rather than the correct line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79919 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-07 Ever confirmed|0 |1
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #12 from Jonathan Wakely --- Created attachment 40908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40908&action=edit Make atomic depend on _GLIBCXX_USE_C99_STDINT_TR1 Here's a patch for trunk, which I'll commit after GCC 7 is released.
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #11 from Jonathan Wakely --- (In reply to Sumit from comment #2) > I understand that 4.8.1 is no longer supported. > Actually, our project in current state can't move to any version beyond > 4.8.1 for some maintainability reasons. Not even 4.8.5? That's just silly.
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #10 from Jonathan Wakely --- Libstdc++ should handle those types being missing, but it doesn't do so correctly. Try making the inclusion of conditional: --- include/std/future +++ include/std/future @@ -40,7 +40,9 @@ #include #include #include +#ifdef _GLIBCXX_USE_C99_STDINT_TR1 #include +#endif #include #include #include
[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #7 from Jakub Jelinek ---
stack size (kbytes, -s) 65532
is 64M, that should be more than enough. Of course unless darwin
pthread_create does something dumb, like using far smaller stack sizes for
threads by default.
In that case, the question is if we shouldn't override that on darwin to
something larger, or just use
! { dg-set-target-env-var OMP_STACKSIZE "8M" }
on the test. Note that dg-set-target-env-var doesn't (yet?) support target
specification as 3rd argument, so I'd prefer not to add that.
Or we could add -finline-matmul-limit=64 or whatever works.
[Bug rtl-optimization/66669] FAIL: gcc.dg/loop-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 mpf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpf at gcc dot gnu.org Known to work||7.0 Resolution|--- |FIXED --- Comment #5 from mpf at gcc dot gnu.org --- This issue is fixed for all reported targets by skipping the test.
[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904 --- Comment #5 from Jakub Jelinek --- Created attachment 40907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40907&action=edit gcc7-pr79904.patch Untested optimization that fixes the original testcase, but doesn't the one without uniform vector.
[Bug target/79473] -mload-store-pairs option is not documented in invoke.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79473 mpf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpf at gcc dot gnu.org Known to work||7.0 Resolution|--- |FIXED --- Comment #2 from mpf at gcc dot gnu.org --- Fixed on trunk.
[Bug target/79914] VEC_SELECT bugs in mips patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79914 mpf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.0 Resolution|--- |FIXED --- Comment #3 from mpf at gcc dot gnu.org --- Fixed by r245911.
[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
For signed integer overflow sanitized vector +/-/*, the code is emitted from
internal-fn.c calling generic expansion routines.
I have no idea what s390.c complains about here, why is it wrong.
What internal-fn.c does is it tries to expand:
VIEW_CONVERT_EXPR({ 3, 3, 3, 3, 3, 3, 3, 3 })[D.2328];
The vector has DImode, is VCEd to array of 8 chars, and then array accessed.
internal-fn.c uses:
op1 = fold_build1_loc (loc, VIEW_CONVERT_EXPR, atype, arg1);
op1 = build4_loc (loc, ARRAY_REF, eltype, op1, cntv,
NULL_TREE, NULL_TREE);
where arg1 is VECTOR_CST and later that op1 is expanded using expand_normal. I
can certainly as optimization deal there with uniform vectors, will attach a
patch for that momentarily, but that doesn't fix:
/* PR sanitizer/79904 */
/* { dg-do compile } */
/* { dg-options "-fsanitize=signed-integer-overflow" } */
typedef signed char V __attribute__((vector_size (8)));
void
foo (V *a)
{
*a = *a * (V) { 3, 4, 5, 6, 7, 8, 9, 10 };
}
which still ICEs. I must say I don't see anything wrong here on the middle-end
side.
[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876 --- Comment #6 from Dominique d'Humieres --- > Does Darwin have so ridiculously low stack size limits by default, > or is that just some setting you've done? On darwin1(0|6) ulimit gives stack size (kbytes, -s) 65532 and the environment variable OMP_STACKSIZE is empty. Note that on darwin10 (revision r245900) the reduced test succeeds with OMP_STACKSIZE set to 80k and for smaller values I get an error libgomp: Stack size larger than system limit at run time.
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 mpf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.0 Resolution|--- |FIXED Known to fail|7.0 | --- Comment #7 from mpf at gcc dot gnu.org --- This is fixed for GCC 7. It may need a backport to GCC 6 though.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 mpf at gcc dot gnu.org changed: What|Removed |Added Known to work||7.0 Target Milestone|--- |8.0 Known to fail||6.2.0 --- Comment #21 from mpf at gcc dot gnu.org --- Moving target to GCC 8.0 albeit that it may not be solvable. Mitigated in GCC 7.
[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 mpf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from mpf at gcc dot gnu.org --- Bootstrap now succeeds.
[Bug c/79938] New: gcc unnecessarily spills xmm register to stack when inserting vector items
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
Bug ID: 79938
Summary: gcc unnecessarily spills xmm register to stack when
inserting vector items
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: postmaster at raasu dot org
Target Milestone: ---
Created attachment 40906
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40906&action=edit
assembler output
When adding together values from one vector and storing the results to another,
gcc uses two xmm registers instead of one and spills the second xmm register to
stack when it runs out of general purpose registers.
Instead of spilling the second xmm register to stack, it should use only one
xmm register as destination, because the addition is already being done using
four general purpose registers.
Using gcc -msse4.1 -O3 -S hadd.c -Wall -Wextra -fno-strict-aliasing -fwrapv -o
hadd.s
mika@LENOVO:~$ gcc --version
gcc (Ubuntu 6.2.0-3ubuntu11~14.04) 6.2.0 20160901
---
#include
#include
#include
typedef uint8_t v1si __attribute__ ((vector_size (16)));
typedef uint16_t v2si __attribute__ ((vector_size (16)));
typedef uint32_t v4si __attribute__ ((vector_size (16)));
typedef uint64_t v8si __attribute__ ((vector_size (16)));
static __m128i haddd_epu8(__m128i a)
{
v1si b = (v1si)a;
v4si ret;
ret[0] = (b[ 0] + b[ 1]) + (b[ 2] + b[ 3]);
ret[1] = (b[ 4] + b[ 5]) + (b[ 6] + b[ 7]);
ret[2] = (b[ 8] + b[ 9]) + (b[10] + b[11]);
ret[3] = (b[12] + b[13]) + (b[14] + b[15]);
return (__m128i)ret;
}
int main(int argc, char *argv[])
{
__m128i a = _mm_set1_epi8(atoi(argv[1]));
__m128i b = haddd_epu8(a);
v4si c = (v4si)b;
printf("b[0] = %i, b[1] = %i, b[2] = %i, b[3] = %i\n", c[0], c[1], c[2],
c[3]);
}
[Bug c++/79937] [5/6/7 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Target Milestone|--- |5.5
[Bug target/79935] DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Or, if MSWin for djgpp never guarantees stack 16-byte alignment, missing STACK_REALIGN_DEFAULT redefinition. There is e.g.: gcc/config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE gcc/config/i386/sol2.h:#define STACK_REALIGN_DEFAULT (TARGET_64BIT ? 0 : 1) But gcc/config/i386/djgpp.h doesn't override it.
[Bug c/79855] params.def: missing period in PARAM_MAX_STORES_TO_MERGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug c++/79937] [5/6/7 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-07 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||5.1.0 Summary|ICE in |[5/6/7 Regression] ICE in |replace_placeholders_r |replace_placeholders_r Ever confirmed|0 |1 Known to fail||5.2.0, 6.3.0, 7.0 --- Comment #1 from Martin Liška --- Confirmed, started on trunk with r224282: PR c++/66383 * tree.c (replace_placeholders_r): Handle placeholders for an outer object. * typeck2.c (store_init_value): Only replace_placeholders for objects of class type. which was back-ported to GCC 5.2.0 as r224291.
[Bug c/79855] params.def: missing period in PARAM_MAX_STORES_TO_MERGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Mar 7 09:36:44 2017 New Revision: 245948 URL: https://gcc.gnu.org/viewcvs?rev=245948&root=gcc&view=rev Log: PR c/79855: add full stop to store merging param descriptions PR c/79855 * params.def (PARAM_STORE_MERGING_ALLOW_UNALIGNED): Add full stop to end of description. (PARAM_MAX_STORES_TO_MERGE): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #9 from Andrew Pinski --- Looks like the stdint.h is not defining all the needed types ...
[Bug c++/79937] New: ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Bug ID: 79937
Summary: ICE in replace_placeholders_r
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@arne-mertz.de
Target Milestone: ---
The following code snippet leads to an internal compiler error in GCC 5.3
through 7.0.1:
(see also https://godbolt.org/g/yFPEfx)
## Code
struct C{};
struct X {
unsigned i;
unsigned n = i;
};
C bar(X) {
return {};
}
void foo()
{
C c = bar(X{1}); //ICE
}
## Error message:
: In function 'void foo()':
:14:19: internal compiler error: in replace_placeholders_r, at
cp/tree.c:2524
C c = bar(X{1});
^
mmap: Cannot allocate memory
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Compiler exited with result code 1
## Version information (-v output):
### GCC 7.0.1:
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20170306/configure --prefix /root/staging
--build=x86_64-linux-gnu --disable-multilibs --disable-bootstrap
--enable-clocale=gnu --enable-languages=c,c++ --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.0.1 20170306 (experimental) (GCC-Explorer-Build)
### GCC 5.3.0
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-5.3.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix /root/staging
--build=x86_64-linux-gnu --disable-multilibs --enable-clocale=gnu
--enable-languages=c,c++ --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 5.3.0 (GCC-Explorer-Build)
COLLECT_GCC_OPTIONS='-g' '-o'
'/tmp/compiler-explorer-compiler11727-6627-1ps4xeb.oclq5mi/output.s'
'-masm=intel' '-S' '-std=c++14' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/opt/compiler-explorer/gcc-5.3.0/bin/../libexec/gcc/x86_64-linux-gnu/5.3.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-5.3.0/bin/../lib/gcc/x86_64-linux-gnu/5.3.0/
-D_GNU_SOURCE -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip
/tmp/compiler-explorer-compiler11727-6627-1ps4xeb.oclq5mi/output.s -g
-std=c++14 -version -o
/tmp/compiler-explorer-compiler11727-6627-1ps4xeb.oclq5mi/output.s
GNU C++14 (GCC-Explorer-Build) version 5.3.0 (x86_64-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 Sumit changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from Sumit --- (In reply to Andrew Pinski from comment #7) > (In reply to Sumit from comment #6) > > Hi Andrew, > > > > Somehow these files were missing in my package. I have recopied them back > > and things have moved further. > > > > Now, I am seeing compilation error at : > > > ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:523:5: error: unable > > to find string literal operator 'operator"" _ASSERT_STR' > > assert(this->_M_kind != _Parameter::__unused_param); > > Looks like the assert in assert.h vxworks has is not C++11 friendly. Add a > space before the _ASSERT_STR. Thanks Andrew. Adding a space before _ASSERT_STR helped. Now there are further errors seen : In file included from /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/atomic:41:0, from /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/future:43, from ../../../../../gcc-4.8/libstdc++-v3/src/c++11/functexcept.cc:31: /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:166:25: error: 'int_least8_t' was not declared in this scope typedef __atomic_baseatomic_int_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:166:37: error: template argument 1 is invalid typedef __atomic_baseatomic_int_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:166:61: error: invalid type in declaration before ';' token typedef __atomic_baseatomic_int_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:169:25: error: 'uint_least8_t' was not declared in this scope typedef __atomic_base atomic_uint_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:169:38: error: template argument 1 is invalid typedef __atomic_base atomic_uint_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:169:68: error: invalid type in declaration before ';' token typedef __atomic_base atomic_uint_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:172:25: error: 'int_least16_t' was not declared in this scope typedef __atomic_base atomic_int_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:172:38: error: template argument 1 is invalid typedef __atomic_base atomic_int_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:172:68: error: invalid type in declaration before ';' token typedef __atomic_base atomic_int_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:175:25: error: 'uint_least16_t' was not declared in this scope typedef __atomic_base atomic_uint_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:175:39: error: template argument 1 is invalid typedef __atomic_base atomic_uint_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:175:70: error: invalid type in declaration before ';' token typedef __atomic_base atomic_uint_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:178:25: error: 'int_least32_t' was not declared in this scope typedef __atomic_base atomic_int_least32_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:178:38: error: template argument 1 is invalid typedef __atomic_base atomic_int_least32_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:178:68: error: invalid type in declaration before ';' token typedef __atomic_base atomic_int_least32_t;
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728 --- Comment #5 from Xi Ruoyao --- (In reply to Bernd Schmidt from comment #4) > Actually here's mine from last week: > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00176.html So please ignore my mumble...
[Bug tree-optimization/79920] Incorrect floating point results when compiling with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79920 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Known to work||5.4.1 Keywords||wrong-code Last reconfirmed||2017-03-07 Component|c |tree-optimization Ever confirmed|0 |1 Target Milestone|--- |6.4 Known to fail||6.3.1, 7.0.1 --- Comment #1 from Richard Biener --- I can confirm your findings, GCC 5 seems fine. -fno-tree-vectorize fixes it. I will have a looksee.
[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876 --- Comment #5 from Jakub Jelinek --- Does Darwin have so ridiculously low stack size limits by default, or is that just some setting you've done?
[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 Richard Biener changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org Target Milestone|--- |7.0
[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #9 from Richard Biener --- If dot_product (matmul (...), ..) can be implemented more optimally (is there a blas/lapack primitive for it?) then the best course of action is to pattern match that inside the frontend and emit a library call to an optimized routine (which means eventually adding one to libfortran or using/extending -fexternal-blas. Recovering from this in the middle-end is only possible if both primitives are inlined and even then I expect it to be quite difficult to get optimal code out of it (though it's certainly interesting to see if we're at least getting a useful idea of data dependence). Long-term exposing important primitives semantics to the middle-end, even when implemented as library calls would be interesting (aka, add __builtin_dot_product, etc. which would make it possible to delay inline-expanding as well).
[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/79934] Vectorization of descending-index loops can produce unnecessary permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79934 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-07 Blocks||53947 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Generally a known weakness of the vectorizer and difficult to fix inside it. Still a fix in the vectorizer itself is wanted as cost modeling should better know about such optimization opportunities. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/79935] DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 --- Comment #1 from Richard Biener --- Sounds like a bug in the dynamic loader then?
[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 on mips when compiling libstdc++ with -mlong-calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915
--- Comment #2 from Jan Smets ---
Reduced test case, only occurs on the vxworks port, not on linux.
namespace a {
template class c;
class d {
public:
virtual ~d();
};
template class e : d {};
template class c : virtual e {};
class g : c {
~g();
};
g::~g() {}
}
[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Mar 7 08:11:30 2017 New Revision: 245947 URL: https://gcc.gnu.org/viewcvs?rev=245947&root=gcc&view=rev Log: PR rtl-optimization/79901 * config/i386/sse.md (*avx512bw_3): Renamed to ... (*avx512f_3): ... this. (3 with maxmin code iterator): Use VI8_AVX2_AVX512F iterator instead of VI8_AVX2_AVX512BW. * gcc.target/i386/pr79901.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr79901.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Mar 7 08:04:38 2017 New Revision: 245946 URL: https://gcc.gnu.org/viewcvs?rev=245946&root=gcc&view=rev Log: PR rtl-optimization/79901 * expr.c (expand_expr_real_2): For vector MIN/MAX, if there is no min/max expander, expand it using expand_vec_cond_expr. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79931 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-07 CC||hubicka at ucw dot cz, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.3.0
[Bug target/79932] _mm512_packus_epi32 does not compile under -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79932 --- Comment #2 from Jakub Jelinek --- Created attachment 40905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40905&action=edit gcc7-pr79932-2.patch Found further 64 intrinsics that weren't available at -O0.
