Re: [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

[Fangrui Song]

On Wed, May 8, 2024 at 1:33 AM Kewen.Lin  wrote:
>
> Hi Richi,
>
> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> index c584664e168..58e48f7dc55 100644
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -18363,11 +18363,11 @@ If @code{N=0}, no pad location is recorded.
> >>  The NOP instructions are inserted at---and maybe before, depending on
> >>  @var{M}---the function entry address, even before the prologue.  On
> >>  PowerPC with the ELFv2 ABI, for a function with dual entry points,
> >> -the local entry point is this function entry address.
> >> +@var{M} NOP instructions are inserted before the global entry point and
> >> +@var{N} - @var{M} NOP instructions are inserted after the local entry
> >> +point, which means the NOP instructions may not be consecutive.
> >
> > Isn't it @var{M-1} NOP instructions before the global entry?  I suppose
>
> No, the existing documentation is a bit confusing, sigh ...
>
> > the existing
> >
> > "... with the function entry point before the @var{M}th NOP.
> > If @var{M} is omitted, it defaults to @code{0} so the
> > function entry points to the address just at the first NOP."
> >
> > wording is self-contradicting in a way since before the 0th NOP (default)
> > to me is the same as before the 1st NOP (M == 1).  So maybe that should
> > be _after_ the @var{M}th NOP instead which would be consistent with your
> > ELFv2 docs?  Maybe the sentence should be re-worded similar to your
> > ELVv2 one, specifying the number of NOPs before and after the entry point.
> >
>
> ... the current "with the function entry point before the Mth NOP."
> has the 0th NOP assumption, so the default (0th) NOP and 1st NOP (M == 1)
> are actually different, such as:
>
> -fpatchable-function-entry=3,0
>
> foo:
> nop
> nop
> nop
>
> -fpatchable-function-entry=3,1
>
> nop
> foo:
> nop
> nop
>
> Alan also had the similar concern on this wording before:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888#c8
>
> " Alan Modra 2022-08-12 03:00:29 UTC
> "
> "(In reply to Segher Boessenkool from comment #7)
> "> '-fpatchable-function-entry=N[,M]'
> ">  Generate N NOPs right at the beginning of each function, with the
> ">  function entry point before the Mth NOP.
> "
> " Bad doco.  Should be "after the Mth NOP" I think.
> " Or better written to avoid the concept of a 0th nop.
> " Default for M is zero, placing all nops after the function entry and
> " before normal function prologue code.
>
> BR,
> Kewen
>
> >> -The maximum value of @var{N} and @var{M} is 65535.  On PowerPC with the
> >> -ELFv2 ABI, for a function with dual entry points, the supported values
> >> -for @var{M} are 0, 2, 6 and 14.
> >> +The maximum value of @var{N} and @var{M} is 65535.
> >>  @end table
> >>


> So this patch is to change the current implementation by
> emitting the "before" NOPs before global entry point and
> the "after" NOPs after local entry point.  The new behavior

Thanks.  This looks good to me :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888#c5


-- 
宋方睿

Re: [PATCH] arm: Force flag_pic for FDPIC

[Fangrui Song]

On Mon, Mar 4, 2024 at 12:13 AM Fangrui Song  wrote:
>
> From: Fangrui Song 
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor).  The sh port simply upgrades -fno-pic to -fpie by setting
> flag_pic.  Let's follow suit.
>
> Link: 
> https://inbox.sourceware.org/gcc-patches/20150913165303.gc17...@brightrain.aerifal.cx/
>
> gcc/ChangeLog:
>
> * config/arm/arm.cc (arm_option_override): Set flag_pic if
>   TARGET_FDPIC.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/fdpic-pie.c: New test.
> ---
>  gcc/config/arm/arm.cc|  6 +
>  gcc/testsuite/gcc.target/arm/fdpic-pie.c | 30 
>  2 files changed, 36 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/arm/fdpic-pie.c
>
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index 1cd69268ee9..f2fd3cce48c 100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -3682,6 +3682,12 @@ arm_option_override (void)
>arm_pic_register = FDPIC_REGNUM;
>if (TARGET_THUMB1)
> sorry ("FDPIC mode is not supported in Thumb-1 mode");
> +
> +  /* FDPIC code is a special form of PIC, and the vast majority of code
> +generation constraints that apply to PIC also apply to FDPIC, so we
> + set flag_pic to avoid the need to check TARGET_FDPIC everywhere
> + flag_pic is checked. */
> +  flag_pic = 2;
>  }
>
>if (arm_pic_register_string != NULL)
> diff --git a/gcc/testsuite/gcc.target/arm/fdpic-pie.c 
> b/gcc/testsuite/gcc.target/arm/fdpic-pie.c
> new file mode 100644
> index 000..909db8bce74
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/fdpic-pie.c
> @@ -0,0 +1,30 @@
> +// { dg-do compile }
> +// { dg-options "-O2 -fno-pic -mfdpic" }
> +// { dg-skip-if "-mpure-code and -fPIC incompatible" { *-*-* } { 
> "-mpure-code" } }
> +
> +__attribute__((visibility("hidden"))) void hidden_fun(void);
> +void fun(void);
> +__attribute__((visibility("hidden"))) extern int hidden_var;
> +extern int var;
> +__attribute__((visibility("hidden"))) const int ro_hidden_var = 42;
> +
> +// { dg-final { scan-assembler "hidden_fun\\(GOTOFFFUNCDESC\\)" } }
> +void *addr_hidden_fun(void) { return hidden_fun; }
> +
> +// { dg-final { scan-assembler "fun\\(GOTFUNCDESC\\)" } }
> +void *addr_fun(void) { return fun; }
> +
> +// { dg-final { scan-assembler "hidden_var\\(GOT\\)" } }
> +void *addr_hidden_var(void) { return _var; }
> +
> +// { dg-final { scan-assembler "var\\(GOT\\)" } }
> +void *addr_var(void) { return  }
> +
> +// { dg-final { scan-assembler ".LANCHOR0\\(GOT\\)" } }
> +const int *addr_ro_hidden_var(void) { return _hidden_var; }
> +
> +// { dg-final { scan-assembler "hidden_var\\(GOT\\)" } }
> +int read_hidden_var(void) { return hidden_var; }
> +
> +// { dg-final { scan-assembler "var\\(GOT\\)" } }
> +int read_var(void) { return var; }
> --
> 2.44.0.rc1.240.g4c46232300-goog

Ping:)


-- 
宋方睿

Re: [PATCH] arm: Support -mfdpic for more targets

[Fangrui Song]

On Wed, Mar 6, 2024 at 1:54 AM Richard Earnshaw (lists)
 wrote:
