gcc-14-20250516 is now available

[GCC Administrator via Gcc]

Snapshot gcc-14-20250516 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20250516/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-14 revision a9de71c2060339fcd56257e64e61af207b924e4c

You'll find:

 gcc-14-20250516.tar.xz   Complete GCC

  SHA256=04a5485c7c0fbfeaef7fa210860efa3b79cfe2e14840afc7484be6a3e6e1d8d2
  SHA1=a4521a6bee063b4dad0b746e070fadedbb77a2e1

Diffs from 14-20250509 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Question for maintainers: ARCv3 port feasibility

[Andrew Stubbs]

On 15/05/2025 17:55, Richard Biener wrote:

On Thu, May 15, 2025 at 6:43 PM Andrew Stubbs  wrote:


Dear GCC Maintainers and Steering Committee,

I'm currently doing a feasibility study and effort estimate for
upstreaming the existing ARCv3 out-of-tree port [1].

Question: Is there likely to be any objection to adding a new "arc64"
port in addition to the existing "arc" port?


I don't see any strong reason not to do this, assuming 'arc' is 32bit only
and 'arc64' is a 64bit CPU.  But I'd say the arc port maintainer should
weight in (CCed).


Claudiu is one of the original authors of the new port, but he no longer 
works for Synopsys so could not upstream it himself.



Technically the SC has to accept a new port I think.


That would be reassuring, if true.

Obviously, getting the quality level up to standard, and getting the 
legal requirements in order, are a required part of the project. As is 
finding someone to act as Maintainer.


Thanks for the reply.

Andrew

Re: Question for maintainers: ARCv3 port feasibility

[Andrew Stubbs]

On 16/05/2025 01:23, Paul Koning wrote:




On May 15, 2025, at 8:06 PM, Oleg Endo via Gcc  wrote:

Hi,

On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote:

Dear GCC Maintainers and Steering Committee,

I'm currently doing a feasibility study and effort estimate for
upstreaming the existing ARCv3 out-of-tree port [1].

Question: Is there likely to be any objection to adding a new "arc64"
port in addition to the existing "arc" port?

At this point, I would like to check that the general approach is likely
to be accepted at the end of the project. Or, at least not rejected for
this most fundamental of reasons.

The ARCv3 port has been written as a new backend because it is not just
a simple evolution of the ARC architecture and starting afresh made more
sense to the developers at the time.  I'm aware that there are some
precedents for this (sh64, ia64, aarch64), so I think it's probably
fine, right?



SH5/SH64 was actually part of the original SH port, not a separate
standalone port.  It made the port more complex and convoluted, but probably
made sense since the it was backwards compatible with the original SH ISA
(it was like ARM Thumb -- jump to select between classic SH ISA and new SH5
ISA, from what I remember).

Best regards,
Oleg Endo


Also: ia64 is a separate ISA.  If you were thinking about x86-64, that's part of i386 
("ia-32").  Similarly, "mips" is both flavors (and all four ABIs). So there are 
several examples in both directions.


Apparently I hallucinated the sh64 being a separate port, which is weird 
because I worked on that stuff (20 years ago). Probably it was separate 
in some other tool(?)


I'm aware that IA64 Itanium was "slightly" more different to IA32 than 
current x86_64 is, but still it kind of sits in this space.


Anyway, I don't think ARC/ARC64 is as different as IA32/IA64 but 
probably about the same amount of difference as Arm/AArch64. Unlike x86, 
you can't run v2 binaries on v3 hardware. I don't know the ISAs well, so 
I can't (yet) speak with authority on this point, but I'm very sure that 
(at this point) it'll be less work to keep arc64 independent, at least 
for GCC.


Andrew