9.2.0 32 bit issue

[Ilir-Liburn]

Hello,

I tried to run following c++ sample

https://www.codeproject.com/Articles/5318983/The-6-2-1plus2-Ambiguity

but executable crashed. Can you please check if this happens on 10.3.0?

[revelator]

there seems to be a problem with the mechanism to hook into the c++ exceptions, specifically the ones in eh_term_handler and eh_unex_handler. removing these two caused things to start working again. Before that it was also unable to build a working jsoncpp.

[Ilir-Liburn]

Hello,

to not open another issue, here are the things I noticed while working on my project:

By default, strtod function doesn't handle hexadecimal values, while gcc 64 bit on Linux or Mac does. I don't remember which -std= option I had to use, but that caused many other issues, so I always use defaults.

    nResult = strtod(cStr, &cEndStr);
    /* https://linux.die.net/man/3/strtod */
    if ( cEndStr && *cEndStr != '\0' ) {
        #if defined(__GNUC__) && defined(_WIN32)
            /* Hexadecimal conversion fallback */
            nHex = strtoll(cStr,&cEndStr,16);
            if ( cEndStr && *cEndStr == '\0' ) {
                return nHex ;
            }
        #endif
        /*
        **  If nothing was converted, input has invalid format 
        **  We don't display a runtime error, we return NAN 
        */
        return NAN ;
    }

There is no reallocarray function which like calloc can use input in form length and sizeof(element), so I made my own just checking whether multiplication exceeds 32 bit range

void * reallocarray ( void *ptr, size_t nitems, size_t size )
{
    ULONGLONG nSize = nitems * size ;
    if ( nSize <= 0xFFFFFFFF ) {
        ptr = realloc(ptr,(size_t)nSize) ;
    }
    else ptr = NULL ;
    return ptr ;
}   

[revelator]

what i discovered was that since the eh_shmem mechanism uses string concatenation we end up exporting the wrong variable, should be terminate_handler but ends up being exported as _shmem_init_eh_term_handlerterminate_handler which breaks anything using this mechanism.

original ->

extern std::terminate_handler __terminate_handler;
extern std::unexpected_handler __unexpected_handler;

with tdm

__SHMEM_DECLARE(std::terminate_handler, eh_term_handler__terminate_handler)
#define __terminate_handler __SHMEM_GET(std::terminate_handler, eh_term_handler__terminate_handler)
__SHMEM_DECLARE(std::unexpected_handler, eh_unex_handler__unexpected_handler)
#define __unexpected_handler __SHMEM_GET(std::unexpected_handler, eh_unex_handler__unexpected_handler)

the terminate_handler and __unexpected_handler are local only and not exported to the library which is fine as long as something does not do something like call std::terminate_handler in which case things go badly.

[revelator]

well ugh... i just tried applying the patchset to gcc-12.1.0 and it is totally broken :S gnat can no longer bootstrap with it throws an exception, in fact any gcc greater than 11.2.0 will segfault with the TDM patchset.

[revelator]

strangely the older version2 of the patchset works if we unlink memcpy and memset from the gcc runtimes like it is done in the newer version. the problem with the __terminate_handler and __unexpected_handler is still a cause for concern though.

[revelator]

gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada
xgcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report, with preprocessed source (by using -freport-bug).
See <https://github.com/msys2/MINGW-packages/issues> for instructions.
make[3]: *** [../../gcc-12.1.0/gcc/ada/gcc-interface/Make-lang.in:167: ada/ali.o] Error 4
make[3]: *** Waiting for unfinished jobs....
xgcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report, with preprocessed source (by using -freport-bug).
See <https://github.com/msys2/MINGW-packages/issues> for instructions.
make[3]: *** [../../gcc-12.1.0/gcc/ada/gcc-interface/Make-lang.in:167: ada/aspects.o] Error 4
rm gcc.pod gfortran.pod
make[3]: Leaving directory '/D/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc'
make[2]: *** [Makefile:5057: all-stage3-gcc] Error 2
make[2]: Leaving directory '/D/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[1]: *** [Makefile:26219: stage3-bubble] Error 2
make[1]: Leaving directory '/D/mingw-w64-gcc/src/build-i686-w64-mingw32'
make: *** [Makefile:1084: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

as you can see :/

[revelator]

gcc-12.2.0 makes the tdm patchset completely unsuitable for the C++ exception part :S the static functions in eh_globals have been changed to C++ constructors so will need a rather hefty rewrite.

[revelator]

fixed most parts for gcc-12.2.0 ada now relies on shared-libgcc and will no longer accept linking gnat to the static runtimes (throws an exception if you try). patched make-lang.in to allways link the executable to the shared libgcc, repeated this for all the other executables as the compiler now uses g++ as the bootstrap compiler and some rather nasty things happen if they are not linked to the shared runtimes. the compiler itself when built still links to the static runtimes unless told otherwise so no worries. the libsupc++ part had to be rewritten somewhat because the cxa functions we used to hook with the shmem mechanism are no longer avaliable in a form usable by the macros. i moved the shmem mechanism into eh_terminate.cc instead which for the part of g++ is the only place it was used anyway, bit unstable still but atleast it builds now.

[revelator]

original-shmem.zip

this is the original implementation from gcc.3.4.4 for posterity, it was quite different from the TDM model as it used the crt for enabling the shared pointers, it also rolled it's own terminate and unexpected handlers. Ive done some preliminary work on it to see if it works better than what we have now.

[revelator]

it seems to be the new dwarf 5 format causing all these headaches :S we had numerous bugs with it on msys2 and while it does build now static exceptions are broken (throws abort after the first exception). I rebuilt the compiler with sjlj for the 32 bit part using SEH for the 64 bit one and all works well again.

[Ilir-Liburn]

seems to be fixed, closing