[Bug ipa/67056] [5/6 regression] Wrong code generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67056 --- Comment #10 from Henning Baldersheim bal...@yahoo-inc.com --- Wrong code generation on valid code does sound like a P2 to me.
[Bug middle-end/67120] New: wrong code for volatile pointers at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67120
Bug ID: 67120
Summary: wrong code for volatile pointers at -O1 and above on
x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O1
and above in both 32-bit and 64-bit modes.
This is a regression from 5.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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 20150804 (experimental) [trunk revision 226592] (GCC)
$
$ gcc-trunk -O0 small.c; ./a.out
$ gcc-5.1 -O1 small.c; ./a.out
$
$ gcc-trunk -O1 small.c
$ ./a.out
Aborted (core dumped)
$
-
volatile int *volatile *a;
static volatile int *volatile **b = a;
int
main ()
{
volatile int *volatile c;
*b = c;
if (a != c)
__builtin_abort ();
return 0;
}
[Bug c/67107] [6 Regression] ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67107 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 5 07:42:54 2015 New Revision: 226609 URL: https://gcc.gnu.org/viewcvs?rev=226609root=gccview=rev Log: 2015-08-05 Richard Biener rguent...@suse.de PR middle-end/67107 * match.pd: Guard const_binop result checking against NULL_TREE result. * gcc.dg/pr67107.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr67107.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/67121] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121
Bug ID: 67121
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes.
This is a regression from 5.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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 20150804 (experimental) [trunk revision 226592] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.1 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$
---
int a[6], b, c = 226, d, e, f;
char g;
void
fn1 (int p1)
{
b = a[p1];
}
int
main ()
{
a[0] = 1;
for (f = 0; f 9; f++)
{
char h = c;
int i = 1;
g = h 0 ? h : h i;
e = g;
for (d = 1; d; d = 0)
;
}
fn1 (g 8 1);
if (b != 0)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/67109] [6 Regression] ICE at -O3 on x86_64-linux-gnu in vect_analyze_slp_instance, at tree-vect-slp.c:1793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67109 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 5 07:48:34 2015 New Revision: 226610 URL: https://gcc.gnu.org/viewcvs?rev=226610root=gccview=rev Log: 2015-08-05 Richard Biener rguent...@suse.de PR tree-optimization/67109 * tree-vect-data-refs.c (vect_analyze_group_access_1): Check against too big groups. Print whether this is a load or store group. Rename from ... (vect_analyze_group_access): ... this which is now a wrapper dissolving an invalid group. (vect_analyze_data_ref_accesses): Print whether this is a load or store group. * gcc.dg/torture/pr67109.c: New testcase. * gcc.dg/vect/vect-119.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/torture/pr67109.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-119.c trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/67055] [5/6 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
2118 threshold = (unsigned HOST_WIDE_INT)PARAM_VALUE
(PARAM_LARGE_STACK_FRAME);
2119 /* In case the alloca is located at function entry, it has the same
lifetime
2120 as a declared array, so we allow a larger size. */
2121 block = gimple_block (stmt);
2122 if (!(cfun-after_inlining
2123 TREE_CODE (BLOCK_SUPERCONTEXT (block)) == FUNCTION_DECL))
2124threshold /= 10;
2125 if (size threshold)
2126return NULL_TREE;
2127
(gdb) p stmt
$2 = gimple_call 0x76a57d80
(gdb) p debug_gimple_stmt (stmt)
# .MEM_11 = VDEF .MEM_10
retAddr.2_7 = __builtin_alloca_with_align (128, 64);
$3 = void
so the fix looks obvious (well, in case the alloca_with_align really is
supposed to have no BLOCK which looks pessimizing).
Looks like we've come the
if (gimple_block (stmt))
{
... remap block tree ...
}
else
remap_blocks_to_null (DECL_INITIAL (fn), id);
path during inlining. So the call we inline wasn't associated with any BLOCK.
That's
retval.11_5 = operator new [] (_2(D), _3(D)); [tail call]
which is created from cgraph_node::expand_thunk. Indeed thunks do not have
any associated BLOCK.
Testing fix.
[Bug tree-optimization/67109] [6 Regression] ICE at -O3 on x86_64-linux-gnu in vect_analyze_slp_instance, at tree-vect-slp.c:1793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67109 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/67107] [6 Regression] ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67107 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/67056] [5/6 regression] Wrong code generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67056 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Henning Baldersheim from comment #10) Wrong code generation on valid code does sound like a P2 to me. The release manager sets the importance. Another question is if the transition from requests valid to wrong code is a regression at all.
[Bug plugins/67122] New: [5/6 Regression] installed plugin headers not sufficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67122 Bug ID: 67122 Summary: [5/6 Regression] installed plugin headers not sufficient Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- [forwarded from https://bugs.debian.org/794605] gcc -E -shared - -o /dev/null -I`gcc -print-file-name=plugin`/include 21 EOF #include gcc-plugin.h #include tree.h #include tm.h #include rtl.h #ifdef ENABLE_BUILD_WITH_CXX #warning g++ #else #warning gcc #endif EOF It yields on my system: In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/hash-set.h:24:0, from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:33, from stdin:1: /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/hash-table.h:201:15: fatal error: new: No such file or directory compilation terminated. This looks to me like some very basic parts are not working correctly. Currently the build-essential is updated from 4.9 to 5.2.1, but this problem prevents the gcc-plugins from working. At the location gcc-plugin-dev breaks on the #include new rule: .. #define TYPED_HASHTAB_H #include ggc.h #include hashtab.h #include new templatetypename, typename, typename class hash_map; templatetypename, typename class hash_set; /* The ordinary memory allocator. */ ..
[Bug plugins/67122] [5/6 Regression] installed plugin headers not sufficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67122 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Not a bug, all plugins have to be compiled as C++ with 5 and above. ENABLE_BUILD_WITH_CXX was removed because it is all C++ code now. new is a standard C++ header.
[Bug middle-end/67120] [6 Regression] wrong code for volatile pointers at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67120 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Summary|wrong code for volatile |[6 Regression] wrong code |pointers at -O1 and above |for volatile pointers at |on x86_64-linux-gnu |-O1 and above on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Cezary Śliwa from comment #4) OK, the newly built compiler cannot be used because we are cross-compiling. That's not true, the compiler can be used, but you can't run the executables. The relevant libstdc++ tests should only need the preprocessor, so should work with a cross-compiler. Please attach the libstdc++-v3/config.log file so I can see what commands are used for the configure tests.
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from nsz at gcc dot gnu.org --- both arm and aarch64 should be fixed now (fix is backported to 4.9 and 5 branches)
[Bug fortran/67123] New: ICE with source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123 Bug ID: 67123 Summary: ICE with source allocation Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- The following code produces an internal compiler error with gfortran-6.0.0 (works with 5.1.0): module m implicit none public type :: ta end type ta contains subroutine sub() type(ta), allocatable :: as(:) allocate( as(0) , source=f() ) end subroutine sub pure function f() result(res) type(ta), allocatable :: res(:) allocate(res(0)) end function f end module m $ gfortran -c ice-test.f90 ice-test.f90:12:0: allocate( as(0) , source=f() ) 1 internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:5831 0x699752 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) gcc/fortran/trans-expr.c:5831 0x69987c gfc_conv_function_expr gcc/fortran/trans-expr.c:6516 0x69f5d8 gfc_conv_expr_reference(gfc_se*, gfc_expr*) gcc/fortran/trans-expr.c:7617 0x6cc8b2 gfc_trans_allocate(gfc_code*) gcc/fortran/trans-stmt.c:5195 0x66ac67 trans_code gcc/fortran/trans.c:1829 0x68dba3 gfc_generate_function_code(gfc_namespace*) gcc/fortran/trans-decl.c:5884 0x66e181 gfc_generate_module_code(gfc_namespace*) gcc/fortran/trans.c:2045 0x62776d translate_all_program_units gcc/fortran/parse.c:5508 0x62776d gfc_parse_file() gcc/fortran/parse.c:5726 0x668042 gfc_be_parse_file gcc/fortran/f95-lang.c:209
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.4 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed for 4.9.4
[Bug rtl-optimization/67124] New: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124
Bug ID: 67124
Summary: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at
-O1, -O2 and -O3 in the 64-bit mode (but not in the 32-bit mode).
This is a regression from 5.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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 20150804 (experimental) [trunk revision 226592] (GCC)
$
$ gcc-trunk -O0 small.c; ./a.out
$ gcc-5.1 -O1 small.c; ./a.out
$
$ gcc-trunk -O1 small.c
$ ./a.out
Aborted (core dumped)
$
--
struct S1
{
int:11;
char f1;
short f2;
int f3;
int f4;
} a[2] = {{0, 0, 0, 0}, {1, 0, 1, 0}}, *b = a[0];
int
main ()
{
struct S1 c = a[1];
c.f2 = 0;
*b = c;
for (;;)
if (c.f1)
break;
if (a[0].f3 != 1)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/67121] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Summary|wrong code at -O3 on|[6 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Summary|wrong code at -O1, -O2 and |[6 Regression] wrong code |-O3 on x86_64-linux-gnu |at -O1, -O2 and -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/67120] [6 Regression] wrong code for volatile pointers at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67120 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Happens in FRE. Setting value number of a.1_4 to c (changed) Applying pattern match.pd:1961, generic-match.c:4683 Marking all edges out of BB 2 but (2 - 3) as not executable Marking all outgoing edges of unreachable BB 4 as not executable ... Replaced a with c in all uses of a.1_4 = a; Applying pattern match.pd:1961, gimple-match.c:5236 gimple_simplified to if (1 != 0)
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 --- Comment #9 from Cezary Śliwa sliwa at ifpan dot edu.pl --- One think I missed is that MinGW64 uses the winpthreads library. If using winpthreads, there is no failure. However, as far as I understand, pthreads-win32 is in use in MinGW.
[Bug c++/66595] [C++14] ICE in partial specialization template variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66595 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in mainline. I'm adding a testcase and closing the bug.
[Bug tree-optimization/67055] [5/6 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 5 10:01:12 2015 New Revision: 226616 URL: https://gcc.gnu.org/viewcvs?rev=226616root=gccview=rev Log: 2015-08-05 Richard Biener rguent...@suse.de PR tree-optimization/67055 * tree-ssa-ccp.c (fold_builtin_alloca_with_align): Handle NULL gimple_block. * g++.dg/torture/pr67055.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr67055.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug ipa/67056] [5/6 regression] Wrong code generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67056 --- Comment #12 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #11) Another question is if the transition from requests valid to wrong code is a regression at all. Apart from the typo (s/requests/rejects) please ignore the comment above, it was meant for a different PR.
[Bug c++/66595] [C++14] ICE in partial specialization template variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66595 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Aug 5 10:07:57 2015 New Revision: 226617 URL: https://gcc.gnu.org/viewcvs?rev=226617root=gccview=rev Log: 2015-08-05 Paolo Carlini paolo.carl...@oracle.com PR c++/66595 * g++.dg/cpp1y/var-templ35.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ35.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/66595] [C++14] ICE in partial specialization template variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66595 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 --- Comment #6 from Cezary Śliwa sliwa at ifpan dot edu.pl --- Created attachment 36131 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36131action=edit config.log libstdc++v3 config.log
[Bug tree-optimization/67121] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Disabling if-conversion fixes it so does disabling VRP2.
[Bug tree-optimization/67121] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Hmm. Visiting statement: h_38 = (char) pretmp_48; Found new range for h_38: VARYING ... Visiting statement: _42 = (int) h_38; Intersecting [-128, 127] and [0, 127] to [0, 127] Found new range for _42: [0, 127] so it seems that the old value-range for _42 is bad: # RANGE [0, 127] NONZERO 127 _42 = (int) h_38; Before if-conversion we have bb 2: a[0] = 1; f = 0; pretmp_48 = c; bb 3: # f.4_36 = PHI 0(2), _19(6) # ivtmp_59 = PHI 9(2), ivtmp_28(6) h_9 = (char) pretmp_48; if (h_9 = 0) goto bb 4; else goto bb 10; bb 4: # RANGE [0, 127] NONZERO 127 _10 = (int) h_9; while after: bb 2: a[0] = 1; f = 0; pretmp_48 = c; bb 3: # f.4_36 = PHI 0(2), _19(4) # ivtmp_59 = PHI 9(2), ivtmp_28(4) h_9 = (char) pretmp_48; # RANGE [0, 127] NONZERO 127 _10 = (int) h_9; ... prephitmp_3 = h_9 = 0 ? _14 : _38; so if-conversion has to reset value-range info on stmts previously conditionally executed.
[Bug target/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Component|rtl-optimization|target --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, looks like a target issue. We expand from c = a[1]; c$2_10 = MEM[(struct S1[2] *)a + 18B]; b.0_4 = b; MEM[(struct S1 *)c + 2B] = c$2_10; MEM[(struct S1 *)c + 4B] = 0; *b.0_4 = c; if (c$2_10 != 0) .. _6 = a[0].f3; if (_6 != 1) ... and get movzbl a+18(%rip), %eax movdqa a+16(%rip), %xmm0 movq%xmm0, %rdx movq%rax, %rcx salq$16, %rax andq$-16711681, %rdx orq %rax, %rdx xorl%eax, %eax testb %cl, %cl movq%rdx, 8(%rsp) movq8(%rsp), %xmm0 pinsrw $2, %eax, %xmm0 movqb(%rip), %rax movups %xmm0, (%rax) --- jne .L2 .L3: jmp .L3 .p2align 4,,10 .p2align 3 .L2: cmpl$1, a+8(%rip) jne .L7 but --- stores the wrong value here. -mno-sse2 fixes the testcase.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #66 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Aug 5 11:20:59 2015
New Revision: 226618
URL: https://gcc.gnu.org/viewcvs?rev=226618root=gccview=rev
Log:
Backport from trunk
2015-05-12 Andrew MacLeod amacl...@redhat.com
PR target/65697
* coretypes.h (MEMMODEL_SYNC, MEMMODEL_BASE_MASK): New macros.
(enum memmodel): Add SYNC_{ACQUIRE,RELEASE,SEQ_CST}.
* tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed)
(is_mm_consume,is_mm_acquire, is_mm_release, is_mm_acq_rel)
(is_mm_seq_cst, is_mm_sync): New accessor functions.
* builtins.c (expand_builtin_sync_operation)
(expand_builtin_compare_and_swap): Use MEMMODEL_SYNC_SEQ_CST.
(expand_builtin_sync_lock_release): Use MEMMODEL_SYNC_RELEASE.
(get_memmodel, expand_builtin_atomic_compare_exchange)
(expand_builtin_atomic_load, expand_builtin_atomic_store)
(expand_builtin_atomic_clear): Use new accessor routines.
(expand_builtin_sync_synchronize): Use MEMMODEL_SYNC_SEQ_CST.
* optabs.c (expand_compare_and_swap_loop): Use MEMMODEL_SYNC_SEQ_CST.
(maybe_emit_sync_lock_test_and_set): Use new accessors and
MEMMODEL_SYNC_ACQUIRE.
(expand_sync_lock_test_and_set): Use MEMMODEL_SYNC_ACQUIRE.
(expand_mem_thread_fence, expand_mem_signal_fence, expand_atomic_load)
(expand_atomic_store): Use new accessors.
* emit-rtl.c (need_atomic_barrier_p): Add additional enum cases.
* tsan.c (instrument_builtin_call): Update check for memory model
beyond
final enum to use MEMMODEL_LAST.
* c-family/c-common.c: Use new accessor for memmodel_base.
* config/aarch64/aarch64.c (aarch64_expand_compare_and_swap): Use new
accessors.
* config/aarch64/atomics.md (atomic_loadmode,atomic_storemode)
(arch64_load_exclusivemode, aarch64_store_exclusivemode)
(mem_thread_fence, *dmb): Likewise.
* config/alpha/alpha.c (alpha_split_compare_and_swap)
(alpha_split_compare_and_swap_12): Likewise.
* config/arm/arm.c (arm_expand_compare_and_swap)
(arm_split_compare_and_swap, arm_split_atomic_op): Likewise.
* config/arm/sync.md (atomic_loadmode, atomic_storemode)
(atomic_loaddi): Likewise.
* config/i386/i386.c (ix86_destroy_cost_data, ix86_memmodel_check):
Likewise.
* config/i386/sync.md (mem_thread_fence, atomic_storemode): Likewise.
* config/ia64/ia64.c (ia64_expand_atomic_op): Add new memmodel cases
and
use new accessors.
* config/ia64/sync.md (mem_thread_fence, atomic_loadmode)
(atomic_storemode, atomic_compare_and_swapmode)
(atomic_exchangemode): Use new accessors.
* config/mips/mips.c (mips_process_sync_loop): Likewise.
* config/pa/pa.md (atomic_loaddi, atomic_storedi): Likewise.
* config/rs6000/rs6000.c (rs6000_pre_atomic_barrier)
(rs6000_post_atomic_barrier): Add new cases.
(rs6000_expand_atomic_compare_and_swap): Use new accessors.
* config/rs6000/sync.md (mem_thread_fence): Add new cases.
(atomic_loadmode): Add new cases and use new accessors.
(store_quadpti): Add new cases.
* config/s390/s390.md (mem_thread_fence, atomic_storemode): Use new
accessors.
* config/sparc/sparc.c (sparc_emit_membar_for_model): Use new
accessors.
* doc/extend.texi: Update docs to indicate 16 bits are used for memory
model, not 8.
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/builtins.c
branches/gcc-5-branch/gcc/c-family/c-common.c
branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
branches/gcc-5-branch/gcc/config/aarch64/atomics.md
branches/gcc-5-branch/gcc/config/alpha/alpha.c
branches/gcc-5-branch/gcc/config/arm/arm.c
branches/gcc-5-branch/gcc/config/arm/sync.md
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/config/i386/sync.md
branches/gcc-5-branch/gcc/config/ia64/ia64.c
branches/gcc-5-branch/gcc/config/ia64/sync.md
branches/gcc-5-branch/gcc/config/mips/mips.c
branches/gcc-5-branch/gcc/config/pa/pa.md
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/config/rs6000/sync.md
branches/gcc-5-branch/gcc/config/s390/s390.md
branches/gcc-5-branch/gcc/config/sparc/sparc.c
branches/gcc-5-branch/gcc/coretypes.h
branches/gcc-5-branch/gcc/doc/extend.texi
branches/gcc-5-branch/gcc/emit-rtl.c
branches/gcc-5-branch/gcc/optabs.c
branches/gcc-5-branch/gcc/tree.h
branches/gcc-5-branch/gcc/tsan.c
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #67 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Wed Aug 5 11:29:28 2015 New Revision: 226619 URL: https://gcc.gnu.org/viewcvs?rev=226619root=gccview=rev Log: Backport from trunk. 2015-06-01 Matthew Wahab matthew.wa...@arm.com PR target/65697 * config/aarch64/aarch64.c (aarch64_emit_post_barrier): New. (aarch64_split_atomic_op): Check for __sync memory models, emit appropriate initial loads and final barriers. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
[Bug fortran/67123] ICE with source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-05 CC||vehre at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think it is a duplicate of pr66927, at least it is fixed by the patch in comment 6.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #68 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Wed Aug 5 11:40:25 2015 New Revision: 226620 URL: https://gcc.gnu.org/viewcvs?rev=226620root=gccview=rev Log: Backport from trunk. 2015-06-01 Matthew Wahab matthew.wa...@arm.com PR target/65697 * config/aarch64/aarch64.c (aarch64_split_compare_and_swap): Check for __sync memory models, emit initial loads and final barriers as appropriate. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
[Bug fortran/67125] New: Incorrect bounds with source allocation, source=function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67125 Bug ID: 67125 Summary: Incorrect bounds with source allocation, source=function Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- The following code prints 0 2 while I think the correct result should be 1 3 (using gfortran 6.0.0): program p implicit none integer, allocatable :: a(:) allocate( a , source=f(3) ) write(*,*) lbound(a,1), ubound(a,1) ! prints 0 2 instead of 1 3 contains pure function f(i) integer, intent(in) :: i integer :: f(i) f = 2*i end function f end program p
[Bug fortran/67125] Incorrect bounds with source allocation, source=function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67125 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-05 CC||vehre at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #69 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Wed Aug 5 11:48:43 2015 New Revision: 226621 URL: https://gcc.gnu.org/viewcvs?rev=226621root=gccview=rev Log: Backport from trunk 2015-06-01 Matthew Wahab matthew.wa...@arm.com PR target/65697 * gcc.target/aarch64/sync-comp-swap.c: New. * gcc.target/aarch64/sync-comp-swap.x: New. * gcc.target/aarch64/sync-op-acquire.c: New. * gcc.target/aarch64/sync-op-acquire.x: New. * gcc.target/aarch64/sync-op-full.c: New. * gcc.target/aarch64/sync-op-full.x: New. * gcc.target/aarch64/sync-op-release.c: New. * gcc.target/aarch64/sync-op-release.x: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-comp-swap.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-comp-swap.x branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-op-acquire.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-op-acquire.x branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-op-full.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-op-full.x branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-op-release.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/sync-op-release.x Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #25 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Wed Aug 5 12:06:25 2015 New Revision: 226622 URL: https://gcc.gnu.org/viewcvs?rev=226622root=gccview=rev Log: 2015-08-05 Paul Thomas pa...@gcc.gnu.org PR fortran/52846 * module.c (check_access): Return true if new static flag 'dump_smod' is true.. (gfc_dump_module): Rename original 'dump_module' and call from new version. Use 'dump_smod' rather than the stack state to determine if a submodule is being processed. The new version of this procedure sets 'dump_smod' depending on the stack state and then writes both the mod and smod files if a module is being processed or just the smod for a submodule. (gfc_use_module): Eliminate the check for module_name and submodule_name being the same. * trans-decl.c (gfc_finish_var_decl, gfc_build_qualified_array, get_proc_pointer_decl): Set TREE_PUBLIC unconditionally and use the conditions to set DECL_VISIBILITY as hidden and to set as true DECL_VISIBILITY_SPECIFIED. 2015-08-05 Paul Thomas pa...@gcc.gnu.org PR fortran/52846 * lib/fortran-modules.exp: Call cleanup-submodules from cleanup-modules. * gfortran.dg/public_private_module_2.f90: Add two XFAILS to cover the cases where private entities are no longer optimized away. * gfortran.dg/public_private_module_6.f90: Add an XFAIL for the same reason. * gfortran.dg/submodule_1.f08: Change cleanup module names. * gfortran.dg/submodule_5.f08: The same. * gfortran.dg/submodule_9.f08: The same. * gfortran.dg/submodule_10.f08: New test Added: trunk/gcc/testsuite/gfortran.dg/submodule_10.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/public_private_module_2.f90 trunk/gcc/testsuite/gfortran.dg/public_private_module_6.f90 trunk/gcc/testsuite/gfortran.dg/submodule_1.f08 trunk/gcc/testsuite/gfortran.dg/submodule_5.f08 trunk/gcc/testsuite/gfortran.dg/submodule_9.f08 trunk/gcc/testsuite/lib/fortran-modules.exp
[Bug target/67126] New: [6 Regression][SH] gcc.target/sh/pr51244-12.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126
Bug ID: 67126
Summary: [6 Regression][SH] gcc.target/sh/pr51244-12.c failures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
There are two new failures:
FAIL: gcc.target/sh/pr51244-12.c scan-assembler-times negc 15
FAIL: gcc.target/sh/pr51244-12.c scan-assembler-times addc 3
which are triggered by the test case
int
test08 (char a)
{
return ((a 1) == 0) ? 0x7FFF : 0x8000;
}
Before it compiled to:
mov r4,r0
tst #1,r0
mov.l .L69,r0
rts
negcr0,r0
.L70:
.align 2
.L69:
.long -2147483648
now it compiles to:
mov.l .L69,r1
shlrr4
mov #0,r0
rts
addcr1,r0
.L70:
.align 2
.L69:
.long 2147483647
Using the tst insn in this case is a bit better.
Before combine would try this pattern
;; Use negc to store the T bit in a MSB of a reg in the following way:
;; T = 0: 0x8000 - reg
;; T = 1: 0x7FFF - reg
;; This works because 0 - 0x8000 = 0x8000.
(define_insn_and_split *mov_t_msb_neg
[(set (match_operand:SI 0 arith_reg_dest)
(minus:SI (const_int -2147483648) ;; 0x8000
(match_operand 1 treg_set_expr)))
(clobber (reg:SI T_REG))]
which now is matched as:
Successfully matched this instruction:
(parallel [
(set (reg:SI 162 [ D.1897 ])
(plus:SI (and:SI (reg:SI 4 r4 [ a+-3 ])
(const_int 1 [0x1]))
(const_int 2147483647 [0x7fff])))
(clobber (reg:SI 147 t))
])
This is the other *mov_t_msb_neg pattern variant. The treg_set_expr is the
shlr insn in this case, which is non-negating and hence addc is used instead of
negc. The (and (reg (const_int 1))) pattern above could be added as a special
case which would split into tst insn.
[Bug middle-end/67120] [6 Regression] wrong code for volatile pointers at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67120 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 5 12:47:59 2015 New Revision: 226623 URL: https://gcc.gnu.org/viewcvs?rev=226623root=gccview=rev Log: 2015-08-05 Richard Biener rguent...@suse.de PR middle-end/67120 * match.pd: Compare address bases with == if they are decls or SSA names, not operand_equal_p. Otherwise fail. * gcc.dg/torture/pr67120.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr67120.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/67121] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r223863.
[Bug target/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r225852.
[Bug target/67127] New: [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67127 Bug ID: 67127 Summary: [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yroux at gcc dot gnu.org Target Milestone: --- Hi, Commit r225461 which avoids odd-number ldrd/strd in movdi, and its backport on gcc-5-branch (r225467) introduced several segfault (stack overflow) in the testsuite when the compiler is built for big-endian + vfp targets. The issue is that the movdi pattern calls gen_lowpart (SImode, operands[0]), operands being in DImode, but the mode of the register cannot be changed as it is explained in the macro CANNOT_CHANGE_MODE_CLASS definition: In big-endian mode, modes greater than word size (i.e. DFmode) are stored in VFP registers in little-endian order. We can't describe that accurately to GCC, so avoid taking subregs of such values. Thus, gen_lowpart_general makes a copy of that register and copy it, which calls again emit_move_insn and gen_movdi and so on ... I've a patch under test that prevent doing this when the mode of a register can't be changed, but the regression discussed in this thread may be back then... https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00216.html
[Bug middle-end/67120] [6 Regression] wrong code for volatile pointers at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67120 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/67126] [6 Regression][SH] gcc.target/sh/pr51244-12.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|unknown |6.0 Depends on||67103 Target Milestone|--- |6.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Probably related to PR67103. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67103 [Bug 67103] [6 Regression]: gcc.target/i386/cmov2.c and gcc.target/i386/cmov3.c FAIL on x86
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #70 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Wed Aug 5 13:27:41 2015 New Revision: 226625 URL: https://gcc.gnu.org/viewcvs?rev=226625root=gccview=rev Log: Backport from trunk: 2015-06-29 Matthew Wahab matthew.wa...@arm.com PR target/65697 * config/armc/arm.c (arm_split_atomic_op): For ARMv8, replace an initial acquire barrier with final barrier. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c
[Bug target/67126] [6 Regression][SH] gcc.target/sh/pr51244-12.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Probably related to PR67103. Yep, I've been following the discussion on the patches ML. I was expecting something to break for SH, too :)
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #71 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Wed Aug 5 13:40:14 2015 New Revision: 226627 URL: https://gcc.gnu.org/viewcvs?rev=226627root=gccview=rev Log: Backport from trunk: 2015-06-29 Matthew Wahab matthew.wa...@arm.com PR target/65697 * config/arm/arm.c (arm_split_compare_and_swap): For ARMv8, replace an initial acquire barrier with final barrier. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #72 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Wed Aug 5 13:43:04 2015 New Revision: 226628 URL: https://gcc.gnu.org/viewcvs?rev=226628root=gccview=rev Log: Backport from trunk: 2015-06-29 Matthew Wahab matthew.wa...@arm.com PR target/65697 * gcc.target/arm/armv-sync-comp-swap.c: New. * gcc.target/arm/armv-sync-op-acquire.c: New. * gcc.target/arm/armv-sync-op-full.c: New. * gcc.target/arm/armv-sync-op-release.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #17 from boger at us dot ibm.com --- Created attachment 36132 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36132action=edit Configure gold linker with split stack if available Attaching my patch to detect for split stack support within the gold linker that is available by the gcc build, and then use it with gccgo compiles. Here are the steps: - When configuring gcc, check for split stack support in the gold linker either identified as the linker to use in the gcc build or found in the path at build time. This check currently only works on ppc64le; I couldn't get it to fail on ppc64 even with older (2.24) gold linkers. Not sure what might be wanted for other targets. If the support is there then HAVE_LD_GOLD_SUPPORTS_SPLIT_STACK is defined. - Modify the check in libgo configure to detect that the gold linker used with the gccgo that was just built supports split stack, defining LINKER_SUPPORTS_SPLIT_STACK if it is. - Add -fuse-ld=gold to the linker spec if HAVE_LD_GOLD_SUPPORTS_SPLIT_STACK is defined (not for m32). - Define TARGET_CAN_SPLIT_STACK for Power targets if the glibc level is correct. This is needed by go/gospec.c to enable the -fsplit-stack option when linking. Comments?
[Bug tree-optimization/67121] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 5 14:16:51 2015 New Revision: 226630 URL: https://gcc.gnu.org/viewcvs?rev=226630root=gccview=rev Log: 2015-08-05 Richard Biener rguent...@suse.de PR tree-optimization/67121 * tree-if-conv.c (combine_blocks): Clear range-info produced by stmts no longer executed conditionally. * gcc.dg/torture/pr67121.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr67121.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/67121] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Target Milestone|6.0 |5.3 Summary|[6 Regression] wrong code |[5 Regression] wrong code |at -O3 on x86_64-linux-gnu |at -O3 on x86_64-linux-gnu --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Marking for backport.
[Bug tree-optimization/67121] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67121 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk but latent issue on the branches, esp. the gcc 5 branch which also uses old ranges during VRP2.
[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311 --- Comment #17 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Aug 5 14:23:42 2015 New Revision: 226632 URL: https://gcc.gnu.org/viewcvs?rev=226632root=gccview=rev Log: gcc/ PR middle-end/66311 * wide-int.cc (wi::from_mpz): Make sure that absolute mpz value is zero- rather than sign-extended. gcc/testsuite/ 2015-08-05 Francois-Xavier Coudert fxcoud...@gcc.gnu.org PR middle-end/66311 * gfortran.dg/pr66311.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/pr66311.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/wide-int.cc
[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311 --- Comment #18 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Fixed on trunk. I'll wait a few days to see whether there's any unexpected fallout before backporting to gcc 5.
[Bug ada/66965] gnat.dg/specs/addr1.ads obsolete -- failing on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66965 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-05 CC||charlet at gcc dot gnu.org, ||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed between r222978 (PASS) and r223099 (FAIL).
[Bug target/58271] ICE in gcc for a MIPS target during compilation with -mpaired-single -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58271 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Fixed some time ago, but I forgot to close it, sorry.
[Bug target/55721] -mabi=64 compilation results in unknown UNSPEC note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55721 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug target/51931] No support for MIPS16 long branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51931 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Fix some time ago.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #7 from xili_gchen_5257 at hotmail dot com --- On 8/5/15 00:45, manu at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Iain Buclaw from comment #5) I can still reproduce the wrong-line diagnostic using gcc (GCC) 6.0.0 20150720 (experimental). However GDB has been building just fine for a while now. But I don't know if that is due to a change on GCC or GDB side. Probably GDB worked around the issue or silence the warning via #pragma. That doesn't mean that the bug is fixed. OK, thanks. I shall try to start analyzing it in 2015-08-20, and try to fix it within this month -- during these days, I am trying tilegx qemu for gcc testsuite. And welcome another members to analyze it. Thanks.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #18 from Ian Lance Taylor ian at airs dot com --- In the patch in comment #17, the code in gcc/configure.ac looks misplaced: shouldn't it be before the ;;, and not add another ;;? Can you explain why the test in libgo/configure.ac will fail for a linker that does not support split-stack? I'm not quite seeing it. I haven't tried it, though.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #19 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #18) In the patch in comment #17, the code in gcc/configure.ac looks misplaced: shouldn't it be before the ;;, and not add another ;;? Can you explain why the test in libgo/configure.ac will fail for a linker that does not support split-stack? I'm not quite seeing it. I haven't tried it, though. For ppc64le, some split stack support was recently added to the gold linker by Alan, so if you try to use a gold linker that is too old, you will get an error like this: /usr/bin/ld.gold -o sss ss-callee.o ss-call.o --defsym __morestack=0 /usr/bin/ld.gold: error: linker does not include stack split support required by ss-call.o But with one after he added the support, it does not get this error. If it is not gold then it doesn't get the error either. However on ppc64 (BE, not LE) it never gets the error, old or new gold. Alan would have to answer why. I don't know about other targets, I haven't tried it. I suppose the test could be on the version number for the gold linker at least for ppc64 LE or BE. Sorry I probably messed up the ;; I will double check on that.
[Bug c++/66336] [C++14][Variable templates] Spurious error: expansion pattern contains no argument packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66336 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed on the trunk by r225692.
[Bug c++/65706] [c++14] Pack expansion with variable template incorrectly marked as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65706 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed on the trunk by r225692. *** This bug has been marked as a duplicate of bug 66336 ***
[Bug c++/66336] [C++14][Variable templates] Spurious error: expansion pattern contains no argument packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66336 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- *** Bug 65706 has been marked as a duplicate of this bug. ***
[Bug c++/64035] [C++11] ICE in reshape_init_r when using initializer list aggregate initialization for default function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64035
Mikhail Maltsev miyuki at gcc dot gnu.org changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment #6 from Mikhail Maltsev miyuki at gcc dot gnu.org ---
(In reply to Jonas Platte from comment #5)
With decent experience in C++, but no experience working on GCC (or any
other compiler), could I help fixing this?
Certainly. Some relevant wiki pages:
https://gcc.gnu.org/wiki/GettingStarted - about contributing to GCC (in
general)
https://gcc.gnu.org/wiki/DebuggingGCC - notes on debugging
Steps which seem reasonable (for me) to start debugging this particular case:
1. build the compiler with debugging information (-ggdb3) and low optimization
level (-Og)
2. run the compiler proper from build/gcc directory under debugger (suppose
that build is the top-level build directory and test.cc is your testcase):
gdb --args ./cc1plus test.cc
(note: gdb should load .gdbinit which is created in gcc directory during build;
it contains several useful macros)
3. I hit the breakpoint in fancy_abort (it is set by .gdbinit) and go one frame
up:
#1 0x00605a28 in reshape_init_r (type=array_type 0x76800348,
d=d@entry=0x7fffd870, first_initializer_p=first_initializer_p@entry=false,
complain=complain@entry=2) at /home/miyuki/gcc/src/gcc/cp/decl.c:5734
5734 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (init));
This asserion fails. I can look at the contents of init like this:
(gdb) p init
$1 = constructor 0x7680adf8
(gdb) p debug_tree(init)
constructor 0x7680adf8
type array_type 0x76800348
type integer_type 0x7669f7e0 int public SI
size integer_cst 0x766bd0a8 constant 32
unit size integer_cst 0x766bd0c0 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7669f7e0
precision 32 min integer_cst 0x766bd060 -2147483648 max integer_cst
0x766bd078 2147483647
pointer_to_this pointer_type 0x766c1930
DI
size integer_cst 0x7669be58 constant 64
unit size integer_cst 0x7669be70 constant 8
align 32 symtab 0 alias set -1 canonical type 0x76800348
domain integer_type 0x768002a0 type integer_type 0x7669f1f8
sizetype
type_6 DI size integer_cst 0x7669be58 64 unit size
integer_cst 0x7669be70 8
align 64 symtab 0 alias set -1 canonical type 0x768002a0
precision 64 min integer_cst 0x7669be88 0 max integer_cst 0x7669bf60
1
constant static lngt 0
So, init is some AST node. If I go 4 frames up, I can see an AST for the entire
initializer:
#5 0x005c0305 in implicit_conversion (to=to@entry=record_type
0x76800150 testStruct, from=lang_type 0x767f6a80 init list,
expr=expr@entry=constructor 0x7680ade0, c_cast_p=c_cast_p@entry=false,
flags=flags@entry=5, complain=2, complain@entry=3) at
/home/miyuki/gcc/src/gcc/cp/call.c:1763
1763 expr = reshape_init (to, expr, complain);
constructor 0x7680ade0
type lang_type 0x767f6a80 init list VOID
align 1 symtab 0 alias set -1 canonical type 0x767f6a80
lngt 1
val constructor 0x7680adf8
type array_type 0x76800348 type integer_type 0x7669f7e0 int
DI
size integer_cst 0x7669be58 constant 64
unit size integer_cst 0x7669be70 constant 8
align 32 symtab 0 alias set -1 canonical type 0x76800348 domain
integer_type 0x768002a0
constant static lngt 0
You need to figure out what went wrong here and why do we get unexpected AST
(perhaps by comparing it with AST that is built in func({{}}); case).
[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66260 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #26 from Mikael Morin mikael at gcc dot gnu.org --- I'm preparing the backports.
[Bug c++/65195] Variable template cannot be used as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65195 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #12 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #11) I have a version of gcc 5.2.0 compiled with the -fsanitize=undefined option. This sanitized version gave me a runtime error due to dereferencing the pointer dst_ctx which was NULL. After the change I suggested the message disappeared. You may double check my finding, as I did myself, by putting assert(dst_ctx) before its dereferencing in ipa-prop.c as in assert(dst_ctx),dst_ctx-combine_with (ctx); It happens twice in isa-prop.c Then try it with the two C codes I sent, with option -O2 Hello. I double-checked that there's no other NULL dereferencing in ipa-prop.c. Can you please confirm that gcc-5-branch works correctly? Thanks, Martin
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #27 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Wed Aug 5 16:15:40 2015 New Revision: 226636 URL: https://gcc.gnu.org/viewcvs?rev=226636root=gccview=rev Log: Fix random class_allocate_18.f90 failure PR fortran/64921 gcc/fortran/ * class.c (generate_finalization_wrapper): Set finalization procedure symbol's always_explicit attribute. gcc/testsuite/ * gfortran.dg/class_allocate_20.f90: New. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/class_allocate_20.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/class.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #28 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Wed Aug 5 16:42:00 2015 New Revision: 226639 URL: https://gcc.gnu.org/viewcvs?rev=226639root=gccview=rev Log: Fix random class_allocate_18.f90 failure PR fortran/64921 gcc/fortran/ * class.c (generate_finalization_wrapper): Set finalization procedure symbol's always_explicit attribute. gcc/testsuite/ * gfortran.dg/class_allocate_20.f90: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_allocate_20.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/class.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Mikael Morin mikael at gcc dot gnu.org --- Fixed for 6.0, 5.3 and 4.9.4, closing.
[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66260 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jason Merrill from comment #1) Fixed on trunk. Oops, haven't checked in the fix yet.
[Bug c++/66596] Type that is not dependent on the variable template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66596 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #31 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Wed Aug 5 17:36:29 2015 New Revision: 226640 URL: https://gcc.gnu.org/viewcvs?rev=226640root=gccview=rev Log: gcc/ChangeLog: 2015-08-05 Manuel López-Ibáñez m...@gcc.gnu.org Jeff Law l...@redhat.com PR c/16351 * doc/invoke.texi (Wnull-dereference): New. * tree-vrp.c (infer_value_range): Update call to infer_nonnull_range. * gimple-ssa-isolate-paths.c (find_implicit_erroneous_behaviour): Warn for potential NULL dereferences. (find_explicit_erroneous_behaviour): Warn for NULL dereferences. * ubsan.c (instrument_nonnull_arg): Call infer_nonnull_range_by_attribute. (instrument_nonnull_return): Likewise. * common.opt (Wnull-dereference); New. * gimple.c (infer_nonnull_range): Remove bool arguments. (infer_nonnull_range_by_dereference): New. (infer_nonnull_range_by_attribute): New. * gimple.h: Update declarations. gcc/testsuite/ChangeLog: 2015-08-05 Manuel López-Ibáñez m...@gcc.gnu.org Jeff Law l...@redhat.com PR c/16351 * gcc.dg/tree-ssa/isolate-2.c: Close comment. * gcc.dg/tree-ssa/isolate-4.c: Likewise. * gcc.dg/tree-ssa/wnull-dereference.c: New test. * gcc.dg/tree-ssa/isolate-1.c: Test warnings with -Wnull-dereference. * gcc.dg/tree-ssa/isolate-3.c: Likewise. * gcc.dg/tree-ssa/isolate-5.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/wnull-dereference.c Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-ssa-isolate-paths.c trunk/gcc/gimple.c trunk/gcc/gimple.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-5.c trunk/gcc/tree-vrp.c trunk/gcc/ubsan.c
[Bug c++/66619] Internal compiler error: variable template deduced by template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66619 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- This
[Bug c++/66649] variable template specializations not being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66649 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/66923] Variable template initialized using auto deduces wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66923 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-05 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #32 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The NULL dereference warnings originally requested should be working in GCC 6 (unless we find some issue and the patch gets reverted). However, the original patch by Jeff also used the nonnull attribute to give even more warnings, thus I'm leaving this open for now.
[Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/66619] Internal compiler error: variable template deduced by template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66619 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 17:51:29 2015 New Revision: 226641 URL: https://gcc.gnu.org/viewcvs?rev=226641root=gccview=rev Log: PR c++/65195 PR c++/66619 * semantics.c (finish_id_expression): Call convert_from_reference for variable template. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ37.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ40.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/65195] Variable template cannot be used as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65195 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 17:51:29 2015 New Revision: 226641 URL: https://gcc.gnu.org/viewcvs?rev=226641root=gccview=rev Log: PR c++/65195 PR c++/66619 * semantics.c (finish_id_expression): Call convert_from_reference for variable template. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ37.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ40.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/66923] Variable template initialized using auto deduces wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66923 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 17:56:14 2015 New Revision: 226642 URL: https://gcc.gnu.org/viewcvs?rev=226642root=gccview=rev Log: PR c++/66260 PR c++/66596 PR c++/66649 PR c++/66923 * pt.c (lookup_template_variable): Use NULL_TREE for type. (instantiate_template_1): Also set DECL_TI_ARGS based on the immediate parent. (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Handle variable templates. (finish_template_variable): Add complain parm. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ36.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ38.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp1y/var-templ32.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ35.C
[Bug c++/66596] Type that is not dependent on the variable template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66596 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 17:56:14 2015 New Revision: 226642 URL: https://gcc.gnu.org/viewcvs?rev=226642root=gccview=rev Log: PR c++/66260 PR c++/66596 PR c++/66649 PR c++/66923 * pt.c (lookup_template_variable): Use NULL_TREE for type. (instantiate_template_1): Also set DECL_TI_ARGS based on the immediate parent. (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Handle variable templates. (finish_template_variable): Add complain parm. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ36.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ38.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp1y/var-templ32.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ35.C
[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66260 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 17:56:14 2015 New Revision: 226642 URL: https://gcc.gnu.org/viewcvs?rev=226642root=gccview=rev Log: PR c++/66260 PR c++/66596 PR c++/66649 PR c++/66923 * pt.c (lookup_template_variable): Use NULL_TREE for type. (instantiate_template_1): Also set DECL_TI_ARGS based on the immediate parent. (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Handle variable templates. (finish_template_variable): Add complain parm. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ36.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ38.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp1y/var-templ32.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ35.C
[Bug c++/66649] variable template specializations not being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66649 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 17:56:14 2015 New Revision: 226642 URL: https://gcc.gnu.org/viewcvs?rev=226642root=gccview=rev Log: PR c++/66260 PR c++/66596 PR c++/66649 PR c++/66923 * pt.c (lookup_template_variable): Use NULL_TREE for type. (instantiate_template_1): Also set DECL_TI_ARGS based on the immediate parent. (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Handle variable templates. (finish_template_variable): Add complain parm. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ36.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ38.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp1y/var-templ32.C trunk/gcc/testsuite/g++.dg/cpp1y/var-templ35.C
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #20 from boger at gcc dot gnu.org --- Author: boger Date: Wed Aug 5 18:07:16 2015 New Revision: 226643 URL: https://gcc.gnu.org/viewcvs?rev=226643root=gccview=rev Log: 2015-08-15 Lynn Boger labo...@linux.vnet.ibm.com PR target/66870 * gcc/config/rs6000/rs6000.c (rs6000_emit_prologue): Check for no_split_stack function attribute along with flag_split_stack. (rs6000_expand_split_stack_prologue): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c++/67117] [c++-concepts] Constraints ignored on variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67117 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 5 18:13:24 2015 New Revision: 226646 URL: https://gcc.gnu.org/viewcvs?rev=226646root=gccview=rev Log: PR c++/67117 * decl.c (grokvardecl): Set constraints here. * pt.c (process_partial_specialization): Not here. (finish_template_variable): Check constraints. Added: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/var-templ1.C Modified: branches/c++-concepts/ChangeLog.concepts branches/c++-concepts/gcc/cp/decl.c branches/c++-concepts/gcc/cp/pt.c branches/c++-concepts/gcc/testsuite/g++.dg/concepts/var-concept3.C
[Bug c++/67117] [c++-concepts] Constraints ignored on variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67117 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #11 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to ctice from comment #10) Author: ctice Date: Sun Aug 2 01:17:39 2015 New Revision: 226471 URL: https://gcc.gnu.org/viewcvs?rev=226471root=gccview=rev Log: Fix PR 66521 Thanks for pushing this! While you're at it, could you take a look at my patch for libstdc++-v3/acinclude.m4, too? Just a heads up, though, even with my additional patch, I still get a bunch of vtv-related warnings upon linking, about not being able to export certain hidden symbols... I'll attach that output next.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #12 from Eric Gallager egall at gwmail dot gwu.edu --- Created attachment 36133 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36133action=edit vtv-related warnings printed upon linking libstdc++ (as I said I'd attach in my previous comment)
[Bug rtl-optimization/67029] [5/6 regression] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- The problem is /* The value of get_preferred_alternatives for the current instruction, supplemental to recog_data. */ static alternative_mask preferred_alternatives; ira_implicitly_set_insn_hard_regs may use the staled preferred_alternatives: #0 ira_implicitly_set_insn_hard_regs (set=0x7fffd950) at /export/gnu/import/git/sources/gcc/gcc/ira-lives.c:847 #1 0x0156d604 in sched_analyze_insn (deps=0x7fffdba0, x=0x718277d0, insn=0x71823240) at /export/gnu/import/git/sources/gcc/gcc/sched-deps.c:2901 #2 0x015703f5 in deps_analyze_insn (deps=0x7fffdba0, insn=0x71823240) at /export/gnu/import/git/sources/gcc/gcc/sched-deps.c:3675 #3 0x01570aa6 in sched_analyze (deps=0x7fffdba0, head=0x71823240, tail=0x71708990) at /export/gnu/import/git/sources/gcc/gcc/sched-deps.c:3822 #4 0x00c4b3d0 in compute_block_dependences (bb=0) at /export/gnu/import/git/sources/gcc/gcc/sched-rgn.c:2743 #5 0x00c4ccae in sched_rgn_compute_dependencies (rgn=0) at /export/gnu/import/git/sources/gcc/gcc/sched-rgn.c:3267 #6 0x00c4c2bf in schedule_region (rgn=0) at /export/gnu/import/git/sources/gcc/gcc/sched-rgn.c:3023 #7 0x00c4d3e6 in schedule_insns () at /export/gnu/import/git/sources/gcc/gcc/sched-rgn.c:3426 #8 0x00c4dca4 in rest_of_handle_sched ()
[Bug rtl-optimization/67029] [5/6 regression] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00313.html
[Bug bootstrap/67128] New: Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128
Bug ID: 67128
Summary: Makefile.in, libcc1 and --enable-shared
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
As of current master (47dcac97f8004116), Makefile.in contains:
configure-libcc1:
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
test ! -f $(HOST_SUBDIR)/libcc1/Makefile || exit 0; \
$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libcc1; \
$(HOST_EXPORTS) \
echo Configuring in $(HOST_SUBDIR)/libcc1; \
cd $(HOST_SUBDIR)/libcc1 || exit 1; \
case $(srcdir) in \
/* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
*) topdir=`echo $(HOST_SUBDIR)/libcc1/ | \
sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
esac; \
module_srcdir=libcc1; \
$(SHELL) \
$$s/$$module_srcdir/configure \
--srcdir=$${topdir}/$$module_srcdir \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} --enable-shared \
|| exit 1
@endif libcc1
If I run at root-level ./configure --disable-shared, then libstdc++ is build
static and building libcc1 fails with:
/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: error
adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:437: recipe for target 'libcc1.la' failed
make[3]: *** [libcc1.la] Error 1
make[3]: Leaving directory '/src/gcc/gcc-git/libcc1'
Makefile:319: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/src/gcc/gcc-git/libcc1'
Makefile:12120: recipe for target 'all-libcc1' failed
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory '/src/gcc/gcc-git'
Makefile:908: recipe for target 'all' failed
make: *** [all] Error 2
Removing --enable-shared from Makefile.(in) solves the problem.
[Bug bootstrap/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 --- Comment #1 from Дилян Палаузов dilyan.palauzov at aegee dot org --- To be precise, here is the complete error message, when linking shared libcc1. I use GNU ld 2.25.51.20150804. libtool: link: /src/gcc/gcc-git/./gcc/xg++ -B/src/gcc/gcc-git/./gcc/ -nostdinc++ -nostdinc++ -I/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include -I/git/gcc/libstdc++-v3/libsupc++ -I/git/gcc/libstdc++-v3/include/backward -I/git/gcc/libstdc++-v3/testsuite/util -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/gcc60/x86_64-pc-linux-gnu/bin/ -B/usr/local/gcc60/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/gcc60/x86_64-pc-linux-gnu/include -isystem /usr/local/gcc60/x86_64-pc-linux-gnu/sys-include -fPIC -DPIC -shared -nostdlib /usr/lib/x86_64-linux-gnu/crti.o /src/gcc/gcc-git/./gcc/crtbeginS.o .libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/src/gcc/gcc-git/./gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 /src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm -lc -lgcc /src/gcc/gcc-git/./gcc/crtendS.o /usr/lib/x86_64-linux-gnu/crtn.o -static-libstdc++ -static-libgcc ../libiberty/pic/libiberty.a -Wl,-soname -Wl,libcc1.so.0 -Wl,-retain-symbols-file -Wl,/git/gcc/libcc1/libcc1.sym -o .libs/libcc1.so.0.0.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: /src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(eh_throw.o): relocation R_X86_64_32S against `.text._ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception' can not be used when making a shared object; recompile with -fPIC /src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:437: recipe for target 'libcc1.la' failed make[3]: *** [libcc1.la] Error 1 make[3]: Leaving directory '/src/gcc/gcc-git/libcc1' Makefile:319: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/src/gcc/gcc-git/libcc1' Makefile:12120: recipe for target 'all-libcc1' failed make[1]: *** [all-libcc1] Error 2 make[1]: Leaving directory '/src/gcc/gcc-git' Makefile:908: recipe for target 'all' failed make: *** [all] Error 2
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 Michael Karcher gcc-bugzilla at mkarcher dot dialup.fu-berlin.de changed: What|Removed |Added CC||gcc-bugzilla at mkarcher dot dialu ||p.fu-berlin.de --- Comment #15 from Michael Karcher gcc-bugzilla at mkarcher dot dialup.fu-berlin.de --- Created attachment 36134 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36134action=edit even further reduced test case I manually reduced the example even more. Interestingly it doesn't contain any C++ specific statements any more, yet it only fails -fcompare-debug with -x c++, but passes with -x c
[Bug c++/66596] Type that is not dependent on the variable template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66596 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.3 and 6.
[Bug c++/66649] variable template specializations not being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66649 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.3 and 6.
[Bug c++/66336] [C++14][Variable templates] Spurious error: expansion pattern contains no argument packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66336 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.3.