>
> On 06/03/2024 05:07, Fangrui Song wrote:
> > On Fri, Feb 23, 2024 at 7:33 PM Fangrui Song  wrote:
> >>
> >> From: Fangrui Song 
> >>
> >> Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
> >> -mfdpic does not pass --fdpic to gas.  This is an unnecessary
> >> restriction.  Just define the ASM_SPEC in bpabi.h.
> >>
> >> Additionally, use armelf[b]_linux_fdpiceabi emulations for -mfdpic in
> >> linux-eabi.h.  This will allow a future musl fdpic port to use the
> >> desired BFD emulation.
> >>
> >> gcc/ChangeLog:
> >>
> >> * config/arm/bpabi.h (TARGET_FDPIC_ASM_SPEC): Transform -mfdpic.
> >> * config/arm/linux-eabi.h (TARGET_FDPIC_LINKER_EMULATION): Define.
> >> (SUBTARGET_EXTRA_LINK_SPEC): Use TARGET_FDPIC_LINKER_EMULATION
> >> if -mfdpic.
> >> ---
> >>  gcc/config/arm/bpabi.h  | 2 +-
> >>  gcc/config/arm/linux-eabi.h | 5 -
> >>  2 files changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
> >> index 7a279f3ed3c..6778be1a8bf 100644
> >> --- a/gcc/config/arm/bpabi.h
> >> +++ b/gcc/config/arm/bpabi.h
> >> @@ -55,7 +55,7 @@
> >>  #define TARGET_FIX_V4BX_SPEC " %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*"\
> >>"|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}"
> >>
> >> -#define TARGET_FDPIC_ASM_SPEC ""
> >> +#define TARGET_FDPIC_ASM_SPEC "%{mfdpic: --fdpic}"
> >>
> >>  #define BE8_LINK_SPEC  \
> >>"%{!r:%{!mbe32:%:be8_linkopt(%{mlittle-endian:little}"   \
> >> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> >> index eef791f6a02..0c5c58e4928 100644
> >> --- a/gcc/config/arm/linux-eabi.h
> >> +++ b/gcc/config/arm/linux-eabi.h
> >> @@ -46,12 +46,15 @@
> >>  #undef  TARGET_LINKER_EMULATION
> >>  #if TARGET_BIG_ENDIAN_DEFAULT
> >>  #define TARGET_LINKER_EMULATION "armelfb_linux_eabi"
> >> +#define TARGET_FDPIC_LINKER_EMULATION "armelfb_linux_fdpiceabi"
> >>  #else
> >>  #define TARGET_LINKER_EMULATION "armelf_linux_eabi"
> >> +#define TARGET_FDPIC_LINKER_EMULATION "armelf_linux_fdpiceabi"
> >>  #endif
> >>
> >>  #undef  SUBTARGET_EXTRA_LINK_SPEC
> >> -#define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION
> >> +#define SUBTARGET_EXTRA_LINK_SPEC " -m %{mfdpic: " \
> >> +  TARGET_FDPIC_LINKER_EMULATION ";:" TARGET_LINKER_EMULATION "}"
> >>
> >>  /* GNU/Linux on ARM currently supports three dynamic linkers:
> >> - ld-linux.so.2 - for the legacy ABI
> >> --
> >> 2.44.0.rc1.240.g4c46232300-goog
> >>
> >
> > Ping:)
> >
>
> We're in stage4 at present and this is new material.  I'll look at it after 
> the branch has been cut.
>
> R.

refs/heads/releases/gcc-14 has been cut :)



-- 
宋方睿

[PATCH] RISC-V: Add -X to link spec

[Fangrui Song]

From: Fangrui Song 

--discard-locals (-X) instructs the linker to remove local .L* symbols,
which occur a lot due to label differences for linker relaxation. The
arm port has a similar need and passes -X to ld.

In contrast, the RISC-V port does not pass -X to ld and rely on the
default --discard-locals in GNU ld's riscv port. The arm way is more
conventional (compiler driver instead of the linker customizes the
default behavior) and works with lld.
---
 gcc/config/riscv/elf.h | 1 +
 gcc/config/riscv/freebsd.h | 1 +
 gcc/config/riscv/linux.h   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index f533764d9f8..c97f13c0cca 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 #define LINK_SPEC "\
 -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
 %{mno-relax:--no-relax} \
+-X \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
 %{shared}"
diff --git a/gcc/config/riscv/freebsd.h b/gcc/config/riscv/freebsd.h
index bd08a985285..5dd4d51c42b 100644
--- a/gcc/config/riscv/freebsd.h
+++ b/gcc/config/riscv/freebsd.h
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.  If not see
   %{p:%nconsider using `-pg' instead of `-p' with gprof (1)}   \
   %{v:-V}  \
   %{assert*} %{R*} %{rpath*} %{defsym*}\
+  -X   \
   %{mbig-endian:-EB}   \
   %{mlittle-endian:-EL}\
   %{shared:-Bshareable %{h*} %{soname*}}   \
diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index 15851f653bc..3c356227134 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
 #define LINK_SPEC "\
 -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
 %{mno-relax:--no-relax} \
+-X \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
 %{shared} \
-- 
2.44.0.769.g3c40516874-goog

Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target

[Fangrui Song]

On Mon, Mar 18, 2024 at 3:10 PM Evgeny Karpov
 wrote:
>
>
> Monday, March 18, 2024 2:34 PM
> Christophe Lyon wrote:
>
> > I had a look at the v2 series, and besides a minor comment patch #8, ISTM 
> > than
> > all the comments your received about v1 have been addressed, indeed.
> >
> > > While unit testing for the x86_64-w64-mingw32 target is still in
> > > progress, the first 4 patches do not obviously change other targets,
> > > including aarch64-linux-gnu.
> > > Could they be merged once stage 1 starts, or could it be done even
> > > now?
> >
> > What would be the benefit of committing only the first 4 patches?
> > (whether now or when stage 1 reopens)
> >
> > Thanks,
> >
> > Christophe
>
> Work on obtaining regression test results for x86_x64-w64-mingw32 was still 
> in progress at that moment.
> The first 4 patches do not obviously change other targets, so it was safe to 
> merge them.
> Now, based on the regression test results 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647967.html,
> it appears safe to merge the entire series.
>
> Regards,
> Evgeny

LLVM has had an aarch64 mingw ABI support for a long time. Does this
patch series introduce a different ABI?
If yes, do you have a summary?

Does the patch need any adaptation on the LLVM side, or should a
different target triple be picked?
I have always been wondering what "32" in "x86_x64-w64-mingw32" means.

https://github.com/llvm/llvm-project/pull/78908 even introduced the
first use of the triple "arm64ec-w64-mingw32" into llvm-project.


-- 
宋方睿

Re: libbacktrace patch committed: Don't assume compressed section aligned

[Fangrui Song]

On ELF64, it looks like BFD uses 8-byte alignment for compressed
`.debug_*` sections while gold/lld/mold use 1-byte alignment. I do not
know how the Solaris linker sets the alignment.

The specification's wording makes me confused whether it really
requires 8-byte alignment, even if a non-packed `Elf64_Chdr` surely
requires 8.

> The sh_size and sh_addralign fields of the section header for a compressed 
> section reflect the requirements of the compressed section.

There are many `.debug_*` sections. So avoiding some alignment padding
seems a very natural extension (a DWARF v5 -gsplit-dwarf relocatable
file has ~10 `.debug_*` sections), even if the specification doesn't
allow it with a very strict interpretation...

(Off-topic: I wonder whether ELF control structures should use
unaligned LEB128 more. REL/RELA can naturally be replaced with a
LEB128 one similar to wasm.)

On Fri, Mar 8, 2024 at 1:57 PM Ian Lance Taylor  wrote:
>
> Reportedly when lld compresses debug sections, it fails to set the
> alignment of the compressed section such that the compressed header
> can be read directly.  To me this seems like a bug in lld.  However,
> libbacktrace needs to work around it.  This patch, originally by the
> GitHub user ubyte, does that.  Bootstrapped and tested on
> x86_64-pc-linux-gnu.  Committed to mainline.
>
> Ian
>
> * elf.c (elf_uncompress_chdr): Don't assume compressed section is
> aligned.



-- 
宋方睿

Re: [PATCH] arm: Support -mfdpic for more targets

[Fangrui Song]

On Fri, Feb 23, 2024 at 7:33 PM Fangrui Song  wrote:
>
> From: Fangrui Song 
>
> Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
> -mfdpic does not pass --fdpic to gas.  This is an unnecessary
> restriction.  Just define the ASM_SPEC in bpabi.h.
>
> Additionally, use armelf[b]_linux_fdpiceabi emulations for -mfdpic in
> linux-eabi.h.  This will allow a future musl fdpic port to use the
> desired BFD emulation.
>
> gcc/ChangeLog:
>
> * config/arm/bpabi.h (TARGET_FDPIC_ASM_SPEC): Transform -mfdpic.
> * config/arm/linux-eabi.h (TARGET_FDPIC_LINKER_EMULATION): Define.
> (SUBTARGET_EXTRA_LINK_SPEC): Use TARGET_FDPIC_LINKER_EMULATION
> if -mfdpic.
> ---
>  gcc/config/arm/bpabi.h  | 2 +-
>  gcc/config/arm/linux-eabi.h | 5 -
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
> index 7a279f3ed3c..6778be1a8bf 100644
> --- a/gcc/config/arm/bpabi.h
> +++ b/gcc/config/arm/bpabi.h
> @@ -55,7 +55,7 @@
>  #define TARGET_FIX_V4BX_SPEC " %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*"\
>"|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}"
>
> -#define TARGET_FDPIC_ASM_SPEC ""
> +#define TARGET_FDPIC_ASM_SPEC "%{mfdpic: --fdpic}"
>
>  #define BE8_LINK_SPEC  \
>"%{!r:%{!mbe32:%:be8_linkopt(%{mlittle-endian:little}"   \
> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> index eef791f6a02..0c5c58e4928 100644
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -46,12 +46,15 @@
>  #undef  TARGET_LINKER_EMULATION
>  #if TARGET_BIG_ENDIAN_DEFAULT
>  #define TARGET_LINKER_EMULATION "armelfb_linux_eabi"
> +#define TARGET_FDPIC_LINKER_EMULATION "armelfb_linux_fdpiceabi"
>  #else
>  #define TARGET_LINKER_EMULATION "armelf_linux_eabi"
> +#define TARGET_FDPIC_LINKER_EMULATION "armelf_linux_fdpiceabi"
>  #endif
>
>  #undef  SUBTARGET_EXTRA_LINK_SPEC
> -#define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION
> +#define SUBTARGET_EXTRA_LINK_SPEC " -m %{mfdpic: " \
> +  TARGET_FDPIC_LINKER_EMULATION ";:" TARGET_LINKER_EMULATION "}"
>
>  /* GNU/Linux on ARM currently supports three dynamic linkers:
> - ld-linux.so.2 - for the legacy ABI
> --
> 2.44.0.rc1.240.g4c46232300-goog
>

Ping:)


-- 
宋方睿

[PATCH] arm: Force flag_pic for FDPIC

[Fangrui Song]

From: Fangrui Song 

-fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
for FDPIC (absolute addressing for symbol references and no function
descriptor).  The sh port simply upgrades -fno-pic to -fpie by setting
flag_pic.  Let's follow suit.

Link: 
https://inbox.sourceware.org/gcc-patches/20150913165303.gc17...@brightrain.aerifal.cx/

gcc/ChangeLog:

* config/arm/arm.cc (arm_option_override): Set flag_pic if
  TARGET_FDPIC.

gcc/testsuite/ChangeLog:

* gcc.target/arm/fdpic-pie.c: New test.
---
 gcc/config/arm/arm.cc|  6 +
 gcc/testsuite/gcc.target/arm/fdpic-pie.c | 30 
 2 files changed, 36 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arm/fdpic-pie.c

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 1cd69268ee9..f2fd3cce48c 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -3682,6 +3682,12 @@ arm_option_override (void)
   arm_pic_register = FDPIC_REGNUM;
   if (TARGET_THUMB1)
sorry ("FDPIC mode is not supported in Thumb-1 mode");
+
+  /* FDPIC code is a special form of PIC, and the vast majority of code
+generation constraints that apply to PIC also apply to FDPIC, so we
+ set flag_pic to avoid the need to check TARGET_FDPIC everywhere
+ flag_pic is checked. */
+  flag_pic = 2;
 }
 
   if (arm_pic_register_string != NULL)
diff --git a/gcc/testsuite/gcc.target/arm/fdpic-pie.c 
b/gcc/testsuite/gcc.target/arm/fdpic-pie.c
new file mode 100644
index 000..909db8bce74
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/fdpic-pie.c
@@ -0,0 +1,30 @@
+// { dg-do compile }
+// { dg-options "-O2 -fno-pic -mfdpic" }
+// { dg-skip-if "-mpure-code and -fPIC incompatible" { *-*-* } { "-mpure-code" 
} }
+
+__attribute__((visibility("hidden"))) void hidden_fun(void);
+void fun(void);
+__attribute__((visibility("hidden"))) extern int hidden_var;
+extern int var;
+__attribute__((visibility("hidden"))) const int ro_hidden_var = 42;
+
+// { dg-final { scan-assembler "hidden_fun\\(GOTOFFFUNCDESC\\)" } }
+void *addr_hidden_fun(void) { return hidden_fun; }
+
+// { dg-final { scan-assembler "fun\\(GOTFUNCDESC\\)" } }
+void *addr_fun(void) { return fun; }
+
+// { dg-final { scan-assembler "hidden_var\\(GOT\\)" } }
+void *addr_hidden_var(void) { return _var; }
+
+// { dg-final { scan-assembler "var\\(GOT\\)" } }
+void *addr_var(void) { return  }
+
+// { dg-final { scan-assembler ".LANCHOR0\\(GOT\\)" } }
+const int *addr_ro_hidden_var(void) { return _hidden_var; }
+
+// { dg-final { scan-assembler "hidden_var\\(GOT\\)" } }
+int read_hidden_var(void) { return hidden_var; }
+
+// { dg-final { scan-assembler "var\\(GOT\\)" } }
+int read_var(void) { return var; }
-- 
2.44.0.rc1.240.g4c46232300-goog

[PATCH] Add myself to write after approval and DCO

[Fangrui Song]

From: Fangrui Song 

ChangeLog:

* MAINTAINERS: Add myself.

Signed-off-by: Fangrui Song 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 986e8d0a725..b01fab16061 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -669,6 +669,7 @@ Edward Smith-Rowland

 Anatoly Sokolov
 Michael Sokolov

 Jayant Sonar   
+Fangrui Song   
 Richard Stallman   
 Basile Starynkevitch   
 Jakub Staszak  
@@ -779,6 +780,7 @@ Bill Schmidt

 Nathaniel Shead

 Nathan Sidwell 
 Edward Smith-Rowland   
+Fangrui Song   
 Petter Tomner  
 Martin Uecker  
 Jonathan Wakely
-- 
2.44.0.rc1.240.g4c46232300-goog

[PATCH] arm: Support -mfdpic for more targets

[Fangrui Song]

From: Fangrui Song 

Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
-mfdpic does not pass --fdpic to gas.  This is an unnecessary
restriction.  Just define the ASM_SPEC in bpabi.h.

Additionally, use armelf[b]_linux_fdpiceabi emulations for -mfdpic in
linux-eabi.h.  This will allow a future musl fdpic port to use the
desired BFD emulation.

gcc/ChangeLog:

* config/arm/bpabi.h (TARGET_FDPIC_ASM_SPEC): Transform -mfdpic.
* config/arm/linux-eabi.h (TARGET_FDPIC_LINKER_EMULATION): Define.
(SUBTARGET_EXTRA_LINK_SPEC): Use TARGET_FDPIC_LINKER_EMULATION
if -mfdpic.
---
 gcc/config/arm/bpabi.h  | 2 +-
 gcc/config/arm/linux-eabi.h | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
index 7a279f3ed3c..6778be1a8bf 100644
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -55,7 +55,7 @@
 #define TARGET_FIX_V4BX_SPEC " %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*"\
   "|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}"
 
-#define TARGET_FDPIC_ASM_SPEC ""
+#define TARGET_FDPIC_ASM_SPEC "%{mfdpic: --fdpic}"
 
 #define BE8_LINK_SPEC  \
   "%{!r:%{!mbe32:%:be8_linkopt(%{mlittle-endian:little}"   \
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index eef791f6a02..0c5c58e4928 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -46,12 +46,15 @@
 #undef  TARGET_LINKER_EMULATION
 #if TARGET_BIG_ENDIAN_DEFAULT
 #define TARGET_LINKER_EMULATION "armelfb_linux_eabi"
+#define TARGET_FDPIC_LINKER_EMULATION "armelfb_linux_fdpiceabi"
 #else
 #define TARGET_LINKER_EMULATION "armelf_linux_eabi"
+#define TARGET_FDPIC_LINKER_EMULATION "armelf_linux_fdpiceabi"
 #endif
 
 #undef  SUBTARGET_EXTRA_LINK_SPEC
