[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401 --- Comment #7 from Eric Gallager --- (In reply to Thomas Petazzoni from comment #6) > I see Eric Gallager added bug 68538 in the "See also" section. However, I > don't see how they can be related: 68538 has been fixed, and the fix was > only in CRIS-specific files. > > This bug however is only about Microblaze, so I don't see how it can be > related to a bug that was fixed in CRIS-specific code. Sorry, I just assumed that since you said previously: (In reply to Thomas Petazzoni from comment #0) > > This bug might be related to bug #68538 (same error message), but it happens > on Microblaze and not CRIS. ...that I could take you at your word for it that they might be related.
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #1 from The Written Word --- I get a similar error with 8.1.0.
[Bug fortran/86599] New: Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
Bug ID: 86599
Summary: Problems building libgfortran from 7.2.0 on HP-UX
11.31/PA
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla-gcc at thewrittenword dot com
Target Milestone: ---
I tried building gcc-7.2.0 on HP-UX 11.31/PA as follows:
$ gtar Jxf gcc-7.2.0.tar.xz
$ cd gcc-7.2.0
$ mkdir .obj
$ cd .obj
$ PATH=/opt/TWWfsw/gcc49/bin:$PATH ../configure \
SHELL=/opt/fsw/bash42/bin/bash --enable-nls --with-included-gettext \
--enable-shared --enable-languages=c,c++,fortran \
--with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \
--with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
--with-gnu-as --with-as=/opt/TWWfsw/gcc7/hppa2.0-hp-hpux11.31/bin/as \
--with-local-prefix=/tmp/gcc7 --prefix=/tmp/gcc7
...
$ PATH=/opt/TWWfsw/gcc49/bin:$PATH \
ac_cv_prog_OBJCOPY="/opt/TWWfsw/gcc7/bin/gobjcopy" \
ac_cv_prog_OBJDUMP="/opt/TWWfsw/gcc7/bin/gobjdump" gmake
The build failed with the following:
libtool: compile: /opt/build/china/gcc-7.2.0/.obj/./gcc/xgcc
-B/opt/build/china
/gcc-7.2.0/.obj/./gcc/ -B/tmp/gcc7/hppa2.0w-hp-hpux11.31/bin/
-B/tmp/gcc7/hppa2.
0w-hp-hpux11.31/lib/ -isystem /tmp/gcc7/hppa2.0w-hp-hpux11.31/include -isystem
/
tmp/gcc7/hppa2.0w-hp-hpux11.31/sys-include -DHAVE_CONFIG_H -I.
-I/opt/build/chin
a/gcc-7.2.0/libgfortran -iquote/opt/build/china/gcc-7.2.0/libgfortran/io
-I/opt/
build/china/gcc-7.2.0/libgfortran/../gcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../gcc/config
-I/opt/build/china/gcc-7.2.0/libgfortran/../libquadmath -I../.././gcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../libgcc -I../libgcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -g -O2 -MT
read.lo -MD -MP -MF .deps/read.Tpo -c
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c -fPIC -DPIC -o .libs/read.o
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c: In function 'convert_real':
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c:177:30: error: incompatible
types when assigning to type 'GFC_REAL_16 {aka long double}' from type
'long_double {aka struct }'
*((GFC_REAL_16*) dest) = gfc_strtold (buffer, );
^
gmake[3]: *** [read.lo] Error 1
gmake[3]: Leaving directory
`/opt/build/china/gcc-7.2.0/.obj/hppa2.0w-hp-hpux11.31/libgfortran'
I was able to build on HP-UX 11.23/PA.
[Bug c++/86598] New: Incorrect lexing of pp-numbers in C++11 due to hexfloat extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86598
Bug ID: 86598
Summary: Incorrect lexing of pp-numbers in C++11 due to
hexfloat extension
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
g++ support C99 hexadecimal literals as an extension in its C++ modes. This is
*almost* a conforming extension in C++98 mode, but it's far from being one in
C++11 mode. For instance, in C++98:
#define PREFIX(x) foo ## x
void f() {
int PREFIX(1p);
int PREFIX(2p) = PREFIX(1p+5);
}
g++ rejects the above code:
code2.cpp:1:19: error: pasting "foo" and "1p+5" does not give a valid
preprocessing token
#define PREFIX(x) foo ## x
^~~
code2.cpp:4:19: note: in expansion of macro 'PREFIX'
int PREFIX(2p) = PREFIX(1p+5);
^~
code2.cpp: In function 'void f()':
code2.cpp:1:19: error: 'foo' was not declared in this scope
#define PREFIX(x) foo ## x
^~~
code2.cpp:4:19: note: in expansion of macro 'PREFIX'
int PREFIX(2p) = PREFIX(1p+5);
^~
code2.cpp:1:19: note: suggested alternative: 'foo2p'
#define PREFIX(x) foo ## x
^~~
code2.c.cpp:4:19: note: in expansion of macro 'PREFIX'
int PREFIX(2p) = PREFIX(1p+5);
^~
In the rules of C++, "1p+5" is three tokens, not one.
In C++11, this goes wrong in much less contrived situations:
Units operator"" _amp(unsigned long long d);
int k = 4_amp+1; // incorrect error: no literal operator "" _amp+1
BTW, clang++ accepts the above code.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #24 from Matt Bentley --- Ugh. I made a mistake. Clang only throws the warning when comparing NULL with 0 without reinterpret_cast/static_cast, not when comparing pointers in general.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #23 from Matt Bentley --- > Actually, don't quote me on that - I may be thinking of the > 'reinterpret_cast<_Tp>(0)' - one of the two. Just to confirm, "reinterpret_cast(__first)" not required in this context, either "reinterpret_cast<_Tp>(0)" or "static_cast<_Tp>(0)" *are* required to avoid warnings in clang when _Tp is a pointer. Either works fine. I understand that reinterpret_cast isn't allowed inside constexpr, but not why, and can't find any resources explicitly stating the reasoning. But __builtin_constant_p allows it, so it's use is a matter of programmer choice, at least in this context.
[Bug libstdc++/86597] New: directory_entry::exist et al forget to clear the error_code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86597
Bug ID: 86597
Summary: directory_entry::exist et al forget to clear the
error_code.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric at efcs dot ca
Target Milestone: ---
The "file type observers" of directory entry like exists and is_regular_file
don't clear the error code they are given when no errors occurs.
Reproducer:
#include
#include
using namespace std::filesystem;
using namespace std;
int main() {
error_code ec = make_error_code(errc::address_in_use);
directory_entry ent("/tmp");
assert(ent.exists(ec));
assert(!ec);
}
https://wandbox.org/permlink/TpQwW1VwBosGaHXZ
[Bug c++/86596] narrowing for template arugments not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86596 --- Comment #1 from Andrew Pinski --- Most likely a dup of bug 57891.
[Bug c++/86596] New: non-type template argument evaluates to an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86596
Bug ID: 86596
Summary: non-type template argument evaluates to an integer
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
template struct A {};
typedef A<255> B;
int main() { return 0; }
g++ accepts the code, but clang++ rejects it:
char.cpp:3:11: error: non-type template argument evaluates to 255, which
cannot be narrowed to type 'char' [-Wc++11-narrowing]
typedef A<255> B;
^
1 error generated.
The code looks illegal, so the diagnose of clang++ is right?
[Bug libstdc++/86595] New: directory_entry::refresh(error_code&) should be noexcept.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86595 Bug ID: 86595 Summary: directory_entry::refresh(error_code&) should be noexcept. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- According to the current specification, the error_code version of directory_entry::refresh should be marked noexcept [1]. Libstdc++ incorrectly omits the `noexcept`. [1] http://eel.is/c++draft/fs.dir.entry.mods#4
[Bug c++/86594] New: Crash on trying to capture 'this' in instantiation of generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86594
Bug ID: 86594
Summary: Crash on trying to capture 'this' in instantiation of
generic lambda
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
#include
template
constexpr void for_sequence(std::integer_sequence, F&& f) {
using unpack_t = int[];
(void)unpack_t{(static_cast(f(std::integral_constant{})),
0)..., 0};
}
template
struct MyType {
void crash() {
for_sequence(std::make_index_sequence::value>{}, [&](auto
i){
make_crash();
});
}
template
void make_crash() {}
};
int main() {
MyType> test;
test.crash();
}
g++ crashes with the following messages:
crash.cpp: In instantiation of 'MyType::crash() [with Tup =
std::tuple]:: [with auto:1 =
std::integral_constant]':
2CPPfilethattriggerthecrash.cpp:6:37: required from 'constexpr void
for_sequence(std::integer_sequence, F&&) [with T = long unsigned int;
T ...S = {0, 1, 2, 3}; F = MyType::crash() [with Tup = std::tuple]::]'
2CPPfilethattriggerthecrash.cpp:12:15: required from 'void
MyType::crash() [with Tup = std::tuple]'
2CPPfilethattriggerthecrash.cpp:24:13: required from here
2CPPfilethattriggerthecrash.cpp:13:4: internal compiler error: trying to
capture 'this' in instantiation of generic lambda
make_crash();
^~
0x90c905 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc9.0/gcc/cp/lambda.c:648
0x90ca5e add_default_capture(tree_node*, tree_node*, tree_node*)
../../gcc9.0/gcc/cp/lambda.c:714
0x90cf01 lambda_expr_this_capture(tree_node*, bool)
../../gcc9.0/gcc/cp/lambda.c:819
0x90d670 maybe_resolve_dummy(tree_node*, bool)
../../gcc9.0/gcc/cp/lambda.c:902
0x85762a build_new_method_call_1
../../gcc9.0/gcc/cp/call.c:9416
0x85762a build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc9.0/gcc/cp/call.c:9531
0x9adcb8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc9.0/gcc/cp/pt.c:18491
0x991329 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc9.0/gcc/cp/pt.c:17431
0x99166d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc9.0/gcc/cp/pt.c:16630
0x991390 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc9.0/gcc/cp/pt.c:16915
0x991390 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc9.0/gcc/cp/pt.c:16915
0x991390 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc9.0/gcc/cp/pt.c:16915
0x9bf24e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc9.0/gcc/cp/pt.c:16601
0x9bf24e instantiate_decl(tree_node*, bool, bool)
../../gcc9.0/gcc/cp/pt.c:24075
0x8e603b maybe_instantiate_decl
../../gcc9.0/gcc/cp/decl2.c:5173
0x8e8167 mark_used(tree_node*, int)
../../gcc9.0/gcc/cp/decl2.c:5323
0x854e8e build_over_call
../../gcc9.0/gcc/cp/call.c:8325
0x862b2a build_op_call_1
../../gcc9.0/gcc/cp/call.c:4602
0x862b2a build_op_call(tree_node*, vec**, int)
../../gcc9.0/gcc/cp/call.c:4631
0x9d95ad finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc9.0/gcc/cp/semantics.c:2553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 --- Comment #1 from Carl Love --- The builtins-1.c test fails on AIX. Again looks like the count should be 1 not 7 for AIX and linux. There is an additional failure on AIX for test file altivec-1-runnable.c. Looks like the compiler options for AIX are not correct to compile variables declared as type double.
[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|[6/7/8/9 Regression]|[6/7/8 Regression] missing |missing -Warray-bounds on |-Warray-bounds on an |an out-of-bounds index into |out-of-bounds index into an |an array|array --- Comment #9 from Martin Sebor --- Committed into GCC 9.0 in r262893. All the test cases in this bug are now diagnosed. Not sure if the fix will be approved for backporting though.
[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776 Martin Sebor changed: What|Removed |Added Summary|[6/7/8/9 Regression]|[6/7/8 Regression] missing |missing -Warray-bounds |-Warray-bounds indexing |indexing past the end of a |past the end of a string |string literal |literal --- Comment #7 from Martin Sebor --- Committed into GCC 9.0 in r262893.
[Bug tree-optimization/84047] [6/7/8/9 Regression] missing -Warray-bounds on an out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047 --- Comment #8 from Martin Sebor --- Author: msebor Date: Thu Jul 19 23:36:34 2018 New Revision: 262893 URL: https://gcc.gnu.org/viewcvs?rev=262893=gcc=rev Log: PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds index into an array PR tree-optimization/83776 - missing -Warray-bounds indexing past the end of a string literal gcc/ChangeLog: PR tree-optimization/84047 PR tree-optimization/83776 * tree-vrp.c (vrp_prop::check_mem_ref): New function. (check_array_bounds): Call it. gcc/testsuite/ChangeLog: PR tree-optimization/83776 PR tree-optimization/84047 * gcc.dg/Warray-bounds-29.c: New test. * gcc.dg/Warray-bounds-30.c: New test. * gcc.dg/Warray-bounds-31.c: New test. * gcc.dg/Warray-bounds-32.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-29.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-30.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-31.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-32.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/83776] [6/7/8/9 Regression] missing -Warray-bounds indexing past the end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776 --- Comment #6 from Martin Sebor --- Author: msebor Date: Thu Jul 19 23:36:34 2018 New Revision: 262893 URL: https://gcc.gnu.org/viewcvs?rev=262893=gcc=rev Log: PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds index into an array PR tree-optimization/83776 - missing -Warray-bounds indexing past the end of a string literal gcc/ChangeLog: PR tree-optimization/84047 PR tree-optimization/83776 * tree-vrp.c (vrp_prop::check_mem_ref): New function. (check_array_bounds): Call it. gcc/testsuite/ChangeLog: PR tree-optimization/83776 PR tree-optimization/84047 * gcc.dg/Warray-bounds-29.c: New test. * gcc.dg/Warray-bounds-30.c: New test. * gcc.dg/Warray-bounds-31.c: New test. * gcc.dg/Warray-bounds-32.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-29.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-30.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-31.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-32.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 --- Comment #16 from Paolo Carlini --- Created attachment 44413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44413=edit Only draft front-end changes, no testcases
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 --- Comment #15 from Paolo Carlini --- Tobias, I'm currently playing with something like the attached, which seems only moderately more complex and passes all my tests so far. If you have ways to further stress it, I would be glad to hear about your findings.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #22 from Matt Bentley --- (In reply to Jonathan Wakely from comment #21) > Surely static_cast is good enough, and doesn't rule out making the function > constexpr? It may well be, how does reinterpret_cast cause constexpr to fail, given that it's also compile-time?
[Bug debug/86593] New: [8.0 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593
Bug ID: 86593
Summary: [8.0 Regression] internal compiler error: in
based_loc_descr, at dwarf2out.c:14272
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: manisandro at gmail dot com
Target Milestone: ---
Following is reproducible using mingw64-gcc-8.1.0-2.fc29 [1] on Fedora Rawhide,
and only when compiling for x86_64-w64-mingw32 (and not i686-w64-mingw32).
I could also reproduce it with gcc-8.2.0-RC-20180719.tar.xz built for mingw64.
I could not reproduce it with native gcc.
The issue also did not appear with mingw64-gcc-7.2.0-1.fc28.x86_64
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1114148
This program:
struct Foo
{
int bar(int a, int b, int c, int d);
};
int Foo::bar(int a, int b, int c, int d)
{
return 0;
}
compiled as
x86_64-w64-mingw32-g++ -O -g -fno-omit-frame-pointer -o test.o -c test.cpp
produces:
during RTL pass: final
test.cpp: In member function 'int Foo::bar(int, int, int, int)':
test.cpp:9:1: internal compiler error: in based_loc_descr, at dwarf2out.c:14272
}
^
All three of "-O -g -fno-omit-frame-pointer" are needed to reproduce the crash.
[Bug c++/86515] std::initializer_list constructor is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86515 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with: commit 27fa846684a0e6d4f52eac665fa05c98a7e4c237 Author: jason Date: Tue May 9 13:48:58 2017 + PR c++/70167 - array prvalue treated as lvalue * cp-tree.h (CONSTRUCTOR_C99_COMPOUND_LITERAL): New. (enum fcl_t): New. * semantics.c (finish_compound_literal): Add fcl_context parameter. Only make a static variable for C99 syntax. * parser.c (cp_parser_postfix_expression): Pass it. * pt.c (tsubst_copy_and_build): Likewise. * call.c (extend_ref_init_temps): Set DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@247793 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/86546] ICE on invalid: tree_class_check_failed()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86546 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/86552] missing warning for reading past the end of non-string arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86552 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01124.html
[Bug c/81851] missing -Wduplicated-branches on if and return statements with no else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81851
--- Comment #5 from Jonathan Wakely ---
Should it warn here?
int g (int i)
{
if (i == 0) // no warning
return 0;
#if SOME_OTHER_PLATFORM
if (i == 2)
return 1;
#endif
return 0;
}
When not compiling for SOME_OTHER_PLATFORM this ends up being equivalent to
your original g, do you want this to warn?
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480
--- Comment #14 from Paolo Carlini ---
Another testcase that we want to accept:
class Matrix;
void rot90 (const Matrix& a, int k = 1) { }
class Matrix {
friend void rot90 (const Matrix&, int);
};
void rot90 (const Matrix& a, int k);
We handle the third occurrence of rot90 as-if the second occurrence in:
class Matrix {
friend void rot90 (const Matrix&, int k = 1) { }
};
void rot90 (const Matrix& a, int k);
and of course we would reject it with my first try.
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #11 from Jonathan Wakely --- (In reply to Eric Gallager from comment #10) > If this is becoming the meta-bug for all warnings that affect codegen, then > I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not > sure if toggling it causes miscompares though) That one is *supposed* to affect codegen (so maybe it should be a -f option instead).
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #4 from Georg-Johann Lay --- Created attachment 44412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44412=edit C test case.
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61579 --- Comment #10 from Eric Gallager --- If this is becoming the meta-bug for all warnings that affect codegen, then I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not sure if toggling it causes miscompares though)
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 --- Comment #17 from alex_y_xu at yahoo dot ca --- seems like this should be RESOLVED FIXED?
[Bug c++/86590] Codegen regression when passing std::string by value in C++ 17 and C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 --- Comment #3 from Jonathan Wakely --- (In reply to Niall Douglas from comment #0) > I think it should also work by value, like it > did in C++ 11 and C++ 14. Alternatively, if the request is for better inlining when there are no explicit instantiation declarations, I'd rephrase this in terms of explicit instantiations / extern templates, not in terms of C++14 vs C++17.
[Bug c++/86590] Codegen regression when passing std::string by value in C++ 17 and C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 --- Comment #2 from Jonathan Wakely --- As Marc said, the only difference is the explicit instantiation declarations. You'll get the same in C++14 if you disable them: #include #undef _GLIBCXX_EXTERN_TEMPLATE #include // ... They're only disabled temporarily for C++17 until our C++17 support is stable, at which point we'll start exporting the new C++17 members of std::string from libstdc++.so and re-enable the explicit instantiation declarations. So there's nothing to do here, except wait for that to happen.
[Bug target/86592] New: [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86592 Bug ID: 86592 Summary: [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The instruction counts are off. make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/p8-vec-xl-xst-v2.c . . . # of expected passes1 # of unexpected failures3 FAIL: gcc.target/powerpc/p8-vec-xl-xst-v2.c scan-assembler-times lvx 4 FAIL: gcc.target/powerpc/p8-vec-xl-xst-v2.c scan-assembler-times stvx 4 FAIL: gcc.target/powerpc/p8-vec-xl-xst-v2.c scan-assembler-times xxpermdi 0
[Bug target/86591] New: [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591 Bug ID: 86591 Summary: [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/builtins-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O0 -mno-fold-gimple -dp -ffat-lto-objects -S -o builtins-1.s gimple folding of rs6000 builtins has been disabled. PASS: gcc.target/powerpc/builtins-1.c (test for excess errors) PASS: gcc.target/powerpc/builtins-1.c scan-assembler-times vcmpequd 8 ... PASS: gcc.target/powerpc/builtins-1.c scan-assembler-times xxlnor 6 gcc.target/powerpc/builtins-1.c: xxlor found 1 times FAIL: gcc.target/powerpc/builtins-1.c scan-assembler-times xxlor 7 PASS: gcc.target/powerpc/builtins-1.c scan-assembler-times \\mvpkudus\\M 1 . . . I think this one just needs the instruction count adjusted.
[Bug c++/86590] Codegen regression when passing std::string by value in C++ 17 and C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 --- Comment #1 from Niall Douglas --- Quoting from bug 86573 regarding this bug: > The real difference in -std=c++17 is _GLIBCXX_EXTERN_TEMPLATE. With > -std=c++14, we have many extern templates which the compiler almost never > inlines. This leaves existing inline functions small enough to be inlined in > main (once it is renamed). With -std=c++17, extern templates are gone, > everything is inlined, and the function that used to be small enough to be > inlined is now too big (several smaller functions have been inlined into it > first). Without inlining, the compiler cannot notice all the simplifications. > (this is in large part guesswork, feel free to verify) > > If someone wants to improve it, I would look into the inliner heuristics, > but that's probably going to be hard.
[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #8 from Niall Douglas --- Added revised bug to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
[Bug c++/86590] New: Codegen regression when passing std::string by value in C++ 17 and C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
Bug ID: 86590
Summary: Codegen regression when passing std::string by value
in C++ 17 and C++ 20
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
If compiled as C++ 14:
#include
inline size_t calc(std::string a, std::string b)
{
return a.size() + b.size();
}
int foo()
{
std::string a = "Hello world", b = "Goodbye world";
return calc(a, b);
}
...one gets:
foo():
mov eax, 24
ret
But if compiled as C++ 17 or later, one gets lots of spew:
https://godbolt.org/g/jCzpAS
Using std::move() generates the right result in C++ 17 or later:
https://godbolt.org/g/tHXpyy. I think it should also work by value, like it did
in C++ 11 and C++ 14.
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 --- Comment #13 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jul 19 16:58:06 2018 New Revision: 262883 URL: https://gcc.gnu.org/viewcvs?rev=262883=gcc=rev Log: 2018-07-19 Paolo Carlini Revert fix for c++/59480 (and testsuite followup) /testsuite 2018-07-19 Paolo Carlini * g++.old-deja/g++.mike/p784.C: Add -fpermissive. /cp 2019-07-18 Paolo Carlini PR c++/59480, DR 136 * decl.c (check_no_redeclaration_friend_default_args): New. (duplicate_decls): Use the latter; also check that a friend declaration specifying default arguments is a definition. /testsuite 2019-07-18 Paolo Carlini PR c++/59480, DR 136 * g++.dg/other/friend8.C: New. * g++.dg/other/friend9.C: Likewise. * g++.dg/other/friend10.C: Likewise. * g++.dg/other/friend11.C: Likewise. * g++.dg/other/friend12.C: Likewise. * g++.dg/parse/defarg4.C: Compile with -fpermissive -w. * g++.dg/parse/defarg8.C: Likewise. Removed: trunk/gcc/testsuite/g++.dg/other/friend10.C trunk/gcc/testsuite/g++.dg/other/friend11.C trunk/gcc/testsuite/g++.dg/other/friend12.C trunk/gcc/testsuite/g++.dg/other/friend8.C trunk/gcc/testsuite/g++.dg/other/friend9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/defarg4.C trunk/gcc/testsuite/g++.dg/parse/defarg8.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p784.C
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 --- Comment #12 from Paolo Carlini --- Umpf. Unfortunately this doesn't work because the second time we see rot90 duplicate_decls smashes together the first two declarations and we end up with a friend declaration which has the defaults and as such is rejected the third time we see rot90. I'll see if getting this right is doable without reworking too much duplicate_decls, for the time being I'm reverting the whole thing and adding the new testcase. Thanks.
[Bug rtl-optimization/85805] [7/8/9 Regression] Wrong code for 64 bit comparisons on avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805 --- Comment #7 from Segher Boessenkool --- I suspect this is because we have hard regs here, not pseudos. Not a good idea in general, which is why other targets don't do this. Perhaps it is a mode mixup in the known value tracking? Confirmed.
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 --- Comment #7 from Alexander Monakov --- Another possible compromise is to add 'bool for_warnings = false' argument to maybe_constant_value, store it along with the reduced tree in cv_cache (perhaps even by setting a flag on the tree itself?), and then when retrieving from cv_cache when !for_warnings, but the retrieved tree has the flag set, throw it away and recompute. That should be a fairly simple change that keeps the current speed when the warnings are disabled or main code generation needs the reduced tree before some of the warnings do.
[Bug c++/85558] ICE in make_rtl_for_nonlocal_decl when using static member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85558
Paolo Carlini changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #3 from Paolo Carlini ---
We ICE also for the following which seems valid to me and doesn't have anything
to do with PR59480:
template
struct triggerBug {
friend void doInitUser(bool = triggerBug::doInit) {}
static bool doInit;
};
template
bool triggerBug::doInit = true;
triggerBug bug;
[Bug target/86589] New: [8 regression] gcc.target/powerpc/altivec-7-le.c and gcc.target/powerpc/vsx-7-be.c fail starting with r262440
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86589 Bug ID: 86589 Summary: [8 regression] gcc.target/powerpc/altivec-7-le.c and gcc.target/powerpc/vsx-7-be.c fail starting with r262440 Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- gcc.target/powerpc/vsx-7-be.c fails on both BE and LE while gcc.target/powerpc/altivec-7-le.c fails only on LE. FAIL: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vupkhpx 1 FAIL: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vupkhpx 1 Executing on host: /home/seurer/gcc/build/gcc-8/gcc/xgcc -B/home/seurer/gcc/build/gcc-8/gcc/ /home/seurer/gcc/gcc-8/gcc/testsuite/gcc.target/powerpc/altivec-7-le.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -ffat-lto-objects -S -o altivec-7-le.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-8/gcc/xgcc -B/home/seurer/gcc/build/gcc-8/gcc/ /home/seurer/gcc/gcc-8/gcc/testsuite/gcc.target/powerpc/ltivec-7-le.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -ffat-lto-objects -S -o altivec-7-le.s PASS: gcc.target/powerpc/altivec-7-le.c (test for excess errors) PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vpkpx 2 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vmulesb 1 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vmulosb 1 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times \\mlxvd2x\\M|\\mlxv\\M 36 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times lvewx 2 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times lvxl 1 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vupklsh 1 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vupkhsh 1 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times xxlnor 4 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times xxland 4 PASS: gcc.target/powerpc/altivec-7-le.c scan-assembler-times xxlxor 5 gcc.target/powerpc/altivec-7-le.c: vupkhpx found 0 times FAIL: gcc.target/powerpc/altivec-7-le.c scan-assembler-times vupkhpx 1 Executing on host: /home/seurer/gcc/build/gcc-8/gcc/xgcc -B/home/seurer/gcc/build/gcc-8/gcc/ /home/seurer/gcc/gcc-8/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mvsx -ffat-lto-objects -S -o vsx-7-be.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-8/gcc/xgcc -B/home/seurer/gcc/build/gcc-8/gcc/ /home/seurer/gcc/gcc-8/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mvsx -ffat-lto-objects -S -o vsx-7-be.s PASS: gcc.target/powerpc/vsx-7-be.c (test for excess errors) PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vpkpx 2 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vmulesb 1 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vmulosb 1 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times \\mlxvd2x\\M 36 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times lvewx 2 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times lvxl 1 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vupklsh 1 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vupkhsh 1 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times xxlnor 4 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times xxland 4 PASS: gcc.target/powerpc/vsx-7-be.c scan-assembler-times xxlxor 5 gcc.target/powerpc/vsx-7-be.c: vupkhpx found 0 times FAIL: gcc.target/powerpc/vsx-7-be.c scan-assembler-times vupkhpx 1
[Bug c++/86574] ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574 --- Comment #4 from tower120 --- Because I don't have gcc 9 locally installed. I saw that ICE on https://wandbox.org/permlink/bPT0llOGPqouv3CM Error message says to report - I'm reporting.
[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #12 from Iain Sandoe --- Created attachment 44411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44411=edit proposed update to the test case. The testcase fails (always has AFAICT) on Darwin, where __USER_LABEL_PREFIX__ is defined. The CPP manual says that __USER_LABEL_PREFIX__ expands to a single token, rather than a string.
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480
Tobias Burnus changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #11 from Tobias Burnus ---
Hmm, it seems as if now too much is rejected - unless, I misunderstand some
rules (which is also likely).
The following compiles with GCC 8 and my very old Clang 3.7.0, but it fails now
on the trunk with the patch with:
foo.cc:3:8: error: friend declaration of ‘Matrix rot90(const Matrix&, int)’
specifies default arguments and isn't the only declaration [-fpermissive]
Matrix rot90 (const Matrix& a, int k) {
^
In file included from foo.cc:1:
foo.h:5:19: note: previous declaration of ‘Matrix rot90(const Matrix&, int)’
friend Matrix rot90 (const Matrix&, int); //no default values here
^
# head foo.h foo.cc
==> foo.h <==
class Matrix;
Matrix rot90 (const Matrix& a, int k = 1);
class Matrix {
friend Matrix rot90 (const Matrix&, int); //no default values here
};
==> foo.cc <==
#include "foo.h"
Matrix rot90 (const Matrix& a, int k) {
return Matrix();
}
[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009 --- Comment #11 from avieira at gcc dot gnu.org --- Author: avieira Date: Thu Jul 19 14:03:21 2018 New Revision: 262881 URL: https://gcc.gnu.org/viewcvs?rev=262881=gcc=rev Log: [AArch64][PATCH 2/2] PR target/83009: Relax strict address checking for store pair lanes gcc/ChangeLog 2018-07-19 Andre Vieira PR target/83009 * config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand): Make address check not strict. gcc/testsuite/ChangeLog 2018-07-19 Andre Vieira PR target/83009 * gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/predicates.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 --- Comment #6 from Jakub Jelinek --- That said, if the -W* does't affect code generation goal is very important and we don't find any other way, perhaps the price to pay for that is acceptable. Even the PR86569 patch isn't without cost (in that case even the cost is we generate worse code with -O0).
[Bug c++/86588] peculiar build issue using range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86588 --- Comment #1 from Hannes Hauswedell --- Created attachment 44410 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44410=edit intermediate file build with -std=c++17 -fconcepts
[Bug c++/86588] New: peculiar build issue using range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86588
Bug ID: 86588
Summary: peculiar build issue using range-v3
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
I have attached a code sample below and will provide an intermediate file that
shows that various forms of initialisation fail to build, while equivalent (at
least some) pass [all that are commented out fail, the last two are the only
that pass].
Since range-v3 pulls in a large amount of code the intermediate files are quite
large and I have as of yet been unsuccessful in reducing this to something that
still fails, but I hope someone with more expertise can track the compiler
while it tries/fails to deduce the type.
tested versions:
g++7 (FreeBSD Ports Collection) 7.3.1 20180712
g++8 (FreeBSD Ports Collection) 8.1.1 20180713
For reference also the issue at range-v3:
https://github.com/ericniebler/range-v3/issues/860
std::string vec{"foo\nbar"};
seqan3::detail::view_take_line v1(ranges::view::all(vec));
assert("foo" == std::string(v1));
assert(ranges::BidirectionalRange());
assert(ranges::View());
// auto v2 = v1 | ranges::view::reverse;// #1
// auto v2 = ranges::reverse_view{v1};// #2
using t = ranges::reverse_view;
// auto v2 = t(v1); // #3
// auto v2 = t{v1}; // #3b
// t v2 = t(v1);// #4
// t v2 = t{v1};// #4b
// t v2 = v1; // #5
t v2(v1);// #6
t v3{v1};// #6b
assert("oof" == std::string(v2));
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 --- Comment #5 from Jakub Jelinek --- That is the costly variant, the already slow C++ FE will need to compute and instantiate a lot of things that aren't really needed.
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |9.0 Alias||add-Wvexing-parse
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 --- Comment #4 from Richard Biener --- cp_fully_fold smells like it could have side-effects as well, of course. Yeah, it calls maybe_constant_value as well ;)
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586
--- Comment #3 from Richard Biener ---
Like with
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 1335da5e9bc..aaa56697f29 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5322,7 +5322,6 @@ cp_build_binary_op (location_t location,
}
if ((short_compare || code == MIN_EXPR || code == MAX_EXPR)
- && warn_sign_compare
/* Do not warn until the template is instantiated; we cannot
bound the ranges of the arguments until that point. */
&& !processing_template_decl
@@ -5336,12 +5335,15 @@ cp_build_binary_op (location_t location,
tree oop0 = maybe_constant_value (orig_op0);
tree oop1 = maybe_constant_value (orig_op1);
- if (TREE_CODE (oop0) != INTEGER_CST)
- oop0 = cp_fully_fold (orig_op0);
- if (TREE_CODE (oop1) != INTEGER_CST)
- oop1 = cp_fully_fold (orig_op1);
- warn_for_sign_compare (location, oop0, oop1, op0, op1,
-result_type, resultcode);
+ if (warn_sign_compare)
+ {
+ if (TREE_CODE (oop0) != INTEGER_CST)
+ oop0 = cp_fully_fold (orig_op0);
+ if (TREE_CODE (oop1) != INTEGER_CST)
+ oop1 = cp_fully_fold (orig_op1);
+ warn_for_sign_compare (location, oop0, oop1, op0, op1,
+result_type, resultcode);
+ }
}
}
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 --- Comment #2 from Richard Biener --- (In reply to Jakub Jelinek from comment #1) > Yeah, I think it is a dup. There are many other cases where we call > maybe_constant_value for some warning only, and we assume it is a safe thing > to do. > Fixing that is going to be extremely hard or extremely costly I'm afraid. Well, just make sure to call maybe_constant_value unconditionally?
[Bug c++/86586] [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Yeah, I think it is a dup. There are many other cases where we call maybe_constant_value for some warning only, and we assume it is a safe thing to do. Fixing that is going to be extremely hard or extremely costly I'm afraid.
[Bug c++/86574] ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574 --- Comment #3 from Marek Polacek --- Why couldn't you? Just use -save-temps.
[Bug c++/86556] , most vexing parse, and diagnostic output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86556
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Jonathan Wakely ---
I think this can be considered a duplicate of PR 25814, because if you got a
warning for:
std::mt19937 gen(std::random_device());
Then the later errors should make more sense.
Clang's output for the same code is:
vex.cc:3:25: warning: parentheses were disambiguated as a function declaration
[-Wvexing-parse]
std::mt19937 gen(std::random_device());
^~
vex.cc:3:26: note: add a pair of parentheses to declare a variable
std::mt19937 gen(std::random_device());
^
( )
In file included from vex.cc:1:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/random:51:
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/random.tcc:3320:62:
error: member reference base type 'std::mersenne_twister_engine (std::random_device (*)())' is not a structure or union
const long double __r = static_cast(__urng.max())
~~^~~~
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/random.h:183:16:
note: in instantiation of function template specialization
'std::generate_canonical
(std::random_device (*)())>' requested here
return std::generate_canonical<_DInputType,
^
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/random.h:3562:7:
note: in instantiation of member function
'std::__detail::_Adaptor (std::random_device (*)()),
double>::operator()' requested here
if ((__aurng() - __aurng.min())
^
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/random.h:3553:22:
note: in instantiation of function template specialization
'std::bernoulli_distribution::operator() (std::random_device (*)())>' requested here
{ return this->operator()(__urng, _M_param); }
^
vex.cc:5:17: note: in instantiation of function template specialization
'std::bernoulli_distribution::operator() (std::random_device (*)())>' requested here
return d(gen);
^
1 warning and 1 error generated.
It's not really possible to improve the later errors, because the location of
the invalid code is quite far from the declaration that causes the problem. We
could add a note to any attempt to access members of a function type or
function pointer type saying that you might have been bitten by a vexing parse,
but it wouldn't always be true.
*** This bug has been marked as a duplicate of bug 25814 ***
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814 Jonathan Wakely changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #10 from Jonathan Wakely --- *** Bug 86556 has been marked as a duplicate of this bug. ***
[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #11 from Iain Sandoe --- The test case fails on m32 Darwin (since it was added, AFAICT) apparently because it's wrong code or triggers a code-gen bug that doesn't happen to cause most platform assemblers to complain. This is repeatable on x86-64-linux-gnu. The test-case is a bit inscrutable, but .. the object static a[] is used thus a[i] = something in fn6. the content is never accessed and no storage is associated with a but the stores to a are not .. so we have (for x86-64-linux-gnu) movl%edx, a(,%rax,4) and $ nm pr72802.o U a b b this assembles for linux and x86-64-darwin (with 'a' showing as an undef), but fails on m32 Darwin which believes that the object should be defined in the TU (since it's static) but then finds it to be undef. Was the intention for the test?
[Bug c++/86583] [DR 1854] exception specification of explicitly defaulted destructor does not match the calculated one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86583 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2018-07-19 Summary|exception specification of |[DR 1854] exception |explicitly defaulted|specification of explicitly |destructor does not match |defaulted destructor does |the calculated one |not match the calculated ||one Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to zhonghao from comment #0) > g++ accepts the code, but I think it shouldn't be. GCC defines the members as deleted, so you don't get an error unless you try to use them. That seems to be correct according to [dcl.fct.def.default] p2 which has a very similar example: ~S() noexcept(false) = default; // deleted: exception specification does not match I think Clang might implement the suggested direction for https://wg21.link/cwg1854 but GCC is correct according to the current standard. > In fact, g++4.9.0 rejects the code: 4.9.0 accepts it, but 4.8.x rejects it.
[Bug target/86560] FAIL: c-c++-common/asan/swapcontext-test-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86560
--- Comment #4 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Jul 19 12:00:59 2018
New Revision: 262878
URL: https://gcc.gnu.org/viewcvs?rev=262878=gcc=rev
Log:
i386: Test __has_attribute (__indirect_return__)
The new indirect_return attribute is intended to mark swapcontext in
. Test __has_attribute (__indirect_return__) so that it
can be backported to GCC 8.
PR target/86560
* gcc.target/i386/pr86560-4.c: New test.
* gcc.target/i386/pr86560-5.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr86560-4.c | 21 +
gcc/testsuite/gcc.target/i386/pr86560-5.c | 21 +
2 files changed, 42 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/i386/pr86560-4.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr86560-5.c
diff --git a/gcc/testsuite/gcc.target/i386/pr86560-4.c
b/gcc/testsuite/gcc.target/i386/pr86560-4.c
new file mode 100644
index 000..a623e3dcbeb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr86560-4.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcf-protection" } */
+/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
+
+struct ucontext;
+
+extern int (*bar) (struct ucontext *)
+#ifdef __has_attribute
+# if __has_attribute (indirect_return)
+ __attribute__((__indirect_return__))
+# endif
+#endif
+;
+
+extern int res;
+
+void
+foo (struct ucontext *oucp)
+{
+ res = bar (oucp);
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr86560-5.c
b/gcc/testsuite/gcc.target/i386/pr86560-5.c
new file mode 100644
index 000..33b0f6424c2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr86560-5.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcf-protection" } */
+/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
+
+struct ucontext;
+
+extern int (*bar) (struct ucontext *)
+#ifdef __has_attribute
+# if __has_attribute (__indirect_return__)
+ __attribute__((__indirect_return__))
+# endif
+#endif
+;
+
+extern int res;
+
+void
+foo (struct ucontext *oucp)
+{
+ res = bar (oucp);
+}
[Bug c++/86581] constexpr variable is not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86581
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-19
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced:
struct V {
union { int n; struct { int x,y; }; };
constexpr V() : x(0) {}
};
constexpr V v;
Clang says:
un.cc:4:12: error: constexpr constructor must initialize all members
constexpr V() : x(0) {}
^
un.cc:2:37: note: member not initialized by constructor
union { int n; struct { int x; int y; }; };
^
un.cc:6:13: error: no matching constructor for initialization of 'const V'
constexpr V v;
^
un.cc:1:8: note: candidate constructor (the implicit copy constructor) not
viable: requires 1 argument, but 0 were provided
struct V {
^
un.cc:1:8: note: candidate constructor (the implicit move constructor) not
viable: requires 1 argument, but 0 were provided
2 errors generated.
[Bug debug/86585] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86585
--- Comment #2 from Richard Biener ---
So the issue is that for 1.ii we do _not_ emit debug information for
namespace Inkscape {
class a;
}
but we _do_ stream its NAMESPACE_DECL which then gets tree-merged with
the NAMESPACE_DECL from 2.ii losing debug info for it.
Interestingly we prune down the debug for 1.ii to just contain a
declaration for class b. This is because we have TYPE_DECL_SUPPRESS_DEBUG
set on class b and thus run into:
static void
gen_struct_or_union_type_die (tree type, dw_die_ref context_die,
enum debug_info_usage usage)
{
...
int complete = (TYPE_SIZE (type)
&& (! TYPE_STUB_DECL (type)
|| ! TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type;
The C++ FE sets this here:
void
maybe_suppress_debug_info (tree t)
{
...
/* If the class has a vtable, write out the debug info along with
the vtable. */
else if (TYPE_CONTAINS_VPTR_P (t))
TYPE_DECL_SUPPRESS_DEBUG (TYPE_MAIN_DECL (t)) = 1;
but we do not emit the vtable of b in this case which leads to incomplete
debug info.
Note that again we may run into such a situation with combining -g and -g0
units and tree-merging to a -g0 entity will drop early debug references
from entities from -g units. So we _may_ want to do sth more clever in
case a SCC is thrown away. Currently we do
/* Drop DIE references. */
dref_queue.truncate (0);
but we could do better here, trying to merge any debug info references we
get like with (for the easy case of SCC of size one). This fixes the testcase
up to the expected link failure.
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index d1add15efeb..8db280ecefc 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1638,6 +1638,21 @@ unify_scc (struct data_in *data_in, unsigned from,
to the tree node mapping computed by compare_tree_sccs. */
if (len == 1)
{
+ /* If we got a debug reference queued, see if the prevailing
+tree has a debug reference and if not, register the one
+for the tree we are about to throw away. */
+ if (dref_queue.length () == 1)
+ {
+ dref_entry e = dref_queue.pop ();
+ gcc_assert (e.decl
+ == streamer_tree_cache_get_tree (cache, from));
+ const char *sym;
+ unsigned HOST_WIDE_INT off;
+ if (!debug_hooks->die_ref_for_decl (pscc->entries[0], ,
+ ))
+ debug_hooks->register_external_die (pscc->entries[0],
+ e.sym, e.off);
+ }
lto_maybe_register_decl (data_in, pscc->entries[0], from);
streamer_tree_cache_replace_tree (cache, pscc->entries[0], from);
}
@@ -1669,7 +1684,9 @@ unify_scc (struct data_in *data_in, unsigned from,
free_node (scc->entries[i]);
}
- /* Drop DIE references. */
+ /* Drop DIE references.
+??? Do as in the size-one SCC case which involves sorting
+the queue. */
dref_queue.truncate (0);
break;
Testing that now.
[Bug fortran/86587] New: Derived-type with attributes BIND(C) and PRIVATE raises an error but standard accepts it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86587 Bug ID: 86587 Summary: Derived-type with attributes BIND(C) and PRIVATE raises an error but standard accepts it Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valentin.clement at env dot ethz.ch Target Milestone: --- Created attachment 44409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44409=edit Code The following code is rejected by gfortran but according to the standard it should be accepted. Cray and PGI Compiler seems to accept this combination of attributes. MODULE mod1 USE ISO_C_BINDING TYPE, BIND(C), PRIVATE :: myType INTEGER(C_INT) :: i1, i2 END TYPE END MODULE mod1 If the PRIVATE is global to the module, the code is fine. MODULE mod1 USE ISO_C_BINDING PRIVATE TYPE, BIND(C) :: myType INTEGER(C_INT) :: i1, i2 END TYPE END MODULE mod1 Compilation: gfortran-8 -c file.f90 gfortran version: Using built-in specs. COLLECT_GCC=gfortran-8 COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.1.0/libexec/gcc/x86_64-apple-darwin17.5.0/8.1.0/lto-wrapper Target: x86_64-apple-darwin17.5.0 Configured with: ../configure --build=x86_64-apple-darwin17.5.0 --prefix=/usr/local/Cellar/gcc/8.1.0 --libdir=/usr/local/Cellar/gcc/8.1.0/lib/gcc/8 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC 8.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-nls Thread model: posix gcc version 8.1.0 (Homebrew GCC 8.1.0) machine: MacBook Pro (Retina, 13-inch, Early 2015), 2.9 GHz Intel Core i5, 8 GB 1867 MHz DDR3
[Bug tree-optimization/86544] Popcount detection generates different code on C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Can confirm this is fixed now. Thanks!
[Bug c++/86524] [8/9 Regression] std::less with pointer arguments not usable in static_assert in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86524
--- Comment #5 from Jakub Jelinek ---
Similarly, when changing:
- static_assert (!foo (, ));
+ constexpr bool y = foo (, );
+ static_assert (!y);
I think the problem is that finish_static_assert evaluates the condition using
fold_non_dependent_expr -> maybe_constant_value and that results in ctx->quiet
being true while evaluating the expression (it wants to diagnose non-constant
expression only later). But we have also:
/* Don't fold __builtin_constant_p within a constexpr function. */
bool bi_const_p = (DECL_FUNCTION_CODE (fun) == BUILT_IN_CONSTANT_P);
/* If we aren't requiring a constant expression, defer __builtin_constant_p
in a constexpr function until we have values for the parameters. */
if (bi_const_p
&& ctx->quiet
&& current_function_decl
&& DECL_DECLARED_CONSTEXPR_P (current_function_decl))
{
*non_constant_p = true;
return t;
}
which means if ctx->quiet is true, we don't try at all to evaluate the builtin.
That is reasonable while parsing the constexpr functions of cp_folding it, but
we don't have a way right now to differentiate between that and the
finish_static_assert which is try as hard as possible to evaluate it to a
constant, just don't complain if that fails. So, do we need another constexpr
context flag for this, or should we e.g. try to fold the __builtin_constant_p
in any case and only set *non_constant_p if it evaluates to false, or something
similar?
[Bug c++/86586] New: [6/7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586
Bug ID: 86586
Summary: [6/7/8/9 Regression] -Wsign-compare affects code
generation
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Blocks: 86518
Target Milestone: ---
void f ()
{
__builtin_cpu_supports ("avx2") && __builtin_cpu_supports ("ssse3");
}
ICEs with 'g++ -std=c++98 -fcompare-debug=-Wsign-compare'. This is minimized
from mv1.C in the testsuite.
I know it's inconvenient that this test depends on an x86-specific builtin, but
unfortunately I don't see other tests failing (apart from cp/mangle.c
miscomparing on bootstrap with/without the warning).
This may be similar to PR 86567: there's a use of maybe_constant_value guarded
by warn_sign_compare.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
[Bug 86518] Strengthen bootstrap comparison by not enabling warnings at stage3
[Bug c++/58194] [DR 1344] default argument for constructor outside of class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58194 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2013-08-19 00:00:00 |2018-7-19 --- Comment #4 from Jonathan Wakely --- Ill-formed by [dcl.fct.default] p5 https://wg21.link/cwg1344 (which is a DR so applies to C++03 and C++11 too).
[Bug c++/86255] addition of default argument on redeclaration makes this constructor a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86255 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Version|unknown |9.0 Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- (In reply to zhonghao from comment #0) > So, is this a > recurring bug in g++? No, it's not recurring. GCC simply doesn't implement https://wg21.link/cwg1344 yet (which was only resolved in 2014 so is nothing to do with PR 2189 from 2002). We already have a bug report for DR 1344. *** This bug has been marked as a duplicate of bug 58194 ***
[Bug c++/58194] [DR 1344] default argument for constructor outside of class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58194 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #3 from Jonathan Wakely --- *** Bug 86255 has been marked as a duplicate of this bug. ***
[Bug target/86560] FAIL: c-c++-common/asan/swapcontext-test-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86560
--- Comment #3 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Jul 19 10:47:23 2018
New Revision: 262877
URL: https://gcc.gnu.org/viewcvs?rev=262877=gcc=rev
Log:
i386: Change indirect_return to function type attribute
In
struct ucontext;
typedef struct ucontext ucontext_t;
extern int (*bar) (ucontext_t *__restrict __oucp,
const ucontext_t *__restrict __ucp)
__attribute__((__indirect_return__));
extern int res;
void
foo (ucontext_t *oucp, ucontext_t *ucp)
{
res = bar (oucp, ucp);
}
bar() may return via indirect branch. This patch changes indirect_return
to type attribute to allow indirect_return attribute on variable or type
of function pointer so that ENDBR can be inserted after call to bar().
gcc/
PR target/86560
* config/i386/i386.c (rest_of_insert_endbranch): Lookup
indirect_return as function type attribute.
(ix86_attribute_table): Change indirect_return to function
type attribute.
* doc/extend.texi: Update indirect_return attribute.
gcc/testsuite/
PR target/86560
* gcc.target/i386/pr86560-1.c: New test.
* gcc.target/i386/pr86560-2.c: Likewise.
* gcc.target/i386/pr86560-3.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr86560-1.c
trunk/gcc/testsuite/gcc.target/i386/pr86560-2.c
trunk/gcc/testsuite/gcc.target/i386/pr86560-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
[Bug debug/86585] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86585 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug debug/86585] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86585 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-7-19 Known to work||8.1.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug debug/86585] New: [9 Regression] ICE in gen_member_die, at dwarf2out.c:24935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86585
Bug ID: 86585
Summary: [9 Regression] ICE in gen_member_die, at
dwarf2out.c:24935
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
This is a follow-up from PR86523:
$ cat 1.ii
namespace Inkscape {
class a;
}
class b {
Inkscape::a *c;
virtual void d();
};
class e {
b f;
};
class g : e {
void h();
};
void g::h() {}
$ cat 2.ii
struct a {
struct b {
b();
} c;
};
class d {
a e;
};
namespace aa {
class h {};
} // namespace aa
class k {
typedef aa::h f;
f g;
};
namespace Inkscape {
class l {
k i;
class : d {
} j;
l();
};
l::l() {}
} // namespace Inkscape
$ g++ 1.ii 2.ii -flto -g
lto1: internal compiler error: in gen_member_die, at dwarf2out.c:24935
0x5c6027 gen_member_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:24935
0x5c6027 gen_struct_or_union_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25130
0x85c38f gen_tagged_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25331
0x87610f gen_typedef_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25245
0x85a0da gen_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26231
0x85cc8c gen_type_die_with_usage
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25396
0x85d8e6 gen_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25580
0x85a3c2 gen_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26299
0x85beb2 gen_member_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25034
0x85beb2 gen_struct_or_union_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25130
0x85c38f gen_tagged_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25331
0x85d207 gen_type_die_with_usage
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25526
0x85d8e6 gen_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25580
0x85a3c2 gen_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26299
0x85beb2 gen_member_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25034
0x85beb2 gen_struct_or_union_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25130
0x85c38f gen_tagged_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25331
0x85d207 gen_type_die_with_usage
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25526
0x85c419 gen_tagged_type_die
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25300
0x85d207 gen_type_die_with_usage
/home/marxin/Programming/gcc/gcc/dwarf2out.c:25526
[Bug c++/86524] [8/9 Regression] std::less with pointer arguments not usable in static_assert in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86524 --- Comment #4 from Jakub Jelinek --- It works with if constexpr (__builtin_constant_p (x < y)) return x < y;
[Bug c++/86524] [8/9 Regression] std::less with pointer arguments not usable in static_assert in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86524
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org,
||nathan at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
constexpr bool
foo (const int *x, const int *y)
{
if (__builtin_constant_p (x < y))
return x < y;
return (__UINTPTR_TYPE__) x < (__UINTPTR_TYPE__) y;
}
void
bar ()
{
constexpr int x = 0;
static_assert (!( < ));
static_assert (!foo (, ));
}
constexpr void
baz ()
{
constexpr int x = 0;
static_assert (!( < ));
static_assert (!foo (, ));
}
[Bug tree-optimization/86526] [9 Regression] ICE in builtin_memcpy_read_str, at builtins.c:3017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86526 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c++/86569] [6/7/8/9 Regression] -Wnonnull-compare affects code generation since r233684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569 --- Comment #4 from Jakub Jelinek --- Created attachment 44408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44408=edit gcc9-pr86569.patch Untested fix.
[Bug c++/86574] ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574 --- Comment #2 from tower120 --- I can't provide a preprocessed source file, but "range/v3/view/transform.hpp" source is here: https://github.com/ericniebler/range-v3
[Bug c++/86569] [6/7/8/9 Regression] -Wnonnull-compare affects code generation since r233684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |6.5 Summary|-Wnonnull-compare affects |[6/7/8/9 Regression] |code generation |-Wnonnull-compare affects ||code generation since ||r233684
[Bug tree-optimization/80155] [7/8/9 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #38 from prathamesh3492 at gcc dot gnu.org --- Hi, The issue can be reproduced exactly, with pr77445-2.c. I am testing with making is_digit() noinline. * Reordering SINK before PRE SPEC2006 data for building SPEC2006 with sink before pre: Number of statements sunk: +2677 (~ +14%) Number of total PRE insertions: -3971 (~ -1%) On the private embedded benchmark suite, there's overall no significant difference. Not sure if this is much helpful. Is there a way to get info about number of registers spilled from lra dump or assembly ? I would like to see the effect on spills by reordering passes. Reordering sink before pre seems to regress no-scevccp-outer-22.c and ssa-dom-thread-7.c, and several SVE tests on aarch64: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/262002-sink-pre/aarch64-none-linux-gnu/diff-gcc-rh60-aarch64-none-linux-gnu-default-default-default.txt Also there seems to be some interplay with hoisting and forwprop. Disabling forwprop3 and forwprop4 seems to eliminate the spill too. However as Bin pointed out on the list, forwprop is also helping to reduce register pressure for this case by mem_ref folding (forward_propagate_addr_expr). * Jump threading cost models It seems jump-threading pass increases the size for this case from 38 to 79 blocks. Wondering if that adds up to "resource hog", eventually leading to extra spill ? Disabling jump threading pass eliminates the spill. I looked a bit into fine tuning jump threading cost models for cortex-m7. Strangely, setting max-jump-thread-duplication-stmts to 20 and fsm-scale-path-stmts to 3 not only removes the spill but also results in 9 more hoistings! I am investigating why this resulted in improved performance. However it regresses ssa-dom-thread-7.c: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/262539-jump-thread-cost-models/aarch64-none-elf/diff-gcc-rh60-aarch64-none-elf-default-default-default.txt * Stop-gap measure for hoisting ? As a stop-gap measure, would it make sense to "localize" hoisting within "large" loop (based on loop->num_nodes?) by refusing to hoist expressions computed outside loop ? My assumption is that hoisting will increase live range of expression which was previously computed in a block outside loop but is brought inside the loop due to hoisting since we'd now need to consider path along the loop as well for estimating it's live-range ? I suppose a cheap way to test that would be to check if block's post-dominator also lies within the same loop since it would ensure all paths from block to EXIT would lie inside the loop ? I created a patch for this (http://people.linaro.org/~prathamesh.kulkarni/pdom.diff), which works to remove the spill but regressed pr77445-2.c (which is how I stumbled on that test). Although the underlying issue doesn't seem particularly relevant to hoisting, so not sure if this "heuristic" makes much sense. * Live range shrinking pass There was some discussion about an inter-block live-range shrinking GIMPLE pass on the list (https://gcc.gnu.org/ml/gcc/2018-05/msg00260.html), which will run just before expand. I would be grateful for suggestions on how to get started with it. I realize this'd be pretty hard, but would like to give a try. Thanks, Prathamesh
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
--- Comment #3 from Georg-Johann Lay ---
...and here is code that triggers the wrong path of the 2-byte case:
typedef struct S
{
const __flash2 struct S *p;
struct S *q;
} S;
const __flash2 S* func2 (const S *s)
{
return s->p->q->p;
}
$ avr-gcc -std=gnu99 -mmcu=atxmega128a1 -S foo.c -Os -dp
func2:
movw r26,r24 ; 20 [c=4 l=1] *movhi/0
ld r30,X+; 6 [c=8 l=2] *movhi/2
ld r31,X
adiw r30,2 ; 8 [c=4 l=1] addhi3_clobber/0
ldi r18,2; 9 [c=8 l=5] *movhi/2
out __RAMPZ__,r18
elpm r0,Z+
elpm r31,Z
mov r30,r0
ld r24,Z ; 15 [c=8 l=2] *movhi/2
ldd r25,Z+1
/* epilogue start */
ret ; 23 [c=0 l=1] return
Insn 9 is missing the reset of RAMPZ so that insn 15 loads with a high-byte of
2.
[Bug c++/86569] -Wnonnull-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Bet this is:
if (TREE_NO_WARNING (org_x)
&& warn_nonnull_compare
&& COMPARISON_CLASS_P (org_x))
{
if (x == error_mark_node || TREE_CODE (x) == INTEGER_CST)
;
else if (COMPARISON_CLASS_P (x))
TREE_NO_WARNING (x) = 1;
/* Otherwise give up on optimizing these, let GIMPLE folders
optimize those later on. */
else if (op0 != TREE_OPERAND (org_x, 0)
|| op1 != TREE_OPERAND (org_x, 1))
{
x = build2_loc (loc, code, TREE_TYPE (org_x), op0, op1);
TREE_NO_WARNING (x) = 1;
}
else
x = org_x;
}
in cp-gimplify.c. Just removing the && warn_nonnull_compare line is likely not
sufficient, as TREE_NO_WARNING is set in many places guarded with
warn_something.
So we'd need to go for:
if (COMPARISON_CLASS_P (org_x))
{
if (x == error_mark_node || TREE_CODE (x) == INTEGER_CST)
;
else if (COMPARISON_CLASS_P (x))
{
if (TREE_NO_WARNING (org_x) && warn_nonnull_compare)
TREE_NO_WARNING (x) = 1;
}
/* Otherwise give up on optimizing these, let GIMPLE folders
optimize those later on. */
else if (op0 != TREE_OPERAND (org_x, 0)
|| op1 != TREE_OPERAND (org_x, 1))
{
x = build2_loc (loc, code, TREE_TYPE (org_x), op0, op1);
if (TREE_NO_WARNING (org_x) && warn_nonnull_compare)
TREE_NO_WARNING (x) = 1;
}
else
x = org_x;
}
or so.
[Bug c++/86580] No warning for default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86580 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- You've reported this three times now. *** This bug has been marked as a duplicate of bug 86255 ***
[Bug c++/86255] addition of default argument on redeclaration makes this constructor a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86255 --- Comment #2 from Jonathan Wakely --- *** Bug 86580 has been marked as a duplicate of this bug. ***
[Bug c++/86250] addition of default argument on redeclaration makes this constructor a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86250 --- Comment #2 from Jonathan Wakely --- Actually three times, PR 86580 too.
[Bug c++/86250] addition of default argument on redeclaration makes this constructor a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86250 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- You've reported this twice. *** This bug has been marked as a duplicate of bug 86255 ***
[Bug middle-end/86575] [7/8/9 Regression] -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |7.4 Summary|-Wimplicit-fallthrough |[7/8/9 Regression] |affects code generation |-Wimplicit-fallthrough ||affects code generation --- Comment #3 from Jakub Jelinek --- As -Wimplicit-fallthrough is included in -Wextra, this is a regression, -Wextra affects code generation.
[Bug c++/86255] addition of default argument on redeclaration makes this constructor a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86255 --- Comment #1 from Jonathan Wakely --- *** Bug 86250 has been marked as a duplicate of this bug. ***
[Bug middle-end/86575] -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The bug is in:
/* Nested scope. Only look at the last statement of
the innermost scope. */
location_t bind_loc = gimple_location (gsi_stmt (*gsi_p));
gimple *last = last_stmt_in_scope (gsi_stmt (*gsi_p));
if (last)
{
prev = last;
/* It might be a label without a location. Use the
location of the scope then. */
if (!gimple_has_location (prev))
gimple_set_location (prev, bind_loc);
}
gsi_next (gsi_p);
The gimple_set_location in there may affect code generation, on this testcase
the difference is unimportant:
@@ -25,10 +25,10 @@ f2:
movl-4(%rbp), %eax
cmpl-28(%rbp), %eax
jl .L5
- jmp .L7
+ jmp .L4
.L6:
nop
-.L7:
+.L4:
nop
popq%rbp
.cfi_def_cfa 7, 8
but on others it could matter.
I see roughly two possibilities to solve this, one is never set a location in
the warning code and use some on-the-side hash map for the warning and use some
helper that will use gimple_location and otherwise fall back to looking up the
hash map.
Or, do the gimple_set_location above, but also push into some vector the gimple
* prev we've modified and traverse that vector at the end of
maybe_warn_implicit_fallthrough ? and set gimple location back to
UNKNOWN_LOCATION and finally release the vector.
What I do not know is if this location is needed also in case of nested
switches etc., or if reseting the location back at the end of
maybe_warn_implicit_fallthrough is fine. Plus, whether !gimple_has_location at
this point always implies gimple_location (prev) == UNKNOWN_LOCATION, or if it
could be already something with on-the-side data (then we'd need to save in the
vector(s) not just gimple *, but also the location_t we should restore to).
[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #7 from Marc Glisse --- The real difference in -std=c++17 is _GLIBCXX_EXTERN_TEMPLATE. With -std=c++14, we have many extern templates which the compiler almost never inlines. This leaves existing inline functions small enough to be inlined in main (once it is renamed). With -std=c++17, extern templates are gone, everything is inlined, and the function that used to be small enough to be inlined is now too big (several smaller functions have been inlined into it first). Without inlining, the compiler cannot notice all the simplifications. (this is in large part guesswork, feel free to verify) If someone wants to improve it, I would look into the inliner heuristics, but that's probably going to be hard.
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Earnshaw --- GCC just implements the ACLE specification in this regard. That doesn't define anything for the LSE extensions. I understand that is deliberate. 1) The recommendation is to use the standard __sync and atomic primitives already defined by the compiler. 2) Hand-coding equivalents in assembly can often lead to architecturally incorrect programs that just appear to work, but might fail if run on other systems. So I think this is a wontfix.
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 Richard Earnshaw changed: What|Removed |Added Resolution|FIXED |WONTFIX
[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #6 from Richard Biener --- (In reply to Niall Douglas from comment #5) > Thanks for the rapid feedback. Very very interesting that -std=c++17 causes > spew for the copy case https://godbolt.org/g/Xnrgg2, yet -std=c++14 or > -std=c++11 does not. > > Is the -std=c++17 case worth opening a new bug report for? I guess so (same for -std=c++2a btw)
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #14 from Tom de Vries --- *** Bug 86582 has been marked as a duplicate of this bug. ***
[Bug debug/86582] [debug] vla size reported as 0 at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Tom de Vries --- If we change the f1 argument to 5, or we comment out the volatile asm in main, the problem is fixed, but for the test-case as is, we can't do anything more. At Os or O1, the problem doesn't occur, because a is optimized away after tree-dse eliminates the dead store (tree-dse also runs at Og, but doesn't manage to get rid of the dead store because ealias is not run for Og), and the body of the function f1 is very simple and doesn't overwrite the value of the argument i, so there's no need to reference back to the initial value of argument i in main. Contrary to what I thought initially, there's nothing vla specific here, this is a plain duplicate of PR78685. *** This bug has been marked as a duplicate of bug 78685 ***
[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #5 from Niall Douglas --- Thanks for the rapid feedback. Very very interesting that -std=c++17 causes spew for the copy case https://godbolt.org/g/Xnrgg2, yet -std=c++14 or -std=c++11 does not. Is the -std=c++17 case worth opening a new bug report for?
[Bug middle-end/86575] -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-19 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- -fdump-tree-gimple-lineno already shows a difference: @@ -15,7 +15,7 @@ f2 (int a, int b, int c, int d) [pr86575.c:7:30] e = e + 1; : [pr86575.c:7:7] if (e < c) goto ; else goto ; -[pr86575.c:7:7] : +: } }
[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #4 from Richard Biener --- Note we only manage to optimize it with the C++11 std::string.
[Bug tree-optimization/86572] unsafe strlen folding of const arguments with non-const offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86572 --- Comment #2 from Richard Biener --- When we can detect undefined behavior we should try to behave as the user intended. For example for MEM[p_1 + 4, int] = 0; MEM[p_1, double *] = 1.; x_2 = MEM[p_1 + 4, int]; we see a must-alias and ignore that TBAA allows us to simplify x_2 to 0. In this particular case folding happens with non-constant offset but the outcome for large i could be considered a bigger security issue than not folding (which likely would have crashed or resulted in a smaller result). MAX(0, 3 - (ssizetype)i) might be indeed a way to limit the possible fallout. Or even len = 3 -(ssizetype)i; len < 0 ? __builtin_trap () : len;
