[Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 --- Comment #13 from Zeb Figura --- (In reply to Sam James from comment #11) > (In reply to Jens-Hanno Schwalm from comment #10) > > Hi, i think we found a very-similar issue in darktable code, you might look > > at > > > > https://github.com/darktable-org/darktable/pull/15742 > > > > If you're hitting this on another target than i686-w64-mingw32, please file > a new bug. We can always mark it as a dupe if it turns out to be, although I > suspect it isn't here. FWIW, I think the relevant part of i686-w64-ming32 is actually just STACK_REALIGN_DEFAULT. I can reproduce the same lack of alignment with "-mstackrealign -mavx512 -O2" with i386-linux-gnu, whereas "-mstackrealign -mavx2 -O2" does align the stack. [-O2 is necessary here otherwise gcc will just use vmovdqu and not bother aligning the stack. No idea what the more targeted optimization is.] I'd assume this is a bug with -mstackrealign, but I also don't understand what the intended purpose of -mstackrealign is. How does it differ from -mincoming-stack-boundary=2 or -mpreferred-stack-boundary=2?
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #17 from Zeb Figura --- Actually, for that matter, what is the intended purpose of -mstackrealign? How is it supposed to differ from -mincoming-stack-boundary and -mpreferred-stack-boundary? The documentation is kind of unclear; it "realigns the stack at entry [...] if necessary", which sounds like it could be synonymous with -mincoming-stack-boundary or -mpreferred-stack-boundary. But the mechanism in the code seems to be entirely separate, and it's also broken with -mavx512f (bug 110273). From some quick testing it also seems to be broken with aligned(8), though not aligned(16). That seems to be due to the logic at [1]; not sure if that was intentional but I'll admit it doesn't make much sense to me. But I also don't see why this mechanism is used instead of whatever mechanism is used for -mincoming-stack-boundary. [1] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386.cc;h=9390f525b99f0c078c912876aee8498bc3e7701b;hb=HEAD#l7768
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #15 from Zeb Figura --- (In reply to Eric Botcazou from comment #14) > > I'd say that > > > > config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE > > > > is a non-working "fix". The appropriate default would be > > -mincoming-stack-boundary=2. MIN_STACK_BOUNDARY should already be 4, so > > that leaves PREFERRED_STACK_BOUNDARY_DEFAULT is the way to go here. > > This was a minimal fix to support SSE, but Solaris was indeed more radical: > > sol2.h:#undef STACK_REALIGN_DEFAULT > sol2.h:#define STACK_REALIGN_DEFAULT (TARGET_64BIT ? 0 : 1) > > so we could just mimic it for Windows. Why use STACK_REALIGN_DEFAULT rather than PREFERRED_STACK_BOUNDARY_DEFAULT?
[Bug target/111722] manually defined memcpy() and memmove() incorrectly handle overlap with -O2 -m32 -march=bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722 --- Comment #5 from Zeb Figura --- (In reply to Andrew Pinski from comment #4) > There is no bug here. > ICF finds that your definition of memcpy is the same as memmove and merges > the 2 and then calls memcpy from your memmove and then inlines the normal > memcpy because well it says it is the same. I suppose I understand this explanation, but it does not feel like a very intuitive behaviour. The ICF part makes sense. The choice to optimize a builtin memcpy/memmove call into a different instruction sequence (which doesn't match the original) also makes sense. I would not really expect these two to be combined in this manner, though. memmove() is not calling builtin memcpy(), it is calling our implementation of memcpy(), which doesn't have the same semantics as builtin memcpy(). [It also seems odd to me that func2() would be replaced with a builtin memcpy() rather than a builtin memmove()?] > You can just use -fno-builtin to fix the issue by saying memcpy and memmove > are not builtins and treat them like normal functions. > > That fixes the issue by not inlining the target defined memcpy. Fair enough, I guess. I suppose that's the right thing to do anyway...
[Bug target/111722] manually defined memcpy() and memmove() incorrectly handle overlap with -O2 -m32 -march=bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722 --- Comment #3 from Zeb Figura --- Created attachment 56072 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56072=edit testcase Attaching a reduced-ish testcase, that contains the unmodified code of memcpy() and memmove(), plus two callers. The callers seem to be necessary to trigger the incorrect optimization. Compile with '-c -O2 -march=bdver2 -m32'.
[Bug target/111722] manually defined memcpy() and memmove() incorrectly handle overlap with -O2 -m32 -march=bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722 Zeb Figura changed: What|Removed |Added Version|unknown |13.2.0 Keywords||wrong-code Target||i686-linux-gnu Component|c |target Summary|gcc generates wrong code|manually defined memcpy() |with|and memmove() incorrectly ||handle overlap with -O2 ||-m32 -march=bdver2 --- Comment #2 from Zeb Figura --- Really sorry about that, I managed to accidentally hit the Enter key halfway through writing the title. Here is the actual bug description: -- Wine provides freestanding libraries, including manual definitions of memcpy() and memmove() [1]. Those are defined in C, and while our definitions are *technically* non-compliant C (violating the requirement that the pointers must point to the same object), they should be fine for our targets, and anyway, the case I'm running into is failure to handle overlap where the pointers *do* in fact point into the same object. I can't find fault with the definitions themselves, although I may be missing something. We also, contrary to standards, give memcpy() the semantics of memmove(), because some Windows programs are buggy and make that assumption. We do this by copy-pasting the definition (I'm not sure why we do this rather than just calling one function from the other, but it is what it is). I recently started compiling with -march=native, and found that gcc was failing to correctly handle overlap in memmove. Further investigation revealed that, somehow, memmove() was being incorrectly optimized to *not* check for overlap, while memcpy() remained in its unoptimized form. I ran into this originally with the i686-w64-mingw32 target, but I've adjusted the target to i686-linux-gnu since it happens there too. It does *not* happen on x86_64. [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/string.c#l98
[Bug c/111722] New: gcc generates wrong code with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722 Bug ID: 111722 Summary: gcc generates wrong code with Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zfigura at codeweavers dot com Target Milestone: ---
[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669 --- Comment #6 from Zeb Figura --- It is my impression that gcc is interested in avoiding false positives for its warnings. This isn't to say that there aren't some number of false positives in existence, but it is my impression that gcc is interested in reducing that number. It is also my impression that -Wnonnull is not *supposed* to emit warnings for cases where, from the compiler's point of view, NULL might be passed, but some high-level invariant prevents this. Compare -Wmaybe-uninitialized, where the documentation clearly specifies otherwise. If both of these impressions are incorrect, this bug report can be closed as WONTFIX. (In reply to Xi Ruoyao from comment #5) > And you can tell the compiler some fact about the semantics of the Windoge > API functions if you really need -Werror=nonnull (though I cannot see any > reason you must use -Werror here): If it makes a difference, please feel free to pretend I said -Wnonnull, rather than -Werror=nonnull. It was merely a debugging aid, meant to help me try to narrow down the conditions causing this error.
[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669 --- Comment #3 from Zeb Figura --- (In reply to Xi Ruoyao from comment #2) > (In reply to Xi Ruoyao from comment #1) > > The warning given for the reduced test case is correct because it does not > > make sense. It should be just rewritten as > > I mean, the code does not make sense. > > And the warning is given exactly because GCC is optimizing the strcpy call > to unreachable. If GetWindowsDirectoryA() was idempotent, and GetSystemDirectory16() had no other users, that might be true, but as it is I don't think so. The pattern both of those functions call is, much like snprintf(), you pass a buffer and a size, and if the size is 0 then they'll return the size that would have been written if there was a large enough buffer. In that case the buffer can be NULL. In trying to reduce the test case down to the minimal possible complexity I obscured that fact, but regardless I don't think the reduced testcase is nonsensical.
[Bug middle-end/111669] New: bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669 Bug ID: 111669 Summary: bogus -Wnonnull in conditionally executed code Product: gcc Version: 13.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zfigura at codeweavers dot com Target Milestone: --- Created attachment 56032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56032=edit reduced testcase, compile with -O2 -Werror=nonnull Sorry about the rather useless title, but I can't really figure out what actually triggers this error. It seems to depend on some arcane combination of optimizations. I was able to reduce this down to a pretty minimal test case, attached here. It may be possible to reduce it further but I couldn't easily find a way. The actual code that triggers this is here [1]. lstrcpyA() and lstrcatA() are trivial wrappers around strcpy/strcat. The NULL comes from get_search_path() at line 192. The offending strcpy/strcat will never be reached if GetWindowsDirectoryA() returns nonzero, which it always should. However, gcc triggers a -Wnonnull warning anyway. Interestingly, the original Wine code only triggers the warning with -march=bdver2 (or other values of -march), but the reduced testcase triggers it with no -march flags. [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/file.c#l639
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #6 from Zebediah Figura --- (In reply to Zebediah Figura from comment #4) > (In reply to Andrew Pinski from comment #3) > > https://inbox.sourceware.org/gcc-patches/5969976.Bvae8NF9fS@polaris/ > > Again, I'm not sure what you're trying to communicate here. I'm aware that > -mstackrealign exists (and its attribute equivalent). We *do* use that in > Wine. Ah, I'm sorry, I think I see what you're trying to say—that it was an intentional choice to add -mstackrealign if -msse2 is used, so it's hard to call this a "bug" per se. (In reply to Richard Biener from comment #5) > I'd say that > > config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE > > is a non-working "fix". The appropriate default would be > -mincoming-stack-boundary=2. MIN_STACK_BOUNDARY should already be 4, so > that leaves PREFERRED_STACK_BOUNDARY_DEFAULT is the way to go here. I also > see > > /* It should be MIN_STACK_BOUNDARY. But we set it to 128 bits for >both 32bit and 64bit, to support codes that need 128 bit stack >alignment for SSE instructions, but can't realign the stack. */ > #define PREFERRED_STACK_BOUNDARY_DEFAULT \ > (TARGET_IAMCU ? MIN_STACK_BOUNDARY : 128) > > which suggests there might be problems with SSE anyway. > > So does the following work? But I would agree with this, yeah. If we're going to manually align for SSE then we should also manually align for types that need to be manually aligned. Which means that we should just have -mincoming-stack-boundary=2 everywhere. In theory that patch works, although I'll have to put together a gcc build to be sure. I do have one question, though... from reading the documentation, I have a hard time understanding the difference, or intended difference, between -mincoming-stack-boundary and -mpreferred-stack-boundary. Could you by chance try to clarify?
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #4 from Zebediah Figura --- (In reply to Andrew Pinski from comment #3) > https://inbox.sourceware.org/gcc-patches/5969976.Bvae8NF9fS@polaris/ Again, I'm not sure what you're trying to communicate here. I'm aware that -mstackrealign exists (and its attribute equivalent). We *do* use that in Wine. Here is, again, what I am trying to communicate: Currently i686-w64-mingw32-gcc effectly assumes 4-byte stack alignment in some places (when -msse2 is used), and 16-byte alignment in others (when __attribute__((aligned)) is used). I am trying to request that it pick one or the other and stick with it. Now, personally, I think that assuming 4-byte stack alignment makes more *sense*. Otherwise *every* API function needs that extra alignment, which is wasteful when comparatively little code actually uses types aligned to 8 or more bytes. (It obviously makes more sense if you can get the whole API to agree on 16-bytes; then you don't have to manually align anything). But if there's a clear consensus that gcc should assume 16 bytes, and that it's Wine's responsibility to set -mstackrealign, or -mincoming-stack-boundary=2, or something, fine, but I'd like GCC to be consistent about that policy. Otherwise it looks like this behaviour is a bug. That's why I reported this as a bug.
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #2 from Zebediah Figura --- (In reply to Andrew Pinski from comment #1) > This on purpose, it is only callbacks (from libc) and main that needs the > realignment here. I don't understand what you mean? It's not just libc and main that needs this. As mentioned, this is *the* 32-bit x86 ABI on Windows. Win32 programs compiled with MSVC don't assume 16-byte alignment (if they do now, they didn't historically, and we do regularly run across programs in Wine that do not keep the stack aligned to 16 bytes). And again, gcc does not, as a blanket statement, assume 16-byte stack alignment for i386. If we think that gcc *should* assume 16-byte stack alignment, then we should also get rid of the existing code in gcc that assumes 4-byte stack alignment. I think this is a bad idea, for the reasons I've been describing, but if that's the decision then let's please at least be consistent and clear about it. I'm sure this is something of a canned response since, as you say, this issue has been reported before (although I couldn't actually find any such reports, just from searching the gcc Bugzilla?). I wouldn't report this as a bug per se if gcc wasn't currently being *inconsistent* about what it assumes the stack alignment is.
[Bug target/111107] New: i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
Bug ID: 07
Summary: i686-w64-mingw32 does not realign stack when
__attribute__((aligned)) or
__attribute__((vector_size)) are used
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Keywords: ABI, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zfigura at codeweavers dot com
Target Milestone: ---
Target: i686-w64-mingw32
Minimal example:
typedef int myint[4] __attribute__((aligned(16)));
extern void g(void *);
void f(void)
{
myint a;
g();
}
The same thing happens if __attribute__((aligned(16))) is applied to the
variable instead of the typedef.
This seems to also prevent __m128 from being aligned correctly (which uses the
"vector_size" attribute rather than "aligned", but I would assume that
"vector_size" implies "aligned").
-mincoming-stack-boundary=2 works as a workaround; so does -mstackrealign.
Neither should be necessary, though.
I've seen some disagreement [1] [2] as to whether the stack alignment for
i686-w64-mingw32 *should* be 16 or 4, but as far as I can tell it really should
be 4. It's explicitly called out in a code comment [3]; it shows up when -msse2
is used [4], and, well, it reflects the actual ABI of programs that exist in
the wild.
We do regularly come across programs in Wine that don't align the stack to a
16-byte boundary before calling win32 functions, and while -mstackrealign and
similar functions exist, they imply that we either waste time and space
unnecessarily aligning *every* function, or we manually align any function that
might use an aligned type, which is in general something that's treated as the
compiler's responsibility.
[1] https://github.com/mingw-w64/mingw-w64/issues/30#issuecomment-1685487779
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273#c5
[3]
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/cygming.h;h=d539f8d0699d69b014e9d3378e78d690ea289f14;hb=HEAD#l34
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273#c6
[Bug target/110260] Multiple applications misbehave at runtime when compiled with -march=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260 --- Comment #11 from Zebediah Figura --- (In reply to Alexander Monakov from comment #10) > Right, those are different issues. Any chance of a standalone testcase > extracted from Wine? If you already see a function where stack realignment > is missing, just give us preprocessed containing source, full gcc command > line, and output of 'gcc -v', as described on https://gcc.gnu.org/bugs/ > > (please open a new bug with that, and mention the new bug # here) I've filed bug 110273 for the Wine misaligned stack problem.
[Bug target/110273] i686-w64-mingw32 with -march=znver4 generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 --- Comment #1 from Zebediah Figura --- Created attachment 55335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55335=edit gcc -v output, from godbolt
[Bug target/110273] New: i686-w64-mingw32 with -march=znver4 generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 Bug ID: 110273 Summary: i686-w64-mingw32 with -march=znver4 generates AVX instructions without stack alignment Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zfigura at codeweavers dot com CC: amonakov at gcc dot gnu.org Target Milestone: --- Created attachment 55334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55334=edit offending source file Found with Wine. I've attached a C file that's a minimal-ish reproducer. I don't currently have a machine with gcc 13.1.0, so I did this using godbolt.org's "MinGW gcc 13.1.0" target, with "-m32". Full compiler flags are "-m32 -march=znver4 -O2". The generated output begins pushl %ebp vpxor %xmm0, %xmm0, %xmm0 movl%esp, %ebp subl$424, %esp vmovdqa %xmm0, 16(%esp) which is broken. Using -march=znver3 instead will generate the same vmovdqa instruction, but align the stack first: pushl %ebp vpxor %xmm0, %xmm0, %xmm0 movl%esp, %ebp andl$-16, %esp subl$416, %esp leal36(%esp), %eax movl$380, 8(%esp) movl$0, 4(%esp) vmovdqa %xmm0, 16(%esp)
[Bug target/110260] Multiple applications misbehave at runtime when compiled with -march=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260 Zebediah Figura changed: What|Removed |Added CC||zfigura at codeweavers dot com --- Comment #9 from Zebediah Figura --- Wine developer here—FWIW, I think these may ultimately be separate issues. The problem we were seeing with Wine is that, on the i386-w64-mingw32 target, the stack alignment is supposed to be assumed to be only 4 (versus 16 on ELF or x86_64 targets), and so any function using SSE/AVX instructions needs to manually align the stack. In the cases where Wine was crashing, gcc was generating vmovdqa instructions without actually aligning the stack first, whereas without the -march=znver4 flag it apparently would align the stack and then generate SSE movdqa.
[Bug tree-optimization/106904] [12 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 --- Comment #8 from Zebediah Figura --- Thanks!
[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(>wp.hwnd, , 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 ">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 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=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(>wp, , sizeof(wp)); | ^~ test.c:9:9: note: destination object ‘hwnd’ of size 4 9 | int hwnd; | ^~~~
[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.
