Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perl can't be built on x64 platform with gcc12.1 #19824

Closed
yjh-styx opened this issue Jun 4, 2022 · 13 comments
Closed

Perl can't be built on x64 platform with gcc12.1 #19824

yjh-styx opened this issue Jun 4, 2022 · 13 comments

Comments

@yjh-styx
Copy link

yjh-styx commented Jun 4, 2022

This is a bug report for perl
generated with the help of perlbug 1.42 running under perl 5.36.0.


[Please describe your issue here]

when build with gcc 12.1 with option -O2 perl crash on start )in perl_create) - gcc use 'movaps' for unaligned memory.
If change -O2 to -Os, perl work.
Also work if describe struct MEMORY_BLOCK_HEADER as aligned(16) see patch below

=============file=================
--- perl-5.36.0/lib/CORE/vmem.h.orig Thu Apr 29 17:35:34 2021
+++ perl-5.36.0/lib/CORE/vmem.h Sat Jun 04 18:20:37 2022
@@ -70,11 +70,18 @@
#ifdef _USE_LINKED_LIST
class VMem;
typedef struct _MemoryBlockHeader* PMEMORY_BLOCK_HEADER;
+#ifdef _MSC_VER
+__declspec(align(16))
+#endif
typedef struct _MemoryBlockHeader {
PMEMORY_BLOCK_HEADER pNext;
PMEMORY_BLOCK_HEADER pPrev;
VMem *owner;
-} MEMORY_BLOCK_HEADER, *PMEMORY_BLOCK_HEADER;
+}
+#ifdef GNUC
+attribute((aligned(16)))
+#endif
+MEMORY_BLOCK_HEADER, *PMEMORY_BLOCK_HEADER;
#endif

class VMem
--- perl-5.36.0/win32/vmem.h.orig Thu Apr 29 17:35:34 2021
+++ perl-5.36.0/win32/vmem.h Sat Jun 04 18:19:25 2022
@@ -70,11 +70,18 @@
#ifdef _USE_LINKED_LIST
class VMem;
typedef struct _MemoryBlockHeader* PMEMORY_BLOCK_HEADER;
+#ifdef _MSC_VER
+__declspec(align(16))
+#endif
typedef struct _MemoryBlockHeader {
PMEMORY_BLOCK_HEADER pNext;
PMEMORY_BLOCK_HEADER pPrev;
VMem *owner;
-} MEMORY_BLOCK_HEADER, *PMEMORY_BLOCK_HEADER;
+}
+#ifdef GNUC
+attribute((aligned(16)))
+#endif
+MEMORY_BLOCK_HEADER, *PMEMORY_BLOCK_HEADER;
#endif

class VMem
==============eof================

[Please do not change anything below this line]


Flags:
category=core
severity=high

Site configuration information for perl 5.36.0:

Configured by yjh at Sat Jun 4 18:42:25 2022.

Summary of my perl5 (revision 5 version 36 subversion 0) configuration:

Platform:
osname=MSWin32
osvers=10.0.19044.1741
archname=MSWin32-x64-multi-thread
uname=''
config_args='undef'
hint=recommended
useposix=true
d_sigaction=undef
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=undef
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
Compiler:
cc='gcc'
ccflags =' -DWIN32 -DWIN64 -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -mms-bitfields'
optimize='-Os'
cppflags='-DWIN32'
ccversion=''
gccversion='12.1.0'
gccosandvers=''
intsize=4
longsize=4
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='long long'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='g++'
ldflags ='-s -L"C:\Perl64\lib\CORE" -L"E:\mingw64\lib" -L"E:\mingw64\x86_64-w64-mingw32\lib" -L"E:\mingw64\lib\gcc\x86_64-w64-mingw32\12.1.0"'
libpth=E:\mingw64\lib E:\mingw64\x86_64-w64-mingw32\lib E:\mingw64\lib\gcc\x86_64-w64-mingw32\12.1.0
libs=-static -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
perllibs=-static -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
libc=-static
so=dll
useshrplib=true
libperl=libperl536.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs
dlext=dll
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags='-shared -s -L"C:\Perl64\lib\CORE" -L"E:\mingw64\lib" -L"E:\mingw64\x86_64-w64-mingw32\lib" -L"E:\mingw64\lib\gcc\x86_64-w64-mingw32\12.1.0"'


@inc for perl 5.36.0:
""
N:/PERL/Perl64/site/lib
N:/PERL/Perl64/lib


