gcc-15-20250309 is now available
Snapshot gcc-15-20250309 is now available on https://gcc.gnu.org/pub/gcc/snapshots/15-20250309/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 15 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 7d3aec2a832ef47be547d9426187562e4548bae6 You'll find: gcc-15-20250309.tar.xz Complete GCC SHA256=8c41886d5b67b332317a997585511d5d7a2a0b93d863bdd390f5b0b055c2e9a5 SHA1=985c647b9e36bc0957d5678aa99c8382fc9d4dd0 Diffs from 15-20250302 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-15 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: What branch to use for the Algol 68 front-end
Hi Jose, On Sat, Mar 08, 2025 at 02:17:52PM +0100, Jose E. Marchesi wrote: > > Since you already have a fork on the (experimental) forge we could > > also move your fork under https://forge.sourceware.org/gcc that way > > you can experiment with merge requests if you like. Even if all your > > patches still go to the algol68 list first. > > I am all for continuing using the forge if it is useful for the > experiment. I think it would. Also I think it would be fun to have one of the oldest language frontends use the most modern development environments :) > Let's see. Right now the resources we are using are: > > Website: https://gcc.gnu.org/wiki/Algol68FrontEnd > Mailing list: algo...@gcc.gnu.org > Bugzilla: https://gcc.gnu.org/bugzilla > Git repo: https://forge.sourceware.org/jemarch/a68-gcc (branch a68) > > If I understand you suggestion right, we would simply move the git repo > to: > > https://forge.sourceware.org/gcc/algol68 (branch a68) Yes. To do that you should become a member/owner of the gcc organization. https://forge.sourceware.org/org/gcc An existing member/owner should be able to accept you. https://forge.sourceware.org/org/gcc/members Then you can move your repository/fork to the gcc organization by going to the existing repository Settings at https://forge.sourceware.org/jemarch/algol68/settings Scroll down to "Danger zone" and click on "Transfer ownership" The new owner would be gcc. It does need to be accepted by one of the gcc Owners. Now you can setup a Team inside the gcc organization of people who help maintain this repository. You can do this by either creating a list of colaborators or pick an existing gcc team at https://forge.sourceware.org/gcc/algol68/settings/collaboration (BTW. This would also be a good time to set the Default branch to a68.) > Then people could fork it, send patch series based on their forks to be > reviewed in the mailing list, get feedback, do corrections, rinse and > repeat. Then when the series has been OKed a PR can be made and the > maintainer just merges it. Is this the idea? Yes, that would be the traditional email workflow extended to the forge. Note that (very unforge like) you (the algol68 team members) can also directly push to the repository through ssh sidestepping creating a merge request if that is how you want to do things. > Is it possible to get emails sent to the mailing list when merges > happen, merge requests are issued, etc? People can get emails by clicking the "Watch" button on the repository. We could try creating a "fake" account that has the mailinglist as email address. But I am a little hesitant experimenting with "fake" users. It might be good if the owner of a repo could add an email address to the Watch list. Maybe this should be a new feature request to Forgejo. Cheers, Mark
Re: [RFC] RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1
On Mon, Mar 10, 2025 at 10:04 AM Fangrui Song wrote: > I am intrigued by the problem but I have trouble understanding the > description. What behavior does this patch change? > > > riscv64-unknown-linux-gnu-gcc test.c > -Wl,--unresolved-symbols=ignore-in-object-files > > There is no -nostdlib, therefore I assume that this command creates a > dynamically linked executable (both -fpie -pie and -fno-pie -no-pie > are possible, depending on how users configure the GCC). > Oops, that's true. I think the original problem is for -no-pie. > I've tested a few cases but do not observe a behavior difference (in > terms of whether `foo` is in .dynsym and whether there is a JUMP_SLOT > relocation). > > ld-new --unresolved-symbols=ignore-in-object-files -o a a.o b.so > ld-new --unresolved-symbols=ignore-in-object-files -o a a.o > % cat a.s .text .weak c .globl _start _start: call a call b call c % cat b.s .globl b b: nop % riscv64-unknown-linux-gnu-as a.s -o a.o % riscv64-unknown-linux-gnu-as b.s -o b.o % riscv64-unknown-linux-gnu-ld -shared b.o -o b.so % riscv64-unknown-linux-gnu-ld -unresolved-symbols=ignore-in-object-files a.o b.o % riscv64-unknown-linux-gnu-objdump -d a.out ... Disassembly of section .text: 000100b0 <_start>: 100b0: 0097 auipc ra,0x0 100b4: f50080e7 jalr -176(ra) # 0 <_start-0x100b0> 100b8: 00c000ef jal 100c4 100bc: 0097 auipc ra,0x0 100c0: 00e7 jalr zero # 0 <_start-0x100b0> 000100c4 : 100c4: 0013 nop % riscv64-unknown-linux-gnu-ld -unresolved-symbols=ignore-in-object-files a.o b.so % riscv64-unknown-linux-gnu-objdump -d a.out ... Disassembly of section .plt: ... 00010330 : 10330: 2e17 auipc t3,0x2 10334: cd0e3e03 ld t3,-816(t3) # 12000 10338: 000e0367 jalr t1,t3 1033c: 0013 nop 00010340 : 10340: 2e17 auipc t3,0x2 10344: cc8e3e03 ld t3,-824(t3) # 12008 10348: 000e0367 jalr t1,t3 1034c: 0013 nop 00010350 : 10350: 2e17 auipc t3,0x2 10354: cc0e3e03 ld t3,-832(t3) # 12010 10358: 000e0367 jalr t1,t3 1035c: 0013 nop Disassembly of section .text: 00010360 <_start>: 10360: ff1ff0ef jal 10350 10364: fcdff0ef jal 10330 10368: fd9ff0ef jal 10340 But before this patch, all undefined weak and non-weak symbols will be forced to zero, % riscv64-unknown-linux-gnu-ld-old -unresolved-symbols=ignore-in-object-files a.o b.so % riscv64-unknown-linux-gnu-objdump -d a.out ... Disassembly of section .plt: ... 00010330 : 10330: 2e17 auipc t3,0x2 10334: cd0e3e03 ld t3,-816(t3) # 12000 10338: 000e0367 jalr t1,t3 1033c: 0013 nop 00010340 : 10340: 2e17 auipc t3,0x2 10344: cc8e3e03 ld t3,-824(t3) # 12008 10348: 000e0367 jalr t1,t3 1034c: 0013 nop 00010350 : 10350: 2e17 auipc t3,0x2 10354: cc0e3e03 ld t3,-832(t3) # 12010 10358: 000e0367 jalr t1,t3 1035c: 0013 nop Disassembly of section .text: 00010360 <_start>: 10360: 0097 auipc ra,0x0 10364: ca0080e7 jalr -864(ra) # 0 <_PROCEDURE_LINKAGE_TABLE_-0x10310> 10368: fc9ff0ef jal 10330 1036c: 0097 auipc ra,0x0 10370: 00e7 jalr zero # 0 <_PROCEDURE_LINKAGE_TABLE_-0x10310> (lld has a quite simple model where undefined non-weak and undefined > weak symbols are handled in a unified way. > A symbol is preemptible if: > > * -shared or at least one input file is DSO, and > * the symbol is undefined or exported (to .dynsym due to > --export-dynamic/--dynamic-list/referenced by DSO/etc), and > * other conditions that the symbol is preemptible > > Then, a preemptible symbol might need a PLT and associated JUMP_SLOT > relocation.) > Yeah I think now the behavior is more similar to lld. Well, except the special handling for a call to undefined weak function, according to this page, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/126 I suddenly feel like we should also apply this special handling to the calls which jump to an undefined non-weak function... Thanks Nelson
[GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization
Hi here, I'm a Master of Computer Science student at the University of Melbourne. Previously, I worked on implementing a GCC optimization prefetching pass (which involved loop unrolling) for an Alpha-like computer architecture. I'm set to complete my research project in July and graduate soon. I'm very interested in applying for the 2025 GSoC project and discussing potential ideas with the community. However, I'm still unfamiliar with the best way to engage in these discussions and apply for the project, so this is my first attempt at reaching out. My primary interest is in projects related to auto-parallelization, particularly the Fortran *DO CONCURRENT* project. Below, I outline my initial understanding of the project and would appreciate any feedback from the community to ensure I'm on the right track: 1. The *front-end parser* processes the Fortran *DO CONCURRENT* syntax and converts it into a language-independent IR—*GIMPLE*. 2. The *middle-end* then applies tree optimizations, utilizing SSA passes to optimize the code for auto-parallelization. 3. This project will involve both *front-end* work (parser and parameterized command-line flags) and *middle-end* optimizations (optimization passes). Loop unrolling is influenced by multiple factors, such as loop nesting and whether iteration counts are deterministic. A significant performance gain comes from reducing array memory access delays, which techniques like prefetching can help with. Since *DO CONCURRENT* assumes iteration independence, we have more flexibility to unroll loops and implement parallelization efficiently. One of the most exciting advantages of this project is that it enables auto-parallelization for a broader range of code without requiring developers to be an OpenMP expert. *DO CONCURRENT* in Fortran is much easier to use, and previous auto-parallelization techniques have been quite limited in their applicability, as only specific loop structures could benefit from them. I look forward to engaging with the community and gaining insights on how best to contribute to this project. Best regards, Chenlu Zhang
Re: [RFC] RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1
On Thu, Mar 6, 2025 at 7:05 PM Nelson Chu wrote:
>
> Committed, thanks.
>
> Nelson
>
> On Mon, Mar 3, 2025 at 11:51 AM Nelson Chu wrote:
>>
>> Looks like we could give it a try and see if it works and won't affect
>> current projects. I will commit it before this weekend if there are no
>> objections.
>>
>> Thanks
>> Nelson
>>
>> On Tue, Feb 11, 2025 at 1:53 AM Palmer Dabbelt wrote:
>>>
>>> On Sat, 08 Feb 2025 00:33:37 PST (-0800), Nelson Chu wrote:
>>> > I got an request about the undefined behaviors, considering the following
>>> > case,
>>> >
>>> > $ cat test.c
>>> > void main ()
>>> > {
>>> > foo();
>>> > }
>>> > $ cat lib.h
>>> > void foo(void);
>>> > $ riscv64-unknown-linux-gnu-gcc test.c
>>> > riscv64-unknown-linux-gnu/bin/ld: /tmp/ccRO8fJl.o: in function `main':
>>> > test.c:(.text+0x8): undefined reference to `foo'
>>> > collect2: error: ld returned 1 exit status
>>> > $ riscv64-unknown-linux-gnu-gcc test.c
>>> > -Wl,--unresolved-symbols=ignore-in-object-files
>>> > $ qemu-riscv64 a.out
>>> > Segmentation fault (core dumped)
>>> >
>>> > Testing with x86 and aarch64, they won't get the segfault since they go
>>> > plt
>>> > for the undefined foo symbol. So, after applying this patch, I can get
>>> > the
>>> > following too,
>>> >
>>> > $ qemu-riscv64 a.out
>>> > a.out: symbol lookup error: a.out: undefined symbol: foo
>>> >
>>> > The change of this patch should only affect the call behavior, which refer
>>> > to an undefined (weak) symbol, when building an dynamic executable. I
>>> > think
>>> > the pic/pie behavior won't be affected as usual. I am not sure if the
>>> > change
>>> > will cause trouble or not for other projects, so please feels free to cc
>>> > people
>>> > that you think they will be affected, thanks.
>>>
>>> Thanks for doing this. For some more context, there's a handful of Go
>>> plugins that seem to want `-Wl,--export-dynamic
>>> -Wl,--unresolved-symbols=ignore-in-object-files` to result in
>>> executables that have PLT-indirect calls to these undefined symbols,
>>> which they'll then later LD_PRELOAD or dlopen() to resolve. Here's an
>>> example
>>> .
>>>
>>> IMO that's pretty far into the realm of undefined behavior, and from
>>> poking around a bit it looks like that's the case even on x86 --
>>> basically if my symbol gets linked before something has triggered a PLT
>>> to be created, then I end up with a direct reference that isn't
>>> dynamically resolvable.
>>>
>>> It also looks like arm64 generates NOPs (rather than calls to absolute
>>> 0) on these undefined symbols, so it's possible some instances of these
>>> are just crashing lazily. THere might be some context floating around
>>> in 7cd2917227 ("aarch64: Return an error on conditional branch to an
>>> undefined symbol"), it's a bit hard to follow so I'm not sure if that's
>>> an intentional side-effect or just the easiest arbitrary thing to
>>> generate for this flavor of undefined behavior.
>>>
>>> So I'm kind of split on what we should do here: in general I like to
>>> have undefined behavior crash eagerly, as otherwise we're just making
>>> these issues harder to debug. That said, this has blown up internally
>>> and making it crash lazily will make the fire go out, and it'd be really
>>> nice to start a Monday morning with more fires going out than
>>> starting...
>>>
>>> Maybe there's some more context floating around in someone's brain about
>>> this?
>>>
>>> > ---
>>> > bfd/elfnn-riscv.c | 84 +--
>>> > 1 file changed, 44 insertions(+), 40 deletions(-)
I am intrigued by the problem but I have trouble understanding the
description. What behavior does this patch change?
> riscv64-unknown-linux-gnu-gcc test.c
> -Wl,--unresolved-symbols=ignore-in-object-files
There is no -nostdlib, therefore I assume that this command creates a
dynamically linked executable (both -fpie -pie and -fno-pie -no-pie
are possible, depending on how users configure the GCC).
I've tested a few cases but do not observe a behavior difference (in
terms of whether `foo` is in .dynsym and whether there is a JUMP_SLOT
relocation).
ld-new --unresolved-symbols=ignore-in-object-files -o a a.o b.so
ld-new --unresolved-symbols=ignore-in-object-files -o a a.o
(lld has a quite simple model where undefined non-weak and undefined
weak symbols are handled in a unified way.
A symbol is preemptible if:
* -shared or at least one input file is DSO, and
* the symbol is undefined or exported (to .dynsym due to
--export-dynamic/--dynamic-list/referenced by DSO/etc), and
* other conditions that the symbol is preemptible
Then, a preemptible symbol might need a PLT and associated JUMP_SLOT
relocation.)
)
Re: [RFC] RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1
On Sun, Mar 9, 2025 at 7:59 PM Nelson Chu wrote: > > > > On Mon, Mar 10, 2025 at 10:04 AM Fangrui Song wrote: >> >> I am intrigued by the problem but I have trouble understanding the >> description. What behavior does this patch change? >> >> > riscv64-unknown-linux-gnu-gcc test.c >> > -Wl,--unresolved-symbols=ignore-in-object-files >> >> There is no -nostdlib, therefore I assume that this command creates a >> dynamically linked executable (both -fpie -pie and -fno-pie -no-pie >> are possible, depending on how users configure the GCC). > > > Oops, that's true. I think the original problem is for -no-pie. > >> >> I've tested a few cases but do not observe a behavior difference (in >> terms of whether `foo` is in .dynsym and whether there is a JUMP_SLOT >> relocation). >> >> ld-new --unresolved-symbols=ignore-in-object-files -o a a.o b.so >> ld-new --unresolved-symbols=ignore-in-object-files -o a a.o > > > % cat a.s > .text > .weak c > .globl _start > _start: > call a > call b > call c > % cat b.s > .globl b > b: > nop > % riscv64-unknown-linux-gnu-as a.s -o a.o > % riscv64-unknown-linux-gnu-as b.s -o b.o > % riscv64-unknown-linux-gnu-ld -shared b.o -o b.so > % riscv64-unknown-linux-gnu-ld -unresolved-symbols=ignore-in-object-files a.o > b.o > % riscv64-unknown-linux-gnu-objdump -d a.out > ... > Disassembly of section .text: > > 000100b0 <_start>: >100b0: 0097 auipc ra,0x0 >100b4: f50080e7 jalr -176(ra) # 0 <_start-0x100b0> >100b8: 00c000ef jal 100c4 >100bc: 0097 auipc ra,0x0 >100c0: 00e7 jalr zero # 0 <_start-0x100b0> > > 000100c4 : >100c4: 0013 nop > % riscv64-unknown-linux-gnu-ld -unresolved-symbols=ignore-in-object-files a.o > b.so > % riscv64-unknown-linux-gnu-objdump -d a.out > ... > Disassembly of section .plt: > ... > 00010330 : >10330: 2e17 auipc t3,0x2 >10334: cd0e3e03 ld t3,-816(t3) # 12000 >10338: 000e0367 jalr t1,t3 >1033c: 0013 nop > > 00010340 : >10340: 2e17 auipc t3,0x2 >10344: cc8e3e03 ld t3,-824(t3) # 12008 >10348: 000e0367 jalr t1,t3 >1034c: 0013 nop > > 00010350 : >10350: 2e17 auipc t3,0x2 >10354: cc0e3e03 ld t3,-832(t3) # 12010 >10358: 000e0367 jalr t1,t3 >1035c: 0013 nop > > Disassembly of section .text: > > 00010360 <_start>: >10360: ff1ff0ef jal 10350 >10364: fcdff0ef jal 10330 >10368: fd9ff0ef jal 10340 > > But before this patch, all undefined weak and non-weak symbols will be forced > to zero, > > % riscv64-unknown-linux-gnu-ld-old -unresolved-symbols=ignore-in-object-files > a.o b.so > % riscv64-unknown-linux-gnu-objdump -d a.out > ... > Disassembly of section .plt: > ... > 00010330 : >10330: 2e17 auipc t3,0x2 >10334: cd0e3e03 ld t3,-816(t3) # 12000 >10338: 000e0367 jalr t1,t3 >1033c: 0013 nop > > 00010340 : >10340: 2e17 auipc t3,0x2 >10344: cc8e3e03 ld t3,-824(t3) # 12008 >10348: 000e0367 jalr t1,t3 >1034c: 0013 nop > > 00010350 : >10350: 2e17 auipc t3,0x2 >10354: cc0e3e03 ld t3,-832(t3) # 12010 >10358: 000e0367 jalr t1,t3 >1035c: 0013 nop > > Disassembly of section .text: > > 00010360 <_start>: >10360: 0097 auipc ra,0x0 >10364: ca0080e7 jalr -864(ra) # 0 > <_PROCEDURE_LINKAGE_TABLE_-0x10310> >10368: fc9ff0ef jal 10330 >1036c: 0097 auipc ra,0x0 >10370: 00e7 jalr zero # 0 <_PROCEDURE_LINKAGE_TABLE_-0x10310> > >> (lld has a quite simple model where undefined non-weak and undefined >> weak symbols are handled in a unified way. >> A symbol is preemptible if: >> >> * -shared or at least one input file is DSO, and >> * the symbol is undefined or exported (to .dynsym due to >> --export-dynamic/--dynamic-list/referenced by DSO/etc), and >> * other conditions that the symbol is preemptible >> >> Then, a preemptible symbol might need a PLT and associated JUMP_SLOT >> relocation.) Thanks for the example! I see that the branch target is now more meaningful after the patch. > > Yeah I think now the behavior is more similar to lld. Well, except the > special handling for a call to undefined weak function, according to this > page, > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/126 > I suddenly feel like we should also apply this special handling to the calls > which jump to an undefined non-weak function... > > Thanks > Nelson
