Re: [PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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.  @samp{compat} is the 
> >>> default.
> >>>
> >>>  @opindex mlarge-data-threshold
> >>>  @item -mlarge-data-threshold=@var{threshold}
> >>> -When @option{-mcmodel=medium} is specified, data objects larger than
> >>> -@var{threshold} are placed in the large data section.  This value must 
> >>> be the
> >>> -same across all objects linked into the binary, and defaults to 65535.
> >>> +When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified, 
> >>> data
> >>> +objects larger than @var{threshold} are placed in large data sections.  
> >>> This
> >>> +value must be the same across all objects linked into the binary, and 
> >>> defaults
> >>> +to 65535.
> >>
> >> Where's the "must be the same" requirement coming from?
> >
> > It's an existing requirement.  I think it may be related to discouraging
> > different COMDAT sections names due to different -mlarge-data-threshold=.
> > I don't think it makes sense but did not feel strongly dropping it.
> >
> > Happy to drop the requirement if I revise this patch.
>
> I understand that this isn't something you introduce, but it still stuck
> me as odd. Therefore I thought I'd suggest to take the opportunity to at
> least soften the language, unless of course there's a real reason behind
> it.

Dropping "This value must be the same across all objects linked into
the binary" looks good to me.

> >> As to the default - to remain compatible with earlier versions, shouldn't
> >> large model code default to "infinity"?
> >>
> >> Jan
> >
> > I have thought about this compatibility need and feel that it is very
> > unlikly to be needed.  GNU ld has supported large data sections since
> > 2005
> > (https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3b22753a67cf616514de804ef6d5ed5e90a7d883).
> > Users' programs with the internal linker scripts will still be working
> > and -fdata-sections sections will be combined.
>
> Well, the concern clearly is about custom scripts. Imo ...
>
> > First, -mcmodel=large use cases are rare enough.  Rare perhaps
> > -mcmodel=largel was considered theoretic excercise  in
> > trying to reach feature completion
> > (https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU/m/NNuA0P7pAQAJ),
> > without this patch -mcmodel=large object files don't interract well with
> > existing -mcmodel=small object files.
>
> ... the more exotic a project, the more likely it is that they're using
> custom scripts.
>
> > Moreover, if a user expects a specific section prefix with
> > -mcmodel=large, that's a brittle assumption. I think it's fair to say
> > that the fault is on the user side and GCC doesn't need to work around
> > their issues.
>
> I guess I don't really see what you base this on. Without any special
> options, expecting data to end up in .data/.bss/.rodata (and variants
> thereof) looks like quite reasonable an assumption to me.
>
> Jan

Making -mlarge-data-threshold= default value for
-mcmodel={medium,large} seems quite odd to me.

The default value is 65536, which is larger than most data objects
that we may encounter in practice.
I want to investigate how often users use -mcmodel=large but it is
quite difficult. Many are for AIX and/or powerpc.
I have tried to be considerate but I am not sure we have users in the
intersection of the three sets: -mcmodel=large, data objects larger
than 65536, using linker script in a way that orphan sections .ldata
will cause trouble.


-- 
宋方睿

Re: [RFC] Introduce -finline-memset-loops

[Fangrui Song via Gcc-patches]

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 adopt a command-line option that suggests a
> > broader effect than it already has, even if it's only a hopeful future
> > extension?  -finline-all-stringops[={memset,memcpy,...}], that you
> > suggested, seems to be a reasonable and extensible one to adopt.
>
> I ended up implementing all of memset, memcpy, memmove, and memcmp:
>
> Introduce -finline-stringops
>
> try_store_by_multiple_pieces was added not long ago, enabling
> variable-sized memset to be expanded inline when the worst-case
> in-range constant length would, using conditional blocks with powers
> of two to cover all possibilities of length and alignment.
>
> This patch introduces -finline-stringops[=fn] to request expansions to
> start with a loop, so as to still take advantage of known alignment
> even with long lengths, but without necessarily adding store blocks
> for every power of two.
>
> This makes it possible for the supported stringops (memset, memcpy,
> memmove, memset) to be expanded, even if storing a single byte per
> iteration.  Surely efficient implementations can run faster, with a
> pre-loop to increase alignment, but that would likely be excessive for
> inline expansions.
>
> Still, in some cases, such as in freestanding environments, users
> prefer to inline such stringops, especially those that the compiler
> may introduce itself, even if the expansion is not as performant as a
> highly optimized C library implementation could be, to avoid
> depending on a C runtime library.
>
> Regstrapped on x86_64-linux-gnu, also bootstrapped with
> -finline-stringops enabled by default, and tested with arm, aarch, 32-
> and 64-bit riscv with gcc-12.  Ok to install?
>[...]

This seems to be related to Clang's __builtin_mem{set,cpy}_inline . I
just created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110094 ("Support
__builtin_mem*_inline").

[PATCH v3] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 mixed, the .l* sections won't exert relocation
overflow pressure on sections in object files built with -mcmodel=small.

However, when using -mcmodel=large, -mlarge-data-threshold doesn't
apply.  This means that the .rodata/.data/.bss sections may exert
relocation overflow pressure on sections in -mcmodel=small object files.

This patch allows -mcmodel=large to generate .l* sections and drops an
unneeded documentation restriction that the value must be the same.

Link: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
("Large data sections for the large code model")

Signed-off-by: Fangrui Song 

---
Changes from v1 
(https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616947.html):
* Clarify commit message. Add link to 
https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU

Changes from v2
* Drop an uneeded limitation in the documentation.
---
 gcc/config/i386/i386.cc| 15 +--
 gcc/config/i386/i386.opt   |  2 +-
 gcc/doc/invoke.texi|  6 +++---
 gcc/testsuite/gcc.target/i386/large-data.c | 13 +
 4 files changed, 26 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index d4ff56ee8dd..ca92a5b65ce 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -637,7 +637,8 @@ ix86_can_inline_p (tree caller, tree callee)
 static bool
 ix86_in_large_data_p (tree exp)
 {
-  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC)
+  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC &&
+  ix86_cmodel != CM_LARGE && ix86_cmodel != CM_LARGE_PIC)
 return false;
 
   if (exp == NULL_TREE)
@@ -848,8 +849,9 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
const char *name, unsigned HOST_WIDE_INT size,
unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+  ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+ size > (unsigned int)ix86_section_threshold)
 {
   switch_to_section (get_named_section (decl, ".lbss", 0));
   fputs (LARGECOMM_SECTION_ASM_OP, file);
@@ -869,9 +871,10 @@ void
 x86_output_aligned_bss (FILE *file, tree decl, const char *name,
unsigned HOST_WIDE_INT size, unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
-switch_to_section (get_named_section (decl, ".lbss", 0));
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+   ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+  size > (unsigned int)ix86_section_threshold)
+switch_to_section(get_named_section(decl, ".lbss", 0));
   else
 switch_to_section (bss_section);
   ASM_OUTPUT_ALIGN (file, floor_log2 (align / BITS_PER_UNIT));
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index d74f6b1f8fc..de8e722cd62 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -282,7 +282,7 @@ Branches are this expensive (arbitrary units).
 
 mlarge-data-threshold=
 Target RejectNegative Joined UInteger Var(ix86_section_threshold) 
Init(DEFAULT_LARGE_SECTION_THRESHOLD)
--mlarge-data-threshold=Data greater than given threshold will 
go into .ldata section in x86-64 medium model.
+-mlarge-data-threshold=Data greater than given threshold will 
go into a large data section in x86-64 medium and large code models.
 
 mcmodel=
 Target RejectNegative Joined Enum(cmodel) Var(ix86_cmodel) Init(CM_32)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9130104af22..a31f33e7193 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -33006,9 +33006,9 @@ the cache line size.  @samp{compat} is the default.
 
 @opindex mlarge-data-threshold
 @item -mlarge-data-threshold=@var{threshold}
-When @option{-mcmodel=medium} is specified, data objects larger than
-@var{threshold} are placed in the large data section.  This value must be the
-same across all objects linked into the binary, and defaults to 65535.
+When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified, data
+objects larger than @var{threshold} are placed in large data sections. The
+default is 65535.
 
 @opindex mrtd
 @item -mrtd
diff --git a/gcc/testsuite/gcc.target/i386/large-data.c 
b/gcc/testsuite/gcc.target/i386/large-data.c
new file mode 100644
index 000..09a917431d4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/large-data.c
@@ -0,0

Re: [PATCH v3] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 -mcmodel=large -mlarge-data-threshold=4" } */
> > +/* { dg-final { scan-assembler ".lbss" } } */
> > +/* { dg-final { scan-assembler ".bss" } } */
> > +/* { dg-final { scan-assembler ".ldata" } } */
> > +/* { dg-final { scan-assembler ".data" } } */
> > +/* { dg-final { scan-assembler ".lrodata" } } */
> > +/* { dg-final { scan-assembler ".rodata" } } */
>
> Aren't these regex-es, and hence the dots all need escaping or enclosing
> in square brackets?
>
> Jan
>

Good catch! I am not familiar with dg-* directives... I can send a v4, but
I'd like to know whether there are other comments.
(I don't have git write permission for gcc.)


-- 
宋方睿

Re: PING^2 [PATCH] Adjust the symbol for SECTION_LINK_ORDER linked_to section [PR99889]

[Fangrui Song via Gcc-patches]

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:
> >> Hi,
> >>
> >> As discussed in PR98125, -fpatchable-function-entry with
> >> SECTION_LINK_ORDER support doesn't work well on powerpc64
> >> ELFv1 because the filled "Symbol" in
> >>
> >>   .section name,"flags"o,@type,Symbol
> >>
> >> sits in .opd section instead of in the function_section
> >> like .text or named .text*.
> >>
> >> Since we already generates one label LPFE* which sits in
> >> function_section of current_function_decl, this patch is
> >> to reuse it as the symbol for the linked_to section.  It
> >> avoids the above ABI specific issue when using the symbol
> >> concluded from current_function_decl.
> >>
> >> Besides, with this support some previous workarounds for
> >> powerpc64 ELFv1 can be reverted.
> >>
> >> btw, rs6000_print_patchable_function_entry can be dropped
> >> but there is another rs6000 patch which needs this rs6000
> >> specific hook rs6000_print_patchable_function_entry, not
> >> sure which one gets landed first, so just leave it here.
> >>
> >> Bootstrapped and regtested on below:
> >>
> >>   1) powerpc64-linux-gnu P8 with default binutils 2.27
> >>  and latest binutils 2.39.
> >>   2) powerpc64le-linux-gnu P9 (default binutils 2.30).
> >>   3) powerpc64le-linux-gnu P10 (default binutils 2.30).
> >>   4) x86_64-redhat-linux with default binutils 2.30
> >>  and latest binutils 2.39.
> >>   5) aarch64-linux-gnu  with default binutils 2.30
> >>  and latest binutils 2.39.
> >>
> >>
> >> [snip...]
> >>
> >> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
> >> index 4db8506b106..d4de6e164ee 100644
> >> --- a/gcc/varasm.cc
> >> +++ b/gcc/varasm.cc
> >> @@ -6906,11 +6906,16 @@ default_elf_asm_named_section (const char 
> >> *name, unsigned int flags,
> >>  fprintf (asm_out_file, ",%d", flags & SECTION_ENTSIZE);
> >>if (flags & SECTION_LINK_ORDER)
> >>  {
> >> -  tree id = DECL_ASSEMBLER_NAME (decl);
> >> -  ultimate_transparent_alias_target (&id);
> >> -  const char *name = IDENTIFIER_POINTER (id);
> >> -  name = targetm.strip_name_encoding (name);
> >> -  fprintf (asm_out_file, ",%s", name);
> >> +  /* For now, only section "__patchable_function_entries"
> >> + adopts flag SECTION_LINK_ORDER, internal label LPFE*
> >> + was emitted in default_print_patchable_function_entry,
> >> + just place it here for linked_to section.  */
> >> +  gcc_assert (!strcmp (name, "__patchable_function_entries"));
> >>>
> >>> I like the idea of removing the rs600 workaround in favour of making the
> >>> target-independent more robust.  But this seems a bit hackish.  What
> >>> would we do if SECTION_LINK_ORDER was used for something else in future?
> >>>
> >>
> >> Good question!  I think it depends on how we can get the symbol for the
> >> linked_to section, if adopting the name of the decl will suffer the
> >> similar issue which this patch wants to fix, we have to reuse the label
> >> LPFE* or some kind of new artificial label in the related section; or
> >> we can just go with the name of the given decl, or something related to
> >> that decl.  Since we can't predict any future uses, I just placed an
> >> assertion here to ensure that we would revisit and adjust this part at
> >> that time.  Does it sound reasonable to you?
> >
> > Yeah, I guess that's good enough.  If the old scheme ends up being
> > correct for some future use, we can make the new behaviour conditional
> > on __patchable_function_entries.
>
> Yes, we can check if the given section name is
> "__patchable_function_entries".
>
> >
> > So yeah, the patch LGTM to me, thanks.
>
> Thanks again!  I rebased and re-tested it on x86/aarch64/powerpc64{,le},
> just committed in r13-4294-gf120196382ac5a.
>
> BR,
> Kewen

Hi, Kewen, do you think whether your patch fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110729
(__patchable_function_entries has wrong sh_link) ?
If yes, it may be useful to include some assembly tests... Right now

rg '\.section.*__patchable' gcc/testsuite/

returns nothing.


-- 
宋方睿

Re: [PATCH v4] Introduce attribute sym

[Fangrui Song via Gcc-patches]

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 x86_64-linux-gnu.  Ok to
> install?
>
>
> This patch introduces an attribute to add extra asm names (aliases)
> for a decl when its definition is output.  The main goal is to ease
> interfacing C++ with Ada, as C++ mangled names have to be named, and
> in some cases (e.g. when using stdint.h typedefs in function
> arguments) the symbol names may vary across platforms.
>
> The attribute is usable in C and C++, presumably in all C-family
> languages.  It can be attached to global variables and functions.  In
> C++, it can also be attached to class types, namespace-scoped
> variables and functions, static data members, member functions,
> explicit instantiations and specializations of template functions,
> members and classes.
>
> When applied to constructors or destructor, additional sym aliases
> with _Base and _Del suffixes are defined for variants other than
> complete-object ones.  This changes the assumption that clones always
> carry the same attributes as their abstract declarations, so there is
> now a function to adjust them.

I wonder whether this attribute can be named "alias" without arguments.
alias ("target") is an existing attribute that applies to a
declaration. The new "alias" without arguments can apply to
definitions.

I am just thinking that the semantics of "sym" may confuse users who
are familiar with "alias" :)

[PATCH v4] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 mixed, the .l* sections won't exert relocation
overflow pressure on sections in object files built with -mcmodel=small.

However, when using -mcmodel=large, -mlarge-data-threshold doesn't
apply.  This means that the .rodata/.data/.bss sections may exert
relocation overflow pressure on sections in -mcmodel=small object files.

This patch allows -mcmodel=large to generate .l* sections and drops an
unneeded documentation restriction that the value must be the same.

Link: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
("Large data sections for the large code model")

Signed-off-by: Fangrui Song 

---
Changes from v1 
(https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616947.html):
* Clarify commit message. Add link to 
https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU

Changes from v2
* Drop an uneeded limitation in the documentation.

Changes from v3
* Change scan-assembler directives to use \. to match literal .
---
 gcc/config/i386/i386.cc| 15 +--
 gcc/config/i386/i386.opt   |  2 +-
 gcc/doc/invoke.texi|  6 +++---
 gcc/testsuite/gcc.target/i386/large-data.c | 13 +
 4 files changed, 26 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index eabc70011ea..37e810cc741 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -647,7 +647,8 @@ ix86_can_inline_p (tree caller, tree callee)
 static bool
 ix86_in_large_data_p (tree exp)
 {
-  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC)
+  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC &&
+  ix86_cmodel != CM_LARGE && ix86_cmodel != CM_LARGE_PIC)
 return false;
 
   if (exp == NULL_TREE)
@@ -858,8 +859,9 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
const char *name, unsigned HOST_WIDE_INT size,
unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+  ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+ size > (unsigned int)ix86_section_threshold)
 {
   switch_to_section (get_named_section (decl, ".lbss", 0));
   fputs (LARGECOMM_SECTION_ASM_OP, file);
@@ -879,9 +881,10 @@ void
 x86_output_aligned_bss (FILE *file, tree decl, const char *name,
unsigned HOST_WIDE_INT size, unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
-switch_to_section (get_named_section (decl, ".lbss", 0));
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+   ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+  size > (unsigned int)ix86_section_threshold)
+switch_to_section(get_named_section(decl, ".lbss", 0));
   else
 switch_to_section (bss_section);
   ASM_OUTPUT_ALIGN (file, floor_log2 (align / BITS_PER_UNIT));
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index 1cc8563477a..52fad492353 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -282,7 +282,7 @@ Branches are this expensive (arbitrary units).
 
 mlarge-data-threshold=
 Target RejectNegative Joined UInteger Var(ix86_section_threshold) 
Init(DEFAULT_LARGE_SECTION_THRESHOLD)
--mlarge-data-threshold=Data greater than given threshold will 
go into .ldata section in x86-64 medium model.
+-mlarge-data-threshold=Data greater than given threshold will 
go into a large data section in x86-64 medium and large code models.
 
 mcmodel=
 Target RejectNegative Joined Enum(cmodel) Var(ix86_cmodel) Init(CM_32)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 104766f446d..bf6fe3e1a20 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -33207,9 +33207,9 @@ the cache line size.  @samp{compat} is the default.
 
 @opindex mlarge-data-threshold
 @item -mlarge-data-threshold=@var{threshold}
-When @option{-mcmodel=medium} is specified, data objects larger than
-@var{threshold} are placed in the large data section.  This value must be the
-same across all objects linked into the binary, and defaults to 65535.
+When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified, data
+objects larger than @var{threshold} are placed in large data sections. The
+default is 65535.
 
 @opindex mrtd
 @item -mrtd
diff --git a/gcc/testsuite/gcc.target/i386/large-data.c 
b/gcc/testsuite/gcc.target/i386/large-data.c
new file mode 100644
index 000..b

[PATCH] Remove legacy -gz=zlib-gnu

[Fangrui Song via Gcc-patches]

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 zlib-gnu and simplify configure.ac by
removing zlib-gnu ld/as check.
---
 gcc/common.opt  |  3 ---
 gcc/configure   | 33 ++---
 gcc/configure.ac| 29 -
 gcc/doc/invoke.texi | 11 +--
 gcc/gcc.cc  | 22 ++
 5 files changed, 17 insertions(+), 81 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index e7a51e882ba..8754d93d545 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3424,9 +3424,6 @@ Enum(compressed_debug_sections) String(none) Value(0)
 EnumValue
 Enum(compressed_debug_sections) String(zlib) Value(1)
 
-EnumValue
-Enum(compressed_debug_sections) String(zlib-gnu) Value(2)
-
 gz
 Common Driver
 Generate compressed debug sections.
diff --git a/gcc/configure b/gcc/configure
index 62872d132ea..ca87e875e9d 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19674,7 +19674,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19679 "configure"
+#line 19677 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19780,7 +19780,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19785 "configure"
+#line 19783 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -29711,20 +29711,13 @@ else
if $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s 2>&1 | 
grep -i warning > /dev/null
then
  gcc_cv_as_compress_debug=0
-   # Since binutils 2.26, gas supports --compress-debug-sections=type,
+   # Since binutils 2.26, gas supports --compress-debug-sections=zlib,
# defaulting to the ELF gABI format.
-   elif $gcc_cv_as --compress-debug-sections=zlib-gnu -o conftest.o conftest.s 
> /dev/null 2>&1
+   elif $gcc_cv_as --compress-debug-sections=zlib -o conftest.o conftest.s > 
/dev/null 2>&1
then
  gcc_cv_as_compress_debug=2
  gcc_cv_as_compress_debug_option="--compress-debug-sections"
  gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections"
-   # Before binutils 2.26, gas only supported --compress-debug-options and
-   # emitted the traditional GNU format.
-   elif $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s > 
/dev/null 2>&1
-   then
- gcc_cv_as_compress_debug=1
- gcc_cv_as_compress_debug_option="--compress-debug-sections"
- gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections"
else
  gcc_cv_as_compress_debug=0
fi
@@ -30238,42 +30231,28 @@ $as_echo "$gcc_cv_ld_eh_gc_sections_bug" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking linker for compressed debug 
sections" >&5
 $as_echo_n "checking linker for compressed debug sections... " >&6; }