Environment for perl 5.36.0:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=C:\Perl64\bin;C:\Windows\System32;C:\Windows;E:\mingw64\bin;E:\TOOLSES;D:\BAT;D:\oci\bin
PERL5LIB=""
PERL_BADLANG (unset)
SHELL (unset)

@sisyphus
Copy link
Contributor

sisyphus commented Jun 5, 2022

Thank you for identifying a fix for this problem.
I found the same problem when I tried to build perl-5.36.0 with my mingw-w64 port of gcc-12.1.0 on Windows 7.
But I didn't know where the alignment problem lay ... and I'm delighted that you've solved that part for us.

A few things I would like to point out:

  1. The vmem.h in lib/CORE is created during the build, and is a copy of win32/vmem.h. So it's necessary only to patch win32/vmem.h.

  2. I haven't struck this problem with Visual Studio 2019, so I suspect that we don't need to patch for _MSC_VER at all.
    Of course, there might be other versions of Visual Studio that do need the patch ... I don't know. And, of course, even if it's not needed, I guess it's not going to do any harm, anyway.

  3. I couldn't get the patch that you provided to work. But you're patch did lead me to one that nearly works for me.
    Here is the patch I used:

--- vmem.h_orig	2022-06-05 13:38:28 +1000
+++ vmem.h	2022-06-05 14:31:33 +1000
@@ -69,13 +69,21 @@
 
 #ifdef _USE_LINKED_LIST
 class VMem;
+#if __GNUC__ > 11
+typedef struct _MemoryBlockHeader* PMEMORY_BLOCK_HEADER __attribute__ ((aligned(16)));
+#else
 typedef struct _MemoryBlockHeader* PMEMORY_BLOCK_HEADER;
+#endif
 typedef struct _MemoryBlockHeader {
     PMEMORY_BLOCK_HEADER    pNext;
     PMEMORY_BLOCK_HEADER    pPrev;
     VMem *owner;
+#if __GNUC__ > 11
+} MEMORY_BLOCK_HEADER __attribute__ ((aligned(16))), *PMEMORY_BLOCK_HEADER;
+#else
 } MEMORY_BLOCK_HEADER, *PMEMORY_BLOCK_HEADER;
 #endif
