[Bug c++/82577] [8 Regression] ICE in compare_base_decls, at alias.c:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82577 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-17 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Target Milestone|--- |8.0 Summary|ice in compare_base_decls, |[8 Regression] ICE in |at alias.c:2053 |compare_base_decls, at ||alias.c:2053 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Confirmed, started with r253649.
[Bug tree-optimization/82549] [6/7/8 Regression] ICE at -O1 and above: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82549 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Oct 17 07:38:32 2017 New Revision: 253805 URL: https://gcc.gnu.org/viewcvs?rev=253805&root=gcc&view=rev Log: PR tree-optimization/82549 * fold-const.c (optimize_bit_field_compare, fold_truth_andor_1): Formatting fixes. Instead of calling make_bit_field_ref with negative bitpos return 0. * gcc.c-torture/compile/pr82549.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr82549.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug other/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #3 from Eric Botcazou --- Btw, do the problematic functions have a prototype or are they written in the old-fashioned K&R way?
[Bug c++/82572] throw on line by itself in constexpr function aborts compile even if never reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82572 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini --- Indeed. *** This bug has been marked as a duplicate of bug 80061 ***
[Bug c++/80061] error on constexpr function with an unevaluated throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061 Paolo Carlini changed: What|Removed |Added CC||ekchew at lgl dot kos.net --- Comment #3 from Paolo Carlini --- *** Bug 82572 has been marked as a duplicate of this bug. ***
[Bug c++/82566] Internal compiler error in type deduction (with C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82566 --- Comment #3 from Peter Gottschling --- Ok. Then I give up on 4.9. BTW, I couldn't find a list on the gcc homepage which release is still supported. There were only dates when it was released but not when the maintenance was terminated (just a note that some versions are maintained longer than others (but then again not which)). Google didn't find anything either.
[Bug middle-end/82344] [8 Regression] SPEC CPU2006 435.gromacs ~10% performance regression with trunk@250855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82344 --- Comment #5 from Yulia Koval --- (In reply to Richard Biener from comment #3) > So the newton-raphson step causes register pressure to increase and post > haswell this makes code slower than not using rsqrt (thus using sqrtf and a > division)? > > I wonder whether it would be profitable to SLP vectorize this (of course > we're not considering this because SLP vectorization is looking for stores). > SLP vectorization would need to do 4 (or 8 with avx256) vector inserts > and extracts but then could do the rsqrt and newton raphson together. > The argument computation to the sqrt also loop vectorizable and the ultimate > operands even come from continuous memory. One of the tricky parts would be > to see that the only first rsqrt arg is re-used and thus taking > rinv21 to rinv33 (8 rsqrts) for the vectorization is probably best. > > rinv11 = 1.0/sqrt(rsq11) > rinv21 = 1.0/sqrt(rsq21) > rinv31 = 1.0/sqrt(rsq31) > rinv12 = 1.0/sqrt(rsq12) > rinv22 = 1.0/sqrt(rsq22) > rinv32 = 1.0/sqrt(rsq32) > rinv13 = 1.0/sqrt(rsq13) > rinv23 = 1.0/sqrt(rsq23) > rinv33 = 1.0/sqrt(rsq33) > r11 = rsq11*rinv11 > > What does ICC do to this loop? > > I can confirm the regression on our tester (a Haswell machine btw). ICC generates vrsqrtps in this case.
[Bug c++/82566] Internal compiler error in type deduction (with C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82566 --- Comment #4 from Andrew Pinski --- The gcc front page: https://gcc.gnu.org Has Supported Releases GCC 7.2 (changes) Status: 2017-08-14 (regression fixes & docs only). Serious regressions. All regressions. GCC 6.4 (changes) Status: 2017-07-04 (regression fixes & docs only). Serious regressions. All regressions. Development: GCC 8.0 (release criteria, changes) Status: 2017-04-20 (Stage 1, general development). Serious regressions. All regressions. I don't see how we could make it more clear
[Bug c++/82570] Lambda fails to compile because it doesn't meet constexpr requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82570 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 17 08:38:07 2017 New Revision: 253806 URL: https://gcc.gnu.org/viewcvs?rev=253806&root=gcc&view=rev Log: 2017-10-17 Paolo Carlini PR c++/82570 * g++.dg/cpp1z/constexpr-lambda18.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda18.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/82570] Lambda fails to compile because it doesn't meet constexpr requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82570 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.3 --- Comment #2 from Paolo Carlini --- Fixed for 7.3.0 by the patch which fixed c++/80935.
[Bug tree-optimization/82574] [8 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82574 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from amker at gcc dot gnu.org --- Sorry for disturbing, I will investigate it.
[Bug rtl-optimization/82578] New: Redundant instructions emitted starting with r204212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82578
Bug ID: 82578
Summary: Redundant instructions emitted starting with r204212
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Starting with r204212 (2013-10-30) a redundant thread pointer extract is
emitted.
static __thread int counter;
void gs_handler(void)
{
counter++;
}
compiled with: -O2 -S
2xear with r204211:
gs_handler:
larl%r5,.L2
ear %r1,%a0
sllg%r1,%r1,32
ear %r1,%a1
lg %r2,.L3-.L2(%r5)
l %r3,0(%r1,%r2)
ahi %r3,1
st %r3,0(%r1,%r2)
br %r14
4xear with r204212:
gs_handler:
larl%r5,.L2
ear %r2,%a0
sllg%r2,%r2,32
ear %r1,%a0
ear %r2,%a1
sllg%r1,%r1,32
lg %r3,.L3-.L2(%r5)
ear %r1,%a1
l %r2,0(%r2,%r3)
ahi %r2,1
st %r2,0(%r1,%r3)
br %r14
[Bug c++/67831] Internal error on complicated constexpr initialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67831 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 17 09:06:53 2017 New Revision: 253807 URL: https://gcc.gnu.org/viewcvs?rev=253807&root=gcc&view=rev Log: 2017-10-17 Paolo Carlini PR c++/67831 * g++.dg/cpp0x/constexpr-ice18.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice18.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/67831] Internal error on complicated constexpr initialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67831 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Paolo Carlini --- Fixed for 6.1.0.
[Bug rtl-optimization/82578] Redundant instructions emitted starting with r204212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82578
--- Comment #1 from Andreas Krebbel ---
As expected the rtl dumps are identical up to removed "regmove" pass.
The interesting change is in insn 8. With regmove the value already loaded into
r47 is reused while without regmove it is loaded from a0 again.
First thing I'll check is whether a register_move_cost adjustment fixes this.
r204211 202r.regmove:
(insn 5 2 6 2 (set (reg/f:DI 46)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [3 S8 A64])) t.c:7
63 {*movdi_64}
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("counter") [flags 0x2a] )
] UNSPEC_NTPOFF))
(nil)))
(insn 6 5 7 2 (set (reg/f:DI 47)
(reg:DI 36 %a0)) t.c:7 63 {*movdi_64}
(expr_list:REG_DEAD (reg:DI 36 %a0)
(nil)))
(insn 7 6 8 2 (set (reg/f:DI 48)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [3 S8 A64])) t.c:7
63 {*movdi_64}
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("counter") [flags 0x2a] )
] UNSPEC_NTPOFF))
(nil)))
(insn 8 7 9 2 (set (reg/f:DI 49)
(reg/f:DI 47)) t.c:7 63 {*movdi_64}
(expr_list:REG_DEAD (reg/f:DI 47)
(nil)))
(insn 9 8 0 2 (parallel [
(set (mem/c:SI (plus:DI (reg/f:DI 49)
(reg/f:DI 46)) [2 counter+0 S4 A32])
(plus:SI (mem/c:SI (plus:DI (reg/f:DI 49)
(reg/f:DI 48)) [2 counter+0 S4 A32])
(const_int 1 [0x1])))
(clobber (reg:CC 33 %cc))
]) t.c:7 327 {*addsi3}
(expr_list:REG_DEAD (reg/f:DI 49)
(expr_list:REG_DEAD (reg/f:DI 48)
(expr_list:REG_DEAD (reg/f:DI 46)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil))
r204212 202r.outof_cfglayout:
(insn 5 2 6 2 (set (reg/f:DI 46)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [3 S8 A64])) t.c:7
63 {*movdi_64}
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("counter") [flags 0x2a] )
] UNSPEC_NTPOFF))
(nil)))
(insn 6 5 7 2 (set (reg/f:DI 47)
(reg:DI 36 %a0)) t.c:7 63 {*movdi_64}
(nil))
(insn 7 6 8 2 (set (reg/f:DI 48)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [3 S8 A64])) t.c:7
63 {*movdi_64}
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("counter") [flags 0x2a] )
] UNSPEC_NTPOFF))
(nil)))
(insn 8 7 9 2 (set (reg/f:DI 49)
(reg:DI 36 %a0)) t.c:7 63 {*movdi_64}
(expr_list:REG_DEAD (reg:DI 36 %a0)
(nil)))
(insn 9 8 0 2 (parallel [
(set (mem/c:SI (plus:DI (reg/f:DI 47)
(reg/f:DI 46)) [2 counter+0 S4 A32])
(plus:SI (mem/c:SI (plus:DI (reg/f:DI 49)
(reg/f:DI 48)) [2 counter+0 S4 A32])
(const_int 1 [0x1])))
(clobber (reg:CC 33 %cc))
]) t.c:7 327 {*addsi3}
(expr_list:REG_DEAD (reg/f:DI 49)
(expr_list:REG_DEAD (reg/f:DI 48)
(expr_list:REG_DEAD (reg/f:DI 47)
(expr_list:REG_DEAD (reg/f:DI 46)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)))
[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82478 --- Comment #2 from Corey Tabaka --- From section 11.3.2 of the C++14 draft spec: "Declaring a class to be a friend implies that the names of private and protected members from the class granting friendship can be accessed in the base-specifiers and member declarations of the befriended class." I take "can be accessed in base-specifiers" to mean any expression in the base specifiers of class B is granted access to private and protected members of class A if class A declares class B to be a friend. Do you agree that this is a valid interpretation? Furthermore, regardless of the interpretation above, in the example supplied the class Outer should have friend access to private members of A, and thus the nested definition of Outer::HasPrivate should have valid access to A::PRIVATE. This also fails to compile with a similar error as the top-level example -- clearly this is not the correct behavior.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561 Richard Biener changed: What|Removed |Added Version|unknown |8.0 Target Milestone|--- |8.0
[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Component|middle-end |fortran --- Comment #4 from Richard Biener --- This is value-numbering running into --param sccvn-max-alias-queries-per-access (default 1000). If you shrink this value compile-time gets faster if you increase it it gets slower. And yes, this is because value-numbering of the memory state of the function is quadratic in the number of stores and loads. The FE should apply some more sensible cost model when deciding to "unroll" the array operation. In this case it's code-size prohibitive. The middle-end behaves as designed (limiting itself with respect to compile-time).
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 Richard Biener changed: What|Removed |Added Keywords||wrong-code Component|other |middle-end Target Milestone|--- |8.0
[Bug rtl-optimization/82576] sbitmap_vector_alloc() not ready for 64 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82576 --- Comment #2 from Richard Biener --- No, I think the public API shouldn't change (we don't want to grow simple_bitmap_def unnecessarily). Such big sbitmaps do not make sense.
[Bug target/82442] vect/pr31699.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82442 Wilco changed: What|Removed |Added Status|NEW |RESOLVED CC||wilco at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Wilco --- Fixed
[Bug middle-end/82556] [7/8 Regression] internal compiler error in curr_insn_transform, at lra-constraints.c:4307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82556 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org Known to work||7.2.0 Target Milestone|8.0 |7.3 Summary|[8 Regression] internal |[7/8 Regression] internal |compiler error in |compiler error in |curr_insn_transform, at |curr_insn_transform, at |lra-constraints.c:4307 |lra-constraints.c:4307 Known to fail||7.2.1, 8.0 --- Comment #3 from Richard Biener --- Confirmed on the branch (for the unreduced testcase). GCC 7.2 works. Probably Jakubs pattern changes.
[Bug tree-optimization/82563] [8 Regression] [graphite] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82563 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine. This is because when we build SCOPs we break LC-SSA with /* For our out-of-SSA we need a block on s->entry, similar to how we include the LCSSA block in the region. */ s->entry = single_pred_edge (split_edge (s->entry)); because in this case we split the loop exit edge and we expect the LC SSA PHI node to be in the exit block rather than its single successor.
[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82478 --- Comment #3 from Jonathan Wakely --- The template argument list of ::HasPrivate> is not a base-specifier.
[Bug c++/82579] New: GCC 7/8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82579
Bug ID: 82579
Summary: GCC 7/8
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
The following code fails to compile with GCC 7/8, in C++17 mode (call to f(s)
is ambiguous):
-
template
class C
{};
template
void f(const C&) {}
template class CT>
void f(CT) {}
int main()
{
C s;
f(s);
}
-
However it compiles cleanly in C++14 mode.
This is a stripped case from boost::container::string:
https://github.com/boostorg/container/issues/58
Here
(https://groups.google.com/a/isocpp.org/d/topic/std-discussion/B1MHPRMqfFA/discussion)
we can find a suggestion that this is somehow related to CWG150 resolution by
P0522R0.
Clang accepts this code in both C++14 and C++17 mode, however they state that
CWG150 resolution "is disabled by default in all language versions" because
"the change to the standard lacks a corresponding change for template partial
ordering, resulting in ambiguity errors for reasonable and previously-valid
code" (https://clang.llvm.org/cxx_status.html#p0522).
[Bug c++/80061] error on constexpr function with an unevaluated throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-17 Ever confirmed|0 |1
[Bug c++/77369] incorrect noexcept specification deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77369
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-04-24 00:00:00 |2017-10-17
Known to fail||4.6.4, 4.7.4, 4.8.5, 4.9.4,
||5.4.0, 6.4.0, 7.2.0, 8.0
--- Comment #3 from Jonathan Wakely ---
Another testcase, this time compile-time only:
template int caller(F f) noexcept(noexcept(f())) { f(); return 0; }
void func1() noexcept { }
void func2() { throw 1; }
#ifndef FIXIT
int instantiate_caller_with_func1 = caller(func1);
#endif
static_assert( !noexcept(caller(func2)), "" );
Without FIXIT defined the first instantiation of caller makes use of the fact
that its template argument type is noexcept, but then we use the same
instantiation for the caller(func2):
n.cc:11:1: error: static assertion failed
static_assert( !noexcept(caller(func2)), "" );
^
As Aaron observed, EDG has exactly the same bug. Clang compiles it
successfully.
[Bug rtl-optimization/82578] Redundant instructions emitted starting with r204212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82578 --- Comment #2 from Andreas Krebbel --- I was wondering why CSE doesn't do the right thing here. In fact it would if it would not consider our access registers to be particularly cheap. Access registers are fixed hard regs. Hence, cse considers them to be CHEAP_REGNO's with a cost of 0 making it cheaper than pseudos. Unfortunately it is rather expensive to load an access register into a general purpose reg. Especially if it is a 64 bit value since access regs are only 32bits. Preventing a0 and a1 from being considered cheap ends up with exactly the same code as with the regmove pass. Perhaps CSE should also check register_move_costs when calculating register costs?
[Bug c++/82579] GCC 7/8 ambiguous call to overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82579 --- Comment #1 from Jonathan Wakely --- This is not a GCC bug, because it's the required behaviour for C++17. Use -fno-new-ttp-matching to disable it in C++17 (or use -fnew-ttp-matching to enable it in C++14 and make it ambiguous).
[Bug c++/82579] GCC 7/8 ambiguous call to overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82579 Viktor Ostashevskyi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Viktor Ostashevskyi --- (In reply to Jonathan Wakely from comment #1) > This is not a GCC bug, because it's the required behaviour for C++17. > > Use -fno-new-ttp-matching to disable it in C++17 (or use -fnew-ttp-matching > to enable it in C++14 and make it ambiguous). Huh, thanks for clearing this. Then this is a bug in Boost and maybe Clang.
[Bug c++/82579] GCC 7/8 ambiguous call to overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82579 Viktor Ostashevskyi changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/82580] New: Optimize comparisons for __int128 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Bug ID: 82580
Summary: Optimize comparisons for __int128 on x86-64
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: morwenn29 at hotmail dot fr
Target Milestone: ---
Given the following simple code:
bool foobar(unsigned __int128 lhs, unsigned __int128 rhs) {
return lhs < rhs;
}
GCC generates branchful code for x86-64 at -O3 optimization level:
foobar(unsigned __int128, unsigned __int128):
cmp rsi, rcx
mov eax, 1
jb .L2
jbe .L6
.L3:
xor eax, eax
.L2:
rep ret
.L6:
cmp rdi, rdx
jnb .L3
rep ret
On the other hand, Clang is able to generate branchless code with just a few
instructions at the same optimization level:
foobar(unsigned __int128, unsigned __int128): # @foobar(unsigned __int128,
unsigned __int128)
cmp rdi, rdx
sbb rsi, rcx
setb al
ret
The codegen results are equivalent for the other comparison instructions. Would
it be possible to optimize these comparison instructions the same way for GCC?
[Bug tree-optimization/82563] [8 Regression] [graphite] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82563 --- Comment #2 from Richard Biener --- Author: rguenth Date: Tue Oct 17 13:17:30 2017 New Revision: 253809 URL: https://gcc.gnu.org/viewcvs?rev=253809&root=gcc&view=rev Log: 2017-10-17 Richard Biener PR tree-optimization/82563 * graphite-isl-ast-to-gimple.c (generate_entry_out_of_ssa_copies): New function. (graphite_regenerate_ast_isl): Call it. * graphite-scop-detection.c (build_scops): Remove entry edge split. * gcc.dg/graphite/pr82563.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr82563.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-isl-ast-to-gimple.c trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/71026] Missing division optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026 --- Comment #7 from Wilco --- Author: wilco Date: Tue Oct 17 13:22:48 2017 New Revision: 253812 URL: https://gcc.gnu.org/viewcvs?rev=253812&root=gcc&view=rev Log: Factor out division by squares and remove division around comparisons (0/2) Commit gcc/fold-const.c missing from r252827: gcc/ PR 71026/tree-optimization * fold-const.c (distribute_real_division): Removed. (fold_binary_loc): Remove calls to distribute_real_divison. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug ada/82573] GNAT.Registry doesn't read/write with HKEY_LOCAL_MACHINE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82573 --- Comment #2 from Jerry Hudson --- I was confused by what you meant by "classpath." The earlier revision by Andrew Pinski better describes the problem, but I don't recall seeing that option on the form. Forgive me, this is the first bug report for me. (I have used Gnu products quite a bit, and bugs are RARE.) - Jerry Hudson On 10/17/2017 2:03 AM, gnu_andrew at member dot fsf.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82573 > > Andrew John Hughes changed: > > What|Removed |Added > > CC||gnu_andrew at member dot > fsf.org > > --- Comment #1 from Andrew John Hughes --- > This doesn't seem to be related to GNU Classpath. >
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #4 from seurer at gcc dot gnu.org --- extern void gl_write_texture_span( GLcontext *ctx, GLuint n, GLint x, GLint y, GLdepth z[], GLfloat s[], GLfloat t[], GLfloat u[], GLfloat lambda[], GLubyte red[], GLubyte green[], GLubyte blue[], GLubyte alpha[], GLenum primitive );
[Bug middle-end/82577] [8 Regression] ICE in compare_base_decls, at alias.c:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82577 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #11 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 17 14:16:35 2017 New Revision: 253814 URL: https://gcc.gnu.org/viewcvs?rev=253814&root=gcc&view=rev Log: gcc/ChangeLog 2017-10-17 Qing Zhao Wilco Dijkstra * builtins.c (expand_builtin_update_setjmp_buf): Add a converstion to Pmode from the buf_addr. gcc/testsuite/ChangeLog 2017-10-17 Qing Zhao Wilco Dijkstra PR middle-end/80295 * gcc.target/aarch64/pr80295.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr80295.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c
[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #12 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 17 14:17:17 2017 New Revision: 253815 URL: https://gcc.gnu.org/viewcvs?rev=253815&root=gcc&view=rev Log: gcc/ChangeLog 2017-10-17 Qing Zhao Wilco Dijkstra * builtins.c (expand_builtin_update_setjmp_buf): Add a converstion to Pmode from the buf_addr. gcc/testsuite/ChangeLog 2017-10-17 Qing Zhao Wilco Dijkstra PR middle-end/80295 * gcc.target/aarch64/pr80295.c: New test. Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/80295] [7 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 Paolo Carlini changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |__builtin_update_setjmp_buf |__builtin_update_setjmp_buf |expander|expander --- Comment #13 from Paolo Carlini --- Fixed in trunk for the time being.
[Bug c++/77369] incorrect noexcept specification deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77369 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/82549] [6/7 Regression] ICE at -O1 and above: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82549 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Oct 17 14:47:15 2017 New Revision: 253816 URL: https://gcc.gnu.org/viewcvs?rev=253816&root=gcc&view=rev Log: PR tree-optimization/82549 * fold-const.c (optimize_bit_field_compare, fold_truth_andor_1): Formatting fixes. Instead of calling make_bit_field_ref with negative bitpos return 0. * gcc.c-torture/compile/pr82549.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/compile/pr82549.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/82546] tree_size handling for TYPE nodes is confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82546 --- Comment #1 from Nathan Sidwell --- Author: nathan Date: Tue Oct 17 14:49:05 2017 New Revision: 253817 URL: https://gcc.gnu.org/viewcvs?rev=253817&root=gcc&view=rev Log: [PATCH PR/82546] tree node size https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00899.html PR middle-end/82546 gcc/ * tree.c (tree_code_size): Reformat. Punt to lang hook for unknown TYPE nodes. gcc/cp/ * cp-objcp-common.c (cp_tree_size): Reformat. Adjust returns size of TYPE nodes. gcc/objc/ * objc-act.c (objc_common_tree_size): Return size of TYPE nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/tree.c
[Bug tree-optimization/82549] [6/7 Regression] ICE at -O1 and above: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82549 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Oct 17 14:53:13 2017 New Revision: 253818 URL: https://gcc.gnu.org/viewcvs?rev=253818&root=gcc&view=rev Log: PR tree-optimization/82549 * fold-const.c (optimize_bit_field_compare, fold_truth_andor_1): Formatting fixes. Instead of calling make_bit_field_ref with negative bitpos return 0. * gcc.c-torture/compile/pr82549.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/pr82549.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/fold-const.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/82581] New: missing -Warray-bounds on writing past the end of a member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82581
Bug ID: 82581
Summary: missing -Warray-bounds on writing past the end of a
member array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When the bounds of a member array are exceeded in a loop that accesses the
member directly by its name, GCC issues a -Waggressive-loop-optimizations
warning mentioning the iteration of the loop in which the undefined behavior
occurs. But when the same access takes place indirectly through a pointer to
the member, no diagnostic is issued. Since the number of iterations of the
loop is known I would expect a -Warray-bounds warning (ideally in both cases,
even when no aggressive loop optimizations are performed).
As an aside, since the first iteration of a loop is usually thought of as
iteration 1 (not iteration zero), the iteration number referenced in the
-Waggressive-loop-optimizations warning is off by one. Since the array has
three elements, iteration 3 writes into the last (third) element, and it's
iteration four that has undefined behavior.
$ cat a.c && gcc -O2 -S -Wall -Warray-bounds -Wextra a.c
struct S
{
int a[3];
void (*pf)(void);
} x;
void f (void)
{
for (unsigned i = 0; i != sizeof x; ++i) // -Waggressive-loop-optimizations
x.a[i] = i;
}
void g (void)
{
int *p = x.a;
for (unsigned i = 0; i != sizeof x; ++i)
p[i] = i;// missing -Warray-bounds
}
a.c: In function ‘f’:
a.c:10:12: warning: iteration 3 invokes undefined behavior
[-Waggressive-loop-optimizations]
x.a[i] = i;
~~~^~~
a.c:9:3: note: within this loop
for (unsigned i = 0; i != sizeof x; ++i)
^~~
[Bug tree-optimization/80907] [6/7/8 Regression] False positive: "warning: array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80907
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.4
Last reconfirmed||2017-10-17
Component|c++ |tree-optimization
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Summary|False positive: "warning: |[6/7/8 Regression] False
|array subscript is above|positive: "warning: array
|array bounds" |subscript is above array
||bounds"
Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
||7.1.0, 8.0
--- Comment #1 from Martin Sebor ---
Confirmed. I see the same warning issued twice. The first revision to trigger
the warning is r192538 (gcc 4.8.0), thus marking this a regression.
$ cat a.c && gcc -O3 -S -Wall -Warray-bounds a.c
int x[3];
int n=2;
void foo()
{
for(int i=0;i
[Bug middle-end/82286] [6/7/8 Regression] Wrong array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82286 Martin Sebor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80907 Summary|Wrong array subscript is|[6/7/8 Regression] Wrong |above array bounds |array subscript is above ||array bounds --- Comment #5 from Martin Sebor --- The first revision to trigger the warning is r192538 (gcc 4.8.0), thus marking this a regression. (See also bug 80907 which is also caused by the same revision.)
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-17 CC||hubicka at gcc dot gnu.org, ||msebor at gcc dot gnu.org Known to work||4.7.4 Summary|Bogus warning with -O3 |[6/7/8 Regression] Bogus |-Warray-bounds: array |warning with -O3 |subscript is above array|-Warray-bounds: array |bounds |subscript is above array ||bounds Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0, ||7.1.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed. The first revision to trigger the error is r192990 (gcc 4.8.0) so marking this a regression.
[Bug middle-end/63441] incorrect "array subscript is below/above array bounds" diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- I still see the warning with today's top of trunk (GCC 4.8) but I agree that some sort of a diagnostic here seems helpful. It would be nice if the warning could distinguish between cases where the index definitely is out of bounds and those where it could be but it's not 100% certain. I haven't looked at the implementation to see if this is feasible. It would also be helpful to have clarity (both for users and GCC developers) on what diagnostics are meant to be issued under what circumstances. Based on some other warnings (-Wuninitialized and -Wmaybe-uninitialized) it seems reasonable to expect -Warray-bounds to only be issued when an index is definitely out of bounds (and not when it could be).
[Bug tree-optimization/82549] [6/7 Regression] ICE at -O1 and above: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82549 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 6.5+, 7.3+ and 8+.
[Bug middle-end/82577] [8 Regression] ICE in compare_base_decls, at alias.c:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82577 --- Comment #4 from Nathan Sidwell --- Author: nathan Date: Tue Oct 17 15:42:19 2017 New Revision: 253819 URL: https://gcc.gnu.org/viewcvs?rev=253819&root=gcc&view=rev Log: [PATCH, middle-end/82577] Fix DECL_ASSEMBLER_NAME ICE https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01067.html gcc/ PR middle-end/82577 * alias.c (compare_base_decls): Check HAS_DECL_ASSEMBLER_NAME_P, use DECL_ASSEMBLER_NAME_RAW. gcc/testsuite/ PR middle-end/82577 * g++.dg/opt/pr82577.C: New. Added: trunk/gcc/testsuite/g++.dg/opt/pr82577.C Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/82577] [8 Regression] ICE in compare_base_decls, at alias.c:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82577 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Fixed r253819.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 --- Comment #4 from Nathan Sidwell --- Author: nathan Date: Tue Oct 17 15:52:21 2017 New Revision: 253820 URL: https://gcc.gnu.org/viewcvs?rev=253820&root=gcc&view=rev Log: [C++ PATCH 82560] missing dtor call https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01068.html PR c++/82560 * call.c (build_over_call): Don't pass tf_no_cleanup to nested calls. PR c++/82560 * g++.dg/cpp0x/pr82560.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr82560.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Fixed r253820.
[Bug target/82582] New: not quite optimal code for -2*x*y - 3*z: could use one less LEA for smaller code without increasing critical path latency for any input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82582
Bug ID: 82582
Summary: not quite optimal code for -2*x*y - 3*z: could use one
less LEA for smaller code without increasing critical
path latency for any input
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
int foo32(int x, int y, int z) {
return -2*x*y - 3*z;
}
gcc8.0.0 20171015 -O3 https://godbolt.org/g/tzBuHx
imull %esi, %edi# x*y
leal0(,%rdx,4), %eax# needs a disp32 = 0
subl%eax, %edx# -3*z
negl%edi # -(x*y)
leal(%rdx,%rdi,2), %eax # result
LEA runs on limited ports, and an index with no base needs a 4-byte disp32 = 0.
The critical-path latencies, assuming 2-operand imul is 3 cycles like on Intel:
x->res: imul, neg, lea = 5c
y->res: imul, neg, lea = 5c
z->res: lea, sub, lea = 3c
This is better than gcc6.3 / gcc7.2 (which uses 3 LEA and is generally worse).
It's also different from gcc4/gcc5 (6c from x to result, but only 2c from z to
result, so it's different but not worse or better in all cases).
clang5.0 does better: same latencies, smaller code size, and trades one LEA for
an ADD:
imull %esi, %edi
addl%edi, %edi
leal(%rdx,%rdx,2), %eax
negl%eax
subl%edi, %eax
x->res: imul, add, sub = 5c
y->res: imul, add, sub = 5c
z->res: lea, neg, sub = 3c
related: poor code-gen for 32-bit code with this. I haven't checked other
32-bit architectures.
long long foo64(int x, int y, int z) {
return -2LL*x*(long long)y - 3LL*(long long)z;
}
// also on the godbolt link
gcc -m32 uses a 3-operand imul-immediate for `-2`, but some clunky shifting for
`-3`. There's also a mull in there.
clang5.0 -m32 makes very nice code, using a one-operand imul for -3 and just
shld/add + sub/sbb (plus some mov instructions). One-operand mul/imul is 3
uops on Intel with 2 clock throughput, but ADC is 2 uops on Intel
pre-Broadwell, so it's nice to avoid that.
related: add %esi,%esi / sbb %edi,%edi is an interesting way to sign-extend a
32-bit input into a pair of registers while doubling it. However, if it starts
in eax, cltd / add %eax,%eax is much better. (sbb same,same is only
recognized as dep-breaking on AMD Bulldozer-family and Ryzen. On Intel it has
a false dep on the old value of the register, not just CF).
[Bug tree-optimization/82583] New: missing -Warray-bounds on out-of-bounds inner indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583
Bug ID: 82583
Summary: missing -Warray-bounds on out-of-bounds inner indices
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Warray-bounds warning seems to only check the innermost array index but it
doesn't check any of intervening ones. This can be seen in the test case below
where the out-of-bounds index in 'p->a[1].a[4]' in f() is detected but the
similarly out-of-bounds index in 'p->a[2]' is not.
$ cat a.c && gcc -O3 -S -Wall -Warray-bounds a.c
struct A { int a[4]; int i; };
struct B { struct A a[2]; int i; };
void f (struct B *p)
{
p->a[1].a[4] = 1; // -Warray-bounds (good)
}
void g (struct B *p)
{
p->a[2].a[3] = 1; // missing -Warray-bounds
}
a.c: In function ‘f’:
a.c:6:12: warning: array subscript is above array bounds [-Warray-bounds]
p->a[1].a[4] = 1; // -Warray-bounds (good)
~^~~
[Bug middle-end/47418] warning: array subscript is above array bounds at O2 with sin6_addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED Known to fail||7.2.0, 8.0 --- Comment #5 from Martin Sebor --- No warnings with recent versions. Given that resolving as fixed (also as per comment #4).
[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 47418, which changed state. Bug 47418 Summary: warning: array subscript is above array bounds at O2 with sin6_addr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 45180, which changed state. Bug 45180 Summary: bogus warning: array subscript is above array bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45180 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/45180] bogus warning: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45180 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||5.4.0, 6.4.0, 7.1.0, 8.0 Resolution|--- |FIXED Known to fail||4.8.3, 4.9.3 --- Comment #4 from Martin Sebor --- The test case doesn't trigger a warning with recent GCC. Bisection points to r220157 (gcc 5.0.0) as the fix. Thus resolving as fixed.
[Bug libstdc++/82584] New: div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584
Bug ID: 82584
Summary: div by zero in random distribution
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 42384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42384&action=edit
compile with -fsanitize=float-divide-by-zero
the attached program, when using ubsan generates:
/data/users/nathans/trunk/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/random.tcc:88:25:
runtime error: division by zero
line 88 is:
*__result = *__first / __factor;
and both *__first and __factor are zero. We end up at:
0x0040314c <+171>: movsd -0x40(%rbp),%xmm0
0x00403151 <+176>: divsd -0x38(%rbp),%xmm0
0x00403156 <+181>: movsd %xmm0,-0x38(%rbp)
where both the operands are zero
Not sure if this is user error in that feeding vector{0,0} to
discrete_distribution is valid or not.
[Bug tree-optimization/38480] bogus warning with -O3 -Wall: "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38480 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||7.2.0, 8.0 Resolution|--- |FIXED Known to fail||4.9.4, 5.4.0, 6.3.0 --- Comment #3 from Martin Sebor --- There is no warning since r239421 (gcc 7.0.0) and function f() is optimized into a no-op, so resolving as fixed.
[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 38480, which changed state. Bug 38480 Summary: bogus warning with -O3 -Wall: "array subscript is above array bounds" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38480 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/52504] (unreachable) out of bounds access in thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52504 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |WAITING Last reconfirmed|2013-02-25 00:00:00 |2017-10-17 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- It's been a few years since this report was opened. Can you please check with a recent version of GCC whether the warning still occurs? If it does, can in addition reduce it to a small test case and include it in your comment?
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 --- Comment #1 from Nathan Sidwell --- The make_unique bit's irrelevant: std::discrete_distribution X (weights.begin(), weights.end()); is sufficient. Reading 29.6.8.6.1 suggests the code is well formed, but all (two) probabilites are zero
[Bug middle-end/82556] [7/8 Regression] internal compiler error in curr_insn_transform, at lra-constraints.c:4307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82556 --- Comment #4 from Vladimir Makarov --- (In reply to Richard Biener from comment #3) > Confirmed on the branch (for the unreduced testcase). GCC 7.2 works. > > Probably Jakubs pattern changes. It is an unusual pattern for LRA. I guess it should be fixed in LRA. I'll investigate the problem and try to find a fix in LRA.
[Bug fortran/82550] program using submodules fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82550 --- Comment #2 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > Confirmed from 6.4 up to trunk (8.0). Adding a reference to 'p' in 'foo' clears the problem. module subroutine foo(fun_ptr) procedure(p), pointer, intent(out) :: fun_ptr call p() fun_ptr => p end subroutine I rather think that the pointer assignment is not setting 'p' as referenced. Investigating. Paul
[Bug middle-end/82546] tree_size handling for TYPE nodes is confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82546 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-17 Ever confirmed|0 |1
[Bug tree-optimization/82585] New: missing -Warray-bounds calling strlen on a member at out-of-bounds offfset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82585
Bug ID: 82585
Summary: missing -Warray-bounds calling strlen on a member at
out-of-bounds offfset
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following test case should trigger two instances of -Warray-bounds, one in
each function, but it only triggers one.
$ cat a.c && gcc -O2 -S -Wall -Warray-bounds a.c
struct A { char a[3]; int i; };
extern char a[3];
int f1 (void)
{
return __builtin_strlen (a + 4); // -Warray-bounds (good)
}
int f2 (struct A *p)
{
return __builtin_strlen (p->a + 4); // missing -Warray-bounds
}
a.c: In function ‘f1’:
a.c:7:10: warning: array subscript is above array bounds [-Warray-bounds]
return __builtin_strlen (a + 4); // -Warray-bounds (good)
^~~~
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 --- Comment #7 from Nathan Sidwell --- Fixed on gcc-7 branch r253822.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 --- Comment #6 from Nathan Sidwell --- Author: nathan Date: Tue Oct 17 17:27:11 2017 New Revision: 253822 URL: https://gcc.gnu.org/viewcvs?rev=253822&root=gcc&view=rev Log: [C++ PATCH 82560] missing dtor call https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01068.html PR c++/82560 * call.c (build_over_call): Don't pass tf_no_cleanup to nested calls. PR c++/82560 * g++.dg/cpp0x/pr82560.C: New. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/pr82560.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/call.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/82586] New: ICE: write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 Bug ID: 82586 Summary: ICE: write_symbol(): bad module symbol Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- I recently did some tests with the very new PDT feature to generate some tiny, disruptive test cases : $ cat z1.f90 module m type t(a) end type end $ gfortran-8-20171015 -c z1.f90 f951: internal compiler error: write_symbol(): bad module symbol 'a' 0x68da6f gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1349 0x6ca032 write_symbol ../../gcc/fortran/module.c:5612 0x6ca07b write_symbol1_recursion ../../gcc/fortran/module.c:5839 0x6cce75 write_symbol1 ../../gcc/fortran/module.c:5872 0x6cce75 write_module ../../gcc/fortran/module.c:6016 0x6cce75 dump_module ../../gcc/fortran/module.c:6143 0x6cd0fd gfc_dump_module(char const*, int) ../../gcc/fortran/module.c:6200 0x6e6a56 gfc_parse_file() ../../gcc/fortran/parse.c:6241 0x72a6bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/82586] ICE: write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 --- Comment #1 from G. Steinmetz --- Other invalid snippets : $ cat z2.f90 program p type t(a integer, kind :: a real(a) :: x end type end $ cat z3.f90 program p type t(a, a) integer, kind :: a integer, len :: a end type end $ gfortran-8-20171015 -c z2.f90 f951: internal compiler error: Segmentation fault 0xb5a08f crash_signal ../../gcc/toplev.c:326 0x66322b delete_root ../../gcc/fortran/bbt.c:150 0x6633fe gfc_delete_bbt(void*, void*, int (*)(void*, void*)) ../../gcc/fortran/bbt.c:197 0x71b008 gfc_delete_symtree(gfc_symtree**, char const*) ../../gcc/fortran/symbol.c:2829 0x71c786 gfc_restore_last_undo_checkpoint() ../../gcc/fortran/symbol.c:3598 0x6db9d7 reject_statement ../../gcc/fortran/parse.c:2546 0x6dbaec match_word_omp_simd ../../gcc/fortran/parse.c:98 0x6dfadb match_word ../../gcc/fortran/parse.c:565 0x6dfadb decode_statement ../../gcc/fortran/parse.c:565 0x6e0fb4 next_free ../../gcc/fortran/parse.c:1225 0x6e0fb4 next_statement ../../gcc/fortran/parse.c:1457 0x6e2ddc parse_spec ../../gcc/fortran/parse.c:3648 0x6e4d93 parse_progunit ../../gcc/fortran/parse.c:5634 0x6e6354 gfc_parse_file() ../../gcc/fortran/parse.c:6174 0x72a6bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/82586] ICE: write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-17 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed on trunk (8.0).
[Bug c/81404] suggested hints for standard C macros should avoid GCC predefined macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81404 --- Comment #5 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01083.html
[Bug fortran/82587] New: ICE in get_pdt_constructor, at fortran/resolve.c:1185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82587 Bug ID: 82587 Summary: ICE in get_pdt_constructor, at fortran/resolve.c:1185 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Another piece of invalid code : $ cat z1.f90 program p type t(a) integer(kind=t()) :: x end type end $ gfortran-8-20171015 -c z1.f90 f951: internal compiler error: in get_pdt_constructor, at fortran/resolve.c:1185 0x6ed6e5 get_pdt_constructor ../../gcc/fortran/resolve.c:1185 0x7037be resolve_structure_cons ../../gcc/fortran/resolve.c:1247 0x6f31ba resolve_generic_f ../../gcc/fortran/resolve.c:2697 0x6f31ba resolve_function ../../gcc/fortran/resolve.c:3120 0x6f350a gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6608 0x6916ef gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:2696 0x6940d1 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:2744 0x679605 gfc_match_kind_spec(gfc_typespec*, bool) ../../gcc/fortran/decl.c:2710 0x67faa2 gfc_match_decl_type_spec(gfc_typespec*, int) ../../gcc/fortran/decl.c:4053 0x68115c gfc_match_data_decl() ../../gcc/fortran/decl.c:5605 0x6dbac9 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x6df17e match_word ../../gcc/fortran/parse.c:376 0x6df17e decode_statement ../../gcc/fortran/parse.c:376 0x6e0fb4 next_free ../../gcc/fortran/parse.c:1225 0x6e0fb4 next_statement ../../gcc/fortran/parse.c:1457 0x6e252d parse_derived ../../gcc/fortran/parse.c:3252 0x6e252d parse_spec ../../gcc/fortran/parse.c:3792 0x6e4d93 parse_progunit ../../gcc/fortran/parse.c:5634 0x6e6354 gfc_parse_file() ../../gcc/fortran/parse.c:6174 0x72a6bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug tree-optimization/82588] New: missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588
Bug ID: 82588
Summary: missing -Warray-bounds on a excessively large index
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC fails to issue a -Warray-bounds warning for indices so large that they
cannot be valid even for the largest objects.
In function f0() below, GCC recognizes that the signed distance between the
beginning of the array and the end pointer cannot be positive and transforms
the function into an unconditional call to abort, but it doesn't issue any sort
of a diagnostic. -Warray-bounds would seem to be appropriate here. Likewise
in function f1().
Similarly in function f2(), the size of the member array cannot be half the
address space because it would leave no room for the remaining members of the
same struct. So again, -Warray-bounds could be issued for this pathological
case. The comment in check_array_ref that reads "Can not check flexible
arrays." indicates the absence of checking for flexible array members is
intentional, but it can be tightened up to detect these boundary conditions.
$ cat a.c && gcc -O2 -S -Wall -Warray-bounds -fdump-tree-optimized=/dev/stdout
a.c
struct A { int n; char a[]; };
void f0 (void)
{
extern int a[];
int *e = a + __SIZE_MAX__ / sizeof (int) + 1; // missing warning
if (e - a <= 0)
__builtin_abort ();
}
int f1 (void)
{
extern int a[];
return a[__SIZE_MAX__ / sizeof (int) + 1]; // missing -Warray-bounds
}
int f2 (struct A *a)
{
return a->a[__SIZE_MAX__ / 2]; // missing -Warray-bounds
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1834, cgraph_uid=0, symbol_order=0)
(unlikely executed)
f0 ()
{
[100.00%] [count: 0]:
__builtin_abort ();
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1840, cgraph_uid=1, symbol_order=1)
f1 ()
{
int _2;
[100.00%] [count: INV]:
_2 = a[4611686018427387904];
return _2;
}
;; Function f2 (f2, funcdef_no=2, decl_uid=1845, cgraph_uid=2, symbol_order=2)
f2 (struct A * a)
{
char _1;
int _4;
[100.00%] [count: INV]:
_1 = a_3(D)->a[9223372036854775807];
_4 = (int) _1;
return _4;
}
[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68325 --- Comment #1 from Martin Sebor --- See also bug 68325 for a similar report of -Warray-bounds failing to detect negative indices into flexible array members.
[Bug fortran/82589] New: ICE in gfc_get_pdt_instance, at fortran/decl.c:3278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82589 Bug ID: 82589 Summary: ICE in gfc_get_pdt_instance, at fortran/decl.c:3278 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- A combination of type-param-attr-spec LEN or KIND with another attribute like PRIVATE conflicts with f2008 4.5.3.1 : $ cat z1.f90 module m type t(a) integer, len, private :: a end type end program p use m type(t(a=:)), allocatable :: x print *, x end $ gfortran-8-20171015 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb5a08f crash_signal ../../gcc/toplev.c:326 0x67a008 gfc_get_pdt_instance(gfc_actual_arglist*, gfc_symbol**, gfc_actual_arglist**) ../../gcc/fortran/decl.c:3278 0x680221 gfc_match_decl_type_spec(gfc_typespec*, int) ../../gcc/fortran/decl.c:3787 0x68115c gfc_match_data_decl() ../../gcc/fortran/decl.c:5605 0x6dbac9 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x6df17e match_word ../../gcc/fortran/parse.c:376 0x6df17e decode_statement ../../gcc/fortran/parse.c:376 0x6e0fb4 next_free ../../gcc/fortran/parse.c:1225 0x6e0fb4 next_statement ../../gcc/fortran/parse.c:1457 0x6e289c parse_spec ../../gcc/fortran/parse.c:3831 0x6e4d93 parse_progunit ../../gcc/fortran/parse.c:5634 0x6e6354 gfc_parse_file() ../../gcc/fortran/parse.c:6174 0x72a6bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/82589] ICE in gfc_get_pdt_instance, at fortran/decl.c:3278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82589 --- Comment #1 from G. Steinmetz --- These variants are processed without any complaints : $ cat z2.f90 module m type t(a) integer, len, private :: a end type end program p use m type(t(:)), allocatable :: x print *, x end $ cat z3.f90 module m type t(a) integer, len, private :: a end type end program p use m type(t(2)) :: x print *, x end $ gfortran-8-20171015 -g -O0 -Wall -Wextra -c z2.f90 $ gfortran-8-20171015 -g -O0 -Wall -Wextra -c z3.f90 $
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #9 from Ben Longbons --- The ones I've filed are: #54533, #58150, #80466 But there are quite a few more at https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=debug&list_id=190134&product=gcc
[Bug libstdc++/82554] uniform_real_distribution can generate the upper endpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82554 --- Comment #3 from Ben Longbons --- There is DR2524 for the [0, 1) case. Otherwise, filing bugs there looks really complicated. I've given you a reproducer. That's as much as I'm capable of.
[Bug fortran/82586] ICE: write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82586 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Thanks - they are now on the todo list :-) Paul
[Bug other/82590] New: auto-host.h error: declaration does not declare anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82590 Bug ID: 82590 Summary: auto-host.h error: declaration does not declare anything Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bastl at eclipso dot de Target Milestone: --- Compiling GCC-7.2.0 with: gcc (GCC) 6.3.0 libtool (GNU libtool) 2.4.6 GNU Make 4.2.1 GNU ld (GNU Binutils) 2.29 GNU Awk 4.1.4 perl 5, version 26, subversion 0 (v5.26.0) bison (GNU Bison) 3.0.4 ldd (GNU libc) 2.26 GNU bash, version 4.4.12(2)-release on and for: i686-pc-linux-gnu breaks with this error (./gcc): checking for strings.h... yes checking for inttypes.h... In file included from /usr/include/stdlib.h:707:0, from /mnt/usb6/prog/7.91_gcc-7/gcc-7.2.0/./gcc/system.h:258, from /mnt/usb6/prog/7.91_gcc-7/gcc-7.2.0/./gcc/genhooks.c:21: /usr/include/bits/stdlib-bsearch.h: In function 'void* bsearch(const void*, const void*, size_t, size_t, __compar_fn_t)': /usr/include/bits/stdlib-bsearch.h:32:65: warning: cast from type 'const char*' to type 'void*' casts away qualifiers [-Wcast-qual] __p = (void *) (((const char *) __base) + (__idx * __size)); ^ /usr/include/bits/stdlib-bsearch.h:39:18: warning: cast from type 'const void*' to type 'void*' casts away qualifiers [-Wcast-qual] return (void *) __p; ^~~ In file included from /usr/include/bits/fcntl.h:61:0, from /usr/include/fcntl.h:35, from /mnt/usb6/prog/7.91_gcc-7/gcc-7.2.0/./gcc/system.h:349, from /mnt/usb6/prog/7.91_gcc-7/gcc-7.2.0/./gcc/genhooks.c:21: /usr/include/bits/fcntl-linux.h: At global scope: /usr/include/bits/fcntl-linux.h:330:27: warning: ISO C++ forbids zero-size array 'f_handle' [-Wpedantic] unsigned char f_handle[0]; ^ In file included from ./bconfig.h:3:0, from /mnt/usb6/prog/7.91_gcc-7/gcc-7.2.0/./gcc/genhooks.c:20: ./auto-host.h:2357:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long ^ /usr/include/bits/resource.h:133:20: note: in expansion of macro 'rlim_t' typedef __rlim64_t rlim_t;
[Bug tree-optimization/82591] New: [8 Regression] [graphite] Compile-time hog w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82591
Bug ID: 82591
Summary: [8 Regression] [graphite] Compile-time hog w/ -O2
-floop-nest-optimize
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171015 snapshot (r253772) takes about 25 s to compile the
following snippet w/ -O2 -floop-nest-optimize on my machine:
unsigned int dd;
unsigned int
hi (unsigned int s1, int w0, int ym, unsigned short int oy)
{
int *v1;
if (w0 == 0)
v1 = &w0;
else
{
int *fr;
v1 = &ym;
for (w0 = 0; w0 < 128; ++w0)
{
int r8;
for (r8 = 0; r8 < 3; ++r8)
{
fr = (int *)ⅆ
oy -= 0x201;
s1 = oy <= 1;
ym += dd;
if (s1 != 0)
{
int x8;
*fr = 0;
x8 = ym / *fr;
}
}
}
}
if (s1 == (((*v1 != 0) ? s1 : 0) - (1 / 0)))
s1 = 0;
return s1;
}
% time gcc-8.0.0-alpha20171015 -O2 -floop-nest-optimize -w -c yaqk7feq.c
gcc-8.0.0-alpha20171015 -O2 -floop-nest-optimize -w -c yaqk7feq.c 21.80s user
0.02s system 92% cpu 23.709 total
On this machine I have gmp 6.1.2 and isl 0.18 installed.
9.37% libgmp.so.10.3.2 [.] __gmpz_divexact
9.16% libgmp.so.10.3.2 [.] __gmpz_mul
8.06% libisl.so.15.3.0 [.] isl_tab_pivot
7.62% libgmp.so.10.3.2 [.] __gmpz_aorsmul_1
7.59% libgmp.so.10.3.2 [.] __gmpn_gcd_1
5.28% libgmp.so.10.3.2 [.] __gmpn_modexact_1_odd
5.17% libgmp.so.10.3.2 [.] __gmpn_divexact_1
4.51% libgmp.so.10.3.2 [.] __gmpz_cmpabs
4.27% libgmp.so.10.3.2 [.] __gmpn_mul_1
4.26% libgmp.so.10.3.2 [.] __gmpz_gcd
2.75% libgmp.so.10.3.2 [.] __gmpn_divexact
2.66% libisl.so.15.3.0 [.] isl_seq_gcd
2.53% libisl.so.15.3.0 [.] isl_seq_abs_min_non_zero
2.05% libgmp.so.10.3.2 [.] __gmpz_cmp_ui
1.91% libgmp.so.10.3.2 [.] __gmpz_addmul
1.31% libgmp.so.10.3.2 [.] __gmpn_gcd
1.25% libgmp.so.10.3.2 [.] __gmpn_copyi
1.04% libisl.so.15.3.0 [.] isl_seq_scale_down
0.91% libgmp.so.10.3.2 [.] __gmpn_submul_1
0.77% libisl.so.15.3.0 [.] isl_tab_var_from_row
0.69% libgmp.so.10.3.2 [.] __gmpz_set
0.64% libisl.so.15.3.0 [.] isl_tab_row_is_redundant
0.50% libgmp.so.10.3.2 [.] 0x0005a3fd
0.42% libgmp.so.10.3.2 [.] __gmpn_addmul_1
0.39% libgmp.so.10.3.2 [.] 0x0005a3f0
0.38% libgmp.so.10.3.2 [.] 0x0005a5e3
0.35% libgmp.so.10.3.2 [.] __gmpn_divexact@plt
0.35% libgmp.so.10.3.2 [.] __gmpn_rshift
0.32% libgmp.so.10.3.2 [.] 0x0005a254
0.32% libc-2.25.so [.] _int_malloc
0.31% libisl.so.15.3.0 [.] isl_seq_normalize
0.30% libisl.so.15.3.0 [.] isl_seq_combine
[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64611 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #7 from Paolo Carlini --- Fixed looong time ago, in 5.1.0.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #5 from seurer at gcc dot gnu.org --- Created attachment 42385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42385&action=edit test case that shows the problem This is a cut down single function test case that shows the problem. I tried cutting out more but it changed how the code was generated too much to show the issue. Compile it with a powerpc compiler built with -mcpu=power6 or power6x ~/gcc/install/gcc-test2/bin/gcc -O3 -S -o bad.s bad.c And look for the srawi that shifts by 13. I changed it from 11 to make it easier to find because there are other shifts by 11. Then trace the result on its way to the function call. I see: 303:srawi 10,31,13 305:stw 10,29148(1) 325:ld 16,29144(1) 332:mr 27,16 545:mr 6,27 546:bl gl_write_texture_span
[Bug c++/65970] [C++14] Endless loop with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65970 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jason at gcc dot gnu.org | Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #4 from Paolo Carlini --- We can resolve this as fixed in 7.1.0, I believe.
[Bug c++/67735] internal compiler error while trying to use __direct_bases to create parallel hierarchy of classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67735 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-17 Ever confirmed|0 |1
[Bug c++/70377] "unexpected AST" and "confused by earlier errors, bailing out" from throw in simple constexpr fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70377 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini --- Ok, I think we can close this one (about the ICE) as fixed for 6.1.0.
[Bug c++/70377] "unexpected AST" and "confused by earlier errors, bailing out" from throw in simple constexpr fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70377 Paolo Carlini changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82478 --- Comment #4 from Corey Tabaka --- Ah, you are right. Late night mixup... The outer class friend should work though, correct?
[Bug c++/71251] [6/7/8 regression] ICE on invalid code, with unusual template name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71251 --- Comment #5 from Paolo Carlini --- Related to PR71220.
[Bug c++/71368] [concepts] ICE on constrained compound requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71368 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.2 --- Comment #2 from Paolo Carlini --- Fixed in 6.2.0.
[Bug c++/71368] [concepts] ICE on constrained compound requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71368 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 17 19:36:49 2017 New Revision: 253826 URL: https://gcc.gnu.org/viewcvs?rev=253826&root=gcc&view=rev Log: 2017-10-17 Paolo Carlini PR c++/71368 * g++.dg/concepts/pr71368.C: New. Added: trunk/gcc/testsuite/g++.dg/concepts/pr71368.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/71821] [6/7/8 regression] ICE on invalid C++11 code (incorrect argument for alignas): unexpected expression ‘f’ of kind template_id_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71821 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 17 19:49:06 2017 New Revision: 253828 URL: https://gcc.gnu.org/viewcvs?rev=253828&root=gcc&view=rev Log: 2017-10-17 Paolo Carlini PR c++/71821 * g++.dg/cpp0x/alignas12.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alignas12.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/71821] [6/7/8 regression] ICE on invalid C++11 code (incorrect argument for alignas): unexpected expression ‘f’ of kind template_id_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71821 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|6.5 |7.0 --- Comment #7 from Paolo Carlini --- Given that this is only an ICE on invalid, I think at this time we can close it as fixed for 7.1.0.
[Bug c++/58601] [meta-bug] alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601 Bug 58601 depends on bug 71821, which changed state. Bug 71821 Summary: [6/7/8 regression] ICE on invalid C++11 code (incorrect argument for alignas): unexpected expression ‘f’ of kind template_id_expr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71821 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/82592] New: [8 Regression] ICE in extract_constrain_insn, at recog.c:2207 (error: insn does not satisfy its constraints)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82592
Bug ID: 82592
Summary: [8 Regression] ICE in extract_constrain_insn, at
recog.c:2207 (error: insn does not satisfy its
constraints)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-8.0.0-alpha20171015 snapshot (r253772) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -funroll-loops:
int pb;
void
ch (unsigned char np, char fc)
{
unsigned char *y6 = &np;
if (fc != 0)
{
unsigned char *z1 = &np;
for (;;)
if (*y6 != 0)
for (fc = 0; fc < 12; ++fc)
{
int hh;
int tp;
if (fc != 0)
hh = (*z1 != 0) ? fc : 0;
else
hh = pb;
tp = fc > 0;
if (hh == tp)
*y6 = 1;
}
}
if (np != 0)
y6 = (unsigned char *)&fc;
if (pb != 0 && *y6 != 0)
for (;;)
{
}
}
% x86_64-unknown-linux-gnu-gcc-8.0.0-alpha20171015 -O2 -funroll-loops -c
id5cyx54.c
id5cyx54.c: In function 'ch':
id5cyx54.c:36:1: error: insn does not satisfy its constraints:
}
^
(insn 565 340 357 42 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:SI (reg:SI 2 cx [120])
(const_int 2 [0x2]))
(const_int 0 [0])))
(set (reg:SI 1 dx [orig:91 ivtmp.14 ] [91])
(plus:SI (reg:SI 2 cx [120])
(const_int 2 [0x2])))
]) 225 {*addsi_2}
(nil))
during RTL pass: rnreg
id5cyx54.c:36:1: internal compiler error: in extract_constrain_insn, at
recog.c:2207
