Closed rwbc closed 2 months ago
TerjeKir
commented
1 year ago Hey, thanks for the report. The error message doesn't make sense to me, and it seems to not happen with GCC 13.2 on another machine, so I'm guessing a GCC issue for now - when msys releases 13.2 can you let me know if you still get this?
skiminki
commented
1 year ago @rwbc I got a clean build with GCC 13.2 (-flto enabled), although that was on Linux.
I see at least one potentially related bug fix in GCC ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 ), so this could be a problem in GCC 13.1.
The error message would hint at either compiler internals (anonymous variable access) or setjmp() internals. If this was a Weiss issue, then by default I'd expect something more specific than '\<anonymous>'. Also, I don't quite see what would be wrong with Weiss to trigger this.
skiminki
commented
1 year ago Actually, not quite sure what's this about. I tried gcc 13.1 (via https://hub.docker.com/_/gcc) and Weiss still compiles and benches fine for me. Perhaps this is an msys2-related issue.
root@ea2540b3bbc7:/weiss/src# gcc --version
gcc (GCC) 13.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.
root@ea2540b3bbc7:/weiss/src# make pgo
gcc -std=gnu11 -Wall -Wextra -Wshadow -Werror -Wmissing-declarations -O3 -flto -march=native -DUSE_PEXT -DNDEBUG *.c pyrrhic/tbprobe.c tuner/*.c query/*.c noobprobe/*.c onlinesyzygy/*.c -pthread -lm -o weiss -fprofile-generate="pgo"
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
lto-wrapper: note: see the '-flto' option documentation for more information
./weiss bench 12 > /dev/null 2>&1
gcc -std=gnu11 -Wall -Wextra -Wshadow -Werror -Wmissing-declarations -O3 -flto -march=native -DUSE_PEXT -DNDEBUG *.c pyrrhic/tbprobe.c tuner/*.c query/*.c noobprobe/*.c onlinesyzygy/*.c -pthread -lm -o weiss -fprofile-use="pgo"
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
lto-wrapper: note: see the '-flto' option documentation for more information
root@ea2540b3bbc7:/weiss/src# ./weiss bench | tail -n 1
OVERALL: 4373 ms 22069011 nodes 5046652 npsThanks for taking the time to look into it @skiminki, much appreciated 👍
rwbc
commented
1 year ago Hey, thanks for the report. The error message doesn't make sense to me, and it seems to not happen with GCC 13.2 on another machine, so I'm guessing a GCC issue for now - when msys releases 13.2 can you let me know if you still get this?
I am doing an upgrade right now and try again later.
rwbc
commented
1 year ago There is the same gcc error complaining with 13.2 here.
Out of curiosity I tried to recompile rev 602, which didn't show this error when compiled in March 7 and it now also shows this error with 13.2 (and also the unsignedness error of #677, which I applied the fix for). Originally I compiled rev with GCC 11.2 at that time.
So it seems it is some additional nit-picking in GCC 13.x and may be the one remaining for me just for Win?
TerjeKir
commented
1 year ago Seems that way, yeah. For now I'll recommend just removing -Werror so it compiles despite the warning.
skiminki
commented
1 year ago So it seems it is some additional nit-picking in GCC 13.x and may be the one remaining for me just for Win?
Yes, so I'm suspecting that there is some bad interaction between the mingw implementation of setjmp() and GCC 13 with flto. The declarations are here:
The unusual things about mingw setmp() are:
returns_twice attribute ( https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html ). The documentation says that this instructs the compiler to ensure that all registers are dead before calling such function, i.e., the registers would be saved/restored when calling such functions.__builtin_frame_address (0). This probably reads the frame pointer or stack pointer register.I think it is a plausible guess that the unusual things (one or the other or a combination) could trigger the spurious warning about using an anonymous object without initialization. This looks to be a bug in mingw (part of msys2) and/or GCC 13, and my suspicion is that it's the latter, since it's triggered only by flto.
The flto optimization does extra passes related to internal representation of sources (GIMPLE stuff). It is possible that there is an oversight related to the aforementioned attributes. In general, returns_twice is basically only ever used by fork()/setjmp() functions and their variants. This combination of attributes and built-ins looks to be mingw-specific.
skiminki
commented
1 year ago Ok, I was able to repro this on Linux with some hacks. It's the returns_twice attribute in combination with __builtin_frame_address(0) that triggers this issue for external functions. I'll investigate this a bit more.
skiminki
commented
1 year ago I figured out a minimal repro:
int threadIndex = 1;
int __attribute__ ((__returns_twice__)) _setjmpex(void *context);
int main(int argc, char **argv)
{
int mainThread = threadIndex;
while (!mainThread) {
_setjmpex(__builtin_frame_address (0));
if (threadIndex) break;
}
return 0;
}Compile this with: gcc-13.2 -c -O2 -Wuninitialized -Werror and you'll see the error.
Checking with godbolt, this seems to be a regression in gcc-12. Reference: https://godbolt.org/z/Mv5b5rc75
I'll double-check the GCC bug database and file an issue later.
TerjeKir
commented
1 year ago Very cool! Hope to see it fixed before long :)
skiminki
commented
1 year ago The GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397
This seems to be fixed on GCC trunk as a side effect of something else, so I'd guess GCC 14 won't be affected.
skiminki
commented
1 year ago Well, that was fast. The GCC issue is already fixed in GCC trunk (was an issue there after all but the warning print was missing, I guess). Backport to GCC 13.x to follow.
As a result, piece of distilled Weiss gets to live in GCC as a test case to protect against future regressions: https://gcc.gnu.org/g:92ea12ea99fce546772a40b7bbc2ea850db9b1be :)
I'd suggest keeping this issue open until we can verify the fix with msys2/mingw. That said, no strong opinions about this.
TerjeKir
commented
1 year ago Fast indeed! Cool stuff, I'll leave this open as you suggested :)
TerjeKir
commented
5 months ago Made the mistake of updating my msys gcc and was stuck with this issue for about half a year. msys finally updated to 14.1 so now it works again lol
This error might be related to another new check in GCC, as referred in: https://github.com/TerjeKir/weiss/issues/677
The error disappears when removing the -flto flag.
output from cmd (old quadcore Q8200)