-#define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION
+#define SUBTARGET_EXTRA_LINK_SPEC " -m %{mfdpic: " \
+  TARGET_FDPIC_LINKER_EMULATION ";:" TARGET_LINKER_EMULATION "}"
 
 /* GNU/Linux on ARM currently supports three dynamic linkers:
- ld-linux.so.2 - for the legacy ABI
-- 
2.44.0.rc1.240.g4c46232300-goog

Re: [PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Fangrui Song]

+Martin who may have an opinion
(https://github.com/mstorsjo/llvm-mingw supports aarch64)

On Fri, Feb 23, 2024 at 6:15 AM Evgeny Karpov
 wrote:
>
> Hi Andrew and Richard,
>
> Thank you for pointing out there's no need for a 64-bit ISA and the 
> big-endian target.
> These changes will be addressed in v2.
>
> Regards,
> Evgeny
>
> -Original Message-
> Thursday, February 22, 2024 12:33 PM
> Richard Earnshaw (lists)  wrote:
> >
> +aarch64*-*-mingw*)
>
> Other targets are a bit inconsistent here as well, but, as Andrew mentioned, 
> if you don't want to handle big-endian, it might be better to match 
> aarch64-*-mingw* here.
>
>
> -Original Message-
> Wednesday, February 21, 2024 7:23 PM
> Andrew Pinski wrote:
>
> > need_64bit_isa=yes
>
> This is not needed in the patch as it is only used for x86_64 targets.
>
> Should you make sure nobody specifies the big-endian target:
> aarch64_be-w64-mingw32  ?
>


-- 
宋方睿

Re: [PATCH] RISC-V: Add tests for constraints "i" and "s"

[Fangrui Song]

On Wed, Feb 21, 2024 at 4:07 PM Kito Cheng  wrote:
>
> LGTM, but I am OoO today, will commit that once I have laptop :p

Thanks! Dropped the gcc/doc/md.texi change and pushed as commit
9ca4c1bf082a4691482ca9f4814fea68f04e2cb3
(I have write-after-approval now:) )

> Fangrui Song  於 2024年2月22日 週四 05:54 寫道：
>>
>> On Tue, Feb 13, 2024 at 10:36 PM Fangrui Song  wrote:
>> >
>> > The constraints "i" and "s" can be used with a symbol that binds
>> > externally, e.g.
>> > ```
>> > namespace ns { extern int var, a[4]; }
>> > void foo() {
>> >   asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "s"(::var));
>> >   asm(".reloc ., BFD_RELOC_NONE, %0" :: "s"(::a[3]));
>> > }
>> > ```
>> >
>> > gcc/testsuite/ChangeLog:
>> >
>> > * gcc.target/riscv/asm-raw-symbol.c: New test.
>> > ---
>> >  gcc/doc/md.texi |  2 +-
>> >  gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c | 14 ++
>> >  2 files changed, 15 insertions(+), 1 deletion(-)
>> >  create mode 100644 gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
>> >
>> > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
>> > index b0c61925120..c75e5bf259d 100644
>> > --- a/gcc/doc/md.texi
>> > +++ b/gcc/doc/md.texi
>> > @@ -1947,7 +1947,7 @@ Integer constant that is valid as an immediate 
>> > operand in a 64-bit @code{MOV}
>> >  pseudo instruction
>> >
>> >  @item S
>> > -An absolute symbolic address or a label reference
>> > +A symbolic reference or label reference.
>> >
>> >  @item Y
>> >  Floating point constant zero
>> > diff --git a/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c 
>> > b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
>> > new file mode 100644
>> > index 000..28305a8b1f0
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
>> > @@ -0,0 +1,14 @@
>> > +/* { dg-do compile } */
>> > +/* { dg-options "-fpic" } */
>> > +
>> > +extern int var, arr[2][2];
>> > +
>> > +void
>> > +test (void)
>> > +{
>> > +  __asm__ ("@ %0" : : "i"());
>> > +  __asm__ ("@ %0 %1 %2" : : "s"(), "s"([1][1]), "s"(test));
>> > +}
>> > +
>> > +/* { dg-final { scan-assembler "@ var arr\\+12 test" } } */
>> > +/* { dg-final { scan-assembler "@ var" } } */
>> > --
>> > 2.43.0.687.g38aa6559b0-goog
>> >
>>
>> Ping:)
>>
>>
>> --
>> 宋方睿



-- 
宋方睿

Re: [PATCH] RISC-V: Add tests for constraints "i" and "s"

[Fangrui Song]

On Tue, Feb 13, 2024 at 10:36 PM Fangrui Song  wrote:
>
> The constraints "i" and "s" can be used with a symbol that binds
> externally, e.g.
> ```
> namespace ns { extern int var, a[4]; }
> void foo() {
>   asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "s"(::var));
>   asm(".reloc ., BFD_RELOC_NONE, %0" :: "s"(::a[3]));
> }
> ```
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/asm-raw-symbol.c: New test.
> ---
>  gcc/doc/md.texi |  2 +-
>  gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c | 14 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
>
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index b0c61925120..c75e5bf259d 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -1947,7 +1947,7 @@ Integer constant that is valid as an immediate operand 
> in a 64-bit @code{MOV}
>  pseudo instruction
>
>  @item S
> -An absolute symbolic address or a label reference
> +A symbolic reference or label reference.
>
>  @item Y
>  Floating point constant zero
> diff --git a/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c 
> b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
> new file mode 100644
> index 000..28305a8b1f0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fpic" } */
> +
> +extern int var, arr[2][2];
> +
> +void
> +test (void)
> +{
> +  __asm__ ("@ %0" : : "i"());
> +  __asm__ ("@ %0 %1 %2" : : "s"(), "s"([1][1]), "s"(test));
> +}
> +
> +/* { dg-final { scan-assembler "@ var arr\\+12 test" } } */
> +/* { dg-final { scan-assembler "@ var" } } */
> --
> 2.43.0.687.g38aa6559b0-goog
>

Ping:)


-- 
宋方睿

Re: Question on -fwrapv and -fwrapv-pointer

[Fangrui Song]

On Fri, Sep 15, 2023 at 11:43 AM Kees Cook via Gcc-patches
 wrote:
>
> On Fri, Sep 15, 2023 at 05:47:08PM +, Qing Zhao wrote:
> >
> >
> > > On Sep 15, 2023, at 1:26 PM, Richard Biener  
> > > wrote:
> > >
> > >
> > >
> > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao :
> > >>
> > >> 
> > >>
> >  On Sep 15, 2023, at 11:29 AM, Richard Biener 
> >   wrote:
> > 
> > 
> > 
> > > Am 15.09.2023 um 17:25 schrieb Qing Zhao :
> > 
> >  
> > 
> > > On Sep 15, 2023, at 8:41 AM, Arsen Arsenović  wrote:
> > >
> > >
> > > Qing Zhao  writes:
> > >
> > >> Even though unsigned integer overflow is well defined, it might be
> > >> unintentional, shall we warn user about this?
> > >
> > > This would be better addressed by providing operators or functions 
> > > that
> > > do overflow checking in the language, so that they can be explicitly
> > > used where overflow is unexpected.
> > 
> >  Yes, that will be very helpful to prevent unexpected overflow in the 
> >  program in general.
> >  However, this will mainly benefit new codes.
> > 
> >  For the existing C codes, especially large applications, we still need 
> >  to identify all the places
> >  Where the overflow is unexpected, and fix them.
> > 
> >  One good example is linux kernel.
> > 
> > > One could easily imagine a scenario
> > > where overflow is not expected in some region of code but is in the
> > > larger application.
> > 
> >  Yes, that’s exactly the same situation Linux kernel faces now, the 
> >  unexpected Overflow and
> >  expected wrap-around are mixed together inside one module.
> >  It’s hard to detect the unexpected overflow under such situation based 
> >  on the current GCC.
> > >>>
> > >>> But that’s hardly GCCs fault nor can GCC fix that in any way.  Only the 
> > >>> programmer can distinguish both cases.
> > >>
> > >> Right, compiler cannot fix this.
> > >> But can provide some tools to help the user to detect this more 
> > >> conveniently.
> > >>
> > >> Right now, GCC provides two set of options for different types:
> > >>
> > >> A. Turn the overflow to expected wrap-around (remove UB);
> > >> B. Detect overflow;
> > >>
> > >>   AB
> > >>  remove UB-fsanitize=…
> > >> signed   -fwrapvsigned-integer-overflow
> > >> pointer   -fwrapv-pointerpointer-overflow (broken in Clang)
> > >>
> > >> However, Options in A and B excluded with each other. They cannot mix 
> > >> together for a single file.
> > >>
> > >> What’s requested from Kernel is:
> > >>
> > >> compiler needs to provide a functionality that can mix these two 
> > >> together for a file.
> > >>
> > >> i.e, apply A (convert UB to defined behavior WRAP-AROUND) only to part 
> > >> of the program.  And then add -fsnaitize=*overflow to detect all other
> > >> Unexpected overflows in the program.

Yes, I believe combining A and B should be allowed.

> > >> This is currently missing from GCC, I guess?
> > >
> > > How can GCC know which part of the program wants wrapping and which 
> > > sanitizing?
> >
> > GCC doesn’t know, but the user knows.
> >
> > Then just provide the user a way to mark part of the program to be wrapping 
> > around and excluded from sanitizing?
> >
> > Currently, GCC provides
> >
> > __attribute__(optimize ("wrapv"))
> >
> > To mark the specific function to be wrapped around.
> >
> > However, this attribute does not work for linux kernel due to the following 
> > reason:
> >
> > Attribute optimize should be only used for debugging purpose;
> > The kernel has banned its usage;
> >
> > So, a new attribute was requested from Linux kernel security:
> >
> >  request wrap-around behavior for specific function (PR102317)
> > __attribute__((wrapv))
> >
> > Is this request reasonable?
>
> After working through this discussion, I'd say it's likely more helpful
> to have a way to disable the sanitizers for a given function (or
> variable). i.e. The goal for the kernel would that untrapped wrap-around
> would be the very rare exception. e.g. our refcount_t implementation:
> https://elixir.bootlin.com/linux/v6.5/source/include/linux/refcount.h#L200
>
> Then we can continue to build the kernel with -fno-strict-overflow (to
> avoid UB), but gain sanitizer coverage for all run-time wraps, except
> for the very few places where we depend on it. Getting there will also
> take some non-trivial refactoring on our end, but without the sanitizers
> we're unlikely to find them all.
>
> --
> Kees Cook

I see a Clang patch that proposes -fsanitize=signed-integer-wrap,
which appears to be the same as signed-integer-overflow, but performs
the check in the -fwrapv mode.
I made a reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317#c13 that we
probably should just make -fsanitize=signed-integer-overflow work with
-fwrapv.

