[Bug target/70934] 16-byte atomics are unimplemented on s390x, but __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70934 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- They are implemented, you just have to make sure the variable you perform atomic on is also sufficiently aligned. a has only 8-byte alignment by default in the s390* ABI, which is not enough. You need ti a __attribute__((aligned (16))); or something similar.
[Bug libstdc++/70940] New: pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 Bug ID: 70940 Summary: pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- resource_adapter incorrectly requires that the Allocator provide: * A pointer typedef. * A default constructor. Furthermore it seems that do_allocate returns ill-aligned pointers. It seems that do_allocate(s, a) returns the pointers from 'Allocator.allocate(...)' directly even though they have no alignment guarantees.
[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935 --- Comment #2 from Jakub Jelinek --- This is tree_unswitch_outer_loop -> hoist_guard not resetting debug stmts that have some uses of SSA_NAMEs defined in the inner loop. But the transformation is really weird. We have: loop7== bb10 | v loop2 = />bb8 | inv test | / | | | something | \ | \ | v v \ | bb7 + | || +---+| loop2 end = | v bb13 DEBUG pm = defined_in_something And we move the inv test to bb 10, with one edge going to loop2, and the other to bb13 (newly added edge). If I understand the cfg right though, we've thus changed an endless loop (if inv test is false, bb8 not really having any side-effects just jumped to bb7 and back to bb8 forever) into no loop, and in addition the newly added edge from bb10 to bb13 of course means any SSA_NAMEs defined in loop2 can't be used.
[Bug c++/70925] Vectorized loop segfaults: read exceeds vector boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70925 Andreas Schaefer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andreas Schaefer --- Thanks, I missed the final clause. Also I've now found the cause for this bug in my code. Sorry for the noise.
[Bug c++/70906] [7 Regression] ice in add_expr, at tree.c:7925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70906 Markus Trippelsdorf changed: What|Removed |Added CC||j.v.dijk at tue dot nl --- Comment #5 from Markus Trippelsdorf --- *** Bug 70933 has been marked as a duplicate of this bug. ***
[Bug c++/70933] [7.0 regression] ICE with -Wall on valid code in inchash::add_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70933 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 70906 ***
[Bug tree-optimization/70916] [6 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "tree_operand_check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70916 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] gcc ICE at |[6 Regression] gcc ICE at |-O3 on valid code on|-O3 on valid code on |x86_64-linux-gnu in |x86_64-linux-gnu in |"tree_operand_check"|"tree_operand_check" --- Comment #7 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396
--- Comment #6 from Richard Biener ---
(In reply to Martin Liška from comment #5)
> Hi.
>
> With the updated version of the compiler, I still get the ICE for:
>
> $ cat tc.ii
>
> void fn1() {
> unsigned *a = 0;
> for (int i; i; ++i) {
> unsigned g(a[i] << 8 >> 24);
> a[i] = g;
> }
> }
>
> $ /home/marxin/bin/gcc2/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
> -fpreprocessed tc.ii -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3
> -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt
> -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2
> -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase
> -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f
> -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt
> -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl
> -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx
> -mno-clzero -mno-pku --param l1-cache-size=32 --param l1-cache-line-size=64
> --param l2-cache-size=8192 -mtune=haswell -quiet -dumpbase tc.ii -O3
>
> tc.ii:7:1: internal compiler error: in immed_wide_int_const, at
> emit-rtl.c:606
> }
> ^
> 0xa4cf35 immed_wide_int_const(generic_wide_int >
> const&, machine_mode)
> ../../gcc/emit-rtl.c:606
> 0x13929a9 change_zero_ext
> ../../gcc/combine.c:1
> 0x13937d8 recog_for_combine
> ../../gcc/combine.c:11148
> 0x13a175d try_combine
> ../../gcc/combine.c:3503
> 0x13a6fc1 combine_instructions
> ../../gcc/combine.c:1288
> 0x13a6fc1 rest_of_handle_combine
> ../../gcc/combine.c:14348
> 0x13a6fc1 execute
> ../../gcc/combine.c:14391
>
> Thanks
Looks like a different issue - please file a new bug.
#2 0x019c0fb7 in change_zero_ext (src=0x76688958)
at /space/rguenther/src/svn/trunk/gcc/combine.c:1
1 x = gen_rtx_AND (mode, x, immed_wide_int_const (mask, mode));
(gdb) l
11106 }
11107 else
11108 continue;
11109
0 wide_int mask = wi::mask (size, false, GET_MODE_PRECISION
(mode));
1 x = gen_rtx_AND (mode, x, immed_wide_int_const (mask, mode));
2
3 SUBST (**iter, x);
4 changed = true;
5 }
(gdb) p debug_rtx (src)
Cannot resolve function debug_rtx to any overloaded instance
(gdb) p src
$1 = (rtx *) 0x76688958
(gdb) p debug_rtx (*src)
(zero_extract:V8SI (mem:V8SI (reg:DI 240 [ ivtmp.29 ]) [1 MEM[base: 0B, index:
ivtmp.29_232, offset: 0B]+0 S32 A256])
(const_int 232 [0xe8])
(const_int 16 [0x10]))
$2 = void
looks like either an invalid zero_extract or change_zero_ext not properly
dealing with vector modes. It's already on insn 154:
(insn 154 153 156 17 (set (reg:V8SI 289 [ vect_g_10.15 ])
(zero_extract:V8SI (mem:V8SI (reg:DI 240 [ ivtmp.29 ]) [1 MEM[base: 0B,
index: ivtmp.29_232, offset: 0B]+0 S32 A256])
(const_int 232 [0xe8])
(const_int 16 [0x10]))) t.ii:4 3098 {lshrv8si3}
(expr_list:REG_DEAD (reg:V8SI 287 [ vect__5.14 ])
(nil)))
but only generated by combine as an intermediate insn it seems.
Trying 152 -> 153:
Failed to match this instruction:
(set (reg:V8SI 287 [ vect__5.14 ])
(ashift:V8SI (mem:V8SI (reg:DI 240 [ ivtmp.29 ]) [1 MEM[base: 0B, index:
ivtmp.29_232, offset: 0B]+0 S32 A256])
(const_int 8 [0x8])))
Trying 153 -> 154:
Failed to match this instruction:
(set (reg:V8SI 289 [ vect_g_10.15 ])
(lshiftrt:V8SI (ashift:V8SI (reg:V8SI 288 [ MEM[base: 0B, index:
ivtmp.29_232, offset: 0B] ])
(const_int 8 [0x8]))
(const_int 24 [0x18])))
Trying 152, 153 -> 154:
Failed to match this instruction:
(set (reg:V8SI 289 [ vect_g_10.15 ])
(zero_extract:V8SI (mem:V8SI (reg:DI 240 [ ivtmp.29 ]) [1 MEM[base: 0B,
index: ivtmp.29_232, offset: 0B]+0 S32 A256])
(const_int 232 [0xe8])
(const_int 16 [0x10])))
[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||jakub at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #7 from Jakub Jelinek ---
I'd say we really don't want vector mode ZERO_EXTRACTs/SIGN_EXTRACTs, so
perhaps
make_extraction could give up in that case, maybe:
/* Never narrow an object, since that might not be safe. */
if (mode != VOIDmode
&& GET_MODE_SIZE (extraction_mode) < GET_MODE_SIZE (mode))
extraction_mode = mode;
and inside of if just do
{
/* Avoid vector mode extractions. */
if (VECTOR_MODE_P (mode))
return NULL_RTX;
extraction_mode = mode;
}
Or should we punt even earlier?
[Bug target/70941] New: [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
Bug ID: 70941
Summary: [5/6/7 Regression] Test miscompiled with -O2.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Created attachment 38409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38409&action=edit
Reproducer.
Test case produces incorrect result with -O2 option.
Output:
> g++ -O0 repr.cpp; ./a.out
-109
> g++ -O3 repr.cpp; ./a.out
-110
GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/export/users/vlivinsk/gcc-trunk/bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/gnutester/stability/svn/trunk/configure
--prefix=/export/users/gnutester/stability/work/trunk/64/install
--enable-bootstrap=no --enable-languages=c,c++,fortran
Thread model: posix
gcc version 7.0.0 20160430 (experimental) (GCC)
Testcase:
#include
#include
char a = 0, b = 0, c = 0, d = 0;
int main() {
a = -(b - 405418259) - ((d && c) ^ 2040097152);
if (a != -109)
abort();
}
[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873 --- Comment #21 from Uroš Bizjak --- (In reply to H.J. Lu from comment #12) > I still see: > > vcvtss2sd (%ecx,%eax,4), %xmm5, %xmm5 > > without vxorpd. You are looking in the cold section. This is by design, the splitter is conditioned on optimize_function_for_speed. Nevertheless, I'm cleaning a bit float_extend and float_truncate splitter/peephole2 pattern and will submit the patch soon.
[Bug target/70902] [7 Regression] GCC freezes while compiling for 'skylake-avx512' target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902 Kirill Yukhin changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org, ||ubizjak at gmail dot com --- Comment #2 from Kirill Yukhin --- Started from Uros's r235523.
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r217349.
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941 --- Comment #2 from Jakub Jelinek --- I'd say this is already wrong in the original dump, the narrowing is done wrongly: *.original has: a = (char) (((unsigned char) -((signed char) (d != 0 && c != 0) ^ -128(OVF)) - (unsigned char) b) + 19); The (OVF) looks fishy and especially the negation performed in signed char instead of unsigned. So we then have in signed char types: _1 = _2 ^ -128; _3 = -_1; and VRP figures out that for valid program that is only possible if _2 is non-zero (i.e. if d and c are both non-zero). But ((d && c) ^ 2040097152) is in the source subtracted in int type rather than signed char due to promotion, so we need to use unsigned char arithmetics if we want to narrow it.
[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085 --- Comment #9 from Jonathan Wakely --- *** Bug 70898 has been marked as a duplicate of this bug. ***
[Bug libstdc++/70898] Stateful Compare objects are very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70898 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Jonathan Wakely --- Right, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085#c5 It's a dup. There's no point making two very similar changes to address very slightly different things. *** This bug has been marked as a duplicate of bug 67085 ***
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941 --- Comment #3 from Richard Biener --- 4.9 has (void) (a = (char) ((-(unsigned char) b - (unsigned char) ((signed char) ((signed char) d != 0 && (signed char) c != 0) ^ -128)) + 19)) >; if ((signed char) a != -109)
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 Ever confirmed|0 |1
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941 --- Comment #4 from Jakub Jelinek --- That looks fine indeed. The r217348 to r217349 *.original diff is similar (there is already the (OVF), but that is probably not it, after all we strip OVF flag away during gimplification: - a = (char) ((-(unsigned char) b - (unsigned char) ((signed char) ((signed char) d != 0 && (signed char) c != 0) ^ -128(OVF))) + 19); + a = (char) (((unsigned char) -((signed char) ((signed char) d != 0 && (signed char) c != 0) ^ -128(OVF)) - (unsigned char) b) + 19);
[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70893 --- Comment #7 from Jonathan Wakely --- (In reply to Кирилл from comment #5) > It makes no sense, because you can explicitly specify little_endian in the > template parameters, but not big_endian. And the standard says that parameter is ignored for codecvt_utf8 and codecvt_utf8_utf16. But as I said, the spec is a mess. Clang's libc++ gives exactly the same result for your testcase as libstdc++ does, so its authors interpreted the spec the same way I did.
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Component|middle-end |fortran
Target Milestone|--- |7.0
Summary|[7.0 Regression] ICE: tree |[7 Regression] ICE: tree
|code ‘ssa_name’ is not |code ‘ssa_name’ is not
|supported in LTO streams|supported in LTO streams
--- Comment #2 from Richard Biener ---
This is fallout of gimplify-into-SSA and another case where SAVE_EXPRs inside
type sizes are corrupted. I fixed one testsuite occurance with
2016-05-02 Richard Biener
* trans-array.c (gfc_trans_create_temp_array): Properly
create a DECL_EXPR for the anonymous VLA array type.
but suspected more places need fixing. The affected type is constructed via
#0 0x009291a3 in gfc_get_character_type_len_for_eltype (
eltype=,
len=)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-types.c:1026
#1 0x00929214 in gfc_get_character_type_len (kind=1,
len=)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-types.c:1036
#2 0x009292d8 in gfc_get_character_type (kind=1, cl=0x26c9420)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-types.c:1051
#3 0x009293d5 in gfc_typenode_for_spec (spec=0x26c8040)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-types.c:1095
#4 0x008a78b6 in gfc_build_dummy_array_decl (sym=0x26c8020,
dummy=)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-decl.c:1106
#5 0x008a8dad in gfc_get_symbol_decl (sym=0x26c8020)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-decl.c:1471
#6 0x008b6e4d in generate_local_decl (sym=0x26c8020)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-decl.c:5220
#7 0x0085fd94 in do_traverse_symtree (st=0x26c77b0, st_func=0x0,
sym_func=0x8b6d89 )
at /space/rguenther/src/svn/trunk/gcc/fortran/symbol.c:3817
and it needs to be handled similarly. Possibly somewhere here:
#4 0x008a78b6 in gfc_build_dummy_array_decl (sym=0x26c8020,
dummy=)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-decl.c:1106
1106 : gfc_typenode_for_spec (&sym->ts);
(gdb) l
1101}
1102
1103 /* For classarrays the element type is required, but
1104 gfc_typenode_for_spec () returns the array descriptor. */
1105 type = is_classarray ? gfc_get_element_type (type)
1106 : gfc_typenode_for_spec (&sym->ts);
1107 type = gfc_get_nodesc_array_type (type, as, packed,
1108!sym->attr.target);
or here:
#5 0x008a8dad in gfc_get_symbol_decl (sym=0x26c8020)
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-decl.c:1471
1471 decl = gfc_build_dummy_array_decl (sym, sym->backend_decl);
(gdb) l
1466
1467 /* Use a copy of the descriptor for dummy arrays. */
1468 if ((sym->attr.dimension || sym->attr.codimension)
1469 && !TREE_USED (sym->backend_decl))
1470{
1471 decl = gfc_build_dummy_array_decl (sym, sym->backend_decl);
1472 /* Prevent the dummy from being detected as unused if it is
copied. */
1473 if (sym->backend_decl != NULL && decl != sym->backend_decl)
1474DECL_ARTIFICIAL (sym->backend_decl) = 1;
1475 sym->backend_decl = decl;
[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||ienkovich at gcc dot gnu.org
[Bug c++/70939] creating object of abstract class allowed in all versions of g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70939 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 Ever confirmed|0 |1 Severity|major |normal
[Bug fortran/70931] [4.9/5/6/7 Regression] ICE with -g in native_encode_initializer, bei dwarf2out.c:17768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70931 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4 --- Comment #3 from Richard Biener --- I think this is a corner-case of native_encode_initializer not handling zero-sized FIELD_DECLs. Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 235859) +++ gcc/dwarf2out.c (working copy) @@ -17806,7 +17806,7 @@ native_encode_initializer (tree init, un fieldsize = tree_to_shwi (DECL_SIZE_UNIT (field)); pos = int_byte_position (field); gcc_assert (pos + fieldsize <= size); - if (val + if (val && fieldsize != 0 && !native_encode_initializer (val, array + pos, fieldsize)) return false; } fixes it.
[Bug lto/70929] [4.9/5/6/7 regression] Cross-module inlining for functions having argument passed by reference is no longer working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929 --- Comment #2 from Richard Biener --- Looks reasonable if it can get some baking time on trunk.
[Bug fortran/70931] [4.9/5/6/7 Regression] ICE with -g in native_encode_initializer, bei dwarf2out.c:17768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70931 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Mine.
[Bug rtl-optimization/70902] [7 Regression] GCC freezes while compiling for 'skylake-avx512' target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902 Uroš Bizjak changed: What|Removed |Added Component|target |rtl-optimization --- Comment #3 from Uroš Bizjak --- (In reply to Kirill Yukhin from comment #2) > Started from Uros's r235523. This is kind of expected, the referred commit enabled SSE spills for the first time, and apparently triggers some problems in LRA.
[Bug c++/70942] New: [c++14] Incorrect deduction of generic lambda `auto&&` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
Bug ID: 70942
Summary: [c++14] Incorrect deduction of generic lambda `auto&&`
parameter
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Created attachment 38410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38410&action=edit
Minimal code example
g++ 6.1 was recently introduced into Arch Linux's testing repositories, and
some of my code that successfully compiled with g++ 5.3.0 does not compile
anymore. I've made a minimal example:
gcc.godbolt.org link:
https://godbolt.org/g/73RTHf
// This code compiles with g++ 5.3.0
// This does not compile with g++ 6.1
#include
#include
#include
#define FWD(...) ::std::forward(__VA_ARGS__)
struct sinker
{
template
void sink(T&)
{
}
};
template
void caller(T& v, TF&& f)
{
sinker s;
f(s, v);
}
template
void interface(T& v)
{
return caller(v, [](auto& xs, auto&& xv) -> decltype(auto)
{
xs.sink(FWD(xv));
});
}
int main()
{
int x = 0;
interface(x);
}
This is the reported error:
: In instantiation of ‘get_impl(T&):: [with
auto:1 = sinker; auto:2 = int; T = int]’:
:25:58: required by substitution of ‘template
get_impl(T&)
[with T = int]operator
decltype (((get_impl(T&) [with T = int]::)0u).operator()(static_cast(),
static_cast())) (*)(auto:1&, auto:2&&)() const
[with auto:1 = sinker; auto:2 = int]’
:19:6: required from ‘void chunk_fn_impl(T&, TF&&) [with T = int; TF =
get_impl(T&) [with T = int]::]’
:25:25: required from ‘void get_impl(T&) [with T = int]’
:36:15: required from here
:27:13: error: invalid initialization of non-const reference of type ‘int&’
from an rvalue of type ‘int’
xs.sink(FWD(md));
^~
:10:10: note: initializing argument 1 of ‘void sinker::sink(T&) [with T =
int]’
void sink(T&)
^~~~
---
Changing:
return caller(v, [](auto& xs, auto&& xv) -> decltype(auto)
to:
return caller(v, [](auto& xs, auto& xv) -> decltype(auto)
allows the code to successfully compile.
---
I do not understand why this error is happening, as `xv` is being
perfectly-forwarded and the `FWD(xv)` call should produce a lvalue reference.
Note that the code worked as intended in g++ 5.3.0 and clang++ 3.7.
gcc.godbolt.org link:
https://godbolt.org/g/73RTHf
Try compiling with multiple g++ versions and changing `auto&&` to `auto&`.
Is this a g++ 6.1 bug? Or was the code incorrectly compiling with previous
versions of g++ and clang++?
---
More information:
http://stackoverflow.com/questions/37023265
[Bug c++/70824] cc1plus consumes all available memory on specific template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70824
--- Comment #1 from Truls Johnsen ---
Reduced the test case to only include and changed max to a
one-liner that still shows the same behavior. Removing constexpr from max, or
the (unused) template from a() makes the code compile:
#include
constexpr
int
max(std::initializer_list __l)
{ return *__l.begin(); }
template
void
a() {
const int v = max({1});
}
I forgot to mention the host in the initial report:
Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz
[Bug c++/70824] cc1plus consumes all available memory on specific template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70824 Truls Johnsen changed: What|Removed |Added Attachment #38348|0 |1 is obsolete|| --- Comment #2 from Truls Johnsen --- Created attachment 38411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38411&action=edit Preprocessed source for test case only including
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 --- Comment #1 from Jonathan Wakely --- Also: __null_memory_resource::do_is_equal() is missing a return statement, so returns garbage off the stack. __null_memory_resource doesn't need to be a class template. new_delete_resource() returns something that: - doesn't have the required is_equal() behaviour. - only uses new/delete if std::allocator uses __gnu_cxx::new_allocator. And another one from Eric: Your new_delete_resource() also unnecessarily pads the allocation size before invoking ::operator new, but that isn't a real bug.
[Bug c++/70942] [c++14] Incorrect deduction of generic lambda `auto&&` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
Reduced:
int main()
{
int x = 0;
[](auto&& xv){
static_cast(xv) = 1;
}(x);
}
OK on GCC 5. Fails with a bogus error on 6 and 7:
main.cpp: In instantiation of 'main():: [with auto:1 = int]':
main.cpp:5:17: required by substitution of 'template
main()operator decltype
(((main()::)0u).operator()(static_cast()))
(*)(auto:1&&)() const [with auto:1 = int]'
main.cpp:7:8: required from here
main.cpp:6:39: error: using xvalue (rvalue reference) as lvalue
static_cast(xv) = 1;
~~^~~
[Bug c++/70942] [c++14] Incorrect deduction of generic lambda `auto&&` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 Ever confirmed|0 |1 Severity|critical|normal
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941 --- Comment #6 from Richard Biener --- The negation issue is a latent fold-const.c issue which when folding (19 - (unsigned char) b) + (unsigned char) ((signed char) (d != 0 && c != 0) ^ -128(OVF)) runs into the associate: case. We partially fixed this for an ICE with 2016-02-01 Bin Cheng PR tree-optimization/67921 * fold-const.c (split_tree): New parameters. Convert pointer type variable part to proper type before negating. (fold_binary_loc): Pass new arguments to split_tree. but appearantly the "real" fix never materialized.
[Bug target/70941] [5/6/7 Regression] Test miscompiled with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
--- Comment #7 from Richard Biener ---
The following fixes this.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 235859)
+++ gcc/fold-const.c(working copy)
@@ -838,9 +838,8 @@ split_tree (location_t loc, tree in, tre
*conp = negate_expr (*conp);
if (neg_var_p)
{
- /* Convert to TYPE before negating a pointer type expr. */
- if (var && POINTER_TYPE_P (TREE_TYPE (var)))
- var = fold_convert_loc (loc, type, var);
+ /* Convert to TYPE before negating. */
+ var = fold_convert_loc (loc, type, var);
var = negate_expr (var);
}
}
@@ -863,9 +862,8 @@ split_tree (location_t loc, tree in, tre
else if (*minus_litp)
*litp = *minus_litp, *minus_litp = 0;
*conp = negate_expr (*conp);
- /* Convert to TYPE before negating a pointer type expr. */
- if (var && POINTER_TYPE_P (TREE_TYPE (var)))
- var = fold_convert_loc (loc, type, var);
+ /* Convert to TYPE before negating. */
+ var = fold_convert_loc (loc, type, var);
var = negate_expr (var);
}
[Bug c++/70943] New: 'conflicting declaration' error with repeated typedefs in function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70943
Bug ID: 70943
Summary: 'conflicting declaration' error with repeated typedefs
in function templates
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
void foo(T t) {
using meow = T;
using meow = int;
}
template void foo(int);
Accepted by clang, rejected by GCC:
main.cpp: In function 'void foo(T)':
main.cpp:4:21: error: conflicting declaration 'using meow = '
using meow = int;
^
main.cpp:3:19: note: previous declaration as 'using meow = T'
using meow = T;
[Bug tree-optimization/70944] New: [7 Regression] ICE in immed_wide_int_const, at emit-rtl.c:606 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70944
Bug ID: 70944
Summary: [7 Regression] ICE in immed_wide_int_const, at
emit-rtl.c:606 with -O3
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396#c5,
after Richi's fix for PR70396, I still see very similar issue.
$ cat tc.ii
void fn1() {
unsigned *a = 0;
for (int i; i; ++i) {
unsigned g(a[i] << 8 >> 24);
a[i] = g;
}
}
$ /home/marxin/bin/gcc2/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
-fpreprocessed tc.ii -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3
-mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2
-msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx -mno-clzero -mno-pku --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192
-mtune=haswell -quiet -dumpbase tc.ii -O3
tc.ii:7:1: internal compiler error: in immed_wide_int_const, at emit-rtl.c:606
}
^
0xa4cf35 immed_wide_int_const(generic_wide_int >
const&, machine_mode)
../../gcc/emit-rtl.c:606
0x13929a9 change_zero_ext
../../gcc/combine.c:1
0x13937d8 recog_for_combine
../../gcc/combine.c:11148
0x13a175d try_combine
../../gcc/combine.c:3503
0x13a6fc1 combine_instructions
../../gcc/combine.c:1288
0x13a6fc1 rest_of_handle_combine
../../gcc/combine.c:14348
0x13a6fc1 execute
../../gcc/combine.c:14391
Thanks
[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- See PR70944.
[Bug tree-optimization/70944] [7 Regression] ICE in immed_wide_int_const, at emit-rtl.c:606 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70944 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 Known to work||6.1.0 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed with -O3 -march=core-avx2
[Bug rtl-optimization/70944] [7 Regression] ICE in immed_wide_int_const, at emit-rtl.c:606 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70944
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I'd say we really don't want vector mode ZERO_EXTRACTs/SIGN_EXTRACTs, so
perhaps
make_extraction could give up in that case, maybe:
/* Never narrow an object, since that might not be safe. */
if (mode != VOIDmode
&& GET_MODE_SIZE (extraction_mode) < GET_MODE_SIZE (mode))
extraction_mode = mode;
and inside of if just do
{
/* Avoid vector mode extractions. */
if (VECTOR_MODE_P (mode))
return NULL_RTX;
extraction_mode = mode;
}
Or should we punt even earlier?
[Bug other/70945] New: Offloading: compatibility of target and offloading toolchains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945 Bug ID: 70945 Summary: Offloading: compatibility of target and offloading toolchains Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc, openmp Severity: enhancement Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- It has been established that for offloading compilation, the target and offloading toolchains need to be compatible (for example: data types; bit-wise copying of data). For OpenACC/OpenMP, offloading is implemented such that the target compiler already applies certains transformations to the source code before handing over to the offloading compilers an intermediate representation of the relevant pieces. Looking at one specific example: inclusion of under the presence of -ffinite-math-only (as implied by -ffast-math, or -Ofast). The (glibc) will then (__FINITE_MATH_ONLY__) include for "special entry points to use when the compiler got told to only expect finite results". In the configuration that I'm looking at right now, this works by diverting the math functions' assembler names from "[function]" to "__[function]_finite". This is a "bits/[...]" header file, that is applicable only to this one target's glibc configuration. For nvptx offloading, for example, we use newlib which doesn't provide these finite math entry points, so when using the "log" function in offloaded code, you'll see the compilation fail because of "unresolved symbol __log_finite". The problem basically is that there is a mis-match between early transformations done by the target compiler (such as via header files, or done early in the compiler internally), that are not actually valid for the offloading compilers. Instead of playing "rat race", trying to make the target and offloading toolchains/compilers/ABIs match completely (which probably isn't even possible in the general case), can we maybe find a better solution? Of course, this problem is applicable only if we agree that it is valid to use such functions in offlodead regions, which indeed is debatable for a lot of standard library functions, but for math functions clearly users expect to be allowed to use them. Also consider Fortran, where such functions are actually part of the language.
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu --- I saw similar error with 465.tonto and 481.wrf from SPEC CPU 2006.
[Bug rtl-optimization/70946] New: Bad interaction between IVOpt and loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70946
Bug ID: 70946
Summary: Bad interaction between IVOpt and loop unrolling
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
IVOpt chooses between using indexing for induction variables or incrementing
pointers. Due to way loop unrolling works, a decision that is optimal if
unrolling is disabled may become very non-optimal with unrolling.
Below are simple examples that show how the choice to use indexing can become a
very bad idea when unrolled, while using offset addressing leads to very decent
code. To improve this we either to teach IVOpt about unrolling (eg. prioritise
base+offset addressing) or add a tree unroller that unrolls small inner loops
before IVOpt.
void loop1 (int *p, int *q, int i)
{
for (i = 0; i < 1000; i++) p[i] = q[i] + 1;
}
void loop2 (int *p, int i)
{
for (i = 0; i < 1000; i++) p[i] = p[i] + 1;
}
On AArch64 with -O2 -funroll-loops this gives:
loop1:
mov x2, 0
.p2align 2
.L41:
ldr w4, [x1, x2]
add x3, x2, 4
add x10, x2, 8
add x9, x2, 12
add w5, w4, 1
str w5, [x0, x2]
add x8, x2, 16
add x7, x2, 20
add x6, x2, 24
add x11, x2, 28
ldr w12, [x1, x3]
add x2, x2, 32
cmp x2, 4000
add w13, w12, 1
str w13, [x0, x3]
ldr w14, [x1, x10]
add w15, w14, 1
str w15, [x0, x10]
ldr w16, [x1, x9]
add w17, w16, 1
str w17, [x0, x9]
ldr w18, [x1, x8]
add w4, w18, 1
str w4, [x0, x8]
ldr w3, [x1, x7]
add w10, w3, 1
str w10, [x0, x7]
ldr w9, [x1, x6]
add w5, w9, 1
str w5, [x0, x6]
ldr w8, [x1, x11]
add w7, w8, 1
str w7, [x0, x11]
bne .L41
ret
loop2:
add x6, x0, 4000
.p2align 2
.L51:
mov x1, x0
ldr w2, [x0]
add x0, x0, 32
add w3, w2, 1
cmp x0, x6
str w3, [x1], 4
ldr w4, [x0, -28]
add w5, w4, 1
str w5, [x0, -28]
ldr w7, [x1, 4]
add w8, w7, 1
str w8, [x1, 4]
ldp w9, w10, [x0, -20]
ldp w11, w12, [x0, -12]
add w14, w9, 1
ldr w13, [x0, -4]
add w15, w10, 1
add w16, w11, 1
add w17, w12, 1
add w18, w13, 1
stp w14, w15, [x0, -20]
stp w16, w17, [x0, -12]
str w18, [x0, -4]
bne .L51
ret
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Wed May 4 12:08:45 2016 New Revision: 235868 URL: https://gcc.gnu.org/viewcvs?rev=235868&root=gcc&view=rev Log: libstdc++/70940 Start fixing polymorphic memory resources PR libstdc++/70940 * include/experimental/memory_resource (__resource_adaptor_imp::do_allocate): Do not default-construct rebound allocator. (__resource_adaptor_imp::do_deallocate): Likewise. Use allocator_traits to get pointer type. (__null_memory_resource::do_allocate): Remove unused parameters. (__null_memory_resource::do_deallocate): Likewise. (__null_memory_resource::do_is_equal): Likewise. Add return statement. * testsuite/experimental/type_erased_allocator/1.cc: Combine with ... * testsuite/experimental/type_erased_allocator/1_neg.cc: This, and move to ... * testsuite/experimental/memory_resource/1.cc: Here. * testsuite/experimental/memory_resource/null_memory_resource.cc: New. * testsuite/experimental/memory_resource/resource_adaptor.cc: New. Added: trunk/libstdc++-v3/testsuite/experimental/memory_resource/ trunk/libstdc++-v3/testsuite/experimental/memory_resource/1.cc - copied, changed from r235859, trunk/libstdc++-v3/testsuite/experimental/type_erased_allocator/1.cc trunk/libstdc++-v3/testsuite/experimental/memory_resource/null_memory_resource.cc - copied, changed from r235859, trunk/libstdc++-v3/testsuite/experimental/type_erased_allocator/1_neg.cc trunk/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc Removed: trunk/libstdc++-v3/testsuite/experimental/type_erased_allocator/1.cc trunk/libstdc++-v3/testsuite/experimental/type_erased_allocator/1_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/memory_resource
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |6.2 --- Comment #3 from Jonathan Wakely --- (In reply to Eric Fiselier from comment #0) > resource_adapter incorrectly requires that the Allocator provide: > * A pointer typedef. > * A default constructor. Those errors are fixed on trunk now. (In reply to Jonathan Wakely from comment #1) > Also: > > __null_memory_resource::do_is_equal() is missing a return statement, so > returns garbage off the stack. So is this. The rest isn't yet.
[Bug rtl-optimization/70946] Bad interaction between IVOpt and loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70946 --- Comment #1 from Wilco --- PR36712 seems related to this
[Bug target/70947] New: regrename Go breakage on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70947 Bug ID: 70947 Summary: regrename Go breakage on powerpc64 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- Instructions around a __morestack call typically have r0, used to save and restore lr, replaced with other regs by regrename. This trashes the current function parameter and return regs. => 0x10001550 <+112>: mflrr3 # argc trashed 0x10001554 <+116>: std r3,16(r1) 0x10001558 <+120>: bl 0x10001818 <__morestack> 0x1000155c <+124>: ld r4,16(r1) 0x10001560 <+128>: mtlrr4 0x10001564 <+132>: blr 0x10001568 <+136>: b 0x100014fc
[Bug target/70947] regrename Go breakage on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70947 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-04 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #4 from Richard Biener ---
The following patch fixes the testcase (otherwise untested). Maybe the first
fix can be absorbed into this as well. I'll have some time on friday to
continue investigating how the fortran FE works but eventually fortran people
can lend me a hand here given the following hint.
(a little testing shows the assert triggers, needs investigation)
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 235859)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -6012,6 +6012,22 @@ finish_oacc_declare (gfc_namespace *ns,
return;
}
+static stmtblock_t *place_decl_expr_init;
+static void
+place_decl_expr (gfc_symbol *sym)
+{
+ if (sym->backend_decl
+ && variably_modified_type_p (TREE_TYPE (sym->backend_decl), NULL))
+{
+ tree type = TREE_TYPE (sym->backend_decl);
+ while (POINTER_TYPE_P (type))
+ type = TREE_TYPE (type);
+ gcc_assert (TYPE_NAME (type));
+ gfc_add_expr_to_block (place_decl_expr_init,
+build1 (DECL_EXPR, type, TYPE_NAME (type)));
+}
+}
+
/* Generate code for a function. */
@@ -6088,6 +6104,9 @@ gfc_generate_function_code (gfc_namespac
has_coarray_vars = false;
generate_local_vars (ns);
+ place_decl_expr_init = &init;
+ gfc_traverse_ns (ns, place_decl_expr);
+
if (flag_coarray == GFC_FCOARRAY_LIB && has_coarray_vars)
generate_coarray_init (ns);
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #5 from Richard Biener ---
Ok, ->backend_decl isn't always a decl. Thus sth like the following (I suppose
the check should be done in fortran terms rather than looking at backend_decl)
static void
place_decl_expr (gfc_symbol *sym)
{
if (sym->backend_decl)
{
tree type = sym->backend_decl;
if (DECL_P (sym->backend_decl))
type = TREE_TYPE (type);
else
gcc_assert (TYPE_P (type));
while (POINTER_TYPE_P (type))
type = TREE_TYPE (type);
if (variably_modified_type_p (type, NULL))
{
if (TYPE_NAME (type))
gfc_add_expr_to_block (place_decl_expr_init,
build1 (DECL_EXPR, type, TYPE_NAME (type)));
}
}
}
[Bug rtl-optimization/70946] Bad interaction between IVOpt and loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70946 --- Comment #2 from Richard Biener --- IVO before unrolling is never going to be optimal.
[Bug middle-end/70807] fwprop pass ICE with incoming CDI_DOMINATORS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807 Ilya Enkovich changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org --- Comment #3 from Ilya Enkovich --- I see CSE invalidates dominance info via delete_insn_and_edges and doesn't fix or free it.
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937 --- Comment #6 from Dominique d'Humieres --- Started at r235817. Which patch should I test?
[Bug tree-optimization/70948] New: [7 Regression] r235622 caused gcc.c-torture/execute/va-arg-pack-1.c execution failure AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70948 Bug ID: 70948 Summary: [7 Regression] r235622 caused gcc.c-torture/execute/va-arg-pack-1.c execution failure AArch64 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jiwang at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: aarch64* Noticed the following regression on aarch64 after r235622 2016-04-29 Richard Biener PR tree-optimization/13962 PR tree-optimization/65686 * tree-ssa-alias.h (ptrs_compare_unequal): Declare. * tree-ssa-alias.c (ptrs_compare_unequal): New function using PTA to compare pointers. * match.pd: Add pattern for pointer equality compare simplification using ptrs_compare_unequal. make check RUNTESTFLAGS="execute.exp=va-arg-pack-1.c" FAIL: gcc.c-torture/execute/va-arg-pack-1.c -O2 execution test FAIL: gcc.c-torture/execute/va-arg-pack-1.c -O3 -g execution test FAIL: gcc.c-torture/execute/va-arg-pack-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/va-arg-pack-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
[Bug other/70945] Offloading: compatibility of target and offloading toolchains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- I don't think there's a reasonable way to "solve" this apart from saying that complete ABI compatibility is required, and enumerating rare exceptions where it's not. Like you say, storage layout must be the same: size/align of all types must match (note this isn't true today for 'long double' and it's not even diagnosed), but also endianness, signedness of 'char'. Layout of _Complex types. Layout of structs that library functions operate on (e.g. div_t). As an exception, va_list type need not match, because data of this type is not usable on both host and accel sides. Typedefs must match, even if underlying types happen to be binary compatible (e.g. C++ mangled name of '::operator new' differs based on whether size_t is 'unsigned' or 'unsigned long'). Basically I'd say that host compilation environment establishes an ABI baseline that the accel environment must follow. In your finite-math example, the problem exists due to an ABI extension in Glibc (note that the custom name could equally happen to be __glibc_log_finite). You'd see the same issue trying to run a new binary on old Glibc systems that didn't have that symbol yet, and now Glibc itself is bound to carry that entrypoint forever. And note that the issue is not limited to math symbols either: with -D_FORTIFY_SOURCE, plain 'printf' may become '__printf_chk', which would also fail to link on Newlib. Is there any actual issue with Fortran functions? As I understand, they are provided by libgfortran, so ABI incompatibilities due to source-level differences, like in Glibc-vs-Newlib above, don't exist. If there are ABI issues due to other reasons, it should be reasonable to just fix those.
[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #22 from Uroš Bizjak --- Created attachment 38412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38412&action=edit Proposed patch This patch moves all TARGET_SSE_PARTIAL_REG_DEPENDENCY FP conversion splitters to a later split pass. Plus, the patch substantially cleans these and related patterns. The functionality of post-reload conversion splitters goes this way: - process FP conversions for TARGET_USE_VECTOR_FP_CONVERTS in an early post-reload splitter. This pass will rewrite FP conversions to vector insns and is thus incompatible with the next two passes. AMDFAM10 processors depend on this transformation. - process FP conversions for TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS in a peephole2 pass. This will transform mem->reg insns to reg->reg insns, and these insn could be processed by the next pass. Some Intel processors depend on this transformation. - process FP conversions for TARGET_SSE_PARTIAL_REG_DEPENDENCY in a late post-reload splitter, when allocated registers are stable. AMD and Intel processors depend on this pass, so it is part of generic tuning.
[Bug c/48778] gcc 4.6 -Waddress adds unhelpful new warning case when using from a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Wed May 4 13:46:15 2016 New Revision: 235878 URL: https://gcc.gnu.org/viewcvs?rev=235878&root=gcc&view=rev Log: PR c/48778 * c-typeck.c (build_binary_op): Don't issue -Waddress warnings for macro expansions. * gcc.dg/Waddress-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Waddress-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/48778] gcc 4.6 -Waddress adds unhelpful new warning case when using from a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed, for some definition of "fixed".
[Bug tree-optimization/70804] Missed tail-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70804 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Alexander Monakov --- Closing as invalid per the previous comment.
[Bug c/70371] Number added worng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70371 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Marek Polacek --- .
[Bug c++/60027] Problem with braced-init-lists and explicit ctors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027 Ed Catmur changed: What|Removed |Added CC||ed at catmur dot co.uk --- Comment #1 from Ed Catmur --- This is correct. [over.match.list]: [...] In copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed. [ Note: This differs from other situations ([over.match.ctor], [over.match.copy]), where only converting constructors are considered for copy-initialization. This restriction only applies if this initialization is part of the final result of overload resolution. — end note ] See also: https://llvm.org/bugs/show_bug.cgi?id=27642 http://stackoverflow.com/questions/34622076/calling-an-explicit-constructor-with-a-braced-init-list-ambiguous-or-not?rq=1
[Bug target/68945] enable libcilkrts on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945 --- Comment #9 from Rainer Orth --- Created attachment 38413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38413&action=edit sparcv9 support patch This patch (on top of the previous one) fixes the sparcv9 failures reported before. As I'd suspected, the problem was that the code didn't take the SPARC V9 stack bias into account: in a couple of places, the stack and frame pointers in the __builtin_setjmp/__builtin_longjmp internal jmpbuf are overwritten with unbiased addresses. The patch includes both debugging code (assertions to check that the stack pointer is either biased or unbiased) and CILK_ADJUST_SP/CILK_UNADJUST_SP macros to turn a stack pointer from unbiased to biased form. The patch is enough to successfully run all Cilk Plus in the gcc and g++ testsuites successfully on sparc-sun-solaris2.10, but there may be code paths that also need adjustments. I'm just posting the patch (which is relative to upstream libcilkrts, which should be merged into mainline any day now) for reference and comments. Rainer
[Bug tree-optimization/70771] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Fixed?
[Bug c/70930] VLAs in stucts in loop headers are not evaluated each iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70930 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/70775] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70775 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Fixed?
[Bug c++/70938] internal compiler error: in tsubst_copy, at cp/pt.c:13008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70938 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-04 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Fixed in r234442 for GCC 6 and GCC 7.
[Bug tree-optimization/70771] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from amker at gcc dot gnu.org --- Yes, fixed.
[Bug sanitizer/70051] ubsan doesn't detect VLA overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70051 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Isn't this a dup of PR68065?
[Bug tree-optimization/70775] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70775 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from amker at gcc dot gnu.org --- Yes, fixed.
[Bug c++/70932] flexible array member with non-trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-05-04
Known to work||4.9.3, 5.3.0
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
Known to fail||6.1.0
--- Comment #1 from Martin Sebor ---
The problem was introduced r233126 as a result of switching the internal
flexible array representation to use a null type domain. Prior to 6.1, GCC
treated flexible array members the same as arrays of zero elements.
I'll have to think about what the right solution is: reject flexible array
members with non-trivial destructors with a better error (like clang does) or
allow them with a warning. My concern with allowing them is that while G++ 6.1
allows them to be initialized (5.x rejects the initialization which seems like
a bug), it won't be able to invoke their destructor in code like this:
struct A {
int i;
~A() { __builtin_printf ("%s\n", __PRETTY_FUNCTION__); }
};
struct S {
int i;
A a[];
};
int main ()
{
S s = { 3, { 1, 2, 3 } };
}
[Bug fortran/50410] [4.9/5/6/7 Regression] ICE in record_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #23 from Gerhard Steinmetz --- These variants give : $ cat z1.f90 program p type ta integer :: a end type type t type(ta), pointer :: b end type type(t) :: z data z / t(ta(1)) / end $ gfortran-6 z1.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64 $ cat z2.f90 program p type ta integer :: a end type type t type(ta) :: b end type type(t), pointer :: z data z / t(ta(1)) / end $ gfortran-6 z2.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64 $ cat z3.f90 program p type ta integer :: a end type type t type(ta), pointer :: b end type type(t), pointer :: z data z / t(ta(1)) / end $ gfortran-6 z3.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256
[Bug fortran/50410] [4.9/5/6/7 Regression] ICE in record_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #24 from Gerhard Steinmetz --- And an exotic case : $ cat z5.f90 module m real, target :: a[*] real, pointer :: z => a end $ gfortran-6 -fcoarray=lib -c z5.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64 $ cat z6.f90 program p real, target :: a[*] real, pointer :: z => a end $ gfortran-6 -fcoarray=lib -finit-local-zero -c z6.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256
[Bug sanitizer/70051] ubsan doesn't detect VLA overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70051 --- Comment #2 from Martin Sebor --- The bug here I believe is in how/where the C++ front end calls the sanitizer to detect the overflow. With PR69517 resolved by having the C++ front end throw an exception, this bug will become largely a non-issue (except with -fno-exceptions it will still need to be fixed), but PR68065 won't.
[Bug fortran/70949] ICE in propagate_necessity, at tree-ssa-dce.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 --- Comment #1 from Gerhard Steinmetz --- This variant works : (as known from several other PRs : change "class" to "type") $ cat z2.f90 program p type t1 end type type t2 type(t1), pointer :: q end type type(t1), pointer :: a type(t2) :: c allocate(a) c%q => a print *, 'a', associated(a, f(c)) contains function f(x) result (z) type(t2), intent(in) :: x type(t1), pointer :: z z => x%q end end
[Bug fortran/70949] New: ICE in propagate_necessity, at tree-ssa-dce.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 Bug ID: 70949 Summary: ICE in propagate_necessity, at tree-ssa-dce.c:924 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Compiling with optimization level -Og, -Os, -O1 or higher : (affects older gfortran versions too) $ cat z1.f90 program p type t1 end type type t2 type(t1), pointer :: q end type type(t1), pointer :: a type(t2) :: c allocate(a) c%q => a print *, 'a', associated(a, f(c)) contains function f(x) result (z) type(t2), intent(in) :: x class(t1), pointer :: z z => x%q end end $ gfortran-6 -O2 z1.f90 z1.f90:12:0: print *, 'a', associated(a, f(c)) internal compiler error: in propagate_necessity, at tree-ssa-dce.c:924
[Bug tree-optimization/70876] ICE in chkp_find_bounds: Unexpected tree code with_size_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-04 Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/70950] New: ICE with -O0 in simplify_subreg, at simplify-rtx.c:5895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70950 Bug ID: 70950 Summary: ICE with -O0 in simplify_subreg, at simplify-rtx.c:5895 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This error message is generated with optimization level -O0 : (affects older gfortran versions too) $ cat z1.f90 program p type t1 end type type t2 type(t1), pointer :: q => null() end type type(t1), pointer :: a, b type(t2) :: c allocate(a) call s(a, c) print *, 'a', associated(a, f(c)) b => f(c) print *, 'b', associated(a, b) contains subroutine s(x, y) type(t1), pointer :: x type(t2), intent(out) :: y y%q => x end function f(x) result (z) type(t2), intent(in) :: x class(t1), pointer :: z z => x%q end end $ gfortran-6 -O0 z1.f90 z1.f90:12:0: print *, 'a', associated(a, f(c)) internal compiler error: in simplify_subreg, at simplify-rtx.c:5895
[Bug middle-end/70877] [MPX] ICE in in convert_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-04 Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/70950] ICE with -O0 in simplify_subreg, at simplify-rtx.c:5895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70950 --- Comment #1 from Gerhard Steinmetz --- Please note : both examples from pr70949 are simplifications of this PR, thus related. Behaviour differs for -O0 (with/without ICE). Compiling the example from above with optimization level -Og, -Os, -O1 or higher shows the same ICE as in PR70949 comment 0. In total, pr70949 is more or less a subcase. Code compiles and works if "class" is changed to "type" : $ cat z2.f90 program p type t1 end type type t2 type(t1), pointer :: q => null() end type type(t1), pointer :: a, b type(t2) :: c allocate(a) call s(a, c) print *, 'a', associated(a, f(c)) b => f(c) print *, 'b', associated(a, b) contains subroutine s(x, y) type(t1), pointer :: x type(t2), intent(out) :: y y%q => x end function f(x) result (z) type(t2), intent(in) :: x type(t1), pointer :: z z => x%q end end $ gfortran-6 -O0 -g z2.f90 $ a.out a T b T
[Bug target/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #23 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #22)
> Created attachment 38412 [details]
> Proposed patch
>
> This patch moves all TARGET_SSE_PARTIAL_REG_DEPENDENCY FP conversion
> splitters to a later split pass. Plus, the patch substantially cleans these
> and related patterns.
>
> The functionality of post-reload conversion splitters goes this way:
>
> - process FP conversions for TARGET_USE_VECTOR_FP_CONVERTS in an early
> post-reload splitter. This pass will rewrite FP conversions to vector insns
> and is thus incompatible with the next two passes. AMDFAM10 processors
> depend on this transformation.
>
> - process FP conversions for TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS in a
> peephole2 pass. This will transform mem->reg insns to reg->reg insns, and
> these insn could be processed by the next pass. Some Intel processors depend
> on this transformation.
>
> - process FP conversions for TARGET_SSE_PARTIAL_REG_DEPENDENCY in a late
> post-reload splitter, when allocated registers are stable. AMD and Intel
> processors depend on this pass, so it is part of generic tuning.
We need to move those special SSE SF->DF splitters before
(define_split
[(set (match_operand 0 "any_fp_register_operand")
(float_extend (match_operand 1 "memory_operand")))]
"reload_completed
&& (GET_MODE (operands[0]) == TFmode
|| GET_MODE (operands[0]) == XFmode
|| GET_MODE (operands[0]) == DFmode)"
[(set (match_dup 0) (match_dup 2))]
{
operands[2] = find_constant_src (curr_insn);
if (operands[2] == NULL_RTX
|| (SSE_REGNO_P (REGNO (operands[0]))
&& standard_sse_constant_p (operands[2],
GET_MODE (operands[0])) != 1)
|| (STACK_REGNO_P (REGNO (operands[0]))
&& standard_80387_constant_p (operands[2]) < 1))
FAIL;
})
Otherwise, they may not be used on memory operand since the general
SSE (In reply to Uroš Bizjak from comment #22)
> Created attachment 38412 [details]
> Proposed patch
>
> This patch moves all TARGET_SSE_PARTIAL_REG_DEPENDENCY FP conversion
> splitters to a later split pass. Plus, the patch substantially cleans these
> and related patterns.
>
> The functionality of post-reload conversion splitters goes this way:
>
> - process FP conversions for TARGET_USE_VECTOR_FP_CONVERTS in an early
> post-reload splitter. This pass will rewrite FP conversions to vector insns
> and is thus incompatible with the next two passes. AMDFAM10 processors
> depend on this transformation.
>
> - process FP conversions for TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS in a
> peephole2 pass. This will transform mem->reg insns to reg->reg insns, and
> these insn could be processed by the next pass. Some Intel processors depend
> on this transformation.
>
> - process FP conversions for TARGET_SSE_PARTIAL_REG_DEPENDENCY in a late
> post-reload splitter, when allocated registers are stable. AMD and Intel
> processors depend on this pass, so it is part of generic tuning.
We need to move those special SSE SF->DF splitters before
(define_split
[(set (match_operand 0 "any_fp_register_operand")
(float_extend (match_operand 1 "memory_operand")))]
"reload_completed
&& (GET_MODE (operands[0]) == TFmode
|| GET_MODE (operands[0]) == XFmode
|| GET_MODE (operands[0]) == DFmode)"
[(set (match_dup 0) (match_dup 2))]
{
operands[2] = find_constant_src (curr_insn);
if (operands[2] == NULL_RTX
|| (SSE_REGNO_P (REGNO (operands[0]))
&& standard_sse_constant_p (operands[2],
GET_MODE (operands[0])) != 1)
|| (STACK_REGNO_P (REGNO (operands[0]))
&& standard_80387_constant_p (operands[2]) < 1))
FAIL;
})
Otherwise, they may not be used on memory operand since the general
SSE float_extend splitter on memory operand will be used.
[Bug target/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873 --- Comment #24 from H.J. Lu --- Created attachment 38414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38414&action=edit A patch to move special SSE splitters before general SSE float_extend splitter
[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #3 from Yuri Rumyantsev ---
Jacub,
Here is a simple fix - do not take into consideration edges destination of
which is loop latch block, i.e. loop is endless:
diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c
index dd6fd01..7de5fba 100644
--- a/gcc/tree-ssa-loop-unswitch.c
+++ b/gcc/tree-ssa-loop-unswitch.c
@@ -532,6 +532,12 @@ find_loop_guard (struct loop *loop)
guard_edge->src->index, guard_edge->dest->index);
return NULL;
}
+ if (guard_edge->dest == loop->latch)
+{
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf(dump_file,"Guard edge destination is loop latch!\n");
+ return NULL;
+}
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
Is it OK for you?
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #7 from Dominique d'Humieres ---
The ICEs are gone with the patch
--- ../_clean/gcc/fortran/trans-decl.c 2016-03-28 13:03:29.0 +0200
+++ ../p_work/gcc/fortran/trans-decl.c 2016-05-04 16:13:21.0 +0200
@@ -6013,6 +6013,29 @@ finish_oacc_declare (gfc_namespace *ns,
}
+static stmtblock_t *place_decl_expr_init;
+static void
+place_decl_expr (gfc_symbol *sym)
+{
+ if (sym->backend_decl)
+{
+ tree type = sym->backend_decl;
+ if (DECL_P (sym->backend_decl))
+type = TREE_TYPE (type);
+ else
+gcc_assert (TYPE_P (type));
+ while (POINTER_TYPE_P (type))
+type = TREE_TYPE (type);
+ if (variably_modified_type_p (type, NULL))
+{
+ if (TYPE_NAME (type))
+gfc_add_expr_to_block (place_decl_expr_init,
+ build1 (DECL_EXPR, type, TYPE_NAME
(type)));
+}
+}
+}
+
+
/* Generate code for a function. */
void
@@ -6088,6 +6111,9 @@ gfc_generate_function_code (gfc_namespac
has_coarray_vars = false;
generate_local_vars (ns);
+ place_decl_expr_init = &init;
+ gfc_traverse_ns (ns, place_decl_expr);
+
if (flag_coarray == GFC_FCOARRAY_LIB && has_coarray_vars)
generate_coarray_init (ns);
However, I see several execution failures:
FAIL: gfortran.dg/array_constructor_type_7.f03 -Oxx execution test where xx
depends on -m32/-m64
FAIL: gfortran.dg/auto_char_dummy_array_1.f90 -O* execution test
FAIL: gfortran.dg/namelist_70.f90 -O* execution test
FAIL: gfortran.dg/string_ctor_1.f90 -Oxx execution test where xx depends on
-m32/-m64
FAIL: libgomp.fortran/task2.f90 -O execution test
FAIL: libgomp.fortran/vla*.f90 -O* execution test
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #6 from Eric Gallager --- (In reply to Andreas Schwab from comment #5) > A cast is seldom a good solution Well, that's the sort of solution this warning causes inexperienced programmers who don't know any better (such as myself) to use... Maybe now that GCC has fixits, it could suggest something better?
[Bug c++/70951] New: misleading -Wignored-qualifiers text, incorrect documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70951
Bug ID: 70951
Summary: misleading -Wignored-qualifiers text, incorrect
documentation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following C/C++ program elicits warnings in either language mode. The
warning is expected, but the phrasing of the text isn't entirely correct
because, as the program shows, qualifiers on function return types can be
deduced in both languages and so are not ignored. I think this can be easily
corrected by tweaking the text of the warning to avoid giving the impression
that the qualifiers are not part of the type.
In addition, the documentation for the option states:
Warn if the return type of a function has a type qualifier such as const. For
ISO C such a type qualifier has no effect, since the value returned by a
function is not an lvalue. For C++, the warning is only emitted for scalar
types or void.
I noticed two problems with the documentation:
First, as the C example program shows, a type qualifier on a function return
type does have an effect even in C. The description should be expanded to make
it clear that the qualifier has no effect on the returned value but that it
does affect the type of the function.
Second, as the C++ example shows, G++ emits the warning also for enumerations
in addition to scalar types. Either the C++ description should be corrected to
mention that the warning is issued for enumerations as well, or the
implementation fixed to match the documentation.
$ (set -x; cat xx.c && gcc -Wall -Wextra -xc xx.c && gcc -Wall -Wextra -xc++
xx.c)
+ cat xx.c
enum E { e };
typedef const enum E T;
T foo (void) { return (T)0; }
#if __cplusplus
template
void f (T);
int main () { f (foo); }
#else
typedef T (*tf)(void);
typedef enum E (*ef)(void);
_Static_assert (1 == _Generic (foo, tf: 1, ef: 0), "");
#endif
+ gcc -S -Wall -Wextra -xc xx.c
xx.c:4:3: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
T foo (void) { return (T)0; }
^~~
xx.c:15:13: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
typedef T (*tf)(void);
^~
+ gcc -Wall -Wextra -xc++ xx.c
xx.c:4:12: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
T foo (void) { return (T)0; }
^
/tmp/cccrycoh.o: In function `main':
xx.c:(.text+0x15): undefined reference to `void f(E const
(*)())'
collect2: error: ld returned 1 exit status
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #15 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #6) > Fixing this is even more unlikely than fixing PR 23608, since the latter > only asks for constant propagation, but this one requires value range > propagation. That has since been closed as fixed. So are the chances of this one being fixed next somewhat better now?
[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #4 from Jakub Jelinek ---
(In reply to Yuri Rumyantsev from comment #3)
> Here is a simple fix - do not take into consideration edges destination of
> which is loop latch block, i.e. loop is endless:
> diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c
> index dd6fd01..7de5fba 100644
> --- a/gcc/tree-ssa-loop-unswitch.c
> +++ b/gcc/tree-ssa-loop-unswitch.c
> @@ -532,6 +532,12 @@ find_loop_guard (struct loop *loop)
> guard_edge->src->index, guard_edge->dest->index);
>return NULL;
> }
> + if (guard_edge->dest == loop->latch)
> +{
> + if (dump_file && (dump_flags & TDF_DETAILS))
> + fprintf(dump_file,"Guard edge destination is loop latch!\n");
Formatting - missing space before (.
> + return NULL;
> +}
>
>if (dump_file && (dump_flags & TDF_DETAILS))
> fprintf (dump_file,
>
> Is it OK for you?
Richard knows this code much better than I do, so I'll defer to him.
That said, is there any guarantee that for non-endless loop we won't run into
the debug stmt issue? For normal non-debug uses of something set inside of the
loop there would need to be a PHI on the exit block if it is reachable from
outside of the loop too, the question is if it is possible even in the
non-endless case that the exit block will be only reachable from within the
loop. If yes, even normal SSA_NAME uses, not just in debug stmts, could be a
problem.
[Bug ada/62042] Missing optimization of copying non-limited objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042 --- Comment #10 from Victor Porton --- Not fixed in GCC 6.1.1.
[Bug ada/62235] segmentation fault on Ada 2012 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235 --- Comment #8 from Victor Porton --- Note fixed in GCC 6.1.1.
[Bug ada/62236] : error: aggregate value used where an integer was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62236 --- Comment #7 from Victor Porton --- Not fixed in GCC 6.1.1.
[Bug c/70952] New: Missing warning for likely-erroneous octal escapes in string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952 Bug ID: 70952 Summary: Missing warning for likely-erroneous octal escapes in string literals Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- GCC doesn't warn for: const char s[] = "\008"; (just the two zeros following the backslash become a part of the octal literal, so the string literal is equivalent to "\0""8") \008 and \009 in string literals are most likely errors (\08 and \09 work just as well if a nil character followed by a digit was really intended) I think a bit of a bikeshed is possible on the point how far we want to take it (do we warn for "\08"? for "\799"?). I think warning when the octal escape with less than 3 digits is followed by [89] is desirable (this catches all of the above), but warning when octal escape already has 3 digits may be not (this exempts "\0009" from the warning).
[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #6 from Marek Polacek ---
This should fix it then:
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index d275f8e..d31e915 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -5532,7 +5532,7 @@ c_parser_if_statement (c_parser *parser, bool *if_p,
vec *chain)
/* Set IF_P to true to indicate that this if statement has an
else clause. This may trigger the Wparentheses warning
below when we get back up to the parent if statement. */
- if (if_p != NULL)
+ if (if_p != NULL && !from_macro_expansion_at (loc))
*if_p = true;
}
else
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index da2ee3c..f6b8008 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10848,6 +10848,7 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
{
tree statement;
tree condition;
+ location_t loc = cp_lexer_peek_token (parser->lexer)->location;
/* Look for the `('. */
if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
@@ -10941,7 +10942,7 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
indicate that this if statement has an else clause.
This may trigger the Wparentheses warning below
when we get back up to the parent if statement. */
- if (if_p != NULL)
+ if (if_p != NULL && !from_macro_expansion_at (loc))
*if_p = true;
}
else
[Bug fortran/70953] New: Reallocation on assignment does not work with debug flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70953 Bug ID: 70953 Summary: Reallocation on assignment does not work with debug flags Product: gcc Version: 7.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 attached code produces a runtime error when compiled with some debug flags (see later). The code however is correct: the dimension mismatch reported by the compiler is not an error but should trigger the allocation of the rhs. program p implicit none integer, allocatable :: v(:), x(:) allocate( x(3) ) v = int( x ) ! runtime error !v = x ! works correctly write(*,*) shape(v) end program p $ gfortran gf.f90 -g -O0 -fcheck=all -ffpe-trap=invalid -o gf $ ./gf At line 7 of file gf.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'v' (7233114627794677618/3) $ gfortran --version GNU Fortran (GCC) 7.0.0 20160422 (experimental) Removing either -fcheck=all or -ffe-trap=invalid solves the problem.
[Bug fortran/70953] Reallocation on assignment does not work with debug flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70953 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-04 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- It looks like a duplicate of pr52162 (see comment 2).
[Bug c++/70932] flexible array member with non-trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
--- Comment #2 from Jens Maurer ---
The whole point of flexible array members seems to be to save an allocation for
the array, with the precondition that the array size can be determined at
initialization time and stays fixed for the entire lifetime of the enclosing
struct. In that scenario, I need to placement-new the array elements (or,
probably, the entire array) anyway, so requiring to explicitly call the
destructor(s) seems a natural duality.
In the example
S s = { 3, { 1, 2, 3 } };
it seems surprising that the destructor for the elements is not called, given
that the number of elements is "right there" in the source code. [Yes, I have
an idea about the implementation difficulties here.] I'd rather prefer this
initialization example to be ill-formed, if the element type has a non-trivial
destructor. Consider if the element type is a std::string (with dynamic
allocation) and this is inside a loop; this seems to cause a serious memory
leak.
[Bug c/70952] Missing warning for likely-erroneous octal escapes in string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952 --- Comment #1 from Alexander Monakov --- Octal escapes have no more than three digits by definition, so "\0009" clearly doesn't fall under this warning. Upon further testing, there's no diagnostic for const char c = '\9'; /* same as ... = 9; */ Surely that's a bug? It is diagnosed (with a warning) inside of string literals.
[Bug c/70954] New: -Wmisleading-indentation false positive on GNU "ed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Bug ID: 70954
Summary: -Wmisleading-indentation false positive on GNU "ed"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
A user reported a false positive with -Wmisleading-indentation when
compiling "ed" with gcc 6.1:
https://gcc.gnu.org/ml/gcc/2016-05/msg00044.html
Minimal reproducer:
void test (const char ** const ibufpp)
{
int c = *(*ibufpp)++;
switch (c)
{
case '#': while( *(*ibufpp)++ != '\n' ) ;
break;
}
}
$ ./xgcc -B. -c test.c -Wall
test.c: In function ‘test’:
test.c:6:15: warning: this ‘while’ clause does not guard...
[-Wmisleading-indentation]
case '#': while( *(*ibufpp)++ != '\n' ) ;
^
test.c:7:15: note: ...this statement, but the latter is misleadingly indented
as if it is guarded by the ‘while’
break;
^
I agree that this is a false positive.
With trunk r235889 (and presumably the gcc-6-branch), we currently exit from
should_warn_for_misleading_indentation
here:
495 /* Otherwise, they are visually aligned: issue a warning. */
496 return true;
[Bug c/70952] Missing warning for likely-erroneous octal escapes in string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952 --- Comment #2 from Alexander Monakov --- Bah, please disregard the last point; '\9' is diagnosed similar to "\9".
[Bug c/70955] New: regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Bug ID: 70955 Summary: regression in code generation for __builtin_ms_va_list in GCC 6.1 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zenith432 at users dot sourceforge.net Target Milestone: --- I've tried on GCC 6.1.0 built for OS X, and GCC 6.1.1 on Fedora 23 supplied by their rawhide. Same behavior. - variadic function with x86-64 ms_abi calling convention. - defines local variable of type __builtin_ms_va_list. - iterates with __builtin_va_arg (note: there is no corresponding __builtin_ms_va_arg). - __builtin_va_arg treats the __builtin_ms_va_list variable as a sysv va_list, and goes berserk. I've anaylzed this by looking at the code generated. Same wrong code generated if __builtin_va_list is used inside an ms_abi function instead of __builtin_ms_va_list. This functionality worked on both GCC 5.3 and GCC 4.9, so this is a regression. I've compared the resulting code generated to GCC 5.3. The code generated on GCC 5.3 is good. As mentioned above, there is no __builtin_ms_va_arg, and never was. The function __builtin_va_arg has previously been used to iterate on all types of __builtin_*_va_list.
