Re: Deprecation/removal of nios2 target support

On 4/18/24 8:41 PM, Arnd Bergmann wrote: On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove support from all toolchain components after the release is made. I'm not sure ther

gcc-11-20240418 is now available

Snapshot gcc-11-20240418 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240418/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Youl

Sent from my iPhone

Re: Deprecation/removal of nios2 target support

On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote: > On Wed, 17 Apr 2024, Sandra Loosemore wrote: > >> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove >> support from all toolchain components after the release is made. I'm not >> sure >> there is an established process f

Re: Updated Sourceware infrastructure plans

On Thu, Apr 18, 2024 at 5:38 PM Frank Ch. Eigler wrote: > > Hi - > > > [...] I suggest that a basic principle for such a system is that it > > should be *easy* to obtain and maintain a local copy of the history > > of all pull requests. That includes all versions of a pull request, > > if it get

Re: Updated Sourceware infrastructure plans

On Thu, 18 Apr 2024, Frank Ch. Eigler via Gcc wrote: > Hi - > > > [...] I suggest that a basic principle for such a system is that it > > should be *easy* to obtain and maintain a local copy of the history > > of all pull requests. That includes all versions of a pull request, > > if it gets re

Re: Updated Sourceware infrastructure plans

Hi - > [...] I suggest that a basic principle for such a system is that it > should be *easy* to obtain and maintain a local copy of the history > of all pull requests. That includes all versions of a pull request, > if it gets rebased, and all versions of comments, if the system > allows editin

Re: Deprecation/removal of nios2 target support

On 4/18/24 10:06, Jeff Law wrote: ACK.  Just one more note to the wider audience.  I looked at QEMU's user mode support for nios2 on/off over the last couple years.  It never seemed to work well enough be able to run the GCC testsuite reliably. I looked at the problems with the nios2 user-mo

Re: Deprecation/removal of nios2 target support

On 4/18/24 9:57 AM, Joel Sherrill wrote: On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers > wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all toolchai

Re: Deprecation/removal of nios2 target support

On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers wrote: > On Wed, 17 Apr 2024, Sandra Loosemore wrote: > > > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > > support from all toolchain components after the release is made. I'm > not sure > > there is an established proce

Re: Updated Sourceware infrastructure plans

On Thu, 18 Apr 2024, Mark Wielaard wrote: > But we like to get more feedback on what people really think a > "pull-request" style framework should look like. We used to have a > gerrit setup which wasn't really popular. And we already have a > sourcehut mirror that can be used to turn your "pull-r

Re: Deprecation/removal of nios2 target support

On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all toolchain components after the release is made. I'm not sure > there is an established process for obsoleting/removing support in other > components; besides

Re: Deprecation/removal of nios2 target support

On 4/18/24 7:53 AM, Thomas Huth wrote: On 18/04/2024 05.27, Sandra Loosemore wrote: Tomorrow I plan to push patches to mark the nios2 target as obsolete in GCC 14. Background: Intel has EOL'ed the Nios II processor IP and is now directing their FPGA customers to a RISC-V platform instead. h

Re: Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

Am Donnerstag, dem 18.04.2024 um 14:01 +0200 schrieb Tobias Burnus: > Hi Janne, > > Janne Blomqvist wrote: > > back when I was active I did think about this > > issue. IMHO the best of my ideas was to convert these into C++ > > templates. I haven't looked at libgfortran but I didn't find it probl

Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

Hi Janne, Janne Blomqvist wrote: back when I was active I did think about this issue. IMHO the best of my ideas was to convert these into C++ templates. I think this will work – but we have to be super careful: With C++, there is the problem that we definitely do not want to add dependency o

Re: Updated Sourceware infrastructure plans

On Thu, Apr 18, 2024 at 11:15 AM FX Coudert wrote: > > > I regenerate auto* files from time to time for libgfortran. Regenerating > > them has always been very fragile (using --enable-maintainer-mode), > > and difficult to get right. > > I have never found them difficult to regenerate, but if you

Re: Updated Sourceware infrastructure plans

Hi, On Thu, 18 Apr 2024 at 10:15, FX Coudert wrote: > > > I regenerate auto* files from time to time for libgfortran. Regenerating > > them has always been very fragile (using --enable-maintainer-mode), > > and difficult to get right. > > I have never found them difficult to regenerate, but if yo

Re: Updated Sourceware infrastructure plans

> I regenerate auto* files from time to time for libgfortran. Regenerating > them has always been very fragile (using --enable-maintainer-mode), > and difficult to get right. I have never found them difficult to regenerate, but if you have only a non maintainer build, it is a pain to have to make