(This message is made so that interested 

[PATCH] RISC-V: Add tests for constraints "i" and "s"

[Fangrui Song]

The constraints "i" and "s" can be used with a symbol that binds
externally, e.g.
```
namespace ns { extern int var, a[4]; }
void foo() {
  asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "s"(::var));
  asm(".reloc ., BFD_RELOC_NONE, %0" :: "s"(::a[3]));
}
```

gcc/testsuite/ChangeLog:

* gcc.target/riscv/asm-raw-symbol.c: New test.
---
 gcc/doc/md.texi |  2 +-
 gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index b0c61925120..c75e5bf259d 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1947,7 +1947,7 @@ Integer constant that is valid as an immediate operand in 
a 64-bit @code{MOV}
 pseudo instruction
 
 @item S
-An absolute symbolic address or a label reference
+A symbolic reference or label reference.
 
 @item Y
 Floating point constant zero
diff --git a/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c 
b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
new file mode 100644
index 000..28305a8b1f0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-fpic" } */
+
+extern int var, arr[2][2];
+
+void
+test (void)
+{
+  __asm__ ("@ %0" : : "i"());
+  __asm__ ("@ %0 %1 %2" : : "s"(), "s"([1][1]), "s"(test));
+}
+
+/* { dg-final { scan-assembler "@ var arr\\+12 test" } } */
+/* { dg-final { scan-assembler "@ var" } } */
-- 
2.43.0.687.g38aa6559b0-goog

Re: [PATCH] i386, testsuite: adjust asm patterns

[Fangrui Song]

On Sun, Feb 11, 2024 at 11:12 AM Mike Stump  wrote:
>
> On Feb 10, 2024, at 10:07 AM, FX Coudert  wrote:
> >
> > The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is 
> > partly because symbols are prefixed with underscore, and also because the 
> > order of operands in the addition is reversed (but I think it’s valid 
> > still). The code generated is this:
> >
> > _func:
> > LFB0:
> >pushq   %rbp
> > LCFI0:
> >movq%rsp, %rbp
> > LCFI1:
> > # 8 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 
> > 1
> >@ _func
> > # 0 "" 2
> > # 9 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 
> > 1
> >@ 4+_var
> > # 0 "" 2
> >nop
> >popq%rbp
> > LCFI2:
> >ret
> >
> >
> >
> > I’m adjusting the pattern accordingly.
> > OK to push?
>
> Ok.

Thanks for commit bbf05e3753c0fd49f1a3bf23897fa96d052ddae9!



-- 
宋方睿

Re: [PATCH] RISC-V: Allow constraint "S" even if the symbol does not bind locally

[Fangrui Song]

On Tue, Jan 30, 2024 at 11:26 PM Kito Cheng  wrote:
>
> I realized there is 's' constraint which is defined in GCC generic
> infra[1], and that's kinda what same as the new semantic of 'S' here,
>
> (define_constraint "s"
>  "Matches a symbolic integer constant."
>  (and (match_test "CONSTANT_P (op)")
>   (match_test "!CONST_SCALAR_INT_P (op)")
>   (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))
>
> Where const, symbol_ref and label_ref is match CONSTANT_P &&
> !CONST_SCALAR_INT_P,
> and LEGITIMATE_PIC_OPERAND_P is always 1 for RISC-V

Thanks for catching this! I read "symbolic integer constant" and
skipped, but did not realized that
this actually means a symbol or label reference with a constant offset.
I agree that "s" should be preferred.
I have jotted down some notes at
https://maskray.me/blog/2024-01-30-raw-symbol-names-in-inline-assembly

The condition !flag_pic || LEGITIMATE_PIC_OPERAND_P (op) highlights a
key distinction in GCC's handling of symbol references:

Non-PIC code (-fno-pic): The "i" and "s" constraints are freely permitted.
PIC code (-fpie and -fpic): The architecture-specific
LEGITIMATE_PIC_OPERAND_P(X) macro dictates whether these constraints
are allowed.

While the default implementation (gcc/defaults.h) is permissive (used
by MIPS, PowerPC, and RISC-V), many ports impose stricter
restrictions, often disallowing preemptible symbols under PIC.

This differentiation probably stems from historical and architectural
considerations:

Non-PIC code: Absolute addresses could be directly embedded in
instructions like an immediate integer operand.
PIC code with dynamic linking: The need for GOT indirection often
requires an addressing mode different from absolute addressing and
more than one instructions.

Nevertheless, I think this symbol preemptibility limitation for "s" is
unfortunate. Ideally, we could retain the current "i" for immediate
integer operand (after linking), and design "s" for a raw symbol name
with a constant offset, ignoring symbol preemptibility. This
architecture-agnostic "s" would simplify metadata section utilization
and boost code portability.


> The only difference is it also allows high, which is something like
> %hi(sym), but I think it's harmless in the use case.

I do not follow this. Do you have an example?

> However I found LLVM also not work on " asm(".reloc ., BFD_RELOC_NONE,
> %0" :: "S"(::a[3]));",
> so maybe we could consider implement 's' in LLVM? and also add some
> document in riscv-c-api.md

Clang does not implement the offset yet.
I created https://github.com/llvm/llvm-project/pull/80201 to support "s"

> And just clarify, I don't have strong prefer on using 's', I am ok
> with relaxing 'S' too,
> propose using 's' is because that is work fine on RISC-V gcc for long
> time and no backward compatible issue,
> But I guess you have this proposal may came from ClangBuiltLinux, so
> 's' may not work for clang well due to backward compatible.

It seems that ClangBuiltLinux can live with "i" for now:)

I raised the topic due to a micro-optimization opportunity in
https://github.com/protocolbuffers/protobuf/blob/1fe463ce71b6acc60b3aef65d51185e3704cac8b/src/google/protobuf/stubs/common.h#L86
and I believe metadata sections will get more used and compilers
should be prepared for future uses.

I'll abandon this "S" change. I can create a test-only change if you
think the test coverage is useful, as we hardly have any non-rvv
inline asm tests at present...

> [1] 
> https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#index-s-in-constraint
> [2] 
> https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md#constraints-on-operands-of-inline-assembly-statements
>
> On Wed, Jan 31, 2024 at 1:02 PM Fangrui Song  wrote:
> >
> > The constraint "S" can only be used with a symbol that binds locally, so
> > the following does not work for -fpie/-fpic (GOT access is used).
> > ```
> > namespace ns { extern int var, a[4]; }
> > void foo() {
> >   asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "S"(::var));
> >   asm(".reloc ., BFD_RELOC_NONE, %0" :: "S"(::a[3]));
> > }
> > ```
> >
> > This is overly restrictive, as many references like an absolute
> > relocation in a writable section or a non-SHF_ALLOC section should be
> > totally fine.  Allow symbols that do not bind locally, similar to
> > aarch64 "S" and x86-64 "Ws" (commit 
> > d7250100381b817114447d91fff4748526d4fb21).
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/constraint

[PATCH] RISC-V: Allow constraint "S" even if the symbol does not bind locally

[Fangrui Song]

The constraint "S" can only be used with a symbol that binds locally, so
the following does not work for -fpie/-fpic (GOT access is used).
```
namespace ns { extern int var, a[4]; }
void foo() {
  asm(".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "S"(::var));
  asm(".reloc ., BFD_RELOC_NONE, %0" :: "S"(::a[3]));
}
```

This is overly restrictive, as many references like an absolute
relocation in a writable section or a non-SHF_ALLOC section should be
totally fine.  Allow symbols that do not bind locally, similar to
aarch64 "S" and x86-64 "Ws" (commit d7250100381b817114447d91fff4748526d4fb21).

gcc/ChangeLog:

* config/riscv/constraints.md: Relax the condition for "S".
* doc/md.texi: Update.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/asm-raw-symbol.c: New test.
---
 gcc/config/riscv/constraints.md |  4 ++--
 gcc/doc/md.texi |  2 +-
 gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c | 17 +
 3 files changed, 20 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c

diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index 41acaea04eb..bb012668fcb 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -121,8 +121,8 @@ (define_memory_constraint "A"
(match_test "GET_CODE(XEXP(op,0)) == REG")))
 
 (define_constraint "S"
-  "A constraint that matches an absolute symbolic address."
-  (match_operand 0 "absolute_symbolic_operand"))
+  "A symbolic reference or label reference."
+  (match_code "const,symbol_ref,label_ref"))
 
 (define_constraint "U"
   "@internal
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index b0c61925120..c75e5bf259d 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1947,7 +1947,7 @@ Integer constant that is valid as an immediate operand in 
a 64-bit @code{MOV}
 pseudo instruction
 
 @item S
-An absolute symbolic address or a label reference
+A symbolic reference or label reference.
 
 @item Y
 Floating point constant zero
diff --git a/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c 
b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
new file mode 100644
index 000..eadf6d23fe1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/asm-raw-symbol.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-fpic" } */
+
+extern int var;
+
+void
+func (void)
+{
+label:
+  __asm__ ("@ %0" : : "S" (func));
+  __asm__ ("@ %0" : : "S" ( + 1));
+  __asm__ ("@ %0" : : "S" (&));
+}
+
+/* { dg-final { scan-assembler "@ func" } } */
+/* { dg-final { scan-assembler "@ var\\+4" } } */
+/* { dg-final { scan-assembler "@ .L" } } */
-- 
2.43.0.429.g432eaa2c6b-goog

Re: [PATCH v4] RISC-V: Implement TLS Descriptors.

[Fangrui Song]

On Mon, Dec 4, 2023 at 11:02 PM Tatsuyuki Ishi  wrote:
>
> This implements TLS Descriptors (TLSDESC) as specified in [1].
>
> The 4-instruction sequence is implemented as a single RTX insn for
> simplicity, but this can be revisited later if instruction scheduling or
> more flexible RA is desired.
>
> The default remains to be the traditional TLS model, but can be configured
> with --with_tls={trad,desc}. The choice can be revisited once toolchain
> and libc support ships.

typo: --with-tls={trad,desc}.

The patch looks good to me, but I am not an approver:) I only have
some nitpicky comments.

Reviewed-by: Fangrui Song 

I know that the binutils patch needs some work, but I think it doesn't
have to block this patch.
BTW, Clang got -mtls-dialect=desc today, so one can test GCC by  gcc
-S -fpic -mtls-dialect + clang -c + ld.lld + musl
https://maskray.me/blog/2024-01-23-riscv-tlsdesc-works

I actually tested my ld.lld patch by compiling with GCC and manually
replacing TLS GD code sequence with TLSDESC :)

> [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
>
> gcc/Changelog:
> * config/riscv/riscv.opt: Add -mtls-dialect to configure TLS flavor.
> * config.gcc: Add --with_tls configuration option to change the
> default TLS flavor.
> * config/riscv/riscv.h: Add TARGET_TLSDESC determined from
> -mtls-dialect and with_tls defaults.
> * config/riscv/riscv-opts.h: Define enum riscv_tls_type for the
> two TLS flavors.
> * config/riscv/riscv-protos.h: Define SYMBOL_TLSDESC symbol type.
> * config/riscv/riscv.md: Add instruction sequence for TLSDESC.
> * config/riscv/riscv.cc (riscv_symbol_insns): Add instruction
> sequence length data for TLSDESC.
> (riscv_legitimize_tls_address): Add lowering of TLSDESC.
> * doc/install.texi: Document --with-tls for RISC-V.
> * doc/invoke.texi: Document -mtls-dialect for RISC-V.
> * testsuite/gcc.target/riscv/tls_1.x: Add TLSDESC GD test case.
> * testsuite/gcc.target/riscv/tlsdesc.c: Same as above.
> ---
> No regression in gcc tests for rv64gc, tested alongside the binutils and
> glibc implementation. Tested with --with_tls=desc.
>
> v2: Add with_tls configuration option, and a few readability improvements.
> Added Changelog.
> v3: Add documentation per Kito's suggestion.
> Fix minor issues pointed out by Kito and Jeff.
> Thanks Kito Cheng and Jeff Law for review.
> v4: Add TLSDESC GD assembly test.
> Rebase on top of trunk.
>
>  gcc/config.gcc   | 15 ++-
>  gcc/config/riscv/riscv-opts.h|  6 ++
>  gcc/config/riscv/riscv-protos.h  |  5 +++--
>  gcc/config/riscv/riscv.cc| 24 
>  gcc/config/riscv/riscv.h |  9 +++--
>  gcc/config/riscv/riscv.md| 20 +++-
>  gcc/config/riscv/riscv.opt   | 14 ++
>  gcc/doc/install.texi |  3 +++
>  gcc/doc/invoke.texi  | 13 -
>  gcc/testsuite/gcc.target/riscv/tls_1.x   |  5 +
>  gcc/testsuite/gcc.target/riscv/tlsdesc.c | 12 
>  11 files changed, 115 insertions(+), 11 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/tls_1.x
>  create mode 100644 gcc/testsuite/gcc.target/riscv/tlsdesc.c
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 748430194f3..8bb22e9f590 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -2490,6 +2490,7 @@ riscv*-*-linux*)
> # Force .init_array support.  The configure script cannot always
> # automatically detect that GAS supports it, yet we require it.
> gcc_cv_initfini_array=yes
> +   with_tls=${with_tls:-trad}
> ;;
>  riscv*-*-elf* | riscv*-*-rtems*)
> tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
> @@ -2532,6 +2533,7 @@ riscv*-*-freebsd*)
> # Force .init_array support.  The configure script cannot always
> # automatically detect that GAS supports it, yet we require it.
> gcc_cv_initfini_array=yes
> +   with_tls=${with_tls:-trad}
> ;;
>
>  loongarch*-*-linux*)
> @@ -4658,7 +4660,7 @@ case "${target}" in
> ;;
>
> riscv*-*-*)
> -   supported_defaults="abi arch tune riscv_attribute isa_spec"
> +   supported_defaults="abi arch tune riscv_attribute isa_spec 
> tls"
>
> case "${target}" in
> riscv-* | riscv32*) xlen=32 ;;
> @@ -4788,6 +4790,17 @@ case "${target}" in
> ;;
>  

[PATCH] i386: Default to -mcet-switch [PR104816]

[Fangrui Song]

When -fcf-protection=branch is used, with the current -mno-cet-switch
default, a NOTRACK indirect jump is generated for jump tables, which can
target a non-ENDBR instruction.  However, the overwhelming opinion is to
avoid NOTRACK (PR104816) to improve safety.  Projects such as Linux
kernel and Xen even specify -fno-jump-table to avoid NOTRACK. Therefore,
let's change the default.