-# gold/gld support compressed debug sections since binutils 2.19/2.21
-# In binutils 2.26, gld gained support for the ELF gABI format.
+# GNU ld/gold support --compressed-debug-sections=zlib since binutils 2.26.
 if test $in_tree_ld = yes ; then
   gcc_cv_ld_compress_debug=0
   if test $ld_is_mold = yes; then
 gcc_cv_ld_compress_debug=3
 gcc_cv_ld_compress_debug_option="--compress-debug-sections"
-  elif test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 19 -o "$gcc_cv_gld_major_version" -gt 2 \
- && test $in_tree_ld_is_elf = yes && test $ld_is_gold = yes; then
-gcc_cv_ld_compress_debug=2
-gcc_cv_ld_compress_debug_option="--compress-debug-sections"
   elif test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 26 -o "$gcc_cv_gld_major_version" -gt 2 \
  && test $in_tree_ld_is_elf = yes && test $ld_is_gold = no; then
 gcc_cv_ld_compress_debug=3
 gcc_cv_ld_compress_debug_option="--compress-debug-sections"
-  elif test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 21 -o "$gcc_cv_gld_major_version" -gt 2 \
- && test $in_tree_ld_is_elf = yes; then
-gcc_cv_ld_compress_debug=1
   fi
 elif echo "$ld_ver" | grep GNU > /dev/null; then
   if test $ld_is_mold = yes; then
 gcc_cv_ld_compress_debug=3
 gcc_cv_ld_compress_debug_option="--compress-debug-sections"
   elif test "$ld_vers_major" -lt 2 \
- || test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 21; then
+ || test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 26; then
 gcc_cv_ld_compress_debug=0
-  elif test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 26; then
-gcc_cv_ld_compress_debug=1
   else
 gcc_cv_ld_compress_debug=3
 gcc_cv_ld_compress_debug_option="--compress-debug-sections"
   fi
-  if test $ld_is_gold = yes; then
-gcc_cv_ld_compress_debug=2
-gcc_cv_ld_compress_debug_option="--compress-debug-sections"
-

Re: [PATCH] Remove legacy -gz=zlib-gnu

[Fangrui Song via Gcc-patches]

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`), no project uses
-gz=zlib-gnu (valgrind has a configure to use -gz=zlib).
Remove support for the legacy zlib-gnu and simplify configure.ac by
removing zlib-gnu ld/as check.


A couple of things, you are missing a changelog.


Sorry.


Second, why remove something which is still working?


It's unused and its existence causes confusion: the paradox of choice.
People may assume the support may be good but newer DWARF consumers may
not support the legacy format.

The other motivation is to clean up it a bit.  I foresee that someone
will add --compress-debug-sections=zstd to binutils and configure.ac and
gcc/gcc.cc would become more messy.


Third, why not just make gz=zlib-gnu as an alias to gz=zlib instead so
if someone used it before it will still work. we try not to remove
options; have them emit a warning and be ignored (or moved over to the
closed option).


Changing the semantics of -gz=zlib-gnu would be even more confusing.


Thanks,
Andrew


---
 gcc/common.opt  |  3 ---
 gcc/configure   | 33 ++---
 gcc/configure.ac| 29 -
 gcc/doc/invoke.texi | 11 +--
 gcc/gcc.cc  | 22 ++
 5 files changed, 17 insertions(+), 81 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index e7a51e882ba..8754d93d545 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3424,9 +3424,6 @@ Enum(compressed_debug_sections) String(none) Value(0)
 EnumValue
 Enum(compressed_debug_sections) String(zlib) Value(1)

-EnumValue
-Enum(compressed_debug_sections) String(zlib-gnu) Value(2)
-
 gz
 Common Driver
 Generate compressed debug sections.
diff --git a/gcc/configure b/gcc/configure
index 62872d132ea..ca87e875e9d 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19674,7 +19674,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19679 "configure"
+#line 19677 "configure"
 #include "confdefs.h"

 #if HAVE_DLFCN_H
@@ -19780,7 +19780,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19785 "configure"
+#line 19783 "configure"
 #include "confdefs.h"

 #if HAVE_DLFCN_H
@@ -29711,20 +29711,13 @@ else
if $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s 2>&1 | grep 
-i warning > /dev/null
then
  gcc_cv_as_compress_debug=0
-   # Since binutils 2.26, gas supports --compress-debug-sections=type,
+   # Since binutils 2.26, gas supports --compress-debug-sections=zlib,
# defaulting to the ELF gABI format.
-   elif $gcc_cv_as --compress-debug-sections=zlib-gnu -o conftest.o conftest.s > 
/dev/null 2>&1
+   elif $gcc_cv_as --compress-debug-sections=zlib -o conftest.o conftest.s > 
/dev/null 2>&1
then
  gcc_cv_as_compress_debug=2
  gcc_cv_as_compress_debug_option="--compress-debug-sections"
  gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections"
-   # Before binutils 2.26, gas only supported --compress-debug-options and
-   # emitted the traditional GNU format.
-   elif $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s > /dev/null 
2>&1
-   then
- gcc_cv_as_compress_debug=1
- gcc_cv_as_compress_debug_option="--compress-debug-sections"
- gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections"
else
  gcc_cv_as_compress_debug=0
fi
@@ -30238,42 +30231,28 @@ $as_echo "$gcc_cv_ld_eh_gc_sections_bug" >&6; }

 { $as_echo "$as_me:${as_lineno-$LINENO}: checking linker for compressed debug 
sections" >&5
 $as_echo_n "checking linker for compressed debug sections... " >&6; }
-# gold/gld support compressed debug sections since binutils 2.19/2.21
-# In binutils 2.26, gld gained support for the ELF gABI format.
+# GNU ld/gold support --compressed-debug-sections=zlib since binutils 2.26.
 if test $in_tree_ld = yes ; then
   gcc_cv_ld_compress_debug=0
   if test $ld_is_mold = yes; then
 gcc_cv_ld_compress_debug=3
 gcc_cv_ld_compress_debug_option="--compress-debug-sections"
-  elif test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 19 -o 
"$gcc_cv_gld_major_version" -gt 2 \
- && test $in_tree_ld_is_elf = yes && test $ld_is_gold = yes; then
-gcc_cv_ld_compress_debug=2
-gcc_cv_ld_compress_debug_option="--compress-debug-sections"
   elif test "$gcc_cv_gld_major_version" -eq 2

Re: [PATCH] Mips: Enable asynchronous unwind tables with both ASAN and TSAN

[Fangrui Song via Gcc-patches]

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 failures for tls_race.c:
> > >
> > > FAIL: c-c++-common/tsan/tls_race.c   -O0  output pattern test
> > > Output was:
> > > ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:452
> > > "((thr_end)) <= ((tls_addr + tls_size))" (0xffec35f8c0,
> > > 0xffec35f784) (tid=748216)
> > > #0 __tsan::CheckUnwind()
> > > ../../../../gcc/libsanitizer/tsan/tsan_rtl.cpp:627
> > > (libtsan.so.2+0xa30ec)
> > > #1 __sanitizer::CheckFailed(char const*, int, char const*,
> > > unsigned long long, unsigned long long)
> > > ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_termination.
> > > cpp:86 (libtsan.so.2+0xeb8cc)
> > > #2 __tsan::ImitateTlsWrite(__tsan::ThreadState*, unsigned long,
> > > unsigned long)
> > > ../../../../gcc/libsanitizer/tsan/tsan_platform_linux.cpp:452
> > > (libtsan.so.2+0xa0cac)
> > > #3 __tsan::ThreadStart(__tsan::ThreadState*, unsigned int,
> > > unsigned long long, __sanitizer::ThreadType)
> > > ../../../../gcc/libsanitizer/tsan/tsan_rtl_thread.cpp:197
> > > (libtsan.so.2+0xc0e88)
> > > #4 __tsan_thread_start_func
> > > ../../../../gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1009
> > > (libtsan.so.2+0x3e5dc)
> > > #5 start_thread /sources/glibc-2.35/nptl/pthread_create.c:442
> > > (libc.so.6+0xc75f4)
> > >
> > > I've tried to diagnose the root cause but failed.
> >
> > Hi Xi, thanks for looking into this. I've tried running the testsuite
> > on a cross-toolchain (as I do not currently have access to a physical
> > machine)
> > for a MIPS64R6 and the test passes successfully. Could you please
> > verify that the test fails solely based on this change?
>
> I guess you mean you are running MIPS64R6 target code with qemu?  I'm
> not 100% sure because maybe something is wrong in my system.  I'm now
> retrying on gcc230.fsffrance.org (an EdgeRouter 4 in Cfarm) but building
> GCC on it is really slow.
>
> The changes I've tested:
>
> diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> index 5eb845960e1..a7f0580e9ba 100644
> --- a/gcc/config/mips/mips.cc
> +++ b/gcc/config/mips/mips.cc
> @@ -20115,10 +20115,11 @@ mips_option_override (void)
> target_flags |= MASK_64BIT;
>  }
>
> -  /* -fsanitize=address needs to turn on -fasynchronous-unwind-tables in
> - order for tracebacks to be complete but not if any
> - -fasynchronous-unwind-table were already specified.  */
> -  if (flag_sanitize & SANITIZE_USER_ADDRESS
> +  /* For -fsanitize=address or -fsanitize=thread, it's needed to turn
> + on -fasynchronous-unwind-tables in order for tracebacks
> + to be complete but not if any -fasynchronous-unwind-table
> + were already specified.  */
> +  if (flag_sanitize & (SANITIZE_USER_ADDRESS | SANITIZE_THREAD)
>&& !global_options_set.x_flag_asynchronous_unwind_tables)
>  flag_asynchronous_unwind_tables = 1;
>
> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> index fb89df4935c..52546bbe4e3 100644
> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -55,6 +55,9 @@ case "${target}" in
>arm*-*-linux*)
> ;;
>mips*-*-linux*)
> +   if test x$ac_cv_sizeof_void_p = x8; then
> +   TSAN_SUPPORTED=yes
> +   fi
> ;;
>aarch64*-*-linux*)
> if test x$ac_cv_sizeof_void_p = x8; then
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Drive-by comment.

Clang considers that asan/msan/tsan/dataflow/etc enables
-fasynchronous-unwind-tables by default so I assume this GCC change is
fine.

With https://reviews.llvm.org/D102046 ("[sanitizer] Fall back to fast
unwinder"), compiler-rt may fall back to the frame pointer based
unwinder. There is not strong need to have the default
-fasynchronous-unwind-tables or -funwind-tables behavior.
However, most targets still default to omit frame pointer, so it's a
bit unfortunately that we need to enable unwind tables to get good
diagnostics.

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

[Fangrui Song via Gcc-patches]

On 2022-07-14, Palmer Dabbelt wrote:

On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng  wrote:


Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix,
otherwise that will break multilib on GNU toolchain for linux
immediately?


IIUC just changing this will break even non-multlib systems, though 
it's possible that the symlinks work around that sufficiently.



Thanks 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.


I'm kind of torn on this one: this has been around for a while and 
dropping it would be an ABI break, but the feedback from distro folks 
is pretty consistently that multlib is broken on RISC-V.  If it's 
really unusably broken then I could buy the argument that there's no 
binaries (and thus no ABI to break), but there's at some base multilib 
functionality working -- I build multilib cross toolchains regularly, 
for example, and they can build simple stuff.


I always find making that "nobody's used it" argument really hard, 
there's just too many users to try and track everyone down.  We're in 
kind of a weird spot with RISC-V in general when it comes to ABI 
stuff: we were probably a bit overly optimistic about how fast any of 
this was going to get used when we committed to the ABI freeze, but 
any ABi break has such a huge potential for user headaches that I'm 
not sure it's going to be possible.  It means we're stuck with some 
baggage, and while it's a headache to keep around stuff that's 
probably not all that useful I think it's just what we've got to live 
with.


If multlib really is so broken it's not fixable without an ABI break 
then I guess there's no other option, but I think in this case we have 
some:


One option would be to add an ld argument that says to turn off the 
emulation-specific path resolution, which we could then add to 
LINK_SPEC when we get the library paths sorted out?  We'd still have 
the emulations and the subdirs, but at least we wouldn't need a flag 
day.


Another option would be to add new multlib paths that don't have the 
subdirectories, as last I checked that was an issue for distros 
(violates FHS, breaks build systems, etc).  If we're going to do that 
anyway then we could piggyback the new behavior on it and deprecate 
the old paths along with whatever behavior is associated with them.


Thanks for chiming in and providing the good consideration.  I don't do
much GNU development.  I just spotted something and think it should be
fixed.  If dropping -L is considered a risk, an alternative scheme is
that someone:

* create an alternative patch making GCC driver pass the -L to ld and use the 
plain emulation name.
* a configure option can possibly be added to guard whether the -L is added at 
all
* drop the excessive emulations in GNU ld.

This way an alternative linker implementation doesn't have to add a
compatibility no-op option.

I appreciate anyone who wants to step up and helps removing
eelf64lriscv_{lp64,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=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 -L.  Different platforms have
different opinions on the hierarchy and all other arches work well without ld's
default -L.
* If some ABI derived library paths are desired, the compiler driver is in a
better position to make the decision and traditionally has done this.
* -m emulation is opaque to the compiler driver.  It doesn't affect -B, so
data files like crt*.o, libasan_preinit.o, and libtsan_preinit.o are not 
affected.

As is, many platforms just use symlinks to fake the lib64/{ilp32{,f},lp64{,f}}
hierarchies needed by the GNU ld emulation.  They can always specify -L
explicitly if they want some ABI derived library paths.  See also the rejected
https://reviews.llvm.org/D95755


I don't do a lot of LLVM stuff, but that has a green check mark that 
says "accepted" at the top.  Does that mean it was merged somewhere, 
or just that it was acked/reviewed and then dropped?


I could land it, but I realized that would be a mistake so I stopped.
There has since been no real need for this feature, either.  I wished
that some RISC-V folks stepped up and fixed it.  It took 

Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

[Fangrui Song via Gcc-patches]

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  
> > > > wrote:
> > >
> > > >> The use of @GOTOFF for locally-bound but externally-visible symbols
> > > >> (e.g. protected visibility) also breaks pointer identity if the
> > > >> canonical address ends up preempted by a PLT entry.
> > >
> > > > Here is a different fix:
> > >
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html
> > >
> > > Oh, thanks, I'd missed that.
> > >
> > > It doesn't seem to fix the part of the problem I quoted above, though.
> > > I think fixing that requires testing the visibility, to make sure the
> > > symbol's canonical address cannot be preempted, which may occur with
> > > local binding, if the symbol is protected and referenced in the main
> > > program, otherwise pointer identity is broken again, admittedly for a
> > > more obscure case, but pointer identity was the point of the PR.
> >
> > The protected symbol issue isn't IFUNC specific.   The protected
> > symbol handling is changed in glibc 2.36 and binutils 2.39.   Only
> > the address of the protected symbol definition should be used as
> > its address.
> >
> > > >> * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
> > > >> chain looking for an ifunc, as in gcc.target/i386/mvc10.c.
> > >
> > > You may also need to do something like this bit for mvc10.c on ia32 PIE.
> > > Because the ifunc is called through an alias, AFAICT we don't even
> > > notice that the call target is (an alias to) an ifunc.  GCC's
> > > gotoff_operand predicate accepts it, but binutils (the linker, IIRC)
> > > then rejects that reference, because the named symbol is an alias to an
> > > ifunc.
> >
> > Yes, this change is needed.
>
> I think this fix should be applied to default_binds_local_p_3:
>
>   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (exp))
>   || (!targetm.ifunc_ref_local_ok ()
>   && TREE_CODE (exp) == FUNCTION_DECL
>   && cgraph_node::get (exp)
>   && cgraph_node::get (exp)->ifunc_resolver))
> return false;
>
> since the ifunc_resolver check won't work on aliases.
>
> --
> H.J.

A note if people are going to refactor default_binds_local_p_3 or add
a new default_binds_local_p_* variant (unrelated to the ifunc
problem):
extern_protected_data == true is now legacy. For new variants we want
all extern_protected_data == false.

Re: [PATCH] i386 testsuite: cope with --enable-default-pie

[Fangrui Song via Gcc-patches]

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, Alexandre Oliva  wrote:
>
> > for  gcc/testsuite/ChangeLog
>
> >   * g++.dg/abi/anon1.C: Disable pie on ia32.
> >   * g++.dg/abi/anon4.C: Likewise.
> >   * g++.dg/cpp0x/initlist-const1.C: Likewise.
> >   * g++.dg/no-stack-protector-attr-3.C: Likewise.
> >   * g++.dg/stackprotectexplicit2.C: Likewise.
> >   * g++.dg/pr71694.C: Likewise.
> >   * gcc.dg/pr102892-1.c: Likewise.
> >   * gcc.dg/sibcall-11.c: Likewise.
> >   * gcc.dg/torture/builtin-self.c: Likewise.
> >   * gcc.target/i386/avx2-dest-false-dep-for-glc.c: Likewise.
> >   * gcc.target/i386/avx512bf16-cvtsbh2ss-1.c: Likewise.
> >   * gcc.target/i386/avx512f-broadcast-pr87767-1.c: Likewise.
> >   * gcc.target/i386/avx512f-broadcast-pr87767-3.c: Likewise.
> >   * gcc.target/i386/avx512f-broadcast-pr87767-5.c: Likewise.
> >   * gcc.target/i386/avx512f-broadcast-pr87767-7.c: Likewise.
> >   * gcc.target/i386/avx512fp16-broadcast-1.c: Likewise.
> >   * gcc.target/i386/avx512fp16-pr101846.c: Likewise.
> >   * gcc.target/i386/avx512vl-broadcast-pr87767-1.c: Likewise.
> >   * gcc.target/i386/avx512vl-broadcast-pr87767-3.c: Likewise.
> >   * gcc.target/i386/avx512vl-broadcast-pr87767-5.c: Likewise.
> >   * gcc.target/i386/pr100865-2.c: Likewise.
> >   * gcc.target/i386/pr100865-3.c: Likewise.
> >   * gcc.target/i386/pr100865-4a.c: Likewise.
> >   * gcc.target/i386/pr100865-4b.c: Likewise.
> >   * gcc.target/i386/pr100865-5a.c: Likewise.
> >   * gcc.target/i386/pr100865-5b.c: Likewise.
> >   * gcc.target/i386/pr100865-6a.c: Likewise.
> >   * gcc.target/i386/pr100865-6b.c: Likewise.
> >   * gcc.target/i386/pr100865-6c.c: Likewise.
> >   * gcc.target/i386/pr100865-7b.c: Likewise.
> >   * gcc.target/i386/pr101796-1.c: Likewise.
> >   * gcc.target/i386/pr101846-2.c: Likewise.
> >   * gcc.target/i386/pr101989-broadcast-1.c: Likewise.
> >   * gcc.target/i386/pr102021.c: Likewise.
> >   * gcc.target/i386/pr90773-17.c: Likewise.
> >   * gcc.target/i386/pr54855-3.c: Likewise.
> >   * gcc.target/i386/pr54855-7.c: Likewise.
> >   * gcc.target/i386/pr15184-1.c: Likewise.
> >   * gcc.target/i386/pr15184-2.c: Likewise.
> >   * gcc.target/i386/pr27971.c: Likewise.
> >   * gcc.target/i386/pr70263-2.c: Likewise.
> >   * gcc.target/i386/pr78035.c: Likewise.
> >   * gcc.target/i386/pr81736-5.c: Likewise.
> >   * gcc.target/i386/pr81736-7.c: Likewise.
> >   * gcc.target/i386/pr85620-6.c: Likewise.
> >   * gcc.target/i386/pr85667-6.c: Likewise.
> >   * gcc.target/i386/pr93492-5.c: Likewise.
> >   * gcc.target/i386/pr96539.c: Likewise.
> >   PR target/81708 (%gs:my_guard)
> >   * gcc.target/i386/stack-prot-sym.c: Likewise.
> >   * g++.dg/init/static-cdtor1.C: Add alternate patterns for PIC.
> >   * gcc.target/i386/avx512fp16-vcvtsh2si-1a.c: Extend patterns
> >   for PIC/PIE register allocation.
> >   * gcc.target/i386/pr100704-3.c: Likewise.
> >   * gcc.target/i386/avx512fp16-vcvtsh2usi-1a.c: Likewise.
> >   * gcc.target/i386/avx512fp16-vcvttsh2si-1a.c: Likewise.
> >   * gcc.target/i386/avx512fp16-vcvttsh2usi-1a.c: Likewise.
> >   * gcc.target/i386/avx512fp16-vmovsh-1a.c: Likewise.
> >   * gcc.target/i386/interrupt-11.c: Likewise, allowing for
> >   preservation of the PIC register.
> >   * gcc.target/i386/interrupt-12.c: Likewise.
> >   * gcc.target/i386/interrupt-13.c: Likewise.
> >   * gcc.target/i386/interrupt-15.c: Likewise.
> >   * gcc.target/i386/interrupt-16.c: Likewise.
> >   * gcc.target/i386/interrupt-17.c: Likewise.
> >   * gcc.target/i386/interrupt-8.c: Likewise.
> >   * gcc.target/i386/cet-sjlj-6a.c: Combine patterns from
> >   previous change.
> >   * gcc.target/i386/cet-sjlj-6b.c: Likewise.
> >   * gcc.target/i386/pad-10.c: Accept insns in get_pc_thunk.
> >   * gcc.target/i386/pr70321.c: Likewise.
> >   * gcc.target/i386/pr81563.c: Likewise.
> >   * gcc.target/i386/pr84278.c: Likewise.
> >   * gcc.target/i386/pr90773-2.c: Likewise, plus extra loads from
> >   the GOT.
> >   * gcc.target/i386/pr90773-3.c: Likewise.
> >   * gcc.target/i386/pr94913-2.c: Accept additional PIC insns.
> >   * gcc.target/i386/stack-check-17.c: Likewise.
> >   * gcc.target/i386/stack-check-12.c: Do not require dummy stack
> >   probing obviated with PIC.
> >   * gcc.target/i386/pr95126-m32-1.c: Expect missed optimization
> >   with PIC.
> >   * gcc.target/i386/pr95126-m32-2.c: Likewise.
> >   * gcc.target/i386/pr95852-2.c: Accept different optimization
> >   with PIC

Re: [PATCH v4] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 output sections.  If small and medium code
> model object files are mixed, the .l* sections won't exert relocation
> overflow pressure on sections in object files built with -mcmodel=small.
>
> However, when using -mcmodel=large, -mlarge-data-threshold doesn't
> apply.  This means that the .rodata/.data/.bss sections may exert
> relocation overflow pressure on sections in -mcmodel=small object files.
>
> This patch allows -mcmodel=large to generate .l* sections and drops an
> unneeded documentation restriction that the value must be the same.
>
> Link: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
> ("Large data sections for the large code model")
>
> Signed-off-by: Fangrui Song 
>
> ---
> Changes from v1 
> (https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616947.html):
> * Clarify commit message. Add link to 
> https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
>
> Changes from v2
> * Drop an uneeded limitation in the documentation.
>
> Changes from v3
> * Change scan-assembler directives to use \. to match literal .
> ---
>  gcc/config/i386/i386.cc| 15 +--
>  gcc/config/i386/i386.opt   |  2 +-
>  gcc/doc/invoke.texi|  6 +++---
>  gcc/testsuite/gcc.target/i386/large-data.c | 13 +
>  4 files changed, 26 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c
>
> [...]

Ping:)

Re: [PATCH v3] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 } */
>> > +/* { dg-require-effective-target lp64 } */
>> > +/* { dg-options "-O2 -mcmodel=large -mlarge-data-threshold=4" } */
>> > +/* { dg-final { scan-assembler ".lbss" } } */
>> > +/* { dg-final { scan-assembler ".bss" } } */
>> > +/* { dg-final { scan-assembler ".ldata" } } */
>> > +/* { dg-final { scan-assembler ".data" } } */
>> > +/* { dg-final { scan-assembler ".lrodata" } } */
>> > +/* { dg-final { scan-assembler ".rodata" } } */
>>
>> Aren't these regex-es, and hence the dots all need escaping or enclosing
>> in square brackets?
>>
>> Jan
>>
>
> Good catch! I am not familiar with dg-* directives... I can send a v4, but
> I'd like to know whether there are other comments.
> (I don't have git write permission for gcc.)
>
>
> --
> 宋方睿
>

Ping. Do people have other suggestions?


-- 
宋方睿

Re: [PATCH] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 are mixed, the .l* sections won't cause
> > relocation overflow pressure on sections in -mcmodel=small object files.
> >
> > However, when using -mcmodel=large, -mlarge-data-threshold doesn't apply.  
> > This
> > means that the .rodata/.data/.bss sections may cause relocation overflow
> > pressure on sections in -mcmodel=small object files.
> >
> > This patch allows -mcmodel=large to generate .l* sections.
>
> The x86_64 psABI does not specify how -mlarge-threshold is handled
> with -mcmodel=large and it also doesn't mention that -mcmodel=large
> inherits handling from -mcmodel=medium. The ABI does say that the
> -mcmodel=large is strictly only required if the text of a single
> function becomes larger than what the medium model allows.
>
> OTOH, the ABI also doesn't prohibit large sections with -mcmodel=large
> and IMO, the introduction of -mlarge-threshold with -mcmodel=large
> does not create an ABI change.
>
> I think the best way is to first discuss the issue with the x86_64
> psABI group, to clarify how -mlarge-threshold and large data is
> handled under a large code model.
>
> Uros.

Thank you for the suggestion. I started
https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU ("Large data
sections for the large code model")
and created https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/42/
to clarify large data sections usage.

In the psABI, "Table 4.4: Additional Special Sections for the Large
Code Model"  lists the large data sections.
Perhaps it should be "Table 4.4: Additional Special Sections for the
Medium and Large Code Models".

> >
> > Signed-off-by: Fangrui Song 
> > ---
> >  gcc/config/i386/i386.cc| 15 +--
> >  gcc/config/i386/i386.opt   |  2 +-
> >  gcc/doc/invoke.texi|  7 ---
> >  gcc/testsuite/gcc.target/i386/large-data.c | 13 +
> >  4 files changed, 27 insertions(+), 10 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index a3db55642e3..c68c66a5567 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -637,7 +637,8 @@ ix86_can_inline_p (tree caller, tree callee)
> >  static bool
> >  ix86_in_large_data_p (tree exp)
> >  {
> > -  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC)
> > +  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC &&
> > +  ix86_cmodel != CM_LARGE && ix86_cmodel != CM_LARGE_PIC)
> >  return false;
> >
> >if (exp == NULL_TREE)
> > @@ -848,8 +849,9 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
> > const char *name, unsigned HOST_WIDE_INT size,
> > unsigned align)
> >  {
> > -  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
> > -  && size > (unsigned int)ix86_section_threshold)
> > +  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
> > +  ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
> > + size > (unsigned int)ix86_section_threshold)
> >  {
> >switch_to_section (get_named_section (decl, ".lbss", 0));
> >fputs (LARGECOMM_SECTION_ASM_OP, file);
> > @@ -869,9 +871,10 @@ void
> >  x86_output_aligned_bss (FILE *file, tree decl, const char *name,
> > unsigned HOST_WIDE_INT size, unsigned align)
> >  {
> > -  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
> > -  && size > (unsigned int)ix86_section_threshold)
> > -switch_to_section (get_named_section (decl, ".lbss", 0));
> > +  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
> > +   ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
> > +  size > (unsigned int)ix86_section_threshold)
> > +switch_to_section(get_named_section(decl, ".lbss", 0));
> >else
> >  switch_to_section (bss_section);
> >ASM_OUTPUT_ALIGN (file, floor_log2 (align / BITS_PER_UNIT));
> > diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> > index d74f6b1f8fc..de8e722cd62 100644
> > --- a/gcc/config/i386/i386.opt
> > +++ b/gcc/config/i386/i386.opt
> > @@ -282,7 +282,7 @@ Branches are this expensive (arbitrary units).
> >
> >  mlarge-data-threshold=
> >  Target RejectNegative Joined UInteger Var(ix86_section_threshold) 
> > Init(DEFAULT_LARGE_SECTION_THRESHOLD)
> > --mlarge-data-threshold=Data greater than given threshold 
> > will go into .ldata section in x86-64 medium model.
> > +-mlarge-data-threshold=Data greater than given threshold 
> > will go into a large data section in x86-64 medium and large code models.
> >
> >  mcmodel=
> >  Target Rejec

[PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 mixed, the .l* sections won't exert relocation
overflow pressure on sections in object files built with -mcmodel=small.

However, when using -mcmodel=large, -mlarge-data-threshold doesn't
apply.  This means that the .rodata/.data/.bss sections may exert
relocation overflow pressure on sections in -mcmodel=small object files.

This patch allows -mcmodel=large to generate .l* sections.

Link: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
("Large data sections for the large code model")

Signed-off-by: Fangrui Song 

---
Changes from v1 
(https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616947.html):
* Clarify commit message. Add link to 
https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
---
 gcc/config/i386/i386.cc| 15 +--
 gcc/config/i386/i386.opt   |  2 +-
 gcc/doc/invoke.texi|  7 ---
 gcc/testsuite/gcc.target/i386/large-data.c | 13 +
 4 files changed, 27 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 202abf0b39c..3568da4f053 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -637,7 +637,8 @@ ix86_can_inline_p (tree caller, tree callee)
 static bool
 ix86_in_large_data_p (tree exp)
 {
-  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC)
+  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC &&
+  ix86_cmodel != CM_LARGE && ix86_cmodel != CM_LARGE_PIC)
 return false;
 
   if (exp == NULL_TREE)
@@ -848,8 +849,9 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
const char *name, unsigned HOST_WIDE_INT size,
unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+  ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+ size > (unsigned int)ix86_section_threshold)
 {
   switch_to_section (get_named_section (decl, ".lbss", 0));
   fputs (LARGECOMM_SECTION_ASM_OP, file);
@@ -869,9 +871,10 @@ void
 x86_output_aligned_bss (FILE *file, tree decl, const char *name,
unsigned HOST_WIDE_INT size, unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
-switch_to_section (get_named_section (decl, ".lbss", 0));
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+   ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+  size > (unsigned int)ix86_section_threshold)
+switch_to_section(get_named_section(decl, ".lbss", 0));
   else
 switch_to_section (bss_section);
   ASM_OUTPUT_ALIGN (file, floor_log2 (align / BITS_PER_UNIT));
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index d74f6b1f8fc..de8e722cd62 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -282,7 +282,7 @@ Branches are this expensive (arbitrary units).
 
 mlarge-data-threshold=
 Target RejectNegative Joined UInteger Var(ix86_section_threshold) 
Init(DEFAULT_LARGE_SECTION_THRESHOLD)
--mlarge-data-threshold=Data greater than given threshold will 
go into .ldata section in x86-64 medium model.
+-mlarge-data-threshold=Data greater than given threshold will 
go into a large data section in x86-64 medium and large code models.
 
 mcmodel=
 Target RejectNegative Joined Enum(cmodel) Var(ix86_cmodel) Init(CM_32)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ee78591c73e..4b5391e12b5 100644
--- 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 @option{-mcmodel=medium} is specified, data objects larger than
-@var{threshold} are placed in the large data section.  This value must be the
-same across all objects linked into the binary, and defaults to 65535.
+When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified, data
+objects larger than @var{threshold} are placed in large data sections.  This
+value must be the same across all objects linked into the binary, and defaults
+to 65535.
 
 @opindex mrtd
 @item -mrtd
diff --git a/gcc/testsuite/gcc.target/i386/large-data.c 
b/gcc/testsuite/gcc.target/i386/large-data.c
new file mode 100644
index 000..09a917431d4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/large-data.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target lp6

Re: [PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 @option{-mcmodel=medium} is specified, data objects larger than
-@var{threshold} are placed in the large data section.  This value must be the
-same across all objects linked into the binary, and defaults to 65535.
+When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified, data
+objects larger than @var{threshold} are placed in large data sections.  This
+value must be the same across all objects linked into the binary, and defaults
+to 65535.


Where's the "must be the same" requirement coming from?


It's an existing requirement.  I think it may be related to discouraging
different COMDAT sections names due to different -mlarge-data-threshold=.
I don't think it makes sense but did not feel strongly dropping it.

Happy to drop the requirement if I revise this patch.


As to the default - to remain compatible with earlier versions, shouldn't
large model code default to "infinity"?

Jan


I have thought about this compatibility need and feel that it is very
unlikly to be needed.  GNU ld has supported large data sections since
2005
(https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3b22753a67cf616514de804ef6d5ed5e90a7d883).
Users' programs with the internal linker scripts will still be working
and -fdata-sections sections will be combined.

First, -mcmodel=large use cases are rare enough.  Rare perhaps
-mcmodel=largel was considered theoretic excercise  in
trying to reach feature completion
(https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU/m/NNuA0P7pAQAJ),
without this patch -mcmodel=large object files don't interract well with
existing -mcmodel=small object files.
Moreover, if a user expects a specific section prefix with
-mcmodel=large, that's a brittle assumption. I think it's fair to say
that the fault is on the user side and GCC doesn't need to work around
their issues.

Re: [PATCH] Remove legacy -gz=zlib-gnu

[Fangrui Song via Gcc-patches]

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 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`), no project uses
> > >>> -gz=zlib-gnu (valgrind has a configure to use -gz=zlib).
> > >>> Remove support for the legacy zlib-gnu and simplify configure.ac by
> > >>> removing zlib-gnu ld/as check.
> > >>
> > >> A couple of things, you are missing a changelog.
> > >
> > > Sorry.
> > >
> > >> Second, why remove something which is still working?
> >
> > Hi.
> >
> > I do support the option removal, while I would replace the removal with a 
> > warning
> > saying no compression will be used.
> >
> > >
> > > It's unused and its existence causes confusion: the paradox of choice.
> > > People may assume the support may be good but newer DWARF consumers may
> > > not support the legacy format.
> >
> > Agree, the compression format is legacy. I verified all openSUSE packages 
> > (15k)
> > and there's no project actively using it.
> >
> > >
> > > The other motivation is to clean up it a bit.  I foresee that someone
> > > will add --compress-debug-sections=zstd to binutils and configure.ac and
> > > gcc/gcc.cc would become more messy.
> >
> > The argument makes sense, it will be even bigger mess.
> >
> > @Richi: Is it something we can deprecate for GCC 13?
>
> What's the practical difference between zlib and zlib-gnu?  Can we just
> map zlib-gnu to zlib?  If it's all configure time what's the point in
> "deprecating" it?

