[Bug target/25114] [m68k] Suboptimal inequality comparisons with small integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25114 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/69027] implement indirect tail calls on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69027 --- Comment #2 from Sebastian Huber --- I have an admittedly quite exotic use case where it hurts. I changed a switch statement to adaptor functions in RTEMS to avoid dead code, e.g. https://git.rtems.org/rtems/diff/cpukit/score/src/threadhandler.c?id=ccd54344d904b657123e4e4ba795a32212382be2 The _Thread_Handler() function in RTEMS calls the thread entry function. Since threads normally don't return every space used on the stack in this area is lost. Due to the change from the switch to a function call we waste now 96 bytes of space grade RAM for each thread.
[Bug tree-optimization/69380] New: FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69380 Bug ID: 69380 Summary: FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: rguenther at suse dot de Target Milestone: --- Target: arm-none-eabi Created attachment 37402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37402&action=edit Failing optimized dump g++.dg/tree-ssa/pr69336.C fails on arm-none-eabi targets since its introduction in r232559 with: FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap" Please find attached the optimized dump with the commit applied.
[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69379 --- Comment #1 from Martin Michlmayr --- Created attachment 37401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37401&action=edit Preprocessed source
[Bug c++/69379] New: [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69379 Bug ID: 69379 Summary: [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tbm at cyrius dot com Target Milestone: --- Running multidelta. Will update tomorrow. tbm@dl580gen9-02:~/gcc6/testcase1/1$ g++-6 -c DictDataInfoPyWrap.ii tbm@dl580gen9-02:~/gcc6/testcase1/1$ g++-6 -c -Wformat DictDataInfoPyWrap.ii src/DictDataInfoPyWrap.C: In function 'void InitDictDataInfoPyWrapper()': src/DictDataInfoPyWrap.C:220:65: internal compiler error: in fold_convert_loc, at fold-const.c:2366 0x890552 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../src/gcc/fold-const.c:2366 0x68f641 cp_fold_convert(tree_node*, tree_node*) ../../src/gcc/cp/cvt.c:605 0x6fa49a cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3344 0x6f902b cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3421 0x6f8daf cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:3613 0x6fbe48 cxx_eval_outermost_constant_expr ../../src/gcc/cp/constexpr.c:3816 0x6fce63 maybe_constant_value_1 ../../src/gcc/cp/constexpr.c:4003 0x6fce63 maybe_constant_value(tree_node*, tree_node*) ../../src/gcc/cp/constexpr.c:4024 0x5cbeb9 build_over_call ../../src/gcc/cp/call.c:7546 0x5ca97f build_new_method_call_1 ../../src/gcc/cp/call.c:8408 0x5ca97f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../src/gcc/cp/call.c:8478 0x656597 cp_parser_postfix_expression ../../src/gcc/cp/parser.c:6855 0x65e370 cp_parser_unary_expression ../../src/gcc/cp/parser.c:7964 0x65ee7b cp_parser_cast_expression ../../src/gcc/cp/parser.c:8641 0x65f298 cp_parser_binary_expression ../../src/gcc/cp/parser.c:8742 0x65fa84 cp_parser_assignment_expression ../../src/gcc/cp/parser.c:9029 0x66282a cp_parser_expression ../../src/gcc/cp/parser.c:9198 0x663210 cp_parser_expression_statement ../../src/gcc/cp/parser.c:10659 0x6516d4 cp_parser_statement ../../src/gcc/cp/parser.c:10510 0x6524d1 cp_parser_statement_seq_opt ../../src/gcc/cp/parser.c:10782 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug tree-optimization/69378] New: FAIL: g++.dg/tree-ssa/pr61034.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69378 Bug ID: 69378 Summary: FAIL: g++.dg/tree-ssa/pr61034.C Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: rguenther at suse dot de Target Milestone: --- Target: arm-none-eabi Created attachment 37400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37400&action=edit Diff of optimized dump before and after offending commit g++.dg/tree-ssa/pr61034.C fails after r232401 with: FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++11 scan-tree-dump-times optimized "free" 4 FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++14 scan-tree-dump-times optimized "free" 4 FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++98 scan-tree-dump-times optimized "free" 4 It then finds 7 instances of free instead of 4. Attached is the diff of the dump before and after that commit.
[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555
--- Comment #6 from Jerry DeLisle ---
This patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 64d59cee..8a465db6 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -14275,6 +14275,13 @@ resolve_symbol (gfc_symbol *sym)
if (sym->ns != formal->sym->ns)
sym->formal_ns->refs++;
}
+
+ /* Check that none of the arguments are a namelist.. */
+ for (formal = sym->formal; formal; formal = formal->next)
+if (formal->sym && formal->sym->attr.flavor == FL_NAMELIST)
+ gfc_error ("Namelist '%s' as argument to procedure at %L "
+"not allowed.", formal->sym->name,
+&sym->declared_at);
}
/* Check threadprivate restrictions. */
results in:
$ gfc pr50555.f90
pr50555.f90:3:7:
f(i)=0
1
Error: Namelist 'i' as argument to procedure at (1) not allowed.
[Bug rtl-optimization/69377] New: wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69377
Bug ID: 69377
Summary: wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O2
in the 32-bit mode (but not in the 64-bit mode).
This is a regression from 5.3.x.
The reduced test is still fairly large; this has been a tough one to reduce.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160119 (experimental) [trunk revision 232571] (GCC)
$
$ gcc-trunk -m32 -Os small.c; ./a.out
2
1
1
$ gcc-5.3 -m32 -O2 small.c; ./a.out
2
1
1
$ gcc-trunk -m32 -O2 small.c
$ ./a.out
2
1
$
---
int printf (const char *, ...);
int r, *s, t, p, a, q, b;
short u = 3;
static int *v;
char c;
static int *
fn1 (int p1)
{
int w = 2, j;
for (; q < 1;)
{
int d = 6094 ^ p, e = ~r;
p = e;
if (!d)
return &t;
j = 0;
for (; j < 1;)
{
j = 0;
for (; j < 1; j++)
for (; q < 2; q++)
;
}
}
if (u)
for (;;)
{
char x;
int y, z = 1, t1;
x = 7;
for (; x; x++)
{
int f = p || r;
t1 = ~p | w;
w = (u || f % a) % ~(t1 && f) - r;
if (p < 6)
{
printf ("%d\n", t1);
break;
}
}
int g = 4 % w;
if (g)
{
--p;
int h = p && t1;
z = h;
if (p > 5 && z)
continue;
}
y = g;
if (z < p)
{
int i = g / u;
y = i;
}
int j = u & y, k, o = z * x;
if (p)
{
k = z;
o = t1;
c = x;
z = -y;
t1 = (j && y << c) + k || x;
x = ~(u % p);
if (x < c)
printf ("%d\n", t1);
}
int l = p < z;
short m = ((l && y) & ~u) * t1;
int n = u && t1;
if (t1 && x && (!x || z))
m = l * (y && n) | x;
printf ("%d\n", t1);
if (o && m > w)
*v = 0;
else
{
if (!p1)
continue;
return &b;
}
}
}
static void
fn2 (char p1)
{
s = fn1 (254);
for (; p1 <= 0;)
{
s = fn1 (254);
for (;;)
;
}
}
int
main ()
{
fn2 (4);
return 0;
}
[Bug tree-optimization/69376] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376
Bug ID: 69376
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -Os
and above in both 32-bit and 64-bit modes.
This is a regression from 5.3.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160119 (experimental) [trunk revision 232571] (GCC)
$
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-5.3 -Os small.c; ./a.out
$
$ gcc-trunk -Os small.c
$ ./a.out
Segmentation fault (core dumped)
$
-
int printf (const char *, ...);
unsigned a, c, *d, f;
char b, e;
short g;
void
fn1 ()
{
unsigned h = 4294967290;
if (b >= 0)
{
h = b;
c = b / 290;
f = ~(c - (8 || h));
if (f)
printf ("%d\n", 1);
if (f)
printf ("%d\n", f);
g = ~f;
if (c < 3)
{
int i = -h < ~c;
unsigned j;
if (i)
j = h;
h = -j * g;
}
c = h;
}
unsigned k = ~h;
char l = e || g;
if (l < 1 || k < 7)
*d = a;
}
int
main ()
{
fn1 ();
return 0;
}
[Bug c++/69375] New: GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69375 Bug ID: 69375 Summary: GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- Created attachment 37399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37399&action=edit reproducer I don't see where [except.handle] allows such a conversion.
[Bug target/69374] New: install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 Bug ID: 69374 Summary: install.texi is bit-rotten Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- While looking at something else, I noticed that install.texi seems to be majorly bit-rotten, with many references to ancient versions of GCC. It even says the instructions are for "the current development sources", so do we need to know things like how to bootstrap versions prior to 3.4? Or that the C++ compiler in version 2.6.0 doesn't support DWARF on 386 SVR4 platforms? Or that support for various old OS versions was removed years ago? Much of this information is target-specific so probably the target maintainers need to go through it and remove everything that's not relevant for currently-supported platforms.
[Bug c++/69373] New: GCC emits incorrect warning that "exception of type ‘void (*)()’ will be caught by earlier handler for 'void*'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69373 Bug ID: 69373 Summary: GCC emits incorrect warning that "exception of type ‘void (*)()’ will be caught by earlier handler for 'void*'" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- Created attachment 37398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37398&action=edit reproducer Since function pointers cannot be converted to void* this warning is incorrect and the "void*" catch site will not be selected.
[Bug c++/69372] GCC allows array and function types to be caught by reference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69372 --- Comment #1 from Eric Fiselier --- Created attachment 37397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37397&action=edit reproducer for function types attached a reproducer for function types.
[Bug c++/69372] New: GCC allows array and function types to be caught by reference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69372 Bug ID: 69372 Summary: GCC allows array and function types to be caught by reference. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- Created attachment 37396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37396&action=edit reproducer for array types The current C++ draft states: [expr.throw]/p2 states: > Evaluating a throw-expression with an operand throws an exception (15.1); the > type of the exception object > is determined by removing any top-level cv-qualifiers from the static type of > the operand and adjusting the > type from “array of T” or function type T to “pointer to T”. Therefore it should not be possible to catch a function or array by reference. However GCC allows this.
[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |6.0
[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 --- Comment #10 from Jack Howarth --- It is unclear if the changes in r232454, to avoid the explicit linkage on libitm, can ever be made darwin-friendly. On darwin, every single executable linked against libstdc++ would require -Wl,-undefined,dynamic_lookup on the linkage to avoid linkage errors from the undefined symbols from libitm within libstdc++.
[Bug testsuite/69371] New: UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371
Bug ID: 69371
Summary: UNRESOLVED:
special_functions/18_riemann_zeta/check_value.cc
compilation failed to produce executable
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
CC: 3dw4rd at verizon dot net, CaptainSifff at gmx dot de,
redi at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Hi,
special_functions/18_riemann_zeta/check_value.cc fails to build on
arm-none-eabi targets with the following error:
libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc: In
function 'void test(const testcase_riemann_zeta (&)[Num], Tp)':
libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc:285:15:
error: 'riemann_zeta' is not a member of 'std'
Since special_functions/18_riemann_zeta/check_nan.cc builds successfully, I
suppose that's due to missing one or all of the following directives:
// { dg-require-c-std "" }
// { dg-add-options ieee }
which are present for check_nan.cc but not for check_value.cc
[Bug c++/53931] [C++11] braced function style cast to reference should be prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53931 --- Comment #2 from Hubert Tong --- Needs a resolution for CWG 1521.
[Bug target/65546] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-20 Ever confirmed|0 |1 Known to fail||5.3.0, 6.0 --- Comment #3 from Martin Sebor --- The test still fails with the latest trunk (6.0) and 5.4 in the latest powerpc64le results reported on gcc-testresults: https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01830.html https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01847.html
[Bug target/65096] Illegal memory access beyond packed struct ARCH: ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65096 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-20 CC||msebor at gcc dot gnu.org Known to work||6.0 Ever confirmed|0 |1 --- Comment #7 from Martin Sebor --- Unable to reproduce with today's trunk on powerpc64, though I don't have 5.3 installed there. In light of comment #5 and #6, should this be closed as fixed?
[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed|2014-11-10 00:00:00 |2016-1-19 Known to work||4.8.5 Known to fail||5.3.0, 6.0 --- Comment #5 from Martin Sebor --- 6.0 still fails with the same ICE. The native 4.8.5 on RHEL 7.2 works though it's not the same as the vanilla 4.8.5.
[Bug target/35490] Wrong code with altivec register passing and sibcalling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35490 Martin Sebor changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Martin Sebor --- Thanks. Let me resolve this as WORKSFORSOME then.
[Bug target/54670] ICE in extract_insn, at recog.c:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54670 --- Comment #5 from Arseny Solokha --- (In reply to Martin Sebor from comment #4) > It has been over three years with no confirmation. Is this still a problem > on the target with recent GCC? Personally, I cannot reproduce it as described neither w/ gcc 5.3 nor w/ the latest gcc 6 snapshot.
[Bug c/64843] miscompilation of atomic_fetch_add on atomic pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843 --- Comment #8 from joseph at codesourcery dot com --- I think we should keep the built-in function semantics as-is, and fix stdatomic.h along the lines I proposed in comment#3.
[Bug target/35490] Wrong code with altivec register passing and sibcalling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35490 --- Comment #2 from Andrew Pinski --- (In reply to Martin Sebor from comment #1) > I don't have a GCC for Darwin but with trunk configured for > powerpc64-linux-gnu the emitted code looks correct. > > Andrew, can you confirm whether this is still a problem? I don't know as I don't have a powerpc darwin machine any more. I got rid of it 4 years ago.
[Bug target/54670] ICE in extract_insn, at recog.c:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54670 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-20 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- It has been over three years with no confirmation. Is this still a problem on the target with recent GCC?
[Bug c++/53931] [C++11] braced function style cast to reference should be prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53931 Martin Sebor changed: What|Removed |Added Keywords|rejects-valid, wrong-code | Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-20 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.5, 5.3.0, 6.0 --- Comment #1 from Martin Sebor --- Confirmed with trunk, 5.3.0, and 4.8.5. The keyword is "accepts-invalid" (not "accepts-invalid" or "wrong-code", the letter being used to mark bugs where gcc generates incorrect code for valid programs, and are usually considered more serious than cases where it accepts invalid programs).
[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-20 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.3.0, 6.0 --- Comment #3 from Martin Sebor --- Confirmed with the modified test case as indicated in comment #2 on trunk, 5.3.0, 4.9.3, and 4.8.5. It doesn't look like it has ever been handled correctly. The same on x86_64.
[Bug fortran/69370] Fortran spurious warning (regression)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69370 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- See the ChangeLog-2015 entry 2015-06-06 Thomas Koenig PR fortran/47659
[Bug rtl-optimization/68298] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jeffrey A. Law --- When I first stepped through this under the debugger, my first thought was one of the REE bugfixes from a while back. Bisection landed on: 423a45f1fecb76c4d50e1695d3a73a8d8b62912b is the first bad commit commit 423a45f1fecb76c4d50e1695d3a73a8d8b62912b Author: ktkachov Date: Tue Nov 24 09:31:57 2015 + [RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves PR rtl-optimization/68194 PR rtl-optimization/68328 PR rtl-optimization/68185 * ree.c (combine_reaching_defs): Reject copy_needed case if copies_list is not empty. * gcc.c-torture/execute/pr68185.c: New test. * gcc.c-torture/execute/pr68328.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230795 138bc75d-0d04-0410-961f-82ee72b054a4 So this was fixed a couple months ago. Again, thanks for the .s and .o files.
[Bug c/64843] miscompilation of atomic_fetch_add on atomic pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Known to fail||4.9.3, 6.0
--- Comment #7 from Martin Sebor ---
See also bug 52291. This never worked correctly and the bug still exists on
trunk (6.0).
The C11 operations are expected to work on "address types" (which is a term
inadvertently held over from the original proposal). There are other problems
with the C11 specification and WG14 has started to clean this up. The DR that
comes closest to addressing this is DR 486, though I expect it to be superseded
by future, more focused papers.
$ cat a.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra
a.c && ./a.out
#include
int main (void)
{
int a[2] = { 1, 2 };
{
int *p = a;
int *q = __sync_fetch_and_add (&p, 2);
__builtin_printf ("%p => %p\n", a, p);
}
{
int *p = a;
int *q = __atomic_fetch_add (&p, 2, 0);
__builtin_printf ("%p => %p\n", a, p);
}
{
int* _Atomic p = a;
int *q = atomic_fetch_add (&p, 2);
__builtin_printf ("%p => %p\n", a, p);
if (p != a + 2)
__builtin_abort ();
}
}
a.c: In function ‘main’:
a.c:9:14: warning: unused variable ‘q’ [-Wunused-variable]
int *q = __sync_fetch_and_add (&p, 2);
^
a.c:16:14: warning: unused variable ‘q’ [-Wunused-variable]
int *q = __atomic_fetch_add (&p, 2, 0);
^
a.c:24:14: warning: unused variable ‘q’ [-Wunused-variable]
int *q = atomic_fetch_add (&p, 2);
^
0x3fffc5851208 => 0x3fffc585120a
0x3fffc5851208 => 0x3fffc585120a
0x3fffc5851208 => 0x3fffc585120a
Aborted
[Bug fortran/69370] New: Fortran spurious warning (regression)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69370 Bug ID: 69370 Summary: Fortran spurious warning (regression)? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: physiker at toast2 dot net Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: gcc version 6.0.0 20160114 Compiling t.f90 with option -Wconversion active generates the warning 'Change of value in conversion from ‘REAL(8)’ to ‘REAL(4)’. This warning does not occur when the code is compiled by gcc 5.3 or gcc 4.4. The warning is not present if undef is set to less than about 2d10. I would appreciate it very much if the warning is expected. t.f90 program t real(8),parameter :: undef=3.33d33 real(4),parameter :: undef4=real(undef,4) end program t gcc-6: gfortran-6 -v -Wconversion t.f90 Driving: gfortran-6 -v -Wconversion t.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran-6 COLLECT_LTO_WRAPPER=/common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/fsy/peschmid/lnx/sw --with-gmp=/home/fsy/peschmid/lnx/sw --with-mpfr=/home/fsy/peschmid/lnx/sw --with-mpc=/home/fsy/peschmid/lnx/sw --with-isl=/home/fsy/peschmid/lnx/sw --enable-__cxa_atexit --enable-languages=c,c++,fortran --program-suffix=-6 Thread model: posix gcc version 6.0.0 20160114 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-Wconversion' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 t.f90 -quiet -dumpbase t.f90 -mtune=generic -march=x86-64 -auxbase t -Wconversion -version -fintrinsic-modules-path /common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o /tmp/ccmDPJqS.s GNU Fortran (GCC) version 6.0.0 20160114 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 6.0.0 20160114 (experimental), GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran2008 (GCC) version 6.0.0 20160114 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 6.0.0 20160114 (experimental), GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 t.f90:3:35: real(4),parameter :: undef4=real(undef,4) 1 Warning: Change of value in conversion from ‘REAL(8)’ to ‘REAL(4)’ at (1) [-Wconversion] COLLECT_GCC_OPTIONS='-v' '-Wconversion' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../x86_64-pc-linux-gnu/bin/as -v --64 -o /tmp/cc5lgPHU.o /tmp/ccmDPJqS.s GNU assembler version 2.25.51.0.4 (x86_64-pc-linux-gnu) using BFD version (Linux/GNU Binutils) 2.25.51.0.4.20151114 Reading specs from /common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-Wconversion' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/:/common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/:/common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/:/common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/:/common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/:/common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../x86_64-pc-linux-gnu/lib/:/common/home/fsy/peschmid/lnx/sw/bin/../lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-Wconversion' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/collect2 -plugin /common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/liblto_plugin.so -plugin-opt=/common/home/fsy/peschmid/lnx/sw/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccoi1UZW.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /
[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52291 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-19 CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- I suspect this is not going to change for the __sync_xxx builtins that have been made obsolete by the newer __atomic_xxx builtins. Those, unfortunately, have the same semantics as far as pointers as the former builtins. Worse yet, these semantics are exposed in the C11 atomic_xxx() generic functions, making the latter incorrect. For instance, atomic_fetch_add(p, N) is expected to be equivalent to p += N for any object pointer p, but in GCC it only holds for pointers to objects 1 byte wide (see bug 64843). I agree that the __sync_xxx semantics should be clarified in the manual to avoid any surprises. Let me put something together.
[Bug rtl-optimization/68298] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-19 Ever confirmed|0 |1 --- Comment #9 from Jeffrey A. Law --- Thanks for the .s and .o files. They were very helpful. So if I compile the provided .o into an executable it still doesn't fail. However, I can throw it into the debugger and see that we're reading a[400], so depending on the exact memory layout and mapped pages we may or may not get a fault. Sadly valgrind doesn't flag this. >From looking at the provided .s file, we have clearly mis-compiled fn3. The guard for the read of a[400] tests %al, which is never set. If I compile this with a trunk compiler, the guard is properly initialized and the read of a[400] never occurs. Bisecting now to find out if it was fixed or just gone latent.
[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612 --- Comment #11 from Segher Boessenkool --- I don't see it being fixed any time soon. a fix is likely too intrusive for stage 4, so yeah let's just xfail it :-(
[Bug middle-end/69369] New: [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
Bug ID: 69369
Summary: [6 Regression] internal compiler error: in
remove_unreachable_nodes, at ipa.c:457
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz
Target Milestone: ---
On x86, r232560 caused:
[hjl@gnu-6 gcc]$ cat
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr65184.c
/* { dg-do compile } */
/* { dg-require-effective-target mpx } */
/* { dg-options "-O2 -mabi=ms -fcheck-pointer-bounds -mmpx" } */
void
foo (int *a)
{
if (a[0] != a[1] * 2333)
__builtin_abort ();
}
void
bar (int *a)
{
if (a[0] != a[1] * 2333)
__builtin_abort ();
}
[hjl@gnu-6 gcc]$ ./xgcc -B./
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr65184.c -S
-O2 -fcheck-pointer-bounds -mmpx
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr65184.c:17:1:
internal compiler error: in remove_unreachable_nodes, at ipa.c:457
}
^
0xbde2b8 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/ipa.c:457
0xd2389c execute_todo
/export/gnu/import/git/sources/gcc/gcc/passes.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[hjl@gnu-6 gcc]$
[Bug c++/51817] [C++11] argument deduction fails when A-type parameter-type-list has additional parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51817 Hubert Tong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Hubert Tong --- (In reply to Martin Sebor from comment #2) > As I understand the complaint it is about rejecting what's thought to be > valid code, so the Keywords should be "rejects-valid" (not "accepts-invalid" > or "wrong-code"). Overload resolution is involved, all three tags would apply (depending on the set of candidates). > > I also note that the most recent versions of Clang and the EDG front end > both reject the example. (I haven't re-read the referenced paper or checked > the latest standard to say if the code really is valid.) Based on the notes from CWG 1763, I am cancelling this.
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 Mike Frysinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail||4.9.3, 5.3.0 --- Comment #46 from Mike Frysinger --- thanks all !
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #45 from Mike Frysinger --- Author: vapier Date: Tue Jan 19 23:15:12 2016 New Revision: 232595 URL: https://gcc.gnu.org/viewcvs?rev=232595&root=gcc&view=rev Log: ia64: don't use dynamic relocations for local symbols Backported from trunk for PR other/60465. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/ia64/pr60465-gprel64-c37.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/ia64/pr60465-gprel64.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/ia64/ia64.c branches/gcc-4_9-branch/gcc/config/ia64/predicates.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 --- Comment #12 from Jeffrey A. Law --- Ah nuts. The partitioning information is part of the .expand dump, not the .optimized dump. -fdump-rtl-expand-details.
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #44 from Mike Frysinger --- Author: vapier Date: Tue Jan 19 23:12:22 2016 New Revision: 232594 URL: https://gcc.gnu.org/viewcvs?rev=232594&root=gcc&view=rev Log: ia64: don't use dynamic relocations for local symbols Backported from trunk for PR other/60465. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/ia64/pr60465-gprel64-c37.c branches/gcc-5-branch/gcc/testsuite/gcc.target/ia64/pr60465-gprel64.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/ia64/ia64.c branches/gcc-5-branch/gcc/config/ia64/predicates.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/69336] Constant value not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336 Jakub Jelinek changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #8 from Jakub Jelinek --- *** Bug 69368 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/69368] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Please just retry with r232559 or newer. *** This bug has been marked as a duplicate of bug 69336 ***
[Bug c++/51817] [C++11] argument deduction fails when A-type parameter-type-list has additional parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51817 Martin Sebor changed: What|Removed |Added Keywords|accepts-invalid, wrong-code | CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- As I understand the complaint it is about rejecting what's thought to be valid code, so the Keywords should be "rejects-valid" (not "accepts-invalid" or "wrong-code"). I also note that the most recent versions of Clang and the EDG front end both reject the example. (I haven't re-read the referenced paper or checked the latest standard to say if the code really is valid.)
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Fixed on the trunk.
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 --- Comment #7 from Jeffrey A. Law --- Author: law Date: Tue Jan 19 23:03:26 2016 New Revision: 232593 URL: https://gcc.gnu.org/viewcvs?rev=232593&root=gcc&view=rev Log: PR middle-end/69347 * tree-ssa-threadbackwards.c (fsm_find_control_statement_thread_paths): Do not try to lookup FSM paths for SSA_NAMEs appearing in abnormal PHIs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadbackward.c
[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #11 from Martin Sebor --- I'm not able to reproduce any bad behavior on powerpc64-*-linux-gnu with recent versions of GCC. The bug was opened against 4.2.1 and has been in WAITING status since 2009. The oldest still maintained version of GCC is 4.9. Does the problem still exist there or can this bug be closed?
[Bug tree-optimization/69368] New: spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 Bug ID: 69368 Summary: spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- This occurs on both powerpc64 LE and BE. I am not sure about other architectures. /home/seurer/gcc/cpu2006b/bin/specinvoke -E -d /home/seurer/gcc/cpu2006b/benchspec/CPU2006/416.gamess/run/run_base_test_base_64. -c 1 -e compare.err -o compare.stdout -f compare.cmd Contents of exam29.err Note: The following floating-point exceptions are signalling: IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG STOP IN ABRT *** Miscompare of exam29.out; for details see /home/seurer/gcc/cpu2006b/benchspec/CPU2006/416.gamess/run/run_base_test_base_64./exam29.out.mis Invalid run; unable to continue. Contents of /home/seurer/gcc/cpu2006b/benchspec/CPU2006/416.gamess/run/run_base_test_base_64./exam29.out.mis 0452: MEMORY REQUIREMENTS FOR SEGMENTED MP2 TRANSFORMATION INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 1 ^ 0453: MINIMUM= 52902 WORDS, USING 1 MOLECULAR ORBITAL PER PASS INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 2 ^ 0454: MAXIMUM=238032 WORDS, MAKING ONLY 1 INTEGRAL PASS INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 3 ^ 0455: CHOOSING THE SEGMENTED MP2 TRANSFORMATION... INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 4 ^ 0456: NUMBER OF MOS/PASS = 11 INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 5 ^ 0457: NUMBER OF PASSES =1 INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 6 ^ 0458: MEMORY USED = 238032 WORDS. INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 7 ^ 0459: PASS # 1 TOOK0.00 SECONDS. INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 8 ^ 0460: DONE WITH PARTIAL TRANSFORMATION (PQ|RS) TO (IA|JB) INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 9 ^ 0461: RESULTS OF MOLLER-PLESSET 2ND ORDER CORRECTION ARE INTEGRAL TRANSFORMATION CANNOT ASSIGN A DEFINITE ORBITAL SYMMETRY TO MO 11 ^
[Bug tree-optimization/38153] ICE in testcase when compiled with -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
Martin Sebor changed:
What|Removed |Added
Target|powerpc64-suse-linux|powerpc64*-*-linux
CC||msebor at gcc dot gnu.org
Host|powerpc64-suse-linux|powerpc64*-*-linux
Known to fail||4.9.3, 5.1.0, 6.0
Build|powerpc64-suse-linux|powerpc64*-*-linux
--- Comment #5 from Martin Sebor ---
Still fails with the latest trunk on both powerpc64 and powerpc64le:
$ cat a.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O -Wall
-ftree-parallelize-loops=2 a.c
void foo(int n, void** p)
{
int i;
for (i = 0; i < n; ++i)
p[i] = &&L;
L: goto **p;
}
a.c: In function ‘foo’:
a.c:1:6: error: label
void foo(int n, void** p)
^~~
L has incorrect context in bb 9a.c:1:6: internal compiler error:
verify_flow_info failed
0x1055b0fb verify_flow_info()
/src/gcc-trunk/gcc/cfghooks.c:260
0x10d7ec33 checking_verify_flow_info
/src/gcc-trunk/gcc/cfghooks.h:198
0x10d81a87 cleanup_tree_cfg_noloop
/src/gcc-trunk/gcc/tree-cfgcleanup.c:766
0x10d81bd3 cleanup_tree_cfg()
/src/gcc-trunk/gcc/tree-cfgcleanup.c:812
0x10af0f47 execute_expand_omp
/src/gcc-trunk/gcc/omp-low.c:13929
0x10af120f execute
/src/gcc-trunk/gcc/omp-low.c:14012
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug driver/69367] spec file documentation is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69367 --- Comment #1 from joseph at codesourcery dot com --- I think the main specs documentation is the comment starting "Specs are strings containing lines" and it was a mistake to copy it into the manual in the first place; it should not be considered an interface for users.
[Bug target/35490] Wrong code with altivec register passing and sibcalling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35490
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2016-01-19
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||
--- Comment #1 from Martin Sebor ---
I don't have a GCC for Darwin but with trunk configured for powerpc64-linux-gnu
the emitted code looks correct.
Andrew, can you confirm whether this is still a problem?
$ cat a.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall
-maltivec -o/dev/stdout a.c
#define vector __vector
struct data {
vector float v;
};
extern int bar (int a, struct data b, void *c);
int foo (struct data *inp_r3, void *inp_r4)
{
return bar(10, *inp_r3, ((void *) inp_r4));
}
.file "a.c"
.machine power4
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl foo
.section".opd","aw"
.align 3
foo:
.quad .L.foo,.TOC.@tocbase,0
.previous
.type foo, @function
.L.foo:
mflr 0
mr 7,4
std 0,16(1)
stdu 1,-112(1)
lvx 2,0,3
li 3,10
bl bar
nop
addi 1,1,112
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,0,0,0
.size foo,.-.L.foo
.ident "GCC: (GNU) 6.0.0 20160119 (experimental)"
[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-19 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/34087] ICE in regrename.c for movdf_hardfloat64_mfpgpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34087 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to work||6.0 --- Comment #4 from Martin Sebor --- The test case compiles with the latest trunk (and even with the native 4.8.5 I have installed on the RHEL 7.2 box I'm using). Can it be closed?
[Bug debug/31690] ICE with const __uint128_t and C++ front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31690 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||msebor at gcc dot gnu.org Known to work||5.3.0, 6.0 Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- This compiles fine with trunk (6.0) as well as 5.3.0, on both powerpc64 and powerpc64le. Resolving as fixed. $ cat a.c && /build/gcc-trunk/gcc/xg++ -B /build/gcc-trunk/gcc -c -g -xc++ a.c && echo PASS const __uint128_t fives = (((__uint128_t)(0xULL)) <<64)|((__uint128_t)(0xULL)); PASS
[Bug middle-end/27321] Compare against constant infinity fails with IBM long double format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27321 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||5.3.0, 6.0 Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Looks like this has worked correctly for some time and is being tested by at least one of the gcc.c-torture/execute/ieee/inf-*.c tests. Resolving as fixed.
[Bug driver/69361] Nonsensical suggestion for misspelled command-line option "-help"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69361 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-19 Ever confirmed|0 |1
[Bug middle-end/26933] Volatile member in struct member accessed/written implicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||msebor at gcc dot gnu.org Known to work||5.3.0, 6.0 Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- With 5.3.0 and 6.0, the bitfield is accessed using the lbz and stb instructions (on both powerpc64 and powerpc64le). The test program attached in comment #1 also seems happy. I think this can be resolved as fixed. $ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra -Wpedantic -xc -o/dev/stdout -O1 a.c .file "a.c" .machine power4 .section".toc","aw" .section".text" a.c: In function ‘foo’: a.c:11:17: warning: overflow in implicit constant conversion [-Woverflow] data->B=1; ^ .align 2 .globl foo .section".opd","aw" .align 3 foo: .quad .L.foo,.TOC.@tocbase,0 .previous .type foo, @function .L.foo: lbz 9,8(3) li 10,-1 rldimi 9,10,7,32 stb 9,8(3) lwz 3,12(3) blr .long 0 .byte 0,0,0,0,0,0,0,0 .size foo,.-.L.foo .ident "GCC: (GNU) 6.0.0 20160119 (experimental)"
[Bug libstdc++/14608] nukes isfinite macro from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #16 from Jonathan Wakely --- Fixed on trunk.
[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60401 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from Jonathan Wakely --- Fixed on trunk
[Bug libstdc++/60401] stdlib.h does not provide abs(long) overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60401 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Jan 19 21:43:55 2016 New Revision: 232586 URL: https://gcc.gnu.org/viewcvs?rev=232586&root=gcc&view=rev Log: Add C++-conforming wrappers for stdlib.h and math.h PR libstdc++/14608 PR libstdc++/60401 * include/Makefile.am: Use c_compatibility math.h and stdlib.h for --enable-cheaders=c_global configs. * include/Makefile.in: Regenerate. * include/c_compatibility/math.h: Remove obsolete _GLIBCXX_NAMESPACE_C test and allow inclusion from C files. * include/c_compatibility/stdlib.h: Likewise. Support freestanding. (at_quick_exit, quick_exit): Add using directives. * include/c_global/cmath: Use #include_next for math.h. * include/c_global/cstdlib: Use #include_next for stdlib.h. * testsuite/26_numerics/headers/cmath/14608.cc: New. * testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc: Remove xfail for most targets. * testsuite/26_numerics/headers/cstdlib/60401.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/14608.cc - copied, changed from r232581, trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc trunk/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/60401.cc - copied, changed from r232581, trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/c_compatibility/math.h trunk/libstdc++-v3/include/c_compatibility/stdlib.h trunk/libstdc++-v3/include/c_global/cmath trunk/libstdc++-v3/include/c_global/cstdlib trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc
[Bug libstdc++/14608] nukes isfinite macro from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 --- Comment #15 from Jonathan Wakely --- Author: redi Date: Tue Jan 19 21:43:55 2016 New Revision: 232586 URL: https://gcc.gnu.org/viewcvs?rev=232586&root=gcc&view=rev Log: Add C++-conforming wrappers for stdlib.h and math.h PR libstdc++/14608 PR libstdc++/60401 * include/Makefile.am: Use c_compatibility math.h and stdlib.h for --enable-cheaders=c_global configs. * include/Makefile.in: Regenerate. * include/c_compatibility/math.h: Remove obsolete _GLIBCXX_NAMESPACE_C test and allow inclusion from C files. * include/c_compatibility/stdlib.h: Likewise. Support freestanding. (at_quick_exit, quick_exit): Add using directives. * include/c_global/cmath: Use #include_next for math.h. * include/c_global/cstdlib: Use #include_next for stdlib.h. * testsuite/26_numerics/headers/cmath/14608.cc: New. * testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc: Remove xfail for most targets. * testsuite/26_numerics/headers/cstdlib/60401.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/14608.cc - copied, changed from r232581, trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc trunk/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/60401.cc - copied, changed from r232581, trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/c_compatibility/math.h trunk/libstdc++-v3/include/c_compatibility/stdlib.h trunk/libstdc++-v3/include/c_global/cmath trunk/libstdc++-v3/include/c_global/cstdlib trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc
[Bug driver/69361] Nonsensical suggestion for misspelled command-line option "-help"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69361
--- Comment #3 from David Malcolm ---
(gdb) p switches[1]
$6 = {part1 = 0x53419d "h", args = 0x7dde70, live_cond = 0, known = true,
validated = false, ordering = false}
So "-h" is "known", but not "validated", but
driver::handle_unrecognized_options uses "validated".
[Bug driver/69367] New: spec file documentation is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69367 Bug ID: 69367 Summary: spec file documentation is incomplete Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- When I was trying to puzzle out the meaning of a spec string using the %n escape, I noticed that the documentation of spec file syntax in the GCC manual does not describe that syntax, and comparing it with the comments in gcc.c it appears a number of other %-escapes are missing documentation as well. Are all of the %-escapes intended to be user-visible? I'm wondering if the spec file documentation really ought to be moved to the internals or installation manual, for that matter. I've seen the --with-specs configure option used, but do real users really use the -specs= option to override the specs GCC was configured with?
[Bug driver/69361] Nonsensical suggestion for misspelled command-line option "-help"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69361 --- Comment #2 from David Malcolm --- Notes to self: Trying to locate the "-h" option. grep -nH -e "^h" *.opt common.opt:2759:h which is: h Driver Joined Separate it was added in r166155 (37ef985f35a963f06b8112872899cb9d6811969) which suggests it's a shorthand for --soname on FreeBSD.
[Bug target/68959] Test case ICEs with -mlra -mvsx-timode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68959
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-19
Ever confirmed|0 |1
--- Comment #6 from Martin Sebor ---
I don't see it on a big-endian powerpc64 even with -mlra -mvsx -mvsx-timode but
I can reproduce/confirm it with those options on powerpc64le (I did miss those
on my first attempt).
$ cat u.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-S -mlra -mvsx-timode u.c
typedef union { _Decimal128 a; } u_t;
extern u_t fn2 (u_t);
u_t
fn1 (void)
{
return fn2 (fn1 ());
}
u.c: In function ‘fn1’:
u.c:7:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)
}
^
0x10a72f87 lra_constraints(bool)
/src/gcc/trunk/gcc/lra-constraints.c:4336
0x10a53127 lra(_IO_FILE*)
/src/gcc/trunk/gcc/lra.c:2277
0x109d0cc7 do_reload
/src/gcc/trunk/gcc/ira.c:5393
0x109d1383 execute
/src/gcc/trunk/gcc/ira.c:5564
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/67755] [5 Regression] Bad edge probability/block freqency for tree jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67755 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Backported to gcc-5 branch as well.
[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 --- Comment #9 from Jack Howarth --- I suspect the current problem is from... // Declare all libitm symbols we rely on, but make them weak so that we do // not depend on libitm. in libstdc++-v3/src/c++11/cow-stdexcept.cc. There needs to be an explicit linkage on libitm to resolve these symbols for the build/genpreds executable.
[Bug testsuite/69366] New: All MPX tests are unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69366 Bug ID: 69366 Summary: All MPX tests are unsupported Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ienkovich at gcc dot gnu.org Target Milestone: --- check_effective_target_mpx checks if "-fcheck-pointer-bounds -mmpx" can link. Since the target directory isn't added to link, I got spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ mpx25592.c -fno-diagnostics-show-caret -fdiagnostics-color=never -fcheck-pointer-bounds -mmpx -lm -o mpx25592.exe^M /usr/local/bin/ld: cannot find -lmpx^M /usr/local/bin/ld: cannot find -lmpxwrappers^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 output is: /usr/local/bin/ld: cannot find -lmpx^M /usr/local/bin/ld: cannot find -lmpxwrappers^M collect2: error: ld returned 1 exit status^M UNSUPPORTED: gcc.target/i386/pr64805.c
[Bug jit/69144] Some libgccjit API entrypoints leave files in /tmp/libgccjit-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69144 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed on trunk (for gcc 6) as of r232582. The fix is probably applicable to the gcc 5 branch, but AIUI that branch is only open for regression fixes and documentation fixes, which isn't the case for this. Closing this out as resolved.
[Bug jit/69144] Some libgccjit API entrypoints leave files in /tmp/libgccjit-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69144 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Tue Jan 19 20:37:19 2016 New Revision: 232582 URL: https://gcc.gnu.org/viewcvs?rev=232582&root=gcc&view=rev Log: PR jit/69144: Ensure that libgccjit's tempdir is fully cleaned-up There were a couple of ways that libgccjit could fail to unlink all of its tempfiles, leading to /tmp/libgccjit-* tempdirs lingering after the build: - dumpfiles requested by gcc_jit_context_enable_dump - ahead-of-time compilation artifacts which lingered in the tempdir after they've been copied up to the output_path. This was only the case for GCC_JIT_OUTPUT_KIND_OBJECT_FILE and GCC_JIT_OUTPUT_KIND_EXECUTABLE. The following patch fixes these by introducing a vec of additional cleanups to be performed by gcc:jit::tempdir's dtor. In addition, if a gcc_jit_result * is leaked and GCC_JIT_BOOL_OPTION_DEBUGINFO is enabled, the tempdir will also not be cleaned up. This was the case for tut04-toyvm/toyvm.cc which the patch fixes by introducing a wrapper around gcc_jit_result *. Doing this required some updates to the corresponding docs. gcc/jit/ChangeLog: PR jit/69144 * jit-playback.c (gcc::jit::playback::compile_to_file::postprocess): Potentially add the temporary artifact to the tempdir's list of tempfiles needing additional cleanup. (gcc::jit::playback::context::extract_any_requested_dumps): Likewise for the dumpfile. * jit-tempdir.c (gcc::jit::tempdir::~tempdir): Clean up additional tempfiles. * jit-tempdir.h (gcc::jit::tempdir::add_temp_file): New method. (gcc::jit::tempdir::m_tempfiles): New field. * docs/cp/intro/tutorial04.rst: Update for changes to toyvm.cc. * docs/examples/tut04-toyvm/toyvm.cc (class compilation_result): New. (toyvm_function::compile): Change return type from function ptr to a compilation_result. (toyvm_function::get_function_name): New accessor. (toyvm_function::m_funcname): New field. (get_function_name): Convert to... (toyvm_function::make_function_name): ...this new method. (toyvm_function::parse): Call make_function_name. (toyvm_function::compile): Convert return type from function ptr to a compilation_result. Use get_function_name. (compilation_state::compile): Convert return type from gcc_jit_result * to a compilation_result. (test_script): Update for above changes, extracting the code from the compilation_result. (main): Likewise. * docs/_build/texinfo/libgccjit.texi: Regenerate. Modified: trunk/gcc/jit/ChangeLog trunk/gcc/jit/docs/_build/texinfo/libgccjit.texi trunk/gcc/jit/docs/cp/intro/tutorial04.rst trunk/gcc/jit/docs/examples/tut04-toyvm/toyvm.cc trunk/gcc/jit/jit-playback.c trunk/gcc/jit/jit-tempdir.c trunk/gcc/jit/jit-tempdir.h
[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #8 from Jack Howarth ---
(In reply to torvald from comment #7)
> Does this patch fix the issue on Darwin?
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01452.html
The proposed patch for libstdc++-v3/src/c++11/cow-stdexcept.cc is incomplete.
You missed the additional required change of...
@@ -385,7 +387,7 @@
} \
void \
_ZGTtNSt##NAME##C2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE( \
-CLASS*, const std::__sso_string&) __attribute__((alias \
+CLASS*, const std::__sso_string&) __attribute__((weak, alias
\
("_ZGTtNSt" #NAME \
"C1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE"))); \
void \
Note however that the compilation of libstdc++-v3/src/c++11/cow-stdexcept.cc on
x86_64-apple-darwin15 does produce warnings of the form...
warning: alias definitions not supported in Mach-O; ignored
and then the bootstrap fails later at...
make[3]: Nothing to be done for `all'.
/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/./prev-gcc/xg++
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc6/x86_64-apple-darwin15.4.0/bin/ -nostdinc++
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/libsupc++/.libs
-I/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/include/x86_64-apple-darwin15.4.0
-I/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc6-6.0.0-1/gcc-6-20160119/libstdc++-v3/libsupc++
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/libsupc++/.libs
-g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc
-Wl,-no_pie -o build/genpreds \
build/genpreds.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/hash-table.o build/read-md.o build/errors.o .././libiberty/libiberty.a
Undefined symbols for architecture x86_64:
"__ITM_RU1", referenced from:
_txnal_cow_string_C1_for_exceptions(void*, char const*, void*) in
libstdc++.a(cow-stdexcept.o)
"__ITM_RU8", referenced from:
_txnal_cow_string_c_str(void const*) in libstdc++.a(cow-stdexcept.o)
_txnal_sso_string_c_str(void const*) in libstdc++.a(cow-stdexcept.o)
_txnal_cow_string_D1(void*) in libstdc++.a(cow-stdexcept.o)
transaction clone for
std::logic_error::logic_error(std::__cxx11::basic_string, std::allocator > const&) in
libstdc++.a(cow-stdexcept.o)
transaction clone for std::logic_error::what() const in
libstdc++.a(cow-stdexcept.o)
transaction clone for
std::domain_error::domain_error(std::__cxx11::basic_string, std::allocator > const&) in
libstdc++.a(cow-stdexcept.o)
transaction clone for
std::invalid_argument::invalid_argument(std::__cxx11::basic_string, std::allocator > const&) in
libstdc++.a(cow-stdexcept.o)
...
"__ITM_addUserCommitAction", referenced from:
_txnal_cow_string_D1(void*) in libstdc++.a(cow-stdexcept.o)
"__ITM_memcpyRnWt", referenced from:
transaction clone for std::logic_error::logic_error(char const*) in
libstdc++.a(cow-stdexcept.o)
transaction clone for
std::logic_error::logic_error(std::__cxx11::basic_string, std::allocator > const&) in
libstdc++.a(cow-stdexcept.o)
transaction clone for std::domain_error::domain_error(char const*) in
libstdc++.a(cow-stdexcept.o)
transaction clone for
std::domain_error::domain_error(std::__cxx11::basic_string, std::allocator > const&) in
libstdc++.a(cow-stdexcept.o)
transaction clone for std::invalid_argument::invalid_argument(char
const*) in libstdc++.a(cow-stdexcept.o)
transaction clone for
std::invalid_argument::invalid_argument(std::__cxx11::basic_string, std::allocator > const&) in
libstdc++.a(cow-stdexcept.o)
transaction clone for std::length_error::length_error(char const*) in
libstdc++.a(cow-stdexcept.o)
...
"__ITM_memcpyRtWn", referenced from:
_txnal_cow_string_C1_for_exceptions(void*, char
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 --- Comment #5 from Jeffrey A. Law --- So the most glaring problem is that we're trying awful hard to find jump threads that ultimately we're going to have to throw away anyway. We're being asked to find jump threads to determine a constant value for an SSA_NAME that is used in an abnormal PHI. While there are cases where in theory that ought to work, we've traditionally rejected jump threads if any of the edges in the thread path or copied blocks are abnormals. The FSM threader is missing those checks, thus it spends an awful lot of time running around in circles in the relatively complex CFG (it's large due to the number of blocks, but also because there's a computed jump inside). I'd bet that if we were to compare gcc-4.9 to gcc-5 we'd see a significant compile-time regression there too, but not as painful as gcc-5 to the current trunk. So I gave up waiting on the current trunk to complete, so call it 19 minutes or whatever, doesn't really matter. r228736 takes ~45 seconds. Filtering out the paths early, ~35 seconds, with nearly 25% of that in the SSA & statement verification code. That's what I'll throw into testing...
[Bug libstdc++/69365] LWG DR2367 (constrained pair default constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69365 Jonathan Wakely changed: What|Removed |Added CC||ville at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- For the record it was fixed on trunk by r229699. I don't know if that patch would apply cleanly on the branch, or if we even want to try.
[Bug libstdc++/69365] New: LWG DR2367 (constrained pair default constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69365 Bug ID: 69365 Summary: LWG DR2367 (constrained pair default constructor) Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: Casey at Carter dot net Target Milestone: --- There's a bug report for range-v3 (https://github.com/ericniebler/range-v3/issues/275) that results from libstdc++ in the GCC-5 branch not implementing the resolution of LWG2367 (constraining the default constructor of std::pair & std::tuple). I'm aware that 2367 is fixed on trunk - is there any possibility of the fix being backported to gcc-5-branch?
[Bug c++/69364] New: [concepts] failure to properly order constraints when using fold expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69364
Bug ID: 69364
Summary: [concepts] failure to properly order constraints when
using fold expressions
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
The below code produces an ambiguous overload error.
I'm not completely sure if the concept-lite standard dictates that it should
compile (see discussion:
http://stackoverflow.com/questions/34843745/how-are-fold-expressions-used-in-the-partial-ordering-of-constraints),
but it seems like it ought to work.
///
#include
#include
template concept bool A = std::is_move_constructible::value;
template concept bool B = std::is_copy_constructible::value;
template concept bool C = A && B;
template
requires A<_a> && A<_b>
void f(_a a, _b b) {
std::cout << "a\n";
}
template
requires C<_a> && C<_b>
void f(_a a, _b b) {
std::cout << "c\n";
}
template
requires (A<_tx> && ...)
void g(_tx... tx) {
std::cout << "a\n";
}
template
requires (C<_tx> && ...)
void g(_tx... tx) {
std::cout << "c\n";
}
int main() {
f(3, 7.0); // works with no fold expressions
g(3, 7.0); // ambiguous overload error
return 0;
}
///
[Bug target/68959] Test case ICEs with -mlra -mvsx-timode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68959 --- Comment #5 from Bill Schmidt --- Martin, did you specify -mlra and -mvsx-timode? Peter's compiler is a test one that turns these on by default. Just want to be sure we're comparing the same things.
[Bug target/68959] Test case ICEs with -mlra -mvsx-timode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68959 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- I don't see the error on trunk with either test case on either BE or LE. Can this be closed?
[Bug lto/66273] [5 Regression] FAIL: gcc.dg/guality/pr43177.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66273 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- It always fails on GCC 5 with GDB 7.10.1.
[Bug target/69031] ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC -fselective-scheduling and __builtin_setjmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- I can't reproduce it with the native powerpc64 compiler on trunk.
[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 --- Comment #7 from torvald at gcc dot gnu.org --- Does this patch fix the issue on Darwin? https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01452.html
[Bug rtl-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68990 --- Comment #6 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #4) > I think the problem is: > ** Pseudos coalescing #1: ** > > Coalescing move 5:r91(91)-r103(103) (freq=1) > Removing move 5 (freq=1) > deleting insn with uid = 5. > Make unique value for inheritance r256 > Make unique value for inheritance r257 > Make unique value for inheritance r258 > Make unique value for inheritance r259 > Make unique value for inheritance r260 > Make unique value for inheritance r262 > Make unique value for inheritance r264 > Coalesced Moves = 1 > > in the other spot where insn 5 is it is perhaps possible to coalesce the two > pseudos, but not at the > int m = -b; > if (m < b) > comparison, where it breaks it. I've reproduced the bug and checked the coalescing. The coalescing seems the right transformation as p91 becomes dead right before insn#30 and actually its value before insn#30 through an inheritance pseudo is used in insn #31. The problem actually occurs later in pseudo assignment sub-pass. I suspect that something is wrong with pseudo values. Changes affecting pseudo values much affect the performance much. So when I have the patch, I need to check the performance impact too. I think if it is everything ok, the patch will be ready at the end of week.
[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 --- Comment #6 from torvald at gcc dot gnu.org --- (In reply to Jack Howarth from comment #5) > (In reply to torvald from comment #4) > > > See https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01203.html > > (Not linked to this bug because this bug is about the darwin breakage.) > > The commit of that patch didn't resolve the bootstrap failures on > x86_64-apple-darwin15 . The "only weak aliases are supported in this > configuration" errors still block the bootstrap on darwin. Of course they don't. This was a reply to a comment about another issue not actually related to the bug, but posted as comment on this bug.
[Bug c++/69363] New: ICE when doing a pragma simd reduction with max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69363
Bug ID: 69363
Summary: ICE when doing a pragma simd reduction with max
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
The below code causes this ICE:
rnburn@localhost ~/test/cilk_reduction $ /usr/local/experimental/bin/g++
-fcilkplus -O3 -march=native -c -S bug.cpp
bug.cpp: In function ‘double t1(double*, int)’:
bug.cpp:7:3: internal compiler error: Segmentation fault
for(int i=0; ihttp://gcc.gnu.org/bugs.html> for instructions.
//
#include
double t1(double* x, int N) {
double result = 0;
int i;
#pragma simd reduction(max:result) private(i)
for(int i=0; i
[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 37395 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37395&action=edit A provisional patch for the PR This fixes the immediate problem. I think some tidying up of unlimited polymorphism is needed. In any case, I am not in a position to commit for some days. Cheers Paul
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 --- Comment #17 from Jason Merrill --- Author: jason Date: Tue Jan 19 19:00:21 2016 New Revision: 232580 URL: https://gcc.gnu.org/viewcvs?rev=232580&root=gcc&view=rev Log: PR c++/59759 * pt.c (convert_template_argument): Handle VAR_DECL properly. Added: trunk/gcc/testsuite/g++.dg/cpp0x/temp_default6.C trunk/gcc/testsuite/g++.dg/cpp0x/temp_default7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 Jack Howarth changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #5 from Jack Howarth --- (In reply to torvald from comment #4) > See https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01203.html > (Not linked to this bug because this bug is about the darwin breakage.) The commit of that patch didn't resolve the bootstrap failures on x86_64-apple-darwin15 . The "only weak aliases are supported in this configuration" errors still block the bootstrap on darwin.
[Bug testsuite/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68820 --- Comment #16 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jan 19 18:27:19 2016 New Revision: 232577 URL: https://gcc.gnu.org/viewcvs?rev=232577&root=gcc&view=rev Log: PR testsuite/68820 * gcc.c-torture/execute/builtins/memops-asm.x: New file. * gcc.c-torture/execute/builtins/strstr-asm.x: Ditto. * gcc.c-torture/execute/builtins/strstr-asm.c: Remove dg-options. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/builtins/memops-asm.x branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm.x Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm.c
[Bug c++/69362] New: ICE when doing a pragma reduction with the wrong variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69362
Bug ID: 69362
Summary: ICE when doing a pragma reduction with the wrong
variable
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
The below code when compiled with -fcilkplus gives the following ICE:
main.cpp: In function ‘double t1(double*, int)’:
main.cpp:4:3: internal compiler error: in build2_stat, at tree.c:4433
for(int i=0; ihttp://gcc.gnu.org/bugs.html> for instructions.
double t1(double* x, int N) {
double result = 0;
#pragma simd reduction(+:x)
for(int i=0; i
[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66232 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed.
[Bug lto/66273] [5 Regression] FAIL: gcc.dg/guality/pr43177.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66273 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-19 Summary|[6 Regression] FAIL:|[5 Regression] FAIL: |gcc.dg/guality/pr43177.c|gcc.dg/guality/pr43177.c Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- It is fixed on trunk, but regressed on GCC 5 branch: https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01751.html
[Bug lto/66273] [6 Regression] FAIL: gcc.dg/guality/pr43177.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66273 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Not seeing these either in my testresults, or in the testresults you are posting, since early July last year or so. Can this be closed?
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 --- Comment #16 from Martin Sebor --- Kai's patch with the small from comment #15 test case posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01446.html
[Bug driver/69361] Nonsensical suggestion for misspelled command-line option "-help"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69361 --- Comment #1 from David Malcolm --- Similarly: $ gcc -h foo gcc: error: unrecognized command line option ‘-h’; did you mean ‘-h’? gcc: fatal error: no input files compilation terminated.
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 --- Comment #4 from Jeffrey A. Law --- We've got function with something like 15k blocks. One particular block as ~3k predecessors. Clearly something in the FSM bits isn't scaling. I've already fixed one bug in this space a few months ago and I'm not surprised we're finding more now that we're using the FSM threader more aggressively. Still investigating.
[Bug driver/69361] New: Nonsensical suggestion for misspelled command-line option "-help"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69361 Bug ID: 69361 Summary: Nonsensical suggestion for misspelled command-line option "-help" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Seen with gcc (GCC) 6.0.0 20151217 (experimental): $ gcc -help gcc: error: unrecognized command line option ‘-h’; did you mean ‘-h’? gcc: fatal error: no input files compilation terminated.
[Bug tree-optimization/66740] [6 Regression] omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Jakub Jelinek --- Please reopen if you can still reproduce and have an executable testcase on which we can actually reproduce it.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The code is indeed invalid on two counts. The first one is named commons of different sizes (related to/duplicate of pr44882). The second is out of bound access: the array 'e' is defined with only one element, accessing e(2) is invalid (caught if the code is compiled with -fcheck=bounds). Thus the compiler can do whatever it wants, e.g., considers that the loop is run only once. This should be disabled by the option no-aggressive-loop-optimizations, but it is not.
[Bug testsuite/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68820 --- Comment #15 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jan 19 17:51:38 2016 New Revision: 232575 URL: https://gcc.gnu.org/viewcvs?rev=232575&root=gcc&view=rev Log: PR testsuite/68820 * gcc.c-torture/execute/builtins/memops-asm.x: New file. * gcc.c-torture/execute/builtins/strstr-asm.x: Ditto. * gcc.c-torture/execute/builtins/strstr-asm.c: Remove dg-options. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/builtins/memops-asm.x branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm.x Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm.c
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Last reconfirmed|2014-09-26 00:00:00 |2016-1-19
CC||msebor at gcc dot gnu.org
Known to fail||6.0
--- Comment #15 from Martin Sebor ---
Today's trunk still crashes on the (invalid) test case in comment #7. Below is
an ever so slightly more reduced test case that reproduces the failure. The
patch from comment #11 still fixes the ICE and produces the following output:
u.c: In function ‘void f(A*)’:
u.c:16:8: error: ‘class C, int>::U’ resolves to ‘C, int>::U {aka
int}’, which is is not a class type
A* map;
^
u.c:17:9: error: no matching function for call to ‘f(A*&)’
f (map);
^
u.c:15:6: note: candidate: template void f(A*)
void f (A*) {
^
u.c:15:6: note: template argument deduction/substitution failed:
u.c:17:9: note: template argument ‘0’ does not match ‘x’
f (map);
^
Slightly reduced test case:
$ cat u.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -xc++ u.c
template
struct B { };
template
struct C {
typedef T U;
};
const int x = 0;
template , int>::U = x>
struct A;
template
void f (A*) {
A* map;
f (map);
}
u.c: In function ‘void f(A*)’:
u.c:16:8: error: ‘class C, int>::U’ resolves to ‘C, int>::U {aka
int}’, which is is not a class type
A* map;
^
u.c: In substitution of ‘template void f(A*) [with T = ]’:
u.c:17:9: required from here
u.c:17:9: internal compiler error: in unify, at cp/pt.c:19935
f (map);
^
0x10440953 unify
/src/gcc/trunk/gcc/cp/pt.c:19935
0x1043f30b unify
/src/gcc/trunk/gcc/cp/pt.c:19768
0x104384a7 try_class_unification
/src/gcc/trunk/gcc/cp/pt.c:18772
0x1043f803 unify
/src/gcc/trunk/gcc/cp/pt.c:19806
0x1043eb77 unify
/src/gcc/trunk/gcc/cp/pt.c:19672
0x10435643 unify_one_argument
/src/gcc/trunk/gcc/cp/pt.c:18121
0x10435983 type_unification_real
/src/gcc/trunk/gcc/cp/pt.c:18195
0x104334a7 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
/src/gcc/trunk/gcc/cp/pt.c:17623
0x1032e533 add_template_candidate_real
/src/gcc/trunk/gcc/cp/call.c:3091
0x1032ea8f add_template_candidate
/src/gcc/trunk/gcc/cp/call.c:3169
0x10338b3f add_candidates
/src/gcc/trunk/gcc/cp/call.c:5341
0x10332893 perform_overload_resolution
/src/gcc/trunk/gcc/cp/call.c:4026
0x10332c1f build_new_function_call(tree_node*, vec**, bool, int)
/src/gcc/trunk/gcc/cp/call.c:4103
0x105f857b finish_call_expr(tree_node*, vec**,
bool, bool, int)
/src/gcc/trunk/gcc/cp/semantics.c:2413
0x10500dbb cp_parser_postfix_expression
/src/gcc/trunk/gcc/cp/parser.c:6884
0x10503d5f cp_parser_unary_expression
/src/gcc/trunk/gcc/cp/parser.c:7964
0x1050516b cp_parser_cast_expression
/src/gcc/trunk/gcc/cp/parser.c:8641
0x10505293 cp_parser_binary_expression
/src/gcc/trunk/gcc/cp/parser.c:8743
0x105064a7 cp_parser_assignment_expression
/src/gcc/trunk/gcc/cp/parser.c:9031
0x10506a2b cp_parser_expression
/src/gcc/trunk/gcc/cp/parser.c:9198
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223 --- Comment #12 from Jakub Jelinek --- Your call. Anyway, I'd appreciate if for -fsanitize=undefined we could make sure that __cxa_pure_virtual will be called in all cases in which it would be called without optimizing, rather than just for the most common cases. Whether we guard that by flag_sanitize & SANITIZE_UNREACHABLE or SANITIZE_PURE_VIRTUAL doesn't matter that much.