Note, for `default: __builtin_unreachable()`, LLVM AArch64 even made a
decision (https://reviews.llvm.org/D155485) to keep the range check,
which can otherwise be optimized out.  This reinforces the opinion that
people want protection for jump tables.

#define DO A(0) A(1) A(2) A(3) A(4) A(5) A(6) A(7) A(8) A(9) A(10) A(11) 
A(12) A(13)
#define A(i) void bar##i();
DO
#undef A
void ext();
void foo(int i) {
  switch (i) {
#define A(i) case i: bar##i(); break;
DO
// -mbranch-protection=bti causes Clang AArch64 to keep the i <= 13 range 
check
  default: __builtin_unreachable();
  }
  ext();
}

gcc/ChangeLog:

PR target/104816
* config/i386/i386.opt: Default to -mcet-switch.
* doc/invoke.texi: Update doc.

gcc/testsuite/ChangeLog:

* gcc.target/i386/cet-switch-1.c: Add -mno-cet-switch.
* gcc.target/i386/cet-switch-2.c: Remove -mcet-switch to check the
  default.
---
 gcc/config/i386/i386.opt |  2 +-
 gcc/doc/invoke.texi  | 19 +--
 gcc/testsuite/gcc.target/i386/cet-switch-1.c |  2 +-
 gcc/testsuite/gcc.target/i386/cet-switch-2.c |  2 +-
 4 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index 5b4f1bff25f..0e168f3c07a 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -1074,7 +1074,7 @@ Enable shadow stack built-in functions from Control-flow 
Enforcement
 Technology (CET).
 
 mcet-switch
-Target Var(flag_cet_switch) Init(0)
+Target Var(flag_cet_switch) Init(1)
 Turn on CET instrumentation for switch statements that use a jump table and
 an indirect jump.
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 16e31a3c6db..720be71f8fa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1455,7 +1455,7 @@ See RS/6000 and PowerPC Options.
 -msse4a  -m3dnow  -m3dnowa  -mpopcnt  -mabm  -mbmi  -mtbm  -mfma4  -mxop
 -madx  -mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mhle  -mlwp
 -mmwaitx  -mclzero  -mpku  -mthreads  -mgfni  -mvaes  -mwaitpkg
--mshstk -mmanual-endbr -mcet-switch -mforce-indirect-call
+-mshstk -mmanual-endbr -mno-cet-switch -mforce-indirect-call
 -mavx512vbmi2 -mavx512bf16 -menqcmd
 -mvpclmulqdq  -mavx512bitalg  -mmovdiri  -mmovdir64b  -mavx512vpopcntdq
 -mavx5124fmaps  -mavx512vnni  -mavx5124vnniw  -mprfchw  -mrdpid
@@ -34886,16 +34886,15 @@ function attribute. This is useful when used with the 
option
 @option{-fcf-protection=branch} to control ENDBR insertion at the
 function entry.
 
+@opindex mno-cet-switch
 @opindex mcet-switch
-@item -mcet-switch
-By default, CET instrumentation is turned off on switch statements that
-use a jump table and indirect branch track is disabled.  Since jump
-tables are stored in read-only memory, this does not result in a direct
-loss of hardening.  But if the jump table index is attacker-controlled,
-the indirect jump may not be constrained by CET.  This option turns on
-CET instrumentation to enable indirect branch track for switch statements
-with jump tables which leads to the jump targets reachable via any indirect
-jumps.
+@item -mno-cet-switch
+When @option{-fcf-protection=branch} is enabled, by default, switch statements
+that use a jump table are instrumented to use ENDBR instructions and constrain
+the indirect jump with CET to protect against an attacker-controlled jump table
+index.  @option{-mno-cet-switch} generates a NOTRACK indirect jump and removes
+ENDBR instructions, which may make the jump table smaller at the cost of an
+unprotected indirect jump.
 
 @opindex mcall-ms2sysv-xlogues
 @opindex mno-call-ms2sysv-xlogues
diff --git a/gcc/testsuite/gcc.target/i386/cet-switch-1.c 
b/gcc/testsuite/gcc.target/i386/cet-switch-1.c
index afe5adc2f3d..4931c3ad1d2 100644
--- a/gcc/testsuite/gcc.target/i386/cet-switch-1.c
+++ b/gcc/testsuite/gcc.target/i386/cet-switch-1.c
@@ -1,6 +1,6 @@
 /* Verify that CET works.  */
 /* { dg-do compile } */
-/* { dg-options "-O -fcf-protection" } */
+/* { dg-options "-O -fcf-protection -mno-cet-switch" } */
 /* { dg-final { scan-assembler-times "endbr32" 1 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 1 { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-times "notrack jmp\[ \t]+\[*]" 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/cet-switch-2.c 
b/gcc/testsuite/gcc.target/i386/cet-switch-2.c
index 69ddc6fd5b7..11578d1a30c 100644
--- a/gcc/testsuite/gcc.target/i386/cet-switch-2.c
+++ b/gcc/testsuite/gcc.target/i386/cet-switch-2.c
@@ -1,6 +1,6 @@
 /* Verify 

Re: [PATCH] i386: Add "Ws" constraint for symbolic address/label reference [PR105576]

[Fangrui Song]

On Thu, Jan 11, 2024 at 10:24 AM Fangrui Song  wrote:
>
> Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> mangled name).  Similar constraints are available in other targets (e.g.
> "S" for aarch64/riscv, "Cs" for m68k).
>
> There isn't a good way for x86 yet, e.g. "i" doesn't work for
> PIC/-mcmodel=large.  This patch adds "Ws".  Here are possible use cases:
>
> ```
> namespace ns { extern int var; }
> asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "Ws"());
> asm (".reloc ., BFD_RELOC_NONE, %0" :: "Ws"());
> ```
>
> gcc/ChangeLog:
>
> PR target/105576
> * config/i386/constraints.md: Define constraint "Ws".
> * doc/md.texi: Document it.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/asm-raw-symbol.c: New testcase.
>
> ---
>
> This obsoletes 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642580.html
> I initially tried 'z', but Uros requested that a W prefix is used.
> ---
>  gcc/config/i386/constraints.md |  4 
>  gcc/doc/md.texi|  4 
>  gcc/testsuite/gcc.target/i386/asm-raw-symbol.c | 13 +
>  3 files changed, 21 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c

Thanks to Uros for "W" prefix suggestion.
If "Ws" sounds a good choice, I'll go ahead with my Clang patch adding
"Ws", even if the GCC patch is still pending:)

https://github.com/protocolbuffers/protobuf/blob/1fe463ce71b6acc60b3aef65d51185e3704cac8b/src/google/protobuf/stubs/common.h

// Strongly references the given variable such that the linker will be forced
// to pull in this variable's translation unit.
template 
void StrongReference(const T& var) {
  auto volatile unused = 
  (void)  // Use address to avoid an extra load of "unused".
}

is an example that "Ws" constraint (which expands to no instruction)
works better than the volatile address-taken operation.
I am not so familiar with the mechanism, but StrongReference is used
to establish a dependency edge so that the ld --gc-sections will not
garbage `var`.



-- 
宋方睿

[PATCH] i386: Add "Ws" constraint for symbolic address/label reference [PR105576]

[Fangrui Song]

Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name).  Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).

There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large.  This patch adds "Ws".  Here are possible use cases:

```
namespace ns { extern int var; }
asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "Ws"());
asm (".reloc ., BFD_RELOC_NONE, %0" :: "Ws"());
```

gcc/ChangeLog:

PR target/105576
* config/i386/constraints.md: Define constraint "Ws".
* doc/md.texi: Document it.

gcc/testsuite/ChangeLog:

* gcc.target/i386/asm-raw-symbol.c: New testcase.

---

This obsoletes 
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642580.html
I initially tried 'z', but Uros requested that a W prefix is used.
---
 gcc/config/i386/constraints.md |  4 
 gcc/doc/md.texi|  4 
 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c | 13 +
 3 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 0c6e662df25..280e4c8e36c 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -348,6 +348,10 @@ (define_constraint "Wf"
to double word size."
   (match_operand 0 "x86_64_dwzext_immediate_operand"))
 
+(define_constraint "Ws"
+  "A symbolic reference or label reference."
+  (match_code "const,symbol_ref,label_ref"))
+
 (define_constraint "Z"
   "32-bit unsigned integer constant, or a symbolic reference known
to fit that range (for immediate operands in zero-extending x86-64
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 47a87d6ceec..b0c61925120 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4275,6 +4275,10 @@ require non-@code{VOIDmode} immediate operands).
 128-bit integer constant where both the high and low 64-bit word
 satisfy the @code{e} constraint.
 
+@item Ws
+A symbolic reference or label reference.
+You can use the @code{%p} modifier to print the raw symbol.
+
 @item Z
 32-bit unsigned integer constant, or a symbolic reference known
 to fit that range (for immediate operands in zero-extending x86-64
diff --git a/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c 
b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
new file mode 100644
index 000..b7854567dd9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+extern int var;
+
+void
+func (void)
+{
+  __asm__ ("@ %p0" : : "Ws" (func));
+  __asm__ ("@ %p0" : : "Ws" ( + 1));
+}
+
+/* { dg-final { scan-assembler "@ func" } } */
+/* { dg-final { scan-assembler "@ var\\+4" } } */
-- 
2.43.0.275.g3460e3d667-goog

Re: [PATCH] i386: Add "z" constraint for symbolic address/label reference [PR105576]

[Fangrui Song]

On 2024-01-11, Uros Bizjak wrote:

On Thu, Jan 11, 2024 at 4:44 AM Fangrui Song  wrote:


Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name).  Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).

There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large.  This patch adds "z".


Please use W-prefixed multi-letter constraint name.

Uros.


Sounds good.  How about "Ws"?

(I've asked overse...@gcc.gnu.org whether I can get gcc access (I
already have binutils-gdb/glibc access), so that I can land approved
patches myself in the future) 



From ad7bf3dce026bf226e22ab709c9326c611a4b745 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Wed, 10 Jan 2024 18:49:45 -0800
Subject: [PATCH] i386: Add "Ws" constraint for symbolic address/label
 reference [PR105576]

Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name).  Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).

There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large.  This patch adds "Ws".  Here are possible use cases:

```
namespace ns { extern int var; }
asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "S"());
asm (".reloc ., BFD_RELOC_NONE, %0" :: "S"());
```

gcc/ChangeLog:

PR target/105576
* config/i386/constraints.md: Define constraint "Ws".
* doc/md.texi: Document it.

gcc/testsuite/ChangeLog:

* gcc.target/i386/asm-raw-symbol.c: New testcase.
---
 gcc/config/i386/constraints.md |  4 
 gcc/doc/md.texi|  4 
 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c | 13 +
 3 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 0c6e662df25..280e4c8e36c 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -348,6 +348,10 @@ (define_constraint "Wf"
to double word size."
   (match_operand 0 "x86_64_dwzext_immediate_operand"))
 
+(define_constraint "Ws"

+  "A symbolic reference or label reference."
+  (match_code "const,symbol_ref,label_ref"))
+
 (define_constraint "Z"
   "32-bit unsigned integer constant, or a symbolic reference known
to fit that range (for immediate operands in zero-extending x86-64
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 47a87d6ceec..b0c61925120 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4275,6 +4275,10 @@ require non-@code{VOIDmode} immediate operands).
 128-bit integer constant where both the high and low 64-bit word
 satisfy the @code{e} constraint.
 
+@item Ws

+A symbolic reference or label reference.
+You can use the @code{%p} modifier to print the raw symbol.
+
 @item Z
 32-bit unsigned integer constant, or a symbolic reference known
 to fit that range (for immediate operands in zero-extending x86-64
diff --git a/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c 
b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
new file mode 100644
index 000..b7854567dd9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+extern int var;
+
+void
+func (void)
+{
+  __asm__ ("@ %p0" : : "Ws" (func));
+  __asm__ ("@ %p0" : : "Ws" ( + 1));
+}
+
+/* { dg-final { scan-assembler "@ func" } } */
+/* { dg-final { scan-assembler "@ var\\+4" } } */
--
2.43.0.275.g3460e3d667-goog

[PATCH] i386: Add "z" constraint for symbolic address/label reference [PR105576]

[Fangrui Song]

Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name).  Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).

There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large.  This patch adds "z".

gcc/ChangeLog:

PR target/105576
* config/i386/constraints.md: Define constraint 'z'.
* doc/md.texi: Document it.

gcc/testsuite/ChangeLog:

* gcc.target/i386/asm-raw-symbol.c: New testcase.
---
 gcc/config/i386/constraints.md |  5 -
 gcc/doc/md.texi|  4 
 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c | 13 +
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 0c6e662df25..64330dfdf01 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -19,7 +19,6 @@
 
 ;;; Unused letters:
 ;;;   H
-;;; z
 
 ;; Integer register constraints.
 ;; It is not necessary to define 'r' here.
@@ -438,3 +437,7 @@ (define_constraint  "je"
   "@internal constant that do not allow any unspec global offsets"
   (and (match_operand 0 "x86_64_immediate_operand")
(match_test "!x86_poff_operand_p (op)")))
+
+(define_constraint "z"
+  "A symbolic reference or label reference."
+  (match_code "const,symbol_ref,label_ref"))
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 47a87d6ceec..bbfec024311 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4286,6 +4286,10 @@ VSIB address operand.
 @item Ts
 Address operand without segment register.
 
+@item z
+A symbolic reference or label reference.
+You can use the @code{%p} modifier to print the raw symbol.
+
 @end table
 
 @item Xstormy16---@file{config/stormy16/stormy16.h}
diff --git a/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c 
b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
new file mode 100644
index 000..ce88f3baee6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+extern int var;
+
+void
+func (void)
+{
+  __asm__ ("@ %p0" : : "z" (func));
+  __asm__ ("@ %p0" : : "z" ( + 1));
+}
+
+/* { dg-final { scan-assembler "@ func" } } */
+/* { dg-final { scan-assembler "@ var\\+4" } } */
-- 
2.43.0.275.g3460e3d667-goog

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Fangrui Song]

