[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert

2021-01-16 Thread keith.marshall at mailinator dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586 --- Comment #6 from Keith Marshall --- (In reply to David Malcolm from comment #5) > Should be fixed by the above commit. I applied your patch, and disabled (by changing "#ifdef _WIN32" to "#if 0") the effect of my own, so that the invalid

[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert

2021-01-08 Thread keith.marshall at mailinator dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586 --- Comment #2 from Keith Marshall --- (In reply to David Malcolm from comment #1) > I looked at calling diagnostic_initialize. > > Unfortunately, libgccjit supports being linked into multithreaded processes, > and it guards all of the regular

[Bug jit/98586] New: libgccjit crashes with segmentation fault on failed gcc_assert

2021-01-07 Thread keith.marshall at mailinator dot com via Gcc-bugs
Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- In response to a feature request by Eli Zaretskii, with my follow-up as detailed at https://osdn.net/projects/mingw/ticket/41070, I

[Bug libgomp/93471] GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths

2020-01-28 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471 --- Comment #4 from Keith Marshall --- (In reply to Keith Marshall from comment #3) > Although this initially manifests for libgomp, the actual source of the > failure may lie elsewhere within the GCC build system. After placing > libpthread.a

[Bug libgomp/93471] GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths

2020-01-28 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471 --- Comment #3 from Keith Marshall --- (In reply to Jakub Jelinek from comment #2) > No idea what to look for, don't have any Windows around, Nor do I ... I encountered this, initially when building a --target=mingw32 cross-compiler, on an

[Bug libgomp/93471] New: GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths

2020-01-27 Thread keith.marshall at mailinator dot com
: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com CC: jakub at gcc dot gnu.org Target Milestone: --- Building GCC-9.2.0 for mingw32 target, initially as GNU/Linux hosted

[Bug libgomp/84393] New: "make install" omits gfortran modules, following cross-native build

2018-02-14 Thread keith.marshall at mailinator dot com
ty: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com CC: jakub at gcc dot gnu.org Target Milestone: --- I've successfully built, and installed, GCC-6.3.0 as a GNU/Li

[Bug driver/84391] New: External specs file misinterpreted, unless read twice

2018-02-14 Thread keith.marshall at mailinator dot com
Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- I'm experimenting with a customised GCC specs file, to enable selection of alternative runtime libraries for MinGW. I started by extracting the default

[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1

2017-10-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 --- Comment #12 from Keith Marshall --- (In reply to Jakub Jelinek from comment #10) > While defining float_t to float and double_t to long double for -msse > -mfpmath=sse is a reasoanble choice, Actually, it is the correct choice, but... >

[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1

2017-10-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 --- Comment #11 from Keith Marshall --- (In reply to Jakub Jelinek from comment #8) > Indeed, this really is a mingw bug. Wrong! It is *both* a MinGW bug, *and* a GCC bug. The difference is that I am fully committed to fixing the MinGW bug,

[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1

2017-10-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 --- Comment #6 from Keith Marshall --- (In reply to Jakub Jelinek from comment #5) > __FLT_EVAL_METHOD__ 0 can't be correct in that case, "all operations and > constants evaluate in the range and precision of the type used." does not > hold,

[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1

2017-10-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 Keith Marshall changed: What|Removed |Added CC||keith.marshall at mailinator dot c

[Bug libobjc/54720] libobjc install-strip target not populated

2017-06-04 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #4 from Keith Marshall --- Created attachment 41468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41468=edit Make install-strip work for libobjc FWIW, I've applied the attached patch, for the MinGW.org binary distribution of

[Bug ada/80921] cross compiling fails to build Ada shared libraries

2017-06-02 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #15 from Keith Marshall --- Created attachment 41464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41464=edit Patch to create gnatlib import libraries for Win32 (In reply to Eric Botcazou from comment #14) > In any case, the

[Bug ada/80921] cross compiling fails to build Ada shared libraries

2017-06-01 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #13 from Keith Marshall --- (In reply to Eric Botcazou from comment #7) > > With that in place, a clean configure and build does now produce: > > > > gcc/ada/rts/libgnarl-6.dll > > gcc/ada/rts/libgnat-6.dll > > > > but there are no

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

2017-06-01 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #6 from Keith Marshall --- (In reply to Keith Marshall from comment #5) > ... a clean configure and build does now produce: > > gcc/ada/rts/libgnarl-6.dll > gcc/ada/rts/libgnat-6.dll > > but there are no accompanying import

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

2017-05-31 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #5 from Keith Marshall --- (In reply to Eric Botcazou from comment #3) > Probably the FIXME in libada/configure.ac then: > > # Determine what to build for 'gnatlib' > if test $build = $target \ >&& test ${enable_shared} = yes ;

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

2017-05-31 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #2 from Keith Marshall --- (In reply to Eric Botcazou from comment #1) > Look into the compilation log, there must be an error reported in this case. There is not. I see records of (successful) ar commands to build the static

[Bug ada/80921] New: Cross compiling for mingw32 target fails to build Ada shared libraries

2017-05-30 Thread keith.marshall at mailinator dot com
Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- Working on a GNU/Linux host, my goal is to deliver a crossed-native GCC build for deployment on MS-Windows32 hosts

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

2017-05-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 --- Comment #3 from Keith Marshall --- (In reply to Eric Botcazou from comment #1) > Patches should be posted on the gcc-patches mailing-list. Huh? So you can blatantly ignore it there too? Not only is that completely asinine, it contradicts

[Bug libobjc/54720] libobjc install-strip target not populated

2017-05-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #3 from Keith Marshall --- And, more than 4 years later, this issue persists in GCC-6.3.0

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

2017-05-16 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 Keith Marshall changed: What|Removed |Added CC||keith.marshall at mailinator dot c

[Bug libstdc++/79178] New: Configuration tests for ISO-C99 support use invalid standards compliance specs

2017-01-21 Thread keith.marshall at mailinator dot com
: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- When building for mingw32, libstdc++-v3 configure uses an inappropriate -std=... spec, when testing

[Bug libfortran/70311] libgfortran build dies on "implicit declaration of function strncasecmp"

2017-01-21 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311 --- Comment #5 from Keith Marshall --- For sake of completeness, I've also implemented a solution for the strnlen() issue, within MinGW.org's mingwrt code base.

[Bug libfortran/70311] libgfortran build dies on "implicit declaration of function strncasecmp"

2016-04-29 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311 --- Comment #2 from Keith Marshall --- (In reply to Dominique d'Humieres from comment #1) > Could some mingw32 guru assign this PR to her/himself? Well, I should have thought that the requirement to include to expose a prototype for

[Bug other/70313] New: libssp/ssp.c should include wincrypt.h for mingw32

2016-03-19 Thread keith.marshall at mailinator dot com
Component: other Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- When building for the mingw32 target, compilation fails with a "HCRYPTPROV does not name a type" error. HCRYPTPROV is typedef'd in , which is con

[Bug libfortran/70311] New: libgfortran build dies on "implicit declaration of function strncasecmp"

2016-03-19 Thread keith.marshall at mailinator dot com
Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- I've just succeeded in building GCC-5.3.0 as a GNU/Linux hosted cross-compiler for the mingw32 target

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

2016-03-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 Keith Marshall changed: What|Removed |Added CC||keith.marshall at mailinator dot c

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

2015-08-18 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #18 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to Francois-Xavier Coudert from comment #17) Given the history and reasons, I've committed the patch to restore build on mingw32. Marking as fixed on trunk

[Bug libobjc/54720] libobjc install-strip target not populated

2015-07-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #2 from Keith Marshall keith.marshall at mailinator dot com --- Created attachment 36018 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36018action=edit Differences between find staged for each of install-strip and install cases.

[Bug libobjc/54720] libobjc install-strip target not populated

2015-07-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 Keith Marshall keith.marshall at mailinator dot com changed: What|Removed |Added CC

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

2015-07-20 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #10 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to Andrew Pinski from comment #9) Well it is a libgfortran bug yes. Which, being pedantic, makes it a GCC bug, because libgfortran is a component of GCC

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

2015-07-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #5 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

2015-07-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #6 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

2015-07-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #8 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #7) So add #define S_IRWXG 0 #define S_IRWXO 0 to the header file wherever mingw defines the available mask bits for umask(3

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available

2015-07-19 Thread keith.marshall at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #2 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #1) The name of the language is Fortran. The language has been called Fortran since 1988 or so. It was always FORTRAN, in the days

[Bug libfortran/66936] New: io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available

2015-07-19 Thread keith.marshall at mailinator dot com
Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- Created attachment 36013 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36013action=edit