Re: [COMMITTED] Remove obsolete Solaris 11.3 support
Hi Peter, On Fri, 2024-05-10 at 12:07 +0100, Peter Tribble wrote: > Tribblix is built from the last commit that worked (November 2021), with any > relevant changes > since cherry-picked on top. So in terms of timeline Tribblix is contemporary > with 11.4, with > hardware support matching the original Solaris 11 release. Thanks, good to know! And thanks a lot for your efforts! > But we're well into the second decade since the fork, so there's enough > divergence that illumos > and Solaris are really different, even if some of what you see looks very > similar. > > (And illumos on SPARC uses gcc4 to build the kernel [!], although > applications on Tribblix use gcc7. > Given the target market, having the latest and greatest toolchains isn't the > highest priority.) Well, at some point you will run into code that won't build with that old toolchain anymore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
On Fri, 2024-05-10 at 12:14 +0200, Richard Biener wrote: > > Because I wasn't subscribed to gcc-patches and I'm also only subscribed now > > without receiving messages due to the large message volume on this list. > > https://gcc.gnu.org/gcc-13/changes.html > > > The problem with announcements on developer mailing lists is usually that > > they > > usually don't reach any users. I was made aware of this change only when I > > checked about the recent changes to GCC Git. > > Where do you expect such announcement then? That's a difficult question, to be honest. From a user perspective, it's hard to track these upstream announcements. I would argue that most users don't follow all such changes in the upstream projects they are using and, to be honest, I really wouldn't have expected that Solaris 11.3 would be considered obsolete. If it had been for Solaris 7, 8 or 9, I would totally understand. But even Solaris 10 is something that Oracle still supports [1]. Adrian > [1] > https://blogs.oracle.com/support/post/extended-support-for-oracle-solaris-10-operating-system -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
Hello Rainer, On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote: > > > Support for Solaris 11.3 had already been obsoleted in GCC 13. However, > > > since the only Solaris system in the cfarm was running 11.3, I've kept > > > it in tree until now when both Solaris 11.4/SPARC and x86 systems have > > > been added. > > > > > > This patch actually removes the Solaris 11.3 support. > > > > I'm not sure I like this change since Solaris 11.3 is the last version of > > Solaris supported by a large number of SPARC systems. > > > > Oracle unfortunately raised the hardware baseline with Solaris 11.4 such > > that every system older than the SPARC T4 is no longer supported by 11.4 > > while 11.3 still runs perfectly fine on these machines. > > I wonder why you didn't raise your concerns 1 1/2 years ago when I > announced the obsoletion of Solaris 11.3 support? Because I wasn't subscribed to gcc-patches and I'm also only subscribed now without receiving messages due to the large message volume on this list. The problem with announcements on developer mailing lists is usually that they usually don't reach any users. I was made aware of this change only when I checked about the recent changes to GCC Git. > > While Oracle does no longer provide feature updates to Solaris 11.3, there > > is still LTSS security support so that users still receive security updates > > so that their systems are continued to be protected against vulnerabilities. > > The Solaris 11.3 ESUs (Extended Support Updates) are available at a > premium only, and just contain the bare minimum of security updates, > often 6 to 9 month in between. That's not an argument for throwing away hardware that still works perfectly fine and that still has some users. > > I think Solaris 11.3 support should be kept since the resulting code removal > > is not that large that it would justify dropping support for such a large > > userbase. > > Do you have any indication on the size of the userbase? I seriously > doubt it's large beyond some hobbyists that keep the old hardware > running. I don't have the exact numbers, no. But I know there are many users out there with pre-11.4 hardware that they still use. As you may know, there are no 11.4 SPARC desktop systems and most 11.4-capable hardware is usually very expensive. > You also seem to forget that my GCC (and LLVM) Solaris support work is > purely voluntary, done in my spare time. Not sure what makes you think so. I'm perfectly aware of the fact that lots of people do this work in their spare time as this applies to me as well. I'm not getting paid for my Debian work, my kernel maintenance and all the other stuff that I'm doing either. That doesn't mean users are not allowed to ask me questions or send me comments about my work. > Keeping Solaris 11.3 support working would be much more than restoring > the removal patch: > > * For each and every of my Solaris patches, I'd have to investigate if > it works on 11.3 or needs adjustments and workarounds. > > * I'd also need to regularly test the result to keep things working. > > I honestly don't have the time or the energy to do this, nor the > hardware required for testing Besides, I have too much on my plate > already, and rather spend it on more beneficial work. Does Solaris support in GCC really change that often that the necessary tests cannot be run by volunteers? I'd be happy to test changes for Solaris 11.3 which can be installed inside an LDOM. > Above all, I always wonder why people insist on running ancient hardware > with an almost-unsupported OS, but require a bleeding edge version of > GCC. What's wrong with continuing to use GCC 13 (or even 14, although I > haven't tested that on Solaris 11.3) instead? You could also ask why people use operating systems other than Linux and architectures other than x86_64. I don't think you will get a satisfactory answer to that question. > > Removing Solaris 11.3 support might make sense in the future when SPARC > > support in Illumos has matured enough that people can switch over their > > machines. > > As has been noted, SPARC is on its way out for Illumos. Which makes my point to keep Solaris 11.3 support even more valid. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
Hello Rainer, > Support for Solaris 11.3 had already been obsoleted in GCC 13. However, > since the only Solaris system in the cfarm was running 11.3, I've kept > it in tree until now when both Solaris 11.4/SPARC and x86 systems have > been added. > > This patch actually removes the Solaris 11.3 support. I'm not sure I like this change since Solaris 11.3 is the last version of Solaris supported by a large number of SPARC systems. Oracle unfortunately raised the hardware baseline with Solaris 11.4 such that every system older than the SPARC T4 is no longer supported by 11.4 while 11.3 still runs perfectly fine on these machines. While Oracle does no longer provide feature updates to Solaris 11.3, there is still LTSS security support so that users still receive security updates so that their systems are continued to be protected against vulnerabilities. I think Solaris 11.3 support should be kept since the resulting code removal is not that large that it would justify dropping support for such a large userbase. Removing Solaris 11.3 support might make sense in the future when SPARC support in Illumos has matured enough that people can switch over their machines. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] build: Check for cargo when building rust language
On Tue, 2024-04-09 at 10:00 +0200, Jakub Jelinek wrote: > On Tue, Apr 09, 2024 at 09:47:18AM +0200, John Paul Adrian Glaubitz wrote: > > Hello, > > > > On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote: > > > The rust frontend requires cargo to build some of it's components, > > > it's presence was not checked during configuration. > > > > Isn't this creating a hen-and-egg problem? How am I supposed to build a Rust > > compiler for a target which is not supported by rustc (yet) when gccrs is > > supposed to build-depend on cargo which requires rustc? > > Cross-compilers? Well, ok. I had there would be a more convenient solution. I guess we will have to wait for rustc_codegen_gcc to mature then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] build: Check for cargo when building rust language
On Tue, 2024-04-09 at 10:00 +0200, Jakub Jelinek wrote: > On Tue, Apr 09, 2024 at 09:47:18AM +0200, John Paul Adrian Glaubitz wrote: > > Hello, > > > > On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote: > > > The rust frontend requires cargo to build some of it's components, > > > it's presence was not checked during configuration. > > > > Isn't this creating a hen-and-egg problem? How am I supposed to build a Rust > > compiler for a target which is not supported by rustc (yet) when gccrs is > > supposed to build-depend on cargo which requires rustc? > > Cross-compilers? Well, ok. I had there would be a more convenient solution. I guess we will have to wait for rustc_codegen_gcc to mature then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] build: Check for cargo when building rust language
Hello, On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote: > The rust frontend requires cargo to build some of it's components, > it's presence was not checked during configuration. Isn't this creating a hen-and-egg problem? How am I supposed to build a Rust compiler for a target which is not supported by rustc (yet) when gccrs is supposed to build-depend on cargo which requires rustc? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] build: Check for cargo when building rust language
Hello, On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote: > The rust frontend requires cargo to build some of it's components, > it's presence was not checked during configuration. Isn't this creating a hen-and-egg problem? How am I supposed to build a Rust compiler for a target which is not supported by rustc (yet) when gccrs is supposed to build-depend on cargo which requires rustc? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Rust front-end patches v4
On 12/6/22 12:40, Arthur Cohen wrote: Can't wait to see this becoming available in the distributions :D. I will make sure we get the frontend enabled in Debian as soon as possible. Haha, I appreciate the enthusiasm :) Please note however that despite the language being in, the compiler is still at an extremely early stage. We are still not able to properly compile Rust code in the version that we target, 1.49. Don't worry, I'm fully aware of that. However, I still consider the inclusion of gccrs into the main gcc code a major step forward as it means the code is exposed to a much broader audience which means it will see more testing. Since Matthias Klose is regularly uploading gcc snapshots to Debian unstable, the gccrs will be compiled and testrun on more than 20 architectures ;-). And I will report back every issue that is discovered this way. To do anything meaningful with the language, you will also need the core library, which again, we cannot compile yet in its 1.49 version. No worries. This is very much an extremely experimental compiler and will still get a lot of changes in the coming weeks and months up until the release. And I'm looking forward to that. Again, thanks everyone for this fantastic effort! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Rust front-end patches v4
On 12/6/22 12:40, Arthur Cohen wrote: Can't wait to see this becoming available in the distributions :D. I will make sure we get the frontend enabled in Debian as soon as possible. Haha, I appreciate the enthusiasm :) Please note however that despite the language being in, the compiler is still at an extremely early stage. We are still not able to properly compile Rust code in the version that we target, 1.49. Don't worry, I'm fully aware of that. However, I still consider the inclusion of gccrs into the main gcc code a major step forward as it means the code is exposed to a much broader audience which means it will see more testing. Since Matthias Klose is regularly uploading gcc snapshots to Debian unstable, the gccrs will be compiled and testrun on more than 20 architectures ;-). And I will report back every issue that is discovered this way. To do anything meaningful with the language, you will also need the core library, which again, we cannot compile yet in its 1.49 version. No worries. This is very much an extremely experimental compiler and will still get a lot of changes in the coming weeks and months up until the release. And I'm looking forward to that. Again, thanks everyone for this fantastic effort! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Rust front-end patches v4
On 12/6/22 12:03, Richard Biener via Gcc-rust wrote: On Tue, Dec 6, 2022 at 11:11 AM wrote: This patchset contains the fixed version of our most recent patchset. We have fixed most of the issues noted in the previous round of reviews, and are keeping some for later as they would otherwise create too many conflicts with our updated development branch. Similarly to the previous round of patches, this patchset does not contain any new features - only fixes for the reviews of the v3. New features will follow shortly once that first patchset is merged. Once again, thank you to all the contributors who made this possible and especially to Philip Herron for his dedication to the project. Thanks a lot - this is OK to merge now, thanks for your patience and I'm looking forward for the future improvements. Woohooo, finally. Congratulations to everyone involved in this massive effort and thanks a lot for this huge step forward for the Rust community. Can't wait to see this becoming available in the distributions :D. I will make sure we get the frontend enabled in Debian as soon as possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Rust front-end patches v4
On 12/6/22 12:03, Richard Biener via Gcc-rust wrote: On Tue, Dec 6, 2022 at 11:11 AM wrote: This patchset contains the fixed version of our most recent patchset. We have fixed most of the issues noted in the previous round of reviews, and are keeping some for later as they would otherwise create too many conflicts with our updated development branch. Similarly to the previous round of patches, this patchset does not contain any new features - only fixes for the reviews of the v3. New features will follow shortly once that first patchset is merged. Once again, thank you to all the contributors who made this possible and especially to Philip Herron for his dedication to the project. Thanks a lot - this is OK to merge now, thanks for your patience and I'm looking forward for the future improvements. Woohooo, finally. Congratulations to everyone involved in this massive effort and thanks a lot for this huge step forward for the Rust community. Can't wait to see this becoming available in the distributions :D. I will make sure we get the frontend enabled in Debian as soon as possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Difference between 32-bit SPARCv9 and SPARCv8+?
Hi Eric! On 1/23/22 10:18, Eric Botcazou wrote: >> Is this intentional? If yes, what is the exact difference between V8+ and >> 32-bit V9? > > V8+ requires the full 64-bit registers to be preserved by the kernel, whereas > 32-bit V9 does not. OK, thanks for the clarification. Asking on top of that: Is it possible to configure gcc on sparc* with -mv8plus enabled by default? There seems to be only an option for setting the default value for -mcpu=, but -mv8plus doesn't seem to be supported as a default baseline in configure. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Difference between 32-bit SPARCv9 and SPARCv8+?
Hi! On 1/21/22 15:00, John Paul Adrian Glaubitz wrote: > While playing around with the compiler options trying to find a solution, I > made an interesting > discovery which is that GCC support 64-bit compare and swap on SPARCv8plus > but not on 32-bit > SPARCv9: > > glaubitz@gcc202:~$ echo | gcc -mv8plus -E -dM -|grep -i SWAP > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 > glaubitz@gcc202:~$ echo | gcc -mcpu=v9 -m32 -E -dM -|grep -i SWAP > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 > #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 > glaubitz@gcc202:~$ It gets even more confusing since on Solaris, gcc will actually support 64-bit atomic operations when setting -mcpu=v9: sysadmin@deimos:~$ echo | gcc -m32 -mcpu=v9 -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 sysadmin@deimos:~$ Does anyone know the reasoning behind this? Adrian PS: Please CC me, I'm not subscribed. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Difference between 32-bit SPARCv9 and SPARCv8+?
Hello! I'm currently trying to solve a problem in LLVM which arises when building the compiler-rt library on 32-bit SPARC [1]. More specifically, I'm getting a linker error which indicates that the target does not 64-bit atomic operations natively and has to use libatomic: /usr/bin/ld: warning: -z gnu-version-script-compat ignored /usr/bin/ld: projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.sparc.dir/sanitizer_libignore.cpp.o: in function `bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint64_t>(__sanitizer::atomic_uint64_t volatile*, __sanitizer::atomic_uint64_t::Type*, __sanitizer::atomic_uint64_t::Type, __sanitizer::memory_order)': /var/lib/buildbot/workers/debian-stadler-sparc64/clang-sparc64-linux-multistage/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h:80: undefined reference to `__sync_val_compare_and_swap_8' While playing around with the compiler options trying to find a solution, I made an interesting discovery which is that GCC support 64-bit compare and swap on SPARCv8plus but not on 32-bit SPARCv9: glaubitz@gcc202:~$ echo | gcc -mv8plus -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 glaubitz@gcc202:~$ echo | gcc -mcpu=v9 -m32 -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 glaubitz@gcc202:~$ Is this intentional? If yes, what is the exact difference between V8+ and 32-bit V9? Thanks, Adrian > [1] https://github.com/llvm/llvm-project/issues/53337 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Merge from GCC upstream into GCC/Rust
Hi Philipp! On 9/24/21 13:20, Philip Herron wrote: > Thanks for reaching out to continue helping with this Adrian, what is it > like building on some of your systems, does it take a long time? > > It would be nice to track this in some kind of built matrix, would you be > interested in carving out a wiki page over on > https://github.com/Rust-GCC/gccrs/wiki? Or do you have any other ideas? Sure, if you want a matrix with build times, I can create one. I'm currently on vacation and could work on that next week. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Merge from GCC upstream into GCC/Rust
Hi Thomas! On 9/24/21 10:30, Thomas Schwinge wrote: > As for checking that the configurations that you're testing are still > fine, would you like to do (and/or fix) that before or after me pushing > the merge? I'm fine with testing after the merge and I'll report issues as they show up. Thanks for asking! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable sh4
Hi Philip! On 6/11/21 1:25 PM, Philip Herron wrote: >> Nice! Thanks for your efforts, Adrian! >> > > This is pretty neat, what was it like to compile GCC on that board? It's an older board made in the early 2000s, so it has only 600 MHz which meant building gccrs took a little longer. It's the same architecture as used in the Sega Saturn and Sega Dreamcast. FWIW, the J-Core project is working on open source reimplementations of the SuperH architecture which is why this architecture still has a future despite Hitachi/Renesas having lost interest in favor of ARM. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable sh4
Hi! Just built revision ff4715d79e2c17d270db8b94315aa6b574f48994 on Debian unstable sh4 (SuperH) on my Renesas SH-7785LCR evaluation board. Testsuite passes without any issues, attaching the full log. CC'ing two SuperH-related mailing list in case someone is interested. Adrian === rust tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /srv/glaubitz/gccrs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /srv/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ... Running /srv/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ... Running /srv/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ... Running /srv/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ... === rust Summary === # of expected passes2415 # of expected failures 15 make[2]: Leaving directory '/srv/glaubitz/gccrs/build/gcc' make[1]: Leaving directory '/srv/glaubitz/gccrs/build/gcc' -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-sh4.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable m68k
-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 3 blank line(s) in output FAIL: rust/compile/torture/methods2.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: rust/compile/torture/methods3.rs -O0 (internal compiler error) FAIL: rust/compile/torture/methods3.rs -O0 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -O0 (test for excess errors) FAIL: rust/compile/torture/methods3.rs -O1 (internal compiler error) FAIL: rust/compile/torture/methods3.rs -O1 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -O1 (test for excess errors) FAIL: rust/compile/torture/methods3.rs -O2 (internal compiler error) FAIL: rust/compile/torture/methods3.rs -O2 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -O2 (test for excess errors) FAIL: rust/compile/torture/methods3.rs -O3 -g (internal compiler error) FAIL: rust/compile/torture/methods3.rs -O3 -g 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -O3 -g (test for excess errors) FAIL: rust/compile/torture/methods3.rs -Os (internal compiler error) FAIL: rust/compile/torture/methods3.rs -Os 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -Os (test for excess errors) FAIL: rust/compile/torture/methods3.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: rust/compile/torture/methods3.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: rust/compile/torture/methods3.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: rust/compile/torture/methods3.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 3 blank line(s) in output FAIL: rust/compile/torture/methods3.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) Running /glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ... Running /glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ... === rust Summary === # of expected passes2412 # of unexpected failures105 # of expected failures 15 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-m68k.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable hppa
Hi! Just built revision 325ef69b132819b824ae757695d9724e503f7256 on Debian unstable hppa. Testsuite passes without any issues, attaching the full log. CC'ing the hppa GCC, Kernel and Debian maintainers. Adrian === rust tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/glaubitz/gccrs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ... === rust Summary === # of expected passes2368 # of expected failures 26 make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc' make[1]: Leaving directory '/home/glaubitz/gccrs/build/gcc' -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-hppa.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
arm_arch8_5 and arm_arch8_6 target baselines in arm.c
Please keep me CC'ed as I'm currently not subscribed! Hi! I'm currently fixing some minor portability issues in gccrs and stumbled over the following error [1] which indicates a reference to an ARMv8 target extension in the ARM backend which doesn't seem to exist: ../../gcc/config/arm/arm-rust.c:204:9: error: 'arm_arch8_5' was not declared in this scope; did you mean 'arm_arch8_4'? 204 | if (arm_arch8_5) | ^~~ | arm_arch8_4 ../../gcc/config/arm/arm-rust.c:206:9: error: 'arm_arch8_6' was not declared in this scope; did you mean 'arm_arch8_4'? 206 | if (arm_arch8_6) | ^~~ | arm_arch8_4 Looking at gcc/config/arm.c, the highest level of ARMv8 that is supported in the ARM backend is 8.4, not 8.5 and 8.6 [2]: /* Nonzero if this chip supports the ARM Architecture 8.2 extensions. */ int arm_arch8_2 = 0; /* Nonzero if this chip supports the ARM Architecture 8.3 extensions. */ int arm_arch8_3 = 0; /* Nonzero if this chip supports the ARM Architecture 8.4 extensions. */ int arm_arch8_4 = 0; /* Nonzero if this chip supports the ARM Architecture 8.1-M Mainline extensions. */ int arm_arch8_1m_main = 0; /* Nonzero if this chip supports the FP16 instructions extension of ARM Architecture 8.2. */ int arm_fp16_inst = 0; Does anyone know whether the ARM backend is supposed to support the ARMv8.5 and ARMv8.6 baselines or are these only present in the Aarch64 backend? If the latter applies, I can just delete the two if statements in arm-rust.c. Thanks, Adrian > [1] https://github.com/Rust-GCC/gccrs/issues/483 > [2] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm.c#L919 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GCC Rust monthly call
On 6/4/21 12:54 PM, Philip Herron wrote: > I think my email with the time is not very clear which doesn't help. I will > maybe copy how the risc-v guys put their status report call email out with > examples of timezones and the simple UTC time. > > Have a great day, The next one will be 2nd of July 2021, these meetings are > on the first Friday of the month. Noted, thanks. See you hopefully next time. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: GCC Rust monthly call
On 6/4/21 12:47 PM, Philip Herron wrote: > For those interested, you find the meeting notes of our call over on: > https://github.com/Rust-GCC/Reporting/blob/main/2021-06-04-community-call.md Ah, dang, I missed the call. I somehow thought it would be in the evening :|. Next time then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable sparc64
Hi! Just built revision 324dfb828cec09f7638b48b6e25e4007b45b9cbc on Debian unstable sparc64. Testsuite passes without any issues, attaching the full log. Adrian === rust tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/glaubitz/gccrs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ... === rust Summary === # of expected passes2368 # of expected failures 26 make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc' make[1]: Leaving directory '/home/glaubitz/gccrs/build/gcc' -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-sparc64.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable aarch64
Hi Phil! On 6/3/21 1:58 PM, Philip Herron wrote: > I just had a thought it would be nice if we could keep a matrix of > different platforms gccrs has been tested on, and they could have states of: > > 1. Build Failure > 2. Test Failures link to log > 3. Tests pass, no unexpected results > > What if we maintained a section in the wiki for this? Sounds like a great idea. I think another idea would be to set up Travis which has support for a couple of architectures such as aarch64 and ppc64le. I'm not planning to keep repeating this manual build and testsuite runs, but I just want to get familiar with the project and fix some minor portability issues while I'm at it. I'm also particularly interested to see how well gccrs already works on various architectures. Getting Rust to work on more targets is very important for Debian as we have some architectures which are currently falling behind due to the lack of platform support in rustc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable aarch64
Hi! Just built revision 324dfb828cec09f7638b48b6e25e4007b45b9cbc on Debian unstable aarch64. Testsuite passes without any issues, attaching the full log. Adrian === rust tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/glaubitz/gccrs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ... === rust Summary === # of expected passes2368 # of expected failures 26 make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc' make[1]: Leaving directory '/home/glaubitz/gccrs/build/gcc' -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-aarch64.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Incorrect linker paths for building gcc on 32-bit PowerPC
ecDivide':
../../../libgcc/../libdecnumber/decBasic.c:626:7: warning: array subscript -1
is outside array bounds of 'uint8_t[47]' {aka 'unsigned char[47]'}
[-Warray-bounds]
626 | *(num.msd-1)=0; /* in case of left carry, or make 0
*/
| ^~~~
../../../libgcc/../libdecnumber/decBasic.c:184:10: note: while referencing
'bcdacc'
184 | uByte bcdacc[(DIVOPLEN+1)*9+2]; /* for quotient in BCD, +1, +1 */
| ^~
make[2]: Leaving directory
'/home/glaubitz/gccrs/build/powerpc-unknown-linux-gnu/libgcc'
make[1]: *** [Makefile:13143: all-target-libgcc] Error 2
make[1]: Leaving directory '/home/glaubitz/gccrs/build'
make: *** [Makefile:944: all] Error 2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Test results for gccrs on Debian unstable ia64
Hi Marc! On 6/2/21 7:02 PM, Marc wrote: >> libunwind on ia64 can be a bit tricky sometimes, so it might not be gccrs >> which is to be blamed here. > > Ah, sorry, already opened :). I'll close it if needed ! > > https://github.com/Rust-GCC/gccrs/issues/474 Let's keep it open for the time being so it doesn't fall off the table. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable s390x
]: Leaving directory '/home/glaubitz/gccrs/build/gcc' -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-s390x.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
Hi Marc! On 6/2/21 6:58 PM, Marc wrote: > Thanks for testing this! IIUC, this is an issue on our side, so I'll > open an issue. Let me test a plain GCC build with just C and C++ first to make sure it's not a general GCC problem on ia64. libunwind on ia64 can be a bit tricky sometimes, so it might not be gccrs which is to be blamed here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
Hello! On 6/2/21 3:08 PM, John Paul Adrian Glaubitz wrote: >> Is libunwind installed ? Not sure why your exe needs it, maybe that's a >> particularity of ia64? > > Yes, gcc explicitly needs libunwind on ia64 unless it's configured to use > the internal version. I might be able to fix that myself. Addendum: Building with "--with-system-libunwind" fixes the problem for me (see below). Adrian === rust tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/glaubitz/gccrs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/glaubitz/gccrs/gcc/testsuite/rust.test/compile/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust.test/execute/execute.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust.test/unsupported/unsupported.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust.test/xfail_compile/xfail_compile.exp ... === rust Summary === # of expected passes2368 # of expected failures 26 make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc' make[1]: Leaving directory '/home/glaubitz/gccrs/build/gcc' -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
Hi Marc! On 6/2/21 3:05 PM, Marc wrote: >> Sure, just found the log file. Didn't know that there was one ;). > > Thanks! Looks like something is missing : > > ./block_expr1.exe: error while loading shared libraries: libunwind.so.7: > cannot open shared object file: No such file or directory Ah, yes, libunwind ;-). > Is libunwind installed ? Not sure why your exe needs it, maybe that's a > particularity of ia64? Yes, gcc explicitly needs libunwind on ia64 unless it's configured to use the internal version. I might be able to fix that myself. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable ppc64 (big-endian)
Hi! Trying to build revision fd9e53249c6c269e68f9aca71b3d17b3ecee8e8a on 64-bit PowerPC (big-endian) succeeds. The testsuite passes without any issues. Attaching the log file, quick summary below: === rust tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/glaubitz/gccrs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ... Running /home/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ... === rust Summary === # of expected passes2368 # of expected failures 26 make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc' make[1]: Leaving directory '/home/glaubitz/gccrs/build/gcc' Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-ppc64.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Test results for gccrs on Debian unstable ia64
Hi Marc! On 6/2/21 2:41 PM, Marc wrote: >> # of expected passes2347 >> # of unexpected failures21 >> # of expected failures 26 > > Would it be possible to have the corresponding .log file ? Looks like > nearly all execution tests are KO (3 out of 4...). Sure, just found the log file. Didn't know that there was one ;). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 rust-ia64.log.gz Description: application/gzip -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Test results for gccrs on Debian unstable powerpc (failure)
Hi! Trying to build revision fd9e53249c6c269e68f9aca71b3d17b3ecee8e8a on 32-bit PowerPC fails with: g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include \ -o build/genpreds.o ../../gcc/genpreds.c In file included from ./tm.h:32, from ../../gcc/genpreds.c:26: ../../gcc/config/rs6000/linux.h:63:3: error: #error "TARGET_RUST_OS_INFO already defined in linux.h (rs6000) - c++ undefines it and redefines it." 63 | # error "TARGET_RUST_OS_INFO already defined in linux.h (rs6000) - c++ undefines it and redefines it." | ^ ../../gcc/config/rs6000/linux.h:65: warning: "TARGET_RUST_OS_INFO" redefined 65 | #define TARGET_RUST_OS_INFO() \ | In file included from ./tm.h:31, from ../../gcc/genpreds.c:26: ../../gcc/config/rs6000/sysv4.h:554: note: this is the location of the previous definition 554 | #define TARGET_RUST_OS_INFO() \ | make[2]: *** [Makefile:2833: build/genpreds.o] Error 1 make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc' make[1]: *** [Makefile:4415: all-gcc] Error 2 make[1]: Leaving directory '/home/glaubitz/gccrs/build' make: *** [Makefile:944: all] Error 2 Reported as [1]. Adrian > [1] https://github.com/Rust-GCC/gccrs/issues/468 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [Ping] AVR CC0 conversion
Hi! On 4/29/21 7:27 AM, Senthil Kumar Selvaraj wrote: > I guess it depends on the scope of the PR? If it was about removing cc0, > then this patch would do. If it was about getting the generated code > also to be as close to what it was with cc0, then no, it cannot be closed. I see. > OTOH, while the second patch (adjusting peepholes) does help, there are > other things in the pipeline - addition of new CC modes and enabling > compare elimination, adjusting rtx costs etc. I will continue to work on > them in my spare time and submit patches when ready. I would then suggest to get the second patch committed as well, then close the bug report and claim your bounty. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Ping] AVR CC0 conversion
On 4/28/21 7:59 PM, Senthil Kumar Selvaraj wrote: >>> OK for trunk. >> >> Anything else that keeps us from merging the changes? Would be great to >> have the last backend besides CR-16 finally converted to MODE_CC on trunk. > > Nope. Committed and pushed just now - > https://gcc.gnu.org/git?p=gcc.git;a=commit;h=3ba781d3b5c8efadb60866c9743b657e8f0eb222 Awesome \o/. Should we wait for the second patch [1] to be merged as well before closing the PR? [2] Adrian > [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568659.html > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Ping] AVR CC0 conversion
Hi Senthil! > On Mon, Apr 26, 2021 at 9:20 AM Senthil Kumar Selvaraj via Gcc-patches > wrote: >> >> Hi, >> >> This is >> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html, >> rebased against latest gcc master. The only change is modification of >> avr_md_asm_adjust's signature to match the extra input_modes parameter >> that TARGET_MD_ASM_ADJUST gained. >> >> I re-ran regression tests for atmega128, atxmega128a3, attiny40 and >> atmega8 (after applying >> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563779.html >> also) and verified that the results matched the original patchset. > > OK for trunk. Anything else that keeps us from merging the changes? Would be great to have the last backend besides CR-16 finally converted to MODE_CC on trunk. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)
Hello! >> I'd ask the original author, but it seems he's busy with other work, so to >> avoid delays... > > Please try to ask him first? That is always nice, but you all also need > to figure out what to do with the bounty. Going through the messages in this thread, my suggestion would be to pick Senthil's conversion as it apparently has no regressions as reported by Dimitar [1]. Since the largest share of the bounty was donated by Atmel/Microchip, there might be a conflict of interest as Senthil works for them from what I have seen on his homepage. If claiming the bounty should be a problem in this case, I would suggest that Senthil donates the money for a good cause or maybe puts the money on a different Bountysource campaign to either benefit GCC (I'm sure there are enough other areas that could see some love) itself or another open source project. Either way, the money is awarded to the individual who did the heavy lifting and it's important that we keep it that way. Otherwise, there is a risk that future potential contributors will refrain from picking up the task from such a Bountysource campaign if there is a reduced chance for them to claim such a bounty. After all, the whole idea of Bountysource is to delegate tasks that the community is interested to being worked on to skilled developers who are willing to spend a lot of their free time and to give them a small financial reward in return. Normally, buying developer time for such extensive tasks is way more expensive, so the community should appreciate anyone willing to do such work for a comparably little amount of money. For what it's worth, there are certainly more tasks coming in the future, so I'd recommend everyone interested in claiming a bounty regularly checking Bountysource.com (Disclaimer: I'm not affiliated with them, I just chose them because the seem to be the most popular site) or similar campaign sites for such offers. Thanks, Adrian > [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updating the backend status for h8300 on the wiki
On 12/7/20 9:06 AM, Eric Botcazou wrote: >> Now there are only AVR and CR16 that need to be converted. Great progress! > > Indeed, but why does CR16 not have the 'c' letter then? I noticed that as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updating the backend status for h8300 on the wiki
Hi Jeff! On 11/30/20 8:22 PM, Jeff Law wrote: > I also took care of updating cris and mn103 status WRT cc0. Attached is > what was pushed to the gcc-wwwdocs trunk. Now that VAX has been converted as well, the entry can be updated here as well. Now there are only AVR and CR16 that need to be converted. Great progress! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updating the backend status for h8300 on the wiki
Hi! Now that h8300 has been converted to use MODE_CC, it might be a good idea to update the documentation on the wiki [1] which still lists h8300 as being cc0. Adrian > [1] https://gcc.gnu.org/backends.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Re: Registers used for exception handling on Linux/m68k?
On 10/1/20 2:46 PM, Nathan Sidwell wrote: > Aha! it is EH_RETURN :) and it appears stack adjustment is something > different. > > for x86, gcc has: > #define EH_RETURN_DATA_REGNO(N) ((N) <= DX_REG ? (N) : INVALID_REGNUM) > > thus N can either be AX_REG or DX_REG. (which is eax/rax and edx/rdx > depending on compilation mode) > > for m68k gcc has: > #define EH_RETURN_DATA_REGNO(N) \ > ((N) < 2 ? (N) : INVALID_REGNUM) > > so that's registers d0 and d1 > > I'm guessing EHPersonality:CoreCLR is a different ABI that you're not > concerned with. Yeah, it also seems to be present in the X86 backend only (at least not in the Sparc backend). > Thus I think you want: > > getExceptionPointerRegister to return d0 and getExceptionSelectorRegister to > return d1. > > give that a go, and see if you can throw/catch exceptions between code > compiled by your llvm port and a gcc Perfect, thanks. > hope that helps. I'll give it a try. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Re: Registers used for exception handling on Linux/m68k?
Hi Nathan!
Thanks for the explanations!
On 10/1/20 2:27 PM, Nathan Sidwell wrote:
> do you know what those 2 functions you mention provide on say x86? Then it
> might be easier to map onto 68k.
>From [1]:
Register X86TargetLowering::getExceptionPointerRegister(
const Constant *PersonalityFn) const {
if (classifyEHPersonality(PersonalityFn) == EHPersonality::CoreCLR)
return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
return Subtarget.isTarget64BitLP64() ? X86::RAX : X86::EAX;
}
Register X86TargetLowering::getExceptionSelectorRegister(
const Constant *PersonalityFn) const {
// Funclet personalities don't use selectors (the runtime does the selection).
assert(!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn)));
return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
}
Adrian
> [1]
> https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Re: Registers used for exception handling on Linux/m68k?
Hi Nathan! On 9/29/20 7:58 PM, Nathan Sidwell wrote: > On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote: >> >> I'm looking for an information regarding exception handling on Linux/m68k, >> in particular >> I need to know what registers are used by the ABI in order to implement the >> functions >> "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the >> M680x0 backend >> in LLVM [1], [2]. > > I don;t know what those functions are, but from their names they seem to be > related to figuring out the exception object and type? I think so. I'm not a compiler expert hence my questions :-). > Do you understand the itanium ABI's unwinding mechanism -- > 1) follow stack to get to landing pad. > 2) invoke landing pad to see if it wants to catch > 3) if not, continue following stack > 4) once we've found one to catch it, we need to unwind properly, which > involves invoking cleanups. and eventually getting to the catcher > > invoking the landing pad means passing (a) an integer telling it what's > happening, and (b) a pointer to data. This seems to be the data that I need. I just need to understand how that works. >> I looked into the GCC source code to find the corresponding parts but I >> could only find >> the macros prefixed with "EH_" [4] which I didn't fully understand. > > Those are the bits you want. one of those is the selector (0?) and the other > is the data pointer (1?). OK. But aren't they passed through particular registers on m68k? Or is this something specific to LLVM? Thanks for the help! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Registers used for exception handling on Linux/m68k?
Hello! I'm looking for an information regarding exception handling on Linux/m68k, in particular I need to know what registers are used by the ABI in order to implement the functions "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the M680x0 backend in LLVM [1], [2]. I looked into the GCC source code to find the corresponding parts but I could only find the macros prefixed with "EH_" [4] which I didn't fully understand. Can any of the experienced GCC/m68k folks tell me which registers in [5] I need to use? Adrian > [1] https://github.com/M680x0/M680x0-mono-repo/issues/15 > [2] > https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/Sparc/SparcISelLowering.h#L107 > [3] > https://github.com/llvm/llvm-project/blob/ee34d9b210cb5a6d14fe069e2e2ae75b0548dba9/llvm/lib/Target/Sparc/SparcRegisterInfo.td#L151 > [4] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68k/m68k.h#L741 > [5] > https://github.com/M680x0/M680x0-mono-repo/blob/master/llvm/lib/Target/M680x0/M680x0RegisterInfo.td -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] m68k: tag floating-point ABI used
Hello! > Tag the floating-point calling convention used on m68k-elf (either hard-float > or soft-float) through the GNU assembler attribute. The use of the tag enables > the linker to ensure linked objects use a consistent floating-point ABI and > allows tools like GDB to infer the ABI used from the ELF file. It is based on > similar work done for PowerPC. > > The patch has been tested for m68k-elf and x86-64/Linux. Since tagging is only > enabled when the m68k assembler supports GNU attributes, this patch can be > applied independently from the corresponding binutils patch. > > If approved, I'll need a maintainer to commit on my behalf. This seems like a useful enhancement to the m68k backend. Any chance it can be picked up? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] m68k: tag floating-point ABI used
Hello! > Tag the floating-point calling convention used on m68k-elf (either hard-float > or soft-float) through the GNU assembler attribute. The use of the tag enables > the linker to ensure linked objects use a consistent floating-point ABI and > allows tools like GDB to infer the ABI used from the ELF file. It is based on > similar work done for PowerPC. > > The patch has been tested for m68k-elf and x86-64/Linux. Since tagging is only > enabled when the m68k assembler supports GNU attributes, this patch can be > applied independently from the corresponding binutils patch. > > If approved, I'll need a maintainer to commit on my behalf. This seems like a useful enhancement to the m68k backend. Any chance it can be picked up? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bountysource campaign for AVR backend now at $7,150
Hello! I just got a notification that the Bountysource campaign I created to modernize the AVR backend - primarily converting it to MODE_CC - has been bumped to $7,150 by Microchip [1]. I hope this will finally convince someone to complete the task :-). Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bountysource campaign for AVR backend now at $7,150
Hello! I just got a notification that the Bountysource campaign I created to modernize the AVR backend - primarily converting it to MODE_CC - has been bumped to $7,150 by Microchip [1]. I hope this will finally convince someone to complete the task :-). Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AVR CC0 transition
Hi! On 5/25/20 2:56 PM, John Paul Adrian Glaubitz wrote: >> I'm thinking about attempting to do the CC0 transition for the >> AVR port in my spare time. I've read the CC0Transition gcc wiki >> page, and as the AVR ISA does not have non-condition-code >> clobbering arithmetic instructions, concluded that I'd have to >> follow the steps outlined for case #2. > > If you are working on it, it might be a good idea to log in to > Bountysource.com > and mark the issue as being worked on [1], so you can get the bounty in case > the conversion has been successful. Important update: Bountysource has announced that they will let bounties expire in the future if not claimed after two years [1]. So, unless someone claims the money with the next two years, the money will be gone. It would therefore be good for anyone working on the AVR MODE_CC conversion (Senthil?) that they submit a claim for this bounty [2] after the patches to convert the AVR backend have been accepted upstream. It would be a shame if the money would be taken by Bountysource in the end. If the developer who submits the claim, cannot take the money for legal reasons (i.e. because worked on it during company time), I would suggest donating the money to a good cause. The same applies to the campaign for the VAX backend [3]. Adrian > [1] https://news.ycombinator.com/item?id=23551098 > [2] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [3] > https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AVR CC0 transition
Hello! > I'm thinking about attempting to do the CC0 transition for the > AVR port in my spare time. I've read the CC0Transition gcc wiki > page, and as the AVR ISA does not have non-condition-code > clobbering arithmetic instructions, concluded that I'd have to > follow the steps outlined for case #2. If you are working on it, it might be a good idea to log in to Bountysource.com and mark the issue as being worked on [1], so you can get the bounty in case the conversion has been successful. Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bountysource campaign for converting the VAX backend
Hi! The NetBSD VAX porters have shown interest in a Bountysource campaign for their GCC backend [1], so I created one [2]. The backend can be tested with the help of the SimH emulator, see [3, 4]. Adrian > [1] http://mail-index.netbsd.org/port-vax/2020/04/16/msg003460.html > [2] > https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [3] http://mail-index.netbsd.org/port-vax/2020/04/18/msg003481.html > [4] http://www.netbsd.org/ports/vax/emulator-howto.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
On 5/9/20 12:31 PM, Arseny Solokha wrote: > I'd also like to nominate the following two: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 > > which I also cannot close myself. There won't be any further revisions of this > list by me. They affect given older versions, so if you just close them, that would imply that the bug in question in gcc-4.5.3 has been dealt with - which I assume is not the case. So, again, I'm not sure what you gain by closing these bugs. Having them marked as open means that someone has observed the issue with a certain gcc version and target. Moving it to "closed" just expresses that some people don't care about this bug anymore. But it doesn't change the fact that the bug still exists. The only thing you gain by closing such bugs is that you are reducing the number of open bug reports and you can somehow claim you fixed a bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
On 5/9/20 10:31 AM, Jonathan Wakely wrote: > If you mean for PR reasons or good apeparances, no. But it's wrong to > have bugs left open that only refer to unsupported versions of GCC. If > none of the supported releases has the bug (either because it's been > fixed, or the relevant code has been removed) then the bug should be > closed. > > If the bug is still present in supported versions (like gcc-8 or > gcc-9) but will never be fixed (like SPE ones) they might as well be > closed now as WONTFIX. Suggesting anything else will happen to them is > misleading. If you don't accept my opinion, why did you ask for it in the first place. Please do whatever you want. I will still continue to contribute to GCC and start BountySource campaigns to support, despite my opinion not being of any relevance. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
Hi! On 5/9/20 12:15 AM, Segher Boessenkool wrote: > I can do both, if you want, or just the first group? Your choice. > > But let's hear other opinions first. These bugs document the current issues with the backend as it existed in gcc-8 (or was it -9)? The bugs are still in the removed code, so I don't really understand what you gain by closing bugs? Is it important to keep the number of open issues low? I don't consider bug reports a bad thing, they document the code quality and are a useful resource to anyone working on the code or using these versions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bountysource campaign for converting AVR to MODE_CC
Hi! Just as a reminder, we still have a Bountysource campaign for the AVR backend running in case someone is looking for an opportunity to make a little money while working on GCC [1]. The campaign has not been as successful as the campaign for m68k [2] but there is still a chance that we might get some more donations if we spread the word. But maybe someone is interested nonetheless to work on the AVR backend as a little sideline. Thanks, Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [2] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Regression on 32-bit powerpc?
On 3/5/20 9:11 AM, Jakub Jelinek wrote: > On Thu, Mar 05, 2020 at 08:56:37AM +0100, John Paul Adrian Glaubitz wrote: >> The latest gcc-10 snapshot in Debian fails to build in Debian with: > > What is the problem? > All that is present in what you posted are warnings. Okay, I was confused by the "internal error: builtin function %qs already processed". >> Full log in: >> https://buildd.debian.org/status/fetch.php?pkg=gcc-10=powerpc=10-20200304-1=1583386777=0 > > And here it shows the buildbox was OOMed. Yeah, I suspected that as well, but I wanted to make sure which is why I asked. Thanks for the confirmation. > That might or might not be a GCC problem, guess it depends on how much > memory it actually needs and if it isn't excessive compared to other > targets. I have rescheduled the build now. Normally we haven't OOMs with GCC on 32-bit PowerPC. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Regression on 32-bit powerpc?
ot;\"%s\": ", key); // FIXME: escaping? | ^~ ../../src/gcc/json.cc:73:27: warning: unquoted sequence of 2 consecutive punctuation characters '":' in format [-Wformat-diag] 73 | pp_printf (pp, "\"%s\": ", key); // FIXME: escaping? | ^~~ ../../src/gcc/json.cc:73:30: warning: spurious trailing space in format [-Wformat-diag] 73 | pp_printf (pp, "\"%s\": ", key); // FIXME: escaping? | ^ ../../src/gcc/json.cc:73:23: warning: unterminated quote character '"' in format [-Wformat-diag] 73 | pp_printf (pp, "\"%s\": ", key); // FIXME: escaping? | ^~ /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/powerpc-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/include/powerpc-linux-gnu -I/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DBASEVER="\"10.0.1\"" -DDATESTAMP="\" 20200304\"" -DREVISION="\" [master revision 0b0908c1f27:cb0a7e0ca53:94f7d7ec6ebef49a50da777fd71db3d03ee03aa0]\"" -DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(Debian 10-20200304-1) \"" -DBUGURL="\"\"" -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o version.o -MT version.o -MMD -MP -MF ./.deps/version.TPo ../../src/gcc/version.c ../../src/gcc/pretty-print.c: In function 'void pp_begin_url(pretty_printer*, const char*)': ../../src/gcc/pretty-print.c:2179:21: warning: unquoted control character '\x1b' in format [-Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\", url); | ^~~ ../../src/gcc/pretty-print.c:2179:24: warning: unbalanced punctuation character ']' in format [-Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\", url); |^ ../../src/gcc/pretty-print.c:2179:26: warning: unquoted sequence of 2 consecutive punctuation characters ';;' in format [-Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\", url); | ^~ ../../src/gcc/pretty-print.c:2179:30: warning: unquoted control character '\x1b' in format [-Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\", url); | ^~~ ../../src/gcc/pretty-print.c:2179:33: warning: spurious trailing punctuation sequence '\' in format [-Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\", url); | ^~ ../../src/gcc/pretty-print.c:2182:21: warning: unquoted control character '\x1b' in format [-Wformat-diag] 2182 | pp_printf (pp, "\33]8;;%s\a", url); | ^~~ ../../src/gcc/pretty-print.c:2182:24: warning: unbalanced punctuation character ']' in format [-Wformat-diag] 2182 | pp_printf (pp, "\33]8;;%s\a", url); |^ ../../src/gcc/pretty-print.c:2182:26: warning: unquoted sequence of 2 consecutive punctuation characters ';;' in format [-Wformat-diag] 2182 | pp_printf (pp, "\33]8;;%s\a", url); | ^~ ../../src/gcc/pretty-print.c:2182:30: warning: unquoted control character '\x07' in format [-Wformat-diag] 2182 | pp_printf (pp, "\33]8;;%s\a", url); | ^~ Full log in: https://buildd.debian.org/status/fetch.php?pkg=gcc-10=powerpc=10-20200304-1=1583386777=0 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bountysource campaign for gcc-rust?
Hi! On 12/27/19 12:26 AM, John Paul Adrian Glaubitz wrote: > For this reason, people have been asking for a Rust frontend for GCC similar > to > the one for Go. Now, there are actually two independent implementation of a > Rust > frontend for GCC [1, 2] being developed and I was wondering whether it would > be > desirable to help this development with a Bountysource campaign? I have now created a campaign on BountySource.com after I received positive feedback on this mailing list: > https://www.bountysource.com/issues/86138921-rfe-add-a-frontend-for-the-rust-programming-language Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bountysource campaign for gcc-rust?
Hello! The programming language Rust has become very popular over the past few years with many projects rewriting parts of their codebase in that language. While these rewrites often make the code perform faster and potentially safer, using Rust makes these projects less portable as Rust is limited to the architectures supported by LLVM which are less than the ones supported by GCC. For this reason, people have been asking for a Rust frontend for GCC similar to the one for Go. Now, there are actually two independent implementation of a Rust frontend for GCC [1, 2] being developed and I was wondering whether it would be desirable to help this development with a Bountysource campaign? I'm asking because I'm not sure whether GCC upstream would be okay having a Rust frontend in GCC at all and, if yes, it would be okay to have a Bountysource campaign for that project? I personally like the idea of a Rust frontend for GCC very much as I expect more software projects in the future to adopt Rust and I would like to be able to build and use these projects on architectures that LLVM doesn't support yet (and might not even in the future). Due to the popularity of Rust and the desire of the community for an independent implementation, I expect the Bountysource campaign to be rather successful. Thanks, Adrian > [1] https://github.com/redbrain/gccrs > [2] https://github.com/sapir/gcc-rust/tree/rust -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AW: [PATCH] m68k architecture: support ccmode + lra
Hi Stefan! > The problems are in the gcc implementation > > - the lra implementation is buggy > - the compare elimination can't handle parallel's containing a compare > - df-core considers parallel's containing a compare also as a USE > - some optimizations/mechanisms do only work if HAVE_CC0 is defined > - way more ... Are you talking about GCC in general or about the m68k backend? In any case, I would appreciate it if you could file bug reports where you are seeing issues and put me in the CC of these bug reports. > And the current implementation is IMHO unusable for lra since it did not > introduce a CC register to track clobbering. So it's a dead end. I assume you are talking about Bernd's m68k cc0 transition? We are planning to have another Bountysource campaign for the m68k backend to fund the LRA transition and - if necessary - fix other bugs in the backend, so constructive feedback is necessary and absolutely welcome. On every bug that is documented in GCC Bugzilla, we can put a bounty if necessary. > I can live with the fact that my patch was refuted since I simply use > my *working* fork, where I fixed the issues mentioned above. I would prefer getting all bugs in GCC reported to the GCC Bugzilla so that they can be resolved in GCC itself. We don't gain anything if important bug fixes are found in forks only. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AW: [PATCH] m68k architecture: support ccmode + lra
Hi! On 12/13/19 4:06 PM, Oleg Endo wrote: >> What are the combine2 patches? > > See the other thread that I've linked in my message. I don't see any patch there. >> And I would support switching SH to LRA as >> there are a few cases (Debian packages) where GCC fails with an internal >> compiler error which I reported to the GCC bugzilla. > > Have you tried rebuilding debian on/for SH with -mlra enabled for > *everything*? Do you have an easy way of doing that? It would be > interesting to see how it goes. Yes, that would be possible. We would have to enable -mlra in gcc by default and then trigger a rebuild for 10.000 source packages. But that would take a while to finish. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AW: [PATCH] m68k architecture: support ccmode + lra
Hello Segher! > With LRA, sh builds fine (with the combine2 patches). I have no idea > if correct code is generated, but it doesn't ICE anymore. What are the combine2 patches? And I would support switching SH to LRA as there are a few cases (Debian packages) where GCC fails with an internal compiler error which I reported to the GCC bugzilla. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
BountySource campaign for the cc0 transition of the AVR backend
Hi! Since we were successful with the BountySource campaign to convert the M68K backend from cc0 to MODE_CC [1], I have now started a second BountySource campaign which aims to achieve the same thing for the AVR backend [2]. The corresponding bug in Bugzilla is #92729 [3]. Let's see how it goes :). Adrian > [1] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [2] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/4] The main m68k cc0 conversion
Hi Bernd! On 11/26/19 2:44 AM, Bernd Schmidt wrote: > I overlooked a difference in the 68881 vs coldfire patterns when I > combined them. They use different suffixes for register compares (I only > spotted the different constraints). > > The following seems to fix the assembler failures. I cannot properly > test Coldfire however due to lack of hardware. Angelo Dureghello (CC'ed) does active kernel development work on ColdFire and he might be able to help with testing on the platform. He also created two open-source ColdFire SBCs [1, 2]. I do have multiple ColdFire boards myself, but they are currently not set up and it would take me some time to get them running as I have never used them before. Adrian > [1] http://sysam.it/cff_amcore.html > [2] http://sysam.it/cff_stmark2.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/4] The main m68k cc0 conversion
On 11/25/19 3:40 PM, Segher Boessenkool wrote: > On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote: >> Thanks for the m68k work! Can you also update >> https://gcc.gnu.org/backends.html ? > >> PS: I wonder whether some other archs also should be updated on that web >> page. > > Possibly. Probably? > > But, do you have any particular suggestions? For m68k, it should be added that a free simulator is available as qemu has gained full emulation support for m68k as compared to the previous ColdFire-only emulation, i.e. the question mark in the "S" column should be removed. Same applies to i386, s390 and tilegx. These are all supported by qemu. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/4] The main m68k cc0 conversion
On 11/25/19 1:38 PM, Bernd Schmidt wrote: > On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote: >> Are all 4 + 2 patches in now? Thus, can we close the bug? > > We're missing one piece for better autoinc generation, but that's a > small optimization issue. The cc0 conversion is complete. Great. I have clicked "Accept" in Bountysource and hope the remaining backers will, too. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/4] The main m68k cc0 conversion
Hi Bernd! On 11/25/19 1:33 PM, Bernd Schmidt wrote: > On 11/23/19 6:36 PM, Jeff Law wrote: > >> Not really. I've already indicated to Bernd that he should go ahead and >> commit the changes and we can iterate on any problems that arise. > > After the last fix, I did some more testing and since I feel confident > that it really is in good shape now, I committed it. Thanks! Are all 4 + 2 patches in now? Thus, can we close the bug? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/4] The main m68k cc0 conversion
there's objections over the next say 48-72 hrs, let's get the > kit in and we can iterate if there's further issues that need resolving. Any news on this? I would be in favor of merging these patches as I have tested them successfully on Debian by building the gcc-snapshot package with the patches applied. I used all four patches plus the additional one required to be able to build the kernel. I did not see the bootstrap problems that Mikael reported and Andreas has reported that the issues is not reliably reproducible on Aranym. He suspected that it might be a bug in the MMU emulation in Aranym which only triggers randomly depending on the current memory layout. I have used a patched gcc-10 to build the Debian kernel (package version 5.3.9-3) and it builds fine. The kernel also boots without any problems on my Amiga 4000 with 68060/50 accelerator and 128 MB RAM. So, I think we should get the patches merged so we have a chance to extensively test them in Debian with the help of the gcc-snapshot package that gets regularly updated in Debian. I will report any bugs that I am running into. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 0/4] Eliminate cc0 from m68k
Hi Bernd! This should work: # binary default deb http://ftp.ports.debian.org/debian-ports/ unstable main deb http://incoming.ports.debian.org/buildd/ unstable main deb http://ftp.ports.debian.org/debian-ports/ unreleased main # source deb-src http://ftp.debian.org/debian/ unstable main deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main The two lines starting with incoming are optional. They will just help getting newly built packages faster. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 0/4] Eliminate cc0 from m68k
Hi Andreas! > === g++ Summary === > > # of expected passes26803 > # of unexpected failures16 > # of expected failures 82 > # of unsupported tests 157 > /daten/aranym/gcc/gcc-20191116/Build/gcc/xg++ version 10.0.0 20191115 > (experimental) [trunk revision 278320] (GCC) Is this testsuite run with or without Bernd's patches? If yes, I think it would be a good sign that the patches are good for submission. I will try to get the patches backported to gcc-9 so that we can start building Debian packages with a patched gcc-9 which may help finding more regressions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 0/4] Eliminate cc0 from m68k
Hi! On 11/15/19 2:45 PM, John Paul Adrian Glaubitz wrote: >> It works on the kernel build, at least. No idea if this *runs*, I just >> built it ;-) > > I just did that and kernel 5.3.9 built with gcc trunk with Bernd's patches > boots fine on qemu-m68k-system. I will test the kernel on a real Amiga > later but I'm confident it will work there as well. Kernel built with the patched gcc-10 also boots fine on my Amiga 4000 68060 :). I'm test building various packages now to see if I can see any other issues but so far I'm very confident that there are no obvious regressions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 0/4] Eliminate cc0 from m68k
Hi Segher! > It works on the kernel build, at least. No idea if this *runs*, I just > built it ;-) I just did that and kernel 5.3.9 built with gcc trunk with Bernd's patches boots fine on qemu-m68k-system. I will test the kernel on a real Amiga later but I'm confident it will work there as well. Thanks to everyone, especially Bernd for helping to make the cc0 transition for m68k happen! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: BountySource campaign for gcc PR/91851
On 10/31/19 10:00 PM, Georg-Johann Lay wrote: >>> I didn't follow the lists for some time... At least neither v9 or v10 >>> release notes caveats mention such deprecation, neither is there >>> respective PRs for the cc0 targets. >> >> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html >> >> Peter > > Ah, thanks. > > So finally, the time has come to move to clang/llvm ? Not quite. Motorola 68k is currently not officially supported by LLVM/Clang. There is a port that is half-finished though [1] and there is also one guy from Czech Republic who wrote a Bachelor thesis on an m68k backend for LLVM [2]. I have not been able to contact him though as his university address bounces. I would love to see the code that was written there. I have also played around with Rust on m68k based on the LLVM code on [1], but it doesn't really work yet. I think finishing LLVM for m68k would be another idea for a Bountysource campaign. Adrian > [1] https://github.com/M680x0/M680x0-llvm/ > [2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902 > [3] https://github.com/glaubitz/rust/tree/m68k-linux -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Deprecating cc0 (and consequently cc0 targets)
On 10/30/19 6:52 PM, Gunther Nikl wrote: > Richard Sandiford wrote: >> FWIW it's already possible to do the transform you mention with: >> >> s/(cc0)/(reg:CC CC_REGNUM_RC)/g >> >> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")]) > > Since "reload_completed" is referenced, this is only about the CC0 > conversion, right? Switching to LRA is not required for this step. I think it would be nice though that anyone who does the cc0 transition would also switch over to LRA unless that would be too much of a burden. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Deprecating cc0 (and consequently cc0 targets)
Hi Jeff!! On 10/29/19 8:34 PM, Jeff Law wrote: >> Any chance that the unfinished code can be shared? I'm looking for any >> blueprints that can be used as a guidance for the work on the m68k >> backend. > I'm not sure it'd be all that useful. The v850 bits would be a better > starting point. The partial H8 transition isn't committed anywhere > because it would certainly break the port. I confused the H8 backend with the V850 backend, sorry for that. I have realized later that the V850 backend is the one where the conversion has been completed. > I'll walk you through one example from the H8 port. This isn't complete > enough to even test that it builds. (...) > This is where we describe (via the mode of the condition code register) > what condition codes are set and how to extract them. These patterns > can be added incrementally. But again, it's going to be a ton of work. Thanks for the detailed explanation. I will be going through this over the weekend trying to understand the details. > My son is definitely still interested. But I doubt he'd likely be able > to take up the task until the spring/summer of 2020. Additionally, > there's some question of whether or not him doing the work could be > viewed as a conflict of interest WRT the bug bounty because of his > relationship to me. I don't think there is a conflict of interest in any way. It's perfectly fine to pick up the task yourself and receive the bounty. The community doesn't really care who gets the job done. And since I don't assume your employer is paying you to work on the m68k backend, it's absolutely okay in my opinion to be paid for the task, time isn't free, especially developer time. It's very valuable to everyone in the various m68k communities to have an up-to-date version of GCC available which is why so many people have donated for the cause. Thanks a lot for your time and input! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Deprecating cc0 (and consequently cc0 targets)
Hello! On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law wrote: >So this message is serving as official notice that we are *deprecating* >all cc0 support in gcc-10. We are not removing any code or targets at >this time -- removals would happen during the gcc-11 cycle. > > >avr >cris >h8300 >m68k >vax >cr16 > >This is based on actually looking at the backend patterns. >backends.html indicates the mn103 port would be affected, but I think >it's just out-of-date. Similarly it fails to mention cr16, but cr16 >clearly has affected patterns (I'll address that separately) > >This patch deprecates the affected targets. With some magic folks can >continue to build them. However, if nobody steps forward to convert >them from cc0 to MODE_CC those targets will be removed during the >gcc-11 >cycle. We have raised $5000 to support anyone willing to work on this for the m68k target [1]. We really need the m68k to stay as it's essential to be able to compile for Linux/m68k, NetBSD/m68k and AROS/m68k (a new and ABI-compatible AmigaOS clone). I'm sure other communities like in the NeXTStep, Atari and Mac/m68k forums are interested in keeping the backend as well. I'm confident we will be able to raise even more money as the community is large and active. >If someone is interested in possibly doing a conversion, I would >strongly recommend reviewing the best documentation we have on the >subject: > >https://gcc.gnu.org/wiki/CC0Transition > >I worked with my son about a year ago to transition the v850 to MODE_CC >using that page as a guideline. We also have a partial transition for >the H8/300 port (not far enough to even build anything yet). I had >hoped we would finish the H8/300 port last year and would have tackled >another, but events have gotten in the way. Any chance that the unfinished code can be shared? I'm looking for any blueprints that can be used as a guidance for the work on the m68k backend. I have also created a guide on how to set up a QEMU virtual machine running a fully fledged Debian/m68k which can be used for the development work [2]. >The transition isn't terribly hard, but does take time because of the >number of patterns that have to be changed. I have already looked at the conversion done on the V850 backend [3] but so far I don't understand enough of the register representation stuff to be able to know where to start. I'm seeing that all the "cc" attributes are being removed but not replaced? Adrian > [1] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [2] https://wiki.debian.org/M68k/QemuSystemM68k > [3] > https://github.com/gcc-mirror/gcc/commit/d6c5e987e730b3b2b9ff396d2361518ff9cb5e23 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
BountySource campaign for gcc PR/91851
Hello! For anyone who isn't aware of it yet, there is an ongoing BountySource campaign for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that it can be kept in gcc versions beyond version 11. The campaign is currently at $3,290 and can be found at [2]. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 > [2] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
gcc Testsuite Results - was: Re: [PATCH] Deprecate ia64*-*-*
Hi! I just stumbled over [1] and just wanted to add that Debian is reguarly building snapshots of all current gcc versions for a large number of targets, including the testsuites (except for m68k and sh4 at the moment). The results can always be found on buildd.debian.org. gcc-7: https://buildd.debian.org/status/package.php?p=gcc-7=sid gcc-8: https://buildd.debian.org/status/package.php?p=gcc-8=sid gcc-9: https://buildd.debian.org/status/package.php?p=gcc-9=sid gcc-snapshot: https://buildd.debian.org/status/package.php?p=gcc-snapshot=sid So gcc is tested regularly on ia64 and co and it's actively being used to build the whole Debian archive. Thanks, Adrian [1] https://gcc.gnu.org/ml/gcc/2019-06/msg00158.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Deprecation of powerpc*-*-*spe*
Hi Jakub! As has been discussed in the https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01227.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00810.html threads and in https://gcc.gnu.org/PR81084 the powerpc*-*-*spe* support which has been split into a separate backend hasn't been given enough maintainance and so is deprecated in GCC 8. I'm surprised that these topics are hardly ever discussed with downstream projects like Debian. I am maintaining powerpcspe in Debian and the port is very stable for us. There are people running the port on embedded PowerPC e500 systems like A-EON Tabor A1222 or the powerpc-based Turris router so killing off gcc support would mean that these people can no longer run an updated version of Debian on their machines. I also don't know why the port is considered to be broken. I haven't run the testsuite for binutils or gcc recently, true, but gcc-8 works just fine on powerpcspe and is actually the only current compiler we have since the powerpcspe support in LLVM is incomplete. Here's the build log of gcc-8 (20180402) built natively on PowerPC e500 just two weeks ago: https://buildd.debian.org/status/fetch.php?pkg=gcc-8=powerpcspe=8-20180402-1=1522856967=0 Is there anything in the powerpcspe port that is currently making life for the users or developers of other code harder? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2] libgo: Add support for sh
On 01/10/2018 04:22 PM, Ian Lance Taylor wrote: Ok, so basically we should end up having only two GOARCHes for SH, being "sh" and "shbe", correct? Yes, I would like to start there. If, yes, I can rebase my patch, make the requested changes and resubmit it to Gerrit. Thanks! Done: https://go-review.googlesource.com/c/gofrontend/+/84555 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2] libgo: Add support for sh
On 01/10/2018 03:51 PM, Ian Lance Taylor wrote: I suppose I shouldn't have said calling convention, as that cuts too finely. There are similar issues with MIPS and even x86 has softfloat variants. Those options are selectable via command line options in GCC, and in the gc toolchain they are selected using environment variables (GO386, GOARM, etc.). Ok, so basically we should end up having only two GOARCHes for SH, being "sh" and "shbe", correct? If, yes, I can rebase my patch, make the requested changes and resubmit it to Gerrit. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2] libgo: Add support for sh
On 01/10/2018 03:40 PM, Ian Lance Taylor wrote: The main purpose of a GOARCH value is to specify build targets, which are the +build lines seen in files like libgo/go/internal/syscall/unix/getrandom_linux_mipsx.go. They also appear in file names. It seems to me unlikely that it will ever be necessary to distinguish SH3 and SH4 when choosing which files to build. What about Oleg's comment on the issue? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2] libgo: Add support for sh
On 01/10/2018 03:25 PM, Ian Lance Taylor wrote: Thanks. I finally took a look at this. I don't know much about SH, but I don't think we want to add each SH variant as a separate GOARCH value. As you can see from the list you modified in ibgo/go/go/build/syslist.go, the difference between GOARCH values is essentially the calling convention. There are many different kinds of x86 processors, but since the only calling convention difference is between 32-bit and 64-bit, the list has only 386 and amd64. Similarly it seems to me we should have only sh and shbe in the list for SH processors. My reasoning is that gcc itself differentiates between those different SH targets, i.e. there is a sh3, a sh4 target and the big-endian variants of these targets. There aren't different x86_64 targets in gcc though. Furthermore, as you can see, sh3 and sh4 also have different cacheline sizes, for example: https://go-review.googlesource.com/c/gofrontend/+/84555/1/libgo/configure.ac In total, we have four different SH targets. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH v2] libgo: Add support for sh
Hello! This is the second version of my patch to add support for SuperH in libgo. The changes over my first patch in [1] are: * account for little- and big-endian targets * account for sh3- and sh4-specific parameters I have not added support for SH-1 and SH-2 targets for now as most Linux distributions with SH support usually target sh3 and sh4 only. I have already signed the Google CLA in the past when I contributed a small patch to Kubernetes. Thanks, Adrian > [1] https://gcc.gnu.org/ml/gcc-patches/2017-12/msg0.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From ce83430f1a8d34f005f46208e4c8ab22ad00c879 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> Date: Sat, 16 Dec 2017 10:05:20 +0100 Subject: [PATCH] 2017-12-17 John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> PR go/83308 * libgo/configure.ac: Add support for sh3, sh3be, sh4, sh4be. * libgo/go/go/build/syslist.go: Add sh3, sh3be, sh4, sh4be to goarchList. * libgo/go/cmd/cgo/main.go: Enable build on sh3, sh3be, sh4, sh4be. * libgo/go/runtime/hash32.go: Likewise. * libgo/go/runtime/lfstack_32bit.go: Likewise. * libgo/go/runtime/unaligned2.go: Likewise. * libgo/go/syscall/endian_big.go: Enable build on sh3be, sh4be. * libgo/go/syscall/endian_little.go: Enable build on sh3, sh4. * libgo/match.sh: Add architecture matching for sh3, sh3be, sh4, sh4be. * libgo/testsuite/gotest: Likewise. --- ChangeLog | 14 ++ libgo/configure.ac| 34 -- libgo/go/cmd/cgo/main.go | 8 libgo/go/go/build/syslist.go | 2 +- libgo/go/runtime/hash32.go| 2 +- libgo/go/runtime/lfstack_32bit.go | 2 +- libgo/go/runtime/unaligned2.go| 2 +- libgo/go/syscall/endian_big.go| 2 +- libgo/go/syscall/endian_little.go | 2 +- libgo/match.sh| 4 ++-- libgo/testsuite/gotest| 4 ++-- 11 files changed, 64 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index 275a340f6a8..18c3cfe0743 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2017-12-17 John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> + + PR go/83308 + * libgo/configure.ac: Add support for sh3, sh3be, sh4, sh4be. + * libgo/go/go/build/syslist.go: Add sh3, sh3be, sh4, sh4be to goarchList. + * libgo/go/cmd/cgo/main.go: Enable build on sh3, sh3be, sh4, sh4be. + * libgo/go/runtime/hash32.go: Likewise. + * libgo/go/runtime/lfstack_32bit.go: Likewise. + * libgo/go/runtime/unaligned2.go: Likewise. + * libgo/go/syscall/endian_big.go: Enable build on sh3be, sh4be. + * libgo/go/syscall/endian_little.go: Enable build on sh3, sh4. + * libgo/match.sh: Add architecture matching for sh3, sh3be, sh4, sh4be. + * libgo/testsuite/gotest: Likewise. + 2017-12-12 Stafford Horne <sho...@gmail.com> * configure.ac: Remove logic adding gdb to noconfigsdirs for or1k. diff --git a/libgo/configure.ac b/libgo/configure.ac index 7b0c629653f..63cd857c23f 100644 --- a/libgo/configure.ac +++ b/libgo/configure.ac @@ -208,10 +208,10 @@ AC_SUBST(USE_DEJAGNU) # supported by the gofrontend and all architectures supported by the # gc toolchain. # N.B. Keep in sync with gcc/testsuite/go.test/go-test.exp (go-set-goarch). -ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mips mipsle mips64 mips64le mips64p32 mips64p32le ppc ppc64 ppc64le s390 s390x sparc sparc64" +ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mips mipsle mips64 mips64le mips64p32 mips64p32le ppc ppc64 ppc64le s390 s390x sh3 sh3be sh4 sh4be sparc sparc64" # All known GOARCH_FAMILY values. -ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 PPC PPC64 S390 S390X SPARC SPARC64" +ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 PPC PPC64 S390 S390X SH SPARC SPARC64" GOARCH=unknown GOARCH_FAMILY=unknown @@ -360,6 +360,36 @@ GOARCH_MINFRAMESIZE=8 GOARCH_CACHELINESIZE=256 GOARCH_PCQUANTUM=2 ;; + sh3eb*-*-*) +GOARCH=sh3be +GOARCH_FAMILY=SH +GOARCH_BIGENDIAN=1 +GOARCH_CACHELINESIZE=16 +GOARCH_PCQUANTUM=2 +GOARCH_MINFRAMESIZE=4 +;; + sh3*-*-*) +GOARCH=sh3 +GOARCH_FAMILY=SH +GOARCH_CACHELINESIZE=16 +GOARCH_PCQUANTUM=2 +GOARCH_MINFRAMESIZE=4 +;; + sh4eb*-*-*) +GOARCH=sh4be +GOARCH_FAMILY=SH +GOARCH_BIGENDIAN=1 +GOARCH_CACHELINESIZE=32 +GOARCH_PCQUANTUM=2 +GOARCH_MINFRAMESIZE=4 +;; + sh4*-*-*) +GOARCH=sh4 +GOARCH_FAMILY=SH +GOARCH_CACHELINESIZE=32 +GOARCH_PCQUANTUM=2 +GOARCH_MINFRAMESIZE=4 +;; sparc*-*-*) AC_COMPILE_IFELSE([ #if defined(__sparcv9) || defined(__arch64__) diff --git a/libgo/go/cmd
Re: [PATCH] libgo: Add support for sh
On 12/16/2017 10:24 AM, John Paul Adrian Glaubitz wrote: > I'm not sure whether all the definitions in libgo/configure.ac are > correct for SuperH. I made the assumptions that the values are similar > for ARM 32-bit and SuperH as these architectures are comparable, except > that SH has always 16-bit instructions. According to the SuperH SH-4 CPU datasheet, the cacheline size is 32 bytes: > www.st.com/resource/en/user_manual/cd00147165.pdf (page 75) No idea about GOARCH_MINFRAMESIZE though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] libgo: Add support for sh
On 12/16/2017 10:24 AM, John Paul Adrian Glaubitz wrote: > The attached patch adds the necessary definitions to enable libgo > to build on sh (Hitachi SuperH). Forgot to mention: I can compile Go programs for SH with the patched gcc-7 which work fine on my Renesas SH7785LCR evaluation board running Debian unstable (sh4). The programs crash on qemu-sh4-user though but that's a limitation in QEMU. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH] libgo: Add support for sh
Hello!
The attached patch adds the necessary definitions to enable libgo
to build on sh (Hitachi SuperH).
Two remarks:
1.
I'm not sure whether all the definitions in libgo/configure.ac are
correct for SuperH. I made the assumptions that the values are similar
for ARM 32-bit and SuperH as these architectures are comparable, except
that SH has always 16-bit instructions.
2.
In order for the build to succeed, I had to adjust the signature of
ioctl() in libgo/go/exp/terminal/util.go to make the second parameter
"uint" instead of "int", see [1]. With this change, the signature also
matches the signature used on Linux [2] and FreeBSD [3].
Without the change, the build fails with an integer overflow:
./libtool: line 1143: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
../../../src/libgo/go/exp/terminal/util.go:70:23: error: integer constant
overflow
if ioctl(fd, syscall.TIOCGWINSZ, unsafe.Pointer()) < 0 {
^
Makefile:3342: recipe for target 'exp/terminal.lo' failed
Thanks,
Adrian
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308#c10
> [2] http://man7.org/linux/man-pages/man2/ioctl.2.html
> [3] https://www.freebsd.org/cgi/man.cgi?query=ioctl=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From a20d0d921734a94da1e72beff862091323534ce0 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Sat, 16 Dec 2017 10:05:20 +0100
Subject: [PATCH] 2017-12-16 John Paul Adrian Glaubitz
<glaub...@physik.fu-berlin.de>
PR go/83308
* libgo/configure.ac: Add autoconf definitions for sh.
* libgo/go/cmd/cgo/main.go: Enable build on sh.
* libgo/go/go/build/syslist.go: Likewise.
* libgo/go/runtime/hash32.go: Likewise.
* libgo/go/runtime/lfstack_32bit.go: Likewise.
* libgo/go/runtime/unaligned2.go: Likewise.
* libgo/go/syscall/endian_little.go: Likewise.
* libgo/testsuite/gotest: Likewise.
* libgo/match.sh: Add architecture matching for sh.
---
ChangeLog | 13 +
libgo/configure.ac| 7 +++
libgo/go/cmd/cgo/main.go | 2 ++
libgo/go/go/build/syslist.go | 2 +-
libgo/go/runtime/hash32.go| 2 +-
libgo/go/runtime/lfstack_32bit.go | 2 +-
libgo/go/runtime/unaligned2.go| 2 +-
libgo/go/syscall/endian_little.go | 2 +-
libgo/match.sh| 4 ++--
libgo/testsuite/gotest| 4 ++--
10 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 275a340f6a8..f6efeb3e809 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2017-12-16 John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
+
+PR go/83308
+* libgo/configure.ac: Add autoconf definitions for sh.
+* libgo/go/cmd/cgo/main.go: Enable build on sh.
+* libgo/go/go/build/syslist.go: Likewise.
+* libgo/go/runtime/hash32.go: Likewise.
+* libgo/go/runtime/lfstack_32bit.go: Likewise.
+* libgo/go/runtime/unaligned2.go: Likewise.
+* libgo/go/syscall/endian_little.go: Likewise.
+* libgo/testsuite/gotest: Likewise.
+* libgo/match.sh: Add architecture matching for sh.
+
2017-12-12 Stafford Horne <sho...@gmail.com>
* configure.ac: Remove logic adding gdb to noconfigsdirs for or1k.
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 7b0c629653f..65a9fb9c54e 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -360,6 +360,13 @@ GOARCH_MINFRAMESIZE=8
GOARCH_CACHELINESIZE=256
GOARCH_PCQUANTUM=2
;;
+ sh*-*-*)
+GOARCH=sh
+GOARCH_FAMILY=SH
+GOARCH_CACHELINESIZE=32
+GOARCH_PCQUANTUM=2
+GOARCH_MINFRAMESIZE=4
+;;
sparc*-*-*)
AC_COMPILE_IFELSE([
#if defined(__sparcv9) || defined(__arch64__)
diff --git a/libgo/go/cmd/cgo/main.go b/libgo/go/cmd/cgo/main.go
index c9a44fdd166..9c821db2d90 100644
--- a/libgo/go/cmd/cgo/main.go
+++ b/libgo/go/cmd/cgo/main.go
@@ -161,6 +161,7 @@ var ptrSizeMap = map[string]int64{
"ppc64le": 8,
"s390":4,
"s390x": 8,
+ "sh": 4,
"sparc": 4,
"sparc64": 8,
}
@@ -183,6 +184,7 @@ var intSizeMap = map[string]int64{
"ppc64le": 8,
"s390":4,
"s390x": 8,
+ "sh": 4,
"sparc": 4,
"sparc64": 8,
}
diff --git a/libgo/go/go/build/syslist.go b/libgo/go/go/build/syslist.go
index 290ba9efa0c..395dc8cd15a 100644
--- a/libgo/go/go/build/syslist.go
+++ b/libgo/go/go/build/syslist.go
@@ -5,4 +5,4 @@
package build
const goosList = "aix android darwin dragonfly freebsd linux nacl netbsd
Re: RFC: Support non-standard extension (call via casted function pointer)
On 01/28/2016 09:55 AM, Andreas Schwab wrote: > Richard Biener <richard.guent...@gmail.com> writes: > >> I think that's reasonable and what GHC expects - declare "there is a function >> foo defined, no idea what prototype yet", unfortunately C requires to specify >> a return type. > > Like void, f.ex. Wait. Do you think this would actually allow ghc to determine the return type later? If I remember correctly, ghc currently initially declares the function prototype with return type void*, doesn't it? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
On 01/26/2016 11:07 AM, Andreas Schwab wrote: > John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> writes: > >> Having gcc allow to work with such code would actually allow us >> to bootstrap ghc on m68k again which would be awesome :). > > The ghc code just needs to be fixed to not lie in such a blatant way. > Just like it was changed when ppc64le flagged this as crap code. I could just find one bug report which mentions a fix for ppc64el [1], are you talking about this one? If this bug is actually the same as the m68k bug, why is ghc still working fine on ppc64el? Does ppc64el actually have separate address and data registers? Adrian > [1] https://ghc.haskell.org/trac/ghc/ticket/8965 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
Hi Richard! On 01/26/2016 08:01 AM, Richard Biener wrote: >> I developed a gcc patch that does not change the code generation for >> conforming programs but fixes this non-conforming use-case by always >> taking the actual return type in the call expression into account, even >> if the function declaration to be called is known. Please comment >> whether such a patch has any chance to be applied to either gcc >> upstream >> or gcc in Debian. > > Without looking at the patch this is already how GCC should behave for all > targets. So, would you actually favor the inclusion of Michael's changes? Having gcc allow to work with such code would actually allow us to bootstrap ghc on m68k again which would be awesome :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
On 01/26/2016 12:07 PM, Andreas Schwab wrote: >> If this bug is actually the same as the m68k bug, > > Where did I say that? > The ghc code just needs to be fixed to not lie in such a blatant way. > Just like it was changed when ppc64le flagged this as crap code. ^ But I don't want to argue anyway. I was assuming ppc64le might have similarities to m68k in that regard. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