On Tue, Jan 9, 2024 at 4:59 PM Kito Cheng  wrote:
>
> Oops, I should leave more context here:
>
> Actually we discussed that years ago, and most people agree with that, but I 
> guess we are just missing that, and also the ISA string isn't so terribly 
> long yet at that moment, however...the number of extensions are growth so 
> fast in last year, so I think it's time to moving this forward.
>
> Also we (SiFive) will send patches for clang/LLVM to relax that as well :)
>
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14
>
> On Wed, Jan 10, 2024 at 2:31 AM Jeff Law  wrote:
>>
>>
>>
>> On 1/8/24 06:47, Kito Cheng wrote:
>> >
>> > Do you know how to build a ISA string with following extension?
>> > - g
>> > - c
>> > - zba
>> > - zbs
>> > - svnapot
>> > - zve64d
>> > - zvl128b
>> >
>> > Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I 
>> > believe it's impossible for most people, even I work for RISC-V so many 
>> > years, I remember most of the rule of the the canonical order, it's still 
>> > hard to order that right in short time...
>> >
>> > So I think it's time to relax that for the -march string inputs, since we 
>> > have so many extension today, but we still keep the canonicalization 
>> > within the compiler, because we need that to handle multi-lib and also 
>> > it's easier to compare different ISA string.
>> >
>> > This patch break into serveral part:
>> > 1) Small refactor patch
>> > 2) Change the way of parsing ISA string.
>> > 3) Remove unused functions
>> > 4) Update test cases
>> > 5) Update document
>> Just because something is hard doesn't necessarily mean we should avoid it.
>>
>> A great example would be strict aliasing.  I'd bet that 90% of C/C++
>> developers would get something wrong in this space.  Similarly for
>> oddities of FP arithmetic.
>>
>> My biggest worry is consistency across various tools.  It's rather lame
>> if GCC were on an island by itself either in being too strict or too loose.
>>
>> So where are the other key tools in this regard?  Are we an outlier
>> right now or will this patch make us an outlier?
>>
>> jeff

If we had fewer extensions, ensuring a canonical order is better as a
code search of a fixed string will retrieve the relevant results, and
I'd wish that we did not lose the strictness.
Now that there are a hundred extensions, I agree that enforcing a
strict order has lost its goodness...


-- 
宋方睿

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

[Fangrui Song]

On Mon, Nov 20, 2023 at 6:20 AM Tatsuyuki Ishi  wrote:
>
> This implements TLS Descriptors (TLSDESC) as specified in [1].
>
> The 4-instruction sequence is implemented as a single RTX insn for
> simplicity, but this can be revisited later if instruction scheduling or
> more flexible RA is desired.
>
> The default remains to be the traditional TLS model, but can be configured
> with --with_tls={trad,desc}. The choice can be revisited once toolchain
> and libc support ships.
>
> [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
>
> gcc/Changelog:
> * config/riscv/riscv.opt: Add -mtls-dialect to configure TLS flavor.
> * config.gcc: Add --with_tls configuration option to change the
> default TLS flavor.
> * config/riscv/riscv.h: Add TARGET_TLSDESC determined from
> -mtls-dialect and with_tls defaults.
> * config/riscv/riscv-opts.h: Define enum riscv_tls_type for the
> two TLS flavors.
> * config/riscv/riscv-protos.h: Define SYMBOL_TLSDESC symbol type.
> * config/riscv/riscv.md: Add instruction sequence for TLSDESC.
> * config/riscv/riscv.cc (riscv_symbol_insns): Add instruction
> sequence length data for TLSDESC.
> (riscv_legitimize_tls_address): Add lowering of TLSDESC.
> * doc/install.texi: Document --with-tls for RISC-V.
> * doc/invoke.texi: Document --mtls-dialect for RISC-V.

Nit: One dash for --mtls-dialect.

> ---
> No regression in gcc tests for rv64gc, tested alongside the binutils and
> glibc implementation. Tested with --with_tls=desc.
>
> v2: Add with_tls configuration option, and a few readability improvements.
> Added Changelog.
> v3: Add documentation per Kito's suggestion.
> Fix minor issues pointed out by Kito and Jeff.
> Thanks Kito Cheng and Jeff Law for review.
>
> I've considered gating this behind a GAS feature test, but it seems
> nontrivial especially for restricting the variants available at runtime.
> Since TLS descriptors is not selected by default, I've decided to leave it
> ungated.
>
> In other news, I have made some progress on binutils side, and I'll try to
> update the GAS / ld patch set with relaxation included, by the end of this
> month.

Thanks for the update.  I understand the complexity adding a runtime
test when the feature also requires binutils and rtld support.
I hope that we add a test checking assembly under
gcc/testsuite/gcc.target/riscv/tls , otherwise as a non-default test,
when this breaks, it may be difficult to figure it out.
(glibc/elf/tst-* will need a runtime test, but GCC needs to have its own.)

>  gcc/config.gcc  | 15 ++-
>  gcc/config/riscv/riscv-opts.h   |  6 ++
>  gcc/config/riscv/riscv-protos.h |  5 +++--
>  gcc/config/riscv/riscv.cc   | 24 
>  gcc/config/riscv/riscv.h|  9 +++--
>  gcc/config/riscv/riscv.md   | 21 -
>  gcc/config/riscv/riscv.opt  | 14 ++
>  gcc/doc/install.texi|  3 +++
>  gcc/doc/invoke.texi | 13 -
>  9 files changed, 99 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 415e0e1ebc5..2c1a7179b02 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -2434,6 +2434,7 @@ riscv*-*-linux*)
> # Force .init_array support.  The configure script cannot always
> # automatically detect that GAS supports it, yet we require it.
> gcc_cv_initfini_array=yes
> +   with_tls=${with_tls:-trad}
> ;;
>  riscv*-*-elf* | riscv*-*-rtems*)
> tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
> @@ -2476,6 +2477,7 @@ riscv*-*-freebsd*)
> # Force .init_array support.  The configure script cannot always
> # automatically detect that GAS supports it, yet we require it.
> gcc_cv_initfini_array=yes
> +   with_tls=${with_tls:-trad}
> ;;
>
>  loongarch*-*-linux*)
> @@ -4566,7 +4568,7 @@ case "${target}" in
> ;;
>
> riscv*-*-*)
> -   supported_defaults="abi arch tune riscv_attribute isa_spec"
> +   supported_defaults="abi arch tune riscv_attribute isa_spec 
> tls"
>
> case "${target}" in
> riscv-* | riscv32*) xlen=32 ;;
> @@ -4694,6 +4696,17 @@ case "${target}" in
> ;;
> esac
> fi
> +   # Handle --with-tls.
> +   case "$with_tls" in
> +   "" \
> +   | trad | desc)
> +   # OK
> +   ;;
> +   *)
> +   echo "Unknown TLS method used in 
> --with-tls=$with_tls" 1>&2
> +   exit 1
> +   ;;
> +   esac
>
> # Handle --with-multilib-list.
> if test "x${with_multilib_list}" != xdefault; then
> diff --git 

Re: [PATCH v2] RISC-V: Implement TLS Descriptors.

[Fangrui Song]

On Wed, Nov 15, 2023 at 9:23 PM Jeff Law  wrote:
>
>
>
> On 11/15/23 18:51, Tatsuyuki Ishi wrote:
> >> On Nov 16, 2023, at 10:07, Jeff Law  wrote:
>
> >
> > Based on what I have read in the AArch64 backend, there are two ways to
> > do this: introduce a custom calling convention, or put in a RTX insn
> > that covers the whole sequence. Ideally we should do the first, but then
> > there’s the label issue and it’s quite a bit more complicated. So I’m
> > sticking with this for now.
> As I said, I think we're OK here.  We can always revamp as we get
> experience with the implementation -- I don't think any of the stuff
> we're talking about is an ABI change, they're just implementation details.
>
> >
> > Sorry for all the delay on this. My progress has been (and still)
> > blocked on supporting relaxation of TLSDESC in binutils (turns out you
> > can’t run static binaries without relaxing it first). But that doesn’t
> > seem exactly easy to do either, because relaxation that involves GOT
> > elimination isn’t something we have in the RISC-V backend.
> Note that binutils is due for another release in the next month or two.
> It'd certainly be helpful to have any issues there resolved in time for
> that release.
>
> >
> > I’ll try to send a new version of this patch and get this unblocked on
> > GCC side first.
> Sounds good.  We can always guard its use behind a feature test for GAS
> support.
>
> Jeff

Agreed.


Tatsuyuki, could you also add some tests? For example

// end of https://maskray.me/blog/2021-02-14-all-about-thread-local-storage
__thread int tls0;
extern __thread int tls1;
int foo() { return ++tls0 + ++tls1; }
static __thread int tls2, tls3;
int bar() { return ++tls2 + ++tls3; }

I have used this to check rtld and linker behavior. I think we need
some `scan-assembler`.
To make it a runnable test, some assembler feature check may be
needed. Perhaps Jeff can make some suggestion or contribute code!




-- 
宋方睿

Re: [PATCH v2] RISC-V: Implement TLS Descriptors.

[Fangrui Song]

On Mon, Oct 2, 2023 at 7:10 AM Kito Cheng  wrote:
>
> Just one nit and one more comment for doc:
>
> Could you add some doc something like that? mostly I grab from other
> target, so you can just included in the patch.
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 31f2234640f..39396668da2 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -1174,6 +1174,9 @@ Specify the default TLS dialect, for systems
> were there is a choice.
> For ARM targets, possible values for @var{dialect} are @code{gnu} or
> @code{gnu2}, which select between the original GNU dialect and the GNU TLS
> descriptor-based dialect.
> +For RISC-V targets, possible values for @var{dialect} are @code{trad} or
> +@code{desc}, which select between the traditional GNU dialect and the GNU TLS
> +descriptor-based dialect.
>
> @item --enable-multiarch
> Specify whether to enable or disable multiarch support.  The default is
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 4085fc90907..459e266d426 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1239,7 +1239,8 @@ See RS/6000 and PowerPC Options.
> -minline-atomics  -mno-inline-atomics
> -minline-strlen  -mno-inline-strlen
> -minline-strcmp  -mno-inline-strcmp
> --minline-strncmp  -mno-inline-strncmp}
> +-minline-strncmp  -mno-inline-strncmp
> +-mtls-dialect=desc  -mtls-dialect=trad}
>
> @emph{RL78 Options}
> @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs
> @@ -29538,6 +29539,17 @@ which register to use as base register for
> reading the canary,
> and from what offset from that base register. There is no default
> register or offset as this is entirely for use within the Linux
> kernel.
> +
> +@opindex mtls-dialect=desc
> +@item -mtls-dialect=desc
> +Use TLS descriptors as the thread-local storage mechanism for dynamic 
> accesses
> +of TLS variables.  This is the default.
> +
> +@opindex mtls-dialect=trad
> +@item -mtls-dialect=traditional

-mtls-dialect=trad.
aarch64-linux-gnu-gcc doesn't support -mtls-dialect=traditional

> +Use traditional TLS as the thread-local storage mechanism for dynamic 
> accesses
> +of TLS variables.
> +
> @end table

This is the default :)

I am happy that we change the default like AArch64, but probably not
now when linker support is not widely available yet.

I cannot comment on the code side as I am not familiar with GCC internals.

> @node RL78 Options
>
>
>
>
> > +(define_insn "@tlsdesc"
> > +  [(set (reg:P A0_REGNUM)
> > +   (unspec:P
> > +   [(match_operand:P 0 "symbolic_operand" "")
> > +(match_operand:P 1 "const_int_operand")]
> > +   UNSPEC_TLSDESC))
> > +   (clobber (reg:SI T0_REGNUM))]
>
> P rather than SI here.
>
> > +  "TARGET_TLSDESC"
> > +  {
> > +return ".LT%1: auipc\ta0, %%tlsdesc_hi(%0)\;"
> > +   "\tt0,%%tlsdesc_load_lo(.LT%1)(a0)\;"
> > +   "addi\ta0,a0,%%tlsdesc_add_lo(.LT%1)\;"
> > +   "jalr\tt0,t0,%%tlsdesc_call(.LT%1)";
> > +  }
> > +  [(set_attr "type" "multi")
> > +   (set_attr "length" "16")
> > +   (set_attr "mode" "")])
> > +
> >  (define_insn "auipc"
> >[(set (match_operand:P   0 "register_operand" "=r")
> > (unspec:P

It seems that x86-64 supports non-adjacent code sequence. Writing the
pattern this way does not allow interleaving, but I assume
interleaving doesn't enable much.
https://reviews.llvm.org/D114416


-- 
宋方睿

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

[Fangrui Song]

On Mon, Oct 16, 2023 at 12:10 PM Uros Bizjak  wrote:
>
> On Mon, Oct 16, 2023 at 8:24 PM Fangrui Song  wrote:
> >
> > On 2023-10-16, Uros Bizjak wrote:
> > >On Tue, Aug 1, 2023 at 9: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
> > >>
> > >> 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)
> > >
> > >Please split multi-line expression before the operator, not after it,
> > >as instructed in GNU Coding Standards [1] ...
> > >
> > >[1] https://www.gnu.org/prep/standards/html_node/Formatting.html
> > >
> > >>  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)
> > >
> > >... also here ...
> > >
> > >>  {
> > >>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)
>

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

[Fangrui Song]

On 2023-10-16, Uros Bizjak wrote:

On Tue, Aug 1, 2023 at 9: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

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)


Please split multi-line expression before the operator, not after it,
as instructed in GNU Coding Standards [1] ...

[1] https://www.gnu.org/prep/standards/html_node/Formatting.html


 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)


... also here ...


 {
   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)


... and here.

