Ok, now I have figured out where is the problem. Antonin, your callback was always called. The problem is with the initialization of that static global variable from callback which by /GL was done _after_ calling the callback.
CRT stdout stream is not available during the execution of initial TLS callbacks but it is possible to use CreateProcess (or WinExec for simplicity) and call "cmd /c echo ..." to print something to stdout. And this prints during both DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. I removed the "extern const PIMAGE_TLS_CALLBACK __xl_f;" and there was no change, the callback was still called. So the "extern const PIMAGE_TLS_CALLBACK __xl_f;" line is really unnecessary as I originally thought. If I mark the variable with "volatile" keyword then it looks like that /GL initialize it before TLS callback and hence it finally make also that variable to correctly working. Full example here: https://godbolt.org/z/dPW8Tr4hW So for future, I would propose to mark all global variables accessed from TLS callback as volatile. I do not know if it is the correct solution but at least for above case it helps. On Tuesday 23 September 2025 15:58:28 Pali Rohár wrote: > Now I played a bit with it based on your example from bug report and > adding "extern const PIMAGE_TLS_CALLBACK __xl_f;" is NOT fixing the > problem when the /O2 /GL flags are used. > > Here is the link to godbolt where anybody can play with it and verify > what is working what not: https://godbolt.org/z/z4sreEcY4 > > So based on above testing, I think that the additional declaration with > extern keyword is unnecessary and does not fix the main issue when /GL > together with /O2 is enabled. > > I do not know how to fix it. > > On Tuesday 23 September 2025 14:38:37 Pali Rohár wrote: > > That it really interesting. At least it proves that I was wrong about > > /include: assumption. > > > > So if I understand correctly, if you add following line to your example > > then it start working, right? "extern const PIMAGE_TLS_CALLBACK __xl_f;" > > > > In this case the extern is there needed for msvc and I would suggest to > > add a comment into mingw-w64 why additional extern declaration (which > > seems unnecessary from C point of view) is required. > > > > On Tuesday 23 September 2025 14:10:31 Antonin Décimo wrote: > > > I experimented with MSVC and LTO two years ago, and had problems > > > applying them to winpthreads. I may not have been very rigorous, and > > > to get certainty the whole process would need to be re-tested. I did > > > report a bug, but it was deemed invalid. > > > https://developercommunity.visualstudio.com/t/Whole-program-optimization-and-optimized/10531811 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