zlib-gnu uses the legacy .zdebug section name with a "ZLIB" magic:
http://www.linker-aliens.org/blogs/ali/entry/elf_section_compression/
https://maskray.me/blog/2022-01-23-compressed-debug-sections has some
history about how the zlib-gabi replacement: ELFCOMPRESS_ZLIB .

FWIW I removed -gz=zlib-gnu from clang and .zdebug support from
various llvm-project tools.

I cannot really find uses of -gz=zlib-gnu in the wild. Users can
always fallback to -Wa, and -Wl, if their tools are so old that
ELFCOMPRESS_ZLIB is unsupported.

> Richard.
>
> >
> > Martin
> >
> > >
> > >> Third, why not just make gz=zlib-gnu as an alias to gz=zlib instead so
> > >> if someone used it before it will still work. we try not to remove
> > >> options; have them emit a warning and be ignored (or moved over to the
> > >> closed option).
> > >
> > > Changing the semantics of -gz=zlib-gnu would be even more confusing.
> > >
> > >> Thanks,
> > >> Andrew
> > >>
> > >>> ---
> > >>>  gcc/common.opt  |  3 ---
> > >>>  gcc/configure   | 33 ++---
> > >>>  gcc/configure.ac| 29 -
> > >>>  gcc/doc/invoke.texi | 11 +--
> > >>>  gcc/gcc.cc  | 22 ++
> > >>>  5 files changed, 17 insertions(+), 81 deletions(-)
> > >>>
> > >>> diff --git a/gcc/common.opt b/gcc/common.opt
> > >>> index e7a51e882ba..8754d93d545 100644
> > >>> --- a/gcc/common.opt
> > >>> +++ b/gcc/common.opt
> > >>> @@ -3424,9 +3424,6 @@ Enum(compressed_debug_sections) String(none) 
> > >>> Value(0)
> > >>>  EnumValue
> > >>>  Enum(compressed_debug_sections) String(zlib) Value(1)
> > >>>
> > >>> -EnumValue
> > >>> -Enum(compressed_debug_sections) String(zlib-gnu) Value(2)
> > >>> -
> > >>>  gz
> > >>>  Common Driver
> > >>>  Generate compressed debug sections.
> > >>> diff --git a/gcc/configure b/gcc/configure
> > >>> index 62872d132ea..ca87e875e9d 100755
> > >>> --- a/gcc/configure
> > >>> +++ b/gcc/configure
> > >>> @@ -19674,7 +19674,7 @@ else
> > >>>lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>

Re: [PATCH v2][DOCS] changes: mentioned ignore -gz=zlib-gnu option

[Fangrui Song via Gcc-patches]

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
--compress-debug-sections=zlib-gnu.


-- 
宋方睿

