https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #2 from Andrew Pinski ---
For GCC 13+, you can use -funreachable-traps which is enabled at -Og at least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100289
--- Comment #20 from Jan-Benedict Glaw ---
I see this as well for my CI builds using a (slightly hacked to use local
copies of the GIT trees) build-many-glibcs.py (from glibc.)
If you call call:
/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100289
--- Comment #21 from Jan-Benedict Glaw ---
But the basic question is: Should a first build pass --disable-gcov (glibc's
failure to provide this) or should GCC detect that there's (not yet) no
sys/mman.h (GCC problem)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
--- Comment #2 from Jonny Grant ---
(In reply to Xi Ruoyao from comment #1)
> I believe attempting to doing so would result exponential time complexity.
Ah ok, I didn't realise it would be complex.
I don't know enough about the internals, I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Created attachment 52138 [details]
> Somewhat reduced reproducer
>
> The issue can be reproduced with a few less modules
The reduced testcase compiles for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96084
--- Comment #1 from anlauf at gcc dot gnu.org ---
It appears that after the fix for pr106856 (CLASS attributes) we get the
right error messages now, and also valgrind suggests there is nothing left.
I tend to mark this PR as a duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365
Bug ID: 109365
Summary: Double delete yields -Wanalyzer-use-after-free instead
of -Wanalyzer-double-free
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #17 from Andrew Pinski ---
(In reply to David Crocker from comment #16)
> This issue is not specific to AVR target. I get the same spurious warning
> from gcc 12.2 arm-none-eabi when I compile the following code for ARM Cortex
> M0+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365
--- Comment #1 from David Malcolm ---
(In reply to Benjamin Priour from comment #0)
[...]
> (Note: sorry David, I've binged through bugzilla doc and gcc bugs page yet I
> cannot seem to find the way to add this to the 'analyzer-c++' block, nor d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365
Benjamin Priour changed:
What|Removed |Added
CC||priour.be at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91196
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-31
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109350
--- Comment #4 from Andrew Macleod ---
Perhaps its clearer (HA!) if I turn the IL into a C program:
This is what the code sequence we are seeing effectively does:
int need_beer(int value);
int need_big_beer(unsigned long value);
int beer(int v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:92f02e754ca2fbcd56dbd7b3949147d50bab99a0
commit r13-6961-g92f02e754ca2fbcd56dbd7b3949147d50bab99a0
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #5 from Jonny Grant ---
(In reply to David Malcolm from comment #3)
> (In reply to Jonny Grant from comment #2)
> > Thank you for your reply David. Your analyzer is very good already.
> >
> > I played around a bit, a base of nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109366
Bug ID: 109366
Summary: No -Wanalyzer-null-dereference for unique_ptr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #3 from contact at thunderperfectwitchcraft dot org ---
I'm not sure if you read the thread I linked: If the statements there are
correct, atm a instruction that causes a crash under any circumstances is
generated and returned if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #4 from Andrew Pinski ---
(In reply to contact from comment #3)
> I'm not sure if you read the thread I linked: If the statements there are
> correct, atm a instruction that causes a crash under any circumstances is
> generated and r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #5 from contact at thunderperfectwitchcraft dot org ---
As mentioned, it isn't anymore: According to the linked Thread in gcc 13 a
return value that contains a invalid instruction is generated on purpose if
there is no return statemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #6 from Andrew Pinski ---
As I will mention it again falling through from a function which has a non void
return type is undefined. So gcc thinks it is unreachable. With the option is
specify in comment #2, gcc 13 will cause a trap (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:4969dcd2b7a94ce6c0d07225b21b5f3c040a4902
commit r13-6962-g4969dcd2b7a94ce6c0d07225b21b5f3c040a4902
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #7 from contact at thunderperfectwitchcraft dot org ---
I'm not sure if I understand you correct (as I'm not a native speaker): You say
that it crashes by chance because it is undefined behavior, right?
On reddit, I got this as a rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #8 from Andrew Pinski ---
That is because -funreachable-traps is also enabled at -O0. And disabled for
-O1 and above except for -Og. That changes all places where you either
__builtin_unreachable or places which gcc inserts that like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #9 from Jonathan Wakely ---
This is an intentional change in GCC 13, see PR 104642.
The comments in Bug 43943 describe old behaviour, things have changed.
The crash is not guaranteed though. The missing return is treated as
unreach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #10 from contact at thunderperfectwitchcraft dot org ---
Now I get it, thanks to you both.
Why not additionally make the -Werror=return-type option to default? Would make
it easier to detect and solve the issue, compared to a crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
--- Comment #11 from Jonathan Wakely ---
I already explained this on reddit, and it's already explained in PR 43943.
There are programs that are valid and must not give an error.
int f() { }
int main() { }
This never calls f() so ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
Jonathan Wakely changed:
What|Removed |Added
Summary|[12/13 Regression] |[12 Regression]
|bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109367
Bug ID: 109367
Summary: bogus -Wunused-function warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109367
--- Comment #1 from Andrew Pinski ---
Please file a different bug with your full testcase as I think decltype of a
lamba is a type which has local linkage but I could be wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109367
--- Comment #2 from Frank Heckenbach ---
My full testcase consists of many includes files, libraries etc.
The type declarations (corresponding to the first two lines of the
stripped-down example) are in a header to be called from other translat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109367
--- Comment #3 from Andrew Pinski ---
Actually I think the bug is:
using T = decltype ([]{});
is broken with GCC. There are multiple testcases dealing with that even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #17 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:fc4cde2e6aa4d6ebdf7f70b7b4359fb59a1915ae
commit r13-6964-gfc4cde2e6aa4d6ebdf7f70b7b4359fb59a1915ae
Author: Iain Sandoe
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b1f6cb2cc3aad0521ad3181d5107e52be155fd18
commit r13-6965-gb1f6cb2cc3aad0521ad3181d5107e52be155fd18
Author: Jakub Jelinek
Date: S
101 - 136 of 136 matches
Mail list logo
