[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 --- Comment #4 from Alexander von Gluck --- oh.. also some context I missed. Our libraries aren't at /lib,/usr/lib,etc. (which is also reflected in our os config headers) Am I wrong to think making that assumption in the architecture level seems misplaced. (if there was a higher level linux.h... 64-bit? /lib64, etc, that seems like a "more better" way of doing it (and how 'the rest of the architectures' seem to do it) The fundamental question here is, "should architecture headers override the location of os library prefix paths in a non-generic way". It's an edge case for sure (there aren't too many unicorn posix operating systems that put their library paths at somewhere not /lib* (we're /boot/system/lib))
[Bug go/90635] New: typo in libgo/configure.ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635 Bug ID: 90635 Summary: typo in libgo/configure.ac Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: jason.duerstock at gmail dot com CC: cmang at google dot com Target Milestone: --- In libgo/configure.ac: AM_CONDITIONAL(USE_LIBFFI, test "$with_liffi" != "no") Surely this should be "$with_libffi"? https://gcc.gnu.org/viewcvs/gcc/trunk/libgo/configure.ac?view=markup#l131
[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 --- Comment #3 from Alexander von Gluck --- The issue here is RISC-V is the only one that does this. We do override the STARTFILE_PREFIX_SPEC for our OS, however the architecture headers come later and undo our undef. root@b36eea373140:/work/src/buildtools/gcc/gcc# grep -R STARTFILE_PREFIX_SPEC config/haiku.h:#undef STARTFILE_PREFIX_SPEC config/mips/mti-linux.h:#undef STARTFILE_PREFIX_SPEC config/mips/mti-linux.h:#define STARTFILE_PREFIX_SPEC \ config/mips/st.h:#undef STARTFILE_PREFIX_SPEC config/mips/st.h:#define STARTFILE_PREFIX_SPEC \ config/riscv/haiku.h:#undef STARTFILE_PREFIX_SPEC config/riscv/riscv.h:#define STARTFILE_PREFIX_SPEC \ I mean... shouldn't the STARTFILE_PREFIX be up to the OS and not the architecture? (any lib32 vs lib64 or whatever would be done by generics, not architecture specific code)
[Bug tree-optimization/45791] Missed devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791 --- Comment #17 from Eric Gallager --- This is the last bug still open blocking bug 45375
[Bug fortran/79861] i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79861 Eric Gallager changed: What|Removed |Added Keywords||documentation, easyhack, ||openmp CC||egallager at gcc dot gnu.org Severity|minor |trivial
[Bug target/85665] Multiple typos in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665 Eric Gallager changed: What|Removed |Added Keywords||easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack, FIXME CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug target/79871] i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79871 Eric Gallager changed: What|Removed |Added Keywords||documentation, easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug target/84911] typo: error ("invalid name (\"%s\")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84911 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug objc/80192] arguments to check_protocols should be marked as translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80192 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug target/80022] arc: diagnostic ending in two periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80022 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug target/79870] i18n: combine structurally identical diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79870 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug rtl-optimization/79858] Explain to translators what %smode means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79858 Eric Gallager changed: What|Removed |Added Keywords||documentation, easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug target/79646] Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 Eric Gallager changed: What|Removed |Added Keywords||easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug target/47099] i686-pc-msdosdjgpp fails to build i386.o: ASM_DECLARE_FUNCTION_NAME undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47099 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- This is one of the last bugs keeping bug 47093 open
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=47093, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44756 --- Comment #9 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #8) > Given how often such issues are in target-specific code, for targets that > only get built as cross compilers, in practice we'll need someone building > for all architectures *using a native compiler from the same trunk > version, and configuring with --enable-werror-always* (whether with > config-list.mk or otherwise) to detect such problems. That is, that will > need doing both as a one-off to find problems now present that > -Wformat-diag can detect, and subsequently at least every release cycle > (preferably as a bot whose results are routinely monitored to detect > problems soon after they are introduced). > > I know there are bots building GCC for lots of targets, but I don't know > if any of the current bots build using current trunk GCC and using > --enable-werror-always to detect such issues that otherwise only show up > in a native bootstrap. Ah, so that's bug 47093 and bug 44756 then
[Bug sanitizer/68338] tsan report error about c++11 static local initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338 Evgeniy Dushistov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Evgeniy Dushistov --- No issues with gcc 8.3.0
[Bug libstdc++/90634] New: filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634
Bug ID: 90634
Summary: filesystem::path insane memory allocations
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: 1000hz.radiowave at gmail dot com
Target Milestone: ---
std::filesystem::path allocates insane amounts of memory, even for short paths.
for example, for a 20 bytes path it allocates 813 bytes. which makes it
practically unusable to store a lot of paths, while crawling through a
filesystem for example.
see the small test program:
#include
#include
#include
#include
using namespace std;
using namespace std::filesystem;
size_t total = 0;
// replace operator new and delete to log allocations
void* operator new(size_t n) {
cout << "allocating " << n << " bytes" << endl;
size_t *p = (size_t*) malloc(n + sizeof(size_t));
*p++ = n;
total += n;
return p;
}
void operator delete(void* p) throw() {
size_t *sp = (size_t *) p;
cout << "freed " << *--sp << " bytes" << endl;
total -= *sp;
free(sp);
}
int main() {
path p("/test/test/test/test");
cout << "about to quit. total allocated " << total << " bytes" << endl;
return 0;
}
the output is:
allocating 21 bytes
allocating 72 bytes
allocating 144 bytes
freed 72 bytes
allocating 288 bytes
allocating 72 bytes
freed 144 bytes
allocating 576 bytes
allocating 72 bytes
allocating 72 bytes
allocating 72 bytes
freed 72 bytes
freed 288 bytes
about to quit. total allocated 813 bytes
[Bug c++/90633] inaccurate line number control reaches end of non-void function [-Wreturn-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90633 --- Comment #1 from Andrew Pinski --- RElated to 33752
[Bug c++/90633] New: inaccurate line number control reaches end of non-void function [-Wreturn-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90633
Bug ID: 90633
Summary: inaccurate line number control reaches end of non-void
function [-Wreturn-type]
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
inaccurate line number control reaches end of non-void function [-Wreturn-type]
if -O2 is used. Not sure why, but it should be line 15 always I thought.
#1 with x86-64 gcc (trunk)
: In function 'int f()':
:7:15: warning: control reaches end of non-void function
[-Wreturn-type]
7 | strvecs_t h;
| ^
Compiler returned: 0
#include
#include
typedef std::vector strvecs_t;
int f()
{
strvecs_t h;
h.push_back("f");
if(!h.empty())
{
return -1;
}
}
[Bug c/90632] New: Incorrect error diagnosis of variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90632
Bug ID: 90632
Summary: Incorrect error diagnosis of variable declaration
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
GCC reports incorrect error diagnosis for error recovery.
For the following example, GCC should not report the undeclared variable after
error recovery when inserting the expected ';' in the first line.
$ cat s.c
static int c
static int a = 0;
static int func_1(int b);
static int func_1(int b)
{
return b;
}
int main (int argc, char* argv[])
{
c = func_1(a);
return 0;
}
$ gcc s.c
$ gcc --version
gcc (Ubuntu 4.8.5-4ubuntu8~14.04.2) 7.1.0
s.c:2:1: error：expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘static’
static int a = 0;
^~
s.c:10:5: error: ‘c’ undeclared (first use in this function)
c = func_1(a);
^
s.c:10:16: error: ‘a’ undeclared (first use in this function)
c = func_1(a);
^
$ clang-8.0 s.c
s.c:1:13: error: expected ';' after top level declarator
static int c
^
;
1 error generated.
[Bug c++/90623] compilation error with fold expression and parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90623
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-25
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Ouch, it actually ICEs:
$ xg++ -c 90623.C -std=c++17
90623.C: In instantiation of ‘main():: [with auto:4 = {int,
int, int}]’:
90623.C:15:46: required from here
90623.C:9:21: error: redeclaration of ‘const int xs#1’
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: note: ‘const int xs#1’ previously declared here
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: error: redeclaration of ‘const int xs#0’
90623.C:9:21: note: ‘const int xs#0’ previously declared here
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: error: redeclaration of ‘const int xs#2’
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: note: ‘const int xs#2’ previously declared here
90623.C:9:21: error: redeclaration of ‘const int xs#2’
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: note: ‘const int xs#2’ previously declared here
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: error: redeclaration of ‘const int xs#0’
90623.C:9:21: note: ‘const int xs#0’ previously declared here
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: error: redeclaration of ‘const int xs#1’
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
90623.C:9:25: note: ‘const int xs#1’ previously declared here
90623.C:8:12: error: designator order for field ‘main()::
[with auto:4 = {int, int, int}]’ does not
match declaration order in ‘main():: [with auto:4 = {int,
int, int}]::’
8 | return [=](auto f) {
|^
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
|
~~~
10 | // other version without fold expression // same problem
| ~
11 | //
(void)std::initializer_list{((void)call_cart(f,xs,xs...),0)...};
|
12 | };
| ~
90623.C: In instantiation of ‘main():: [with auto:4 = {int,
int, int}]:: [with auto:5 = main()::]’:
90623.C:17:56: required from here
90623.C:9:21: internal compiler error: in insert_capture_proxy, at
cp/lambda.c:311
9 | (call_cart(f, xs, xs... ), ...); // ok with gcc8 // error with
gcc9
| ^~
0x99e0a1 insert_capture_proxy(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/lambda.c:311
0xab3331 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17137
0xab271c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17036
0xab4d00 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17330
0xad7289 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:24760
0x95f8d2 maybe_instantiate_decl
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5303
0x9605b6 mark_used(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5459
0x86267d build_over_call
/home/mpolacek/src/gcc/gcc/cp/call.c:8646
0x852ef0 build_op_call_1
/home/mpolacek/src/gcc/gcc/cp/call.c:4768
0x8530b2 build_op_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:4797
0xb0f66a finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:2601
0xa0cde9 cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7375
0xa0f681 cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:8461
0xa10adb cp_parser_cast_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9346
0xa10bc8 cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9449
0xa11986 cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9747
0xa11d11 cp_parser_expression
/home/mp
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- The warning is in place and triggers with -Wextra: warning (OPT_Wextra, "ordered comparison of pointer with integer zero"); I guess we should make it a permerror.
[Bug c++/90572] [9/10 Regression] Wrong disambiguation in friend declaration as implicit typename context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Should be fixed.
[Bug c++/90572] [9/10 Regression] Wrong disambiguation in friend declaration as implicit typename context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Sat May 25 14:46:15 2019 New Revision: 271620 URL: https://gcc.gnu.org/viewcvs?rev=271620&root=gcc&view=rev Log: PR c++/90572 - wrong disambiguation in friend declaration. * parser.c (cp_parser_constructor_declarator_p): Don't allow missing typename for friend declarations. * g++.dg/cpp2a/typename16.C: New test. * g++.dg/parse/friend13.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/typename16.C branches/gcc-9-branch/gcc/testsuite/g++.dg/parse/friend13.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/parser.c
[Bug c++/90572] [9/10 Regression] Wrong disambiguation in friend declaration as implicit typename context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Sat May 25 14:39:12 2019 New Revision: 271619 URL: https://gcc.gnu.org/viewcvs?rev=271619&root=gcc&view=rev Log: PR c++/90572 - wrong disambiguation in friend declaration. * parser.c (cp_parser_constructor_declarator_p): Don't allow missing typename for friend declarations. * g++.dg/cpp2a/typename16.C: New test. * g++.dg/parse/friend13.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/typename16.C trunk/gcc/testsuite/g++.dg/parse/friend13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/90631] New: this statement may fall through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90631
Bug ID: 90631
Summary: this statement may fall through
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
I appreciate the option -Wimplicit-fallthrough gives a clue. I think it could
be clearer.
Currently g++ says "this statement may fall through"
Actually it definitely does fall through in this simple example below. So
perhaps the message could be "this statement falls through" if that can be
determined? All statements without a return, break, continue perhaps?
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:8:15: error: this statement may fall through
[-Werror=implicit-fallthrough=]
8 | a = 2;
| ~~^~~
:10:9: note: here
10 | default:
| ^~~
cc1plus: all warnings being treated as errors
Compiler returned: 1
int main()
{
int a = 1;
switch(a)
{
case 1:
{
a = 2;
}
default:
{
a = 3;
}
}
return a;
}
[Bug c/90630] New: missing error diagnosis of redundant parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90630
Bug ID: 90630
Summary: missing error diagnosis of redundant parenthesis
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
GCC 4.3.0, 4.4.3, 6.1.0, and 7.1.0 do not report the error diagnosis when there
is a redundant parenthesis token in the following scenario, as well as several
other redundant tokens, such as ";",")","[", and etc..
For the following example, GCC 4.3.0, 4,4,3, 6.1.0, and 7.1.0 should report the
error diagnosis for line 2, such as "expected declaration specifiers or ‘...’
before ‘(’ token", to tell the token should be noticed, and help fix the error
in the code early.
$: cat s.c
static long a
static const int func_1((void);
static const int func_1(void)
{
return 0;
}
int main (int argc, char* argv[])
{
int a = func_1();
return 0;
}
$: gcc s.c
s.c:2:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘static’
static const int func_1((void);
^
version of GCC:
gcc (Ubuntu 4.8.5-4ubuntu8~14.04.2) 4.3.0 or
gcc (Ubuntu 4.8.5-4ubuntu8~14.04.2) 4.4.3 or
gcc (Ubuntu 4.8.5-4ubuntu8~14.04.2) 6.1.0 or
gcc (Ubuntu 4.8.5-4ubuntu8~14.04.2) 7.1.0
Fortunately, when compiled with GCC 4.8.5, 8.1.0, and 8.2.0 under the same
workstation and the same command, there are error diagnoses of the redundant
token "(":
s.c:1:14: error：expected ‘;’ before ‘static’
static long a
^
;
static const int func_1((void);
~~
s.c:2:25: error：expected declaration specifiers or ‘...’ before ‘(’ token
static const int func_1((void);
^
In the same way, when compiled with Clang 6.0, 7.0, and 8.0, there are also
similar error diagnoses:
$clang s.c
s.c:1:14: error: expected ';' after top level declarator
static long a
^
;
s.c:2:31: error: expected ')'
static const int func_1((void);
^
[Bug c++/90629] New: Support for -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629
Bug ID: 90629
Summary: Support for -Wmismatched-new-delete
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void alloc() {
int *arr = new int [10];
delete arr;
}
GCC with -Wall -Wextra - No warnings.
Clang with -Wall -Wextra:
:5:5: warning: 'delete' applied to a pointer that was allocated with
'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete]
delete arr;
^
[]
:4:16: note: allocated with 'new[]' here
int *arr = new int [10];
[Bug target/88656] [7/8/9/10 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
gerd at egidy dot de changed:
What|Removed |Added
CC||gerd at egidy dot de
--- Comment #2 from gerd at egidy dot de ---
Could it be that this is a duplicate of bug 88167?
I compiled a gcc 7.4.0 patched with the fix for 88167 and now get this result:
push{r4, lr}
mov r3, r8
mov r4, r9
push{r3, r4}
mov r0, lr
The patch for bug 88167 seems to be just in trunk for now. As the problem is a
regression in all releases till gcc 7 I'd prefer if it could be backported into
the corresponding branches.
[Bug c++/58798] class with a class reference member generates unjustified warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58798 --- Comment #8 from Jonathan Wakely --- (In reply to Szikra from comment #3) > I have found a suggestion to hide warning about ignored attributes: > #pragma clang diagnostic ignored "-Wignored-attributes" > which doesn't seem to have a GCC equivalent. :( I'm pretty sure Clang copied that feature from GCC: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas
[Bug d/90601] ICE: gimplification failed (gimplify.c at 13436)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90601
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> Well, fix_trunc_expr isn't an lvalue you can pre-increment ... if D means
> to pre-increment a temporary (and not a) then it has to say so explicitely.
> Note GENERIC doesn't allow floating types on {PRE,POST}{DE,IN}CREMENT_EXPR
> just in case D does.
>
> A C compiler says the code is invalid C:
>
> t.c: In function ‘f’:
> t.c:3:12: error: lvalue required as increment operand
> return ++(a += 1.0);
> ^
This should be equivalent to '++(a += 1.0, a)'. So just missing the getting
the lvalue out of 'a += 1.0' here, the post de/increment handler doesn't do
this unlike the binary assignment handler in the GENERIC builder visitor.
[Bug c/90628] __builtin_mul_overflow writes to const qualified integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628 Marc Glisse changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-25 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Thanks for the report. (next time, please include a complete, compilable example, with the #includes, int main, etc)
