[Bug c++/106873] unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873 --- Comment #6 from Kemal Akcam --- (In reply to Jonathan Wakely from comment #5) > Read https://en.cppreference.com/w/c/language/object#Alignment (for C) and > https://en.cppreference.com/w/cpp/language/object#Alignment (for C++). > > Instead of filing bugs like this and PR 106869, please find somewhere more > suitable to learn how C++ works. Both your "bugs" would be appropriate as > questions on StackOverflow (in fact they have probably already been answered > there, and you could find the answers by searching). "I find GCC's behaviour > surprising" is not a bug. I like writing a piece of code to analyse software behaviour and sometimes it is not the software that I'm analysing. I thank both of you giving quick insight with your responses. I still like GCC thou. Best regards.
[Bug tree-optimization/106904] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 --- Comment #3 from Zebediah Figura --- >From the warning, it seems like it thinks I wrote memcpy(&ps->wp.hwnd, &wp, sizeof(wp)); but that's not what I wrote.
[Bug tree-optimization/106904] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 --- Comment #2 from Zebediah Figura --- (In reply to Andrew Pinski from comment #1) > The warning is correct for the reduced testcase as we warning that you are > copying the wrong size for the field The field "&ps->wp" is of size 16 (4 ints), whereas the source "wp" is of size 8 (2 ints). Or did I make a mistake somewhere?
[Bug tree-optimization/106904] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 --- Comment #1 from Andrew Pinski --- The warning is correct for the reduced testcase as we warning that you are copying the wrong size for the field Now I have not looked at the non reduced testcase.
[Bug c/106904] New: Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 Bug ID: 106904 Summary: Incorrect -Wstringop-overflow with partial memcpy() into a nested structure Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zfigura at codeweavers dot com Target Milestone: --- Created attachment 53562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53562&action=edit minimal test case I encountered a warning while trying to compile 32-bit wine 7.17 with gcc 12.2, specificially at this line here: https://source.winehq.org/git/wine.git/blob/wine-7.17:/dlls/win32u/message.c#l359 The relevant code copies a smaller structure into a larger one of a different type. (This may be a violation of aliasing rules, but adding -fno-strict-aliasing doesn't change anything.) I was able to reproduce this with a minimal test case. This is a very weird set of conditions, but I couldn't seem to reduce this test case any further. Changing the type of "ps" to "struct packed_windowpos" makes the error go away; so does changing the first argument of the memcpy to "ps". leslie@terabithia:~$ gcc --version gcc (Debian 12.2.0-1) 12.2.0 Copyright (C) 2022 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. leslie@terabithia:~$ gcc -m32 test.c -c -o test.o -Wall -O2 test.c: In function ‘func’: test.c:26:5: warning: writing 8 bytes into a region of size 4 [-Wstringop-overflow=] 26 | __builtin_memcpy(&ps->wp, &wp, sizeof(wp)); | ^~ test.c:9:9: note: destination object ‘hwnd’ of size 4 9 | int hwnd; | ^~~~
[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106845 Tim Lange changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Tim Lange --- (In reply to CVS Commits from comment #5) > The master branch has been updated by Tim Lange : > > https://gcc.gnu.org/g:0ea5e3f4542832b8da016b152695e64a2a386309 > > commit r13-2582-g0ea5e3f4542832b8da016b152695e64a2a386309 Fixed the ICE with the commit above.
[Bug analyzer/106845] [13 Regression] ICE in exceeds_p, at analyzer/store.cc:464 since r13-2029-g7e3b45befdbbf1a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106845 --- Comment #5 from CVS Commits --- The master branch has been updated by Tim Lange : https://gcc.gnu.org/g:0ea5e3f4542832b8da016b152695e64a2a386309 commit r13-2582-g0ea5e3f4542832b8da016b152695e64a2a386309 Author: Tim Lange Date: Sat Sep 10 23:53:48 2022 +0200 analyzer: consider empty ranges and zero byte accesses [PR106845] This patch adds handling of empty ranges in bit_range and byte_range and adds an assertion to member functions that assume a positive size. Further, the patch fixes an ICE caused by an empty byte_range passed to byte_range::exceeds_p. Regression-tested on Linux x86_64. 2022-09-10 Tim Lange gcc/analyzer/ChangeLog: PR analyzer/106845 * region-model.cc (region_model::check_region_bounds): Bail out if 0 bytes were accessed. * store.cc (byte_range::dump_to_pp): Add special case for empty ranges. (byte_range::exceeds_p): Restrict to non-empty ranges. (byte_range::falls_short_of_p): Restrict to non-empty ranges. * store.h (bit_range::empty_p): New function. (bit_range::get_last_byte_offset): Restrict to non-empty ranges. (byte_range::empty_p): New function. (byte_range::get_last_byte_offset): Restrict to non-empty ranges. gcc/testsuite/ChangeLog: PR analyzer/106845 * gcc.dg/analyzer/out-of-bounds-zero.c: New test. * gcc.dg/analyzer/pr106845.c: New test.
[Bug tree-optimization/96367] bogus -Wformat-truncation in ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96367 --- Comment #4 from Zebediah Figura --- Forgot to mention: leslie@terabithia:~/git/wine32$ gcc --version gcc (Debian 12.2.0-1) 12.2.0 Copyright (C) 2022 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.
[Bug tree-optimization/96367] bogus -Wformat-truncation in ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96367
Zebediah Figura changed:
What|Removed |Added
CC||zfigura at codeweavers dot com
--- Comment #3 from Zebediah Figura ---
I believe I'm running into this trying to compile Wine. Specifically, this
snprintf statement:
https://source.winehq.org/git/wine.git/blob/wine-7.17:/dlls/ntdll/unix/system.c#l3176
is yielding this warning:
../wine/dlls/ntdll/unix/system.c: In function ‘NtQuerySystemInformation’:
../wine/dlls/ntdll/unix/system.c:3176:36: error: ‘%s’ directive output between
0 and 2147483644 bytes may cause result to exceed ‘INT_MAX’
[-Werror=format-truncation=]
3176 | snprintf( info, size, "%s%c%s%c%s%c%s", version, 0, wine_build,
0, buf.sysname, 0, buf.release );
|^~ ~~
../wine/dlls/ntdll/unix/system.c:3176:9: note: ‘snprintf’ output between 8 and
2147483780 bytes into a destination of size 4294967295
3176 | snprintf( info, size, "%s%c%s%c%s%c%s", version, 0, wine_build,
0, buf.sysname, 0, buf.release );
|
^~~~
when compiled as 32-bit, using Wine's default flags (so notably -g -O2 -m32
-Wall).
I also tried to reduce it into a simpler test case:
#include
#include
extern const char text[];
size_t func(char *buffer, size_t size)
{
size_t len = strlen(text);
snprintf(buffer, size, "text%s", text);
return len;
}
which fails similarly with "gcc -m32 -O2 -Wall".
Is there a way we can even work around this in Wine? I don't see an obvious
one, especially with no clue why the bug is even happening.
[Bug fortran/106750] Memory leak calling array slice of derived type containing `allocatable` entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- Regarding the other "leak" from the original test: (In reply to federico from comment #0) > > program test (...) >type(t), allocatable :: ts(:) (...) >! [leak #2] happens if ts is not deallocated. Shouldn't a program work > like a >! subroutine, and deallocate everything that's going out of scope? >deallocate(ts) > > end program test > Not automatically deallocating is the correct behavior here, I think: > A variable, (...) declared in the scoping unit of a main program, module, or > submodule implicitly has the SAVE attribute => TS has the save attribute. > The SAVE attribute specifies that a local variable of a program unit or > subprogram retains its association status, allocation status, definition > status, and value after execution of a RETURN or END statement (...). => TS is not deallocated at the end of the program > When the execution of a procedure is terminated by execution of a RETURN or > END statement, an unsaved allocatable local variable of the procedure retains > its allocation and definition status if it is a function result or a > subobject thereof; otherwise, if it is allocated it will be deallocated. => this doesn’t apply as TS has the save attribute.
[Bug c++/106903] New: Incorrectly accepts call to function template when deduced type doesn't match adjusted type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106903
Bug ID: 106903
Summary: Incorrectly accepts call to function template when
deduced type doesn't match adjusted type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/T1vPGYash
template
struct Array {
template
operator Array() const;
};
template
void foo(Array x,
Array y);
int main()
{
foo(Array(), Array());
}
My understanding is that template type deduction on the call to `foo` should
fail, because even though we can unambiguously deduce [T=int, U=char], and even
though the actual argument's type Array is CONVERTIBLE to the formal
parameter's type Array, it's not actually the same type. My
understanding is that a parameter that contributes to deduction must have the
same type as its corresponding function argument.
MSVC correctly rejects with this confusing message-spew:
(13): error C2664: 'void foo(Array,Array)':
cannot convert argument 2 from 'Array' to 'Array'
(13): note: Binding to reference
(13): note: followed by
(13): note: Call to user-defined-conversion 'Array::operator
Array(void) const<4>'
(4): note: see declaration of 'Array::operator Array'
(13): note: followed by
(13): note: Exactly the same type
(8): note: see declaration of 'foo'
Clang correctly rejects with this message:
:13:5: error: no matching function for call to 'foo'
foo(Array(), Array());
^~~
:8:6: note: candidate template ignored: deduced type 'Array<[...],
sizeof(int) aka 4>' of 2nd parameter does not match adjusted type 'Array<[...],
6>' of argument [with T = int, U = char]
void foo(Array x,
^
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Brendan Dolan-Gavitt changed:
What|Removed |Added
CC||brendandg at nyu dot edu
--- Comment #19 from Brendan Dolan-Gavitt ---
I read through the crtfastmath.c implementations for the other affected targets
and confirmed that they do all set flush-to-zero in this thread:
https://threadreaderapp.com/thread/1567612053363347461.html
I agree that there should be a way for a shared library to link crtfastmath.o
if it wants that behavior. But is there a reason -l:crtfastmath.o isn't
sufficient in that case? Why does it need to be enabled automatically when
-Ofast/-ffast-math/-funsafe-math optimizations are turned on?
The other note I would add is that in multi-threaded applications,
crtfastmath.o is already not behaving as intended: FTZ/DAZ will only be set in
the CPU state of the thread that loaded the shared library; it's hard to
imagine a case where a user wants individual threads to have different FTZ/DAZ
(unless they explicitly manage that by hand). Example:
$ cat baz.c
#include
#include
#include
#include
void loadlib() {
void *handle = dlopen("./gofast.so", RTLD_LAZY);
if (!handle) {
fprintf(stderr, "dlopen: %s\n", dlerror());
}
}
#define MXCSR_DAZ (1 << 6) /* Enable denormals are zero mode */
#define MXCSR_FTZ (1 << 15) /* Enable flush to zero mode */
void printftz(int i) {
unsigned int mxcsr = __builtin_ia32_stmxcsr ();
printf("[%d] mxcsr.FTZ = %d, mxcsr.DAZ = %d\n", i, !!(mxcsr & MXCSR_FTZ),
!!(mxcsr & MXCSR_DAZ));
return;
}
void *thread(void *arg) {
// Print thread id
int i = *(int *)arg;
if (i == 0) loadlib();
sleep(1);
printftz(i);
}
int main(int argc, char **argv) {
// Create 4 threads
pthread_t threads[4];
int tids[4];
for (int i = 0; i < 4; i++) {
tids[i] = i;
pthread_create(&threads[i], NULL, thread, &tids[i]);
}
// Wait for all threads to finish
for (int i = 0; i < 4; i++) {
pthread_join(threads[i], NULL);
}
return 0;
}
$ touch gofast.c
$ gcc -Ofast -fpic -shared gofast.c -o gofast.so
$ gcc -pthread baz.c -o baz -ldl
$ ./baz
[3] mxcsr.FTZ = 0, mxcsr.DAZ = 0
[0] mxcsr.FTZ = 1, mxcsr.DAZ = 1
[2] mxcsr.FTZ = 0, mxcsr.DAZ = 0
[1] mxcsr.FTZ = 0, mxcsr.DAZ = 0
[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 Triffid Hunter changed: What|Removed |Added CC||triffid.hunter at gmail dot com --- Comment #5 from Triffid Hunter --- Created attachment 53561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53561&action=edit patch based on comment 1 I ran into this issue yesterday (with gcc-13.0.0-20220904). I made the attached patch based on Comment 1, and it does seem to solve the issue. I had some odd lto-related crashes afterwards, but wasn't able to reproduce them after a clean rebuild of my project - so I suspect there was some odd interaction with stale/cached object files. lto crash backtrace in case it's relevant: avr-gcc -Wall -Wextra -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections -mmcu=atmega2560 -fno-stack-protector -o /tmp/arduino_build_820599/sketch_sep10a.ino.elf /tmp/arduino_build_820599/sketch/sketch_sep10a.ino.cpp.o /tmp/arduino_build_820599/libraries/SD/File.cpp.o /tmp/arduino_build_820599/libraries/SD/SD.cpp.o /tmp/arduino_build_820599/libraries/SD/utility/Sd2Card.cpp.o /tmp/arduino_build_820599/libraries/SD/utility/SdFile.cpp.o /tmp/arduino_build_820599/libraries/SD/utility/SdVolume.cpp.o /tmp/arduino_build_820599/libraries/SPI/SPI.cpp.o /tmp/arduino_build_820599/../arduino_cache_495395/core/core_arduino_avr_mega_cpu_atmega2560_0535ac2d4e0500949a67f524c7f20d71.a -L/tmp/arduino_build_820599 -lm lto1: internal compiler error: Segmentation fault 0x135b2a8 internal_error(char const*, ...) ???:0 0x675125 bp_unpack_string(data_in*, bitpack_d*) ???:0 0x986c9e cl_optimization_stream_in(data_in*, bitpack_d*, cl_optimization*) ???:0 0xc3bf60 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) ???:0 0x904fad lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) ???:0 0x9053d7 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned int*, bool) ???:0 0x5e9fc8 read_cgraph_and_symbols(unsigned int, char const**) ???:0 0x5d7222 lto_main() ???:0 Note: stopped happening after clean project rebuild, but ideally it should throw a proper error rather than a segfault?
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #5 from Carlos Galvez ---
I also would like to understand why the warning is not triggered if the first
"if (size < expected_size)" is removed.
https://godbolt.org/z/7vqPxhsqo
The possibility of executing the loop and do out-of-bounds still exists, right?
So why is the compiler warning in one case and not other?
Similarly, a regular for-loop with "size" known at runtime is equally risky,
yet the compiler is not flagging it:
bool bar(std::array const& vec,
std::size_t const size)
{
for (std::size_t i{0}; i < size; ++i)
{
if (vec[i] != 0)
{
return false;
}
}
return true;
}
https://godbolt.org/z/6c64MEY7d
Personally, I think this warning should only warn about 100% confirmed OOB
cases, and put the "maybe" cases in a separate flag. All respectable projects
have as minimum "-Wall -Werror" in their compiler flags, to detect problems
that do exist, not that "might" exist. This can lead to quite a few false
positives, leading to people either disabling the warning altogether (which is
pretty bad!) or polluting the code with inline pragmas (disallowed by some
coding guidelines).