Re: [COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro

[Fangrui Song via Gcc-patches]

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:
>
> * config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a
> target macro.
> ---
>  gcc/config/bpf/bpf.cc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
> index 7e37e080808..9cb56cfb287 100644
> --- a/gcc/config/bpf/bpf.cc
> +++ b/gcc/config/bpf/bpf.cc
> @@ -291,6 +291,7 @@ void
>  bpf_target_macros (cpp_reader *pfile)
>  {
>builtin_define ("__BPF__");
> +  builtin_define ("__bpf__");
>
>if (TARGET_BIG_ENDIAN)
>  builtin_define ("__BPF_BIG_ENDIAN__");
> --
> 2.30.2
>

Having multiple choices in this case seems to just add confusion to
users and making code search slightly more inconvenient.

How much code uses LLVM specific __bpf__? Can it be migrated? Should
LLVM undefine the macro instead?

Re: [COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro

[Fangrui Song via Gcc-patches]

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 macro for BPF.
> >> Tested in bpf-unknown-none.
> >>
> >> gcc/ChangeLog:
> >>
> >> * config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a
> >> target macro.
> >> ---
> >>  gcc/config/bpf/bpf.cc | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
> >> index 7e37e080808..9cb56cfb287 100644
> >> --- a/gcc/config/bpf/bpf.cc
> >> +++ b/gcc/config/bpf/bpf.cc
> >> @@ -291,6 +291,7 @@ void
> >>  bpf_target_macros (cpp_reader *pfile)
> >>  {
> >>builtin_define ("__BPF__");
> >> +  builtin_define ("__bpf__");
> >>
> >>if (TARGET_BIG_ENDIAN)
> >>  builtin_define ("__BPF_BIG_ENDIAN__");
> >> --
> >> 2.30.2
> >>
> >
> > Having multiple choices in this case seems to just add confusion to
> > users and making code search slightly more inconvenient.
> >
> > How much code uses LLVM specific __bpf__? Can it be migrated? Should
> > LLVM undefine the macro instead?
>
> I agree that it would be better to support just one form of the target
> macro.  Having two alternative forms can only lead to problems.
>
> But I think the train left the station long ago to do any better: there
> are files in the kernel tree that rely on __bpf__ and there may be BPF
> programs around doing the same thing.

Ok, thanks.

Re: [PATCH] LoongArch: add -mdirect-extern-access option

[Fangrui Song via Gcc-patches]

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 with new-reloc toolchain.  And it should be
> > also useful for building statically linked executables, firmwares (EDK2
> > for example), and other OS kernels.
>
> Some news: get rid of the GOT will also make the implementation of
> relocatable kernel easier, so I hope this can be reviewed quickly.
>
> > OK for trunk?
> >
> > -- >8 --
> >
> > As a new target, LoongArch does not use copy relocation as it's
> > problematic in some circumstances.  One bad consequence is we are
> > emitting GOT for all accesses to all extern objects with default
> > visibility.  The use of GOT is not needed in statically linked
> > executables, OS kernels etc.  The GOT entry just wastes space, and the
> > GOT access just slow down the execution in those environments.
> >
> > Before -mexplicit-relocs, we used "-Wa,-mla-global-with-pcrel" to tell
> > the assembler not to use GOT for extern access.  But with
> > -mexplicit-relocs, we have to opt the logic in GCC.
> >
> > The name "-mdirect-extern-access" is learnt from x86 port.

I think a discussion about the exact option name is useful.

The GCC x86 port generates
GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS for
-mno-direct-extern-access.

The Clang -fdirect-access-external-data (which is added before
-mdirect-extern-access) does not use
GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.

If a new port avoids copy relocations in the first place,
GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS isn't really useful.

> > gcc/ChangeLog:
> >
> > * config/loongarch/genopts/loongarch.opt.in: Add
> > -mdirect-extern-access option.
> > * config/loongarch/loongarch.opt: Regenerate.
> > * config/loongarch/loongarch.cc (loongarch_classify_symbol):
> > Don't use SYMBOL_GOT_DISP if TARGET_DIRECT_EXTERN_ACCESS.
> > (loongarch_option_override_internal): Complain if
> > -mdirect-extern-access is used with -fPIC or -fpic.
> > * doc/invoke.texi: Document -mdirect-extern-access for
> > LoongArch.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/loongarch/direct-extern-1.c: New test.
> > * gcc.target/loongarch/direct-extern-2.c: New test.
> > ---
> >  gcc/config/loongarch/genopts/loongarch.opt.in |  4 
> >  gcc/config/loongarch/loongarch.cc |  5 -
> >  gcc/config/loongarch/loongarch.opt|  4 
> >  gcc/doc/invoke.texi   | 15
> > +++
> >  .../gcc.target/loongarch/direct-extern-1.c|  6 ++
> >  .../gcc.target/loongarch/direct-extern-2.c|  6 ++
> >  6 files changed, 39 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/loongarch/direct-extern-
> > 1.c
> >  create mode 100644 gcc/testsuite/gcc.target/loongarch/direct-extern-
> > 2.c
> >
> > diff --git a/gcc/config/loongarch/genopts/loongarch.opt.in
> > b/gcc/config/loongarch/genopts/loongarch.opt.in
> > index ebdd9538d48..e10618777b2 100644
> > --- a/gcc/config/loongarch/genopts/loongarch.opt.in
> > +++ b/gcc/config/loongarch/genopts/loongarch.opt.in
> > @@ -184,3 +184,7 @@ Enum(cmodel) String(@@STR_CMODEL_EXTREME@@)
> > Value(CMODEL_EXTREME)
> >  mcmodel=
> >  Target RejectNegative Joined Enum(cmodel) Var(la_opt_cmodel)
> > Init(CMODEL_NORMAL)
> >  Specify the code model.
> > +
> > +mdirect-extern-access
> > +Target Var(TARGET_DIRECT_EXTERN_ACCESS) Init(0)
> > +Avoid using the GOT to access external symbols.
> > diff --git a/gcc/config/loongarch/loongarch.cc
> > b/gcc/config/loongarch/loongarch.cc
> > index 77e3a105390..2875fa5b0f3 100644
> > --- a/gcc/config/loongarch/loongarch.cc
> > +++ b/gcc/config/loongarch/loongarch.cc
> > @@ -1642,7 +1642,7 @@ loongarch_classify_symbol (const_rtx x)
> >if (SYMBOL_REF_TLS_MODEL (x))
> >  return SYMBOL_TLS;
> >
> > -  if (!loongarch_symbol_binds_local_p (x))
> > +  if (!TARGET_DIRECT_EXTERN_ACCESS && !loongarch_symbol_binds_local_p
> > (x))
> >  return SYMBOL_GOT_DISP;
> >
> >tree t = SYMBOL_REF_DECL (x);
> > @@ -6093,6 +6093,9 @@ loongarch_option_override_internal (struct
> > gcc_options *opts)
> >if (loongarch_branch_cost == 0)
> >  loongarch_branch_cost = loongarch_cost->branch_cost;
> >
> > +  if (TARGET_DIRECT_EXTERN_ACCESS && flag_shlib)
> > +error ("%qs cannot be used for compiling a shared library",
> > +  "-mdirect-extern-access");
> >
> >switch (la_target.cmodel)
> >  {
> > diff --git a/gcc/config/loongarch/loongarch.opt
> > b/gcc/config/loongarch/loongarch.opt
> > index 6395234218b..96c811c850b 100644
> > --- a/gcc/config/loongarch/loongarch.opt
> > +++ b/gcc/config/loongarch/loongarch.opt
> > @@ -191,3 +191,7 @@ Enum(cmodel) String(extreme) Value(CMOD

Re: [PATCH] LoongArch: add -mdirect-extern-access option

[Fangrui Song via Gcc-patches]

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 added, the function call is:
> 
>    bl %plt(test1)
> 
>  now is :
> 
>    bl test1
> >>> Regarding "%plt(...)", in the binutils code:
> >>>
> >>> /* For compatible old asm code.  */
> >>> if (0 == strcmp (op_c_str, "plt"))
> >>>   btype = BFD_RELOC_LARCH_B26;
> >>>
> >>> Link:
> >>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/loongarch-parse.y;h=8704687706df50aa15aff05f97e4560d7ec6fa23;hb=refs/heads/master#l131
> >>>
> >>> Zhensong: does "old asm code" here mean we should remove %plt from
> >>> "new"
> >>> assembly code, i. e. stop to print %plt(...) in GCC completely?
> >>>
> >>
> >> I think '%plt' also needs to be removed from the readability of the
> >> assembly code.:-\
> > I understand, but maybe we should remove %plt unconditionally, with or
> > without -mdirect-extern-access.  Note that for -mcmodel=medium we don't
> > say something like "%pc_hi20(%plt(x))" either.
>
>
> I have thought about this problem. For example, there is no '%plt' in
> aarch64, but I think it can be added and easily distinguished at the
> assembly code level,
>
> so this is not removed.

I think @plt should be removed unconditionally. It was a mistake in
some ABI (e.g. i386, riscv).

[PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

[Fangrui Song via gcc-patches]

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 ++
 gcc/collect2.c  | 67 -
 gcc/common.opt  | 14 ++
 gcc/doc/invoke.texi | 15 +++---
 gcc/gcc.c   | 14 --
 gcc/opts.c  |  4 +--
 6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   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.
+
 2020-02-09  Uroš Bizjak  
 
* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
 {
   USE_DEFAULT_LD,
   USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
 } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
 {
   "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
   static const char *const strip_suffix = "strip";
   static const char *const gstrip_suffix = "gstrip";
 
-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
  the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *use_ld = NULL;
 
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
 #endif
   int i;
 
-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
 full_ld_suffixes[i]
 #ifdef CROSS_DIRECTORY_STRUCTURE
   = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+   use_ld = argv[i] + 9;
+   selected_linker = USE_LD;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1152,8 +1146,7 @@ main (int argc, char **argv)
   /* Maybe we know the right file to use (if not cross).  */
   ld_file_name = 0;
 #ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  if (!ld_file_name && selected_linker == USE_LD)
 {
   char *linker_name;
 # ifdef HOST_EXECUTABLE_SUFFIX
@@ -1168,15 +1161,13 @@ main (int argc, char **argv)
  if (! strcmp (&default_linker[len], HOST_EXECUTABLE_SUFFIX))
{
  default_linker[len] = '\0';
- linker_name = concat (default_linker,
-   &ld_suffixes[selected_linker][2],
+ linker_name = concat (default_linker, ".", use_ld,
HOST_EXECUTABLE_SUFFIX, NULL);
}
}
   if (linker_name == NULL)
 # endif
-  linker_name = concat (DEFAULT_LINKER,
-   &ld_suffixes[selected_linker][2],
+  linker_name = concat (DEFAULT_LINKER, ".", use_ld,
NULL);
   if (access (linker_name, X_OK) == 0)
ld_file_name = linker_name;
@@ -1197,14 +1188,28 @@ main (int argc, char **argv)
   ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
   use_collect_ld = ld_file_name != 0;
 }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-  

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

[Fangrui Song via gcc-patches]

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.
---
gcc/ChangeLog   |  8 ++
gcc/collect2.c  | 67 -
gcc/common.opt  | 14 ++
gcc/doc/invoke.texi | 15 +++---
gcc/gcc.c   | 14 --
gcc/opts.c  |  4 +--
6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   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.
+
2020-02-09  Uroš Bizjak  

* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
{
  USE_DEFAULT_LD,
  USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
} selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
{
  "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
};
  static const char *const real_ld_suffix = "real-ld";
  static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
  static const char *const strip_suffix = "strip";
  static const char *const gstrip_suffix = "gstrip";

-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
#ifdef CROSS_DIRECTORY_STRUCTURE
  /* If we look for a program in the compiler directories, we just use
 the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
  const char **ld1;
  bool use_plugin = false;
  bool use_collect_ld = false;
+  const char *use_ld = NULL;

  /* The kinds of symbols we will have to consider when scanning the
 outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
#endif
  int i;

-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
full_ld_suffixes[i]
#ifdef CROSS_DIRECTORY_STRUCTURE
  = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+   use_ld = argv[i] + 9;
+   selected_linker = USE_LD;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1152,8 +1146,7 @@ main (int argc, char **argv)
  /* Maybe we know the right file to use (if not cross).  */
  ld_file_name = 0;
#ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  if (!ld_file_name && selected_linker == USE_LD)
{
  char *linker_name;
# ifdef HOST_EXECUTABLE_SUFFIX
@@ -1168,15 +1161,13 @@ main (int argc, char **argv)
  if (! strcmp (&default_linker[len], HOST_EXECUTABLE_SUFFIX))
{
  default_linker[len] = '\0';
- linker_name = concat (default_linker,
-   &ld_suffixes[selected_linker][2],
+ linker_name = concat (default_linker, ".", use_ld,
HOST_EXECUTABLE_SUFFIX, NULL);
}
}
  if (linker_name == NULL)
# endif
-  linker_name = concat (DEFAULT_LINKER,
-   &ld_suffixes[selected_linker][2],
+  linker_name = concat (DEFAULT_LINKER, ".", use_ld,
NULL);
  if (access (linker_name, X_OK) == 0)
ld_file_name = linker_name;
@@ -1197,14 +1188,28 @@ main (int argc, char **argv)
  ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
  use_collect_ld = ld_file_name != 0;
}
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_file_n

[PATCH] Align __patchable_function_entries to POINTER_SIZE

[Fangrui Song via gcc-patches]

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

---
 gcc/ChangeLog   | 5 +
 gcc/targhooks.c | 1 +
 2 files changed, 6 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 44ae44c8260..74fdb773dc9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-08  Fangrui Song  
+
+	* targhooks.c (default_print_patchable_function_entry): Align to
+	POINTER_SIZE.
+
 2020-01-08  Luo Xiong Hu  
 
 	* ipa-inline.c (caller_growth_limits): Restore the AND.
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 4819bb8058f..a3f83918f8e 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1812,6 +1812,7 @@ default_print_patchable_function_entry (FILE *file,
 
   switch_to_section (get_section ("__patchable_function_entries",
   SECTION_WRITE | SECTION_RELRO, NULL));
+  assemble_align (POINTER_SIZE);
   fputs (asm_op, file);
   assemble_name_raw (file, buf);
   fputc ('\n', file);
-- 
2.24.0

[PATCH] Add --enable-default-semantic-interposition to GCC configure

[Fangrui Song via Gcc-patches]

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
functions is the biggest difference between -fPIE/-fPIC.
Distributions may want to enable default -fno-semantic-interposition to
reclaim the lost performance (e.g. CPython is said to be 27% faster;
Clang is 3% faster).

gcc/

PR 100937
* common.opt (fsemantic-interposition): Initialize to -1.
* configure.ac: Add --enable-default-semantic-interposition. Default
to yes.
* defaults.h (DEFAULT_FLAG_SEMANTIC_INTERPOSITION): New.
* opts.c (finish_options): Update
opts->x_flag_semantic_interposition if it is -1.
* doc/install.texi: Document --enable-default-semantic-interposition.
* config.in: Add template.
* configure: Regenerate.
---
 gcc/common.opt   |  2 +-
 gcc/config.in|  6 ++
 gcc/configure| 22 --
 gcc/configure.ac | 12 
 gcc/defaults.h   |  6 ++
 gcc/doc/install.texi |  3 +++
 gcc/opts.c   |  3 +++
 7 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index ffb968d90f8..68fcbac96b1 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2480,7 +2480,7 @@ Common Var(flag_sel_sched_reschedule_pipelined) Init(0) 
Optimization
 Reschedule pipelined regions without pipelining.
 
 fsemantic-interposition
-Common Var(flag_semantic_interposition) Init(1)
+Common Var(flag_semantic_interposition) Init(-1)
 Allow interposing function (or variables) by ones with different semantics (or 
initializer) respectively by dynamic linker.
 
 ; sched_stalled_insns means that insns can be moved prematurely from the queue
diff --git a/gcc/config.in b/gcc/config.in
index e54f59ce0c3..7f1d56c1903 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -125,6 +125,12 @@
 #endif
 
 
+/* Define if -fPIC defaults to -fsemantic-interposition */
+#ifndef USED_FOR_TARGET
+#undef ENABLE_DEFAULT_SEMANTIC_INTERPOSITION
+#endif
+
+
 /* Define if your target supports default stack protector and it is enabled.
*/
 #ifndef USED_FOR_TARGET
diff --git a/gcc/configure b/gcc/configure
index 4a9e4fa08ab..3835b22f6a5 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -632,6 +632,7 @@ ac_includes_default="\
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 CET_HOST_FLAGS
+enable_default_semantic_interposition
 NO_PIE_FLAG
 NO_PIE_CFLAGS
 enable_default_pie
@@ -1027,6 +1028,7 @@ with_linker_hash_style
 with_diagnostics_color
 with_diagnostics_urls
 enable_default_pie
+enable_default_semantic_interposition
 enable_cet
 enable_s390_excess_float_precision
 '
@@ -1787,6 +1789,8 @@ Optional Features:
   --disable-libquadmath-support
   disable libquadmath support for Fortran
   --enable-default-pieenable Position Independent Executable as default
+  --enable-default-semantic-interposition
+  enable -fsemantic-interposition as -fPIC default
   --enable-cetenable Intel CET in host libraries [default=auto]
   --enable-s390-excess-float-precision
   on s390 targets, evaluate float with double
@@ -19435,7 +19439,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19438 "configure"
+#line 19454 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19541,7 +19545,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19544 "configure"
+#line 19560 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -31893,6 +31897,20 @@ if test "$gcc_cv_no_pie" = "yes"; then
 fi
 
 
+# Check whether --enable-default-semantic-interposition=no was given.
+if test "${enable_default_semantic_interposition+set}" = set; then :
+  enableval=$enable_default_semantic_interposition; 
enable_default_semantic_interposition=$enableval
+else
+  enable_default_semantic_interposition=yes
+fi
+
+if test x$enable_default_semantic_interposition != xno ; then
+
+$as_echo "#define ENABLE_DEFAULT_SEMANTIC_INTERPOSITION 1" >>confdefs.h
+
+fi
+
+
 # Enable Intel CET on Intel CET enabled host if jit is enabled.
  # Check whether --enable-cet was given.
 if test "${enable_cet+set}" = set; then :
diff --git a/gcc/configure.ac b/gcc/configure.ac
index d9fc3c219e8..1cdf8b4ce00 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -7419,6 +7419,18 @@ if test "$gcc_cv_no_pie" = "yes"; then
 fi
 AC_SUBST([NO_PIE_FLAG])
 
+# Check whether --enable-default-semantic-interposition=no was given.
+AC_ARG_ENABLE(default-semantic-interposition,
+[AS_HELP_STRING([--enable-default-semantic-interposition],
+  [enable -fsemantic-interposition as -fPIC default])],
+enable_default_semantic_interposition=$enableval,
+enable_default_semantic

[PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

[Fangrui Song via Gcc-patches]

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.
HAVE_LD_PIE_COPYRELOC has deviated from the goal.  With this change, the
-fPIE behavior of x86-64 will be closer to x86-32 and other targets.

---

See https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html for a list
of fixed and unfixed (e.g. gold incompatibility with protected
https://sourceware.org/bugzilla/show_bug.cgi?id=19823) issues.

If you prefer a longer write-up, see
https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
---
 gcc/config.in |  6 ---
 gcc/config/i386/i386.c| 11 +---
 gcc/configure | 52 ---
 gcc/configure.ac  | 48 -
 gcc/doc/sourcebuild.texi  |  3 --
 .../gcc.target/i386/pie-copyrelocs-1.c| 14 -
 .../gcc.target/i386/pie-copyrelocs-2.c| 14 -
 .../gcc.target/i386/pie-copyrelocs-3.c| 14 -
 .../gcc.target/i386/pie-copyrelocs-4.c| 17 --
 gcc/testsuite/lib/target-supports.exp | 47 -
 10 files changed, 2 insertions(+), 224 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-1.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-2.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-3.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-4.c

diff --git a/gcc/config.in b/gcc/config.in
index e54f59ce0c3..a65bf5d4176 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1659,12 +1659,6 @@
 #endif
 
 
-/* Define 0/1 if your linker supports -pie option with copy reloc. */
-#ifndef USED_FOR_TARGET
-#undef HAVE_LD_PIE_COPYRELOC
-#endif
-
-
 /* Define if your PowerPC linker has .gnu.attributes long double support. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 915f89f571a..5ec3c6fd0c9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10579,11 +10579,7 @@ legitimate_pic_address_disp_p (rtx disp)
return true;
}
  else if (!SYMBOL_REF_FAR_ADDR_P (op0)
-  && (SYMBOL_REF_LOCAL_P (op0)
-  || (HAVE_LD_PIE_COPYRELOC
-  && flag_pie
-  && !SYMBOL_REF_WEAK (op0)
-  && !SYMBOL_REF_FUNCTION_P (op0)))
+  && SYMBOL_REF_LOCAL_P (op0)
   && ix86_cmodel != CM_LARGE_PIC)
return true;
  break;
@@ -22892,10 +22888,7 @@ ix86_atomic_assign_expand_fenv (tree *hold, tree 
*clear, tree *update)
 static bool
 ix86_binds_local_p (const_tree exp)
 {
-  return default_binds_local_p_3 (exp, flag_shlib != 0, true, true,
- (!flag_pic
-  || (TARGET_64BIT
-  && HAVE_LD_PIE_COPYRELOC != 0)));
+  return default_binds_local_p_3 (exp, flag_shlib != 0, true, true, !flag_pic);
 }
 #endif
 
diff --git a/gcc/configure b/gcc/configure
index f03fe888384..c500f5ca11e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -29968,58 +29968,6 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld_pie" >&5
 $as_echo "$gcc_cv_ld_pie" >&6; }
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker PIE support with copy 
reloc" >&5
-$as_echo_n "checking linker PIE support with copy reloc... " >&6; }
-gcc_cv_ld_pie_copyreloc=no
-if test $gcc_cv_ld_pie = yes ; then
-  if test $in_tree_ld = yes ; then
-if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 25 -o "$gcc_cv_gld_major_version" -gt 2; then
-  gcc_cv_ld_pie_copyreloc=yes
-fi
-  elif test x$gcc_cv_as != x -a x$gcc_cv_ld != x ; then
-# Check if linker supports -pie option with copy reloc
-case "$target" in
-i?86-*-linux* | x86_64-*-linux*)
-  cat > conftest1.s < conftest2.s < /dev/null 2>&1 \
- && $gcc_cv_ld -shared -melf_x86_64 -o conftest1.so conftest1.o > 
/dev/null 2>&1 \
- && $gcc_cv_as --64 -o conftest2.o conftest2.s > /dev/null 2>&1 \
- && $gcc_cv_ld -pie -melf_x86_64 -o conftest conftest2.o conftest1.so 
> /dev/null 2>&1; then
-gcc_cv_ld_pie_copyreloc=yes
-  fi
-  rm -f conftest conftest1.so conftest1.o conftest2.o conftest1.s 
conftest2.s
-  ;;
-esac
-  fi
-fi
-
-cat >>confdefs.h <<_ACEOF
-#define HAVE_LD_PIE_COPYRELOC `if test x"$gcc_cv_ld_pie_copyreloc" = xyes; 
then echo 1; else echo 0; fi`
-_ACEOF
-
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld_pie_copyreloc" >&5
-$as_echo "$gcc_cv_ld_pie_copyreloc" >&6; }
-
 { $as_echo "$as_me:${as_lineno-$LINENO

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

[Fangrui Song via Gcc-patches]

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
stay.  The Solaris 11.3/x86 assembler doesn't support
R_X86_64_*GOTPCRELX.


Then I'll suggest that platforms which don't support GOTPCRELX just take
the very little performance hit (global variable access really should
not be in bottleneck of any properly written applications).

Avoiding copy relocations is *much* more important than saving few bytes
in global variable access.

If an app still wants faster variable access, use protected[1]/hidden.

[1]: protected data symbol has poor performance, which is the next thing
which should be fixed.


Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

[Fangrui Song via Gcc-patches]

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 problem before,
> > > however Qemu has fix a bug to make qemu user mode honor
> PT_GNU_STACK[1],
> > > that will cause problem when we test baremetal with qemu.
> > >
> > > So the straightforward is enable that as well for non-linux toolchian,
> > > the price is that will increase few bytes for each binary.
> > >
> > > [1]
> https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
> > >
> > > gcc/ChangeLog:
> > >
> > >   * config/riscv/linux.h (TARGET_ASM_FILE_END): Move ...
> > >   * config/riscv/riscv.cc (TARGET_ASM_FILE_END): to here.
> > OK.
> > jeff
>

Does
https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
use #define EXSTACK_DEFAULT true
for riscv?




-- 
宋方睿

Re: [PATCH v4] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 variants).  GNU ld and ld.lld 17 place
> > .l* sections into separate output sections.  If small and medium code
> > model object files are mixed, the .l* sections won't exert relocation
> > overflow pressure on sections in object files built with -mcmodel=small.
> >
> > However, when using -mcmodel=large, -mlarge-data-threshold doesn't
> > apply.  This means that the .rodata/.data/.bss sections may exert
> > relocation overflow pressure on sections in -mcmodel=small object files.
> >
> > This patch allows -mcmodel=large to generate .l* sections and drops an
> > unneeded documentation restriction that the value must be the same.
> >
> > Link: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
> > ("Large data sections for the large code model")
> >
> > Signed-off-by: Fangrui Song 
> >
> > ---
> > Changes from v1 
> > (https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616947.html):
> > * Clarify commit message. Add link to 
> > https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU
> >
> > Changes from v2
> > * Drop an uneeded limitation in the documentation.
> >
> > Changes from v3
> > * Change scan-assembler directives to use \. to match literal .
> > ---
> >  gcc/config/i386/i386.cc| 15 +--
> >  gcc/config/i386/i386.opt   |  2 +-
> >  gcc/doc/invoke.texi|  6 +++---
> >  gcc/testsuite/gcc.target/i386/large-data.c | 13 +
> >  4 files changed, 26 insertions(+), 10 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c
> >
> > [...]
>
> Ping:)

Ping:) https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625993.html

(I don't have write access to gcc.)


-- 
宋方睿

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

[Fangrui Song via gcc-patches]

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.
* collect2.c (main): Likewise.
---
gcc/ChangeLog   |  8 ++
gcc/collect2.c  | 67 -
gcc/common.opt  | 14 ++
gcc/doc/invoke.texi | 15 +++---
gcc/gcc.c   | 14 --
gcc/opts.c  |  4 +--
6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   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.
+
2020-02-09  Uroš Bizjak  

* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
   {
 USE_DEFAULT_LD,
 USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
   } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
   {
 "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
   };
 static const char *const real_ld_suffix = "real-ld";
 static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
 static const char *const strip_suffix = "strip";
 static const char *const gstrip_suffix = "gstrip";

-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
#ifdef CROSS_DIRECTORY_STRUCTURE
 /* If we look for a program in the compiler directories, we just use
the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
 const char **ld1;
 bool use_plugin = false;
 bool use_collect_ld = false;
+  const char *use_ld = NULL;

 /* The kinds of symbols we will have to consider when scanning the
outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
#endif
 int i;

-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
   full_ld_suffixes[i]
#ifdef CROSS_DIRECTORY_STRUCTURE
 = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+   use_ld = argv[i] + 9;
+   selected_linker = USE_LD;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1152,8 +1146,7 @@ main (int argc, char **argv)
 /* Maybe we know the right file to use (if not cross).  */
 ld_file_name = 0;
#ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  if (!ld_file_name && selected_linker == USE_LD)
   {
 char *linker_name;
# ifdef HOST_EXECUTABLE_SUFFIX
@@ -1168,15 +1161,13 @@ main (int argc, char **argv)
  if (! strcmp (&default_linker[len], HOST_EXECUTABLE_SUFFIX))
{
  default_linker[len] = '\0';
- linker_name = concat (default_linker,
-   &ld_suffixes[selected_linker][2],
+ linker_name = concat (default_linker, ".", use_ld,
HOST_EXECUTABLE_SUFFIX, NULL);
}
}
 if (linker_name == NULL)
# endif
-  linker_name = concat (DEFAULT_LINKER,
-   &ld_suffixes[selected_linker][2],
+  linker_name = concat (DEFAULT_LINKER, ".", use_ld,
NULL);
 if (access (linker_name, X_OK) == 0)
ld_file_name = linker_name;
@@ -1197,14 +1188,28 @@ main (int argc, char **argv)
 ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
 use_collect_ld = ld_file_name != 0;
   }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_

[PING^3][PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

[Fangrui Song via Gcc-patches]

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 (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
---
gcc/ChangeLog   |  8 ++
gcc/collect2.c  | 67 -
gcc/common.opt  | 14 ++
gcc/doc/invoke.texi | 15 +++---
gcc/gcc.c   | 14 --
gcc/opts.c  |  4 +--
6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   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.
+
2020-02-09  Uroš Bizjak  

* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
  {
USE_DEFAULT_LD,
USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
  } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
  {
"ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
  };
static const char *const real_ld_suffix = "real-ld";
static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
static const char *const strip_suffix = "strip";
static const char *const gstrip_suffix = "gstrip";

-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
#ifdef CROSS_DIRECTORY_STRUCTURE
/* If we look for a program in the compiler directories, we just use
   the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
const char **ld1;
bool use_plugin = false;
bool use_collect_ld = false;
+  const char *use_ld = NULL;

/* The kinds of symbols we will have to consider when scanning the
   outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
#endif
int i;

-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
  full_ld_suffixes[i]
#ifdef CROSS_DIRECTORY_STRUCTURE
= concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+   use_ld = argv[i] + 9;
+   selected_linker = USE_LD;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1152,8 +1146,7 @@ main (int argc, char **argv)
/* Maybe we know the right file to use (if not cross).  */
ld_file_name = 0;
#ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  if (!ld_file_name && selected_linker == USE_LD)
  {
char *linker_name;
# ifdef HOST_EXECUTABLE_SUFFIX
@@ -1168,15 +1161,13 @@ main (int argc, char **argv)
  if (! strcmp (&default_linker[len], HOST_EXECUTABLE_SUFFIX))
{
  default_linker[len] = '\0';
- linker_name = concat (default_linker,
-   &ld_suffixes[selected_linker][2],
+ linker_name = concat (default_linker, ".", use_ld,
HOST_EXECUTABLE_SUFFIX, NULL);
}
}
if (linker_name == NULL)
# endif
-  linker_name = concat (DEFAULT_LINKER,
-   &ld_suffixes[selected_linker][2],
+  linker_name = concat (DEFAULT_LINKER, ".", use_ld,
NULL);
if (access (linker_name, X_OK) == 0)
ld_file_name = linker_name;
@@ -1197,14 +1188,28 @@ main (int argc, char **argv)
ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
use_collect_ld = ld_file_name != 0;
  }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
- 

[PATCH] libstdc++: Fix the return type of __cxa_finalize according to the Itanium C++ ABI

[Fangrui Song via Gcc-patches]

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 deletion(-)

diff --git a/libstdc++-v3/libsupc++/cxxabi.h b/libstdc++-v3/libsupc++/cxxabi.h
index 50298205daa..000713ecdf8 100644
--- a/libstdc++-v3/libsupc++/cxxabi.h
+++ b/libstdc++-v3/libsupc++/cxxabi.h
@@ -127,7 +127,7 @@ namespace __cxxabiv1
   int
   __cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW;
 
-  int
+  void
   __cxa_finalize(void*);
 
   // TLS destruction.
-- 
2.25.1

[PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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 -fuse-ld={bfd,gold,lld}. If in the
future, we want to make dfferent linker option decisions we can let
-fuse-ld= represent the linker flavor and --ld-path= the linker path.

PR driver/93645
* common.opt (--ld-path=): Add --ld-path=
* opts.c (common_handle_option): Handle OPT__ld_path_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
* doc/invoke.texi: Document --ld-path=.

---
Changes in v2:
* Renamed -fld-path= to --ld-path= (clang 12.0.0 new option).
  The option does not affect code generation and is not a language feature,
  -f* is not suitable. Additionally, clang has other similar --*-path=
  options, e.g. --cuda-path=.
---
 gcc/collect2.c  | 63 +++--
 gcc/common.opt  |  4 +++
 gcc/doc/invoke.texi |  9 +++
 gcc/gcc.c   |  2 +-
 gcc/opts.c  |  1 +
 5 files changed, 64 insertions(+), 15 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index f8a5ce45994..caa1b96ab52 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -844,6 +844,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *ld_path = NULL;
 
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -961,12 +962,21 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (strncmp (argv[i], "-fuse-ld=", 9) == 0
+&& selected_linker != USE_LD_MAX)
+ {
+   if (strcmp (argv[i] + 9, "bfd") == 0)
+ selected_linker = USE_BFD_LD;
+   else if (strcmp (argv[i] + 9, "gold") == 0)
+ selected_linker = USE_GOLD_LD;
+   else if (strcmp (argv[i] + 9, "lld") == 0)
+ selected_linker = USE_LLD_LD;
+ }
+   else if (strncmp (argv[i], "--ld-path=", 10) == 0)
+ {
+   ld_path = argv[i] + 10;
+   selected_linker = USE_LD_MAX;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1117,14 +1127,34 @@ main (int argc, char **argv)
   ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
   use_collect_ld = ld_file_name != 0;
 }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
-  /* Search the ordinary system bin directories
- for `ld' (if native linking) or `TARGET-ld' (if cross).  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
X_OK);
+  if (selected_linker == USE_LD_MAX)
+{
+  /* If --ld-path= does not contain a path component separator, search for
+the command using cpath, then using path.  Otherwise find the linker
+relative to the current working directory.  */
+  if (lbasename (ld_path) == ld_path)
+   {
+ ld_file_name = find_a_file (&cpath, ld_path, X_OK);
+ if (ld_file_name == 0)
+   ld_file_name = find_a_file (&path, ld_path, X_OK);
+   }
+  else if (file_exists (ld_path))
+   {
+ ld_file_name = ld_path;
+   }
+}
+  else
+{
+  /* Search the compiler directories for `ld'.  We have protection against
+recursive calls in find_a_file.  */
+  if (ld_file_name == 0)
+   ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
+  /* Search the ordinary system bin directories
+for `ld' (if native linking) or `TARGET-ld' (if cross).  */
+  if (ld_file_name == 0)
+   ld_file_name =
+ find_a_file (&path, full_ld_suffixes[selected_linker], X_OK);
+}
 
 #ifdef REAL_NM_FILE_NAME
   nm_file_name = find_a_file (&path, REAL_NM_FILE_NAME, X_OK);
@@ -1461,6 +1491,11 @@ main (int argc, char **argv)
  ld2--;
 #endif
}
+ else if (strncmp (arg, "--ld-path=", 10) == 0)
+   {
+ ld1--;
+ ld2--;
+   }
  else if (strncmp (arg, "--sysroot=", 10) == 0)
target_system_root = arg + 10;
 

[PATCH v3] Add --ld-path= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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 path relative to the
current working directory.

--ld-path= complements and overrides -fuse-ld={bfd,gold,lld}. If in the
future, we want to make dfferent linker option decisions we can let
-fuse-ld= represent the linker flavor and --ld-path= the linker path.


Hello.

I have just few nits:

=== ERROR type #3: trailing operator (1 error(s)) ===
gcc/collect2.c:1155:14: ld_file_name =



PR driver/93645
* common.opt (--ld-path=): Add --ld-path=
* opts.c (common_handle_option): Handle OPT__ld_path_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
* doc/invoke.texi: Document --ld-path=.

---
Changes in v2:
* Renamed -fld-path= to --ld-path= (clang 12.0.0 new option).
  The option does not affect code generation and is not a language feature,
  -f* is not suitable. Additionally, clang has other similar --*-path=
  options, e.g. --cuda-path=.
---
 gcc/collect2.c  | 63 +++--
 gcc/common.opt  |  4 +++
 gcc/doc/invoke.texi |  9 +++
 gcc/gcc.c   |  2 +-
 gcc/opts.c  |  1 +
 5 files changed, 64 insertions(+), 15 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index f8a5ce45994..caa1b96ab52 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -844,6 +844,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *ld_path = NULL;
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -961,12 +962,21 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (strncmp (argv[i], "-fuse-ld=", 9) == 0
+&& selected_linker != USE_LD_MAX)
+ {
+   if (strcmp (argv[i] + 9, "bfd") == 0)
+ selected_linker = USE_BFD_LD;
+   else if (strcmp (argv[i] + 9, "gold") == 0)
+ selected_linker = USE_GOLD_LD;
+   else if (strcmp (argv[i] + 9, "lld") == 0)
+ selected_linker = USE_LLD_LD;
+ }
+   else if (strncmp (argv[i], "--ld-path=", 10) == 0)
+ {
+   ld_path = argv[i] + 10;
+   selected_linker = USE_LD_MAX;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1117,14 +1127,34 @@ main (int argc, char **argv)
   ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
   use_collect_ld = ld_file_name != 0;
 }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
-  /* Search the ordinary system bin directories
- for `ld' (if native linking) or `TARGET-ld' (if cross).  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
X_OK);
+  if (selected_linker == USE_LD_MAX)
+{
+  /* If --ld-path= does not contain a path component separator, search for
+the command using cpath, then using path.  Otherwise find the linker
+relative to the current working directory.  */
+  if (lbasename (ld_path) == ld_path)
+   {
+ ld_file_name = find_a_file (&cpath, ld_path, X_OK);
+ if (ld_file_name == 0)
+   ld_file_name = find_a_file (&path, ld_path, X_OK);
+   }
+  else if (file_exists (ld_path))
+   {


^^^ these braces are not needed.


Usually, if the 'if' branch has braces, I'd add braces to 'else' as
well.  Updated to follow your advice anyway.


+ ld_file_name = ld_path;
+   }
+}
+  else
+{
+  /* Search the compiler directories for `ld'.  We have protection against
+recursive calls in find_a_file.  */
+  if (ld_file_name == 0)


I would prefer '== NULL'.


Done.


+   ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
+  /* Search the ordinary system bin directories
+for `ld' (if native linking) or `TARGET-ld' (if cross).  */
+  if (ld_file_name == 0)
+   ld_file_name =
+ find_a_file (&path, full_ld_suffixes[selected_linker], X_OK);
+}
 #ifdef REAL_NM_FILE_NAME
   nm

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

[Fangrui Song via Gcc-patches]

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 to https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543028.html "GCC 
10.0 Status Report (2020-04-01)",
I guess GCC is not open for a new development cycle yet.
I will just answer a few questions instead of uploading a new patch.


Anyway, I'm going to provide a review (even though I'm not maintainer of that).

Can you please describe your test-case why you need such option? When using
a different ld, I typically export PATH=/path/to/binutils and then run configure
and make.


I would hope -fuse-ld=ld.bfd and -fuse-ld=ld.gold were used instead of
-fuse-ld=bfd and -fuse-ld=gold, then it would be more natural to have
-fuse-ld=/abs/path/to/ld . https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470

-fuse-ld=bfd, -fuse-ld=gold and -fuse-ld=lld are hard-coded in numerous
places. It is too late to change that.

One idea is to make

-fuse-ld=bfd
-fuse-ld=gold
-fuse-ld=lld

special. For any other value, e.g. -fuse-ld=foo or -fuse-ld=/abs/path, just 
searches the
executable named "foo" (instead of "ld.foo") or /abs/path .

Does the scheme sound good? If it is agreed, I can make a similar change to 
clang.


I noticed not ideal error message:

$ gcc -fuse-ld=pes /tmp/foo.c
collect2: fatal error: cannot find ‘ld’
compilation terminated.

while clang prints:

$clang -fuse-ld=pes /tmp/foo.c
clang-9.0: error: invalid linker name in argument '-fuse-ld=pes'

The rest of the patch is comment inline...


Thanks for all the comments.


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 ++
 gcc/collect2.c  | 67 -
 gcc/common.opt  | 14 ++
 gcc/doc/invoke.texi | 15 +++---
 gcc/gcc.c   | 14 --
 gcc/opts.c  |  4 +--
 6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   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.
+
 2020-02-09  Uroš Bizjak  
* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
 {
   USE_DEFAULT_LD,
   USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
 } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
 {
   "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
   static const char *const strip_suffix = "strip";
   static const char *const gstrip_suffix = "gstrip";
-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
  the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *use_ld = NULL;
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
 #endif
   int i;
-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
 full_ld_suffixes[i]
 #ifdef CROSS_DIRECTORY_STRUCTURE
   = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)

[PATCH] Add -fsplit-dwarf

[Fangrui Song via Gcc-patches]

-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: Add -fsplit-dwarf.
* doc/invoke.texi: Document it.
---
 gcc/common.opt  | 4 
 gcc/doc/invoke.texi | 8 
 2 files changed, 12 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..07aa9f28002 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2515,6 +2515,10 @@ fsingle-precision-constant
 Common Report Var(flag_single_precision_constant) Optimization
 Convert floating point constants to single precision constants.
 
+fsplit-dwarf
+Common Driver Var(dwarf_split_debug_info) Init(0)
+If debug information is enabled, generate debug information in separate .dwo 
files.
+
 fsplit-ivs-in-unroller
 Common Report Var(flag_split_ivs_in_unroller) Init(1) Optimization
 Split lifetimes of induction variables when loops are unrolled.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 850aeac033d..6590e60f5b3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -448,6 +448,7 @@ Objective-C and Objective-C++ Dialects}.
 -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
 -fno-eliminate-unused-debug-symbols  -femit-class-debug-always @gol
 -fno-merge-debug-strings  -fno-dwarf2-cfi-asm @gol
+-fsplit-dwarf @gol
 -fvar-tracking  -fvar-tracking-assignments}
 
 @item Optimization Options
@@ -8771,6 +8772,13 @@ also be used to change an absolute path to a relative 
path by using
 are location independent, but may require an extra command to tell GDB
 where to find the source files. See also @option{-ffile-prefix-map}.
 
+@item -fsplit-dwarf
+@opindex fsplit-dwarf
+If DWARF debugging information is enabled, separate as much debugging
+information as possible into a separate output file with the extension
+@file{.dwo}. This is similar to @option{-gsplit-dwarf}, but this option
+does not enable debugging information by itself.
+
 @item -fvar-tracking
 @opindex fvar-tracking
 Run variable tracking pass.  It computes where variables are stored at each
-- 
2.26.2.645.ge9eca65c58-goog

[PATCH] Don't make -gsplit-dwarf imply -g

[Fangrui Song via Gcc-patches]

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 favorite as
well:)

-gsplit-dwarf is not common. Many uses have separate -g. Let's change it.

Attached the patch.


(I also wish -gdwarf-5 did not imply -g but the ship may have shipped.)
>From d389afcaf66ae9f0549ec91437a7bcb1e3b0d7d7 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Wed, 13 May 2020 08:27:29 -0700
Subject: [PATCH] Don't make -gsplit-dwarf imply -g

-gsplit-dwarf introduces order dependency: it overrides previous -g0 and -g1.

Don't imply -g so that it can be plugged into a build without worrying
that unnecessary debugging information may be generated.

2020-05-13  Fangrui Song  

	PR debug/95096
	* common.opt: Don't make -gsplit-dwarf imply -g.
	* doc/invoke.texi: Update documentation.
---
 gcc/doc/invoke.texi | 10 +-
 gcc/opts.c  |  5 -
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 850aeac033d..12b65f0f604 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8796,11 +8796,11 @@ except when selective scheduling is enabled.
 
 @item -gsplit-dwarf
 @opindex gsplit-dwarf
-Separate as much DWARF debugging information as possible into a
-separate output file with the extension @file{.dwo}.  This option allows
-the build system to avoid linking files with debug information.  To
-be useful, this option requires a debugger capable of reading @file{.dwo}
-files.
+If DWARF debugging information is enabled, separate as much debugging
+information as possible into a separate output file with the extension
+@file{.dwo}.  This option allows the build system to avoid linking files with
+debug information.  To be useful, this option requires a debugger capable of
+reading @file{.dwo} files.
 
 @item -gdescribe-dies
 @opindex gdescribe-dies
diff --git a/gcc/opts.c b/gcc/opts.c
index ec3ca0720f9..b45f22d9634 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2723,11 +2723,6 @@ common_handle_option (struct gcc_options *opts,
   set_debug_level (DWARF2_DEBUG, false, "", opts, opts_set, loc);
   break;
 
-case OPT_gsplit_dwarf:
-  set_debug_level (NO_DEBUG, DEFAULT_GDB_EXTENSIONS, "", opts, opts_set,
-		   loc);
-  break;
-
 case OPT_ggdb:
   set_debug_level (NO_DEBUG, 2, arg, opts, opts_set, loc);
   break;
-- 
2.26.2.645.ge9eca65c58-goog

[PATCH] Add -fuse-ld= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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:
https://gcc.gnu.org/develop.html#stage4


Thanks for the review!
According to https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543028.html "GCC 
10.0 Status Report (2020-04-01)",
I guess GCC is not open for a new development cycle yet.


Yes, it's not opened, but I expect to be opened in 3 weeks from now.


I will just answer a few questions instead of uploading a new patch.


Sure, but don't hesitate to send a patch. It can sit here and wait for next 
stage1 ;)


Thank you! I got around and updated the patch.

Tested locally with -fuse-ld=~/Stable/bin/ld.lld and 
-fuse-ld=~/Dev/binutils-gdb/Debug/ld/ld-new




Anyway, I'm going to provide a review (even though I'm not maintainer of that).

Can you please describe your test-case why you need such option? When using
a different ld, I typically export PATH=/path/to/binutils and then run configure
and make.


I would hope -fuse-ld=ld.bfd and -fuse-ld=ld.gold were used instead of
-fuse-ld=bfd and -fuse-ld=gold, then it would be more natural to have
-fuse-ld=/abs/path/to/ld . https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470


Well, problem with that is that the option values are used and we want to 
preserve
backward compatibility of options (if possible). I mean we can't just rename
-fuse-ld=bfd to -fuse-ld=ld.bfd.



-fuse-ld=bfd, -fuse-ld=gold and -fuse-ld=lld are hard-coded in numerous
places. It is too late to change that.

One idea is to make

-fuse-ld=bfd
-fuse-ld=gold
-fuse-ld=lld

special. For any other value, e.g. -fuse-ld=foo or -fuse-ld=/abs/path, just 
searches the
executable named "foo" (instead of "ld.foo") or /abs/path .


Yes, that seems feasible to me.



Does the scheme sound good? If it is agreed, I can make a similar change to 
clang.


Yes, please send a patch and we can make another round of review process.

Thanks,
Martin




I noticed not ideal error message:

$ gcc -fuse-ld=pes /tmp/foo.c
collect2: fatal error: cannot find ‘ld’
compilation terminated.

while clang prints:

$clang -fuse-ld=pes /tmp/foo.c
clang-9.0: error: invalid linker name in argument '-fuse-ld=pes'

The rest of the patch is comment inline...


Thanks for all the comments.


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 ++
 gcc/collect2.c  | 67 -
 gcc/common.opt  | 14 ++
 gcc/doc/invoke.texi | 15 +++---
 gcc/gcc.c   | 14 --
 gcc/opts.c  |  4 +--
 6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+    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.
+
 2020-02-09  Uroš Bizjak  
 * recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
 {
   USE_DEFAULT_LD,
   USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
 } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
 {
   "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
   static const char *const strip_suffix = "strip";
   static const char *const gstrip_suffix = "gstrip";
-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
  the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *use_ld = NULL;
   /* The kinds of symbols we will have to consider when sca

[PATCH v2] Add -fuse-ld= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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,
  USE_LLD_LD,
+  USE_LD,


I wouldn't add a new constant.


  USE_LD_MAX
} selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
{
  "ld",
  PLUGIN_LD_SUFFIX,
  "ld.gold",
  "ld.bfd",
-  "ld.lld"
+  "ld.lld",


Not needed change.


};
  static const char *const real_ld_suffix = "real-ld";
  static const char *const collect_ld_suffix = "collect-ld";
@@ -802,7 +803,7 @@ main (int argc, char **argv)
  static const char *const strip_suffix = "strip";
  static const char *const gstrip_suffix = "gstrip";
-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
#ifdef CROSS_DIRECTORY_STRUCTURE
  /* If we look for a program in the compiler directories, we just use
 the short name, since these directories are already system-specific.
@@ -844,6 +845,7 @@ main (int argc, char **argv)
  const char **ld1;
  bool use_plugin = false;
  bool use_collect_ld = false;
+  const char *use_ld = NULL;
  /* The kinds of symbols we will have to consider when scanning the
 outcome of a first pass link.  This is ALL to start with, then might
@@ -868,7 +870,7 @@ main (int argc, char **argv)
#endif
  int i;
-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
full_ld_suffixes[i]
#ifdef CROSS_DIRECTORY_STRUCTURE
  = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -967,6 +969,11 @@ main (int argc, char **argv)
  selected_linker = USE_GOLD_LD;
else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
  selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+   use_ld = argv[i] + 9;
+   selected_linker = USE_LD;


Here you can selected_linker = USE_LD_MAX.


+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1119,12 +1126,16 @@ main (int argc, char **argv)
}
  /* Search the compiler directories for `ld'.  We have protection against
 recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
-  /* Search the ordinary system bin directories
- for `ld' (if native linking) or `TARGET-ld' (if cross).  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
X_OK);


Here you can check either for selected_linker == USE_LD_MAX or for use_ld != 
NULL.


v2 changes to use `path` (PATH) instead. It probably makes more sense.
-fuse-ld=ld.lld -> find a program named ld.lld in PATH.
find_a_file with cpath can unlikely return a result.

Additionally, full_ld_suffixes[selected_linker] does not make sense for
a non-BFD-non-gold linker. (So the existing behavior regarding
-fuse-ld=lld may be strange. I don't intend to change the behavior, though).


+  if (selected_linker == USE_LD) {
+ld_file_name = find_a_file (&cpath, use_ld, X_OK);
+  } else {


Bad coding style (braces should be at a separate line) and you don't need the 
{} here.


+if (ld_file_name == 0)
+  ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
+/* Search the ordinary system bin directories
+   for `ld' (if native linking) or `TARGET-ld' (if cross).  */
+if (ld_file_name == 0)
+  ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
X_OK);
+  }
#ifdef REAL_NM_FILE_NAME
  nm_file_name = find_a_file (&path, REAL_NM_FILE_NAME, X_OK);
@@ -1296,8 +1307,7 @@ main (int argc, char **argv)
 "configuration");
#endif
}
- else if (!use_collect_ld
-  && strncmp (arg, "-fuse-ld=", 9) == 0)
+ else if (strncmp (arg, "-fuse-ld=", 9) == 0)


Why did you change this logic here? Note that it also affects e.g. 
-fuse-ld=gold here.

Martin


Thanks. I noted that the program Debug/gcc/collect-ld is not updated for
-fuse-ld=lld. configure.ac has a problem that if my ld in PATH is
actually /usr/local/bin/ld -> lld, 


ORIGINAL_LD_BFD_FOR_TARGET
and
ORIGINAL_LD_GOLD_FOR_TARGET

can point to non-existent /usr/local/bin/ld.{bfd,gold}

The above issues motivated me to touch this line in PATCH v2.
Dropped in PATCH v2.


{
  /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
  ld1--;
diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..6408d042d8c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2908,6 +2908,10 @@ fuse-ld=lld
Common Driver Negative(fuse-ld=lld)
Use the lld LLVM linker instead of the default l

[PATCH v3] Add -fuse-ld= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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 
/tmp/0001-Add-fuse-ld-to-specify-an-arbitrary-executable-as-th.patch
=== ERROR type #1: blocks of 8 spaces should be replaced with tabs (4 error(s)) 
===
gcc/collect2.c:1135:0:ld_file_name = find_a_file(&cpath, 
ld_suffixes[selected_linker], X_OK);
gcc/collect2.c:1137:0: for `ld' (if native linking) or `TARGET-ld' (if 
cross).  */
gcc/collect2.c:1139:0:ld_file_name =
gcc/collect2.c:1140:0:find_a_file(&path, 
full_ld_suffixes[selected_linker], X_OK);

=== ERROR type #2: there should be exactly one space between function name and 
parenthesis (2 error(s)) ===
gcc/collect2.c:1135:34:ld_file_name = find_a_file(&cpath, 
ld_suffixes[selected_linker], X_OK);
gcc/collect2.c:1140:23:find_a_file(&path, 
full_ld_suffixes[selected_linker], X_OK);


Thank you. I did not know ./contrib/check_GNU_style.py

PATCH v3 fixes the above style issues and checks both cpath and path
which appears to make more sense (and compatible with clang).


=== ERROR type #3: trailing operator (1 error(s)) ===
gcc/collect2.c:1139:21:ld_file_name =


but I can't fix this one because joining two lines will break the 80-column 
rule.


Note that I can't approve the patch, please wait for a reviewer that can 
approve it.

Martin


I'll wait for a reviewer to approve and apply it.
>From 1fea80498891db3fef831bd65f231603951e5f14 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Tue, 19 May 2020 12:21:26 -0700
Subject: [PATCH] Add -fuse-ld= to specify an arbitrary executable as the
 linker

The value can be either a relative path (relative to a COMPILER_PATH
directory or a PATH directory) or an absolute path.  Unlike
-fuse-ld={bfd,gold,lld}, -fuse-ld= does not add a prefix `ld.`

	PR driver/93645
	* common.opt (-fuse-ld=): Add -fuse-ld=.
	* opts.c (common_handle_option): Handle OPT_fuse_ld_.
	* gcc.c (driver_handle_option): Likewise.
	* collect2.c (main): Likewise.
	* doc/invoke.texi: Document -fuse-ld=.
---
 gcc/collect2.c  | 32 
 gcc/common.opt  |  4 
 gcc/doc/invoke.texi |  4 
 gcc/opts.c  |  1 +
 4 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index f8a5ce45994..cc57a20e08b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -844,6 +844,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *use_ld = NULL;
 
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -967,6 +968,11 @@ main (int argc, char **argv)
 	  selected_linker = USE_GOLD_LD;
 	else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
 	  selected_linker = USE_LLD_LD;
+	else if (!strncmp (argv[i], "-fuse-ld=", 9))
+	  {
+	use_ld = argv[i] + 9;
+	selected_linker = USE_LD_MAX;
+	  }
 	else if (strncmp (argv[i], "-o", 2) == 0)
 	  {
 	/* Parse the output filename if it's given so that we can make
@@ -1117,14 +1123,24 @@ main (int argc, char **argv)
   ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
   use_collect_ld = ld_file_name != 0;
 }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
-  /* Search the ordinary system bin directories
- for `ld' (if native linking) or `TARGET-ld' (if cross).  */
-  if (ld_file_name == 0)
-ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], X_OK);
+  if (selected_linker == USE_LD_MAX)
+{
+  ld_file_name = find_a_file (&cpath, use_ld, X_OK);
+  if (ld_file_name == 0)
+	ld_file_name = find_a_file (&path, use_ld, X_OK);
+}
+  else
+{
+  /* Search the compiler directories for `ld'.  We have protection against
+	 recursive calls in find_a_file.  */
+  if (ld_file_name == 0)
+	ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], X_OK);
+  /* Search the ordinary system bin directories
+	 for `ld' (if native linking) or `TARGET-ld' (if cross).  */
+  if (ld_file_name == 0)
+	ld_file_name =
+	  find_a_file (&path, full_ld_suffixes[selected_linker], X_OK);
+}
 
 #ifdef REAL_NM_FILE_NAME
   nm_file_name = find_a_file (&path, REAL_NM_FILE_NAME, X_OK);
diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..6408d042d8c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2908,6 +2908,10 @@ fuse-ld=lld
 Common Driver Negative(fuse-ld=lld)
 Use the lld LLVM linker instead of the default linker.
 
+fuse-ld=
+Common Driver Joined
+Use the specified executable instead of the default l

Re: [PATCH v3] Add -fuse-ld= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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
+++ b/gcc/collect2.c
@@ -1138,8 +1138,8 @@ main (int argc, char **argv)
  /* Search the ordinary system bin directories
 for `ld' (if native linking) or `TARGET-ld' (if cross).  */
  if (ld_file_name == 0)
-   ld_file_name =
- find_a_file (&path, full_ld_suffixes[selected_linker], X_OK);
+   ld_file_name
+ = find_a_file (&path, full_ld_suffixes[selected_linker], X_OK);
}
#ifdef REAL_NM_FILE_NAME

Apart from that, the patch is fine.

Martin


Adding people who may be able to approve and commit on my behalf.

This formatting issue seems small enough. Hopefully a maintainer can do
it for me.

Re: [PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

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 eventually usage of the --ld-path= 
option.

I see it handy when developing a ld feature to be able to point to a built ld
(without need to build GCC with it). Yes, one can use --save-temps --verbose
and invoke the built linker, but it's not handy.

Martin



I did this when I worked on some GNU ld features.
clang --ld-path=/path/to/binutils/out/debug/ld/ld-new
or debugging some Linux kernel issues related to ld.

Having --ld-path= in GCC will be handy.

Re: [PATCH] AArch64: Add support for -mdirect-extern-access

[Fangrui Song via Gcc-patches]

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 
> > > indirection
> > > +  on all external data symbols with :option:`-fpie` or :option:`-fPIE`.  
> > > This is
> > > +  useful for executables linked with :option:`-static` or 
> > > :option:`-static-pie`.
> > > +  With :option:`-fpic` or :option:`-fPIC`, it only affects accesses to 
> > > protected
> > > +  data symbols.  It has no effect on non-position independent code.  The 
> > > default
> > > +  is :option:`-mno-direct-extern-access`.
> > > +
> > > +  .. warning::
> > > +
> > > +Use :option:`-mdirect-extern-access` either in shared libraries or in
> > > +executables, but not in both.  Protected symbols used both in a 
> > > shared
> > > +library and executable may cause linker errors or fail to work 
> > > correctly.
> >
> > I think current GCC and Clang's behavior is:
> >
> > * -mdirect-extern-access is the default for -fno-pic. This is to enable 
> > optimizations for -static programs but may introduce copy relocations.
> > * -mno-direct-extern-access is the default for -fpie and -fpic. This uses 
> > some GOT-generating relocations which can be optimized out (lld, see 
> > https://maskray.me/blog/2021-08-29-all-about-global-offset-table) but the 
> > instruction is nevertheless slightly longer.
> >
> > (-mdirect-extern-access for -fpic probably doesn't make sense.)
> >
> > The option I introduced to Clang is -fdirect-access-external-data
> > (see 
> > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected).
> > If -mdirect-extern-access gets more popular, I can add a Clang alias.
> > But I am opposed to forcing a GNU property for 
> > -mdirect-extern-access/-mno-direct-extern-access.
> >
> > FWIW I used 
> > https://gist.github.com/MaskRay/c03a90922003df666551589f1629df22 to test my 
> > Clang changes related to -fno-semantic-interposition
> > on various visibility attributes x non-weak/weak x nopic/pie/pic x 
> > dllimport/not x ...
>
>
> The x86_64 discussion about this is here
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 .
> I think clang changing the ABI is just broken and should think twice
> before we do it for GCC.
>
> And there is a lot of visibility protected issues filed in GCC bug
> databases specifically about copy relocs too.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56527
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
> https://sourceware.org/bugzilla/show_bug.cgi?id=28875
> https://sourceware.org/bugzilla/show_bug.cgi?id=28877
> I also suspect clang's behavior is still broken too.
>
> Thanks,
> Andrew

Well, I don't think Clang changed ABI regarding -fno-pic/-fpie/-fpic.
As I did archaeology on
https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
"Reflection on protected data symbols and copy relocations"
GCC 5 x86-64 made a change and GCC aarch64 accidentally picked up the change.

"""
On the GCC side, in -fpic mode, using GOT-generating relocations when
accessing a protected variable subverts the point using the protected
visibility. The unneeded pessimization is the foremost complaint. The
pessimization applies to all ports with #define TARGET_BINDS_LOCAL_P
default_binds_local_p_2. aarch64 moved to default_binds_local_p_2
accidentally by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cbddf64c0243816b45e6680754a251c603245dbc.

For GCC<5 (and all versions of Clang), direct accesses to protected
variables are produced in -fpic code. Mixing such object files can
still silently break copy relocations on protected data symbols.
Therefore, GNU ld made the controversial change
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5
to error in -shared mode.
"""


> >
> > On 2022-11-17, Ramana Radhakrishnan wrote:
> > >On Thu, Nov 17, 2022 at 5:30 PM Richard Sandiford via Gcc-patches
> > > wrote:
> > >>
> > >> Wilco Dijkstra  writes:
> > >> > Hi Richard,
> > >> >
> > >> >> Can you go into more detail about:
> > >> >>
> > >> >>Use :option:`-mdirect-extern-access` either in shared libraries or 
> > >> >> in
> > >> >>executables, but not in both.  Protected symbols used both in a 
> > >> >> shared
> > >> >>library and executable may cause linker errors or fail to work 
> > >> >> correctly
> > >> >>
> > >> >> If this is LLVM's default for PIC (and by assumption shared 
> > >> >> libraries),
> > >> >> is it then invalid to use -mdirect-extern-access for any PIEs that
> > >> >> are linked against those shared libraries and use protected symbols
> > >> >> from those libraries?  How would a user know that one of the shared
> > >> >> libraries they're linking against was built in this way?
> > >> >
> > >> >

Re: [PATCH] AArch64: Add support for -mdirect-extern-access

[Fangrui Song via Gcc-patches]

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:: -mdirect-extern-access, -mno-direct-extern-access
> > > > > +
> > > > > +  Use direct accesses for external data symbols.  It avoids a GOT 
> > > > > indirection
> > > > > +  on all external data symbols with :option:`-fpie` or 
> > > > > :option:`-fPIE`.  This is
> > > > > +  useful for executables linked with :option:`-static` or 
> > > > > :option:`-static-pie`.
> > > > > +  With :option:`-fpic` or :option:`-fPIC`, it only affects accesses 
> > > > > to protected
> > > > > +  data symbols.  It has no effect on non-position independent code.  
> > > > > The default
> > > > > +  is :option:`-mno-direct-extern-access`.
> > > > > +
> > > > > +  .. warning::
> > > > > +
> > > > > +Use :option:`-mdirect-extern-access` either in shared libraries 
> > > > > or in
> > > > > +executables, but not in both.  Protected symbols used both in a 
> > > > > shared
> > > > > +library and executable may cause linker errors or fail to work 
> > > > > correctly.
> > > >
> > > > I think current GCC and Clang's behavior is:
> > > >
> > > > * -mdirect-extern-access is the default for -fno-pic. This is to enable 
> > > > optimizations for -static programs but may introduce copy relocations.
> > > > * -mno-direct-extern-access is the default for -fpie and -fpic. This 
> > > > uses some GOT-generating relocations which can be optimized out (lld, 
> > > > see https://maskray.me/blog/2021-08-29-all-about-global-offset-table) 
> > > > but the instruction is nevertheless slightly longer.
> > > >
> > > > (-mdirect-extern-access for -fpic probably doesn't make sense.)
> > > >
> > > > The option I introduced to Clang is -fdirect-access-external-data
> > > > (see 
> > > > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected).
> > > > If -mdirect-extern-access gets more popular, I can add a Clang alias.
> > > > But I am opposed to forcing a GNU property for 
> > > > -mdirect-extern-access/-mno-direct-extern-access.
> > > >
> > > > FWIW I used 
> > > > https://gist.github.com/MaskRay/c03a90922003df666551589f1629df22 to 
> > > > test my Clang changes related to -fno-semantic-interposition
> > > > on various visibility attributes x non-weak/weak x nopic/pie/pic x 
> > > > dllimport/not x ...
> > >
> > >
> > > The x86_64 discussion about this is here
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 .
> > > I think clang changing the ABI is just broken and should think twice
> > > before we do it for GCC.
> > >
> > > And there is a lot of visibility protected issues filed in GCC bug
> > > databases specifically about copy relocs too.
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56527
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=28875
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=28877
> > > I also suspect clang's behavior is still broken too.
> > >
> > > Thanks,
> > > Andrew
> >
> > Well, I don't think Clang changed ABI regarding -fno-pic/-fpie/-fpic.
> > As I did archaeology on
> > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
> > "Reflection on protected data symbols and copy relocations"
> > GCC 5 x86-64 made a change and GCC aarch64 accidentally picked up the 
> > change.
>
> You missed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 (or
> rather r5-7961-ga5eef8e9b02474 ) was the change to fix protected .

I didn't. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 proposed a problem.
It could be resolved as "wontfix. copy relocations are just
incompatible with protected symbols as an optimization (which is the
very purpose of inventing protected)"
but was resolved by pessimizing GCC codegen. This led to heated
discussion in several places including
https://sourceware.org/legacy-ml/binutils/2016-03/msg00312.html (which
my article linked to).

>
> >
> > """
> > On the GCC side, in -fpic mode, using GOT-generating relocations when
> > accessing a protected variable subverts the point using the protected
> > visibility. The unneeded pessimization is the foremost complaint. The
> > pessimization applies to all ports with #define TARGET_BINDS_LOCAL_P
> > default_binds_local_p_2. aarch64 moved to default_binds_local_p_2
> > accidentally by
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cbddf64c0243816b45e6680754a251c603245dbc.
>
> This was NOT by accident. In fact you just looked into the commit and
> NOT the actually email which submitted the patch:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01432.html
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

This aarch64 commit was by accident. The code happened to 

[PATCH] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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, when using -mcmodel=large, -mlarge-data-threshold doesn't apply.  This
means that the .rodata/.data/.bss sections may cause relocation overflow
pressure on sections in -mcmodel=small object files.

This patch allows -mcmodel=large to generate .l* sections.

Signed-off-by: Fangrui Song 
---
 gcc/config/i386/i386.cc| 15 +--
 gcc/config/i386/i386.opt   |  2 +-
 gcc/doc/invoke.texi|  7 ---
 gcc/testsuite/gcc.target/i386/large-data.c | 13 +
 4 files changed, 27 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/large-data.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index a3db55642e3..c68c66a5567 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -637,7 +637,8 @@ ix86_can_inline_p (tree caller, tree callee)
 static bool
 ix86_in_large_data_p (tree exp)
 {
-  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC)
+  if (ix86_cmodel != CM_MEDIUM && ix86_cmodel != CM_MEDIUM_PIC &&
+  ix86_cmodel != CM_LARGE && ix86_cmodel != CM_LARGE_PIC)
 return false;
 
   if (exp == NULL_TREE)
@@ -848,8 +849,9 @@ x86_elf_aligned_decl_common (FILE *file, tree decl,
const char *name, unsigned HOST_WIDE_INT size,
unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+  ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+ size > (unsigned int)ix86_section_threshold)
 {
   switch_to_section (get_named_section (decl, ".lbss", 0));
   fputs (LARGECOMM_SECTION_ASM_OP, file);
@@ -869,9 +871,10 @@ void
 x86_output_aligned_bss (FILE *file, tree decl, const char *name,
unsigned HOST_WIDE_INT size, unsigned align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && size > (unsigned int)ix86_section_threshold)
-switch_to_section (get_named_section (decl, ".lbss", 0));
+  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC ||
+   ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC) &&
+  size > (unsigned int)ix86_section_threshold)
+switch_to_section(get_named_section(decl, ".lbss", 0));
   else
 switch_to_section (bss_section);
   ASM_OUTPUT_ALIGN (file, floor_log2 (align / BITS_PER_UNIT));
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index d74f6b1f8fc..de8e722cd62 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -282,7 +282,7 @@ Branches are this expensive (arbitrary units).
 
 mlarge-data-threshold=
 Target RejectNegative Joined UInteger Var(ix86_section_threshold) 
Init(DEFAULT_LARGE_SECTION_THRESHOLD)
--mlarge-data-threshold=Data greater than given threshold will 
go into .ldata section in x86-64 medium model.
+-mlarge-data-threshold=Data greater than given threshold will 
go into a large data section in x86-64 medium and large code models.
 
 mcmodel=
 Target RejectNegative Joined Enum(cmodel) Var(ix86_cmodel) Init(CM_32)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e5ee2d536fc..4a20eef92e5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -32927,9 +32927,10 @@ the cache line size.  @samp{compat} is the default.
 
 @opindex mlarge-data-threshold
 @item -mlarge-data-threshold=@var{threshold}
-When @option{-mcmodel=medium} is specified, data objects larger than
-@var{threshold} are placed in the large data section.  This value must be the
-same across all objects linked into the binary, and defaults to 65535.
+When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified, data
+objects larger than @var{threshold} are placed in large data sections.  This
+value must be the same across all objects linked into the binary, and defaults
+to 65535.
 
 @opindex mrtd
 @item -mrtd
diff --git a/gcc/testsuite/gcc.target/i386/large-data.c 
b/gcc/testsuite/gcc.target/i386/large-data.c
new file mode 100644
index 000..09a917431d4
--- /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 -mcmodel=large -mlarge-data-threshold=4" } */
+/* { dg-final { scan-assembler ".lbss" } } */
+/* { dg-final { scan-assembler ".bss" } } */
+/* { dg-final { scan-assembler ".ldata" } } */
+/* { dg-final { scan-assembler ".data" } } */
+/* { dg-final { scan-assembler ".lrodata" } } */
+/* { dg-final { scan-assembler ".rodata" } } */
+
+const char rodata_a[] = "abc", rodata_b[] = "abcd";
+char d

Re: [PATCH] i386: Allow -mlarge-data-threshold with -mcmodel=large

[Fangrui Song via Gcc-patches]

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 pressure on sections in -mcmodel=small object files.
>
> However, when using -mcmodel=large, -mlarge-data-threshold doesn't apply.  
> This
> means that the .rodata/.data/.bss sections may cause relocation overflow
> pressure on sections in -mcmodel=small object files.
>
> This patch allows -mcmodel=large to generate .l* sections.
>
> Signed-off-by: Fangrui Song 
> ---
> [...]

Ping https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616947.html :)

[PATCH] x86: Use DW_EH_PE_indirect|DW_EH_PE_pcrel encodings for -fno-pic code

[Fangrui Song via Gcc-patches]

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.

gcc/

PR target/108622
* config/i386/i386.cc (asm_preferred_eh_data_format): Always use the
PIC encoding. Use DW_EH_PE_indirect if global.
---
 gcc/config/i386/i386.cc | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 3cacf738c4a..b572dd46a62 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -22851,22 +22851,13 @@ ix86_stack_protect_fail (void)
 int
 asm_preferred_eh_data_format (int code, int global)
 {
-  /* PE-COFF is effectively always -fPIC because of the .reloc section.  */
-  if (flag_pic || TARGET_PECOFF || !ix86_direct_extern_access)
-{
-  int type = DW_EH_PE_sdata8;
-  if (ptr_mode == SImode
- || ix86_cmodel == CM_SMALL_PIC
- || (ix86_cmodel == CM_MEDIUM_PIC && (global || code)))
-   type = DW_EH_PE_sdata4;
-  return (global ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | type;
-}
-
-  if (ix86_cmodel == CM_SMALL
-  || (ix86_cmodel == CM_MEDIUM && code))
-return DW_EH_PE_udata4;
-
-  return DW_EH_PE_absptr;
+  int type = DW_EH_PE_sdata8;
+  if (ptr_mode == SImode || ix86_cmodel == CM_SMALL ||
+  ix86_cmodel == CM_SMALL_PIC ||
+  (ix86_cmodel == CM_MEDIUM && code) ||
+  (ix86_cmodel == CM_MEDIUM_PIC && (global || code)))
+type = DW_EH_PE_sdata4;
+  return (global ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | type;
 }
 
 /* Implement targetm.vectorize.builtin_vectorization_cost.  */
-- 
2.39.1.456.gfc5497dd1b-goog

Re: [PATCH] x86: Use DW_EH_PE_indirect|DW_EH_PE_pcrel encodings for -fno-pic code

[Fangrui Song via Gcc-patches]

> 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 -mno-direct-extern-access or not using it, the above change
> disallows the choice), for !global I miss the point altogether.
> In non-PIC (and non-PECOFF maybe, don't know that format well)
> code if code references a local symbol, it will never generate
> a copy relocation and so DW_EH_PE_udata4 could be just fine and cheaper
> to handle on the consumer sides.

On Wed, Feb 1, 2023 at 1:09 AM Jakub Jelinek  wrote:
>
> On Wed, Feb 01, 2023 at 10:01:36AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > And, while I can understand the rationale for global cases
> > (though am not sure I agree, as currently the user can choose
> > by using -mno-direct-extern-access or not using it, the above change
> > disallows the choice), for !global I miss the point altogether.
> > In non-PIC (and non-PECOFF maybe, don't know that format well)
> > code if code references a local symbol, it will never generate
> > a copy relocation and so DW_EH_PE_udata4 could be just fine and cheaper
> > to handle on the consumer sides.
>
> Plus, e.g. for the typeinfo references, if using the default
> -mdirect-extern-access and RTTI is used, there will be copy relocations
> anyway and so the .eh_frame growth will be just waste of .got space.
>
> Jakub
>

There is a copy relocation but the canonical PLT entry for
__gxx_personality_v0 can be removed.
-fno-pic C++ exception code is less common nowadays, so there seems little value
to keep a complex condition (if (flag_pic || TARGET_PECOFF ||
!ix86_direct_extern_access)) to
optimize a bit for the object file size (I think you mean .data space
instead of .got space).
The .eh_frame growth is nearly negligible as well.

[PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

[Fangrui Song via Gcc-patches]

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 -L.  Different platforms have
different opinions on the hierarchy and all other arches work well without ld's
default -L.
* If some ABI derived library paths are desired, the compiler driver is in a
better position to make the decision and traditionally has done this.
* -m emulation is opaque to the compiler driver.  It doesn't affect -B, so
data files like crt*.o, libasan_preinit.o, and libtsan_preinit.o are not 
affected.

As is, many platforms just use symlinks to fake the lib64/{ilp32{,f},lp64{,f}}
hierarchies needed by the GNU ld emulation.  They can always specify -L
explicitly if they want some ABI derived library paths.  See also the rejected
https://reviews.llvm.org/D95755

gcc/Changelog:

* config/riscv/linux.h (LD_EMUL_SUFFIX): Remove.
(LINK_SPEC): Remove LD_EMUL_SUFFIX.
---
 gcc/config/riscv/linux.h | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index 38803723ba9..e0ff6e6a178 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -49,16 +49,8 @@ along with GCC; see the file COPYING3.  If not see
 
 #define CPP_SPEC "%{pthread:-D_REENTRANT}"
 
-#define LD_EMUL_SUFFIX \
-  "%{mabi=lp64d:}" \
-  "%{mabi=lp64f:_lp64f}" \
-  "%{mabi=lp64:_lp64}" \
-  "%{mabi=ilp32d:}" \
-  "%{mabi=ilp32f:_ilp32f}" \
-  "%{mabi=ilp32:_ilp32}"
-
 #define LINK_SPEC "\
--melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
+-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
 %{mno-relax:--no-relax} \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
-- 
2.36.1.476.g0c4daa206d-goog

[PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

[Fangrui Song via Gcc-patches]

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.
HAVE_LD_PIE_COPYRELOC has deviated from the goal.  By removing
HAVE_LD_PIE_COPYRELOC, the -fPIE behavior of x86-64 will match x86-32
and other targets.

The design goal of protected symbols was to improve performance similar
to -Bsymbolic.  lld rejects copy relocations on data symbols.  Latest
glibc rtld reports a warning when a protected data symbol is copy
relocated[1].  With the adoption of PIE most object files are -fPIE or
-fPIC.  -fPIE defaulting to the possibly copy relocations behavior makes
protected data symbols infeasible to adopt on x86-64.

[1]: 
https://sourceware.org/git/?p=glibc.git;a=commit;h=7374c02b683b7110b853a32496a619410364d70b
("elf: Refine direct extern access diagnostics to protected symbol")
---
 gcc/config.in |  6 ---
 gcc/config/i386/i386.cc   | 16 +-
 gcc/configure | 52 ---
 gcc/configure.ac  | 48 -
 gcc/doc/sourcebuild.texi  |  3 --
 .../gcc.target/i386/pie-copyrelocs-1.c| 14 -
 .../gcc.target/i386/pie-copyrelocs-2.c| 14 -
 .../gcc.target/i386/pie-copyrelocs-3.c| 14 -
 .../gcc.target/i386/pie-copyrelocs-4.c| 17 --
 gcc/testsuite/gcc.target/i386/pr32219-9.c |  1 -
 gcc/testsuite/lib/target-supports.exp | 47 -
 11 files changed, 2 insertions(+), 230 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-1.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-2.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-3.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-4.c

diff --git a/gcc/config.in b/gcc/config.in
index 16bb963b45b..ade42625deb 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1691,12 +1691,6 @@
 #endif
 
 
-/* Define 0/1 if your linker supports -pie option with copy reloc. */
-#ifndef USED_FOR_TARGET
-#undef HAVE_LD_PIE_COPYRELOC
-#endif
-
-
 /* Define if your PowerPC linker has .gnu.attributes long double support. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 3d189e124e4..f9fd9650f7c 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -10790,16 +10790,7 @@ legitimate_pic_address_disp_p (rtx disp)
  || ix86_cmodel == CM_SMALL_PIC)
return true;
}
- else if (!SYMBOL_REF_FAR_ADDR_P (op0)
-  && (SYMBOL_REF_LOCAL_P (op0)
-  || ((ix86_direct_extern_access
-   && !(SYMBOL_REF_DECL (op0)
-&& lookup_attribute ("nodirect_extern_access",
- DECL_ATTRIBUTES 
(SYMBOL_REF_DECL (op0)
-  && HAVE_LD_PIE_COPYRELOC
-  && flag_pie
-  && !SYMBOL_REF_WEAK (op0)
-  && !SYMBOL_REF_FUNCTION_P (op0)))
+ else if (!SYMBOL_REF_FAR_ADDR_P (op0) && SYMBOL_REF_LOCAL_P (op0)
   && ix86_cmodel != CM_LARGE_PIC)
return true;
  break;
@@ -23815,10 +23806,7 @@ ix86_binds_local_p (const_tree exp)
 ix86_has_no_direct_extern_access = true;
   return default_binds_local_p_3 (exp, flag_shlib != 0, true,
  direct_extern_access,
- (direct_extern_access
-  && (!flag_pic
-  || (TARGET_64BIT
-  && HAVE_LD_PIE_COPYRELOC != 0;
+ (direct_extern_access && !flag_pic));
 }
 
 /* If flag_pic or ix86_direct_extern_access is false, then neither
diff --git a/gcc/configure b/gcc/configure
index f43dc989d02..bf8aaec6e05 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30081,58 +30081,6 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld_pie" >&5
 $as_echo "$gcc_cv_ld_pie" >&6; }
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker PIE support with copy 
reloc" >&5
-$as_echo_n "checking linker PIE support with copy reloc... " >&6; }
-gcc_cv_ld_pie_copyreloc=no
-if test $gcc_cv_ld_pie = yes ; then
-  if test $in_tree_ld = yes ; then
-if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 25 -o "$gcc_cv_gld_major_version" -gt 2; then
-  gcc_cv_ld_pie_copyreloc=yes
-fi
-  elif test x$gcc_cv_as != x -a x$gcc_cv_ld != x ; then
-# Check if linker supports -pie option with copy reloc
-case "$target" in
-i?86-*-linux* | x86

Re: [PATCH] Add -fextra-libc-function=memcmpeq for __memcmpeq

[Fangrui Song via Gcc-patches]

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 9:02 PM H.J. Lu via Gcc-patches
> > >>>  wrote:
> > >>>
> > >>> Add -fextra-libc-function=memcmpeq to map
> > >>>
> > >>> extern int __memcmpeq (const void *, const void *, size_t);
> > >>>
> > >>> which was added to GLIBC 2.35, to __builtin_memcmp_eq.
> > >>
> > >> Humm.  Can't we instead use the presence of a declaration
> > >> of __memcmpeq with a GNU standard dialect as this instead of
> > >> adding a weird -fextra-libc-function= option?  Maybe that's even
> > >> reasonable with a non-GNU dialect standard in effect since
> > >> __ prefixed names are in the implementation namespace?
> > >
> > > But not all source codes include  and GCC may generate
> > > memcmp directly.  How should we handle these cases?
> >
> > Not.  Similar as to vectorized math functions.
> > I think it’s not worth optimizing for this case.
>
> Another question.  Should we consider any __memcmpeq prototype
> or just the one in the system header file?

An idea from https://reviews.llvm.org/D56593#3586673: -fbuiltin-__memcmpeq

This requires making -fbuiltin-function available, see
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
("There is no corresponding -fbuiltin-function option")

I prefer an option over a magic behavior about whether a declaration exists.

> > Richard.
> >
> > >
> > >> Richard.
> > >>
> > >>> gcc/
> > >>>
> > >>>* builtins.cc: Include "opts.h".
> > >>>(expand_builtin): Generate BUILT_IN_MEMCMP_EQ if __memcmpeq is
> > >>>available.
> > >>>* builtins.def (BUILT_IN___MEMCMPEQ): New.
> > >>>* common.opt: Add -fextra-libc-function=.
> > >>>* opts.cc (extra_libc_functions): New.
> > >>>(parse_extra_libc_function): New function.
> > >>>(common_handle_option): Handle -fextra-libc-function=.
> > >>>* opts.h (extra_libc_function_list): New.
> > >>>(extra_libc_functions): Likewise.
> > >>>* doc/invoke.texi: Document -fextra-libc-function=memcmpeq.
> > >>>
> > >>> gcc/testsuite/
> > >>>
> > >>>* c-c++-common/memcmpeq-1.c: New test.
> > >>>* c-c++-common/memcmpeq-2.c: Likewise.
> > >>>* c-c++-common/memcmpeq-3.c: Likewise.
> > >>>* c-c++-common/memcmpeq-4.c: Likewise.
> > >>>* c-c++-common/memcmpeq-5.c: Likewise.
> > >>>* c-c++-common/memcmpeq-6.c: Likewise.
> > >>>* c-c++-common/memcmpeq-7.c: Likewise.
> > >>> ---
> > >>> gcc/builtins.cc |  5 -
> > >>> gcc/builtins.def|  4 
> > >>> gcc/common.opt  |  4 
> > >>> gcc/doc/invoke.texi |  6 ++
> > >>> gcc/opts.cc | 23 +++
> > >>> gcc/opts.h  |  7 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-1.c | 11 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-2.c | 11 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-3.c | 11 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-4.c | 11 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-5.c | 11 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-6.c | 11 +++
> > >>> gcc/testsuite/c-c++-common/memcmpeq-7.c | 11 +++
> > >>> 13 files changed, 125 insertions(+), 1 deletion(-)
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-1.c
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-2.c
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-3.c
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-4.c
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-5.c
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-6.c
> > >>> create mode 100644 gcc/testsuite/c-c++-common/memcmpeq-7.c
> > >>>
> > >>> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> > >>> index b9d89b409b8..22269318e8c 100644
> > >>> --- a/gcc/builtins.cc
> > >>> +++ b/gcc/builtins.cc
> > >>> @@ -81,6 +81,7 @@ along with GCC; see the file COPYING3.  If not see
> > >>> #include "demangle.h"
> > >>> #include "gimple-range.h"
> > >>> #include "pointer-query.h"
> > >>> +#include "opts.h"
> > >>>
> > >>> struct target_builtins default_target_builtins;
> > >>> #if SWITCHABLE_TARGET
> > >>> @@ -7410,7 +7411,9 @@ expand_builtin (tree exp, rtx target, rtx 
> > >>> subtarget, machine_mode mode,
> > >>>return target;
> > >>>   if (fcode == BUILT_IN_MEMCMP_EQ)
> > >>>{
> > >>> - tree newdecl = builtin_decl_explicit (BUILT_IN_MEMCMP);
> > >>> + tree newdecl = builtin_decl_explicit
> > >>> +   (extra_libc_functions.has_memcmpeq
> > >>> +? BUILT_IN___MEMCMPEQ : BUILT_IN_MEMCMP);
> > >>>  TREE_OPERAND (exp, 1) =

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

[Fangrui Song via Gcc-patches]

On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng  wrote:
>
> Generally I agree we should fix that by GCC driver rather than ld
> emulation, but I think this should be reverted with the -L path fix,
> otherwise that will break multilib on GNU toolchain for linux
> immediately?

Thanks 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 Fangrui Song via Gcc-patches
>  wrote:
> >
> > 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 -L.  Different platforms have
> > different opinions on the hierarchy and all other arches work well without 
> > ld's
> > default -L.
> > * If some ABI derived library paths are desired, the compiler driver is in a
> > better position to make the decision and traditionally has done this.
> > * -m emulation is opaque to the compiler driver.  It doesn't affect -B, so
> > data files like crt*.o, libasan_preinit.o, and libtsan_preinit.o are not 
> > affected.
> >
> > As is, many platforms just use symlinks to fake the 
> > lib64/{ilp32{,f},lp64{,f}}
> > hierarchies needed by the GNU ld emulation.  They can always specify -L
> > explicitly if they want some ABI derived library paths.  See also the 
> > rejected
> > https://reviews.llvm.org/D95755
> >
> > gcc/Changelog:
> >
> > * config/riscv/linux.h (LD_EMUL_SUFFIX): Remove.
> > (LINK_SPEC): Remove LD_EMUL_SUFFIX.
> > ---
> >  gcc/config/riscv/linux.h | 10 +-
> >  1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> > index 38803723ba9..e0ff6e6a178 100644
> > --- a/gcc/config/riscv/linux.h
> > +++ b/gcc/config/riscv/linux.h
> > @@ -49,16 +49,8 @@ along with GCC; see the file COPYING3.  If not see
> >
> >  #define CPP_SPEC "%{pthread:-D_REENTRANT}"
> >
> > -#define LD_EMUL_SUFFIX \
> > -  "%{mabi=lp64d:}" \
> > -  "%{mabi=lp64f:_lp64f}" \
> > -  "%{mabi=lp64:_lp64}" \
> > -  "%{mabi=ilp32d:}" \
> > -  "%{mabi=ilp32f:_ilp32f}" \
> > -  "%{mabi=ilp32:_ilp32}"
> > -
> >  #define LINK_SPEC "\
> > --melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
> > +-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
> >  %{mno-relax:--no-relax} \
> >  %{mbig-endian:-EB} \
> >  %{mlittle-endian:-EL} \
> > --
> > 2.36.1.476.g0c4daa206d-goog
> >



-- 
宋方睿

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

[Fangrui Song via Gcc-patches]

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).
>
> One design goal of -fPIE was to avoid copy relocations.
> HAVE_LD_PIE_COPYRELOC has deviated from the goal.  By removing
> HAVE_LD_PIE_COPYRELOC, the -fPIE behavior of x86-64 will match x86-32
> and other targets.
>
> The design goal of protected symbols was to improve performance similar
> to -Bsymbolic.  lld rejects copy relocations on data symbols.  Latest
> glibc rtld reports a warning when a protected data symbol is copy
> relocated[1].  With the adoption of PIE most object files are -fPIE or
> -fPIC.  -fPIE defaulting to the possibly copy relocations behavior makes
> protected data symbols infeasible to adopt on x86-64.
>
> [1]: 
> https://sourceware.org/git/?p=glibc.git;a=commit;h=7374c02b683b7110b853a32496a619410364d70b
> ("elf: Refine direct extern access diagnostics to protected symbol")
> ---
>  gcc/config.in |  6 ---
>  gcc/config/i386/i386.cc   | 16 +-
>  gcc/configure | 52 ---
>  gcc/configure.ac  | 48 -
>  gcc/doc/sourcebuild.texi  |  3 --
>  .../gcc.target/i386/pie-copyrelocs-1.c| 14 -
>  .../gcc.target/i386/pie-copyrelocs-2.c| 14 -
>  .../gcc.target/i386/pie-copyrelocs-3.c| 14 -
>  .../gcc.target/i386/pie-copyrelocs-4.c| 17 --
>  gcc/testsuite/gcc.target/i386/pr32219-9.c |  1 -
>  gcc/testsuite/lib/target-supports.exp | 47 -
>  11 files changed, 2 insertions(+), 230 deletions(-)
>  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-1.c
>  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-2.c
>  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-3.c
>  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-4.c
>
> diff --git a/gcc/config.in b/gcc/config.in
> index 16bb963b45b..ade42625deb 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -1691,12 +1691,6 @@
>  #endif
>
>
> -/* Define 0/1 if your linker supports -pie option with copy reloc. */
> -#ifndef USED_FOR_TARGET
> -#undef HAVE_LD_PIE_COPYRELOC
> -#endif
> -
> -
>  /* Define if your PowerPC linker has .gnu.attributes long double support. */
>  #ifndef USED_FOR_TARGET
>  #undef HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 3d189e124e4..f9fd9650f7c 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -10790,16 +10790,7 @@ legitimate_pic_address_disp_p (rtx disp)
>   || ix86_cmodel == CM_SMALL_PIC)
> return true;
> }
> - else if (!SYMBOL_REF_FAR_ADDR_P (op0)
> -  && (SYMBOL_REF_LOCAL_P (op0)
> -  || ((ix86_direct_extern_access
> -   && !(SYMBOL_REF_DECL (op0)
> -&& lookup_attribute 
> ("nodirect_extern_access",
> - DECL_ATTRIBUTES 
> (SYMBOL_REF_DECL (op0)
> -  && HAVE_LD_PIE_COPYRELOC
> -  && flag_pie
> -  && !SYMBOL_REF_WEAK (op0)
> -  && !SYMBOL_REF_FUNCTION_P (op0)))
> + else if (!SYMBOL_REF_FAR_ADDR_P (op0) && SYMBOL_REF_LOCAL_P (op0)
>&& ix86_cmodel != CM_LARGE_PIC)
> return true;
>   break;
> @@ -23815,10 +23806,7 @@ ix86_binds_local_p (const_tree exp)
>  ix86_has_no_direct_extern_access = true;
>return default_binds_local_p_3 (exp, flag_shlib != 0, true,
>   direct_extern_access,
> - (direct_extern_access
> -  && (!flag_pic
> -  || (TARGET_64BIT
> -  && HAVE_LD_PIE_COPYRELOC != 0;
> + (direct_extern_access && !flag_pic));
>  }
>
>  /* If flag_pic or ix86_direct_extern_access is false, then neither
> diff --git a/gcc/configure b/gcc/configure
> index f43dc989d02..bf8aaec6e05 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -30081,58 +30081,6 @@ fi
>  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld_pie" >&5
>  $as_echo "$gcc_cv_ld_pie" >&6; }
>
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker PIE support with 
> copy reloc" >&5
> -$as_echo_n "checking linker PIE support with copy reloc... " >&6; }
> -gcc_cv_ld_pie_copyreloc=no
> -if test $gcc_cv_ld_pie = yes ; then
> -  if test $in_tree_ld = yes ; then
> -if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
>

Re: [PATCH] Introduce -nolibstdc++ option

[Fangrui Song via Gcc-patches]

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 libstdc++
> > without also dropping libc and any other libraries that the target
> > implicitly links in.
> >
> > This has often led to the need for manual adjustments to this
> > testcase.
> >
> > I figured adding support for -nolibstdc++, even though redundant,
> > makes some sense.  One could presumably use gcc rather than g++ for
> > linking, for the same effect, but sometimes changing the link command
> > is harder than adding an option, as in our testsuite.
> >
> > Regstrapped on x86_64-linux-gnu, also tested with a cross to
> > aarch64-rtems6.  Ok to install?
>
> OK in case nobody objects in 24h.
>
> Richard.

Is this similar to clang -nostdlib++ ?
When libstdc++ is selected, clang -nostdlib++ removes -lstdc++.

> >
> > for  gcc/ChangeLog
> >
> > * common.opt (nolibstdc++): New.
> > * doc/invoke.texi (-nolibstdc++): Document it.
> >
> > for  gcc/cp/ChangeLog
> >
> > * g++spec.c (lang_specific_driver): Implement -nolibstdc++.
> >
> > for  gcc/testsuite/ChangeLog
> >
> > * g++.dg/abi/pure-virtual1.C: Use -nolibstdc++.
> > ---
> >  gcc/common.opt   |3 +++
> >  gcc/cp/g++spec.cc|1 +
> >  gcc/doc/invoke.texi  |6 +-
> >  gcc/testsuite/g++.dg/abi/pure-virtual1.C |2 +-
> >  4 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/common.opt b/gcc/common.opt
> > index 32917aafcaec1..e00c6fc2fb098 100644
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -3456,6 +3456,9 @@ Driver
> >  nolibc
> >  Driver
> >
> > +nolibstdc++
> > +Driver
> > +
> >  nostdlib
> >  Driver
> >
> > diff --git a/gcc/cp/g++spec.cc b/gcc/cp/g++spec.cc
> > index 8174d652776b1..539e6ca089d85 100644
> > --- a/gcc/cp/g++spec.cc
> > +++ b/gcc/cp/g++spec.cc
> > @@ -160,6 +160,7 @@ lang_specific_driver (struct cl_decoded_option 
> > **in_decoded_options,
> > {
> > case OPT_nostdlib:
> > case OPT_nodefaultlibs:
> > +   case OPT_nolibstdc__:
> >   library = -1;
> >   break;
> >
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 50f57877477bc..469b6d97e0dfa 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -652,7 +652,7 @@ Objective-C and Objective-C++ Dialects}.
> >  @item Linker Options
> >  @xref{Link Options,,Options for Linking}.
> >  @gccoptlist{@var{object-file-name}  -fuse-ld=@var{linker}  -l@var{library} 
> > @gol
> > --nostartfiles  -nodefaultlibs  -nolibc  -nostdlib @gol
> > +-nostartfiles  -nodefaultlibs  -nolibc  -nolibstdc++  -nostdlib @gol
> >  -e @var{entry}  --entry=@var{entry} @gol
> >  -pie  -pthread  -r  -rdynamic @gol
> >  -s  -static  -static-pie  -static-libgcc  -static-libstdc++ @gol
> > @@ -16787,6 +16787,10 @@ absence of a C library is assumed, for example 
> > @option{-lpthread} or
> >  @option{-lm} in some configurations.  This is intended for bare-board
> >  targets when there is indeed no C library available.
> >
> > +@item -nolibstdc++
> > +@opindex nolibstdc++
> > +Do not link with standard C++ libraries implicitly.
> > +
> >  @item -nostdlib
> >  @opindex nostdlib
> >  Do not use the standard system startup files or libraries when linking.
> > diff --git a/gcc/testsuite/g++.dg/abi/pure-virtual1.C 
> > b/gcc/testsuite/g++.dg/abi/pure-virtual1.C
> > index 538e2cb097a0d..889c33e4952f4 100644
> > --- a/gcc/testsuite/g++.dg/abi/pure-virtual1.C
> > +++ b/gcc/testsuite/g++.dg/abi/pure-virtual1.C
> > @@ -1,7 +1,7 @@
> >  // Test that we don't need libsupc++ just for __cxa_pure_virtual.
> >  // { dg-do link }
> >  // { dg-require-weak }
> > -// { dg-additional-options "-fno-rtti -nodefaultlibs -lc" }
> > +// { dg-additional-options "-fno-rtti -nolibstdc++" }
> >  // { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
> > *-*-darwin* } }
> >  // { dg-xfail-if "AIX weak" { powerpc-ibm-aix* } }
> >
> >
> > --
> > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
> >Free Software Activist   GNU Toolchain Engineer
> > Disinformation flourishes because many people care deeply about injustice
> > but very few check the facts.  Ask me about 

Re: [PATCH] Introduce -nolibstdc++ option

[Fangrui Song via Gcc-patches]

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 g++.dg/abi/pure-virtual1.C,
> > is error prone, because there's no way to tell g++ to drop libstdc++
> > without also dropping libc and any other libraries that the target
> > implicitly links in.
> >
> > This has often led to the need for manual adjustments to this
> > testcase.
> >
> > I figured adding support for -nolibstdc++, even though redundant,
> > makes some sense.  One could presumably use gcc rather than g++ for
> > linking, for the same effect, but sometimes changing the link command
> > is harder than adding an option, as in our testsuite.
> >
> > Regstrapped on x86_64-linux-gnu, also tested with a cross to
> > aarch64-rtems6.  Ok to install?
>
> OK in case nobody objects in 24h.
>
> Richard.

Is this similar to clang -nostdlib++ ?
When libstdc++ is selected, clang -nostdlib++ removes -lstdc++.


Probably.  Note that we have -static-libstdc++ already so
-nolibstdc++ matches that.  We also have -nolibc, not -noclib.

Richard.


I think the relation between -static-foo and -nofoo is not that large.
-nostdlib does not have a corresponding -static-stdlib.

Note that gcc has supported -stdlib=libc++ since 2020-12, though the
usage is a bit tricky. Having a C++ standard library agnostic name
helps libc++:)

For -lc, clang has -nolibc.


> >
> > for  gcc/ChangeLog
> >
> > * common.opt (nolibstdc++): New.
> > * doc/invoke.texi (-nolibstdc++): Document it.
> >
> > for  gcc/cp/ChangeLog
> >
> > * g++spec.c (lang_specific_driver): Implement -nolibstdc++.
> >
> > for  gcc/testsuite/ChangeLog
> >
> > * g++.dg/abi/pure-virtual1.C: Use -nolibstdc++.
> > ---
> >  gcc/common.opt   |3 +++
> >  gcc/cp/g++spec.cc|1 +
> >  gcc/doc/invoke.texi  |6 +-
> >  gcc/testsuite/g++.dg/abi/pure-virtual1.C |2 +-
> >  4 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/common.opt b/gcc/common.opt
> > index 32917aafcaec1..e00c6fc2fb098 100644
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -3456,6 +3456,9 @@ Driver
> >  nolibc
> >  Driver
> >
> > +nolibstdc++
> > +Driver
> > +
> >  nostdlib
> >  Driver
> >
> > diff --git a/gcc/cp/g++spec.cc b/gcc/cp/g++spec.cc
> > index 8174d652776b1..539e6ca089d85 100644
> > --- a/gcc/cp/g++spec.cc
> > +++ b/gcc/cp/g++spec.cc
> > @@ -160,6 +160,7 @@ lang_specific_driver (struct cl_decoded_option 
**in_decoded_options,
> > {
> > case OPT_nostdlib:
> > case OPT_nodefaultlibs:
> > +   case OPT_nolibstdc__:
> >   library = -1;
> >   break;
> >
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 50f57877477bc..469b6d97e0dfa 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -652,7 +652,7 @@ Objective-C and Objective-C++ Dialects}.
> >  @item Linker Options
> >  @xref{Link Options,,Options for Linking}.
> >  @gccoptlist{@var{object-file-name}  -fuse-ld=@var{linker}  -l@var{library} 
@gol
> > --nostartfiles  -nodefaultlibs  -nolibc  -nostdlib @gol
> > +-nostartfiles  -nodefaultlibs  -nolibc  -nolibstdc++  -nostdlib @gol
> >  -e @var{entry}  --entry=@var{entry} @gol
> >  -pie  -pthread  -r  -rdynamic @gol
> >  -s  -static  -static-pie  -static-libgcc  -static-libstdc++ @gol
> > @@ -16787,6 +16787,10 @@ absence of a C library is assumed, for example 
@option{-lpthread} or
> >  @option{-lm} in some configurations.  This is intended for bare-board
> >  targets when there is indeed no C library available.
> >
> > +@item -nolibstdc++
> > +@opindex nolibstdc++
> > +Do not link with standard C++ libraries implicitly.
> > +
> >  @item -nostdlib
> >  @opindex nostdlib
> >  Do not use the standard system startup files or libraries when linking.
> > diff --git a/gcc/testsuite/g++.dg/abi/pure-virtual1.C 
b/gcc/testsuite/g++.dg/abi/pure-virtual1.C
> > index 538e2cb097a0d..889c33e4952f4 100644
> > --- a/gcc/testsuite/g++.dg/abi/pure-virtual1.C
> > +++ b/gcc/testsuite/g++.dg/abi/pure-virtual1.C
> > @@ -1,7 +1,7 @@
> >  // Test that we don't need libsupc++ just for __cxa_pure_virtual.
> >  // { dg-do link }
> >  // { dg-require-weak }
> > -// { dg-additional-options "-fno-rtti -nodefaultlibs -lc" }
> > +// { dg-additional-options "-fno-rtti -nolibstdc++" }
> >  // { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
*-*-darwin* } }
> >  // { dg-xfail-if "AIX weak" { powerpc-ibm-aix* } }
> >
> >
> > --
> > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
> >Free Software Activist   GNU Toolchain Engineer
> > Disinformation flourishes because many people care deeply about injustice
> > but very few check the facts.  Ask me about 

Re: [PATCH] Introduce -nolibstdc++ option

[Fangrui Song via Gcc-patches]

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 something that brings
> C++ to (my) mind.

Agree that clang --stdlib= and -nostdlib++ probably should be better
named. There are many
standard libraries and "stdlib" as a name isn't tied to C++ much.
That said, --stdlib= has a very long history and seems not so
necessary to change now.
For new Clang driver options (I subscribe to clang/lib/Driver files to
try catching up the change),
I try to keep an eye on and for something useful which may be matched by GCC,
I'll notify some GCC folks I know (e.g. Nathan, Martin).

> > (so, fo example, if libstdc++ were separate from libsupc++ I would
> >  expect your use-case to wish to exclude both, not just libstdc++)?
>
> That's what the testcase requires, yes.  IIRC there's another that would
> benefit from the ability to link with libsupc++, but not with libstdc++.
>
> > if GCC already has an option spelling, usually clang would follow that
> > - it does not seem unreasonable to reciprocate.

Thanks.

> Yeah, I suppose that makes sense, it's beneficial for users to avoid the
> cognitive overload of dealing with equivalent options with different
> spellings.  I'll swallow my dislike for the spelling and change the
> patch to use -nostdlib++.

Thanks:)

BTW: even if -static-libstdc++ is a bit of misnomer when a clang user
uses libc++,
since -static-libc++ or -static-stdlib does not exist, they are still
using -static-libstdc++.

> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep

[Fangrui Song via Gcc-patches]

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 places is
likely
to break at least the Solaris build.

Please see the autoconf manual for details.  I suspect you'll have to
rework the patch set to use AC_PROG_EGREP and $EGREP instead.


Thanks for the advice.  I'll rework on it.

Is there some way to access a Solaris and do some test?


Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
farm (https://gcc.gnu.org/wiki/CompileFarm).

Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
moment, but those don't differ in this regard.

Rainer


FWIW: glibc recently got the grep -E change and the solution is to use
plain grep -E, without $EGREP things.
Isn't setting PATH a good workaround if Solaris has the problem?

https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html

Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only 
vendor-supported platform I know of where '/usr/bin/grep -E' does not 
work is Solaris 10 (end-of-life January 2024), and that's easily fixed 
by prepending /usr/xpg4/bin to PATH.

Re: Should -ffp-contract=off the default on GCC?

[Fangrui Song via Gcc-patches]

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 it's even less realistic to expect users to know the details of
> >>> floating-point math.  So I doubt any such sentence will be helpful
> >>> besides spreading some FUD?
> >>
> >> I think it's closer to "fundamental notions" rather than "details". For
> >> users who bother to read the GCC manual there's a decent chance it wouldn't
> >> be for naught.
> >>
> >> For documentation, I was thinking
> >>
> >>  Together with -fexcess-precision=standard, -ffp-contract=off
> >>  is necessary to ensure that rounding of intermediate results to precision
> >>  implied by the source code and the FLT_EVAL_METHOD macro is not
> >>  omitted by the compiler.
> >
> > that sounds good to me
>
> Shall we add such clarification to our Gcc13 doc? That should be helpful if 
> we keep the currently default.
>
> Qing
> >
> >> Alexander
>

While updating the documentation, consider adding information that
#pragma STDC FP_CONTRACT OFF is ignored with -ffp-contract=fast.

This surprising behavior motivated Clang to add
-Xclang=-ffp-contract=fast-honor-pragmas
(https://discourse.llvm.org/t/fp-contract-fast-and-pragmas/58529).



-- 
宋方睿