OK with these formatting changes.

Thanks,
Uros.


Thank you for the review!
Posted PATCH v5 
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633153.html
with the formatting.

I don't have write access to the gcc repository:)

(Hmmm... in emacs, C-c . gnu RET C-M-\  doesn't fix the && || formatting 
errors.)


+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/

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

[Fangrui Song]

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 .

Changes from v4 
(https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633145.html)
* "When you split an expression into multiple lines, split it before an 
operator, not after one."
---
 gcc/config/i386/i386.cc|  9 ++---
 gcc/config/i386/i386.opt   |  2 +-
 gcc/doc/invoke.texi|  6 +++---
 gcc/testsuite/gcc.target/i386/large-data.c | 13 +
 4 files changed, 23 insertions(+), 7 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 8251b67e2d6..641e7680335 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -663,7 +663,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)
@@ -874,7 +875,8 @@ 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)
+  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));
@@ -895,7 +897,8 @@ 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)
+  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
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index b8382c48099..0c3b8f4b621 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 eb714d18511..50745a3a195 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -33390,9 +33390,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..bdd4acd30b8
--- /dev/null
+++ b/gcc/tes

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

[Fangrui Song]

On Wed, Sep 13, 2023 at 11:19 AM Fangrui Song  wrote:
>
> 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.)
>
>
> --
> 宋方睿

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

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


-- 
宋方睿

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] 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: RFC: Top level configure: Require a minimum version 6.8 texinfo

[Fangrui Song]

On Tue, Aug 29, 2023 at 8:50 AM YunQiang Su via Binutils
 wrote:
>
> > I think that is too new.
> > We still allow building gcc e.g. with GCC 4.8 from ~ 10 years ago and
> > I think various boxes where people regularly build gcc will have similarly
> > old other tools.
> > So, bumping requirement from ~ 20 years old tools to ~ 10 years old tools
> > might be ok, but requiring ones at most 2 years old will be a nightmare,
>
> I agree.
> Lots of toolchains distributed by CPU vendors are supposed to support
> CentOS 6, or at least 7.

I wonder whether documents can be disabled. When people build old
packages, they may not care about the documentation.

I tried to build gcc 4.4.7 yesterday with gcc 12 and failed due to a
tex syntax error.
I could not figure out why, and `configure MAKEINFO=true` did not
help, so I switched to `truncate -s0 gcc/doc/*`.

I just tried binutils and did not find a way to disable doc, either.
To me, if doc can be disabled, any makeinfo version requirement is
fine.
(To build GCC 5, I have noticed that --disable-libsanitizer is needed.)

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:)

[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/testsui

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" :)

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 ();
> >> -  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 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 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.)


