https://gcc.gnu.org/g:50c218e3ffe57860591a987ecf44fcc0abb31f2c
commit r15-10-g50c218e3ffe57860591a987ecf44fcc0abb31f2c
Author: Fangrui Song
Date: Fri Apr 26 18:14:33 2024 -0700
RISC-V: Add -X to link spec
--discard-locals (-X) instructs the linker to remove local .L* symbols,
On Thu, Mar 28, 2024 at 2:23 AM Jan Beulich wrote:
>
> On 28.03.2024 08:43, Fangrui Song wrote:
> > On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
> >>
> >> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> >>>
> >>> The relocation formats REL and RELA for ELF are inefficient. In a
>
On Thu, Mar 28, 2024 at 6:04 AM Alan Modra wrote:
>
> On Fri, Mar 22, 2024 at 06:51:41PM -0700, Fangrui Song wrote:
> > On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> > > I propose RELLEB, a new format offering significant file size
> > > reductions: 17.2% (x86-64), 16.5% (aarch64), and
On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
>
> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> >
> > The relocation formats REL and RELA for ELF are inefficient. In a
> > release build of Clang for x86-64, .rela.* sections consume a
> > significant portion (approximately 20.9%) of
On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
>
> The relocation formats REL and RELA for ELF are inefficient. In a
> release build of Clang for x86-64, .rela.* sections consume a
> significant portion (approximately 20.9%) of the file size.
>
> I propose RELLEB, a new format offering
The relocation formats REL and RELA for ELF are inefficient. In a
release build of Clang for x86-64, .rela.* sections consume a
significant portion (approximately 20.9%) of the file size.
I propose RELLEB, a new format offering significant file size
reductions: 17.2% (x86-64), 16.5% (aarch64),
On Tue, Aug 22, 2023 at 12:19 AM Fangrui Song wrote:
>
> On Tue, Aug 1, 2023 at 12:51 PM Fangrui Song wrote:
> >
> > When using -mcmodel=medium, large data objects larger than the
> > -mlarge-data-threshold threshold are placed into large data sections
> > (.lrodata, .ldata, .lbss and some
On Tue, Sep 5, 2023 at 5:14 AM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> committed, thanks :)
>
> On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches
> wrote:
> >
> >
> >
> > On 8/31/23 03:05, Kito Cheng wrote:
> > > We only emit that on linux target before, that not
On Tue, Aug 1, 2023 at 12:51 PM Fangrui Song wrote:
>
> When using -mcmodel=medium, large data objects larger than the
> -mlarge-data-threshold threshold are placed into large data sections
> (.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place
> .l* sections into separate
When using -mcmodel=medium, large data objects larger than the
-mlarge-data-threshold threshold are placed into large data sections
(.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place
.l* sections into separate output sections. If small and medium code
model object files are
On Wed, Jul 19, 2023 at 4:12 PM Alexandre Oliva via Gcc-patches
wrote:
>
> On Jul 18, 2023, Richard Biener wrote:
>
> > I think the __symver__ attribute does something similar already so
> > maybe use __attribute__((__sym__("foo")))?
>
> Cool, thanks, that will do. Regstrapped on
On Thu, Nov 24, 2022 at 7:26 PM Kewen.Lin via Gcc-patches
wrote:
>
> Hi Richard,
>
> on 2022/11/23 00:08, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> Hi Richard,
> >>
> >> Many thanks for your review comments!
> >>
> > on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> >>
On Tue, Jun 13, 2023 at 2:49 PM Fangrui Song wrote:
> On Mon, Jun 12, 2023 at 11:16 PM Jan Beulich wrote:
>
>> On 13.06.2023 05:28, Fangrui Song wrote:
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.target/i386/large-data.c
>> > @@ -0,0 +1,13 @@
>> > +/* { dg-do compile } */
>> > +/* {
On Mon, Jun 12, 2023 at 11:16 PM Jan Beulich wrote:
> On 13.06.2023 05:28, Fangrui Song wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/large-data.c
> > @@ -0,0 +1,13 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target lp64 } */
> > +/* { dg-options "-O2
When using -mcmodel=medium, large data objects larger than the
-mlarge-data-threshold threshold are placed into large data sections
(.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place
.l* sections into separate output sections. If small and medium code
model object files are
On Fri, Jun 2, 2023 at 3:11 AM Alexandre Oliva via Gcc-patches
wrote:
>
> On Jan 19, 2023, Alexandre Oliva wrote:
>
> > Would it make more sense to extend it, even constrained by the
> > limitations mentioned above, or handle memset only? In the latter case,
> > would it still make sense to
On Fri, May 26, 2023 at 12:11 AM Jan Beulich wrote:
>
> On 25.05.2023 18:11, Fangrui Song wrote:
> > On 2023-05-25, Jan Beulich wrote:
> >> On 25.05.2023 17:16, Fangrui Song wrote:
> >>> --- a/gcc/doc/invoke.texi
> >>> +++ b/gcc/doc/invoke.texi
> >>> @@ -32942,9 +32942,10 @@ the cache line size.
On 2023-05-25, Jan Beulich wrote:
On 25.05.2023 17:16, Fangrui Song wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default.
@opindex mlarge-data-threshold
@item -mlarge-data-threshold=@var{threshold}
-When
When using -mcmodel=medium, large data objects larger than the
-mlarge-data-threshold threshold are placed into large data sections
(.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place
.l* sections into separate output sections. If small and medium code
model object files are
On Wed, May 10, 2023 at 2:58 AM Uros Bizjak wrote:
>
> On Fri, Apr 28, 2023 at 2:47 AM Fangrui Song wrote:
> >
> > When using -mcmodel=medium, large data is placed into .l* sections. GNU ld
> > places .l* sections into separate output sections. If small and medium
> > code model object files
On Thu, Apr 27, 2023 at 5:47 PM Fangrui Song wrote:
>
> When using -mcmodel=medium, large data is placed into .l* sections. GNU ld
> places .l* sections into separate output sections. If small and medium
> code model object files are mixed, the .l* sections won't cause
> relocation overflow
When using -mcmodel=medium, large data is placed into .l* sections. GNU ld
places .l* sections into separate output sections. If small and medium
code model object files are mixed, the .l* sections won't cause
relocation overflow pressure on sections in -mcmodel=small object files.
However,
On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
wrote:
>
>
>
> > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches
> > wrote:
> >
> > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov
> > wrote:
> >>
> >>
> >> On Wed, 22 Mar 2023, Richard Biener wrote:
> >>
> >>> I think
> The above is incorrectly formatted, the GCC Coding Conventions
say || etc. shouldn't be at the end of lines, but rather at the
start of the next ones.
Ack.
> And, while I can understand the rationale for global cases
> (though am not sure I agree, as currently the user can choose
> by using
Follow aarch64 and riscv ports by using (global ? DW_EH_PE_indirect : 0)
| DW_EH_PE_pcrel for -fno-pic code. This avoids a canonical PLT entry
for a personality reference in .eh_frame and a copy relocation for a
typeinfo reference in .gcc_except_table, when the definition is in
libstdc++.so.6.
On Thu, Nov 17, 2022 at 1:55 PM Andrew Pinski wrote:
>
> On Thu, Nov 17, 2022 at 1:46 PM Fangrui Song wrote:
> >
> > On Thu, Nov 17, 2022 at 1:37 PM Andrew Pinski wrote:
> > >
> > > On Thu, Nov 17, 2022 at 1:21 PM maskray--- via Gcc-patches
> > > wrote:
> > > >
> > > > > +.. option::
On Thu, Nov 17, 2022 at 1:37 PM Andrew Pinski wrote:
>
> On Thu, Nov 17, 2022 at 1:21 PM maskray--- via Gcc-patches
> wrote:
> >
> > > +.. option:: -mdirect-extern-access, -mno-direct-extern-access
> > > +
> > > + Use direct accesses for external data symbols. It avoids a GOT
> > >
On Thu, Sep 29, 2022 at 3:28 AM Martin Liška wrote:
> Sending V2 where I included new -gz=zstd option value.
>
> Cheers,
> Martin
At some point binutils will want to remove
--compress-debug-sections=zlib-gnu support as well.
I think the message can drop mentioning of
On Wed, Sep 21, 2022 at 12:37 AM Richard Biener
wrote:
>
> On Tue, Sep 20, 2022 at 2:55 PM Martin Liška wrote:
> >
> > On 7/1/22 09:20, Fangrui Song via Gcc-patches wrote:
> > > On 2022-07-01, Andrew Pinski wrote:
> > >> On Thu, Jun 30, 2022 at 11:58 PM Fan
On Sun, Sep 4, 2022 at 12:00 AM Lulu Cheng wrote:
>
>
> 在 2022/9/4 下午2:35, Xi Ruoyao 写道:
> > On Sun, 2022-09-04 at 11:22 +0800, Lulu Cheng wrote:
> >> 在 2022/9/4 上午10:51, Xi Ruoyao 写道:
> >>
> >>> On Sun, 2022-09-04 at 10:26 +0800, Lulu Cheng wrote:
> >>>
> If the above modifications are not
On Fri, Sep 2, 2022 at 4:31 AM Xi Ruoyao via Gcc-patches
wrote:
>
> On Thu, 2022-09-01 at 18:54 +0800, Xi Ruoyao wrote:
> > We'd like to introduce a new codegen option to align with the old
> > "-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
> > building the Linux kernel
On Tue, Aug 30, 2022 at 9:46 AM Jose E. Marchesi
wrote:
>
>
> > On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> > wrote:
> >>
> >>
> >> LLVM defines both __bpf__ and __BPF_ as target macros.
> >> GCC was defining only __BPF__.
> >>
> >> This patch defines __bpf__ as a target
On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> LLVM defines both __bpf__ and __BPF_ as target macros.
> GCC was defining only __BPF__.
>
> This patch defines __bpf__ as a target macro for BPF.
> Tested in bpf-unknown-none.
>
> gcc/ChangeLog:
>
> *
On Tue, Aug 9, 2022 at 7:00 AM Alexandre Oliva via Gcc-patches
wrote:
>
> Ping?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598276.html
This is great! And hope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 can be
re-considered, at least for some ports :)
> On Jul 27, 2022,
On Mon, Aug 1, 2022 at 12:05 PM H.J. Lu via Gcc-patches
wrote:
>
> On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
> >
> > On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> > >
> > > On Jul 27, 2022, "H.J. Lu" wrote:
> > >
> > > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > >
p64,ilp32f,...}. We will have "*64briscv*" variants and
it will then look really ugly.
On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches
wrote:
This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.
The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=2
On Mon, Jul 4, 2022 at 6:54 PM Xi Ruoyao via Gcc-patches
wrote:
>
> On Mon, 2022-07-04 at 14:28 +, Dimitrije Milosevic wrote:
> > On Saturday, June 11, 2022 2:03 PM, Xi wrote:
> > > Just tried TSAN_SUPPORTED=yes with asynchronous unwind tables
> > > enabled,
> > > but I got some strange test
On 2022-07-01, Andrew Pinski wrote:
On Thu, Jun 30, 2022 at 11:58 PM Fangrui Song via Gcc-patches
wrote:
From: Fangrui Song
SHF_COMPRESSED style zlib has been supported since binutils 2.26
and the legacy zlib-gnu option hasn't gain adoption.
According to Debian Code Search (`gz=zlib-gnu
From: Fangrui Song
SHF_COMPRESSED style zlib has been supported since binutils 2.26
and the legacy zlib-gnu option hasn't gain adoption.
According to Debian Code Search (`gz=zlib-gnu`), no project uses
-gz=zlib-gnu (valgrind has a configure to use -gz=zlib).
Remove support for the legacy
On 2022-06-24, Rainer Orth wrote:
Hi Xi,
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several
On Wed, Jun 22, 2022 at 4:29 PM Alexandre Oliva wrote:
>
> On Jun 22, 2022, Iain Sandoe wrote:
>
> > It makes some sense to have the option named -nostdlib++ if a target
> > might add multiple libs (and/or make other changes) for linking C++.
>
> if it was nostdlibc++, I'd agree. lib++ is not
On 2022-06-21, Richard Biener wrote:
On Tue, Jun 21, 2022 at 9:53 AM Fangrui Song wrote:
On Tue, Jun 21, 2022 at 1:43 AM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Jun 21, 2022 at 7:56 AM Alexandre Oliva via Gcc-patches
> wrote:
> >
> >
> > Using g++ to link without libstdc++, as in
On Tue, Jun 21, 2022 at 1:43 AM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Jun 21, 2022 at 7:56 AM Alexandre Oliva via Gcc-patches
> wrote:
> >
> >
> > Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C,
> > is error prone, because there's no way to tell g++ to drop
On Wed, Jun 15, 2022 at 2:34 AM Fangrui Song wrote:
>
> This was introduced in 2014-12 to use local binding for external symbols
> for -fPIE. It avoids a GOT indirection but the same optimizationis
> obtained with ld's R_X86_64_[REX_]GOTPCRELX optimization (albeit with
> slightly longer code).
>
ks for the good consideration. That said, I am unsure any distro
uses this currently.
I think some just work around the possibly non-existent paths by
creating symlinks.
Perhaps we should prioritize on fixing the scheme before distros start
to rely on the behavior.
> On Wed, Jun 15, 2022 at 4:00 PM Fa
On Wed, Jun 15, 2022 at 2:44 PM H.J. Lu via Gcc-patches
wrote:
>
> On Mon, Jun 13, 2022 at 9:01 AM Richard Biener
> wrote:
> >
> >
> >
> > > Am 13.06.2022 um 16:36 schrieb H.J. Lu :
> > >
> > > On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
> > > wrote:
> > >>
> > >>> On Tue, Jun 7, 2022 at
This was introduced in 2014-12 to use local binding for external symbols
for -fPIE. It avoids a GOT indirection but the same optimizationis
obtained with ld's R_X86_64_[REX_]GOTPCRELX optimization (albeit with
slightly longer code).
One design goal of -fPIE was to avoid copy relocations.
This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.
The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962
let GCC pass -m emulation to ld and let the ld emulation configure
default library paths. This scheme is problematic:
* It's not ld's business to specify default
On 2021-06-18, H.J. Lu via llvm-dev wrote:
Add GNU_PROPERTY_1_NEEDED:
#define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
to indicate the needed properties by the object file.
I am fine with this logical OR style usage. But see below, do we need it
for ld.so runtime check?
(As I
On 2021-06-17, H.J. Lu via llvm-dev wrote:
On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote:
On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
>
> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
>
> #define GNU_PROPERTY_UINT32_AND_LO 0xb000
> #define GNU_PROPERTY_UINT32_AND_HI
From: Fangrui Song
--enable-default-semantic-interposition=no makes -fPIC default to
-fno-semantic-interposition which enables interprocedural optimizations
for default visibility non-vague-linkage function definitions.
The suppression of interprocedural optimizations and inlining for such
On 2021-05-12, Rainer Orth wrote:
Hi Fangrui,
Hi Rainer,
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
Solaris/x86 ld doesn't support this, so HAVE_LD_PIE_COPYRELOC needs to
This was introduced in 2014-12 to use local binding for external symbols
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
One design goal of -fPIE was to avoid copy relocations.
On 2021-01-14, Martin Liška wrote:
On 1/14/21 11:07 AM, Richard Biener wrote:
I see no particular reason to allow arbitrary garbage to be used as
linker. It just asks for users to shoot themselves in the foot and
for strange bugreports to pop up.
Well, for a strange bug report, we'll see
Attached v3 to address nits.
On 2020-07-23, Martin Liška wrote:
On 7/21/20 6:07 AM, Fangrui Song wrote:
If the value does not contain any path component separator (e.g. a
slash), the linker will be searched for using COMPILER_PATH followed by
PATH. Otherwise, it is either an absolute path or a
If the value does not contain any path component separator (e.g. a
slash), the linker will be searched for using COMPILER_PATH followed by
PATH. Otherwise, it is either an absolute path or a path relative to the
current working directory.
--ld-path= complements and overrides
Fix email addresses:)
On 2020-07-09, Fangrui Song wrote:
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I think there
On 2020-05-25, Martin Liška wrote:
On 5/22/20 6:42 AM, Fangrui Song wrote:
but I can't fix this one because joining two lines will break the 80-column
rule.
What about this:
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cc57a20e08b..e5b54b080f7 100644
--- a/gcc/collect2.c
+++
On 2020-05-21, Martin Liška wrote:
On 5/21/20 1:52 AM, Fangrui Song wrote:
The above issues motivated me to touch this line in PATCH v2.
Dropped in PATCH v2.
Thank you for the updated patch.
The patch is fine except coding style issues:
$ ./contrib/check_GNU_style.py
On 2020-05-20, Martin Liška wrote:
Hello.
Thanks for review. Sent PATCH v2.
diff --git a/gcc/collect2.c b/gcc/collect2.c
index f8a5ce45994..e04892cb91f 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -782,15 +782,16 @@ main (int argc, char **argv)
USE_GOLD_LD,
USE_BFD_LD,
On 2020-04-06, Martin Liška wrote:
On 4/6/20 12:32 AM, Fangrui Song wrote:
On 2020-03-11, Martin Liška wrote:
On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote:
Hello.
Thank you for the patch. You haven't received a review because we are right now
in stage4 of the development cycle
On 2020-05-13, Eric Botcazou wrote:
Did I mention I dislike -fsplit-dwarf? ;)
Seconded, this will be confusing for almost all users. Since the option only
affects debug info generation, it should be prefixed with 'g' in any case.
Updating the semantics of -gsplit-dwarf is actually my
-fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging
information by itself. This makes it easier to be plugged into a build
system without worrying that unnecessary debugging information may be
generated.
2020-05-12 Fangrui Song
PR debug/95096
* common.opt:
On 2020-03-11, Martin Liška wrote:
On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote:
Hello.
Thank you for the patch. You haven't received a review because we are right now
in stage4 of the development cycle:
https://gcc.gnu.org/develop.html#stage4
Thanks for the review!
According
Alternatively, we can delete it, because no user code should call it.
It may be weird that libc is expected to define this function.
This function is a language runtime interface that has nothing to do
with a libc.
---
libstdc++-v3/libsupc++/cxxabi.h | 2 +-
1 file changed, 1 insertion(+), 1
On 2020-02-24, Fangrui Song wrote:
On 2020-02-13, Fangrui Song wrote:
On 2020-02-09, Fangrui Song wrote:
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c
On 2020-02-13, Fangrui Song wrote:
On 2020-02-09, Fangrui Song wrote:
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
On 2020-02-09, Fangrui Song wrote:
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
---
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
---
gcc/ChangeLog | 8 ++
Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194
>From 60f489f2bf2b32afd1bdbb2405bb028dcedf82cc Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Tue, 7 Jan 2020 20:46:26 -0800
Subject: [PATCH] Align __patchable_function_entries to POINTER_SIZE
To: gcc-patches@gcc.gnu.org
---
71 matches
Mail list logo
