[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org ---
After some debugging, root cause appears to be in initialization of
pic_offset_table_rtx.
In i386.h:
/* Register to hold the addressing base for position independent
code access to data items. We don't use PIC pointer for 64bit
mode. Define the regnum to dummy value to prevent gcc from
pessimizing code dealing with EBX.
To avoid clobbering a call-saved register unnecessarily, we renumber
the pic register when possible. The change is visible after the
prologue has been emitted. */
#define REAL_PIC_OFFSET_TABLE_REGNUM (TARGET_64BIT ? R15_REG : BX_REG)
#define PIC_OFFSET_TABLE_REGNUM\
((TARGET_64BIT (ix86_cmodel == CM_SMALL_PIC\
|| TARGET_PECOFF))\
|| !flag_pic\
? INVALID_REGNUM\
: pic_offset_table_rtx\
? INVALID_REGNUM\
: REAL_PIC_OFFSET_TABLE_REGNUM)
and in emit-rtl.c:init_emit_regs:
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
else
pic_offset_table_rtx = NULL_RTX;
Adding some debugging prints there:
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -5872,10 +5872,18 @@ init_emit_regs (void)
= gen_raw_REG (Pmode, RETURN_ADDRESS_POINTER_REGNUM);
#endif
+ debug (pic_offset_table_rtx);
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
-pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
+{
+ printf (calling gen_raw_REG\n);
+ pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
+}
else
-pic_offset_table_rtx = NULL_RTX;
+{
+ printf (not calling gen_raw_REG\n);
+ pic_offset_table_rtx = NULL_RTX;
+}
+ debug (pic_offset_table_rtx);
for (i = 0; i (int) MAX_MACHINE_MODE; i++)
{
For 32-bit PIC, there appears to be some circular logic in this
initialization; if this has already been called, then
pic_offset_table_rtx is non-NULL, so PIC_OFFSET_TABLE_REGNUM
is INVALID_REGNUM, and so on reinitialization, it transitions back to
NULL.
Indeed, with test-empty.c, we see the NULL/non-NULL-ness of
pic_offset_table_rtx toggle at each iteration:
ITERATION 1
PASSED: test-empty.c.exe iteration 1 of 5: set_up_logging: logfile is
non-null
NOTE: test-empty.c.exe iteration 1 of 5: writing reproducer to
./test-empty.c.exe.reproducer.c
test-empty.c.exe iteration 1 of 5: writing reproducer to .
nil
calling gen_raw_REG
(reg:SI 3 bx)
intermediate files written to /tmp/libgccjit-n2vMx2
PASSED: test-empty.c.exe iteration 1 of 5: verify_code: result is
non-null
ITERATION 2
PASSED: test-empty.c.exe iteration 2 of 5: set_up_logging: logfile is
non-null
NOTE: test-empty.c.exe iteration 2 of 5: writing reproducer to
./test-empty.c.exe.reproducer.c
test-empty.c.exe iteration 2 of 5: writing reproducer to .
(reg:SI 3 bx)
not calling gen_raw_REG
nil
intermediate files written to /tmp/libgccjit-qF4SVX
PASSED: test-empty.c.exe iteration 2 of 5: verify_code: result is
non-null
ITERATION 3
PASSED: test-empty.c.exe iteration 3 of 5: set_up_logging: logfile is
non-null
NOTE: test-empty.c.exe iteration 3 of 5: writing reproducer to
./test-empty.c.exe.reproducer.c
test-empty.c.exe iteration 3 of 5: writing reproducer to .
nil
calling gen_raw_REG
(reg:SI 3 bx)
intermediate files written to /tmp/libgccjit-mw8kAT
PASSED: test-empty.c.exe iteration 3 of 5: verify_code: result is
non-null
ITERATION 4
PASSED: test-empty.c.exe iteration 4 of 5: set_up_logging: logfile is
non-null
NOTE: test-empty.c.exe iteration 4 of 5: writing reproducer to
./test-empty.c.exe.reproducer.c
test-empty.c.exe iteration 4 of 5: writing reproducer to .
(reg:SI 3 bx)
not calling gen_raw_REG
nil
intermediate files written to /tmp/libgccjit-h63OvP
PASSED: test-empty.c.exe iteration 4 of 5: verify_code: result is
non-null
ITERATION 5
PASSED: test-empty.c.exe iteration 5 of 5: set_up_logging: logfile is
non-null
NOTE: test-empty.c.exe iteration 5 of 5: writing reproducer to
./test-empty.c.exe.reproducer.c
test-empty.c.exe iteration 5 of 5: writing reproducer to .
nil
calling gen_raw_REG
(reg:SI 3 bx)
intermediate files written to /tmp/libgccjit-hzBrIL
PASSED: test-empty.c.exe iteration 5 of 5: verify_code: result is
non-null
i.e. on odd-numbered iterations it transitions from NULL to reg bx
on even-numbered iterations it transitions from non-NULL back to NULL.
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org ---
Indeed, adding this to toplev.c fixes the issue:
@@ -2166,7 +2169,8 @@ toplev::finalize (void)
{
rtl_initialized = false;
this_target_rtl-target_specific_initialized = false;
+ this_target_rtl-x_pic_offset_table_rtx = NULL;
/* Needs to be called before cgraph_c_finalize since it uses symtab. */
ipa_reference_c_finalize ();
fixes the issue; 5 iterations of test-hello-world.c run to completion.
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 22 Jan 2015, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
Index: tree-ssa-coalesce.c
===
--- tree-ssa-coalesce.c (revision 219989)
+++ tree-ssa-coalesce.c (working copy)
@@ -1213,8 +1215,11 @@ coalesce_partitions (var_map map, ssa_co
gsi_next (gsi))
{
gphi *phi = gsi.phi ();
- tree res = PHI_RESULT (phi);
tree arg = PHI_ARG_DEF (phi, e-dest_idx);
+ if (SSA_NAME_IS_DEFAULT_DEF (arg))
+ continue;
+
+ tree res = PHI_RESULT (phi);
int v1 = SSA_NAME_VERSION (res);
int v2 = SSA_NAME_VERSION (arg);
fixes it for me.
Is that right even when SSA_NAME_VAR is a PARM_DECL?
No, of course not.
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Can you explain it? Usually when this function is called, pic_offset_table_rtx is NULL and your i386.h macro relies on that. When initializing default target during initialization it is NULL of course, and apparently even in target_reinit, when it is called with freshly cleared heap object for the non-default target. It is just when jit calls the initialization again without clearing all the variables... So I believe my proposed change is correct. In any case, perhaps jit shouldn't reinitialize everything all the time, at least if the compilation options don't change.
[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 Hale Wang Hale.Wang at arm dot com changed: What|Removed |Added CC||Hale.Wang at arm dot com --- Comment #7 from Hale Wang Hale.Wang at arm dot com --- (In reply to Tim Pambor from comment #4) Created attachment 33307 [details] testcase for gcc 4.9.1 I think this bug is still present in gcc 4.9.1 and 4.8.4. I could reproduce the problem with the attached testcase using gcc 4.8.4 with -O1 and -Og and 4.9.1 with -O1. -O0, -O2, -O3, -Os generated correct code. It generated the following assembler code: ... mov r0, r0 @ r0 mov r4, r4 @ r1 mov r2, r2 @ r2 ... Expected would have been: ... mov r0, r0 @ r0 mov r1, r1 @ r1 mov r2, r2 @ r2 ... The combine pass combined the volatile register which caused this bug. The expected assembler code should be: mov r4, .L_temp mov r1, r4 ... mov r0, r0@ r0 mov r1, r1@ r1 mov r2, r2@ r2 But GCC combined the insns, and the code is generated as: mov r4, .L_temp ... mov r0, r0@ r0 mov r4, r4@ r1 mov r2, r2@ r2 The register 'r1' is defined as volatile in this case. It should not be combined.
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I'll reduce and bisect.
[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- If you are willing to cook up an effective-target for that in lib/target-supports.exp, sure, go ahead. Given the complexity of the HAVE_COMDAT_GROUP test in gcc/configure.ac, the best way seems to have gcc define something like __GCC_HAVE_COMDAT_GROUP and use that in target-supports.exp. Rainer
[Bug testsuite/63439] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- Also FAILs on Solaris/SPARC: FAIL: gcc.dg/vect/vect-33.c -flto -ffat-lto-objects scan-tree-dump-times vect Alignment of access forced using versioning 1 FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-times vect Alignment of access forced using versioning 1 Rainer
[Bug tree-optimization/64728] New: internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 Bug ID: 64728 Summary: internal compiler error: SSA corruption Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Created attachment 34528 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34528action=edit preprocessed source $ ./cc1 -quiet -O x.i -o /dev/null Unable to coalesce ssa_names 158 and 160 which are marked as MUST COALESCE. start_position_158(ab) and start_position_160(ab) src/openslide-vendor-hamamatsu.c: In function ‘read_from_jpeg’: src/openslide-vendor-hamamatsu.c:599:11: internal compiler error: SSA corruption 0xe31965 fail_abnormal_edge_coalesce /home/marek/src/gcc/gcc/tree-ssa-coalesce.c:927 0xe32950 coalesce_partitions /home/marek/src/gcc/gcc/tree-ssa-coalesce.c:1225 0xe3301a coalesce_ssa_name() /home/marek/src/gcc/gcc/tree-ssa-coalesce.c:1370 0xdb8a08 remove_ssa_form /home/marek/src/gcc/gcc/tree-outof-ssa.c:1018 0xdb9318 rewrite_out_of_ssa(ssaexpand*) /home/marek/src/gcc/gcc/tree-outof-ssa.c:1252 0x7edd69 execute /home/marek/src/gcc/gcc/cfgexpand.c:5817 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.
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|internal compiler error:|[5 Regression] internal |SSA corruption |compiler error: SSA ||corruption
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- But then wonder if/how target_reinit works for i?86 32-bit. Perhaps pic_offset_table_rtx should be cleared in init_emit_regs before computing it? pic_offset_table_rtx = NULL_RTX; if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
[Bug fortran/64726] [OpenACC] ICE with -fopenacc and reduction(+:a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64726 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Patch, lightly tested. (The test case will later fail in gimplify.c with sorry, not implemented.) (In the function below, only op == EXEC_OACC_PARALLEL_LOOP or op == EXEC_OACC_KERNELS_LOOP are permitted [otherwise: assert].) --- a/gcc/fortran/trans-openmp.c +++ b/gcc/fortran/trans-openmp.c @@ -3440,3 +3440,3 @@ gfc_trans_oacc_combined_directive (gfc_code *code) pushlevel (); - stmt = gfc_trans_omp_do (code, code-op, pblock, loop_clauses, NULL); + stmt = gfc_trans_omp_do (code, EXEC_OACC_LOOP, pblock, loop_clauses, NULL); if (TREE_CODE (stmt) != BIND_EXPR)
[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- dg-bogus is better, yet. FWIW, the patch has been successfully regtested/bootstrapped now.
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Also, if you keep pic_offset_table_rtx NULL, then PIC_OFFSET_TABLE_REGNUM will be 3 instead of -1 in other places.
[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Andrew, are you going to post the patch? I think it is pretty obvious...
[Bug c/63307] [4.9 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-22 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[4.9/5 Regression] Cilk+|[4.9 Regression] Cilk+ |breaks -fcompare-debug |breaks -fcompare-debug |bootstrap |bootstrap Ever confirmed|0 |1 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Created attachment 34529 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34529action=edit Somewhat reduced testcase Here's what I managed to reduce from a arm cross
[Bug middle-end/64729] gcc.dg/stackprotectexplicit1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64729 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug middle-end/64729] New: gcc.dg/stackprotectexplicit1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64729 Bug ID: 64729 Summary: gcc.dg/stackprotectexplicit1.c FAILs Product: gcc Version: 5.0 URL: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01884.ht ml Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: marcos.diaz at tallertechnologies dot com Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* As reported in https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01884.html the new gcc.dg/stackprotectexplicit1.c FAILs on Solaris: FAIL: gcc.dg/stackprotectexplicit1.c (test for excess errors) WARNING: gcc.dg/stackprotectexplicit1.c compilation failed to produce executable Excess errors: Undefined first referenced symbol in file __stack_chk_guard /var/tmp//ccv9aOr1.o ld: fatal: symbol referencing errors. No output written to . Further analysis and proposed patch above. Rainer
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- What's the status of this bug? At least the failure of gcc.target/i386/funcspec-5.c occurs on several x86 targets (Darwin, Linux/x86, Solaris/x86) and no progess whatsoever for more than a month! Rainer
[Bug tree-optimization/64277] [4.9/5 Regression] Incorrect warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
--- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Here is a reduced test case:
cat test.c
int f1[10];
void foo(short a[], short m, unsigned short l)
{
int i = l;
for (i = i + 5; i m; i++)
f1[i] = a[i]++;
}
gcc test.c -O3 -c -Wall
test.c: In function 'foo':
test.c:6:7: warning: array subscript is above array bounds [-Warray-bounds]
f1[i] = a[i]++;
^
test.c:6:7: warning: array subscript is above array bounds [-Warray-bounds]
test.c:6:7: warning: array subscript is above array bounds [-Warray-bounds]
test.c:6:7: warning: array subscript is above array bounds [-Warray-bounds]
test.c:6:7: warning: array subscript is above array bounds [-Warray-bounds]
Here we have complete unroll of the loop by 10 due to f1 size. Later vrp
complains of last five produced iterations accessing above array bounds.
Used GCC 5.0.
[Bug c++/59366] A friend function template defined in a class is found without ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59366 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com --- Thus done.
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 --- Comment #4 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Thu Jan 22 11:55:33 2015 New Revision: 219994 URL: https://gcc.gnu.org/viewcvs?rev=219994root=gccview=rev Log: make fold ignore decl_with_vis.symtab_node gcc/ PR middle-end/63325 * fold-const.c (fold_checksum_tree): Don't include expr.decl_with_vis.symtab_node in the checksum. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp Summary|OpenACC coarray ICE |OpenACC coarray ICE (also ||with OpenMP?) --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- With the patch for PR64726 applied and the ACC CACHE commented, the program gets stuck (endless loop) for the code in gcc/testsuite/gfortran.dg/goacc/coarray.f95. It works, if one changes the scalar coarray into either an array coarray or into a noncoarray scalar. I think gfc_has_alloc_comps just needs to be updated to handle coarrays, which use an array descriptor but aren't true arrays. (I think GFC_TYPE_ARRAY_RANK(...) == 0 can be used to detect this, but that might not work for all array types.) I marked it as OpenMP as it is probably also possible to trigger this for some OpenMP code. Even though, I do not have a test case. Backtrace: #1 gfc_get_element_type (type=0x720f25e8) at ../../gcc/fortran/trans-types.c:1180 #2 0x00742f85 in gfc_has_alloc_comps (type=optimized out, decl=optimized out) at ../../gcc/fortran/trans-openmp.c:193 #3 0x0099eb12 in gimplify_scan_omp_clauses (list_p=0x720f32a0, pre_p=pre_p@entry=0x7fffd918, region_type=region_type@entry=ORT_TARGET) at ../../gcc/gimplify.c:6062 #4 0x009a07c8 in gimplify_omp_workshare (expr_p=expr_p@entry=0x720eb778, pre_p=pre_p@entry=0x7fffd918) at ../../gcc/gimplify.c:7307
[Bug go/64510] FAIL: go.test/test/nilptr2.go execution on non-split-stack targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64510 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- Should the test just be marked untested in go.test/go-test.exp for split-stack targets? Rainer
[Bug ipa/64730] g++.dg/ipa/pr64049-1.C ICE: SEGV when printing NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64730 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug ipa/64730] New: g++.dg/ipa/pr64049-1.C ICE: SEGV when printing NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64730 Bug ID: 64730 Summary: g++.dg/ipa/pr64049-1.C ICE: SEGV when printing NULL Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.10 Target: *-*-solaris2.10 Build: *-*-solaris2.10 As reported in https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01889.html this change 2015-01-15 Naveen H.S naveen.hurugalaw...@caviumnetworks.com * ipa-inline.c (inline_small_functions): Swap the operands in enum. caused a couple of testsuite failures on Solaris 10: FAIL: g++.dg/ipa/pr64049-1.C -std=gnu++11 (internal compiler error) FAIL: g++.dg/ipa/pr64049-1.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/ipa/pr64049-1.C -std=gnu++14 (internal compiler error) FAIL: g++.dg/ipa/pr64049-1.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/ipa/pr64049-1.C -std=gnu++98 (internal compiler error) FAIL: g++.dg/ipa/pr64049-1.C -std=gnu++98 (test for excess errors) /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ipa/pr64049-1.C:34:1: internal compiler error: Segmentation Fault 0x88b777c crash_signal /vol/gcc/src/hg/trunk/local/gcc/toplev.c:381 cc1plus -fpreprocessed pr64049-1.ii -quiet -O3 -fdump-ipa-inline -o pr64049-1.s Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfee0645c in strlen () from /lib/libc.so.1 (gdb) where #0 0xfee0645c in strlen () from /lib/libc.so.1 #1 0xfee61aee in _ndoprnt () from /lib/libc.so.1 #2 0xfee6469e in fprintf () from /lib/libc.so.1 #3 0x08ed5f04 in inline_small_functions () at /vol/gcc/src/hg/trunk/local/gcc/ipa-inline.c:1718 #4 0x08ed84e4 in ipa_inline () at /vol/gcc/src/hg/trunk/local/gcc/ipa-inline.c:2178 #5 (anonymous namespace)::pass_ipa_inline::execute (this=optimized out) at /vol/gcc/src/hg/trunk/local/gcc/ipa-inline.c:2550 #6 0x087f94b3 in execute_one_pass (pass=0x98f7fd0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2326 #7 0x087f9fdd in execute_ipa_pass_list (pass=0x98f7fd0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2723 #8 0x0850cd02 in ipa_passes () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2133 #9 symbol_table::compile (this=this@entry=0xfea09000) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2221 #10 0x0850eda7 in compile (this=0xfea09000) at /vol/gcc/src/hg/trunk/local/gcc/timevar.h:110 #11 symbol_table::finalize_compilation_unit (this=0xfea09000) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2370 #12 0x082fcd2e in cp_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/cp/decl2.c:4750 #13 0x088b7819 in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:606 #14 0x091fa5e9 in do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2045 #15 toplev::main (this=0x804759f, argc=8, argv=0x80475e0) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2142 #16 0x091fb27f in main (argc=8, argv=0x80475e0) at /vol/gcc/src/hg/trunk/local/gcc/main.c:38 On Solaris 11 and Linux, I find Considering static EnumStatusCode ValueHelper::getLocalizedText(const ValueStruct*, LocalizedText)/26 with 17 size to be inlined into static LocalizedText ValueHelper::getLocalizedText(const ValueStruct*)/15 in (null):0 i.e. fprintf(NULL), which doesn't work in every libc. Rainer
[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|FAIL: gcc.dg/vect/vect-33.c |[5 Regression] FAIL: |scan-tree-dump vect |gcc.dg/vect/vect-33.c |Alignment of access forced |scan-tree-dump vect |using peeling |Alignment of access forced ||using peeling
[Bug tree-optimization/61403] An opportunity for x86 gcc vectorizer (~40% gain)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61403 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- So is this fixed now?
[Bug fortran/59107] [4.8/4.9/5 Regression] Spurious Type specified for intrinsic function 'command_argument_count' at (1) is ignored under -Wsurprising.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107
--- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Updated patch for 5.0
--- ../_clean/gcc/fortran/gfortran.h2015-01-19 02:01:40.0 +0100
+++ gcc/fortran/gfortran.h2015-01-22 11:42:56.0 +0100
@@ -1451,7 +1451,7 @@ typedef struct gfc_symbol
/* Set if this variable is used as an index name in a FORALL. */
unsigned forall_index:1;
/* Used to avoid multiple resolutions of a single symbol. */
- unsigned resolved:1;
+ unsigned resolve_symbol_called:2;
int refs;
struct gfc_namespace *ns;/* namespace containing this symbol */
--- ../_clean/gcc/fortran/resolve.c2015-01-18 17:58:11.0 +0100
+++ gcc/fortran/resolve.c2015-01-22 11:41:38.0 +0100
@@ -1625,8 +1625,9 @@ gfc_resolve_intrinsic (gfc_symbol *sym,
gfc_intrinsic_sym* isym = NULL;
const char* symstd;
- if (sym-formal)
+ if (sym-resolve_symbol_called = 2)
return true;
+ sym-resolve_symbol_called = 2;
/* Already resolved. */
if (sym-from_intmod sym-ts.type != BT_UNKNOWN)
@@ -6930,7 +6931,9 @@ resolve_allocate_expr (gfc_expr *e, gfc_
goto failure;
}
- if (code-ext.alloc.ts.type == BT_CHARACTER !e-ts.deferred)
+ /* Check F08:C632. */
+ if (code-ext.alloc.ts.type == BT_CHARACTER !e-ts.deferred
+ !UNLIMITED_POLY (e))
{
int cmp = gfc_dep_compare_expr (e-ts.u.cl-length,
code-ext.alloc.ts.u.cl-length);
@@ -13082,9 +13085,9 @@ resolve_symbol (gfc_symbol *sym)
gfc_array_spec *as;
bool saved_specification_expr;
- if (sym-resolved)
+ if (sym-resolve_symbol_called = 1)
return;
- sym-resolved = 1;
+ sym-resolve_symbol_called = 1;
if (sym-attr.artificial)
return;
It regtest cleanly.
If it helps, I can take this PR.
[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 34530 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34530action=edit sparc vectorizer dump
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34531 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34531action=edit gcc5-pr64511.patch The #c13 testcase can be fixed by the attached patch. Not including the testcase, as it takes 5 seconds to compile, which might be too much for the testsuite.
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r217034.
Reduced testcase for -O:
char a[128];
int b, d;
void baz (long);
int setjmp (char [128]);
static void
bar (long *x)
{
if (d)
*x = b;
}
void
foo ()
{
baz (0);
if (setjmp (a))
{
long c;
bar (c);
baz (c);
}
baz (0);
}
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
Index: tree-ssa-coalesce.c
===
--- tree-ssa-coalesce.c (revision 219989)
+++ tree-ssa-coalesce.c (working copy)
@@ -1213,8 +1215,11 @@ coalesce_partitions (var_map map, ssa_co
gsi_next (gsi))
{
gphi *phi = gsi.phi ();
- tree res = PHI_RESULT (phi);
tree arg = PHI_ARG_DEF (phi, e-dest_idx);
+ if (SSA_NAME_IS_DEFAULT_DEF (arg))
+ continue;
+
+ tree res = PHI_RESULT (phi);
int v1 = SSA_NAME_VERSION (res);
int v2 = SSA_NAME_VERSION (arg);
fixes it for me.
Is that right even when SSA_NAME_VAR is a PARM_DECL?
[Bug ipa/64730] [5 Regression] g++.dg/ipa/pr64049-1.C ICE: SEGV when printing NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64730 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Summary|g++.dg/ipa/pr64049-1.C ICE: |[5 Regression] |SEGV when printing NULL |g++.dg/ipa/pr64049-1.C ICE: ||SEGV when printing NULL
[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-22 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-22 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine (but waiting for a reduced testcase).
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Index: tree-ssa-coalesce.c
===
--- tree-ssa-coalesce.c (revision 219989)
+++ tree-ssa-coalesce.c (working copy)
@@ -1213,8 +1215,11 @@ coalesce_partitions (var_map map, ssa_co
gsi_next (gsi))
{
gphi *phi = gsi.phi ();
- tree res = PHI_RESULT (phi);
tree arg = PHI_ARG_DEF (phi, e-dest_idx);
+ if (SSA_NAME_IS_DEFAULT_DEF (arg))
+ continue;
+
+ tree res = PHI_RESULT (phi);
int v1 = SSA_NAME_VERSION (res);
int v2 = SSA_NAME_VERSION (arg);
fixes it for me.
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 Ilya Enkovich enkovich.gnu at gmail dot com changed: What|Removed |Added CC||enkovich.gnu at gmail dot com --- Comment #4 from Ilya Enkovich enkovich.gnu at gmail dot com --- (In reply to Jakub Jelinek from comment #3) But then wonder if/how target_reinit works for i?86 32-bit. Perhaps pic_offset_table_rtx should be cleared in init_emit_regs before computing it? pic_offset_table_rtx = NULL_RTX; if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM); Clearing pic_offset_table_rtx here would mean PIC_OFFSET_TABLE_REGNUM tranfroms into EBX and pic_offset_table_rtx is initialized with EBX which is not what we want. Probably we just shouldn't try to initialize pic_offset_table_rtx with a hard reg in case target assumes pseudo pic reg? diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c index df85366..51ef3a5 100644 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -5872,7 +5872,8 @@ init_emit_regs (void) = gen_raw_REG (Pmode, RETURN_ADDRESS_POINTER_REGNUM); #endif - if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) + if (!targetm.use_pseudo_pic_reg () + (unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM); else pic_offset_table_rtx = NULL_RTX;
[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #16) --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- If you are willing to cook up an effective-target for that in lib/target-supports.exp, sure, go ahead. Given the complexity of the HAVE_COMDAT_GROUP test in gcc/configure.ac, the best way seems to have gcc define something like __GCC_HAVE_COMDAT_GROUP and use that in target-supports.exp. Rainer The predefined macros aren't zero cost, so I'd strongly prefer not to abuse them. Just compiling something where comdat groups should be used and scanning the assembly should be even easier.
[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #61 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Mikael Pettersson from comment #60) FWIW I've been including backports of r202778 and r206437 (which I think are the two relevant fixes) in my 4.8-based GCCs on x86_64, sparc64, powerpc64, m68k, armv5, and armv7 for a year now, without regressions. Well Mikael, if you already have used/tested that patch on 4.8 for such a long time, I would appreciate it very much if you post it on the gcc-patches mailing list. Thanks Bernd.
[Bug target/64688] [5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|vmakarov at redhat dot com |ubizjak at gmail dot com --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Vladimir Makarov from comment #3) will solve the PR. So the change will solve 2 PRs (this one and 64477). I believe it is up to x86 maintainers to do this change. True. The proposed patch in PR 64477 also solves this PR.
[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #62 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Bernd Edlinger from comment #61) if you already have used/tested that patch on 4.8 for such a long time, I would appreciate it very much if you post it on the gcc-patches mailing list. I'll post it this weekend, but I'll need for someone else to commit it if it's approved.
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580
--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Annotating rs6000_stack_info() in perf shows:
│/* First, find out if we use _any_ altivec registers. */
│for (i = FIRST_ALTIVEC_REGNO; i = LAST_ALTIVEC_REGNO; ++i)
│ if (df_regs_ever_live_p (i))
0.00 │mr r3,r31
│bl 10293df0 .df_regs_ever_live_p(unsigned int)
0.00 │nop
│cmpdi cr7,r3,0
│beqcr7,10a7c3f4 .rs6000_stack_info()+0xc14
│mask |= ALTIVEC_REG_BIT (i);
│addi r9,r31,-77
│srwr9,r22,r9
│or r9,r9,r24
│clrldi r24,r9,32
│if (DEFAULT_ABI == ABI_DARWIN crtl-calls_eh_return
│ ! TARGET_ALTIVEC)
│ mask |= 0xFFF;
│
│/* First, find out if we use _any_ altivec registers. */
│for (i = FIRST_ALTIVEC_REGNO; i = LAST_ALTIVEC_REGNO; ++i)
0.00 │addi r31,r31,1
│cmplwi cr7,r31,109
│clrldi r31,r31,32
│bnecr7,10a7c3d0 .rs6000_stack_info()+0xbf0
│ if (df_regs_ever_live_p (i))
│mask |= ALTIVEC_REG_BIT (i);
│
│if (mask == 0)
0.00 │cmpdi cr7,r24,0
│beqcr7,10a7c5c0 .rs6000_stack_info()+0xde0
│/* Next, remove the argument registers from the set. These
must
│ be in the VRSAVE mask set by the caller, so we don't need to
add
│ them in again. More importantly, the mask we compute here
is
│ used to generate CLOBBERs in the set_vrsave insn, and we do
not
│ wish the argument registers to die. */
│for (i = crtl-args.info.vregno - 1; i = ALTIVEC_ARG_MIN_REG;
--i)
│lwar10,144(r29)
│addi r9,r10,-1
│cmplwi cr7,r9,78
│blecr7,10a7c458 .rs6000_stack_info()+0xc78
│addi r10,r10,-78
│ mask = ~ALTIVEC_REG_BIT (i);
│lisr8,-32768
│clrldi r10,r10,32
│addi r9,r10,-2
│clrldi r9,r9,32
│addi r9,r9,1
│mtctr r9
│nop
│nop
99.57 │srwr9,r8,r10
│addi r10,r10,-1
│andc r9,r24,r9
0.41 │clrldi r10,r10,32
│clrldi r24,r9,32
│/* Next, remove the argument registers from the set. These
must
│ be in the VRSAVE mask set by the caller, so we don't need to
add
│ them in again. More importantly, the mask we compute here
is
│ used to generate CLOBBERs in the set_vrsave insn, and we do
not
│ wish the argument registers to die. */
│for (i = crtl-args.info.vregno - 1; i = ALTIVEC_ARG_MIN_REG;
--i)
│bdnz 10a7c440 .rs6000_stack_info()+0xc60
│ mask = ~ALTIVEC_REG_BIT (i);
│
│/* Similarly, remove the return value from the set. */
│{
│ bool yes = false;
│li r9,0
│mr r4,r1
│ diddle_return_value (is_altivec_return_reg, yes);
│addis r3,r2,-4
│for (i = crtl-args.info.vregno - 1; i = ALTIVEC_ARG_MIN_REG;
--i)
│ mask = ~ALTIVEC_REG_BIT (i);
[Bug ipa/63970] [4.9 Regression] gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63970 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.9.3 Resolution|--- |FIXED Known to fail||4.9.2 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34527 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34527action=edit gcc5-ice-nobt.patch Untested fix for the undesirable backtrace from driver.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||5.0 Resolution|--- |FIXED --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org --- Ok, somewhat mitigated by the new allocator in GCC 5.
[Bug fortran/63861] OpenACC coarray ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Cesar Philippidis from comment #0) Coarrays in OpenACC accelerated regions causes an ICE in gfortran. The test case gcc/testsuite/gfortran.dg/goacc/coarray.f95 reproduces this failure. It already ICEs for me with a normal variable: PR64726, besides it currently doesn't ICE because CACHE is not yet implemented: PR63865. Note that the test case should at the end also use -fcoarray=lib besides -fcoarray=single. It's unclear whether OpenACC 2.0a even supports coarrays. Regardless, this test case shouldn't cause an ICE. Regarding coarrays: If they are not coindexed (a[remote_process_idx]), they act as local variable. Thus, I'd expect that they work. Synchronization is in the realm of the user, who has to ensure that the host has the current value and the processes are sync'ed when remote access is required. [One probably should also reject calls to a procedures which expect a coarray as argument as that won't fly either. That's something to be done on best-effort base.] Thus, I think they should be permitted.
[Bug c++/64727] New: [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 Bug ID: 64727 Summary: [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot med.uc.edu, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, jason at gcc dot gnu.org Host: x86_64-apple-darwin14 Target: x86_64-apple-darwin14 Build: x86_64-apple-darwin14 Compiling g++.dg/torture/darwin-cfstring-3.C on x86_64-apple-darwin14 with r219982 (see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02466.html) gives the following ICE /opt/gcc/work/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11 #define CFSTR(STR) ((CFStringRef) __builtin___CFStringMakeConstantString (STR)) ^ /opt/gcc/work/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C:19:18: note: in expansion of macro 'CFSTR' CFStringRef s0 = CFSTR(Hello there); ^ /opt/gcc/work/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Abort trap: 6 #define CFSTR(STR) ((CFStringRef) __builtin___CFStringMakeConstantString (STR)) ^ /opt/gcc/work/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C:19:18: note: in expansion of macro 'CFSTR' CFStringRef s0 = CFSTR(Hello there); ^ g++5: internal compiler error: Abort trap: 6 (program cc1plus) Abort Revision r219969 is OK.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Can you reproduce it with stage1 cc1plus? As in, is it miscompiled compiler or just some problem on the testcase? If the former, can you bisect exactly to the version and bisect which *.o file it is?
[Bug tree-optimization/64715] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Of course the question is whether
int
main (void)
{
struct A { char buf1[9]; char buf2[1]; } a;
char *p = a.buf1;
p += 4;
strcpy (p, str1 + 5);
}
should detect a buffer overflow - because that's what the original testcase
boils down to. GCC 4.9 doesn't detect a buffer overflow here - a bug?
What is the closest surrounding object 'p' points to? What is an object
in C terms? (what is it in C++ terms?)
I start to believe the testcase is ill-formed and should have used
a.buf1[4] instead which works fine with GCC 5.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #35 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I see three possibilities for this PR:
(1) Revert r211405 for 5.0 and r212329 for 4.9.
(2) Understand why elemental procedures expose the problem when expr-expr_type
== EXPR_ARRAY.
(3) Apply the conservative patch
--- ../4.9_clean/gcc/fortran/trans-expr.c2014-10-04 12:59:45.0
+0200
+++ ../4.9_work/gcc/fortran/trans-expr.c2014-10-04 13:11:36.0 +0200
@@ -6475,7 +6475,7 @@ gfc_conv_expr_reference (gfc_se * se, gf
if (expr-ts.type == BT_DERIVED expr-rank
!gfc_is_finalizable (expr-ts.u.derived, NULL)
expr-ts.u.derived-attr.alloc_comp
- expr-expr_type != EXPR_VARIABLE)
+ expr-expr_type == EXPR_FUNCTION)
{
tree tmp;
--- ../4.9_clean/gcc/testsuite/gfortran.dg/class_array_15.f032014-07-07
14:33:14.0 +0200
+++ ../4.9_work/gcc/testsuite/gfortran.dg/class_array_15.f032014-11-08
14:26:21.0 +0100
@@ -115,5 +115,5 @@ subroutine pr54992 ! This test remains
bh = bhGet(b,instance=2)
if (loc (b) .ne. loc(bh%hostNode)) call abort
end
-! { dg-final { scan-tree-dump-times builtin_free 12 original } }
+! { dg-final { scan-tree-dump-times builtin_free 12 original { xfail *-*-*
} } }
! { dg-final { cleanup-tree-dump original } }
I am not fond of (1).
For (2) I need some help. So far the problem has been looked from the 'if'
block point of view. It may be easier to look at the alloc/free machinery
handling elemental.
I think (3) is probably the best solution for 4.9. What I have not done so far
is a test to check this PR, e.g., the test in comment 31, a test for pr41936,
and open a new PR for the memory leak in gfortran.dg/class_array_15.f03.
Feedback welcomed.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jan 22 09:21:48 2015 New Revision: 219988 URL: https://gcc.gnu.org/viewcvs?rev=219988root=gccview=rev Log: 2015-01-22 Richard Biener rguent...@suse.de PR libstdc++/64535 * libsupc++/eh_alloc.cc: Include new. (bitmask_type): Remove. (one_buffer): Likewise. (emergency_buffer): Likewise. (emergency_used): Likewise. (dependents_buffer): Likewise. (dependents_used): Likewise. (class pool): New custom fixed-size arena, variable size object allocator. (emergency_pool): New global. (__cxxabiv1::__cxa_allocate_exception): Use new emergency_pool. (__cxxabiv1::__cxa_free_exception): Likewise. (__cxxabiv1::__cxa_allocate_dependent_exception): Likewise. (__cxxabiv1::__cxa_free_dependent_exception): Likewise. * g++.old-deja/g++.eh/badalloc1.C: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_alloc.cc
[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
It would appear so, in which case the following (untested, only quick hack)
should work:
diff --git a/gcc/testsuite/gcc.dg/cpp/pr36320.c
b/gcc/testsuite/gcc.dg/cpp/pr36320.c
index d136a69..ebd5191 100644
--- a/gcc/testsuite/gcc.dg/cpp/pr36320.c
+++ b/gcc/testsuite/gcc.dg/cpp/pr36320.c
@@ -4,5 +4,5 @@
int z;
#if 1
-#elif /* { dg-error with no expression } */
+#elif
#endif
diff --git a/libcpp/directives.c b/libcpp/directives.c
index ab4f15c..37cd109 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -2036,23 +2036,16 @@ do_elif (cpp_reader *pfile)
}
ifs-type = T_ELIF;
- if (! ifs-was_skipping)
+ /* See DR#412: Only the first group whose control condition
+ evaluates to true (nonzero) is processed; any following groups
+ are skipped and their controlling directives are processed as
+ if they were in a group that is skipped. */
+ if (ifs-skip_elses)
+pfile-state.skipping = 1;
+ else
{
- bool value;
- /* The standard mandates that the expression be parsed even
- if we are skipping elses at this point -- the lexical
- restrictions on #elif only apply to skipped groups, but
- this group is not being skipped. Temporarily set
- skipping to false to get lexer warnings. */
- pfile-state.skipping = 0;
- value = _cpp_parse_expr (pfile, false);
- if (ifs-skip_elses)
-pfile-state.skipping = 1;
- else
-{
- pfile-state.skipping = ! value;
- ifs-skip_elses = value;
-}
+ pfile-state.skipping = ! _cpp_parse_expr (pfile, false);
+ ifs-skip_elses = ! pfile-state.skipping;
}
/* Invalidate any controlling macro. */
together with a test like the following
#if 1
int i;
#elif 1/0
#endif
#if 1
int j;
#elif
#endif
#if 0
#elif 1/0/* { dg-error division by zero } */
int k;
#endif
#if 0
#elif/* { dg-error with no expression } */
int n;
#endif
#if 1
# if 1
int l;
# elif 1/0
# endif
#endif
#if 1
# if 0
# elif 1/0/* { dg-error division by zero } */
# endif
#endif
[Bug go/64725] New: FAIL: libgo/runtime TestFinalizerType testing.go:278: #2: finalizer for type func(*int) didn't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64725 Bug ID: 64725 Summary: FAIL: libgo/runtime TestFinalizerType testing.go:278: #2: finalizer for type func(*int) didn't run Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vries at gcc dot gnu.org CC: cmang at google dot com libgo.log (non-m32 part): ... --- FAIL: TestFinalizerType (4.02s) testing.go:278: #2: finalizer for type func(*int) didn't run FAIL FAIL: runtime /home/vries/gcc_versions/data/ref-master-15-01-21/src/libgo/testsuite/gotest: line 514: gotest-timeout: No such file or directory ... configure line: ... $ ./gcc/xgcc -v Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: src/configure --prefix=install --with-cloog=infra --with-ppl=infra --with-gmp=infra --with-mpfr=infra --with-mpc=infra --with-isl=infra --enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++,go,obj-c++ Thread model: posix gcc version 5.0.0 20150121 (experimental) (GCC) ... Using r219928 I've run the libgo testsuite twice more. The first time the FAIL dissapeared. The second time it reappeared, but without the gotest-timeout message.
[Bug fortran/64726] New: [OpenACC] ICE with -fopenacc and reduction(+:a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64726 Bug ID: 64726 Summary: [OpenACC] ICE with -fopenacc and reduction(+:a) Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openacc Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: cesar at codesourcery dot com, tschwinge at gcc dot gnu.org Found when looking at gcc/testsuite/gfortran.dg/goacc/coarray.f95 and PR63861. The following program ICEs with gfortran -fopenacc but compiles with -fopenmp; the ICE is: internal compiler error: in gfc_trans_omp_do, at fortran/trans-openmp.c:3380 subroutine oacc1() implicit none integer :: i integer :: a !$acc parallel loop reduction(+:a) !$omp parallel do reduction(+:a) do i = 1,5 enddo end subroutine oacc1
[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
-#elif /* { dg-error with no expression } */
+#elif
Perhaps turn it into dg-bogus instead?
[Bug tree-optimization/64715] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- The original test case is already using the equivalent of a.buf1[4], without any intermediate variable.
[Bug tree-optimization/64715] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Note that if I fix this the only possible fix will complain for char *p = (char *)a; p += 4; ... as well.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can you reproduce it with stage1 cc1plus? Yes: [Book15] f90/bug% /opt/gcc/build_w/stage1-gcc/cc1plus /opt/gcc/work/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C /opt/gcc/work/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11 #define CFSTR(STR) ((CFStringRef) __builtin___CFStringMakeConstantString (STR)) ... As in, is it miscompiled compiler or just some problem on the testcase? The test has not changed since Oct 23 2010. If the former, can you bisect exactly to the version and bisect which *.o file it is? I can do the bisection, but I don't understand what you mean by *.o file it is.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- If stage1 fails, then it is not miscompilation of the compiler itself (or it would be miscompilation by your system compiler instead). So no *.o bisection is needed. That said, I don't see what commit in that range might be related.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- If stage1 fails, then it is not miscompilation of the compiler itself (or it would be miscompilation by your system compiler instead). My bootstrap compiler is gcc version 5.0.0 20150107 (experimental) [trunk revision 219318] (GCC) I don't know which compiler FX is using (I guess Clang). So no *.o bisection is needed. That said, I don't see what commit in that range might be related. Candidates are 219970, 219973, 219974, and 219981.
[Bug driver/64690] -freport-bug issue with comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64690 --- Comment #2 from Maxim Ostapenko chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Jan 22 10:55:32 2015 New Revision: 219990 URL: https://gcc.gnu.org/viewcvs?rev=219990root=gccview=rev Log: 2015-01-22 Max Ostapenko m.ostape...@partner.samsung.com PR driver/64690 * gcc.c (insert_comments): New function. (try_generate_repro): Call it. (append_text): Removed. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- The only FE change among those is r219973.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727
--- Comment #10 from howarth at bromo dot med.uc.edu ---
This ICE for FAIL: g++.dg/torture/darwin-cfstring-3.C -O0 backtraces as...
% lldb
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../cc1plus
(lldb) target create
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../cc1plus
Current executable set to
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../cc1plus'
(x86_64).
(lldb) r -quiet -nostdinc++ -v -I
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/include/x86_64-apple-darwin14.1.0
-I
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/include
-I /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/libstdc++-v3/libsupc++ -I
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/libstdc++-v3/include/backward
-I
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/libstdc++-v3/testsuite/util
-iprefix
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/
-isystem
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../include
-isystem
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../include-fixed
-D__DYNAMIC__
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C
-fPIC -quiet -dumpbase darwin-cfstring-3.C -mmacosx-version-min=10.10.1
-mconstant-cfstrings -m64 -mtune=core2 -auxbase-strip darwin-cfstring-3.s -O0
-version -fno-diagnostics-show-caret -fdiagnostics-color=never
-fmessage-length=0 -o darwin-cfstring-3.s
Process 97821 launched:
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../cc1plus'
(x86_64)
GNU C++ (GCC) version 5.0.0 20150122 (experimental) (x86_64-apple-darwin14.1.0)
compiled by GNU C version 5.0.0 20150122 (experimental), GMP version 6.0.0,
MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/include
ignoring nonexistent directory
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/include-fixed
ignoring nonexistent directory
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/../../../../x86_64-apple-darwin14.1.0/include
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/../../../../x86_64-apple-darwin14.1.0/include
#include ... search starts here:
#include ... search starts here:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/include/x86_64-apple-darwin14.1.0
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/libstdc++-v3/include
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/libstdc++-v3/libsupc++
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/libstdc++-v3/include/backward
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150121/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../include
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../include-fixed
/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/include
/sw/lib/gcc5.0/include
/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.1.0/5.0.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C++ (GCC) version 5.0.0 20150122 (experimental) (x86_64-apple-darwin14.1.0)
compiled by GNU C version 5.0.0 20150122 (experimental), GMP version 6.0.0,
MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 73eb99ceace32769122060efa78397a6
Process 97821 stopped
* thread #1: tid = 0x1b316f, 0x000100805551
cc1plus`used_types_insert(t=0x) + 17 at function.c:6372, queue
= 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000100805551
cc1plus`used_types_insert(t=0x) + 17 at function.c:6372
6369void
6370used_types_insert (tree t)
6371{
- 6372 while (POINTER_TYPE_P (t) || TREE_CODE (t) == ARRAY_TYPE)
6373if (TYPE_NAME (t))
6374 break;
6375else
(lldb) bt
* thread #1: tid = 0x1b316f, 0x000100805551
cc1plus`used_types_insert(t=0x) + 17 at function.c:6372, queue
= 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x000100805551
cc1plus`used_types_insert(t=0x) + 17 at function.c:6372
frame #1: 0x000100101e4d cc1plus`mark_used(decl=0x00014261e1c0,
complain=3) + 429 at decl2.c:4938
frame #2: 0x00010018d595
cc1plus`constant_value_1(decl
[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
r219076 introduced:
if (current_badness != badness)
{
if (edge_heap.min () badness edge_heap.min_key ())
^
Does it look right?
This is a thinko, indeed. I am testing a fix, but I doubdt this can affect
correctness
of a testcase. I see it does inlining, but why it depends on inline decisions?
Honza
{
edge-aux = edge_heap.insert (current_badness, edge);
continue;
}
else
badness = current_badness;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ipa/64694] [5 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64694
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
r219076 introduced:
if (current_badness != badness)
{
if (edge_heap.min () badness edge_heap.min_key ())
^
Does it look right?
This is a thinko, indeed. I am testing a fix, but I doubdt this can affect
correctness
of a testcase. I see it does inlining, but why it depends on inline
decisions?
I meant unwinding.
Honza
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from tbsaunde at gcc dot gnu.org --- fixed
[Bug middle-end/61225] [5 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #17 from Rainer Orth ro at gcc dot gnu.org --- Another 6 weeks have passed and gcc.target/i386/pr49095.c is still failing. This needs to be handled somehow before the GCC 5 release. Rainer
[Bug target/64159] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64159 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- Also FAILs on Solaris/SPARC, in the same way as on powerpc. Rainer
[Bug libfortran/64732] [5 Regression] julia build failure: double free or corruption in libgfortran.so.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64732 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-01-22 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Waiting for some kind of a testcase (or at least a pointer to what Julia is).
[Bug libfortran/64732] [5 Regression] julia build failure: double free or corruption in libgfortran.so.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64732 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Waiting for some kind of a testcase (or at least a pointer to what Julia is). Judging by the .jl suffix, I'd think it's this: http://julialang.org/
[Bug tree-optimization/64731] vector lowering should split loads and stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-01-22
CC||rguenth at gcc dot gnu.org
Summary|poor code when using|vector lowering should
|vector_size((32)) for sse2 |split loads and stores
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, the issue is simple - veclower doesn't split the loads/stores itself but
the
registers:
bb 3:
# ivtmp.11_24 = PHI ivtmp.11_23(3), 0(2)
_8 = MEM[base: a_6(D), index: ivtmp.11_24, offset: 0B];
_11 = MEM[base: b_9(D), index: ivtmp.11_24, offset: 0B];
_17 = BIT_FIELD_REF _8, 128, 0;
_4 = BIT_FIELD_REF _11, 128, 0;
_5 = _4 + _17;
_29 = BIT_FIELD_REF _8, 128, 128;
_28 = BIT_FIELD_REF _11, 128, 128;
_14 = _28 + _29;
_12 = {_5, _14};
MEM[base: a_6(D), index: ivtmp.11_24, offset: 0B] = _12;
ivtmp.11_23 = ivtmp.11_24 + 32;
if (ivtmp.11_23 != 8192)
goto bb 3;
else
goto bb 4;
in this case it would also have a moderately hard time to split the loads/store
as it is faced with TARGET_MEM_REFs already.
Nothing combines this back into a sane form. I've recently added code that
handles exactly the same situation but only for complex arithmetic
(in tree-ssa-forwprop.c for PR64568).
I wonder why with only -msse2 IVOPTs produces TARGET_MEM_REFs for the loads.
For sure x86_64 cannot load V4DF in one instruction...
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Thu Jan 22 14:43:55 2015 New Revision: 22 URL: https://gcc.gnu.org/viewcvs?rev=22root=gccview=rev Log: PR target/64688 PR target/64477 * config/i386/sse.md (vec_setmode_0): Use (Yi/r/C) constraints for alternative 3. testsuite/ChangeLog: PR target/64688 * g++.dg/pr64688.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr64688.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 --- Comment #11 from Ilya Enkovich enkovich.gnu at gmail dot com --- (In reply to David Malcolm from comment #10) which led to investigating this code in ix86_conditional_register_usage: 4394 j = PIC_OFFSET_TABLE_REGNUM; 4395 if (j != INVALID_REGNUM) 4396fixed_regs[j] = call_used_regs[j] = 1; and line 4396 is bizarrely only called on the 2nd iteration, not the 1st, which led me to investigate PIC_OFFSET_TABLE_REGNUM, and discover what appears to be the root cause, as described in comment #1. Now I see. The problem also is in ix86_conditional_register_usage that relies on pic_offset_table_rtx value. As I said EBX value is used only to estimate costs for middle-end. Thus we shouldn't fix reg here if pseudo pic register is used and correct code would be: @@ -4388,7 +4388,7 @@ ix86_conditional_register_usage (void) /* The PIC register, if it exists, is fixed. */ j = PIC_OFFSET_TABLE_REGNUM; - if (j != INVALID_REGNUM) + if (j != INVALID_REGNUM !ix86_use_pseudo_pic_reg ()) fixed_regs[j] = call_used_regs[j] = 1; /* For 32-bit targets, squash the REX registers. */
[Bug ada/64712] [5 Regression] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64712 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-01-22 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I cannot reproduce at the same revision though: === gnat tests === Schedule of variations: unix/-m32 Running target unix/-m32 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/eric/svn/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/eric/svn/gcc/gcc/testsuite/gnat.dg/dg.exp ... FAIL: gnat.dg/lto8.adb (internal compiler error) FAIL: gnat.dg/lto8.adb (test for excess errors) WARNING: gnat.dg/lto8.adb compilation failed to produce executable === gnat Summary === # of expected passes1143 # of unexpected failures2 # of expected failures 1 # of unsupported tests 3
[Bug ada/64712] [5 Regression] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64712 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I also don't see the failure.
[Bug tree-optimization/64728] [5 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64728 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jan 22 16:07:36 2015 New Revision: 220003 URL: https://gcc.gnu.org/viewcvs?rev=220003root=gccview=rev Log: 2015-01-22 Richard Biener rguent...@suse.de PR middle-end/64728 * tree-ssa-coalesce.c (coalesce_partitions): Do not perform abnormal coalescing on undefined SSA names. * gcc.dg/torture/pr64728.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64728.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-coalesce.c
[Bug libfortran/64732] [5 Regression] julia build failure: double free or corruption in libgfortran.so.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64732 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to ktkachov from comment #2) (In reply to Richard Biener from comment #1) Waiting for some kind of a testcase (or at least a pointer to what Julia is). Judging by the .jl suffix, I'd think it's this: http://julialang.org/ Yes. Here's another backtrace: === Backtrace: = /lib/libc.so.6(+0x73fbe)[0x7f3682997fbe] /lib/libc.so.6(+0x7973d)[0x7f368299d73d] /lib/libc.so.6(+0x79f4b)[0x7f368299df4b] /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libgfortran.so.3(+0xe6aa6)[0x7f366f954aa6] /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libgfortran.so.3(+0xe6bb2)[0x7f366f954bb2] /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libgfortran.so.3(+0x1a7f9)[0x7f366f8887f9] /lib64/ld-linux-x86-64.so.2(+0xf927)[0x7f368399a927] /lib/libc.so.6(+0x3686a)[0x7f368295a86a] /lib/libc.so.6(+0x368b5)[0x7f368295a8b5] /lib/libc.so.6(__libc_start_main+0xf7)[0x7f3682943fd7] /var/tmp/julia/usr/bin/julia[0x4014d5] addr2line shows: libgfortran/io/unit.c:718 : 718 free_format_hash_table (u); libgfortran/io/unit.c:764 libgfortran/runtime/main.c:292 Don't know how to come up with a small testcase yet.
[Bug tree-optimization/64731] vector lowering should split loads and stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Doesn't look like a regression, I see roughly same code quality all the way from 4.1 which I tried first to current trunk.
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #3 from tbsaunde at gcc dot gnu.org --- So, in cfghooks.c make_forwarder_block we redirect two edges to point at a bb, both edges have probability 1 (1) the first edge's src bb has freq 873, and the second 9409. So at least one of those is slightly high, and when we combine them we set the freq for dummy to 10282. Then later we copy that freq of 10282 and assert because that's not a sane frequency. Its not entirely clear to me if make_forwarder_block should handle this case by capping freq at 1, or if the bug is even earlier when those two initial frequencies are generated.
[Bug tree-optimization/64731] vector lowering should split loads and stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 22 Jan 2015, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Doesn't look like a regression, I see roughly same code quality all the way from 4.1 which I tried first to current trunk. Yes, it's not a regression and a fix has to wait for GCC 6.
[Bug target/52076] bloated code for setting single bits in bitfields on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52076
--- Comment #2 from Jeffrey A. Law law at gcc dot gnu.org ---
Author: law
Date: Thu Jan 22 21:24:28 2015
New Revision: 220015
URL: https://gcc.gnu.org/viewcvs?rev=220015root=gccview=rev
Log:
PR target/52076
* config/m68k/m68k.md (xorsi3_internal): Twiddle constraints to
improve code density for small immediate to memory case.
(insv): Better handle bitfield assignments when the field is
being set to all ones.
* config/m68k/predicates.md (reg_or_pow2_m1_operand): New
operand predicate.
PR target/52076
* gcc.target/m68k/pr52076-1.c: New test.
* gcc.target/m68k/pr52076-2.c: New test.
Added:
trunk/gcc/config/m68k/.m68k.md.swp (with props)
trunk/gcc/testsuite/gcc.target/m68k/pr52076-1.c
trunk/gcc/testsuite/gcc.target/m68k/pr52076-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k.md
trunk/gcc/config/m68k/predicates.md
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/config/m68k/.m68k.md.swp
('svn:executable' added)
[Bug target/52076] [5 Regression] bloated code for setting single bits in bitfields on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52076 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED Summary|bloated code for setting|[5 Regression] bloated code |single bits in bitfields on |for setting single bits in |m68k|bitfields on m68k --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Resolved on trunk. Not going to fix in release branches.
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #11 from Igor Zamyatin izamyatin at gmail dot com --- Could you please provide details of your compiler configuration for me to try to reproduce the problem?
[Bug ada/64712] [5 Regression] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64712 --- Comment #6 from vries at gcc dot gnu.org --- Also reproduced with r219989.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #11 from Jason Merrill jason at gcc dot gnu.org --- This seems to be because darwin_build_constant_cfstring uses CONST_DECL for a global variable, and the C++ front end expects CONST_DECL to be used only for enumerators.
[Bug libgomp/64707] FAIL: libgomp.c/target-9.c with -ftree-parallelize-loops=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64707 --- Comment #4 from vries at gcc dot gnu.org --- Created attachment 34535 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34535action=edit tentative patch, makes fopenmp an LTO option, adds lto-wrapper handling
[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672 --- Comment #16 from vries at gcc dot gnu.org --- Created attachment 34536 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34536action=edit tentative patch, makes fopenacc an LTO option, adds lto-wrapper handling
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 --- Comment #12 from howarth at bromo dot med.uc.edu --- (In reply to Jason Merrill from comment #11) This seems to be because darwin_build_constant_cfstring uses CONST_DECL for a global variable, and the C++ front end expects CONST_DECL to be used only for enumerators. Any ideas on how to recode that?
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 --- Comment #7 from David Malcolm dmalcolm at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) But then wonder if/how target_reinit works for i?86 32-bit. Perhaps pic_offset_table_rtx should be cleared in init_emit_regs before computing it? pic_offset_table_rtx = NULL_RTX; if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM); Adding the line: pic_offset_table_rtx = NULL_RTX; does indeed fix the issue; with that (or with my patch from comment #2) the jit testsuite fully passes on i686. I was hoping to keep the patch confined to toplev::finalize, since only the jit calls this, reducing the scope of the proposed change, but if you think it's better to have it in init_emit_regs, I'll defer to your judgement.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 61403, which changed state. Bug 61403 Summary: An opportunity for x86 gcc vectorizer (~40% gain) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61403 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/64731] New: poor code when using vector_size((32)) for sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
Bug ID: 64731
Summary: poor code when using vector_size((32)) for sse2
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
It would be nice if for some simple cases too large vector_size for the
selected instruction set would still produce efficient code.
E.g. using vector_size of 32 for SSE2 code results in essentially once unrolled
vector_size 16 code and it still simply uses AVX if it one compiles with the
appropriate option.
But with current gcc 5.0 with this code:
typedef double double4 __attribute__((vector_size(32)));
void fun(double * a, double * b)
{
for (int i = 0; i 1024; i+=4) {
*(double4*)a[i] += *(double4*)b[i];
}
}
with AVX this turns into the expected code, but with only SSE2 enabled one gets
this:
gcc -O3 test2.c -c -std=c99
fun:
0:4c 8d 54 24 08 lea0x8(%rsp),%r10
5:48 83 e4 e0 and$0xffe0,%rsp
9:31 c0xor%eax,%eax
b:41 ff 72 f8 pushq -0x8(%r10)
f:55 push %rbp
10:48 89 e5 mov%rsp,%rbp
13:41 52push %r10
15:48 83 ec 10 sub$0x10,%rsp
19:0f 1f 80 00 00 00 00 nopl 0x0(%rax)
20:48 8b 14 07 mov(%rdi,%rax,1),%rdx
24:48 89 55 90 mov%rdx,-0x70(%rbp)
28:48 8b 54 07 08 mov0x8(%rdi,%rax,1),%rdx
2d:48 89 55 98 mov%rdx,-0x68(%rbp)
31:48 8b 54 07 10 mov0x10(%rdi,%rax,1),%rdx
36:48 89 55 a0 mov%rdx,-0x60(%rbp)
3a:48 8b 54 07 18 mov0x18(%rdi,%rax,1),%rdx
3f:48 89 55 a8 mov%rdx,-0x58(%rbp)
43:48 8b 14 06 mov(%rsi,%rax,1),%rdx
47:48 89 55 b0 mov%rdx,-0x50(%rbp)
4b:48 8b 54 06 08 mov0x8(%rsi,%rax,1),%rdx
50:48 89 55 b8 mov%rdx,-0x48(%rbp)
54:48 8b 54 06 10 mov0x10(%rsi,%rax,1),%rdx
59:66 0f 28 45 b0 movapd -0x50(%rbp),%xmm0
5e:66 0f 58 45 90 addpd -0x70(%rbp),%xmm0
63:48 89 55 c0 mov%rdx,-0x40(%rbp)
67:48 8b 54 06 18 mov0x18(%rsi,%rax,1),%rdx
6c:48 89 55 c8 mov%rdx,-0x38(%rbp)
70:0f 29 85 70 ff ff ff movaps %xmm0,-0x90(%rbp)
77:66 48 0f 7e c2 movq %xmm0,%rdx
7c:66 0f 28 45 c0 movapd -0x40(%rbp),%xmm0
81:48 89 14 07 mov%rdx,(%rdi,%rax,1)
85:48 8b 95 78 ff ff ff mov-0x88(%rbp),%rdx
8c:66 0f 58 45 a0 addpd -0x60(%rbp),%xmm0
91:0f 29 45 80 movaps %xmm0,-0x80(%rbp)
95:48 89 54 07 08 mov%rdx,0x8(%rdi,%rax,1)
9a:48 8b 55 80 mov-0x80(%rbp),%rdx
9e:48 89 54 07 10 mov%rdx,0x10(%rdi,%rax,1)
a3:48 8b 55 88 mov-0x78(%rbp),%rdx
a7:48 89 54 07 18 mov%rdx,0x18(%rdi,%rax,1)
ac:48 83 c0 20 add$0x20,%rax
b0:48 3d 00 20 00 00cmp$0x2000,%rax
b6:0f 85 64 ff ff ffjne20 fun+0x20
bc:48 83 c4 10 add$0x10,%rsp
c0:41 5apop%r10
c2:5d pop%rbp
c3:49 8d 62 f8 lea-0x8(%r10),%rsp
c7:c3 retq
c8:0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
cf:00
while I would have hoped for something along the lines of this:
10:66 0f 28 44 c6 10movapd 0x10(%rsi,%rax,8),%xmm0
16:66 0f 28 0c c6 movapd (%rsi,%rax,8),%xmm1
1b:66 0f 58 0c c7 addpd (%rdi,%rax,8),%xmm1
20:66 0f 58 44 c7 10addpd 0x10(%rdi,%rax,8),%xmm0
26:66 0f 29 44 c7 10movapd %xmm0,0x10(%rdi,%rax,8)
2c:66 0f 29 0c c7 movapd %xmm1,(%rdi,%rax,8)
31:48 83 c0 04 add$0x4,%rax
35:3d 00 04 00 00 cmp$0x400,%eax
3a:7c d4jl 10 fun+0x10
[Bug target/64688] [5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Thu Jan 22 14:43:55 2015 New Revision: 22 URL: https://gcc.gnu.org/viewcvs?rev=22root=gccview=rev Log: PR target/64688 PR target/64477 * config/i386/sse.md (vec_setmode_0): Use (Yi/r/C) constraints for alternative 3. testsuite/ChangeLog: PR target/64688 * g++.dg/pr64688.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr64688.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722 --- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com --- different hooks(In reply to Jakub Jelinek from comment #5) Can you explain it? Usually when this function is called, pic_offset_table_rtx is NULL and your i386.h macro relies on that. When initializing default target during initialization it is NULL of course, and apparently even in target_reinit, when it is called with freshly cleared heap object for the non-default target. It is just when jit calls the initialization again without clearing all the variables... So I believe my proposed change is correct. In any case, perhaps jit shouldn't reinitialize everything all the time, at least if the compilation options don't change. I misunderstood places when init_emit_regs is called and my fix is incorrect. It is still unclear to me how this initialization affects generated code. IIRC we let pic_offset_table_rtx be EBX only because of middle-end which calls target hooks for code cost estimations. In this case we needed some valid pic reg to generate RTL for its estimation and EBX was used. But in target code pic_offset_table_rtx is initialized with pseudo register and value set in init_emit_regs shouldn't matter.
[Bug jit/64722] On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #10 from David Malcolm dmalcolm at gcc dot gnu.org ---
Notes to self on how I debugged this:
I added the following to harness.h:
gcc_jit_context_set_bool_option (
ctxt,
GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING,
1);
gcc_jit_context_set_bool_option (
ctxt,
GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES,
1);
thus populating each iteration's tempdir with logfiles (and turned off
optimizations).
Rename the tempdirs to iteration-1 and iteration-2 for the sake of sanity.
Diffing the logfiles:
(for f in $(ls /tmp/iteration-1); do
diff -up /tmp/iteration-1/$f /tmp/iteration-2/$f;
done) | less
showed the first significant difference appears
in fake.c.234r.pro_and_epilogue:
--- /tmp/iteration-1/fake.c.234r.pro_and_epilogue 2015-01-22
03:31:55.243746546 -0500
+++ /tmp/iteration-2/fake.c.234r.pro_and_epilogue 2015-01-22
03:31:55.315744888 -0500
@@ -28,11 +26,11 @@ Dataflow summary:
;; hardware regs used 7 [sp]
;; regular block artificial uses 6 [bp] 7 [sp]
;; eh block artificial uses6 [bp] 7 [sp] 16 [argp] 20 [frame]
-;; entry block defs0 [ax] 1 [dx] 2 [cx] 3 [bx] 6 [bp] 7 [sp] 20 [frame]
+;; entry block defs0 [ax] 1 [dx] 2 [cx] 6 [bp] 7 [sp] 20 [frame]
i.e. 3 [bx] no longer appears in entry block defs in iteration 2.
and it's in this dump that the RTL diverged; previous pass dumps show use a
use of bx in the call_insn, but this dump shows the save/restore
of ebx in iteration 1's code, and *not* in iteration 2's.
I put a breakpoint on emit_insn to find where the save insns are emitted:
Breakpoint 12, emit_insn (x=0xf653e900) at ../../src/gcc/emit-rtl.c:4922
4922{
(gdb) call debug(x)
(set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 3 bx))
(gdb) bt
#0 emit_insn (x=0xf653e900) at ../../src/gcc/emit-rtl.c:4922
#1 0xf74d2744 in ix86_emit_save_regs () at
../../src/gcc/config/i386/i386.c:10282
#2 ix86_expand_prologue () at ../../src/gcc/config/i386/i386.c:11398
#3 0xf75bd6fa in gen_prologue () at ../../src/gcc/config/i386/i386.md:12187
#4 0xf7027836 in thread_prologue_and_epilogue_insns () at
../../src/gcc/function.c:5929
#5 0xf70280a5 in rest_of_handle_thread_prologue_and_epilogue () at
../../src/gcc/function.c:6499
#6 (anonymous namespace)::pass_thread_prologue_and_epilogue::execute
(this=0x8074610) at ../../src/gcc/function.c:6537
#7 0xf71a6ac5 in execute_one_pass (pass=0x8074610) at
../../src/gcc/passes.c:2326
#8 0xf71a6f57 in execute_pass_list_1 (pass=0x8074610) at
../../src/gcc/passes.c:2378
#9 0xf71a6f6a in execute_pass_list_1 (pass=0x8074450) at
../../src/gcc/passes.c:2379
#10 0xf71a6f6a in execute_pass_list_1 (pass=0x8073910, pass@entry=0x80717d0) at
../../src/gcc/passes.c:2379
#11 0xf71a6fc3 in execute_pass_list (fn=0xf6527064, pass=0x80717d0) at
../../src/gcc/passes.c:2389
#12 0xf6f338e0 in cgraph_node::expand (this=0xf65261c8) at
../../src/gcc/cgraphunit.c:1804
#13 0xf6f34517 in output_in_order (no_reorder=no_reorder@entry=false) at
../../src/gcc/cgraphunit.c:2042
#14 0xf6f3491d in symbol_table::compile (this=0xf6527000) at
../../src/gcc/cgraphunit.c:2287
#15 0xf6f362d9 in symbol_table::finalize_compilation_unit (this=0xf6527000) at
../../src/gcc/cgraphunit.c:2370
#16 0xf6eadcad in jit_langhook_write_globals () at
../../src/gcc/jit/dummy-frontend.c:231
#17 0xf725c098 in compile_file () at ../../src/gcc/toplev.c:606
#18 0xf6eaa4ac in do_compile () at ../../src/gcc/toplev.c:2048
#19 toplev::main (this=0xd4c7, argc=12, argv=0x804e918) at
../../src/gcc/toplev.c:2145
#20 0xf6ec7c43 in gcc::jit::playback::context::compile (this=0xd52c) at
../../src/gcc/jit/jit-playback.c:1721
#21 0xf6ec03c1 in gcc::jit::recording::context::compile (this=0x804d008) at
../../src/gcc/jit/jit-recording.c:1175
#22 0xf6eb5d7c in gcc_jit_context_compile (ctxt=0x804d008) at
../../src/gcc/jit/libgccjit.c:2201
#23 0x08049bd0 in test_jit (argv0=0xd7ea
/root/gcc-git-jit/build-jit/gcc/testsuite/jit/test-hello-world.c.exe,
user_data=0x0) at /root/gcc-git-jit/src/gcc/testsuite/jit.dg/harness.h:352
#24 0x08049cc8 in main (argc=1, argv=0xd6b4) at
/root/gcc-git-jit/src/gcc/testsuite/jit.dg/harness.h:397
This revealed that ix86_emit_save_regs is only being called on
iteration 1, not on iteration 2.
Debugging ix86_expand_prologue showed differences in frame:
iter 1 iter 2
nregs = 10
reg_save_offset = 812
sse_reg_save_offset = 12 8
In particular, nregs = 1 on iter1, but is 0 on iter2
nregs is computed in ix86_nsaved_regs (void)
which loops over regno for real non-SSE registers calling:
ix86_save_reg (unsigned int regno, bool maybe_eh_return)
within ix86_expand_prologue:
On iteration 1:
(gdb) p this_target_hard_regs-x_call_used_regs[3]
$42 = 0 '\000'
(gdb) p this_target_hard_regs-x_fixed_regs[3]
$43 = 0 '\000'
(gdb) p regs_ever_live[3]
$44 = true
On iteration 2:
(gdb) p
[Bug libfortran/64732] New: [5 Regression] julia build failure: double free or corruption in libgfortran.so.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64732 Bug ID: 64732 Summary: [5 Regression] julia build failure: double free or corruption in libgfortran.so.3 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Trying to build Julia with gcc-5: ... /var/tmp/julia/usr/bin/julia -C native --build /var/tmp/julia/usr/lib/julia/sys0 sysimg.jl *** Error in `/var/tmp/julia/usr/bin/julia': double free or corruption (out): 0x0c131370 *** === Backtrace: = /lib/libc.so.6(+0x73fbe)[0x7f92eeb62fbe] /lib/libc.so.6(+0x7973d)[0x7f92eeb6873d] /lib/libc.so.6(+0x79f4b)[0x7f92eeb68f4b] /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libgfortran.so.3(+0x244913)[0x7f92dbb10913] /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libgfortran.so.3(+0x1a7e9)[0x7f92db8e67e9] /lib64/ld-linux-x86-64.so.2(+0xf927)[0x7f92efb68927] /lib/libc.so.6(+0x3686a)[0x7f92eeb2586a] /lib/libc.so.6(+0x368b5)[0x7f92eeb258b5] /lib/libc.so.6(__libc_start_main+0xf7)[0x7f92eeb0efd7] /var/tmp/julia/usr/bin/julia[0x4014d5] Switching to /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libgfortran.so.3.0.0 fixes the issue.
[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64727 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- The only FE change among those is r219973. And indeed if I revert it, the ICE disappears.
