[Bug tree-optimization/79286] [7 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286
--- Comment #2 from Martin Liška ---
Reducing the test-case bit more:
$ int a = 0, c = 0;
static int d[][8] = {};
int main ()
{
int e;
for (int b = 0; b < 4; b++)
{
__builtin_printf ("%d\n", b, e);
while (a && c++)
e = d[30][0];
}
return 0;
}
Problem is that we segfault here:
│0x8048448 push %ebx
│0x8048449 push %ecx
│0x804844a mov$0x0,%ebx
│0x804844f jmp0x8048459
│0x8048451 add$0x1,%ebx
│0x8048454 cmp$0x4,%ebx
│0x8048457 je 0x804849f
│0x8048459 sub$0x4,%esp
>│0x804845c pushl 0x1bc48534
which is I guess d[30][0], which is a dead-code that is placed
before the printf call first time in 273r.ira:
...
(insn 8 7 9 3 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1 S4 A32])
(mem/u:SI (const:SI (plus:SI (symbol_ref:SI ("d") [flags 0x2]
)
(const_int 331350016 [0x13c0]))) [1 d+331350016 S4
A32])) "tc.c":9 58 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 8 [0x8])
(nil)))
(insn 9 8 10 3 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1 S4 A32])
(reg/v:SI 88 [ b ])) "tc.c":9 58 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil)))
(insn 10 9 11 3 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [2 S4 A32])
(symbol_ref/f:SI ("*.LC0") [flags 0x2] )) "tc.c":9 58 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
(call_insn 11 10 12 3 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("printf") [flags 0x41] ) [0 __builtin_printf S1 A8])
(const_int 16 [0x10]))) "tc.c":9 663 {*call_value}
(expr_list:REG_UNUSED (reg:SI 0 ax)
(nil))
(nil))
That points to a different commit, I'll bisect that.
[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79299 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-31 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r242872, which is however just a pass manager changes. Thus I suspect it's a latent issue.
[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-31 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Summary|[5 Regression] ICE in |[7 Regression] ICE in |mangle_decl, at |mangle_decl, at |cp/mangle.c:3845|cp/mangle.c:3845 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r244935.
[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79297 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-31 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r241765.
[Bug ipa/79285] [7 Regression] new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I've got a patch for that, currently testing.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 Doug Gilmore changed: What|Removed |Added CC||law at redhat dot com, ||rguenth at gcc dot gnu.org, ||zqchen at gcc dot gnu.org --- Comment #18 from Doug Gilmore --- CC author and reviewers of r216501.
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 --- Comment #12 from Segher Boessenkool --- new_ready just adds insns to the ready list. High latency isn't directly a problem: if we can schedule a high latency insn early speculatively, that is a _good_ thing!
[Bug target/79299] New: [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79299
Bug ID: 79299
Summary: [7 Regression] Operand size mismatch for `vpgatherqd'
w/ -O3 -masm=intel -mavx512bw
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
When compiling the following snippet w/ -O3 -masm=intel -mavx512bw (and other
flavors of AVX-512) using gcc-7.0.0-alpha20170129 snapshot, gas 2.27 emits the
"operand size mismatch" error for instruction vpgatherqd:
int
q9 (int b7, int dr)
{
int **ov;
int rk = &b7;
while (dr != 0)
{
while (b7 != 0)
++b7;
rk += **ov;
++dr;
}
return rk;
}
% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20170129 -O3 -masm=intel -mavx512bw -c -w
xivubswo.c
/tmp/cc27Zzec.s: Assembler messages:
/tmp/cc27Zzec.s:38: Error: operand size mismatch for `vpgatherqd'
/tmp/cc27Zzec.s:39: Error: operand size mismatch for `vpgatherqd'
[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197 --- Comment #8 from Michael Meissner --- I agree the expander should call gpc_reg_operand and not reg_operand. This is due to the fact that on PowerPCs with separate floating point registers, SFmode is represented internally as DFmode when it is in the floating point/vector registers (i.e. my change on January 4th, 2017). I evidently missed the expander. The history is originally we had a define_expand and three separate insns, one in rs6000.md that handled the non-VSX case, one in spe.md, and one in vsx.md that handled VSX, and it had a common insn for DF, V2DF, and V4SF modes. We later moved the scalar processing to rs6000.md. However, since spe.md has its own unsigned fix insns, and it uses wildly different constraints, etc. we need to keep a separate define_expand, and two define_insns (in rs6000.md and spe.md). Note, I have no way of testing SPE, other than by hand inspection of the assembly code.
[Bug sanitizer/79265] -fsanitize=undefined inserts unnecessary null pointer tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265
--- Comment #2 from Martin Sebor ---
As I mentioned, the unnecessary null tests inserted by the sanitizer are
usually removed by subsequent optimization passes so they serve no useful
purpose. They do, however, make GCC work harder which can cause trouble when
they result in calls to the nonnull functions with constant null pointers as a
result of jump threading (as we have seen, and as demonstrated by the test case
below).
In the test case in comment #0 GCC eliminates the null pointer checks in f0
(local array) and f2 (alloca) but retains those in f1 (VLA) and f3 (attribute
nonnull). In all of f0, f1, and f2, the object whose address is tested against
null is on the stack, so emitting a null check in all three is equally
important or equally pointless (depending on one's point of view).
The only case where a valid pointer cannot point into the stack is f3. In this
case the pointer is "guaranteed" to be non-null by the function being declared
attribute returns_nonnull. As I also mentioned, there may be some value in
emitting the null pointer check here in case the returns_nonnull function
returns null despite its promise. Even then, however, there is no point in
emitting the check or the handler more than once when the pointer is being
passed to a nonnull argument of a built-in function like sprintf (or strcpy)
that we know will try to write to it and crash. Doing so only leads to
unnecessarily inefficient code and can cause false positives. (The repeated
calls to the UBSan null handler are also unnecessary in these cases and suggest
missing logic in the sanitizer.)
Here's another test case highlighting the returns_nonnull problem discussed
above:
$ cat u.c && gcc -O3 -S -Wall -fdump-tree-optimized=/dev/stdout
-fsanitize=undefined u.c
char* __attribute__ ((alloc_size (1), returns_nonnull))
myalloc (unsigned);
void sink (void*);
void __attribute__ ((noinline, nonnull))
f (unsigned n)
{
char *p = myalloc(n);
*p = 'a';
__builtin_sprintf (p, "%i", 1);
sink (p);
__builtin_sprintf (p, "%i", 2);
sink (p);
}
u.c: In function ‘f’:
u.c:13:3: warning: null destination pointer [-Wformat-overflow=]
__builtin_sprintf (p, "%i", 1);
^~
;; Function f (f, funcdef_no=0, decl_uid=2121, cgraph_uid=0, symbol_order=0)
__attribute__((noinline))
f (unsigned int n)
{
char * p;
[100.00%]:
p_4 = myalloc (n_2(D));
if (p_4 == 0B)
goto ; [0.04%]
else
goto ; [99.96%]
[0.00%]:
__builtin___ubsan_handle_type_mismatch (&*.Lubsan_data4, 0);
[100.00%]:
*p_4 = 97;
if (p_4 == 0B)
goto ; [0.04%]
else
goto ; [99.96%]
[0.04%]:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0);
__builtin_sprintf (0B, "%i", 1);
sink (0B);
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);
[100.00%]:
__builtin_sprintf (p_4, "%i", 2);
sink (p_4); [tail call]
return;
[99.96%]:
__builtin_sprintf (p_4, "%i", 1);
sink (p_4);
goto ; [100.00%]
}
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 --- Comment #4 from John David Anglin --- Guess this is key line "Not unifying; Symbol aliases are not supported by target".
[Bug c++/79298] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79298 Martin Sebor changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-31 CC||dmalcolm at gcc dot gnu.org, ||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Bisection points to r244715: r244715 | dmalcolm | 2017-01-20 09:36:46 -0500 (Fri, 20 Jan 2017) | 33 lines C++: fix fix-it hints for misspellings within explicit namespaces
[Bug debug/63238] DWARF does not represent _Alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63238 --- Comment #2 from Alexandre Oliva --- Author: aoliva Date: Tue Jan 31 01:03:15 2017 New Revision: 245052 URL: https://gcc.gnu.org/viewcvs?rev=245052&root=gcc&view=rev Log: [PR63238] output alignment debug information Output DWARFv5+ DW_AT_alignment for non-default alignment of variables, fields and types. for gcc/ChangeLog PR debug/63238 * dwarf2out.c (clone_as_declaration): Drop DW_AT_alignment. (add_alignment_attribute): New. (base_type_die): Add alignment attribute. (subrange_type_die): Likewise. (modified_type_die): Likewise. (gen_array_type_die): Likewise. (gen_descr_array_type_die: Likewise. (gen_enumeration_type_die): Likewise. (gen_subprogram_die): Likewise. (gen_variable_die): Likewise. (gen_field_die): Likewise. (gen_ptr_to_mbr_type_die): Likewise. (gen_struct_or_union_type_die): Likewise. (gen_subroutine_type_die): Likewise. (gen_typedef_die): Likewise. (base_type_cmp): Compare alignment attribute. for gcc/testsuite/ChangeLog PR debug/63238 * gcc.dg/debug/dwarf2/align-1.c: New. * gcc.dg/debug/dwarf2/align-2.c: New. * gcc.dg/debug/dwarf2/align-3.c: New. * gcc.dg/debug/dwarf2/align-4.c: New. * gcc.dg/debug/dwarf2/align-5.c: New. * gcc.dg/debug/dwarf2/align-6.c: New. * gcc.dg/debug/dwarf2/align-as-1.c: New. * g++.dg/debug/dwarf2/align-1.C: New. * g++.dg/debug/dwarf2/align-2.C: New. * g++.dg/debug/dwarf2/align-3.C: New. * g++.dg/debug/dwarf2/align-4.C: New. * g++.dg/debug/dwarf2/align-5.C: New. * g++.dg/debug/dwarf2/align-6.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-1.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-4.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-5.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-6.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-4.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-5.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-6.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-as-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #17 from Doug Gilmore --- > This really throws off the costing of substituting different IVs on > MIPS. I forgot to mention that for MIPS the net of effect r216501 is to not produce indexed memory OPs in simple examples where we should. But we also will produce problematic indexed memory OPs in situations where address generation costing is a bit complicated (the original issue associated with this bug report). Applying the the two patches I just attached fixes the problem of generating indexed memory OPs in simple examples, and also will cause IVOPTS to select IVs that are similar to those that were made in the past that avoids the problem executing indexed memory OPs in O32 binaries on 64-bit MIPS processors running current Linux kernels. There is still the issue of recognizing that rewriting a "use" to use a different IV can expose a problem with indexed memory OPs on 64-bit MIPS processors, where an infinite cost should be associated in that situation, that still needs to be addressed (thus the need for the flag to turn off the generation of indexed memory OPs until this issue is addressed).
[Bug c++/79298] New: ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79298
Bug ID: 79298
Summary: ICE on invalid C++ code on x86_64-linux-gnu:
Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
This seems to be a recent regression.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170130 (experimental) [trunk revision 245020] (GCC)
$
$ g++-trunk -c tmp.cpp
tmp.cpp: In function ‘int foo()’:
tmp.cpp:6:13: error: ‘y’ is not a member of ‘M’
return M::y;
^
tmp.cpp:6:13: internal compiler error: Segmentation fault
0xe13a2f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x89192b consider_binding_level
../../gcc-source-trunk/gcc/cp/name-lookup.c:4788
0x897a81 suggest_alternative_in_explicit_scope(unsigned int, tree_node*,
tree_node*)
../../gcc-source-trunk/gcc/cp/name-lookup.c:4529
0x7871b4 qualified_name_lookup_error(tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc-source-trunk/gcc/cp/error.c:3780
0x843ef8 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc-source-trunk/gcc/cp/semantics.c:3461
0x7b0373 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:5335
0x7b314e cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6782
0x7ae3cc cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8101
0x7bb627 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8778
0x7bbc35 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8880
0x7bc520 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9168
0x7befe9 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9335
0x7d16a3 cp_parser_jump_statement
../../gcc-source-trunk/gcc/cp/parser.c:12145
0x7d16a3 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10579
0x7d21cc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11025
0x7d22bf cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10979
0x7cccaf cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21431
0x7cccaf cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21467
0x7cd591 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26235
0x7ce7c9 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26147
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
-
namespace N { int x; }
namespace M = N;
int foo ()
{
return M::y;
}
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #16 from Doug Gilmore --- Created attachment 40632 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40632&action=edit Tweak to adjust_setup_cost (r220473). Second patch associated with previous comment.
[Bug target/79277] lies about alignment of DFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79277 --- Comment #1 from joseph at codesourcery dot com --- Note that for compatibility you don't want to change either __alignof__ (double) (preferred alignment, 8) or _Alignof (double) (required alignment, 4).
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #15 from Doug Gilmore --- Created attachment 40631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40631&action=edit Prototype change to backout r216501. > Bisected the problem to commit r216501: The review discussion of r216501 starts with message: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00758.html Which contains: The are two implementations of seq_cost. The function bodies are exactly the same. The patch removes one of them and make the other global. This seems the patch was cleanup that shouldn't introduce a functional change. However implementations of seq_cost are different, per final version of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00896.html cfgloopanal.c: - cost += set_rtx_cost (set, speed); rtlanal.c: +cost += set_rtx_cost (set, speed); tree-ssa-loop-ivopts.c: - cost += set_src_cost (SET_SRC (set), speed); In general, when computing the cost of a sequence of N INSNs this increases the cost of the sequence by N*4. This really throws off the costing of substituting different IVs on MIPS. The first patch attached (just a prototype) basically reverts this change. The second fixes a problem with r220473, a fix for PR62631 from Eric Botcazou: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631#c17 This looks a generic problem in get_shiftadd_cost to me, it ought to mimic the algorithms in expmed.c, something like ... This change can lower the cost of a sequence of instruction. However there are situations this (lower) cost is being scaled by an estimated iteration count will cause the adjusted cost to now become zero. For the example attached to the second patch the IV replacement algorithm will determine that the cost using separate IVs for each load will be less than then cost of one IV for all loads. Thus, in the second patch we detect that a non-zero cost being scaled to zero should represented by one instead, which gets us back to IVSOPTS generating just one IV that will be used for all loads.
[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 --- Comment #6 from Segher Boessenkool --- (In reply to Bernd Schmidt from comment #5) > (In reply to Christophe Leroy from comment #0) > > > The following section is just useless: (shift left 4 bits, remove 16, shift > > right 4 bits, add 1) > > c000d984: 55 24 20 36 rlwinm r4,r9,4,0,27 > > c000d988: 39 24 ff f0 addir9,r4,-16 > > c000d98c: 55 29 e1 3e rlwinm r9,r9,28,4,31 > > c000d990: 39 29 00 01 addir9,r9,1 > > Are you suggesting just removing these? That would not produce the same > value in all cases - consider zero as an input: > > ((0 << 4) - 16) >> 4 = 0xfff, add one and you get 0x1000. But this cannot happen, see the two immediately preceding instructions.
[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79290
--- Comment #2 from Jonathan Wakely ---
I forgot to provide the error. For completeness, it's:
s.cc: In member function ‘bool Printer::operator()(SongTag)’:
s.cc:16:36: error: request for member ‘int (Song::*)(unsigned int)
const::__pfn’ in ‘st.SongTag::function()’, which is of non-class type
‘Song::GetFunction {aka int (Song::*)(unsigned int) const}’
return st.function() == &Song::get;
^~~
[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79297 --- Comment #1 from Matthias Klose --- Created attachment 40630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40630&action=edit preprocessed source
[Bug middle-end/79297] New: [7 Regression] ICE (segfault) in main_block_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79297
Bug ID: 79297
Summary: [7 Regression] ICE (segfault) in main_block_label
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with trunk 20170129
$ cat share.ii
struct a {
a() {
goto b;
if (0)
b:;
}
} c;
(exp)doko@gb:/scratch/packages/tmp/yosys-0.7$ g++ -std=c++11 -c share.ii
share.ii: In constructor 'a::a()':
share.ii:2:3: internal compiler error: Segmentation fault
a() {
^
0xb1317f crash_signal
../../src/gcc/toplev.c:333
0xb3c743 main_block_label
../../src/gcc/tree-cfg.c:1381
0xb3cc3d cleanup_dead_labels()
../../src/gcc/tree-cfg.c:1564
0xb477f1 build_gimple_cfg
../../src/gcc/tree-cfg.c:238
0xb477f1 execute_build_cfg
../../src/gcc/tree-cfg.c:397
0xb477f1 execute
../../src/gcc/tree-cfg.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 --- Comment #3 from John David Anglin --- Created attachment 40629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40629&action=edit ipa dump
[Bug c++/79296] New: [5 Regression] ICE in mangle_decl, at cp/mangle.c:3845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296
Bug ID: 79296
Summary: [5 Regression] ICE in mangle_decl, at cp/mangle.c:3845
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
Created attachment 40628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40628&action=edit
preprocessed source
seen with 20170129
$ cat test_alias_initialization.ii
namespace a {
class b {
public:
template b(c h::*...) {
[] {};
}
};
class d {};
template class e {
public:
template void ab(const char *, g l) { b(l, int()); }
};
}
template class ac;
template class B {
protected:
static ad i(int) {}
};
template class o;
template
class o : B {
public:
static af k(const int &p1, j... l) { B::i(p1)(l...); }
};
template class ac {
template using m = int;
public:
template , typename = m>
ac(ad);
using ah = af (*)(const int &, j...);
ah n;
};
template
template
ac::ac(ad) {
n = o::k;
}
namespace ai = a;
class q {
public:
q(ac);
} r([](ai::d) {
struct p {
virtual void f();
};
struct aj;
ai::e().ab("", &p::f);
});
$ g++ -c -std=c++14 -flto test_alias_initialization.ii
test_alias_initialization.ii:5:6: internal compiler error: in mangle_decl, at
cp/mangle.c:3845
[] {};
^
0x6f3372 mangle_decl(tree_node*)
../../src/gcc/cp/mangle.c:3844
0xd29b1b decl_assembler_name(tree_node*)
../../src/gcc/tree.c:671
0xd29b1b assign_assembler_name_if_needed(tree_node*)
../../src/gcc/tree.c:5920
0xd2aeb1 free_lang_data_in_cgraph
../../src/gcc/tree.c:5969
0xd2aeb1 free_lang_data
../../src/gcc/tree.c:6006
0xd2aeb1 execute
../../src/gcc/tree.c:6055
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79170 --- Comment #2 from acsawdey at gcc dot gnu.org --- Author: acsawdey Date: Mon Jan 30 23:24:24 2017 New Revision: 245041 URL: https://gcc.gnu.org/viewcvs?rev=245041&root=gcc&view=rev Log: 2017-01-27 Aaron Sawdey PR target/79170 * gcc.dg/memcmp-1.c: Improved to catch failures seen in PR 79170. 2017-01-27 Aaron Sawdey PR target/79170 * config/rs6000/altivec.md (*setb_internal): Rename to setb_signed. (setb_unsigned) New pattern for setb with CCUNS. * config/rs6000/rs6000.c (expand_block_compare): Use a different subfc./subfe sequence to avoid overflow problems. Generate a shorter sequence with cmpld/setb for power9. * config/rs6000/rs6000.md (subf3_carry_dot2): Add a new pattern for generating subfc. instruction. (cmpstrsi): Add TARGET_POPCNTD predicate as the generate sequence now uses this instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/memcmp-1.c
[Bug other/79295] New: [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79295
Bug ID: 79295
Summary: [7 regression] gcc.target/powerpc/bcd-3.c fails
starting with r244942
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
Causes an ICE
spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O2
-ffat-lto-objects -S -o bcd-3.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c: In function
'do_add_lt':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c:34:1: error:
insn does not satisfy its constraints:
(insn 44 3 13 2 (parallel [
(set (reg/v:V1TI 32 0 [orig:156 ] [156])
(unspec:V1TI [
(reg/v:V1TI 77 0 [orig:157 a ] [157])
(reg/v:V1TI 78 1 [orig:158 b ] [158])
(const_int 0 [0])
] UNSPEC_BCDADD))
(set (reg:CCFP 74 6)
(compare:CCFP (unspec:V2DF [
(reg/v:V1TI 77 0 [orig:157 a ] [157])
(reg/v:V1TI 78 1 [orig:158 b ] [158])
(const_int 0 [0])
] UNSPEC_BCDADD)
(const_vector:V2DF [
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
])))
])
"/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c":30 1753
{*bcdadd_test2}
(nil))
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c:34:1:
internal compiler error: in extract_constrain_insn, at recog.c:2213
0x108a9b13 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/seurer/gcc/gcc-test/gcc/rtl-error.c:108
0x108a9b6b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/seurer/gcc/gcc-test/gcc/rtl-error.c:119
0x1086fa67 extract_constrain_insn(rtx_insn*)
/home/seurer/gcc/gcc-test/gcc/recog.c:2213
0x10874e1f copyprop_hardreg_forward_1
/home/seurer/gcc/gcc-test/gcc/regcprop.c:794
0x10875eb7 execute
/home/seurer/gcc/gcc-test/gcc/regcprop.c:1301
[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Patch committed.
[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jan 30 22:26:26 2017 New Revision: 245039 URL: https://gcc.gnu.org/viewcvs?rev=245039&root=gcc&view=rev Log: PR debug/79289 * dwarf2out.c (gen_type_die_with_usage): When picking a variant for FUNCTION_TYPE/METHOD_TYPE, use the first matching one. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/79286] [7 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286 Martin Liška changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-30 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Summary|wrong code at -O3 on|[7 Regression] wrong code |x86_64-linux-gnu in 32-bit |at -O3 on x86_64-linux-gnu |mode (but not in 64-bit |in 32-bit mode (but not in |mode) |64-bit mode) Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r239357.
[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79294 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-30 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r241425.
[Bug c++/79294] New: [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79294 Bug ID: 79294 Summary: [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 40627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40627&action=edit preprocessed source seen with r244943 20170129 $ cat python.ii template struct a; template a < b $ g++ -c -std=c++11 python.ii python.ii:2:23: internal compiler error: in convert_nontype_argument, at cp/pt.c:6812 template a < b ^ 0x62d24a convert_nontype_argument ../../src/gcc/cp/pt.c:6811 0x62d24a convert_template_argument ../../src/gcc/cp/pt.c:7648 0x62de3c coerce_template_parms ../../src/gcc/cp/pt.c:8108 0x630139 lookup_template_class_1 ../../src/gcc/cp/pt.c:8632 0x630139 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../src/gcc/cp/pt.c:8977 0x6c8bfd finish_template_type(tree_node*, tree_node*, int) ../../src/gcc/cp/semantics.c:3145 0x67923e cp_parser_template_id ../../src/gcc/cp/parser.c:15488 0x6793df cp_parser_class_name ../../src/gcc/cp/parser.c:21922 0x683987 cp_parser_qualifying_entity ../../src/gcc/cp/parser.c:6287 0x683987 cp_parser_nested_name_specifier_opt ../../src/gcc/cp/parser.c:5973 0x6705a2 cp_parser_constructor_declarator_p ../../src/gcc/cp/parser.c:25918 0x6705a2 cp_parser_decl_specifier_seq ../../src/gcc/cp/parser.c:13312 0x670975 cp_parser_single_declaration ../../src/gcc/cp/parser.c:26574 0x68c64c cp_parser_template_declaration_after_parameters ../../src/gcc/cp/parser.c:26268 0x68c3ab cp_parser_explicit_template_declaration ../../src/gcc/cp/parser.c:26503 0x68c3ab cp_parser_template_declaration_after_export ../../src/gcc/cp/parser.c:26522 0x670ff1 cp_parser_declaration ../../src/gcc/cp/parser.c:12442 0x69692b cp_parser_declaration_seq_opt ../../src/gcc/cp/parser.c:12369 0x696c12 cp_parser_translation_unit ../../src/gcc/cp/parser.c:4369 0x696c12 c_parse_file() ../../src/gcc/cp/parser.c:38357 Please submit a full bug report, with preprocessed source if appropriate.
[Bug testsuite/79293] [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79293 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Test fixed via r245037.
[Bug testsuite/79293] [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79293 --- Comment #2 from Martin Sebor --- Author: msebor Date: Mon Jan 30 21:59:37 2017 New Revision: 245037 URL: https://gcc.gnu.org/viewcvs?rev=245037&root=gcc&view=rev Log: PR testsuite/79293 - gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/builtin-sprintf.c: Relax long double test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
[Bug testsuite/79293] [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79293
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2017-01-30
Component|tree-optimization |testsuite
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. The following is the test case on line 724:
RNG ( 3, 13, 14, "%Lg", 0.1L);
It expects the call to sprintf ("%Lg", 0.1L) to return a value between 3 and 13
but on powerpc64 it returns between 3 and 4 bytes ("0.1" when the argument is
rounded up and "0.099" when it's rounded down, with the decimal point
taking resulting in between 1 and 6 bytes in multibyte locales).
The test case needs to be relaxed for powerpc64. Let me take care of it.
[Bug c/79082] -Wformat-truncation inconsistent behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082 Martin Sebor changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Sebor --- Resolving as fixed as per comment #14.
[Bug middle-end/79275] -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79275 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02353.html
[Bug target/79158] gcc.target/powerpc/pr70669.c fails on powerpc BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79158
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pthaugen at gcc dot
gnu.org
--- Comment #1 from Pat Haugen ---
The problem on BE is that the compiler recognizes it doesn't have to move the
value back to a VSR before dong the store, and just generates stores of the GPR
(hence the FAILs on mtvsrd/stxvd2x). Here's the source of testcase and output
on BE with current trunk.
#ifndef TYPE
#define TYPE __float128
#endif
void foo (TYPE *p, TYPE *q)
{
TYPE r = *q;
#ifndef NO_ASM
__asm__ (" # %0" : "+r" (r));
#endif
*p = r;
}
.L.foo:
lxvd2x 0,0,4
mfvsrd 10,0
xxpermdi 0,0,0,3
mfvsrd 11,0
#APP
# 14 "pr70669.c" 1
# 10
# 0 "" 2
#NO_APP
std 10,0(3)
std 11,8(3)
blr
Since this testcase is just trying to test that the moves don't go through
memory, modifying the last stmt to "*p = r + r" so that the value in 'r' (i.e.
GPR 10/11) is forced back to a VSR appears to fix the problem on BE and still
passes on LE.
Mike, Does this reasoning sound correct to you? If so I'll submit a patch.
[Bug target/78597] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78597 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-30 CC||meissner at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Michael Meissner --- It is a real bug in the PowerPC backend. The bug is that the unsigned int value of 0x8000 is converted incorrectly, when it is converted from unsigned int to __float128 and back to unsigned int. I have a solution already as part of PRs target/79038, target/79202, and target/79203. Most of the work in those bugs is an enhancement that did not make the stage3 cut, but I will try to isolate a minimum patch to fix GCC 7.
[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824
--- Comment #7 from Leandro Nini ---
Reduced testcase, ICEs with gcc -O2 -floop-interchange:
int a, b, d;
int **c;
int fn1() {
while (a)
if (d) {
int e = -d;
for (; b < e; b++)
c[b] = &a;
} else {
for (; b; b++)
c[b] = &b;
d = 0;
}
}
[Bug ipa/79285] [7 Regression] new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, let me isolate a test-case.
[Bug tree-optimization/79293] New: [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79293 Bug ID: 79293 Summary: [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- At least I think it is 244753. There were a bunch of updates for that revision which left the compiler unable to build but after those were cleared up builtin-sprintf was failing. pawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c -fno-diagnostics-show-caret -fdiagnostics-color=never -ansi -pedantic-errors -O2 -Wall -Wno-pedantic -fprintf-return-value -lm -o ./builtin-sprintf.exe /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_d_i': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:307:20: warning: '0' flag ignored with precision and '%i' gnu_printf format [-Wformat=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:128:44: note: in definition of macro 'RNG' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_percent': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:791:18: warning: too many arguments for format [-Wformat-extra-args] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:792:18: warning: too many arguments for format [-Wformat-extra-args] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:793:18: warning: too many arguments for format [-Wformat-extra-args] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL' /tmp/ccg3ni4S.o: In function `test_g_long_double': builtin-sprintf.c:(.text+0x5600): undefined reference to `failure_on_line_724' collect2: error: ld returned 1 exit status compiler exited with status 1 output is: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_d_i': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:307:20: warning: '0' flag ignored with precision and '%i' gnu_printf format [-Wformat=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:128:44: note: in definition of macro 'RNG' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_percent': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:791:18: warning: too many arguments for format [-Wformat-extra-args] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:792:18: warning: too many arguments for format [-Wformat-extra-args] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL' /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:793:18: warning: too many arguments for format [-Wformat-extra-args] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL' /tmp/ccg3ni4S.o: In function `test_g_long_double': builtin-sprintf.c:(.text+0x5600): undefined reference to `failure_on_line_724' collect2: error: ld returned 1 exit status PASS: gcc.dg/tree-ssa/builtin-sprintf.c (test for warnings, line 307) PASS: gcc.dg/tree-ssa/builtin-sprintf.c (test for warnings, line 791) PASS: gcc.dg/tree-ssa/builtin-sprintf.c (test for warnings, line 792) PASS: gcc.dg/tree-ssa/builtin-sprintf.c (test for warnings, line 793) FAIL: gcc.dg/tree-ssa/builtin-sprintf.c (test for excess errors) Excess errors: builtin-sprintf.c:(.text+0x5600): undefined reference to `failure_on_line_724' UNRESOLVED: gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable
[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210 --- Comment #11 from David Malcolm --- In theory we could fix the location of the stringified token; perhaps it could use the location of the arg. But cpp_interpret_string_ranges calls cpp_interpret_string_1 which expects the strings it re-lexes to have opening quotes, which isn't going to be the case for a stringified arg; we would have to somehow flag the token as being from stringization, and to interpret it differently so that it doesn't expect quotes. This seems invasive and error-prone, so I think the lowest-risk fix is likely to be to convert the failing assertion to an error-handling conditional, rather than to attempt to fixup the locations.
[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289 --- Comment #2 from Jason Merrill --- (In reply to Ian Lance Taylor from comment #1) > This patch seems to fix the problem, but I can't tell whether this is > correct or whether the other obvious change is correct. This one looks good.
[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210 --- Comment #10 from David Malcolm --- For reference, after preprocessing, the format string is: "0423 lpfc_peer_port_login attribute cannot be set to %d, allowed range is [0, 1]\n" ^~ ...showing where the underline would be, if it was a regular string without macros.
[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #9 from David Malcolm ---
Origin of the garbage location_t value:
During macro expansion, temporary tokens (via _cpp_temp_token) use the location
of the last lexed token as their location, so identifying the origin of the
bogus location_t value requires some tracing back through a series of temporary
tokens. The easier way to do it was to put an assertion into
linemap_position_for_column to detect where the bogus value is generated:
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index cf7c110..021059c 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -195,6 +195,11 @@ get_combined_adhoc_loc (struct line_maps *set,
{
source_location packed = locus | col_diff;
set->num_optimized_ranges++;
+
+ /* What leads to this bogus value? */
+ if (0)
+ linemap_assert (packed != 229843);
+
return packed;
}
}
The bogus location_t value arises when a cpp_token for the CPP_NAME
"lpfc_peer_port_login" is generated, due to:
#define LPFC_VPORT_ATTR_R(name, desc) \
unsigned int lpfc_##name;\
^
first part
LPFC_VPORT_ATTR_R(peer_port_login,
^~~
second part
and there isn't a way of representing this split location as a location_t.
In fact, it generates an entirely bogus location for the token:
line_table: entering: void paste_all_tokens(cpp_reader*, const cpp_token*)
line_table:entering: bool paste_tokens(cpp_reader*, source_location, const
cpp_token**, const cpp_token*)
line_table: *plhs: lpfc_
../../src/pr79210-via-attachment.c:13:14: note: 209764
unsigned int lpfc_##name;\
^
line_table: rhs: peer_port_login
../../src/pr79210-via-attachment.c:16:19: note: 22
LPFC_VPORT_ATTR_R(peer_port_login,
^~~
line_table: entering: cpp_token* _cpp_lex_direct(cpp_reader*)
line_table: entering: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table: to_column: 1
line_table: returning: 229824
../../src/pr79210-via-attachment.c:18:1: note: 229824
"other.");
^
line_table: exiting: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table: entering: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table: to_column: 20
line_table: returning: 230432
../../src/pr79210-via-attachment.c:18:20: note: 230432
"other.");
^
line_table: exiting: source_location
linemap_position_for_column(line_maps*, unsigned int)
paste_tokens takes a pair of tokens, combines the text into a temporary buffer,
and calls _cpp_lex_direct on that temporary buffer.
Hence the start and finish locations for the resulting pasted token is insane:
it takes the line information from the last parsed line in the line table, and
uses the buffer length for the column number.
Subsequent temporary tokens (including the stringified name) "inherit" this
bogus location.
[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210 --- Comment #8 from David Malcolm --- The concatenation: The concatenated string comes from 4 string tokens, with the following locations, and locs[1] is a bogus value: ../../src/pr79210-via-attachment.c:8:6: note: locs[0] "0423 lpfc_"#attr" attribute cannot be set to %d, "\ ^~~~ ../../src/pr79210-via-attachment.c:18:1: note: locs[1] "other."); ^~~~ ../../src/pr79210-via-attachment.c:8:23: note: locs[2] "0423 lpfc_"#attr" attribute cannot be set to %d, "\ ^~~ "allowed range is [0, 1]\n", val); \ ../../src/pr79210-via-attachment.c:9:6: note: locs[3] "allowed range is [0, 1]\n", val); \ ^~~ Note that diagnostic_show_locus doesn't print the full range of garbage value locs[1] correctly, and needed this patch: diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c index 5c386ae..a41b19a 100644 --- a/gcc/diagnostic-show-locus.c +++ b/gcc/diagnostic-show-locus.c @@ -1367,9 +1367,11 @@ layout::get_state_at_point (/* Inputs. */ /* Within a multiline range, don't display any underline in any leading or trailing whitespace on a line. We do display carets, however. */ +#if 0 if (!out_state->draw_caret_p) if (column < first_non_ws || column > last_non_ws) return false; +#endif /* We are within a range. */ return true; to avoid just printing: (gdb) call inform(result->src_loc, "") ../../src/pr79210-via-attachment.c:18:1: note: "other."); ^ ~~
[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210 --- Comment #7 from David Malcolm --- Root cause is: (a) a garbage location_t value for one of the string tokens within the concatenation, but (b) it's not clear that there *is* a non-garbage value for the string token in question, as it comes from pasting macro tokens together.
[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79290 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-30 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79290 Jonathan Wakely changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Looks like this was caused by r244833
[Bug c++/79292] New: address of string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79292
Bug ID: 79292
Summary: address of string constant
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
We warn about address of non-weak decl being non-null ('if (&foo) ...'), but we
don't warn about string constants:
bool x = "baz";
[Bug tree-optimization/79291] New: r244397 introduces alias related performance issues for daxpy on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79291 Bug ID: 79291 Summary: r244397 introduces alias related performance issues for daxpy on MIPS Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doug.gilmore at imgtec dot com Target Milestone: --- It appears that r244397 introduces pealing for DP daxpy, which per bug 69710, introduces a performance degradation due to alias issues. After IVOPTS before r244897 (use daxpy example from bug 69710): ivtmp.20_36 = ivtmp.20_35 + 1; ivtmp.21_24 = ivtmp.21_9 + 16; ivtmp.24_3 = ivtmp.24_2 + 16; After IVOPTS after r244897: ivtmp.23_56 = ivtmp.23_24 + 1; ivtmp.24_11 = ivtmp.24_9 + 16; ivtmp.27_87 = ivtmp.27_86 + 16; ivtmp.29_90 = ivtmp.29_89 + 16; Thus after r244397 we have a problem in DP daxpy that we were only seeing for SP daxpy (or saxpy) as shown in bug69710. BTW: I have been investigating another IVOPTS related regression on MIPS32R2 that is related to the generation of indexed memory OPs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176#c12 I'll be updating that report with more information on how to fix the regression and how it relates to this issue. Bin: I suspect this is also now broken on ARM, can you check? Thanks, Doug
[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289
Ian Lance Taylor changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #1 from Ian Lance Taylor ---
I think the bug is a mismatch in how the code determines the base type to use
for the DIE in this change:
2016-11-03 Jakub Jelinek
Alexandre Oliva
Jason Merrill
PR debug/28767
PR debug/56974
* langhooks.h (struct lang_hooks_for_types): Add type_dwarf_attribute
langhook.
* langhooks.c (lhd_type_dwarf_attribute): New function.
* langhooks-def.h (lhd_type_dwarf_attribute): Declare.
(LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add
LANG_HOOKS_TYPE_DWARF_ATTRIBUTE.
(check_qualified_type, check_aligned_type): Call it.
* dwarf2out.c (modified_type_die): Don't use type_main_variant
for FUNCTION_TYPE or METHOD_TYPE, instead walk over variants with
check_base_type and check_lang_type.
(gen_ptr_to_mbr_type_die): If lookup_type_die is already non-NULL,
return early. For pointer-to-data-member add DW_AT_use_location
attribute.
(gen_subroutine_type_die): Add DW_AT_{,rvalue_}reference attribute
if needed.
(gen_type_die_with_usage): Don't use type_main_variant
for FUNCTION_TYPE or METHOD_TYPE, instead walk over variants with
check_base_type and check_lang_type. Formatting fixes. Call
get_debug_type langhook.
The problem is that the DIE is stored with one type variant in
gen_type_die_with_usage (the last matching variant), but looked up with a
different type variant in modified_type_die (the first matching variant).
This patch seems to fix the problem, but I can't tell whether this is correct
or whether the other obvious change is correct.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 244166)
+++ gcc/dwarf2out.c (working copy)
@@ -24395,8 +24395,13 @@ gen_type_die_with_usage (tree type, dw_d
but try to canonicalize. */
tree main = TYPE_MAIN_VARIANT (type);
for (tree t = main; t; t = TYPE_NEXT_VARIANT (t))
- if (check_base_type (t, main) && check_lang_type (t, type))
- type = t;
+ {
+ if (check_base_type (t, main) && check_lang_type (t, type))
+ {
+ type = t;
+ break;
+ }
+ }
}
else if (TREE_CODE (type) != VECTOR_TYPE
&& TREE_CODE (type) != ARRAY_TYPE)
[Bug c++/79290] New: [7 Regression] forming pointer to member function tries to access "__pfn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79290
Bug ID: 79290
Summary: [7 Regression] forming pointer to member function
tries to access "__pfn"
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct Song {
typedef int (Song::*GetFunction)(unsigned) const;
virtual int get(unsigned) const = 0;
};
struct SongTag {
Song::GetFunction function() const { return m_function; }
Song::GetFunction m_function;
};
template
struct Printer {
bool operator()(const SongTag st) {
return st.function() == &Song::get;
}
};
int main()
{
Printer p;
p(SongTag{});
}
[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78958 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug debug/79289] New: DWARF info for typeof of C function with no args and no prototype is empty pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289
Bug ID: 79289
Summary: DWARF info for typeof of C function with no args and
no prototype is empty pointer
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
Compile this program with current mainline with -g on GNU/Linux:
static void sub() {}
void f1() { sub(); }
void f2(void) { sub(); }
__typeof__(f1) *v1;
__typeof__(f2) *v2;
Using readelf --debug to examine the debug info I see this for v1:
<1><2d>: Abbrev Number: 2 (DW_TAG_variable)
<2e> DW_AT_name: v1
<31> DW_AT_decl_file : 1
<32> DW_AT_decl_line : 4
<33> DW_AT_type: <0x41>
<37> DW_AT_external: 1
<37> DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0 (DW_OP_addr: 8)
<1><41>: Abbrev Number: 3 (DW_TAG_pointer_type)
<42> DW_AT_byte_size : 8
Note that the type of v1 is a pointer, but there is no type listed for what it
points to.
By comparison, the debug info for v2 is:
<1><43>: Abbrev Number: 4 (DW_TAG_subroutine_type)
<44> DW_AT_prototyped : 1
<1><44>: Abbrev Number: 2 (DW_TAG_variable)
<45> DW_AT_name: v2
<48> DW_AT_decl_file : 1
<49> DW_AT_decl_line : 5
<4a> DW_AT_type: <0x58>
<4e> DW_AT_external: 1
<4e> DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0 (DW_OP_addr: 8)
<1><58>: Abbrev Number: 5 (DW_TAG_pointer_type)
<59> DW_AT_byte_size : 8
<5a> DW_AT_type: <0x43>
Here the type of v2 is clearly a pointer to a function, although there is no
real information about the function: just that it is prototyped.
By comparison, with GCC 6, I see this for v1:
<1><29>: Abbrev Number: 2 (DW_TAG_subroutine_type)
<2a> DW_AT_sibling : <0x30>
<2><2e>: Abbrev Number: 3 (DW_TAG_unspecified_parameters)
<2><2f>: Abbrev Number: 0
<1><30>: Abbrev Number: 4 (DW_TAG_variable)
<31> DW_AT_name: v1
<34> DW_AT_decl_file : 1
<35> DW_AT_decl_line : 4
<36> DW_AT_type: <0x44>
<3a> DW_AT_external: 1
<3a> DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0 (DW_OP_addr: 8)
<1><44>: Abbrev Number: 5 (DW_TAG_pointer_type)
<45> DW_AT_byte_size : 8
<46> DW_AT_type: <0x29>
and I see this for v2 (the same as for GCC 7):
<1><4a>: Abbrev Number: 6 (DW_TAG_subroutine_type)
<4b> DW_AT_prototyped : 1
<1><4b>: Abbrev Number: 4 (DW_TAG_variable)
<4c> DW_AT_name: v2
<4f> DW_AT_decl_file : 1
<50> DW_AT_decl_line : 5
<51> DW_AT_type: <0x5f>
<55> DW_AT_external: 1
<55> DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0 (DW_OP_addr: 8)
<1><5f>: Abbrev Number: 5 (DW_TAG_pointer_type)
<60> DW_AT_byte_size : 8
<61> DW_AT_type: <0x4a>
I'm not entirely sure what is correct here, but a pointer type that doesn't
point to anything must be wrong. The change from GCC 6 to GCC 7 in the debug
info for v1 is a regression.
[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79288 --- Comment #2 from Jakub Jelinek --- Created attachment 40626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40626&action=edit gcc7-pr79288.patch Untested fix.
[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 --- Comment #11 from PeteVine --- Super cool, thanks! That makes the OP a true prophet before his time ;)
[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79288 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #6 from Maxim Ostapenko --- (In reply to Maxim Ostapenko from comment #5) > (In reply to Iain Sandoe from comment #4) > > (In reply to Jakub Jelinek from comment #3) > > > Have you raised this with compiler-rt upstream already? > > > > I don't believe that upstream supports the sanitisers for Darwin < 11. > > > > However, as seen, they are quite capable of function with a little TLC. I > > don't have a chance to progress this until at least mid-Feb, if it's more > > urgent, then (a) please adopt some version of the patch locally, or (b) > > disable for Darwin < 11. > > They don't, but they can actually accept the patch for Darwin 10 (I used to > commit such patches after previous merge). > I can post attached fix upstream, but than I'll ask you (or Dominique) for > help in testing if they won't accept the patch as it is (most likely they > won't). I've initiated discussion upstream: https://reviews.llvm.org/D29287
[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79288 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-30 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- The definition of the static data member could be of course in some shared library the binary is linked against. As I've caused this, I'll debug this tomorrow.
[Bug c++/79288] New: [7 Regression] TLS model wrong for static data members since r241137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79288
Bug ID: 79288
Summary: [7 Regression] TLS model wrong for static data members
since r241137
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r241137
struct S
{
static __thread int *p;
};
int *
foo ()
{
return S::p;
}
emits for non-pic code TLS local exec model relocations instead of initial
exec.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to James Clarke from comment #4) > Ah, sorry, there's a separate C implementation of all this. I imagine it's > the bools in "struct M" in runtime.h messing it up, so "struct Note" and > "struct Lock" need __attribute__((aligned(4))) on their key fields. I just did that on gcc-6. The result is: (sid-m68k-sbuild)root@ikarus:/# ./routines Alice Bob Hello World Alice Bob Hello World Alice Bob Hello World Alice Bob Hello World Alice Bob Hello (sid-m68k-sbuild)root@ikarus:/# :D I haven't tested gcc-7 yet, but at least this fix for gcc-6 can be added.
[Bug fortran/79287] New: include files not searched for relative to the file containing the fortran include statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79287 Bug ID: 79287 Summary: include files not searched for relative to the file containing the fortran include statement Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: okiddle at yahoo dot co.uk Target Milestone: --- I have some Fortran code that makes use of the Fortran INCLUDE statement (as opposed to the preprocessor). A source file includes an include file which in turn includes another source file. Specifying no search path with -I it is able to find the first include file, looking relative to the original source file but when looking for the second include file it is not looking relative to the first include file (the file containing the INCLUDE statement). The same code compiles with the Intel or Solaris compilers. As a basic test: hello.f90 contains INCLUDE 'include/first.inc' include/first.inc contains INCLUDE 'second.inc' include/second.inc contains whatever In order to find second.inc, it should look relative to the directory containing first.inc.
[Bug middle-end/79285] [7 Regression] new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 Andrew Pinski changed: What|Removed |Added Keywords||GC, ice-on-valid-code Component|c |middle-end Target Milestone|--- |7.0 Summary|new valgrind error in build |[7 Regression] new valgrind ||error in build
[Bug c++/79264] [7 Regression] ICE verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79264 --- Comment #2 from Nathan Sidwell --- Created attachment 40625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40625&action=edit Reduced testcase ./obj/x86_64/gcc/cc1plus -fconcepts -std=c++1z -g3 79264-dbg.ii It's very easy to turn this into a different seg fault somewhere in the gimplifier. Sadly my 67273 patch doesn't fix this one.
[Bug c/79082] -Wformat-truncation inconsistent behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082 --- Comment #14 from Franz Sirl --- I just finished testing with r245021 and now the warnings are as expected. All warnings are there with -Wformat-truncation=2 and also -Wformat-truncation=1 behaves according to the documentation (BTW, there's a typo in invoke.texi, "truncatation" instead of "truncation"). You can close the bug.
[Bug target/79240] [7 Regression] ICE in s390_extzv_shift_ok, at config/s390/s390.c:2475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/79286] New: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286
Bug ID: 79286
Summary: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
(but not in 64-bit mode)
Product: gcc
Version: unknown
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: ---
This seems to be a recent regression.
$ 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/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170130 (experimental) [trunk revision 245020] (GCC)
$
$ gcc-trunk -m32 -O2 small.c; ./a.out
$ gcc-trunk -m64 -O3 small.c; ./a.out
$
$ gcc-trunk -m32 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$
-
int printf (const char *, ...);
int a[6], b, c, d, e, f, g, h;
static int i[][8] = { { 0 } };
void fn1 (int l)
{
c = (c & 5) ^ a[(c ^ l) & 5];
}
void fn2 ()
{
fn1 (e >> 5);
fn1 (e >> 6 & 5);
c = (c & 5) ^ a[(c ^ 5) & 5];
fn1 (e >> 2 & 5);
fn1 (e & 5);
fn1 (e >> 28 & 5);
}
void fn3 ()
{
int k;
for (; g < 4; g++)
{
while (d)
{
fn2 ();
if (k)
printf ("%d\n", k);
}
while (f)
while (h++)
k = i[30][0];
while (b)
while (1)
d++;
}
}
int main ()
{
fn3 ();
return 0;
}
[Bug c/79285] New: new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 Bug ID: 79285 Summary: new valgrind error in build Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just tried a gcc trunk build, under valgrind, and got this: ==19121== Invalid read of size 4 ==19121==at 0x9C9E3D: slide (hash-table.h:999) ==19121==by 0x9C9E3D: begin (hash-table.h:476) ==19121==by 0x9C9E3D: begin (hash-map.h:233) ==19121==by 0x9C9E3D: release (symbol-summary.h:78) ==19121==by 0x9C9E3D: function_summary::~function_summary() (symbol-summary.h:57) ==19121==by 0x7D2BA4: call (ggc-page.c:339) Configure line was ../trunk/configure --prefix=/home/dcb/gcc/results.245021 \ --disable-bootstrap \ --disable-multilib \ --disable-werror \ --enable-checking=valgrind \ --enable-languages=c,c++,fortran The last time I did this, on 20170120, there was no such valgrind error.
[Bug c/79082] -Wformat-truncation inconsistent behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082 Martin Sebor changed: What|Removed |Added Status|NEW |WAITING --- Comment #13 from Martin Sebor --- Franz, when you have a chance now that the full patch set for bug 78703 has been committed, can you please give it try and let me know if it resolves the issues you reported here? If so I'd like to resolve this bug as fixed. If there are other issues unrelated to these please open a new bug. (FYI: I'm working on another patch for bug 79275 that should further reduce the false positive rate in this area.)
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Rainer Orth --- Fixed for gcc 6.4.0, 5.5.0.
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979 --- Comment #8 from Rainer Orth --- Author: ro Date: Mon Jan 30 16:08:42 2017 New Revision: 245034 URL: https://gcc.gnu.org/viewcvs?rev=245034&root=gcc&view=rev Log: Only declare gets for C++ < 2014 on Solaris (PR libstdc++/78979) Backport from mainline 2017-01-13 Rainer Orth PR libstdc++/78979 * inclhack.def (solaris_gets_c11, solaris_gets_cxx14) (solaris_std_gets_cxx14, solaris_stdlib_noreturn): New fixes. * fixincl.x: Regenerate. * tests/base/iso/stdio_iso.h [SOLARIS_GETS_C11_CHECK, SOLARIS_GETS_CXX14_CHECK, SOLARIS_STD_GETS_CXX14_CHECK, SOLARIS_STDLIB_NORETURN_CHECK]: New tests. Added: branches/gcc-5-branch/fixincludes/tests/base/iso/stdlib_c99.h Modified: branches/gcc-5-branch/fixincludes/ChangeLog branches/gcc-5-branch/fixincludes/fixincl.x branches/gcc-5-branch/fixincludes/inclhack.def branches/gcc-5-branch/fixincludes/tests/base/iso/stdio_iso.h branches/gcc-5-branch/fixincludes/tests/base/stdio.h
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #30 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Mon Jan 30 16:06:15 2017 New Revision: 245033 URL: https://gcc.gnu.org/viewcvs?rev=245033&root=gcc&view=rev Log: PR lto/79061 * asan.c (get_translation_unit_decl): Remove function. (asan_add_global): Force has_dynamic_init to zero in LTO mode. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c
[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284 --- Comment #2 from Martin Liška --- (gdb) p debug_gimple_stmt(stmt) mask__5.10_9 = mask__3.9_16 ^ vect_cst__10; $1 = void (gdb) p debug_gimple_stmt(rhs1)) Junk after end of expression. (gdb) p debug_tree(rhs1_type) unit size align 32 symtab 0 alias set -1 canonical type 0x769a5f18 precision 32 min max > V4SI size constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type 0x769a5d20 nunits 4> $2 = void (gdb) p debug_tree(rhs2_type) unit size align 8 symtab 0 alias set -1 canonical type 0x769a5738 precision 8 min max > unsigned V16QI size constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type 0x769e1150 nunits 16> $3 = void (gdb) p debug_gimple_stmt(stmt) mask__5.10_9 = mask__3.9_16 ^ vect_cst__10; $4 = void (gdb) p debug_tree(rhs1_type) unit size align 32 symtab 0 alias set -1 canonical type 0x769a5f18 precision 32 min max > V4SI size constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type 0x769a5d20 nunits 4> $5 = void (gdb) p debug_tree(rhs2_type) unit size align 8 symtab 0 alias set -1 canonical type 0x769a5738 precision 8 min max > unsigned V16QI size constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type 0x769e1150 nunits 16> $6 = void
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979 --- Comment #7 from Rainer Orth --- Author: ro Date: Mon Jan 30 16:01:11 2017 New Revision: 245032 URL: https://gcc.gnu.org/viewcvs?rev=245032&root=gcc&view=rev Log: Only declare gets for C++ < 2014 on Solaris (PR libstdc++/78979) Backport from mainline 2017-01-13 Rainer Orth PR libstdc++/78979 * inclhack.def (solaris_gets_c11, solaris_gets_cxx14) (solaris_std_gets_cxx14, solaris_stdlib_noreturn): New fixes. * fixincl.x: Regenerate. * tests/base/iso/stdio_iso.h [SOLARIS_GETS_C11_CHECK, SOLARIS_GETS_CXX14_CHECK, SOLARIS_STD_GETS_CXX14_CHECK, SOLARIS_STDLIB_NORETURN_CHECK]: New tests. Added: branches/gcc-6-branch/fixincludes/tests/base/iso/stdlib_c99.h Modified: branches/gcc-6-branch/fixincludes/ChangeLog branches/gcc-6-branch/fixincludes/fixincl.x branches/gcc-6-branch/fixincludes/inclhack.def branches/gcc-6-branch/fixincludes/tests/base/iso/stdio_iso.h branches/gcc-6-branch/fixincludes/tests/base/stdio.h
[Bug c/79082] -Wformat-truncation inconsistent behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082
--- Comment #12 from Martin Sebor ---
(In reply to Sylvestre Ledru from comment #11)
> Other testcase:
> ---
> #include
> #include
> int main() {
> char* buf = new char[10];
> uint8_t data = 255;
> printf("%.2x\n", data);// just print data
> snprintf(&buf[0], 2, "%.2x", data);
> return 0;
> }
> ---
>
> foo.c:7:13: note: format output 3 bytes into a destination of size 2
> snprintf(&buf[0], 2, "%.2x", data);
> ^~
This is warning is valid. The function is called with a buffer size of 2 bytes
but the total output for 255 in hex ("ff") and the terminating nul would be 3
bytes. The output is truncated after the first 'f' which is usually a bug.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #4 from James Clarke --- Ah, sorry, there's a separate C implementation of all this. I imagine it's the bools in "struct M" in runtime.h messing it up, so "struct Note" and "struct Lock" need __attribute__((aligned(4))) on their key fields.
[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-30 CC||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE on valid code at -O3 on |[7 Regression] ICE on valid |x86_64-linux-gnu: |code at -O3 on |verify_gimple failed|x86_64-linux-gnu: ||verify_gimple failed Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r237064.
[Bug tree-optimization/79284] New: ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284
Bug ID: 79284
Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
verify_gimple failed
Product: gcc
Version: unknown
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: ---
This seems to be a recent regression.
$ 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/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170130 (experimental) [trunk revision 245020] (GCC)
$
$ gcc-trunk -O2 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:8:6: error: type mismatch in binary expression
void fn1 (int p)
^~~
vector(4)
vector(4)
vector(16) unsigned char
mask__5.10_9 = mask__3.9_16 ^ vect_cst__10;
small.c:8:6: internal compiler error: verify_gimple failed
0xc6143f verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5266
0xb35752 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1966
0xb36109 execute_todo
../../gcc-source-trunk/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
-
struct
{
unsigned a:1;
} b;
int c[5];
void fn1 (int p)
{
char e = 4, f;
for (; e; e--)
f = (c[e] && ~0) != b.a;
while (1)
fn1 (f);
}
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #3 from James Clarke --- I believe the problem is in the "m" type in runtime2.go. There are 4 bools in a row, which is fine, as they will take up 4 bytes, but then "printlock" is an int8, which means "fastrand" will only be 2-byte aligned. This continues with "ncgocall" and "ncgo" being 2-byte aligned, and then the "park" field will also be 2-byte aligned only. Is there a way to tell gcngo that the "note" struct (and in theory the "mutex" struct too, since that will be a futex, and I don't know if anything embeds it incorrectly-aligned) should be 4-byte aligned, i.e. an equivalent of __attribute__((aligned(4)))?
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #2 from Ian Lance Taylor --- Perhaps this would be fixed by adding __attribute__((aligned(4))) to some field of struct Sched in proc.c. This code is all different on trunk/GCC7. I don't know whether it still has the same problem or not. Probably it does but the fix would have to be different.
[Bug gcov-profile/79259] [7 Regression] Corrupted profile when one uses -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79259 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed on trunk.
[Bug gcov-profile/79259] [7 Regression] Corrupted profile when one uses -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79259 --- Comment #1 from Martin Liška --- Author: marxin Date: Mon Jan 30 15:35:57 2017 New Revision: 245031 URL: https://gcc.gnu.org/viewcvs?rev=245031&root=gcc&view=rev Log: Fix profile corruption with -O1 (PR gcov-profile/79259) 2017-01-30 Martin Liska PR gcov-profile/79259 * opts.c (common_handle_option): Enable flag_ipa_bit_cp w/ -fprofile-generate. 2017-01-30 Martin Liska PR gcov-profile/79259 * g++.dg/tree-prof/pr79259.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-prof/pr79259.C Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c trunk/gcc/testsuite/ChangeLog
[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012 --- Comment #6 from Bill Schmidt --- (In reply to Iain Sandoe from comment #5) > (In reply to Bill Schmidt from comment #4) > > Created attachment 40568 [details] > > Proposed patch > > > > Attaching proposed patch. Iain, would you be able to test this on Darwin > > 32- and 64-bit and see whether it makes sense? > > On darwin (powerpc-darwin9, trunk 244915) the patch flips the fail from m32 > -> m64. I.E. without the patch m64 passes and m32 fails; with the patch, > the inverse. > > I haven't built powerpc64-darwin9 in quite a while, so no comment there. > > Apologies, but will have defer analysis for a while. Hi Iain, If you get a chance to just send me the vectorization dump file from each of -m32 and -m64, I can figure out why the tests fail for powerpc-darwin9 -m64. My guess from what I'm seeing is that powerpc64-darwin9 will have the same characteristics as powerpc-darwin9 -m64. Thanks, Bill
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 --- Comment #13 from Martin Liška --- Author: marxin Date: Mon Jan 30 15:16:33 2017 New Revision: 245030 URL: https://gcc.gnu.org/viewcvs?rev=245030&root=gcc&view=rev Log: Fix aarch64 PGO bootstrap (bootstrap/78985) 2017-01-30 Martin Liska PR bootstrap/78985 * config/aarch64/cortex-a57-fma-steering.c (func_fma_steering::analyze): Initialize variables with NULL value. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/cortex-a57-fma-steering.c
[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #1 from ktkachov at gcc dot gnu.org --- I think this is a problem with the di3_neon pattern in neon.md and in particular the neon_for_64bits/avoid_neon_for_64bits stuff in the arch attribute. I think the last two alternatives that generate the NEON version should have avoid_neon_for_64bits in their arch attribute rather than neon_for_64bits
[Bug c++/79232] [7 Regression] error: invalid rhs for gimple memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79232 Jakub Jelinek changed: What|Removed |Added Attachment #40607|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 40624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40624&action=edit gcc7-pr79232.patch Fixed up patch with testcases.
[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362 --- Comment #6 from Martin Liška --- Created attachment 40623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40623&action=edit Patch candidate The patch fixes issue, however I believe that PHI handling is in general broken in graphite since r236440. This PR is very similar to PR71351. Both are confused by PHI nodes created by LIM.
[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 --- Comment #9 from Martin Liška --- (In reply to Martin Liška from comment #8) > Started with r236440. Sorry, belongs to a different bug.
[Bug target/79260] [7 Regression] missing header files for plugins: arm-isa.h, arm-flags.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79260 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Earnshaw --- Fixed.
[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351 --- Comment #4 from Martin Liška --- Started with r236440.
[Bug target/79260] [7 Regression] missing header files for plugins: arm-isa.h, arm-flags.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79260 --- Comment #2 from Richard Earnshaw --- Author: rearnsha Date: Mon Jan 30 14:39:50 2017 New Revision: 245029 URL: https://gcc.gnu.org/viewcvs?rev=245029&root=gcc&view=rev Log: PR target/79260 * config.gcc (arm*-*-*): Add arm/arm-flags.h and arm/arm-isa.h to tm_p_file. * arm/arm-protos.h: Don't directly include arm-flags.h and arm-isa.h. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/arm/arm-protos.h
[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- Started with r236440.
[Bug target/79260] [7 Regression] missing header files for plugins: arm-isa.h, arm-flags.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79260 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-30 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Build an arm cross-compiler with --enable-plugin configure the kernel with make ARCH=arm defconfig then manually edit the .config to set CONFIG_GCC_PLUGINS=y then build make ARCH=arm -j all and it will soon fail.
[Bug tree-optimization/79276] [7 Regression] ICE: Segmentation fault in VRP pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79276 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #5 from Bernd Schmidt --- (In reply to Christophe Leroy from comment #0) > The following section is just useless: (shift left 4 bits, remove 16, shift > right 4 bits, add 1) > c000d984: 55 24 20 36 rlwinm r4,r9,4,0,27 > c000d988: 39 24 ff f0 addir9,r4,-16 > c000d98c: 55 29 e1 3e rlwinm r9,r9,28,4,31 > c000d990: 39 29 00 01 addir9,r9,1 Are you suggesting just removing these? That would not produce the same value in all cases - consider zero as an input: ((0 << 4) - 16) >> 4 = 0xfff, add one and you get 0x1000.
[Bug tree-optimization/79276] [7 Regression] ICE: Segmentation fault in VRP pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79276 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Jan 30 14:24:37 2017 New Revision: 245026 URL: https://gcc.gnu.org/viewcvs?rev=245026&root=gcc&view=rev Log: 2017-01-30 Richard Biener PR tree-optimization/79276 * tree-vrp.c (process_assert_insertions): Properly adjust common when removing a duplicate. * gcc.dg/torture/pr79276.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr79276.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230 --- Comment #22 from Dominique d'Humieres --- > > Finally rt_error --check radiation_generator failed with > > > > Running test: radiation_generator_1 > > Program received signal SIGSEGV: Segmentation fault - invalid memory > > reference. > > This, however, seems to be a problem. That segmentation fault seems > to be another problem not yet covered by the fix. The change occurred between revisions r242872 (2016-11-25) and r242901 (2016-11-27, SIGSEGV), r242875 (pr78293)?. I let you reduce the problem and file a new PR.
[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- Started with r232656.
