[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds
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: Thu Mar 30 13:14:23 2023 +0530 c++,coroutines: Stabilize names of promoted slot vars [PR101118]. When we need to 'promote' a value (i.e. store it in the coroutine frame) it is given a frame entry name. This was based on the DECL_UID for slot vars. However, when LTO is used, the names from multiple TUs become visible at the same time, and the DECL_UIDs usually differ between units. This leads to a "ODR mismatch" warning for the frame type. The fix here is to use the current promoted temporaries count to produce the name, this is stable between TUs and computed per coroutine. Signed-off-by: Iain Sandoe PR c++/101118 gcc/cp/ChangeLog: * coroutines.cc (flatten_await_stmt): Use the current count of promoted temporaries to build a unique name for the frame entries.
[Bug c++/109367] bogus -Wunused-function warning with decltype of a lambda as an argument
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.
[Bug c++/109367] bogus -Wunused-function warning
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 translation units, and the function implementation (the last line) in a cpp file, as usual. So this means, decltype can't be used this way at all? If so, not a compiler bug; but severely disappointed in the standard again, rendering a hopeful feature mostly useless by too strict limitations. I hope it will be rectified in C++38 or so ... :/
[Bug c++/109367] bogus -Wunused-function warning
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.
[Bug c++/109367] New: bogus -Wunused-function warning
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++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
using T = decltype ([]{});
struct S { static void f(T); };
void S::f(T) {}
% g++ --std=c++20 -Wall -c test.cpp
test.cpp:3:6: warning: 'static void S::f(T)' defined but not used
[-Wunused-function]
3 | void S::f(T) {}
| ^
This happens with decltype of a lambda or a type containing such (in my actual
use case, a multimap with a comparator defined this way) in the function's
arguments or return type.
The warning is bogus since static member functions can be accessed from
elsewhere.
[Bug tree-optimization/107087] [12 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087 Jonathan Wakely changed: What|Removed |Added Summary|[12/13 Regression] |[12 Regression] |bits/stl_algobase.h:431:|bits/stl_algobase.h:431: |warning: 'void* |warning: 'void* |__builtin_memcpy(void*, |__builtin_memcpy(void*, |const void*, unsigned int)' |const void*, unsigned int)' |reading between 8 and |reading between 8 and |2147483644 bytes from a |2147483644 bytes from a |region of size 4|region of size 4 |[-Wstringop-overread] |[-Wstringop-overread] --- Comment #12 from Jonathan Wakely --- Fixed on trunk
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 there is no problem. -Werror=return-type would fail to
compile this valid program.
int g(bool b) { if (b) return 1; }
int main() { g(true); }
This program calls g(true) which is OK, it never calls g(false).
-Werror=return-type would fail to compile this valid program.
The C++ standard says these programs must be accepted without errors. What GCC
does is allow you to compile broken code, but it warns, and since GCC 13 it
tries to prevent completely unpredictable undefined behaviour if you
accidentally do fall off the end of a function without returning.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 binary.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 unreachable by the compiler. If the -funreachable-traps option is enabled, then calls to that function will result in a trap (and crash). The -funreachable-traps option is enabled by default for -O0 and -Og but at higher optimization levels the code is not guaranteed to crash unless you explicitly use -funreachable-traps.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 this place, gcc will cause a trap.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 reply: "I noticed that GCC13 seems to now add a purposeful invalid instruction to functions that have a return type, like Clang does. So your program crashes instead of attempting to continue with some trash return value." Which wouldn't be by chance to my understanding. What is correct?
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
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: Fri Mar 31 13:44:04 2023 +0100 libstdc++: Teach optimizer that empty COW strings are empty [PR107087] The compiler doesn't know about the invariant that the _S_empty_rep() object is immutable and so _M_length and _M_refcount are always zero. This means that we get warnings about writing possibly-non-zero length strings into buffers that can't hold them. If we teach the compiler that the empty rep is always zero length, it knows it can be copied into any buffer. For Stage 1 we might want to also consider adding this to capacity(): if (_S_empty_rep()._M_capacity != 0) __builtin_unreachable(); And this to _Rep::_M_is_leaked() and _Rep::_M_is_shared(): if (_S_empty_rep()._M_refcount != 0) __builtin_unreachable(); libstdc++-v3/ChangeLog: PR tree-optimization/107087 * include/bits/cow_string.h (basic_string::size()): Add optimizer hint that _S_empty_rep()._M_length is always zero. (basic_string::length()): Call size().
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 (usually an illegal instruction but could be an abort call). So there is nothing to change about gcc. Undefined code means just that if you invoke undefined code, anything can happen.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 statement, forcing a crash. To my understanding, this is the only thing that can happen now.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 returned if the statement is missing. Yes the code is undefined so anything can happen.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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 statement is missing.
[Bug analyzer/109366] New: No -Wanalyzer-null-dereference for unique_ptr
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: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: priour.be at gmail dot com
CC: priour.be at gmail dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Build: 13.0.1 20230328 (experimental)
Created attachment 54800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54800=edit
Preprocessed reproducer
While shared_ptr does, the usage of unique_ptrs doesn't lead to the expected
-Wanalyzer-null-dereference diagnostic.
// Preprocessed source in attachment.
#include
struct A {int x; int y;};
int main() {
std::unique_ptr a;
a->x = 12;
return 0;
}
bin/g++ -v --save-temps -S -fanalyzer -Wanalyzer-null-dereference
-Wanalyzer-possible-null-dereference -fanalyzer-fine-grained
null_dereference_unique_ptr_test.cpp
No diagnostics are issued.
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
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 doesn't give a warning. But > > changing to 0x10 does give array-bounds warning. > > cc1plus: note: source object is likely at address zero > > :13:13: warning: array subscript 0 is outside array bounds of 'a_t > > [0]' [-Warray-bounds=] > > > > https://godbolt.org/z/PhhT48xxP > > FWIW, note that [-Warray-bounds=] is separate from -fanalyzer. > > > > > Found Andrew Pinski comment says 4096 is not accessible: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699#c1 > > Aha - thanks for the link! I think that's the thing that I was > half-remembering (well, its dup, PR 99578), and that it was, in fact, in GCC. > > Looks like I should extend -Wanalyzer-null-dereference to warn about > accesses to constant addresses, but have it respect --param=min-pagesize= > (see r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18). This would have > to wait for GCC 14 at this point in the release cycle. > > > > > I wondered if you know how to turn on that "cc1plus: note: source object is > > likely at address zero? It seems different from normal warnings. > > Grepping the sources shows it's from gcc/pointer-query.cc: > access_ref::inform_access; I think it's one of the middle-end warnings that > triggers that, but I'm not sure exactly which (the analyzer doesn't use that > at the moment). Many thanks for your investigation and reply. > > It would be fantastic if there was a way for me to specify on the gcc > > command line an address range I didn't want read and/or writable. That would > > be great to get build warnings from those addresses if the compiler could > > see them being accessed. > > Is this always for stuff near the 0 address, or are there other use cases? > (embedded?) Are you able to post an example here of what the input might > look like? For me, I was mainly thinking issues due to reading near the 0x0 address (which is valid containing some stuff like the interrupt vector of function pointers etc). The best example would be the struct at NULL I put on godbolt. However, it is true that reading from other addresses that aren't HW mapped IO, RAM or Flash etc would also lead to faults, so if there was a way to specify the valid address ranges that would be great. I recall another compiler I used did let me specify valid ranges. Jonathan Wakely mentioned __attribute__((access(read_only, 1))); elsewhere it could imply the pointer was non-null (I couldn't get any build warnings through use of that attribute though in GCC 12). I don't know if the Analyzer could use that attribute too. > > > > At the moment, I always need to use the JTAG debugger to set some hw > > breakpoints on read from various addresses to catch those accesses (as they > > are mapped to the interrupt vector from 0x0). On Windows I've had various > > crashes where the access was address 0x10 so felt like that was probably a > > struct offset too > > > > I don't know very much about gcc internals. I did wonder if the analyzer can > > see the base address of the struct being passed as 0x0 in the RTL file? > > I tried -fdump-rtl-all but couldn't see the 0x0 address, or when I changed > > to 0x10 either > > The analyzer works on the gimple-ssa representation, which is before it > become RTL. If you want to see the gory details, have a look in: > https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html > in the gcc internal docs, and: > https://gcc-newbies-guide.readthedocs.io/en/latest/inside-cc1.html > in the guide for new gcc contributors I wrote. Thank thanks for the links. I modified the above example to have a base of 0x100 and noticed it in the SSA file MEM[(struct a_t *)256B].c[0] = 98; In the resulting ASM output, it was 8 bytes offset from the base. 0x108 Would be great if Analyzer could report on these in a future release.
[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors
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: Fri Mar 31 22:48:44 2023 +0200
testsuite, analyzer: Fix up pipe-glibc.c testcase [PR107396]
The gcc.dg/analyzer/pipe-glibc.c test FAILs when using recent glibc headers
and succeeds with older headers.
The important change is that
https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818
in 2021 added __attribute__ ((__malloc__ (fclose, 1))) attribute to fdopen,
so in write_to_pipe there is an excess warning:
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c: In function
'write_to_pipe':
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3: warning: use of
possibly-NULL 'stream' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:27:12: note: (1) this call
could return NULL
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3: note: (2) argument 4
('stream') from (1) could be NULL where non-null expected
: note: argument 4 of '__builtin_fwrite' must be non-null
Strangely, nothing is reported on the read_from_pipe function, seems
fwrite/fprintf/fputc etc. are builtins in GCC and we mark the FILE *
arguments as nonnull there on the builtin declarations, while fgetc/fread
etc. aren't builtins and glibc doesn't mark any of those using nonnull.
Shall we change that on the glibc side?
Anyway, because this differs based on glibc version and I think the
above warning is not the primary intention of the test, I think it is
best to tweak it so that this warning isn't reported.
Another option would be avoid using glibc headers and use our own
declarations, or make sure we add the malloc with fclose attribute
ourselves
(but fdopen in the libc headers could be a macro, so not sure
__typeof (fdopen) fdopen __attribute__ ((__malloc__, __malloc__ (fclose,
1)));
would work). Or use -Wno-analyzer-possible-null-arguments in
dg-additional-options?
2023-03-31 Jakub Jelinek
PR analyzer/107396
* gcc.dg/analyzer/pipe-glibc.c (read_from_pie, write_to_pipe): Exit
if fdopen returns NULL.
[Bug tree-optimization/109350] FAIL: g++.dg/warn/Wstringop-overflow-4.C
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 value)
{
unsigned long x = value;
unsigned long y = x + 0x8000;
if (y < 0x)
{
int r = x;
int t = r + 1;
unsigned long z = t;
if (x > 0x3FFC)
{
need_beer (r);
if (z <= 0x3FFC)
need_big_beer (z);
}
}
}
and with relevant outgoing edges:
:
x_3 = (long unsigned int) value_2(D);
y_4 = x_3 + 2147483648;
if (y_4 != 4294967295)
goto ; [INV]
else
goto ; [INV]
x_3 : [irange] long unsigned int [0, 2147483647][18446744071562067968, +INF]
y_4 : [irange] long unsigned int [0, 4294967295] NONZERO 0x
2->3 (T) value_2(D) : [irange] int [-INF, 2147483646]
2->3 (T) x_3 : [irange] long unsigned int [0,
2147483646][18446744071562067968, +INF]
2->3 (T) y_4 : [irange] long unsigned int [0, 4294967294] NONZERO
0x
:
t_7 = value_2(D) + 1;
z_8 = (long unsigned int) t_7;
if (x_3 > 4611686018427387900)
goto ; [INV]
else
goto ; [INV]
t_7 : [irange] int [-2147483647, +INF]
z_8 : [irange] long unsigned int [0, 2147483647][18446744071562067969, +INF]
3->4 (T) value_2(D) : [irange] int [-INF, -1]
3->4 (T) x_3 : [irange] long unsigned int [18446744071562067968, +INF]
3->4 (T) t_7 : [irange] int [-2147483647, 0]
3->4 (T) z_8 : [irange] long unsigned int [0, 0][18446744071562067969,
+INF]
:
need_beer (value_2(D));
if (z_8 <= 4611686018427387900)
goto ; [INV]
else
goto ; [INV]
4->5 (T) value_2(D) : [irange] int [-1, -1]
4->5 (T) z_8 : [irange] long unsigned int [0, 0] NONZERO 0x0
:
need_big_beer (0);
[Bug analyzer/109361] RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-03-31 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #0) > My integration tests for -fanalyzer don't yet track how long the analyzer > takes on the real-world cases. Filed as https://github.com/davidmalcolm/gcc-analyzer-integration-tests/issues/5 > It would be nice for the .sarif files generated by > -fdiagnostics-format=sarif-file to contain profiling or timing information. I'm testing an implementation of this, which puts the -ftime-report data into a property bag of the "invocation" object.
[Bug fortran/91196] Interface generated for proc with VALUE, OPTIONAL misses hidden is-present argument
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 --- Comment #3 from anlauf at gcc dot gnu.org --- Should work in gcc-13 after the fixes for pr107441 and pr107444. I get: logical(kind=1) foo (void * x, integer(kind=4)[1] * y, integer(kind=4) * z, integer(kind=4) z2, logical(kind=1) .z2) and in the main: static logical(kind=1) foo (void *, integer(kind=4)[1] *, integer(kind=4) *, integer(kind=4), logical(kind=1)); Note the update on the ABI documentation. Tobias: can you please check?
[Bug analyzer/109365] Double delete yields -Wanalyzer-use-after-free instead of -Wanalyzer-double-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365 Benjamin Priour changed: What|Removed |Added CC||priour.be at gmail dot com --- Comment #2 from Benjamin Priour --- (In reply to David Malcolm from comment #1) > (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 do > > I see the option in the advanced fields.) > > I've added it for you; see the "Blocks: " field of show_bug.cgi Ahah yes thank you, you sure were fast, I only had time to notice the field actually appearing only after I submitted the bug, that you had already updated it.
[Bug analyzer/109365] Double delete yields -Wanalyzer-use-after-free instead of -Wanalyzer-double-free
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 do > I see the option in the advanced fields.) I've added it for you; see the "Blocks: " field of show_bug.cgi
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
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+ and M4 targets: > > const char *bootloaderVersionText = *reinterpret_cast(0x20); > > I haven't found a workaround other than to use a pragma to disable the > warning for that line of code. The change in your build would be --param=min-pagesize=0 . I made a mention of this a few times in this bug report on why avr is different from arm here.
[Bug analyzer/109365] New: Double delete yields -Wanalyzer-use-after-free instead of -Wanalyzer-double-free
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
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: priour.be at gmail dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Build: 13.0.1 20230328 (experimental)
Double delete does not result in a -Wanalyzer-double-free warning as expected,
but rather into -Wanalyzer-use-after-free warning.
Using the following reproducer:
// file ../../double_delete_test.cpp
struct A {int a; int b;};
int main () {
A* a = new A();
delete a;
delete a;
return 0;
}
Then compiling with
./xg++ -B. -S -fanalyzer -Wanalyzer-double-free ../../double_delete_test.cpp
../../double_delete_test.cpp: In function ‘int main()’:
../../double_delete_test.cpp:9:1: warning: use after ‘delete’ of ‘a’ [CWE-416]
[-Wanalyzer-use-after-free]
9 | }
| ^
‘int main()’: events 1-7
|
|5 | A* a = new A();
| | ^
| | |
| | (1) state of ‘_ALLOCATED_REGION(10)’:
‘start’ -> ‘nonnull’ (NULL origin)
|6 | delete a;
| |
| | | |
| | | (3) ...to here
| | | (4) deleted here
| | (2) following ‘true’ branch...
|7 | delete a;
| |
| | | |
| | | (6) ...to here
| | (5) following ‘true’ branch...
|8 | return 0;
|9 | }
| | ~
| | |
| | (7) use after ‘delete’ of ‘a’; deleted at (4)
|
I also attempted with -fno-exception, but no impact was observer on the graphs
nor the output.
With the addition of -fanalyzer-fine-grained, I observed than each delete
statement is actually split into two:
delete a;
becomes in the ipa form
:
*a.0_9 ={v} {CLOBBER};
operator delete (a.0_9, 8);
The exploded-graph shows that the second '*a.1_12 ={v} {CLOBBER};' dereference
is responsible for the -Wanalyzer-use-after-free, and changes the state of the
allocated region from 'freed' to 'stop', which causes the actual following
'operator delete' to not be detected as a double free.
I am still familiarizing myself with the gimplification and ssa passes, so I'm
yet unsure as to how to tackle this.
I'm still looking into this though, and would gladly receive your pointers.
(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 do I
see the option in the advanced fields.)
[Bug fortran/96084] ICE in free_expr0, at fortran/expr.c:446
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.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I will have to investigate further. I was involved in implementing a lot of this.
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
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 me with today's 13-trunk, but not 12-branch. However, the full original testcase fails with varying errors depending on the gfortran version.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
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 from Xi Ruoyao --- (In reply to Jonny Grant from comment #4) > (In reply to Andrew Pinski from comment #2) > > Oh and the manual is not exactly out of date for that version of gcc. So the > > text you have would be wrong. > > Sorry, you're completely right. A script could search for and insert > after: > > Warning: This GCC manual is not the href="https://gcc.gnu.org/onlinedocs/gcc-latest-stable-redirect;>latest GCC > release It would be wrong. GCC 9.5 released after GCC 12.1, so GCC 12.1 was not the "latest" GCC release on May 27, 2022. But we absolutely didn't want people to look at GCC 9.5 doc instead of 12.1.
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
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 was just thinking it could use the
[2] to know that it had got 2 elements, and that } closing brace was needed
before the comma.
ie.
:5:10: error: expected '}' before ',' token
5 | {"E", "F",
| ^
Or I thought it could just count the number of braces, and when it got to the
3rd open brace {
ie.
:6:2: error: expected '}' before '{' token
5 | {"E", "F",
| ^
[Bug gcov-profile/100289] [11/12/13 Regression] libgcc/libgcov.h: bootstrap failure due to missing #include
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)?
[Bug gcov-profile/100289] [11/12/13 Regression] libgcc/libgcov.h: bootstrap failure due to missing #include
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/glibc/scripts/build-many-glibcs.py --keep all --replace-sources -j 1 /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21 checkout binutils-vcs-master gcc-vcs-master glibc-vcs-master linux-vcs-master log_execute host-libraries /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/glibc/scripts/build-many-glibcs.py --keep all --replace-sources -j 1 /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21 host-libraries log_execute compilers /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/glibc/scripts/build-many-glibcs.py --keep all --replace-sources -j 1 /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21 --full-gcc compilers alpha-linux-gnu (as an example, use the Alpha builds at http://toolchain.lug-owl.de/laminar/jobs/glibcbot-alpha-linux-gnu , with the actual breakage for example at http://toolchain.lug-owl.de/archive/glibcbot-alpha-linux-gnu/21/logs/compilers/alpha-linux-gnu/012-compilers-alpha-linux-gnu-gcc-first-build-log.txt) ...we're ending up at the same spot: echo 'int __libgcc_eh_dummy;' > eh_dummy.c; \ /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/build/compilers/alpha-linux-gnu/gcc-first/./gcc/xgcc -B/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/build/compilers/alpha-linux-gnu/gcc-first/./gcc/ -B/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/bin/ -B/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/lib/ -isystem /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/include -isystem /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/sys-include -g -O2 -mieee -O2 -g -O2 -mieee -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mieee -mfp-rounding-mode=d -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -mieee -mfp-rounding-mode=d -I. -I. -I../.././gcc -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/. -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/../gcc -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/../include -DHAVE_CC_TLS -fvisibility=hidden -DHIDE_EXPORTS -c eh_dummy.c \ -o eh_dummy.o; \ objects=eh_dummy.o; \ fi; \ /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/bin/ar rc libgcc.a $objects /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/bin/ranlib libgcc.a /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/build/compilers/alpha-linux-gnu/gcc-first/./gcc/xgcc -B/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/build/compilers/alpha-linux-gnu/gcc-first/./gcc/ -B/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/bin/ -B/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/lib/ -isystem /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/include -isystem /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/install/compilers/alpha-linux-gnu/alpha-glibc-linux-gnu/sys-include -g -O2 -mieee -O2 -g -O2 -mieee -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mieee -mfp-rounding-mode=d -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -mieee -mfp-rounding-mode=d -I. -I. -I../.././gcc -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/. -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/../gcc -I/var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/../include -DHAVE_CC_TLS -o _gcov_merge_add.o -MT _gcov_merge_add.o -MD -MP -MF _gcov_merge_add.dep -DL_gcov_merge_add -c /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/libgcov-merge.c In file included from /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/libgcov-merge.c:26: /var/lib/laminar/run/glibcbot-alpha-linux-gnu/21/src/gcc/libgcc/libgcov.h:49:10: fatal error: sys/mman.h: No such file or directory 49 | #include | ^~~~ compilation terminated. ISTR
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
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.
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- >it should be only a warning since it can work if the return value isn't used >anywhere No that is for C, for C++: "The point being that it's undefined behaviour to /return/ from such a function, not to /write/ such a function." See comment #5 *** This bug has been marked as a duplicate of bug 43943 ***
[Bug c++/43943] "warning: no return statement in function returning non-void" should be an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943 Andrew Pinski changed: What|Removed |Added CC||contact@thunderperfectwitch ||craft.org --- Comment #9 from Andrew Pinski --- *** Bug 109364 has been marked as a duplicate of this bug. ***
[Bug c++/109364] New: Missing return statement in a non void function gives only a warning but produces a forced crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
Bug ID: 109364
Summary: Missing return statement in a non void function gives
only a warning but produces a forced crash.
Product: gcc
Version: 13.0
URL: https://www.reddit.com/r/gcc/comments/123ojov/no_retur
n_in_function_binary_crashes_with/
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: contact at thunderperfectwitchcraft dot org
Target Milestone: ---
Calling
int Test()
{
std::cout << "Test";
}
from main causes the program to crash, even though only a warning is given.
As pointed out in this thread
https://www.reddit.com/r/gcc/comments/123ojov/no_return_in_function_binary_crashes_with/
this is because a invalid instruction is returned to cause the crash to prevent
people from letting out the return statement. But here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943
it is stated that it should be only a warning since it can work if the return
value isn't used anywhere. This is no longer the case, as there is no way to
bring this code to run as far as I can see. To reduce the confusion it should
be a error by default, everything else is only frustrating.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #5 from joseph at codesourcery dot com --- As I mentioned in previous discussions of this idea: any implementation should *not* involve simply editing the old generated files in place; it needs to involve keeping an unmodified copy of those files (which it might not readily be possible to regenerate now with current Texinfo) and having a properly automated process that goes from the unmodified source to the modified version served on the website, with the ability to rerun a new version of that process at any time.
[Bug c++/109357] [12/13 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r12-6329-g4f6bc28fc7dd86bd9e7408cbf
[Bug c++/109357] [12/13 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |12.3 Known to work||11.3.0 CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-31 Ever confirmed|0 |1 Summary|GCC 13.0.1: internal|[12/13 Regression] internal |compiler error in |compiler error in |cp/constexpr.cc:1685|cp/constexpr.cc:1685 Known to fail||12.2.0
[Bug tree-optimization/109363] New: [13 Regression] gcc.dg/tree-ssa/pr23109.c cris-elf reciptmp with r13-6945-g429a7a88438cc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109363 Bug ID: 109363 Summary: [13 Regression] gcc.dg/tree-ssa/pr23109.c cris-elf reciptmp with r13-6945-g429a7a88438cc8 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: amacleod at redhat dot com Target Milestone: --- Target: cris-elf Created attachment 54799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54799=edit failing pr23109.c.189t.recip (at r13-6956-ge02c9d9116f2) With r13-6944-ga23b33a1bdeff7 this test passed. At r13-6945-g429a7a88438cc8 I see for the first time: FAIL: gcc.dg/tree-ssa/pr23109.c scan-tree-dump-not recip "reciptmp" In gcc.log: Executing on host: /x/cris-elf/gccobj/gcc/xgcc -B/x/cris-elf/gccobj/gcc/ /x/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c\ -fdiagnostics-plain-output -O2 -funsafe-math-optimizations -ftrapping-math -fdump-tree-recip -fdump-tree-lim2 -S \ -isystem /x/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /x/gcc/newlib/libc/include -o pr23109.s(timeo\ ut = 300) spawn -ignore SIGHUP /x/cris-elf/gccobj/gcc/xgcc -B/x/cris-elf/gccobj/gcc/ /x/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23109\ .c -fdiagnostics-plain-output -O2 -funsafe-math-optimizations -ftrapping-math -fdump-tree-recip -fdump-tree-lim2 -S -is\ ystem /x/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /x/gcc/newlib/libc/include -o pr23109.s^M cc1: warning: '-fassociative-math' disabled; other options take precedence^M PASS: gcc.dg/tree-ssa/pr23109.c at line 3 (test for warnings, line ) PASS: gcc.dg/tree-ssa/pr23109.c (test for excess errors) PASS: gcc.dg/tree-ssa/pr23109.c scan-tree-dump-not lim2 "reciptmp" FAIL: gcc.dg/tree-ssa/pr23109.c scan-tree-dump-not recip "reciptmp" I'm attaching pr23109.c.189t.recip
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362 --- Comment #4 from Barry Revzin --- Awesome!
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362
--- Comment #3 from Jakub Jelinek ---
Reduced C testcase would be
struct S { long a, b; };
int
foo (struct S *v)
{
while (1)
{
__atomic_load_n (>a, __ATOMIC_ACQUIRE);
if (__atomic_load_n (>b, __ATOMIC_ACQUIRE))
return 1;
}
}
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This got fixed with r13-137-gee1cb43bc76de800efa0ade6 on the trunk.
[Bug target/109087] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087 Jakub Jelinek changed: What|Removed |Added Summary|[13 Regression] csmith: end |csmith: end of year runtime |of year runtime bug since |bug since |r13-4839-geef81eefcdc2a581 |r13-4839-geef81eefcdc2a581 Priority|P1 |P3
[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-03-31 --- Comment #4 from Jonathan Wakely --- (In reply to Jason Merrill from comment #1) > Why does _M_get clear _M_sbuf? Because that's what the standard implies should happen: If the end of stream is reached (streambuf_type::sgetc() returns traits::eof()), the iterator becomes equal to the end-of-stream iterator value." charT operator*() const; 1 Returns: The character obtained via the streambuf member sbuf_->sgetc(). But this means that a dereferenceable iterator can become non-dereferenceable as a result of dereferencing it ... which seems very wrong indeed. It seems better to check for EOF on operator++ and only clear _M_sbuf in that function, but we need to basically rewrite the entire class (without ABI changes) to do that.
[Bug target/109093] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P3 Summary|[13 regression] csmith: a |csmith: a February runtime |February runtime bug ? |bug ?
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #8 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:e9910e002d610db6e08230583c2976c9a557131b commit r13-6959-ge9910e002d610db6e08230583c2976c9a557131b Author: Vladimir N. Makarov Date: Fri Mar 31 11:04:44 2023 -0400 LRA: Implement commutative operands exchange for combining secondary memory reload and original insn The patch implements trying commutative operands exchange for combining secondary memory reload and original insn. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: (combine_reload_insn): New function. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052-2.c: New.
[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087 --- Comment #18 from Jakub Jelinek --- It is true that with r13-6661 + r13-6691 this bug is just latent, so perhaps it doesn't need to be P1 unless somebody comes up with a reproducer.
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 --- Comment #22 from Jakub Jelinek --- It is true that with r13-6661 + r13-6691 this bug is just latent, so perhaps it doesn't need to be P1 unless somebody comes up with a reproducer.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a35e8042fbc7a3eb9cece1fba4cdd3b6cdfb906f commit r13-6958-ga35e8042fbc7a3eb9cece1fba4cdd3b6cdfb906f Author: Jonathan Wakely Date: Fri Mar 31 13:38:14 2023 +0100 libstdc++: Avoid -Wmaybe-uninitialized warning in std::stop_source [PR109339] We pass a const-reference to *this before it's constructed, and GCC assumes that all const-references are accessed. Add the access attribute to say it's not accessed. libstdc++-v3/ChangeLog: PR libstdc++/109339 * include/std/stop_token (_Stop_state_ptr(const stop_source&)): Add attribute access with access-mode 'none'. * testsuite/30_threads/stop_token/stop_source/109339.cc: New test.
[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104 Yanzhang, Wang changed: What|Removed |Added CC||yanzhang.wang at intel dot com --- Comment #5 from Yanzhang, Wang --- We are still working on it. Hope it can be pushed soon.
[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 Bug 56183 depends on bug 90706, which changed state. Bug 90706 Summary: [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362
--- Comment #1 from Barry Revzin ---
Sorry, in this reduced example, it doesn't actually consume an extra register -
only rdi is used.
In this slightly less reduced example:
#include
struct S {
std::atomic size;
std::atomic read_ptr;
auto peek() const -> const char* {
auto const s = size.load(std::memory_order_acquire);
return read_ptr.load(std::memory_order_acquire);
}
};
auto with_atomic(S const& v) {
while (true) {
if (v.peek()) {
return true;
}
}
}
the codegen is:
with_atomic(WithAtomic const&):
lea rdx, [rdi+8]
.L2:
mov rax, QWORD PTR [rdi]
mov rax, QWORD PTR [rdx]
testrax, rax
je .L2
mov eax, 1
ret
which now does consume rdx unnecessarily.
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Georg-Johann Lay changed: What|Removed |Added Known to fail||10.0, 11.0, 12.0, 9.0 Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||13.0 --- Comment #22 from Georg-Johann Lay --- Fixed in 12.3+
[Bug tree-optimization/109350] FAIL: g++.dg/warn/Wstringop-overflow-4.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109350
--- Comment #3 from Andrew Macleod ---
On 3/31/23 03:17, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109350
>
> Richard Biener changed:
>
> What|Removed |Added
>
> CC||amacleod at redhat dot com
>
> --- Comment #2 from Richard Biener ---
> Hmm, the same reproduces with r_imin_imax as ptrdiff_t but the IL is a bit
> more obvious:
>
> [local count: 1073741824]:
> _27 ={v} signed_value_source;
> _4 = (unsigned long) _27;
> _8 = _4 + 2147483648;
> if (_8 > 4294967295)
>goto ; [50.00%]
> else
>goto ; [50.00%]
>
> [local count: 536870913]:
> _30 = _27 + 1;
> _28 = (sizetype) _30;
> if (_4 <= 4611686018427387900)
>goto ; [50.00%]
> else
>goto ; [50.00%]
>
> [local count: 268435458]:
> _12 = operator new [] (18446744073709551615);
> __builtin_memcpy (_12, [(void
> *)"0123456789abcdefghijklmnopqrstuvwxyz" + 35B], 2);
> sink (_12);
> if (_28 <= 4611686018427387900)
>goto ; [100.00%]
> else
>goto ; [0.00%]
>
> [local count: 0]:
> iftmp.2_37 = _28 * 2;
> _39 = operator new [] (iftmp.2_37);
> __builtin_memcpy (_39, [(void
> *)"0123456789abcdefghijklmnopqrstuvwxyz" + 34B], 3);
>
> so we have (unsigned long)[int_min, int_max] > 4611686018427387900
> && (unsigned long)[int_min+1, int_max+1] <= 4611686018427387900 to
> constrain _4. I don't see how we can arrive at [0,0] for iftmp.2_37.
Looking at what ranger produces for vrp2 (same code just a few passes
later):
=== BB 2
Imports: _28
Exports: _4 _10 _28
_4 : _28(I)
_10 : _4 _28(I)
Partial equiv (_4 pe64 _28)
Relational : (_10 != _4)
[local count: 1073741824]:
_28 ={v} signed_value_source;
_4 = (unsigned long) _28;
_10 = _4 + 2147483648;
if (_10 > 4294967295)
goto ; [50.00%]
else
goto ; [50.00%]
2->3 (F) _4 : [irange] unsigned long [0,
2147483647][18446744071562067968, +INF]
2->3 (F) _10 : [irange] unsigned long [0, 4294967295] NONZERO
0x
2->3 (F) _28 : [irange] long int [-2147483648, 2147483647]
on entry top BB3 , _28 has the full range of a signed int in a long int
body.
=== BB 3
_4 [irange] unsigned long [0, 2147483647][18446744071562067968, +INF]
_28 [irange] long int [-2147483648, 2147483647]
Partial equiv (r_imin_imax_8 pe32 _28)
Relational : (_31 > r_imin_imax_8)
[local count: 536870913]:
r_imin_imax_8 = (int) _28; << THIs is
varying, which is why it isnt printed anywhere
_31 = r_imin_imax_8 + 1; << signed traps on overflowt, so
this would be [min+1, +INF]
_29 = (sizetype) _31; << sizetype is a larger unsigned
object,so the possible values for it are [0,
2147483647][18446744071562067969, +INF]
if (_4 <= 4611686018427387900) << this leaves _4 with
possible values of [18446744071562067968, +INF] on the FALSE branch.
goto ; [50.00%]
else
goto ; [50.00%]
_29 : [irange] sizetype [0, 2147483647][18446744071562067969, +INF]
_31 : [irange] int [-2147483647, +INF]
When we recalculate values based on the range of _4 on the false
branch, intersected with their knowns ranges, it comes up with this
3->5 (F) _4 : [irange] unsigned long [18446744071562067968, +INF]
3->5 (F) r_imin_imax_8 : [irange] int [-INF, -1]
3->5 (F) _28 : [irange] long int [-2147483648, -1]
3->5 (F) _29 : [irange] sizetype [0, 0][18446744071562067969, +INF]
3->5 (F) _31 : [irange] int [-2147483647, 0]
when we feed that value of _4 into
[18446744071562067968, +INF] = (unsigned long)28
in BB2, we discover the only possible valiues of _28 are [-2147483648,
-1] on this branch.
We now go an recalculate r_imin_imax_8, _31 and _29 based on this new
value of _28 and come up with those ranges
that means when we get to bb5, and see
if (_29 <= 4611686018427387900)
goto ; [100.00%]
the only possible value of _29 on this branch is a [0,0] And thats a
direct result of _31 = [-INF, -1] + 1 before _20 is created with the cast.
yikes. talk about convoluted...
>
> In fact if I put this into a separate testcase like
>
> void __attribute__((noipa))
> foo (long signed_value_source)
> {
>unsigned long temu = signed_value_source;
>if (temu + 2147483648 > 4294967295)
> ;
>else
> {
> long tems = signed_value_source + 1;
> unsigned long temu2 = tems;
> if (temu > 4611686018427387900)
> if (temu2 <= 4611686018427387900)
> {
> unsigned long iftmp = temu2 * 2;
> if (iftmp == 0)
> __builtin_abort ();
> }
> }
> }
>
> then we optimize this to
>
> [local count: 1073741824]:
>temu_3 = (long unsigned int)
[Bug c++/109359] [12/13 Regression] Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think the fold-const.cc change is right though. I wonder if for constant evaluation (constexpr, constinit) we shouldn't arrange for those to be evaluated with temporarily -fno-rounding-math, I think C uses fold_init and its START_FOLD_INIT ... END_FOLD_INIT for this purpose.. And otherwise perhaps we want dynamic initialization and do the conversion at runtime? Or disable the -frounding-math for all initializer folding? What we emit is definitely wrong, Variable which claims to have 8 bytes in size but actually has 16 under the hood, with constants in different mode.
[Bug c++/109362] New: codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362
Bug ID: 109362
Summary: codegen adds unnecessary extra add when reading atomic
member
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This program:
#include
struct S {
long size;
std::atomic read_ptr;
auto peek() const -> const char* {
return read_ptr.load(std::memory_order_acquire);
}
};
auto with_atomic(S const& v) {
while (true) {
if (v.peek()) {
return true;
}
}
}
emits (on gcc 12.2 -O3):
with_atomic(S const&):
add rdi, 8
.L2:
mov rax, QWORD PTR [rdi]
testrax, rax
je .L2
mov eax, 1
ret
But that add is completely necessary, the mov could just be:
mov rax, QWORD PTR [rdi + 8]
which is what clang (16.0 -O3) generates:
with_atomic(S const&):# @with_atomic(S const&)
.LBB0_1:# =>This Inner Loop Header: Depth=1
mov rax, qword ptr [rdi + 8]
testrax, rax
je .LBB0_1
mov al, 1
ret
It's not just an extra add, it's consuming an extra register - which has more
downstream optimization effects.
[Bug c++/109359] [12/13 Regression] Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Jakub Jelinek --- Started with r12-4764-ga84b9d5373c7e67fd0ab2a
[Bug c++/109359] [12/13 Regression] Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-31 Target Milestone|--- |12.3 Summary|Compile-time rounding of|[12/13 Regression] |double literal to float is |Compile-time rounding of |incorrect with |double literal to float is |-frounding-math |incorrect with ||-frounding-math Keywords||needs-bisection, wrong-code Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- With -frounding-math: xs: .long -639366012 .long 1063214053 .long 536561674 .long 1071918432 without: xs: .long 989519663 .long 1059154689 it looks like we fail to convert the double constant to single precision and then end up outputting the double precision constants ... The C frontend works.
[Bug analyzer/109361] RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 --- Comment #1 from David Malcolm --- Some existing SARIF properties we could generate: 3.20.7 startTimeUtc property An invocation object MAY contain a property named startTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the invocation started. 3.20.8 endTimeUtc property An invocation object MAY contain a property named endTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the invocation ended. 3.38.12 executionTimeUtc property A threadFlowLocation object MAY contain a property named executionTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the thread of execution through the code reached this location. 3.48.2 firstDetectionTimeUtc property A resultProvenance object MAY contain a property named firstDetectionTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the result was first detected. It SHOULD specify the start time of the run in which the result was first detected, as opposed to, for example, the time within the run at which the result was actually generated. NOTE: Using the run’s start time makes it possible to group together results that were first detected in the same run. 3.48.3 lastDetectionTimeUtc property A resultProvenance object MAY contain a property named lastDetectionTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the result was most recently detected. It SHOULD specify the start time of the run in which the result was most recently detected, as opposed to, for example, the time within the run at which the result was actually generated. NOTE: Using the run’s start time makes it possible to group together results that were detected in the same run. If lastDetectionTimeUtc is absent, its default value SHALL be determined as follows: 1. If run.invocations is present, and if the startTimeUtc property (§3.20.7) is present on any of the invocation objects (§3.20) in that array, then the default is the earliest of those times. 2. Otherwise, there is no default. 3.58.8 timeUtc property A notification object MAY contain a property named timeUtc whose value is a string in the format specified §3.9, specifying the UTC date and time at which the analysis tool generated the notification. or perhaps we could use a property bag (e.g. to capture timevar information)
[Bug analyzer/109361] New: RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 Bug ID: 109361 Summary: RFE: SARIF output could contain timing/profile information Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- My integration tests for -fanalyzer don't yet track how long the analyzer takes on the real-world cases. It would be nice for the .sarif files generated by -fdiagnostics-format=sarif-file to contain profiling or timing information.
[Bug other/109163] SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from David Malcolm --- Should be fixed by the above patch on trunk for GCC 13.
[Bug testsuite/109360] New: RFE: check that generated .sarif files validate against the SARIF schema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109360 Bug ID: 109360 Summary: RFE: check that generated .sarif files validate against the SARIF schema Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 54798 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54798=edit WIP progress patch I have a partially-working patch to scansarif.exp that validates the .sarif files generated by -fdiagnostics-format=sarif-file against the sarif schema. Filing here to keep track of merging this to trunk
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #4 from Jonny Grant --- (In reply to Andrew Pinski from comment #2) > Oh and the manual is not exactly out of date for that version of gcc. So the > text you have would be wrong. Sorry, you're completely right. A script could search for and insert after: Warning: This GCC manual is not the https://gcc.gnu.org/onlinedocs/gcc-latest-stable-redirect;>latest GCC release
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #21 from Vladimir Makarov --- (In reply to CVS Commits from comment #20) > The releases/gcc-12 branch has been updated by Vladimir Makarov > : > > https://gcc.gnu.org/g:88792f04e5c63025506244b9ac7186a3cc10c25a > > The trunk with the patch behaved good for a few weeks. So I backported it to gcc-12 branch. GCC-12 branch with the patch was successfully tested and bootstrapped on x86-64.
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #10 from Jonathan Wakely ---
I wonder if some other hints about properties of the empty rep would help
codegen:
--- a/libstdc++-v3/include/bits/cow_string.h
+++ b/libstdc++-v3/include/bits/cow_string.h
@@ -204,6 +204,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
_M_is_leaked() const _GLIBCXX_NOEXCEPT
{
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_S_empty_rep()._M_refcount != 0)
+ __builtin_unreachable();
+#endif
+
#if defined(__GTHREADS)
// _M_refcount is mutated concurrently by _M_refcopy/_M_dispose,
// so we need to use an atomic load. However, _M_is_leaked
@@ -218,6 +223,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
_M_is_shared() const _GLIBCXX_NOEXCEPT
{
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_S_empty_rep()._M_refcount != 0)
+ __builtin_unreachable();
+#endif
+
#if defined(__GTHREADS)
// _M_refcount is mutated concurrently by _M_refcopy/_M_dispose,
// so we need to use an atomic load. Another thread can drop last
@@ -907,17 +917,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
public:
// Capacity:
+
/// Returns the number of characters in the string, not including any
/// null-termination.
size_type
size() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ {
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_S_empty_rep()._M_length != 0)
+ __builtin_unreachable();
+#endif
+ return _M_rep()->_M_length;
+ }
/// Returns the number of characters in the string, not including any
/// null-termination.
size_type
length() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ { return size(); }
/// Returns the size() of the largest possible %string.
size_type
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:88792f04e5c63025506244b9ac7186a3cc10c25a commit r12-9372-g88792f04e5c63025506244b9ac7186a3cc10c25a Author: Vladimir N. Makarov Date: Thu Mar 2 16:29:05 2023 -0500 IRA: Use minimal cost for hard register movement This is the 2nd attempt to fix PR90706. IRA calculates wrong AVR costs for moving general hard regs of SFmode. This was the reason for spilling a pseudo in the PR. In this patch we use smaller move cost of hard reg in its natural and operand modes. PR rtl-optimization/90706 gcc/ChangeLog: * ira-costs.cc: Include print-rtl.h. (record_reg_classes, scan_one_insn): Add code to print debug info. (record_operand_costs): Find and use smaller cost for hard reg move. gcc/testsuite/ChangeLog: * gcc.target/avr/pr90706.c: New.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- Oh good! Testing that now then ...
[Bug c++/109359] New: Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
Bug ID: 109359
Summary: Compile-time rounding of double literal to float is
incorrect with -frounding-math
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
The following program should print:
0.001914
0.630538
With "g++ -frounding-math", it prints instead:
-8023756970655744.00
0.872496
This bug is present in trunk, and since gcc 12.1, and does not appear to be
platform specific.
Compiler explorer link: https://godbolt.org/z/aMhcYcY66
#include
float xs[] = {0.001914, 0.630539};
int main() {
std::size_t size = sizeof xs / sizeof xs[0];
for (std::size_t i = 0; i != size; ++i) {
std::printf("%f\n", xs[i]);
}
}
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #37 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #36) > > --- a/gcc/tree-inline.cc > > +++ b/gcc/tree-inline.cc > > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, > > profile_count count) > >/* Get clean struct function. */ > >push_struct_function (new_fndecl, true); > >targetm.target_option.relayout_function (new_fndecl); > > + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl > > +gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8); > > > >/* We will rebuild these, so just sanity check that they are empty. */ > >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); > > This one passed the build. That is kind of bad news for trying to debug where the problem is, because the above patch has only effect of doing 4 extra GC allocations, so the -fno-checking vs. -fchecking=1 bug was just latent before, perhaps some code generation decision is done from pointer comparisons or something similar. If the problem without this patch is reliably reproduceable even with the same d21 binary but not after enabling all the dumps, perhaps another attempt would be try to see if enabling just one dump somewhere would make it latent again as well or if it would still reproduce. So rather than trying to -fdump-tree-all -da, perhaps just try -fdump-tree-optimized, or -fdump-rtl-vregs or -fdump-rtl-postreload etc. If the assemblies differ even with just one of those dumps enabled, you can see if there is any difference in the dump or not. Other option would be only side-by-side debugging but without the dumps actually working it is much harder to find out where to look at.
[Bug tree-optimization/109334] tree-object-size: Improve size computation in arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334 --- Comment #2 from Siddhesh Poyarekar --- That seems OK; I had added that to be conservative since I really only intended to add support for the access attribute back then and not the implicit attributes. Could you please post that on the ML and have it reviewed? Thanks!
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #10 from Jakub Jelinek --- __attribute__((__access__(__none__, 2))) on the ctor works, no need to add pragmas.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #35 from Jakub Jelinek --- > Sorry for wasting your time. No worries: it's mostly the SPARC box doing the compiles ;-) > --- a/gcc/tree-inline.cc > +++ b/gcc/tree-inline.cc > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, > profile_count count) >/* Get clean struct function. */ >push_struct_function (new_fndecl, true); >targetm.target_option.relayout_function (new_fndecl); > + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl > +gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8); > >/* We will rebuild these, so just sanity check that they are empty. */ >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); This one passed the build.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
--- Comment #9 from Jonathan Wakely ---
Yes, we can pass something else there instead.
It would be nice if this worked to silence the warning though:
--- a/libstdc++-v3/include/std/stop_token
+++ b/libstdc++-v3/include/std/stop_token
@@ -395,10 +395,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
_Stop_state_ref() = default;
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
+ __attribute__((__access__(__none__, 1)))
explicit
_Stop_state_ref(const stop_source&)
: _M_ptr(new _Stop_state_t())
{ }
+#pragma GCC diagnostic pop
_Stop_state_ref(const _Stop_state_ref& __other) noexcept
: _M_ptr(__other._M_ptr)
It has no effect at all (putting the pragmas around the caller works though).
Now that we have the access attribute, why doesn't access(none, N) help here?
It seems to express exactly what I want to express here, but the warning
doesn't care.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
What is the
explicit
_Stop_state_ref(const stop_source&)
: _M_ptr(new _Stop_state_t())
{ }
there for, can't you use some completely unrelated type there instead (bool,
stop_source*, some enum, whatever), or drop the const at least?
The passing pointer to uninitialized const object or reference to uninitialized
const object to function we don't know anything about is I think one of the
design goals of Martin's change which probably not everybody will agree with,
but it is true that it can sometimes find bugs in code.
[Bug tree-optimization/109353] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353 --- Comment #5 from Richard Biener --- (In reply to Jonathan Wakely from comment #4) > This doesn't help: > > --- a/libstdc++-v3/include/bits/vector.tcc > +++ b/libstdc++-v3/include/bits/vector.tcc > @@ -936,15 +936,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER > *__position = __x; > ++this->_M_impl._M_finish; > } > + else if (!this->_M_impl._M_start._M_p) yes, we can't CSE this load from the = nullptr assignment so we'd still diagnose the else case ...
[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug middle-end/65534] tailcall not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #9 from Jonathan Wakely ---
This prevents the warning:
--- a/libstdc++-v3/include/bits/cow_string.h
+++ b/libstdc++-v3/include/bits/cow_string.h
@@ -911,13 +911,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/// null-termination.
size_type
size() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ {
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_M_rep() == &_S_empty_rep() && _M_rep()->_M_length != 0)
+ __builtin_unreachable();
+#endif
+ return _M_rep()->_M_length;
+ }
/// Returns the number of characters in the string, not including any
/// null-termination.
size_type
length() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ {
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_M_rep() == &_S_empty_rep() && _M_rep()->_M_length != 0)
+ __builtin_unreachable();
+#endif
+ return _M_rep()->_M_length;
+ }
/// Returns the size() of the largest possible %string.
size_type
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e02c9d9116f243643c0daba8dbcc5d1795c827c3
commit r13-6956-ge02c9d9116f243643c0daba8dbcc5d1795c827c3
Author: Jakub Jelinek
Date: Fri Mar 31 13:41:34 2023 +0200
range-op-float, value-range: Fix up handling of UN{LT,LE,GT,GE,EQ}_EXPR and
handle comparisons in get_tree_range [PR91645]
When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR
comparisons incorrectly.
All those are unordered or ..., we correctly return [1, 1] if one or
both operands are known NANs, and correctly ask the non-UN prefixed
op to fold_range if neither operand may be NAN.
But for the case where one or both operands may be NAN, we always
return [0, 1]. The UN* fold_range tries to handle it by asking
the non-UN prefixed fold_range and if it returns [1, 1] return that,
if it returns [0, 0] or [0, 1] return [0, 1], which makes sense,
because the maybe NAN means that it is the non-UN prefixed fold_range
unioned with [1, 1] in case the maybe NAN is actually NAN at runtime.
The problem is that the non-UN prefixed fold_range always returns [0, 1]
because those fold_range implementations are like:
if (op1.known_isnan () || op2.known_isnan ())
r = range_false (type);
else if (!maybe_isnan (op1, op2))
{
...
}
else
r = range_true_and_false (type);
and so if maybe_isnan, they always return [0, 1]. Now, thinking about it,
this is unnecessary pessimization, for the case where the ... block
returns range_false (type) we actually could do it also if maybe_isnan
(op1,
op2), because if one or both operands are NAN, the comparison will be
false,
and if neither is NAN, the comparison will be also false. Will fix
incrementally today.
Anyway, the following patch fixes it by asking the non-UN prefixed
fold_range on ranges with NAN cleared, which I think does the right
thing in all cases.
Another change in the patch is that range_query::get_tree_range
always returned VARYING for comparisons, this patch allows to ask about
those as well (they are very much like binary ops, except they take
the important type from the types of the operands rather than result).
Initially I've developed this patch together with changes to
tree-call-cdce.cc,
but those result in one regression and apparently aren't actually needed to
fix this bug, the range-op-float.cc changes are enough.
2023-03-31 Jakub Jelinek
PR tree-optimization/91645
* range-op-float.cc (foperator_unordered_lt::fold_range,
foperator_unordered_le::fold_range,
foperator_unordered_gt::fold_range,
foperator_unordered_ge::fold_range,
foperator_unordered_equal::fold_range): Call the ordered
fold_range on ranges with cleared NaNs.
* value-query.cc (range_query::get_tree_range): Handle also
COMPARISON_CLASS_P trees.
* gcc.target/i386/pr103559-1.c: New test.
* gcc.target/i386/pr103559-2.c: New test.
* gcc.target/i386/pr103559-3.c: New test.
* gcc.target/i386/pr103559-4.c: New test.
[Bug middle-end/61294] [4.9 Regression] erroneous memset used with constant zero length parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294 Andrew Pinski changed: What|Removed |Added CC||martin at v dot loewis.de --- Comment #16 from Andrew Pinski --- *** Bug 16794 has been marked as a duplicate of this bug. ***
[Bug c/16794] should warn about switched memset arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16794 Andrew Pinski changed: What|Removed |Added Resolution|WONTFIX |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 61294 *** This bug has been marked as a duplicate of bug 61294 ***
[Bug c/15450] Ability to turn selected warnings into errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15450 --- Comment #3 from Andrew Pinski --- Note for long long, you can use -Wno-long-long which is documented here: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wlong-long Been around since 3.1: https://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Warning-Options.html#Warning%20Options -Wlong-long Warn if long long type is used. This is default. To inhibit the warning messages, use -Wno-long-long. Flags -Wlong-long and -Wno-long-long are taken into account only when -pedantic flag is used.
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
Richard Biener changed:
What|Removed |Added
Summary|[13 Regression] |[12/13 Regression]
|bits/stl_algobase.h:431:|bits/stl_algobase.h:431:
|warning: 'void* |warning: 'void*
|__builtin_memcpy(void*, |__builtin_memcpy(void*,
|const void*, unsigned int)' |const void*, unsigned int)'
|reading between 8 and |reading between 8 and
|2147483644 bytes from a |2147483644 bytes from a
|region of size 4|region of size 4
|[-Wstringop-overread] |[-Wstringop-overread]
Status|RESOLVED|REOPENED
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Resolution|FIXED |---
Target Milestone|13.0|12.3
--- Comment #8 from Richard Biener ---
Only comment#1 is fixed, the original testcase is 22_locale/money_get/cons/3.cc
which still fails with the settings from comment#7
We have
[local count: 268328082]:
_187 = MEM[(struct _Rep *)&_S_empty_rep_storage].D.58774._M_length;
_189 = MIN_EXPR <_170, _187>;
if (_189 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 134164041]:
if (_189 == 1)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 45615775]:
MEM[(struct char_type *)_172] = MEM[(const struct character
&)&_S_empty_rep_storage + 12];
goto ; [100.00%]
[local count: 88548267]:
_173 = _189 * 4;
__builtin_memcpy (_172, [(void *)&_S_empty_rep_storage +
12B], _173); // <--- diagnosed
[local count: 268328083]:
__negative_sign ={v} {CLOBBER};
so we know that _173 is [2, +INF] * 4 and that's enough to diagnose the
call as we seem to have an idea about the source size (the embedded
string length).
There's an intervening operator new preventing CSE of the length of the
destination and while there's a condition of != &_S_empty_rep_storage
control flow converges again before this, so it seems we handle both
here.
It's incredibly branchy code :/
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 107087, which changed state. Bug 107087 Summary: [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of size 4 [-Wstringop-overread] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #7 from Jonathan Wakely --- OK I suppose we can change the library to avoid passing a reference there.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #3 from Jonathan Wakely --- We could add server rules to insert a banner into the HTML on every page, but it's not trivial. You might be thinking of PR 65699.
[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318 --- Comment #9 from Martin Jambor --- Most likely a duplicate of PR 107769.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6 from Richard Biener ---
OK, I suppose I was misled by trying to trace how the construction works. The
first half of my comment#2 still stands - we diagnose
ss ={v} {CLOBBER};
std::stop_token::_Stop_state_ref::_Stop_state_ref (_M_state, );
by (maybe broken) design, the argument is a const reference which
we decide implies read. In this case we could even use modref to
see the parameter is unused - but the call happens through an alias
and in the -Og pipeline we do not run late modref.
The called body is
void std::stop_token::_Stop_state_ref::_Stop_state_ref (struct _Stop_state_ref
* const this, const struct stop_source & D.79270)
{
void * _5;
[local count: 1073741824]:
_5 = operator new (24);
MEM[(struct _Stop_state_t *)_5]._M_owners.D.16955._M_i = 0;
MEM[(struct _Stop_state_t *)_5]._M_value.D.16955._M_i = 0;
MEM[(struct _Stop_state_t *)_5]._M_head = 0B;
MEM[(struct _Stop_state_t *)_5]._M_requester._M_thread = 0;
MEM[(struct __atomic_base *)_5]._M_i = 1;
MEM[(struct __atomic_base *)_5 + 4B]._M_i = 4;
MEM[(struct id *)_5 + 16B]._M_thread = 0;
this_2(D)->_M_ptr = _5;
return;
}
but since this function can be interposed even modref doesn't help (when
scheduled and enabled) since it throws away this knowledge :/ Maybe
we need some optimistic mode for diagnostic code (or add
EAF_LIKELY_UNUSED).
But as said (late) modref isn't in the -Og pipeline and it's only enabled
with -O2+ anyway.
The other possible heuristic adjustment would be noticing is also
passed as first non-const reference argument.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #2 from Andrew Pinski --- Oh and the manual is not exactly out of date for that version of gcc. So the text you have would be wrong.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #1 from Andrew Pinski --- There is another bug about adding a version to the manual pages. Thar would be better. Touching old generated html files is not a good solution. Plus the version is in the url.
[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769 --- Comment #6 from Martin Jambor --- Yes, you identified the correct commit. The same jump function is double counted (once during iPA-CP and then again during inlining) when we drop references and so an address reference is replaced with a read one. I will make this bug a priority next week.
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- I believe attempting to doing so would result exponential time complexity.
[Bug fortran/109358] New: Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Bug ID: 109358 Summary: Wrong formatting with T-descriptor during stream output Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- This is a very minor bug, but probably easy to fix. It seems, that the T data edit descriptor handling is non-standard conforming when using formatted stream I/O: Given the following MWE: program tabformat implicit none integer :: fd open(newunit=fd, file="test.stream.txt", access="stream", form="formatted") write(fd, "(a)") "1234567890123" write(fd, "(a, t10, a)") "1234", "0123" ! A-descriptor, file positioning allowed write(fd, "(i4, t10, i4.4)") 1234, 0123 ! I-descriptor, file positioning not allowed close(fd) end program tabformat The resulting file contains 1234567890123 1234 0123 # 9 spaces between blocks 1234 0123 # 9 spaces between blocks Apparently, a file positioning takes place during the execution of the write statement. However, if I understand 13.7.1 §1 correctly, file positioning may only happen with the A-descriptor (and it is optional even there). So the standard conforming output would be either (if file positioning happens after the A-descriptor) 1234567890123 1234 0123# 9 spaces 1234 0123# 5 spaces or (if no file positioning happens after the A-descriptor) 1234567890123 1234 0123# 5 spaces 1234 0123# 5 spaces I personally would prefer latter, and it would be also equivalent to the behavior of the Intel and NAG compilers.
[Bug c++/109357] New: GCC 13.0.1: internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357
Bug ID: 109357
Summary: GCC 13.0.1: internal compiler error in
cp/constexpr.cc:1685
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kgledits at cisco dot com
Target Milestone: ---
Created attachment 54797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54797=edit
C++ file triggering internal compiler error
See also https://godbolt.org/z/obn7vvjje . Using the attached CPP file:
$ g++ --version
g++ (GCC) 13.0.1 20230318 (Red Hat 13.0.1-0)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -std=c++20 -O2 -o - input-reduced.cpp
input-reduced.cpp: In destructor ‘s2::~s2()’:
input-reduced.cpp:15:19: warning: ISO C++ forbids converting a string constant
to ‘char*’ [-Wwrite-strings]
15 | s2::~s2() { s1 = {"", ""}; }
| ^~
input-reduced.cpp:15:23: warning: ISO C++ forbids converting a string constant
to ‘char*’ [-Wwrite-strings]
15 | s2::~s2() { s1 = {"", ""}; }
| ^~
input-reduced.cpp: In destructor ‘s2::~s2()’:
input-reduced.cpp:15:28: internal compiler error: in adjust_temp_type, at
cp/constexpr.cc:1685
15 | s2::~s2() { s1 = {"", ""}; }
|^
Please submit a full bug report, with preprocessed source.
See for instructions.
Preprocessed source stored into /tmp/ccN3KzRp.out file, please attach this to
your bugreport.
[Bug sanitizer/107048] GCC lacks -fsanitize=kcfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048 Xi Ruoyao changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW CC||xry111 at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-03-31
[Bug sanitizer/107374] Please expand the size of flag_sanitize to uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- Invalid then.