-- 
宋方睿

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

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").

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: [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.

[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/gc

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/gc

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] 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" } } */
+/*

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



-- 
宋方睿

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] 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] 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 sev

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 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: [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
> > >>>lt_stat

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

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) 

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: [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: [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 

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] 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 so long so I
ended up sending this patch myself, but I have no bandwidth to change this
patch to a form providing better compatibility

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] 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 -a &qu

[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 "$l

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: [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] 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 }
> &

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] 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}: res

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] 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) 

[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* | 

[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] include/longlong.h: Remove incorrect lvalue to rvalue conversion from asm output constraints

[Fangrui Song]

An output constraint takes a lvalue. While GCC happily strips the
incorrect lvalue to rvalue conversion, Clang rejects the code by default:

error: invalid use of a cast in a inline asm context requiring an lvalue: 
remove the cast or build with -fheinous-gnu-extensions

The file appears to share the same origin with gmplib longlong.h but
they differ much now (gmplib version is much longer).

I don't have write access to the git repo.
---
 include/longlong.h | 186 ++---
 1 file changed, 93 insertions(+), 93 deletions(-)

diff --git a/include/longlong.h b/include/longlong.h
index c3e92e54ecc..0a21a441d2d 100644
--- a/include/longlong.h
+++ b/include/longlong.h
@@ -194,8 +194,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype, 
UDItype);
 #if defined (__arc__) && W_TYPE_SIZE == 32
 #define add_ss(sh, sl, ah, al, bh, bl) \
   __asm__ ("add.f  %1, %4, %5\n\tadc   %0, %2, %3" \
-  : "=r" ((USItype) (sh)), \
-"=" ((USItype) (sl)) \
+  : "=r" (sh), \
+"=" (sl) \
   : "%r" ((USItype) (ah)), \
 "rICal" ((USItype) (bh)),  \
 "%r" ((USItype) (al)), \
@@ -203,8 +203,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype, 
UDItype);
   : "cc")
 #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
   __asm__ ("sub.f  %1, %4, %5\n\tsbc   %0, %2, %3" \
-  : "=r" ((USItype) (sh)), \
-"=" ((USItype) (sl)) \
+  : "=r" (sh), \
+"=" (sl) \
   : "r" ((USItype) (ah)),  \
 "rICal" ((USItype) (bh)),  \
 "r" ((USItype) (al)),  \
@@ -230,16 +230,16 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype, 
UDItype);
  && W_TYPE_SIZE == 32
 #define add_ss(sh, sl, ah, al, bh, bl) \
   __asm__ ("adds   %1, %4, %5\n\tadc   %0, %2, %3" \
-  : "=r" ((USItype) (sh)), \
-"=" ((USItype) (sl)) \
+  : "=r" (sh), \
+"=" (sl) \
   : "%r" ((USItype) (ah)), \
 "rI" ((USItype) (bh)), \
 "%r" ((USItype) (al)), \
 "rI" ((USItype) (bl)) __CLOBBER_CC)
 #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
   __asm__ ("subs   %1, %4, %5\n\tsbc   %0, %2, %3" \
-  : "=r" ((USItype) (sh)), \
-"=" ((USItype) (sl)) \
+  : "=r" (sh), \
+"=" (sl) \
   : "r" ((USItype) (ah)),  \
 "rI" ((USItype) (bh)), \
 "r" ((USItype) (al)),  \
@@ -262,8 +262,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype, 
UDItype);
   "addcs   %0, %0, #65536\n"   \
   "adds%1, %1, %3, lsl #16\n"  \
   "adc %0, %0, %3, lsr #16"\
-  : "=" ((USItype) (xh)),\
-"=r" ((USItype) (xl)), \
+  : "=" (xh),\
+"=r" (xl), \
 "=" (__t0), "=" (__t1), "=r" (__t2)\
   : "r" ((USItype) (a)),   \
 "r" ((USItype) (b)) __CLOBBER_CC );\
@@ -348,16 +348,16 @@ extern UDItype __umulsidi3 (USItype, USItype);
 #if defined (__hppa) && W_TYPE_SIZE == 32
 #define add_ss(sh, sl, ah, al, bh, bl) \
   __asm__ ("add %4,%5,%1\n\taddc %2,%3,%0" \
-  : "=r" ((USItype) (sh)), \
-"=" ((USItype) (sl)) \
+  : "=r" (sh), \
+"=" (sl) \
  

Re: [PATCH v2] docs: Add 'S' to Machine Constraints for RISC-V

[Fangrui Song]

On 2021-07-12, Kito Cheng wrote:

It was undocument before, but it might used in linux kernel for resolve
code model issue, so LLVM community suggest we should document that,
so that make it become supported/documented/non-internal machine constraints.

gcc/ChangeLog:

PR target/101275
* config/riscv/constraints.md ("S"): Update description and remove
@internal.
* doc/md.texi (Machine Constraints): Document the 'S' constraints
for RISC-V.
---
gcc/config/riscv/constraints.md | 3 +--
gcc/doc/md.texi | 3 +++
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index 8c15c6c0486..c87d5b796a5 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -67,8 +67,7 @@ (define_memory_constraint "A"
   (match_test "GET_CODE(XEXP(op,0)) == REG")))

(define_constraint "S"
-  "@internal
-   A constant call address."
+  "A constraint that matches an absolute symbolic address."
  (match_operand 0 "absolute_symbolic_operand"))

(define_constraint "U"
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 00caf3844cc..2d120da96cf 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -3536,6 +3536,9 @@ A 5-bit unsigned immediate for CSR access instructions.
@item A
An address that is held in a general-purpose register.

+@item S
+A constraint that matches an absolute symbolic address.
+
@end table

@item RX---@file{config/rx/constraints.md}
--
2.31.1


LGTM

Re: [PATCH] docs: Add 'S' to Machine Constraints for RISC-V

[Fangrui Song]

On 2021-07-02, Kito Cheng wrote:

It was undocument before, but already used in linux kernel, so LLVM
community suggest we should document that, so that make it become
supported/documented/non-internal machine constraints.

gcc/ChangeLog:

PR target/101275
* doc/md.text (Machine Constraints): Document the 'S' constraints
for RISC-V.
---
gcc/doc/md.texi | 3 +++
1 file changed, 3 insertions(+)

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 00caf3844cc..b776623e8a5 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -3536,6 +3536,9 @@ A 5-bit unsigned immediate for CSR access instructions.
@item A
An address that is held in a general-purpose register.

+@item S
+A constant call address.
+
@end table

@item RX---@file{config/rx/constraints.md}
--
2.31.1



Ping on this:)

'S' can be used on either a variable or a function. Does "A constant call 
address." need change?

Re: [PATCH] docs: Add 'S' to Machine Constraints for RISC-V

[Fangrui Song]

On 2021-07-02, Kito Cheng wrote:

It was undocument before, but already used in linux kernel, so LLVM
community suggest we should document that, so that make it become
supported/documented/non-internal machine constraints.

gcc/ChangeLog:

PR target/101275
* doc/md.text (Machine Constraints): Document the 'S' constraints
for RISC-V.
---
gcc/doc/md.texi | 3 +++
1 file changed, 3 insertions(+)

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 00caf3844cc..b776623e8a5 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -3536,6 +3536,9 @@ A 5-bit unsigned immediate for CSR access instructions.
@item A
An address that is held in a general-purpose register.

+@item S
+A constant call address.
+
@end table

@item RX---@file{config/rx/constraints.md}
--
2.31.1



Thanks for the patch!

To clarify, 'S' is used by the aarch64 port of the Linux kernel.
(https://github.com/ClangBuiltLinux/linux/issues/13)

It was proposed as one way to make  __vdso_rt_sigreturn in
arch/riscv/kernel/signal.c less hacky but we have agreed that riscv
should just use the existing mechanism (e.g.
arch/arm64/kernel/vdso/gen_vdso_offsets.sh) as used by a few other
ports.

That said, 'S' is still useful as it enables flexible modifiers (e.g.
`%got_pcrel_hi, %pcrel_hi`) in inline asm.

Re: [PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[Fangrui Song]

On 2021-06-22, H.J. Lu wrote:

On Mon, Jun 21, 2021 at 10:46 PM Fangrui Song  wrote:


On 2021-06-21, H.J. Lu wrote:
>On Mon, Jun 21, 2021 at 9:16 PM Alan Modra  wrote:
>>
>> On Mon, Jun 21, 2021 at 07:12:02PM -0700, H.J. Lu wrote:
>> > On Mon, Jun 21, 2021 at 5:06 PM Alan Modra  wrote:
>> > >
>> > > On Mon, Jun 21, 2021 at 03:34:38PM -0700, Fangrui Song wrote:
>> > > > clang -fno-pic -fno-direct-access-extern-data  works with 
clang>=12.0.0 today.
>> > >
>> > > -fno-direct-access-extern-data or variations on that also seem good to
>> > > me.  -fpic-extern would also work.  I liked -fprotected-abi because
>> > > it shows the intent of correcting abi issues related to protected
>> > > visibility.  (Yes, it affects code for all undefined symbols because
>> > > the compiler clearly isn't seeing the entire program if there are
>> > > undefined symbols.)
>> >
>> > I need an option which can be turned on and off.   How about
>> > -fextern-access=direct and -fextern-access=indirect?  It will cover
>> > both data and function?

-fno-direct-access-external-data and -fdirect-access-external-data can turn 
on/off the bit.

clang -fno-pic -fno-direct-access-external-data  works for x86-64 and aarch64.

We can add a -fno-direct-access-external


Since both clang and GCC will add a new option for both data and function
symbols, can we have an agreement on the new option name?  I am listing
options here:

1. -fdirect-access-external/-fno-direct-access-external
2. -fdirect-extern-access/-fno-direct-exern-access
3. -fdirect-external-access/-fno-direct-exernal-access
4. -fextern-access=direct/-fextern-access=indirect
5. -fexternal-access=direct/-fexternal-access=indirect

My order of preferences are 4, 5, 2, 3, 1.


Preferring "extern" to "external" looks fine to me. (`extern` is the C/C++ 
construct anyway and this option describes what to do with default visibility non-definition 
`extern int xxx`/`extern void foo()`).

-fextern-access=direct/-fextern-access=indirect and 
-fdirect-extern-access/-fno-direct-exern-access

look good to me.

I am happy to add aliases to clang if consensus is moving toward  
-fextern-access=indirect or -fno-direct-extern-access.


>> Yes, FWIW that option name for gcc also looks good to me.
>
>I will change the gcc option to
>
>-fextern-access=direct
>-fextern-access=indirect
>
>and change GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION
>to GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS

Note that this will be a glibc + GNU ld specific thing.

gold and ld.lld error for copy relocations on protected data symbols by default.


At run-time, there will be a mixture of components built with different tools
over time.  A marker will help glibc to avoid potential run-time failures due
to binary incompatibility.


glibc can perform the check without a GNU PROPERTY.


For a st_value!=0 && st_shndx==0 symbol lookup during relocation
processing, if the definition is found protected in a shared object,
ld.so can report an error and make a suggestion like
"consider recompiling the executable with -fno-direct-extern-access or
-fpie/-fpic"


I echo Michael's question in another thread
https://sourceware.org/pipermail/binutils/2021-June/117137.html

"IOW: which scenario do you want to not error on when you want to make the error 
conditional?"

For such rare cases, we can use a LD_* environment variable.


>> Now as to the need for a corresponding linker option, I'm of the
>> opinion that it is ideal for the linker to be able to cope without
>> needing special options.  Can you show me a set of object files (or
>> just describe them) where ld cannot deduce from relocations and
>> dynamic symbols what dynbss copies, plt stubs, and dynamic relocations
>> are needed?  I'm fairly sure I manage to do that for powerpc.
>>
>> Note that I'm not against a new option to force the linker to go
>> against what it would do based on input object files (perhaps
>
>I'd like to turn it on in linker without any compiler changes, especially
>when building shared libraries, kind of a subset of -Bsymbolic.
>
>> reporting errors), but don't think we should have a new option without
>> some effort being made to see whether we really need it.
>
>Here is a glibc patch to use both linker options on some testcases:
>
>https://sourceware.org/pipermail/libc-alpha/2021-June/127770.html
>
>> > > The main thing that struck me about -fsingle-global-definition is that
>> > > the option doesn't do what it says.  You can still have multiple
>> > > global definitions of a given symbol, one in the executable and one in
>> > > each of the shared libraries making up the complete program.  Which of
>> > > course is no different to code without -fsingle-global-definition.
>> >
>> >
>> > --
>> > H.J.
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM
>
>
>
>--
>H.J.




--
H.J.

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

[Fangrui Song]

On 2021-06-07, Jakub Jelinek wrote:

On Mon, Jun 07, 2021 at 12:01:55PM -0600, Jeff Law via Gcc-patches wrote:

> This breaks assumptions across the board.  If software packages want
> to use -fno-semantic-interposition that is one thing.  But distros
> should not be changing the default.  This is just like using
> -ffast-math :).
Some distros already force immediate binding at link time for security
purposes on a distro-wide basis which, IIUC, does the same thing, but
without the benefits from a code generation standpoint.


If you are talking about -Wl,-z,now, that is very different, semantic
interposition then still works just fine.
If you are talking about the glibc style by hand "protected" visibility,
bind calls to symbols defined in the same library through internal symbols,
then that is done only for a couple of packages and is stronger than
-fno-semantic-interposition.

Jakub



-fno-semantic-interposition can save a PLT entry (and associated
R_*_JUMP_SLOT dynamic relocation) if a default visibility STB_GLOBAL
function is only called in its defining TU, not by other TUs linked into
the shared object.

This is a subset of the PLT-suppressing optimization if a distribution defaults 
to ld -Bsymbolic-non-weak-functions
(https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#the-last-alliance-of-elf-and-men)



Binding definitions in the same component can make software securer.

https://twitter.com/CarlosODonell/status/1400879768028028935
"Disable PRELOAD/AUDIT, which is what I'm going to pursue e.g.  system-wide glibc 
hardening tunable."
If such a thing is deployed, why cannot a passionate distribution default to 
gcc -fno-semantic-interposition  and ld -Bsymbolic-non-weak-functions
can bring back the lost performance (15+% for my clang; 27% for cpython; ...)



Last, the "assumption" is just GCC's mapping from source code to the ELF binary
format.
https://maskray.me/blog/2021-05-09-fno-semantic-interposition#source-level-implication
We could also argue that C++ odr rule doesn't like us doing semantic 
interposition.
(I know it's vague 
https://stackoverflow.com/questions/5563/odr-violation-when-linking-static-and-dynamic-library
 )

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

[Fangrui Song]

On 2021-06-06, Andrew Pinski wrote:

On Sun, Jun 6, 2021 at 4:13 PM Fangrui Song via Gcc-patches
 wrote:


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



This breaks assumptions across the board.  If software packages want
to use -fno-semantic-interposition that is one thing.  But distros
should not be changing the default.  This is just like using
-ffast-math :).

Thanks,
Andrew Pinski


What assumption?

Vague linkage function definitions already support IPO/inlining.

For a large non-vague linkage function, presumably GCC will not inline
it into the call sites in the same TU, users can keep using LD_PRELOAD
to interpose that single symbol.

Even if the non-vague function is small and inlined, users can use LD_PRELOAD to
interpose both the callee and callers.

You cannot do such interposition for Windows.
macOS two-level namespace requires explicit `ld -flat_interpose` for such 
definition interposition.
Users are free to add noinline or -fsemantic-interposition.



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 "

[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

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

[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 

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.

[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 (, 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 (, 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 (, 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 (, ld_path, X_OK);
+ if (ld_file_name == 0)
+   ld_file_name = find_a_file (, 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 (, 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 (, full_l

[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 (, 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 (, 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 (, 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 (, ld_path, X_OK);
+ if (ld_file_name == 0)
+   ld_file_name = find_a_file (, 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 (, 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 (, full_ld_suffixes[selected_linker], X_OK);
+}
 
 #ifdef REAL_NM_FILE_NAME
   nm_file_name = find_a_file (, 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;
  else if (strcmp (arg, "--version") 

Re: [PATCH] gcov: rename 2 options.

[Fangrui Song]

On 2020-07-04, Fangrui Song wrote:

Good idea! I've done that and made an alias for -i -> -j option.
I'm going to push it to master.

Martin
-- next part --
A non-text attachment was scrubbed...
Name: 0001-gcov-rename-2-options.patch
Type: text/x-patch
Size: 5457 bytes
Desc: not available
URL:
<https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200701/2a0ca9c2/attachment.bin>


Note that -i was --intermediate-format in many releases, dropping -i should be 
fine if
there is no intention bring back --intermediate-format.

(Personally I still find --intermediate-format useful: for template
instantiations, in many cases users only care about aggregated line
execution counts (0 vs 1). They don't want to see 10 instantiations of a
function.)

-j -> --json-format looks good.

I don't think anyone uses --human-readable. The short option can even be
removed.


Fix Richard's email address.
(I am not subscribed so replying to a thread is difficult.)

Re: [PATCH] gcov: rename 2 options.

[Fangrui Song]

> Good idea! I've done that and made an alias for -i -> -j option.
> I'm going to push it to master.
> 
> Martin
> -- next part --
> A non-text attachment was scrubbed...
> Name: 0001-gcov-rename-2-options.patch
> Type: text/x-patch
> Size: 5457 bytes
> Desc: not available
> URL:
> 

Note that -i was --intermediate-format in many releases, dropping -i should be 
fine if
there is no intention bring back --intermediate-format.

(Personally I still find --intermediate-format useful: for template
instantiations, in many cases users only care about aggregated line
execution counts (0 vs 1). They don't want to see 10 instantiations of a
function.)

-j -> --json-format looks good.

I don't think anyone uses --human-readable. The short option can even be
removed.

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 (, full_ld_suffixes[selected_linker], X_OK);
+   ld_file_name
+ = find_a_file (, 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.

[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(, 
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(, 
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(, 
ld_suffixes[selected_linker], X_OK);
gcc/collect2.c:1140:23:find_a_file(, 
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 (, 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 (, 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 (, full_ld_suffixes[selected_linker], X_OK);
+  if (selected_linker == USE_LD_MAX)
+{
+  ld_file_name = find_a_file (, use_ld, X_OK);
+  if (ld_file_name == 0)
+	ld_file_name = find_a_file (, 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 (, 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 (, full_ld_suffixes[selected_linker], X_OK);
+}
 
 #ifdef REAL_NM_FILE_NAME
   nm_file_name = find_a_file (, 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 linker.
+
 fuse-linke

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

[Fangrui Song via Gcc-patches]

mmon.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 linker.
+
fuse-linker-plugin
Common Undocumented Var(flag_use_linker_plugin)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7217e27151d..30a2fc4fa53 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14304,6 +14304,10 @@ Use the @command{gold} linker instead of the default 
linker.
@opindex fuse-ld=lld
Use the LLVM @command{lld} linker instead of the default linker.
+@item -fuse-ld=@var{linker}
+@opindex fuse-ld=linker
+Use the specified executable named @var{linker} instead of the default linker.
+
@cindex Libraries
@item -l@var{library}
@itemx -l @var{library}
diff --git a/gcc/opts.c b/gcc/opts.c
index ec3ca0720f9..522a196ab0f 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2785,6 +2785,7 @@ common_handle_option (struct gcc_options *opts,
case OPT_fuse_ld_bfd:
case OPT_fuse_ld_gold:
case OPT_fuse_ld_lld:
+case OPT_fuse_ld_:
case OPT_fuse_linker_plugin:
  /* No-op. Used by the driver and passed to us because it starts with f.*/
  break;



#ifdef REAL_NM_FILE_NAME
  nm_file_name = find_a_file (, 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)
{
  /* 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 linker.
+fuse-ld=
+Common Driver Joined
+Use the specified executable instead of the default linker.
+
fuse-linker-plugin
Common Undocumented Var(flag_use_linker_plugin)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7217e27151d..30a2fc4fa53 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14304,6 +14304,10 @@ Use the @command{gold} linker instead of the default 
linker.
@opindex fuse-ld=lld
Use the LLVM @command{lld} linker instead of the default linker.
+@item -fuse-ld=@var{linker}
+@opindex fuse-ld=linker
+Use the specified executable named @var{linker} instead of the default linker.
+
@cindex Libraries
@item -l@var{library}
@itemx -l @var{library}
diff --git a/gcc/opts.c b/gcc/opts.c
index ec3ca0720f9..522a196ab0f 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2785,6 +2785,7 @@ common_handle_option (struct gcc_options *opts,
case OPT_fuse_ld_bfd:
case OPT_fuse_ld_gold:
case OPT_fuse_ld_lld:
+case OPT_fuse_ld_:
case OPT_fuse_linker_plugin:
  /* No-op. Used by the driver and passed to us because it starts with f.*/
  break;

>From 4050d91468ba2b358037818f8d5945bdd643e112 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 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  | 30 ++
 gcc/common.opt  |  4 
 gcc/doc/invoke.texi |  4 
 gcc/opts.c  |  1 +
 4 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index f8a5ce45994..707cd2581e9 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,22 @@ main (int argc, char **argv)
   ld_file_name = find_a_file (, collect_ld_suffix, X_OK);
   use_collect_ld = ld_file_name != 0;
 }
-  /* Search the compiler directories f

[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 scanning the
  outcome of a first pass 

[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 -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

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)
- selected_linke

[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

[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 (_linker[len], HOST_EXECUTABLE_SUFFIX))
{
  default_linker[len] = '\0';
- linker_name = concat (default_linker,
-   _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,
-   _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 (, collect_ld_suffix, X_OK);
use_collect_ld = ld_file_na

Re: [PATCH v2 0/3] Introduce a new GCC option, --record-gcc-command-line

[Fangrui Song]

On 2020-03-03, Joseph Myers wrote:

On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote:


Although we discussed after the submission of the first version that
there are several other options performing similar tasks, I believe we
established that there is still a need for this specific functionality.
Therefore, I am skipping in this email the comparison between this
option and the existing options with similarities.


Mentioning -frecord-gcc-switches will be much appreciated.

How is the new .GCC.command.line different?

Does it still have the SHF_MERGE | SHF_STRINGS flag?
If you change the flags, the .GCC.command.line section may not play with
another object file (generated by -frecord-gcc-switches) whose 
.GCC.command.line is
SHF_MERGE | SHF_STRINGS.

When both -frecord-gcc-switches and --record-command-line are specified,
is it an error?


We're now using git-style commit messages with self-contained explanation
/ justification of the change being committed.

This means that one of the commit messages (not just message 0, whose
contents don't go in a commit message) for an individual patch should have
the explanation, which should include the self-contained justification by
reference to comparison with other existing similar options.  People
should be able to find the relevant information in the commit without
needing to search the list archives for reviews of a previous patch
version.