+#endif
 
 class VMem
 {

The problem we're dealing with doesn't arise with gcc-11 or earlier, so I've written the patch to take effect only if gcc is at version 12 (or later).
But perhaps nothing is achieved by limiting the patch to gcc-12 and later.

The only remaining issue for me is that perl crashed 3 or 4 times during the running of gmake test, though only one of those crashes caused a "FAIL" to be registered.
So there's still something not quite right.
The one crash that did register as a "FAIL" was the one that occurred at either the beginning or the end of ../cpan/bignum/t/backend-gmp-bigfloat.t.
That's quite strange because no tests are actually run.
In fact, it's probably an error (of little significance) that this test file is present. There is no possibility that Math::BigInt::GMP will be found during the running of the perl test suite.
If I run that test script outside of the test harness, then it behaves as it should ... and no crash.

You haven't mentioned any other patches to the perl source that you used.
For me, with 5.36.0 source I have to patch at least cpan/Socket/Socket.xs and dist/IO/poll.h.
Did you do the same ?
(In current blead, the dist/IO/poll.h patch is already applied, so it's only the cpan/Socket/Socket.xs that requires the patching.)

I notice from your perl -V output that you've set optimization to -Os.
I've stayed with -O2 optimization. I don't see any other significant difference other than the different versions of Windows.
Now that I've finally been able to build a perl (that doesn't crash) with gcc-12.1.0, here is my perl -V:

Summary of my perl5 (revision 5 version 36 subversion 0) configuration:
   
  Platform:
    osname=MSWin32
    osvers=6.1.7601
    archname=MSWin32-x64-multi-thread
    uname=''
    config_args='undef'
    hint=recommended
    useposix=true
    d_sigaction=undef
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=undef
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='gcc'
    ccflags =' -DWIN32 -DWIN64 -fdiagnostics-color=never -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -mms-bitfields'
    optimize='-O2'
    cppflags='-DWIN32'
    ccversion=''
    gccversion='12.1.0'
    gccosandvers=''
    intsize=4
    longsize=4
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='long long'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='g++'
    ldflags ='-s -L"C:\perl-5.36.0-1210\lib\MSWin32-x64-multi-thread\CORE" -L"C:\_64\winlibs-gcc-1210\mingw64\lib" -L"C:\_64\winlibs-gcc-1210\mingw64\x86_64-w64-mingw32\lib" -L"C:\_64\winlibs-gcc-1210\mingw64\lib\gcc\x86_64-w64-mingw32\12.1.0"'
    libpth=C:\_64\winlibs-gcc-1210\mingw64\lib C:\_64\winlibs-gcc-1210\mingw64\x86_64-w64-mingw32\lib C:\_64\winlibs-gcc-1210\mingw64\lib\gcc\x86_64-w64-mingw32\12.1.0 C:\_64\msys_1210\1.0\local\lib
    libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    libc=
    so=dll
    useshrplib=true
    libperl=libperl536.a
    gnulibc_version='10.0.0'
  Dynamic Linking:
    dlsrc=dl_win32.xs
    dlext=dll
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags=' '
    lddlflags='-shared -s -L"C:\perl-5.36.0-1210\lib\MSWin32-x64-multi-thread\CORE" -L"C:\_64\winlibs-gcc-1210\mingw64\lib" -L"C:\_64\winlibs-gcc-1210\mingw64\x86_64-w64-mingw32\lib" -L"C:\_64\winlibs-gcc-1210\mingw64\lib\gcc\x86_64-w64-mingw32\12.1.0"'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_TIMES
    HAVE_INTERP_INTERN
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_IMPLICIT_SYS
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under MSWin32
  Compiled at Jun  5 2022 14:33:11
  @INC:
    C:/perl-5.36.0-1210/site/lib/MSWin32-x64-multi-thread
    C:/perl-5.36.0-1210/site/lib
    C:/perl-5.36.0-1210/lib/MSWin32-x64-multi-thread
    C:/perl-5.36.0-1210/lib


@yjh-styx
Copy link
Author

yjh-styx commented Jun 5, 2022

The vmem.h in lib/CORE is created during the build, and is a copy of win32/vmem.h. So it's
necessary only to patch win32/vmem.h.
Thanks for the information (I did the quick fix and was just too lazy to unpack it again, and make clean didn't remove it)

I haven't struck this problem with Visual Studio 2019, so I suspect that we don't need to patch for _MSC_VER at all.
Yes, definitely. The part for _MSC was made for the following reasons - in terms of today's C standard, what happens is a compiler error (gcc). However, looking back at the history of their similar errors, it is possible that a change was/will be made in the draft like this "any complex type must be aligned to the maximum integral type of the platform", in which case the patch will have to be done for all compilers. Well, "so as not to insert twice" ... :). Fortunately, this edit does not affect the speed of work,
and it does not really affect the memory used.

The problem we're dealing with doesn't arise with gcc-11 or earlier, so I've written the patch
to take effect only if gcc is at version 12 (or later).
Well, if you do everything "strictly by necessity", then you can still check the platform (patch is needed only in x64 or x86 with AVX enabled). Well, if "at a minimum", then your version is more correct. Only I would change #if like this
#if defined(GNUC) && GNUC >= 12
because with an undefined symbol "just" comparison in some compilers will give an error.

For me, with 5.36.0 source I have to patch at least cpan/Socket/Socket.xsand dist/IO/poll.h.
Did you do the same ?
For Socket.xs/poll.h, I have a patch that changes the name of inet_pton to _inet_pton, and includes
winsock2.h instead of 'system' poll.h - however, this patch is mingw-windows-specific, so I did not
send it then (5.34) or now.

I notice from your perl -Voutput that you've set optimization to -Os.
I've stayed with -O2optimization. I don't see any other significant difference
other than the different versions of Windows.
Maybe that's the point. With -Os, the behavior of gcc changes quite noticeably - for example, patch with alignment is no longer necessary. I do not exclude that some other errors/incompatibilities are eliminated.

@jkeenan jkeenan changed the title Perl can't be build on x64 platform with gcc12.1 Perl can't be built on x64 platform with gcc12.1 Jun 5, 2022
@sisyphus
Copy link
Contributor

sisyphus commented Jun 5, 2022

I'm certainly agreeable to:

#if defined(__GNUC__) && __GNUC__ >= 12

It doesn't seem to be needed with the 32-bit mingw-w64 ports of gcc-12.1.0 so we could also write it as:

#if defined(__MINGW64__) && __GNUC__ >= 12

but if there's a chance that it might be needed in future with 32-bit builds, then I'd be happy to exclude the "64 bit" requirement.
However, I'm not the one who would make the decision about that.
(If __MINGW64__ is defined then so is __GNUC__.)

Also, it sounds fair enough to me that we include the safeguard for _MSC_VER if there's a chance that an MS compiler might need it.
Again, that wouldn't be my decision to make.

Do you have a link that explains what -Os optimization is ? I couldn't dig up any information on it.

My current proposal on how to deal with the Socket.xs problem can be seen in my most recent post at:
https://rt.cpan.org/Public/Bug/Display.html?id=142390

If you have any comments on that, now would be a good time to make them.
Please provide your patches to that thread if you' think they are a better solution than the one I've proposed,

@yjh-styx
Copy link
Author

yjh-styx commented Jun 5, 2022

It doesn't seem to be needed with the 32-bit mingw-w64 ports of gcc-12.1.0 so we could also write it as:
#if defined(MINGW64) && GNUC >= 12
Yes, but I think that this problem is NOT a mingw-specific

Do you have a link that explains what -Os optimization is ? I couldn't dig up any information on it.
gcc -Q -Os --help=optimizers

My current proposal on how to deal with the Socket.xs problem can be seen in my most recent post at:
...
Please provide your patches to that thread if you' think they are a better solution than the one I've proposed,
---cit---
--- dist/IO/poll.h.orig Thu Jan 21 02:04:44 2021
+++ dist/IO/poll.h Fri Sep 17 22:27:44 2021
@@ -10,7 +10,9 @@
#ifndef POLL_H

define POLL_H

-#if (defined(HAS_POLL) && defined(I_POLL)) || defined(POLLWRBAND)
+#if defined(WINDOWS) || defined(_WIN32)
+# include <winsock2.h>
+#elif (defined(HAS_POLL) && defined(I_POLL)) || defined(POLLWRBAND)

include <poll.h>

#elif (defined(HAS_POLL) && defined(I_SYS_POLL))

include <sys/poll.h>

--- cpan/Socket/Socket.xs.orig Sun Apr 24 23:29:00 2022
+++ cpan/Socket/Socket.xs Sat Jun 04 13:12:42 2022
@@ -98,7 +98,7 @@

#endif

-static int inet_pton(int af, const char *src, void *dst)
+static int _inet_pton(int af, const char *src, void *dst)
{
struct sockaddr_storage ss;
int size = sizeof(ss);
@@ -120,7 +120,7 @@
}
}

-static const char *inet_ntop(int af, const void *src, char *dst, socklen_t size)
+static const char *_inet_ntop(int af, const void *src, char *dst, socklen_t size)
{
struct sockaddr_storage ss;
unsigned long s = size;
@@ -1157,7 +1157,7 @@
}

void
-inet_ntop(af, ip_address_sv)
+_inet_ntop(af, ip_address_sv)
int af
SV * ip_address_sv
CODE:
@@ -1207,7 +1207,7 @@
else {
Copy(ip_address, &addr, sizeof addr, char);
}

  • inet_ntop(af, &addr, str, sizeof str);
  • _inet_ntop(af, &addr, str, sizeof str);

    ST(0) = sv_2mortal(newSVpvn(str, strlen(str)));
    #else
    @@ -1217,7 +1217,7 @@
    #endif

void
-inet_pton(af, host)
+_inet_pton(af, host)
int af
const char * host
CODE:
@@ -1248,7 +1248,7 @@
#endif
"Socket::inet_pton", af);
}

  • ok = (*host != '\0') && inet_pton(af, host, &ip_address);
  • ok = (*host != '\0') && _inet_pton(af, host, &ip_address);

    ST(0) = sv_newmortal();
    if (ok) {
    --end---

@hvds
Copy link
Contributor

hvds commented Jun 5, 2022

Do you have a link that explains what -Os optimization is ? I couldn't dig up any information on it.

See https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

-Os means optimize for (code) size, rather than for speed.

@yjh-styx
Copy link
Author

yjh-styx commented Jun 5, 2022

-Os means optimize for (code) size, rather than for speed.
Formally this is so, but by fact -Os enabled almost speed optimiztion.
say:
gcc -Q -O2 --help=optimize
and
gcc -Q -Os --help=optimize
and compare output

@sisyphus
Copy link
Contributor

sisyphus commented Jun 6, 2022

Thanks for the info about -Os. (The docs that I kept googling up mentioned only -O0, -O1, -O2 and -O3.)
With -Os optimization, the (few) perl crashes that I experienced during the running of the test suite no longer occurred.
I found that another way to avoid them (while still keeping -O2 optimization && the alignment patch to vmem.h) was to build perl without threads.

@sisyphus
Copy link
Contributor

In testing today's release of 5.37.1, I've tried to get a better handle on what works and what doesn't when building with gcc-12.1.0, runtime version 10.
The 16-byte alignment in win32/vmem.h seems to be essential for 64-bit builds of 5.37.1, but not needed for 32-bit builds.
For 64 bit builds, if I want to avoid crashes during the running of the test suite, then I need to additionally do one of 3 things:

  1. build perl without threads, or
  2. change optimization from -O2 to -Os or
  3. build perl with CFG=Debug.

Either of those 3 changes will allow the test suite to complete without failure.
(I haven't actually tried a Debug build without the 16-byte alignment stuff in win32/vmem.h ... so I don't know what happens in that case.)

The crashing that otherwise occurs during the test suite, seems to occur only in certain test scripts, and at random points within those scripts.
It doesn't cause any termination of the test scripts; nor does it result in any test failures being reported.
I'm wondering if it's something in Test::More that's being triggered.
These crashes (maybe "cessations" is a better description) can also occur if the test scripts are run outside of the Harness. Again, it's just a matter of closing the pop-up box that appears, and the tests will continue on without any registration of a failure.
Sometimes there will be a succession of these "cessations" in the same test script - but always at seemingly random points.
I'll see if I can get some debug info about what's going on, and report futher.

@sisyphus
Copy link
Contributor

The test suite crashes occur in test files that don't use Test::More.
But all of those files do require t/test.pl - which claims to provide "most of Test::More functionality without the fuss".
For the record, here's a list of the test files which I found to be prone to the crashing (in perl-5.37.1) :
t/run/switches.t
t/op/heredoc.t
t/lib/croak.t
t/win32/popen.t
lib/charnames.t
lib/strict.t

t/win32/popen.t is the only one of those files that registers a FAIL as a result of the crash.
All other files still register as PASS.

I think that fixing this will turn out to be beyond my capabilities, but I'll keep poking at it from time to time, and report anything that might be useful.

@sisyphus
Copy link
Contributor

@yjh-styx I think that a PR with the fix to win32/vmem.h should be presented now.
If we sit around waiting for someone else to run with it, we might be waiting for a very long time ;-)

