[Bug tree-optimization/67816] [6 Regression] ICE in duplicate_thread_path, 186.crafty fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67816 --- Comment #5 from rguenther at suse dot de --- On October 2, 2015 5:58:24 PM GMT+02:00, law at redhat dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67816 > >--- Comment #4 from Jeffrey A. Law --- >I can't get it to fail either. I've also tried running cc1 under >valgrind to >see if anything shows up. Sadly nothing relevant. > >Richi, if this is still failing, can you get me a little context? A >gimple_debug_cfg (0x60) at the point of failure and anything in the DOM >debugging dump (-fdump-whatever-details-blocks-vops) Crafty is still ICEing on all our testers at -O3. I'll re-reduce on Monday, but eventually you have access to SPEC CPU 2000 as well.
[Bug c++/37798] unaligned memory access with multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37798 Bernd Edlinger changed: What|Removed |Added Status|NEW |RESOLVED CC||edlinger at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Bernd Edlinger --- apparently fixed with 4.9, as discussed on gcc-patches.
[Bug ada/67836] New: Exceptions with tracebacks in task rendezvous cause STORAGE_ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67836 Bug ID: 67836 Summary: Exceptions with tracebacks in task rendezvous cause STORAGE_ERROR Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas.boulenguez at free dot fr Target Milestone: --- Exceptions with tracebacks enabled (gnatbind -E switch) cause a STORAGE_ERROR on kfreebsd-i386 when raised in a task rendezvous. procedure Main is task Test_Task is entry Rendezvous; end Test_Task; task body Test_Task is begin accept Rendezvous do raise Constraint_Error with "Some error occurred"; end Rendezvous; end Test_Task; begin Test_Task.Rendezvous; end Main; This code compiles and run without tracebacks in exception occurrences. If compiled with tracebacks: # gnatmake -v main -bargs -E it produces the following result: # Execution terminated by unhandled exception # Exception name: STORAGE_ERROR # Message: s-intman.adb:139 explicit raise The whole story can be found at https://bugs.debian.org/666106.
[Bug ada/67837] New: Ada ATC with delay abort syscalls not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67837
Bug ID: 67837
Summary: Ada ATC with delay abort syscalls not working
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: nicolas.boulenguez at free dot fr
Target Milestone: ---
As I understand the reference manual, the following program
with Ada.Calendar; use Ada.Calendar;
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.C; use Interfaces.C;
procedure Main is
function usleep (Secs : int) return int;
pragma Import (C, usleep, "usleep");
Res: int;
Start_Time : Time := Clock;
begin
select
delay 1.0;
Put_Line ("OK:" & Integer'Image (Integer (Clock - Start_Time)));
then abort
Res := usleep (10_000_000);
Put_Line ("KO:" & Integer'Image (Integer (Clock - Start_Time)));
end select;
end Main;
should produce
OK: 1
Instead, on amd64 with gnat-5.2.1-17:
KO: 1
OK: 1
and on mips with gnat-5.2.1-19:
KO: 10
OK: 10
The whole history can be found at https://bugs.debian.org/673772.
[Bug fortran/67818] [5 Regression] FAIL: libgomp.fortran/alloc-comp-[23].f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67818 --- Comment #8 from H.J. Lu --- (In reply to Mikael Morin from comment #4) > I have looked at the r222477 patch more in details, and it seems reasonable > after all. > Moreover, Paul suggested a backport when he approved it. > So I think I'll go the backport route. > HJL, can you confirm it fixes the problem? Yes, r222477 fixed the regression on gcc-5-branch without any new testsuite failures.
[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758 --- Comment #5 from Mikael Morin --- Author: mikael Date: Sun Oct 4 12:30:16 2015 New Revision: 228457 URL: https://gcc.gnu.org/viewcvs?rev=228457&root=gcc&view=rev Log: Fix fortran common-related error recovery ICE. Upon reverting a symbol in a common block (after throwing an error), the compiler was ICEing because the symbol's common_block field was set, but the symbol was not in the common block's list of symbols. Fixed by both adding the symbol to the common block list and setting the symbol's common_block field at the same time. Furthermore, the gfc_add_in_common call is delayed and its result is ignored, so that its error messages are ignored and the compiler has the opportunity to give a better error message. Another gfc_add_in_common call is added later during resolution to emit again the missing errors. PR fortran/67758 gcc/fortran/ * match.c (gfc_match_common): Delay the common_block pointer assignment after error checking. Delay the call to gfc_add_in_common attribute after the handling of array specs. * resolve.c (resolve_common_vars): Call gfc_add_in_common again. gcc/testsuite/ * gfortran.dg/common_24.f: New. Added: trunk/gcc/testsuite/gfortran.dg/common_24.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67838] New: Rejects-valid-code: templated lambda variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67838
Bug ID: 67838
Summary: Rejects-valid-code: templated lambda variable.
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
GCC 5.2 fails to compile the code below, erroneously citing "error: use of
'TestFunc' before deduction of 'auto'".
Compiles fine in Clang 3.5.
#include
template
static auto TestFunc = [](int param1)
{
return param1;
};
template
static void test(Func func)
{
printf("%d\n", func(12345));
}
int main()
{
test(TestFunc);
test(TestFunc);
}
[Bug c++/67838] Rejects-valid-code: templated lambda variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67838 --- Comment #1 from Joel Yliluoma --- Note that the use of "template" here is to declare a parametric variable. It is not for the function's parameter list. It works the same way as in this expression: template int v = 3*LMode;
[Bug c++/67838] Rejects-valid-code: templated lambda variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67838 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-04 CC||trippels at gcc dot gnu.org Known to work||6.0 Ever confirmed|0 |1 Known to fail||5.2.1 Severity|major |normal --- Comment #2 from Markus Trippelsdorf --- Confirmed. Working fine with gcc-6.
[Bug target/67839] New: Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 Bug ID: 67839 Summary: Bit addressable instructions generated for invalid memory address Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: senthil_kumar.selvaraj at atmel dot com Target Milestone: --- Bit addressable instructions (sbi, cbi, sbis, sbic) only work on IO addresses 0x0-0x1f (inclusive). The compiler generates these instructions for IO address 0x20 as well. The problem is in the specification of low_io_address_operand predicate, which has (define_special_predicate "low_io_address_operand" (ior (and (match_code "const_int") (match_test "IN_RANGE (INTVAL (op) - avr_arch->sfr_offset, 0, 0x20 - GET_MODE_SIZE (mode))")) (and (match_code "symbol_ref") (match_test "SYMBOL_REF_FLAGS (op) & SYMBOL_FLAG_IO_LOW" While this looks ok, gcc invokes low_io_address_operand with mode set to VOID, and GET_MODE_SIZE for VOID returns 0, so the effective range becomes 0x0-0x20. gcc does pass the correct mode if the operand mode is set in the define_insn that uses this predicate. Don't know why it isn't set, and why define_special_predicate is used instead of define_predicate. Note that io_address_operand predicate has a GET_MODE_SIZE call as well, so the range check is off by one in it too
[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66697
--- Comment #2 from Uroš Bizjak ---
IMO, if "outside" code misaligns stack, then these applications need support
for -mincoming-stack-boundary=3, which is currently limited on x86_64 to 4.
Documentation says:
'-mincoming-stack-boundary=NUM'
Assume the incoming stack is aligned to a 2 raised to NUM byte
boundary. If '-mincoming-stack-boundary' is not specified, the one
specified by '-mpreferred-stack-boundary' is used.
[...]
Following patch:
--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 228460)
+++ config/i386/i386.c (working copy)
@@ -5102,8 +5102,7 @@ ix86_option_override_internal (bool main_args_p,
ix86_incoming_stack_boundary = ix86_default_incoming_stack_boundary;
if (opts_set->x_ix86_incoming_stack_boundary_arg)
{
- int min = (TARGET_64BIT_P (opts->x_ix86_isa_flags)
-? (TARGET_SSE_P (opts->x_ix86_isa_flags) ? 4 : 3) : 2);
+ int min = TARGET_64BIT_P (opts->x_ix86_isa_flags) ? 3 : 2;
if (opts->x_ix86_incoming_stack_boundary_arg < min
|| opts->x_ix86_incoming_stack_boundary_arg > 12)
--cut here--
will compile following test:
-- cut here--
typedef float v4sf __attribute__((vector_size(16)));
v4sf test (v4sf a, v4sf b)
{
volatile v4sf z = a + b;
return z;
}
--cut here--
using "-O2 -mincoming-stack-boundary=3" to:
:
0: 4c 8d 54 24 08 lea0x8(%rsp),%r10
5: 0f 58 c8addps %xmm0,%xmm1
8: 48 83 e4 f0 and$0xfff0,%rsp
c: 41 ff 72 f8 pushq -0x8(%r10)
10: 55 push %rbp
11: 48 89 e5mov%rsp,%rbp
14: 41 52 push %r10
16: 0f 29 4d e0 movaps %xmm1,-0x20(%rbp)
1a: 0f 28 45 e0 movaps -0x20(%rbp),%xmm0
1e: 41 5a pop%r10
20: 5d pop%rbp
21: 49 8d 62 f8 lea-0x8(%r10),%rsp
25: c3 retq
The stack realignment code ensures ABI-compliant stack alignment in all
functions - and is kind of punishment for rogue application.
[Bug c/67840] New: #define function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67840
Bug ID: 67840
Summary: #define function error
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ka_bena at yahoo dot fr
Target Milestone: ---
/* #define function error */
#include
#include
#include
#define tadjib(x) (sizeof( x )== sizeof( float ) ?cosf(x) \
:sizeof( x )== sizeof( double ) ?cos(x) \
:sizeof( x ) == sizeof( long double )?cosl(x) \
:cosq(x))
int main(void)
{
float x = tadjib(1.F) ;
double y = tadjib(1. ) ;
long double z = tadjib(1.L) ;
printf("%E \n" , x ) ;
printf("%E \n" , y ) ;
printf("%LE \n" , z ) ;
printf("\n");
float x1 = 1.F ;
double y1 = 1. ;
long double z1 = 1.L ;
printf ( "%E \n" , tadjib(x1) ) ;
printf ( "%E \n" , tadjib(y1) ) ;
printf ( "%LE \n" , tadjib(z1) ) ;
return 0 ;
}
/*
main_test_generic.c: In function ‘main’:
main_test_generic.c:29:4: warning: format ‘%E’ expects argument of type
‘double’, but argument 2 has type ‘__float128’ [-Wformat=]
printf ( "%E \n" , tadjib(x1) ) ;
^
main_test_generic.c:30:4: warning: format ‘%E’ expects argument of type
‘double’, but argument 2 has type ‘__float128’ [-Wformat=]
printf ( "%E \n" , tadjib(y1) ) ;
^
main_test_generic.c:31:4: warning: format ‘%LE’ expects argument of type ‘long
double’, but argument 2 has type ‘__float128’ [-Wformat=]
printf ( "%LE \n" , tadjib(z1) ) ;
^
Done.*/
/* Results::
main_test_generic.exe
5.403023E-01
5.403023E-01
5.403023E-01
-5.610234E-259
5.403023E-01
5.403023E-01
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
gcc -std=gnu99 -omain_test_generic.exe main_test_generic.c -lm -lquadmath ;
*/
[Bug ada/67837] Ada ATC with delay abort syscalls not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67837 Arnaud Charlet changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||charlet at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Arnaud Charlet --- Actually Ada does not make any guarantee when mixing ATC and system calls and indeed, it is fundamentally unsafe if not impossible to properly abort from any random system call, so this isn't supported.
[Bug c/67840] #define function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67840 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- For ?: both sides are converted into a single type which in case is __float128. There is _Generic or the other builtin which does not suffer this issue.
[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66697 Uroš Bizjak changed: What|Removed |Added Target||x86_64 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-10-04 See Also||https://bugs.winehq.org/sho ||w_bug.cgi?id=27680 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- Proposed patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00342.html
[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758 Dominique d'Humieres changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Dominique d'Humieres --- If I compile the test as free form before r228458, I get the following ICE [Book15] f90/bug% gfc pr67758.f90 pr67758.f90:1:26: COMMON /FMCOM / X(80 000 000) 1 Error: Expected another dimension in array declaration at (1) pr67758.f90:3:27: COMMON /FMCOM / XX(80 000 000) 1 Error: Expected another dimension in array declaration at (1) Segmentation fault: 11 Internal compiler error: Error reporting routines re-entered. gfc: internal compiler error: Abort trap: 6 (program f951) or if configured with --enable-checking=release [Book15] f90/bug% gfcp pr67758.f90 pr67758.f90:1:26: COMMON /FMCOM / X(80 000 000) 1 Error: Expected another dimension in array declaration at (1) pr67758.f90:3:27: COMMON /FMCOM / XX(80 000 000) 1 Error: Expected another dimension in array declaration at (1) (null):0: confused by earlier errors, bailing out After r228458, I get [Book15] f90/bug% gfc pr67758.f90 pr67758.f90:1:26: COMMON /FMCOM / X(80 000 000) 1 Error: Expected another dimension in array declaration at (1) pr67758.f90:3:27: COMMON /FMCOM / XX(80 000 000) 1 Error: Expected another dimension in array declaration at (1) in gfc_format_decoder, at fortran/error.c:936 Internal compiler error: Error reporting routines re-entered. then gfortran hangs.
[Bug target/67447] [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67447 --- Comment #2 from Uroš Bizjak --- This PR is fixed by the fix [1] for PR 67756. I will add the testcase and close this PR. [1] https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00225.html
[Bug target/67447] [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67447 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Sun Oct 4 15:56:45 2015 New Revision: 228461 URL: https://gcc.gnu.org/viewcvs?rev=228461&root=gcc&view=rev Log: PR rtl-optimization/67447 * gcc.target/i386/pr67447.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr67447.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/67447] [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67447 Uroš Bizjak changed: What|Removed |Added Target|x86_64-linux-gnu|x86 Status|UNCONFIRMED |RESOLVED Component|target |rtl-optimization Depends on||67756 Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756 [Bug 67756] [6 Regression] ICE compiling Linux Kernel fs/namei.c on ARM
[Bug target/67717] [6.0 regression] ICE when compiling WRF benchmark from cpu2006 with -Ofast -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67717 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Uroš Bizjak --- Dup. *** This bug has been marked as a duplicate of bug 67447 ***
[Bug rtl-optimization/67447] [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67447 Uroš Bizjak changed: What|Removed |Added CC||vekumar at gcc dot gnu.org --- Comment #5 from Uroš Bizjak --- *** Bug 67717 has been marked as a duplicate of this bug. ***
[Bug other/67841] New: Can't use vector registers if all vector registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841
Bug ID: 67841
Summary: Can't use vector registers if all vector registers are
callee-saved
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com
Blocks: 67552
Target Milestone: ---
Target: x86
[hjl@gnu-tools-1 interrupt-1]$ cat y.i
typedef float xmm_t __attribute__ ((__vector_size__ (16)));
extern xmm_t x, y;
void
__attribute__((no_caller_saved_registers))
fn (void)
{
x = __builtin_ia32_addss (x, y);
}
[hjl@gnu-tools-1 interrupt-1]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 y.i
y.i: In function ‘fn’:
y.i:10:1: error: unable to find a register to spill
}
^
y.i:10:1: error: this is the insn:
(insn 6 12 13 2 (set (reg:V4SF 92)
(vec_merge:V4SF (plus:V4SF (reg:V4SF 92)
(mem/c:V4SF (symbol_ref:DI ("y") [flags 0x40] ) [1 y+0 S16 A128]))
(reg:V4SF 92)
(const_int 1 [0x1]))) y.i:9 1410 {sse_vmaddv4sf3}
(expr_list:REG_EQUIV (mem/c:V4SF (symbol_ref:DI ("x") [flags 0x40]
) [1 x+0 S16 A128])
(nil)))
y.i:10:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1431
0xceef23 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/gnu/import/git/sources/gcc/gcc/rtl-error.c:109
0xbb54ba assign_by_spills
/export/gnu/import/git/sources/gcc/gcc/lra-assigns.c:1431
0xbb5e1d lra_assign()
/export/gnu/import/git/sources/gcc/gcc/lra-assigns.c:1606
0xbaf6f7 lra(_IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/lra.c:2343
0xb5c4f5 do_reload
/export/gnu/import/git/sources/gcc/gcc/ira.c:5391
0xb5c8a8 execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[hjl@gnu-tools-1 interrupt-1]$
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
[Bug 67552] [meta] x86 interrupt attribute
[Bug other/67841] error: unable to find a register to spill if all vector registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841
H.J. Lu changed:
What|Removed |Added
Summary|Can't use vector registers |error: unable to find a
|if all vector registers are |register to spill if all
|callee-saved|vector registers are
||callee-saved
--- Comment #1 from H.J. Lu ---
Same problem with integer registers:
[hjl@gnu-tools-1 interrupt-1]$ cat i.i
extern int bar (int);
__attribute__((no_caller_saved_registers))
void foo (void)
{
int a,b,c,d,e,f,i;
a = bar (5);
b = bar (a);
c = bar (b);
d = bar (c);
e = bar (d);
f = bar (e);
for (i = 1; i < 10; i++)
{
a += bar (a + i) + bar (b + i) +
bar (c + i) + bar (d + i) +
bar (e + i) + bar (f + i);
}
}
[hjl@gnu-tools-1 interrupt-1]$ cat i.i
extern int bar (int);
__attribute__((no_caller_saved_registers))
void foo (void)
{
int a,b,c,d,e,f,i;
a = bar (5);
b = bar (a);
c = bar (b);
d = bar (c);
e = bar (d);
f = bar (e);
for (i = 1; i < 10; i++)
{
a += bar (a + i) + bar (b + i) +
bar (c + i) + bar (d + i) +
bar (e + i) + bar (f + i);
}
}
[hjl@gnu-tools-1 interrupt-1]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2
-mincoming-stack-boundary=2 -S i.i -m32
i.i: In function ‘foo’:
i.i:19:1: error: unable to find a register to spill
}
^
i.i:19:1: error: this is the insn:
(insn 67 114 113 3 (parallel [
(set (reg:SI 150 [orig:103 _35 ] [103])
(plus:SI (reg:SI 150 [orig:103 _35 ] [103])
(reg:SI 151 [orig:104 _38 ] [104])))
(clobber (reg:CC 17 flags))
]) i.i:17 216 {*addsi_1}
(expr_list:REG_DEAD (reg:SI 151 [orig:104 _38 ] [104])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
i.i:19:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1431
0xceef23 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/gnu/import/git/sources/gcc/gcc/rtl-error.c:109
0xbb54ba assign_by_spills
/export/gnu/import/git/sources/gcc/gcc/lra-assigns.c:1431
0xbb5e1d lra_assign()
/export/gnu/import/git/sources/gcc/gcc/lra-assigns.c:1606
0xbaf6f7 lra(_IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/lra.c:2343
0xb5c4f5 do_reload
/export/gnu/import/git/sources/gcc/gcc/ira.c:5391
0xb5c8a8 execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[hjl@gnu-tools-1 interrupt-1]$
[Bug tree-optimization/67842] New: Incorrect check in sese.h:bb_in_region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67842 Bug ID: 67842 Summary: Incorrect check in sese.h:bb_in_region Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: ice-checking Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: miyuki at gcc dot gnu.org Target Milestone: --- >From discussion on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00615.html The function bb_in_region contains the following check guarded by ENABLE_CHECKING: edge e; edge_iterator ei; /* Check that there are no edges coming in the region: all the predecessors of EXIT are dominated by ENTRY. */ FOR_EACH_EDGE (e, ei, exit->preds) dominated_by_p (CDI_DOMINATORS, e->src, entry); dominated_by_p is a pure function, so the check has no effect. If it is changed to gcc_assert (dominated_by_p (CDI_DOMINATORS, e->src, entry)); It starts to ICE on several testcases, for example gcc.dg/graphite/block-1.c.
[Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 Bug ID: 67843 Summary: experimental/filesystem/iterators/directory_iterator.c c fails on armv5t Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- ./experimental/filesystem/iterators/directory_iterator.cc fails when compiled with -march=armv5t: *** Error in `./directory_iterator.exe': malloc(): memory corruption: 0x40b787f7 ***^M To reproduce it, you can build an armv7* toolchain, can compile this testcase with -march=armv5t, and execute the result. I chose the libstdc++ category for the time being, but it could very well be target dependent bug (since it works on armv7-a for instance).
[Bug other/67841] error: unable to find a register to spill if all vector registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841 --- Comment #2 from H.J. Lu --- find_drap_reg in i386.c requires one scratch register. -maccumulate-outgoing-args may be used to avoid it.
[Bug c++/67844] New: Cannot make tuple of class with template constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67844 Bug ID: 67844 Summary: Cannot make tuple of class with template constructor Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rbock at eudoxos dot de Target Milestone: --- Created attachment 36443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36443&action=edit struct with template constructor, instantiate, try to make_tuple from the instance If the constructor of a class is a template (see attached code), trying to call make_tuple on an instance of this class fails to compile with g++-6.0.0. The first error in the output is include/c++/6.0.0/type_traits:138:12: error: invalid use of incomplete type ‘struct std::is_convertible&, A>’ g++-4.9 as well as clang-3.[456] compile the code just fine.
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 --- Comment #1 from Jonathan Wakely --- I'm unable to build an armv7 toolchain, it keeps failing with an ICE, so I'll need more information to do anything about this.
[Bug other/67841] error: unable to find a register to spill if all vector registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841 --- Comment #3 from Uroš Bizjak --- (In reply to H.J. Lu from comment #2) > find_drap_reg in i386.c requires one scratch register. > -maccumulate-outgoing-args may be used to avoid it. How about we push scratch reg to the stack as the first thing we enter the function, and pop it off the stack before iret?
[Bug other/67841] error: unable to find a register to spill if all registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841 --- Comment #4 from H.J. Lu --- (In reply to Uroš Bizjak from comment #3) > (In reply to H.J. Lu from comment #2) > > find_drap_reg in i386.c requires one scratch register. > > -maccumulate-outgoing-args may be used to avoid it. > > How about we push scratch reg to the stack as the first thing we enter the > function, and pop it off the stack before iret? We can try that.
[Bug other/67841] error: unable to find a register to spill if all registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841
--- Comment #5 from H.J. Lu ---
I updated hjl/interrupt/calls branch to update stack boundary for
use of SSE registers. Now I got
[hjl@gnu-tools-1 interrupt-1]$ cat x.i
void
__attribute__((no_caller_saved_registers))
fn (void)
{
asm ("#"
:
:
: "xmm3");
}
[hjl@gnu-tools-1 interrupt-1]$ make x.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -m32
-mincoming-stack-boundary=2 -maccumulate-outgoing-args -S x.i
[hjl@gnu-tools-1 interrupt-1]$ cat x.s
.file "x.i"
.text
.p2align 4,,15
.globl fn
.type fn, @function
fn:
.LFB0:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$136, %esp
andl$-16, %esp
movups %xmm3, -136(%ebp)
.cfi_offset 24, -144
#APP
# 5 "x.i" 1
#
# 0 "" 2
#NO_APP
movups -136(%ebp), %xmm3
leave
.cfi_restore 5
.cfi_restore 24
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE0:
.size fn, .-fn
.ident "GCC: (GNU) 6.0.0 20151002 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 interrupt-1]$
But is incompatible how registers are saved in prologue
which uses the original stack before realignment to save
registers. To use aligned load/store to save vector
registers in prologue requires significant changes.
[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66697 --- Comment #4 from Justas L --- I haven't tested this yet, but I understand this global solution would affect the performance of ALL functions, not only those that interface with outside code, correct? Wine already assigns the force_align_arg_pointer attribute to vulnerable functions, so making it work for x86_64 would be the better, less disruptive solution.
[Bug c++/67844] [6 Regression] Cannot make tuple of class with template constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67844 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-04 CC||ville at gcc dot gnu.org Target Milestone|--- |6.0 Summary|Cannot make tuple of class |[6 Regression] Cannot make |with template constructor |tuple of class with ||template constructor Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Ville, I haven't looked into what's happening here yet, do you see anything obvious?
[Bug other/67841] error: unable to find a register to spill if all registers are callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841 --- Comment #6 from H.J. Lu --- ix86_expand_prologue in i386.c has /* The computation of the size of the re-aligned stack frame means that we must allocate the size of the register save area before performing the actual alignment. Otherwise we cannot guarantee that there's enough storage above the realignment point. */ That is where unaligned SSE load/store in prologue come from.
[Bug c++/67844] [6 Regression] Cannot make tuple of class with template constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67844 Ville Voutilainen changed: What|Removed |Added Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen --- To the extent anything in this area is obvious, yes. :) The check for non-nested tuple ends up in infinite meta-recursion because A is constructible from the tuple itself. I think that can be tackled by adding an is_same check to _TNTC so that the converting templates that take a tuple outright reject tuples that are the same as the tuple itself. Fixing...
[Bug c++/67845] New: ICE on invalid use of const qualifier on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67845 Bug ID: 67845 Summary: ICE on invalid use of const qualifier on x86_64-linux-gnu Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- The following code causes an ICE when compiled with the current gcc trunk on x86_64-linux-gnu. This is a regression from 5.2.x. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 6.0.0 20151004 (experimental) [trunk revision 228457] (GCC) $ $ g++-5.2 -c small.cc small.cc:3:3: error: non-member function ‘void foo()’ cannot have cv-qualifier F foo; ^ small.cc:4: confused by earlier errors, bailing out $ $ $ g++-trunk -c small.cc small.cc:3:3: error: non-member function ‘void foo()’ cannot have cv-qualifier F foo; ^ small.cc:4:11: internal compiler error: in merge_types, at cp/typeck.c:854 void foo (); ^ 0x71e224 merge_types(tree_node*, tree_node*) ../../gcc-trunk/gcc/cp/typeck.c:854 0x5f8f72 duplicate_decls(tree_node*, tree_node*, bool) ../../gcc-trunk/gcc/cp/decl.c:2029 0x7bd77e pushdecl_maybe_friend_1 ../../gcc-trunk/gcc/cp/name-lookup.c:812 0x7bd77e pushdecl_maybe_friend(tree_node*, bool) ../../gcc-trunk/gcc/cp/name-lookup.c:1305 0x6134e3 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc-trunk/gcc/cp/decl.c:4913 0x7016b2 cp_parser_init_declarator ../../gcc-trunk/gcc/cp/parser.c:18042 0x702282 cp_parser_simple_declaration ../../gcc-trunk/gcc/cp/parser.c:11956 0x6fda24 cp_parser_block_declaration ../../gcc-trunk/gcc/cp/parser.c:11837 0x70bfd7 cp_parser_declaration ../../gcc-trunk/gcc/cp/parser.c:11734 0x70a53a cp_parser_declaration_seq_opt ../../gcc-trunk/gcc/cp/parser.c:11613 0x70a880 cp_parser_translation_unit ../../gcc-trunk/gcc/cp/parser.c:4169 0x70a880 c_parse_file() ../../gcc-trunk/gcc/cp/parser.c:34599 0x857542 c_common_parse_file() ../../gcc-trunk/gcc/c-family/c-opts.c:1064 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. $ -- typedef void F () const; F foo; void foo ();
[Bug c++/67845] ICE on invalid use of const qualifier on x86_64-linux-gnu in merge_types, at cp/typeck.c:854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67845 --- Comment #1 from Andrew Pinski --- >This is a regression from 5.2.x. No it is not because 5.2 does: > small.cc:4: confused by earlier errors, bailing out Which is just saying there was an ICE after an error had been produced :). --enable-checking disables that and the trunk defaults to that mode.
[Bug c++/67846] New: ICE on code with lambda expression on x86_64-linux-gnu in check_return_expr, at cp/typeck.c:8609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67846
Bug ID: 67846
Summary: ICE on code with lambda expression on x86_64-linux-gnu
in check_return_expr, at cp/typeck.c:8609
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151004 (experimental) [trunk revision 228457] (GCC)
$
$ g++-trunk -c small.cc
small.cc: In lambda function:
small.cc:5:23: error: invalid use of member function (did you forget the ‘()’
?)
[=] { return foo; };
^
small.cc:5:23: internal compiler error: in check_return_expr, at
cp/typeck.c:8609
0x723c8d check_return_expr(tree_node*, bool*)
../../gcc-trunk/gcc/cp/typeck.c:8609
0x7610be finish_return_stmt(tree_node*)
../../gcc-trunk/gcc/cp/semantics.c:873
0x705e44 cp_parser_lambda_body
../../gcc-trunk/gcc/cp/parser.c:9855
0x705e44 cp_parser_lambda_expression
../../gcc-trunk/gcc/cp/parser.c:9360
0x6d92b7 cp_parser_primary_expression
../../gcc-trunk/gcc/cp/parser.c:4713
0x6e410b cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6404
0x6e4c99 cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7689
0x6e58d7 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8442
0x6e5fdf cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:8700
0x6e89f1 cp_parser_expression
../../gcc-trunk/gcc/cp/parser.c:8854
0x6e9cb6 cp_parser_expression_statement
../../gcc-trunk/gcc/cp/parser.c:10270
0x6ff07a cp_parser_statement
../../gcc-trunk/gcc/cp/parser.c:10121
0x6ffee9 cp_parser_statement_seq_opt
../../gcc-trunk/gcc/cp/parser.c:10393
0x70004b cp_parser_compound_statement
../../gcc-trunk/gcc/cp/parser.c:10347
0x70025b cp_parser_function_body
../../gcc-trunk/gcc/cp/parser.c:20112
0x70025b cp_parser_ctor_initializer_opt_and_function_body
../../gcc-trunk/gcc/cp/parser.c:20148
0x7010f9 cp_parser_function_definition_after_declarator
../../gcc-trunk/gcc/cp/parser.c:24755
0x704cdc cp_parser_late_parsing_for_member
../../gcc-trunk/gcc/cp/parser.c:25559
0x6e0199 cp_parser_class_specifier_1
../../gcc-trunk/gcc/cp/parser.c:20972
0x6e0199 cp_parser_class_specifier
../../gcc-trunk/gcc/cp/parser.c:20998
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.
$
--
class A
{
void foo ()
{
[=] { return foo; };
}
};
[Bug c++/67847] New: ICE on (invalid) nested enum declaration on x86_64-linux-gnu in is_ancestor, at cp/name-lookup.c:2771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67847
Bug ID: 67847
Summary: ICE on (invalid) nested enum declaration on
x86_64-linux-gnu in is_ancestor, at
cp/name-lookup.c:2771
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk (and
earlier GCC versions) on x86_64-linux-gnu.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151004 (experimental) [trunk revision 228457] (GCC)
$
$ g++-trunk -c small.cc
small.cc:4:11: internal compiler error: in is_ancestor, at
cp/name-lookup.c:2771
enum T::Color {R, G, B} c;
^
0x7b285c is_ancestor(tree_node*, tree_node*)
../../gcc-trunk/gcc/cp/name-lookup.c:2770
0x6f1b84 cp_parser_enum_specifier
../../gcc-trunk/gcc/cp/parser.c:16736
0x6df7e5 cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:15330
0x6f067b cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:12324
0x703ef9 cp_parser_member_declaration
../../gcc-trunk/gcc/cp/parser.c:21718
0x6dfa34 cp_parser_member_specification_opt
../../gcc-trunk/gcc/cp/parser.c:21570
0x6dfa34 cp_parser_class_specifier_1
../../gcc-trunk/gcc/cp/parser.c:20762
0x6dfa34 cp_parser_class_specifier
../../gcc-trunk/gcc/cp/parser.c:20998
0x6dfa34 cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:15358
0x6f067b cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:12324
0x702828 cp_parser_single_declaration
../../gcc-trunk/gcc/cp/parser.c:25124
0x702bbb cp_parser_template_declaration_after_parameters
../../gcc-trunk/gcc/cp/parser.c:24816
0x7037a4 cp_parser_explicit_template_declaration
../../gcc-trunk/gcc/cp/parser.c:25051
0x7037a4 cp_parser_template_declaration_after_export
../../gcc-trunk/gcc/cp/parser.c:25069
0x70c179 cp_parser_declaration
../../gcc-trunk/gcc/cp/parser.c:11691
0x70a53a cp_parser_declaration_seq_opt
../../gcc-trunk/gcc/cp/parser.c:11613
0x70a880 cp_parser_translation_unit
../../gcc-trunk/gcc/cp/parser.c:4169
0x70a880 c_parse_file()
../../gcc-trunk/gcc/cp/parser.c:34599
0x857542 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
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.
$
template < typename T >
class D
{
enum T::Color {R, G, B} c;
};
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 --- Comment #2 from Christophe Lyon --- I am not sure what kind of helpful information I can provide. Can you build a cross-compiler (x86 -> armv7-a)? This is what I do and I haven't seen the ICE you mention (I was using r228286).
