On Mon, 17 Apr 2023, sisyphus wrote:
My question therefore is:
If the 32-bit 12.2.0 version of setjmp.h works fine with 32-bit gcc-13.0.1,
then why was it altered ?
Maybe that's a dumb question - hopefully not sufficiently dumb as to cause
offence.
We made a change to simplify code, in a place which is quite complex and
messy. We believed this change wouldn't have any effect, since nothing
within mingw-w64 defines USE_NO_MINGW_SETJMP_TWO_ARGS and we didn't
believe that any user code would define it either.
As regards the building of 32-bit threaded perl, the main stumbling block
seemed to be that setjmp.h in gcc-13.0.1 no longer checks to see
if USE_NO_MINGW_SETJMP_TWO_ARGS is not defined.
AIUI, the omission of that check for the 64-bit version of setjmp.h is
quite ok - as USE_NO_MINGW_SETJMP_TWO_ARGS is only ever defined for 32-bit
builds.
mingw-w64 never defined USE_NO_MINGW_SETJMP_TWO_ARGS. Do the perl sources
define it?
If they do, we wonder why, and would ideally want to see a reproducible
example of code where the default setting of not defining this macro
breaks things.
On a lower level, since commit 82347ded0d43a80de68b6a35a209717bded5f28a in
2009, mingw-w64's setjmp.h has been using _setjmp3 for i386, while setting
the USE_NO_MINGW_SETJMP_TWO_ARGS define makes it revert to using _setjmp.
We weren't aware of any issues with using _setjmp3 (and if there are,
maybe we should revisit that change from 2909?) - ideally user code
shouldn't need to know or care about this - the defaults are supposed to
work.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
