[Bug modula2/113511] lack of libm2 ABI compatibility on powerpc platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113511 --- Comment #2 from gaiusmod2 at gmail dot com --- "rguenth at gcc dot gnu.org" writes: > There's also the question on compatibility to libgm2 from GCC 13. indeed - I guess the -mabi could be retained for backward compatibility. > I suppose the frontend could simply not allow changing the M2 language > "long double" (however it is called) with -mabi=... (which really only > change the C language ABI!). Of course calls to libm are subject to the > C language ABI. ok yes. So m2's longreal data type uses ieeelongdouble throughout by default on powerpc - that would be clean. In principle could all the C interface from m2 code convert the longreal representation to glibc long double and visa versa? So for example in the case of libm.def change libm.def from a DEFINITION FOR "C" to an ordinary m2 definition module. Introduce libm.c which for non power platforms just passes calls though to C. On powerpc (without an IEEE128 glibc) it will convert __float128 onto the underlying long double representation. > Does the language standard have anything to say here? I suppose there's > no ABI documents for M2 for various targets, so eventually C interoperability > language in the standard directs at the common sense? It leaves much to be implementation defined :-) The gcc/m2/gm2-libs-iso/LowLong.def provides setMode which could be used to control the behaviour of the above conversions. The size of the set Modes and their meaning is implementation defined. Possibly it might be implemented: Bit 0: issue an error and abort if the underlying long double support in glibc does not match the longreal in m2. Bit 1: issue a single warning if the underlying long double support in glibc does not match the longreal in m2 and then attempt conversion. Bit 2: raise an exception if the underlying long double support in glibc does not match the longreal in m2. Bit 3: raise an exception if the conversion between longreal and glibc C long double representations exceeds range. Bit 4.. More bits to control conversion behaviour. [ as a start ]
[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #16 from gaiusmod2 at gmail dot com --- "rguenth at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 > > --- Comment #15 from Richard Biener --- > (In reply to Gaius Mulley from comment #14) >> Ah apologies, is it best that I revert: >> >> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; >> h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 >> >> happy to do this in the morning. > > I think it might be better to define > M2C_LONGREAL_FLOAT128/M2C_LONGREAL_PPC64LE > (whatever they exactly indicate) in terms of the existing > > --with-long-double-128 > --with-long-double-format > > aka the TARGET_DEFAULT_LONG_DOUBLE_128 that's put into the config plus > with_long_double_format (I think that causes TARGET_IEEEQUAD_DEFAULT > to be defined to 1/0, but only for ppc, via config.gcc and > tm_defines). yes thanks for the hints this sounds good. I'll pursue this line for a fix. > I can't say whether it's better to revert or disable/fix as I can't say > how this for example affects the M2 ABI (like if there was any 'long double' > before this change and what effective type this used). Prior to the patch it used the default C long double type but many of the intrinsic functions were broken. Currently with the patch gcc120 has no regression test failures and gcc135 (yesterday with manual configure intervention) was at 96 failures in the m2 testsuite. I suspect configure confusion and hence using TARGET_DEFAULT_LONG_DOUBLE_128 and TARGET_IEEEQUAD_DEFAULT should resolve it.
[Bug modula2/112946] Assignment of string to enumeration or set crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946 --- Comment #5 from gaiusmod2 at gmail dot com --- many thanks for the bug report - all fixed in gcc master branch.
[Bug modula2/93575] the modula2 frontend fails to build with a profiled bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93575 Gaius Mulley changed: What|Removed |Added CC||gaiusmod2 at gmail dot com --- Comment #1 from Gaius Mulley --- I've git pushed fixes to the devel/modula-2 branch (gcc-12) which now allows gm2 to be built using: MAKEFLAGS=profiledbootstrap-lean CONFIGFLAGS=--with-build-config=bootstrap-lto-lean I'm also seeing all regression tests pass on the amd64 platform and aarch64 platform after the lto build.
[Bug modula2/102325] gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 --- Comment #3 from Gaius Mulley --- "rguenth at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 > > Richard Biener changed: > >What|Removed |Added > >Last reconfirmed||2021-09-14 > Ever confirmed|0 |1 > Status|UNCONFIRMED |NEW > > --- Comment #1 from Richard Biener --- > Confirmed. [again apologies if this is the wrong way to mention a status change.] now fixed in the git repro. regards, Gaius regards, Gaius
[Bug modula2/102339] gm2 testsuite leaves many files behind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339 --- Comment #2 from Gaius Mulley --- "ro at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339 > > Bug ID: 102339 >Summary: gm2 testsuite leaves many files behind >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: modula2 > Assignee: unassigned at gcc dot gnu.org > Reporter: ro at gcc dot gnu.org > CC: gaiusmod2 at gmail dot com > Target Milestone: --- > > After running the gm2 testsuite, there are almost 2000 files left behind in > gcc/testsuite/gm2. All but a handful follow the same pattern, e.g. > > wr.x0-wr_m2.o > > I suspect this is a driver issue: m2-link-support.h has > > #define SCAFFOLDNAME "%b_m2" > > Since those files are purely temporary, I suspect (but haven't tried) that > they > should be marked as such using %d. > > There are only a few more: > > * remaining objects: > > cpp.o > cvararg.o > fileio.o > hello.o > mycpp.o > rangesupport.o > sys.o > testiotransfer.o > wr.o > > * also: > > integer.x0-integer_m2.cpp > integer.x1-integer_m2.cpp > integer.x2-integer_m2.cpp > integer.x3-integer_m2.cpp > integer.x4-integer_m2.cpp > integer.x5-integer_m2.cpp > > results.dat > > second.txt > > test.txt > > testiotransfer.x2* > testiotransfer.x5* > testtime.x3* [again apologies if this is the wrong way to mention a status change.] I'd like to confirm the bug and report that it is now fixed (I believe) in the git repro. regards, Gaius regards, Gaius
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #3 from Gaius Mulley --- "ro at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 > > Bug ID: 102344 >Summary: gm2/pim/fail/TestLong4.mod FAILs >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: modula2 > Assignee: unassigned at gcc dot gnu.org > Reporter: ro at gcc dot gnu.org > CC: gaiusmod2 at gmail dot com > Target Milestone: --- > > The gm2/pim/fail/TestLong4.mod test FAILs everywhere, it seems (seen on > i386-pc-solaris2.11 and x86_64-pc-linux-gnu, both 32 and 64-bit): > > FAIL: gm2/pim/fail/TestLong4.mod, -g > FAIL: gm2/pim/fail/TestLong4.mod, -O > FAIL: gm2/pim/fail/TestLong4.mod, -O -g > FAIL: gm2/pim/fail/TestLong4.mod, -Os > FAIL: gm2/pim/fail/TestLong4.mod, -O3 -fomit-frame-pointer > FAIL: gm2/pim/fail/TestLong4.mod, -O3 -fomit-frame-pointer -finline-functions > > The test is expected to FAIL, it seems, but actually compilation completes > without error. So this should actually be an XPASS instead. apologies if this is the wrong way to mention a status change. (Is this done on bugzilla? I've looked and cannot see how to change its status :-). I'd like to confirm the bug and report that it is now fixed (I believe) in the git repro. I've moved TestLong4.mod to the pass directory, regards, Gaius regards, Gaius
[Bug modula2/101388] Unconditional use of __MAX_BAUD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388 --- Comment #5 from Gaius Mulley --- Many thanks - I've applied the patch to the git repro. Fixed now I believe.
[Bug modula2/102323] gm2 testsuite needs to be parallelized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102323 --- Comment #1 from Gaius Mulley --- Confirmed, thank you for the bug report. Now fixed in the git repro.
[Bug modula2/102340] gm2 test sources shouldn't be executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102340 Gaius Mulley changed: What|Removed |Added CC||gaiusmod2 at gmail dot com --- Comment #1 from Gaius Mulley --- Confirmed and fixed now in the git repository. Many thanks for the report.
[Bug modula2/102339] gm2 testsuite leaves many files behind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339 --- Comment #1 from Gaius Mulley --- Confirmed as a bug and now fixed in the repository - many thanks for the report.
[Bug modula2/102325] gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 --- Comment #2 from Gaius Mulley --- Many thanks for reporting this bug/issue. I've now git pushed changes which have renamed all the gm2.exp driver scripts as distinct names.
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #2 from Gaius Mulley --- moved file in the git repro branch and pushed.
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #1 from Gaius Mulley --- "ro at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 > > Bug ID: 102344 >Summary: gm2/pim/fail/TestLong4.mod FAILs >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: modula2 > Assignee: unassigned at gcc dot gnu.org > Reporter: ro at gcc dot gnu.org > CC: gaiusmod2 at gmail dot com > Target Milestone: --- > > The gm2/pim/fail/TestLong4.mod test FAILs everywhere, it seems (seen on > i386-pc-solaris2.11 and x86_64-pc-linux-gnu, both 32 and 64-bit): > > FAIL: gm2/pim/fail/TestLong4.mod, -g > FAIL: gm2/pim/fail/TestLong4.mod, -O > FAIL: gm2/pim/fail/TestLong4.mod, -O -g > FAIL: gm2/pim/fail/TestLong4.mod, -Os > FAIL: gm2/pim/fail/TestLong4.mod, -O3 -fomit-frame-pointer > FAIL: gm2/pim/fail/TestLong4.mod, -O3 -fomit-frame-pointer -finline-functions > > The test is expected to FAIL, it seems, but actually compilation completes > without error. So this should actually be an XPASS instead. yes indeed it should be XPASS - I'll move this into the pass directory. regards, Gaius
[Bug modula2/101389] Parallel build doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101389 Gaius Mulley changed: What|Removed |Added CC||gaiusmod2 at gmail dot com --- Comment #1 from Gaius Mulley --- Thanks for the report - I've pushed some fixes to various Makefiles. I've tested it using make -j48 and believe it is fixed.
[Bug modula2/101387] Unconditional use of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101387 --- Comment #1 from Gaius Mulley --- many thanks for the bug report - now fixed in the git repro. The bugfix emits a prototype for throw (if required) rather than use a non portable header file.
[Bug modula2/101388] Unconditional use of __MAX_BAUD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388 --- Comment #1 from Gaius Mulley --- "ro at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388 > > Bug ID: 101388 >Summary: Unconditional use of __MAX_BAUD >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: modula2 > Assignee: unassigned at gcc dot gnu.org > Reporter: ro at gcc dot gnu.org > CC: gaiusmod2 at gmail dot com > Target Milestone: --- > Target: *-*-solaris2.11 > > Building the devel/modula-2 branch on Solaris 11 fails with undefined > references > to __MAX_BAUD in two places: > > /vol/gcc/src/git/modula-2/gcc/m2/mc-boot-ch/Gtermios.c: In function > 'termios_GetFlag': > /vol/gcc/src/git/modula-2/gcc/m2/mc-boot-ch/Gtermios.c:872:27: error: > '__MAX_BAUD' undeclared (first use in this function) >*b = ((t->c_cflag & __MAX_BAUD) == __MAX_BAUD); >^~ > > /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs-ch/termios.c: In function > 'termios_GetFlag': > /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs-ch/termios.c:877:27: error: > '__MAX_BAUD' undeclared (first use in this function) > 877 | *b = ((t->c_cflag & __MAX_BAUD) == __MAX_BAUD); > | ^~ > __MAX_BAUD seems to be Linux/glibc specific, but the current problem is > obviously > cause by a wrong guard which checks for defined(MAX) instead of > defined(__MAX_BAUD). > > Correcting this lets the build continue. many thanks for the report - now fixed in the git repro, regards, Gaius
[Bug modula2/101391] Unresolved reference to module getopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391 --- Comment #2 from Gaius Mulley --- Thanks for mentioning the automake version discrepancy - which is also fixed in git using 1.15.1.
[Bug modula2/101259] error: the file containing the definition module 'getopt' cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101259 --- Comment #3 from Gaius Mulley --- "doko at debian dot org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101259 > > Matthias Klose changed: > >What|Removed |Added > > CC||gaiusmod2 at gmail dot com thanks for the bug report - all fixed now in git, regards, Gaius
[Bug modula2/101391] Unresolved reference to module getopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391 Gaius Mulley changed: What|Removed |Added CC||gaiusmod2 at gmail dot com --- Comment #1 from Gaius Mulley --- Now fixed in the gcc git repro thanks for the patch.