We've already established that there's a bit more to it than just amending win32/vmem.h, but those additional points (namely optimization level and whether we want debugging or unthreaded or threaded) can already be handled via configuration directives, without any need to make additional amendments to the perl source.

@yjh-styx would you like to prepare that PR ?
If not, I'm happy to do it.
The only thing I would want to know is whether you find the following patch satisfactory:

--- vmem.h_vmem_h	2022-06-21 03:57:59 +1000
+++ vmem.h	2022-06-21 11:50:53 +1000
@@ -69,14 +69,26 @@
 
 #ifdef _USE_LINKED_LIST
 class VMem;
+
+#if defined(__MINGW64__) && __GNUC__ > 11
+typedef struct _MemoryBlockHeader* PMEMORY_BLOCK_HEADER __attribute__ ((aligned(16)));
+#else
 typedef struct _MemoryBlockHeader* PMEMORY_BLOCK_HEADER;
+#endif
+
 typedef struct _MemoryBlockHeader {
     PMEMORY_BLOCK_HEADER    pNext;
     PMEMORY_BLOCK_HEADER    pPrev;
     VMem *owner;
+
+#if defined(__MINGW64__) && __GNUC__ > 11
+} MEMORY_BLOCK_HEADER __attribute__ ((aligned(16))), *PMEMORY_BLOCK_HEADER;
+#else
 } MEMORY_BLOCK_HEADER, *PMEMORY_BLOCK_HEADER;
 #endif
 
+#endif
+
 class VMem
 {
 public:

Cheers,
Rob

@sisyphus
Copy link
Contributor

sisyphus commented Jul 7, 2022

Although the merging of #19912 allows a usable perl to be built, it doesn't fix the additional problem with optimization level -O2 on multi-thread Windows perls that are built using gcc-12.
That additional problem was discussed here in this Issue, and I'm wondering whether this Issue should therefore remain open until that problem has either been dealt with or submitted as a new and separate Issue.
In any case, I don't have the requisite permissions to close this Issue.

Cheers,
Rob

@tonycoz
Copy link
Contributor

tonycoz commented Aug 1, 2022

Could you please make a new issue for the other problems?

Thanks

@sisyphus
Copy link
Contributor

sisyphus commented Aug 1, 2022

The other issue has now been raised at #20024 .
I think this Issue can now be closed.

Cheers,
Rob

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants