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
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 t
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*-*-uclinuxfdpice
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
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
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
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.
>
>
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
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
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
+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
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月
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\"
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 :
> > >>
> > >>
> > >>
> >
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:
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
andon 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-i
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 .,
er:) 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
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
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
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
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).
Th
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".
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
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.
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
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
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 us
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
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-b
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
> > >
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
> > (.l
On Tue, Sep 5, 2023 at 5:14 AM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> committed, thanks :)
>
> On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches
> wrote:
> >
> >
> >
> > On 8/31/23 03:05, Kito Cheng wrote:
> > > We only emit that on linux target before, that not
On Tue, Aug 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
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* section
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-b
On Wed, Jul 19, 2023 at 4:12 PM Alexandre Oliva via Gcc-patches
wrote:
>
> On Jul 18, 2023, Richard Biener wrote:
>
> > I think the __symver__ attribute does something similar already so
> > maybe use __attribute__((__sym__("foo")))?
>
> Cool, thanks, that will do. Regstrapped on
On Thu, Nov 24, 2022 at 7:26 PM Kewen.Lin via Gcc-patches
wrote:
>
> Hi Richard,
>
> on 2022/11/23 00:08, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> Hi Richard,
> >>
> >> Many thanks for your review comments!
> >>
> > on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> >>
On Tue, Jun 13, 2023 at 2:49 PM Fangrui Song wrote:
> On Mon, Jun 12, 2023 at 11:16 PM Jan Beulich wrote:
>
>> On 13.06.2023 05:28, Fangrui Song wrote:
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.target/i386/large-data.c
>> > @@ -0,0 +1,13 @@
>
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 lp
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-b
On Fri, Jun 2, 2023 at 3:11 AM Alexandre Oliva via Gcc-patches
wrote:
>
> On Jan 19, 2023, Alexandre Oliva wrote:
>
> > Would it make more sense to extend it, even constrained by the
> > limitations mentioned above, or handle memset only? In the latter case,
> > would it still make sense to
On Fri, May 26, 2023 at 12:11 AM Jan Beulich wrote:
>
> On 25.05.2023 18:11, Fangrui Song wrote:
> > On 2023-05-25, Jan Beulich wrote:
> >> On 25.05.2023 17:16, Fangrui Song wrote:
> >>> --- a/gcc/doc/invoke.texi
> >>> +++ b/gcc/doc/invoke.texi
>
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
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-pa
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
>
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
> relo
, 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
On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
wrote:
>
>
>
> > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches
> > wrote:
> >
> > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov
> > wrote:
> >>
> >>
> >> On Wed, 22 Mar 2023, Richard Biener wrote:
> >>
> >>> I think
> The above is incorrectly formatted, the GCC Coding Conventions
say || etc. shouldn't be at the end of lines, but rather at the
start of the next ones.
Ack.
> And, while I can understand the rationale for global cases
> (though am not sure I agree, as currently the user can choose
> by using
Follow aarch64 and riscv ports by using (global ? DW_EH_PE_indirect : 0)
| DW_EH_PE_pcrel for -fno-pic code. This avoids a canonical PLT entry
for a personality reference in .eh_frame and a copy relocation for a
typeinfo reference in .gcc_except_table, when the definition is in
libstdc++.so.6.
On Thu, Nov 17, 2022 at 1:55 PM Andrew Pinski wrote:
>
> On Thu, Nov 17, 2022 at 1:46 PM Fangrui Song wrote:
> >
> > On Thu, Nov 17, 2022 at 1:37 PM Andrew Pinski wrote:
> > >
> > > On Thu, Nov 17, 2022 at 1:21 PM maskray--- via Gcc-patches
> > > w
On Thu, Nov 17, 2022 at 1:37 PM Andrew Pinski wrote:
>
> On Thu, Nov 17, 2022 at 1:21 PM maskray--- via Gcc-patches
> wrote:
> >
> > > +.. option:: -mdirect-extern-access, -mno-direct-extern-access
> > > +
> > > + Use direct accesses for external data symbols. It avoids a GOT
> > >
On Thu, Sep 29, 2022 at 3:28 AM Martin Liška wrote:
> Sending V2 where I included new -gz=zstd option value.
>
> Cheers,
> Martin
At some point binutils will want to remove
--compress-debug-sections=zlib-gnu support as well.
I think the message can drop mentioning of
On Wed, Sep 21, 2022 at 12:37 AM Richard Biener
wrote:
>
> On Tue, Sep 20, 2022 at 2:55 PM Martin Liška wrote:
> >
> > On 7/1/22 09:20, Fangrui Song via Gcc-patches wrote:
> > > On 2022-07-01, Andrew Pinski wrote:
> > >> On Thu, Jun 30, 2022 at 11:58 PM Fan
On Sun, Sep 4, 2022 at 12:00 AM Lulu Cheng wrote:
>
>
> 在 2022/9/4 下午2:35, Xi Ruoyao 写道:
> > On Sun, 2022-09-04 at 11:22 +0800, Lulu Cheng wrote:
> >> 在 2022/9/4 上午10:51, Xi Ruoyao 写道:
> >>
> >>> On Sun, 2022-09-04 at 10:26 +0800, Lulu Cheng wrote:
> >>>
> If the above modifications are not
On Fri, Sep 2, 2022 at 4:31 AM Xi Ruoyao via Gcc-patches
wrote:
>
> On Thu, 2022-09-01 at 18:54 +0800, Xi Ruoyao wrote:
> > We'd like to introduce a new codegen option to align with the old
> > "-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
> > building the Linux kernel
On Tue, Aug 30, 2022 at 9:46 AM Jose E. Marchesi
wrote:
>
>
> > On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> > wrote:
> >>
> >>
> >> LLVM defines both __bpf__ and __BPF_ as target macros.
> >> GCC was defining only __BPF__.
> >>
> >> This patch defines __bpf__ as a target
On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> LLVM defines both __bpf__ and __BPF_ as target macros.
> GCC was defining only __BPF__.
>
> This patch defines __bpf__ as a target macro for BPF.
> Tested in bpf-unknown-none.
>
> gcc/ChangeLog:
>
> *
On Tue, Aug 9, 2022 at 7:00 AM Alexandre Oliva via Gcc-patches
wrote:
>
> Ping?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598276.html
This is great! And hope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 can be
re-considered, at least for some ports :)
> On Jul 27, 2022,
On Mon, Aug 1, 2022 at 12:05 PM H.J. Lu via Gcc-patches
wrote:
>
> On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
> >
> > On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> > >
> > > On Jul 27, 2022, "H.J. Lu" wrote:
> > >
> > > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > >
p64,ilp32f,...}. We will have "*64briscv*" variants and
it will then look really ugly.
On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches
wrote:
This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.
The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=2
On Mon, Jul 4, 2022 at 6:54 PM Xi Ruoyao via Gcc-patches
wrote:
>
> On Mon, 2022-07-04 at 14:28 +, Dimitrije Milosevic wrote:
> > On Saturday, June 11, 2022 2:03 PM, Xi wrote:
> > > Just tried TSAN_SUPPORTED=yes with asynchronous unwind tables
> > > enabled,
> > > but I got some strange test
On 2022-07-01, Andrew Pinski wrote:
On Thu, Jun 30, 2022 at 11:58 PM Fangrui Song via Gcc-patches
wrote:
From: Fangrui Song
SHF_COMPRESSED style zlib has been supported since binutils 2.26
and the legacy zlib-gnu option hasn't gain adoption.
According to Debian Code Search (`gz=zlib-gnu
From: Fangrui Song
SHF_COMPRESSED style zlib has been supported since binutils 2.26
and the legacy zlib-gnu option hasn't gain adoption.
According to Debian Code Search (`gz=zlib-gnu`), no project uses
-gz=zlib-gnu (valgrind has a configure to use -gz=zlib).
Remove support for the legacy zlib
On 2022-06-24, Rainer Orth wrote:
Hi Xi,
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several
On Wed, Jun 22, 2022 at 4:29 PM Alexandre Oliva wrote:
>
> On Jun 22, 2022, Iain Sandoe wrote:
>
> > It makes some sense to have the option named -nostdlib++ if a target
> > might add multiple libs (and/or make other changes) for linking C++.
>
> if it was nostdlibc++, I'd agree. lib++ is not
On 2022-06-21, Richard Biener wrote:
On Tue, Jun 21, 2022 at 9:53 AM Fangrui Song wrote:
On Tue, Jun 21, 2022 at 1:43 AM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Jun 21, 2022 at 7:56 AM Alexandre Oliva via Gcc-patches
> wrote:
> >
> >
> > Using
On Tue, Jun 21, 2022 at 1:43 AM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Jun 21, 2022 at 7:56 AM Alexandre Oliva via Gcc-patches
> wrote:
> >
> >
> > Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C,
> > is error prone, because there's no way to tell g++ to drop
On Wed, Jun 15, 2022 at 2:34 AM Fangrui Song wrote:
>
> This was introduced in 2014-12 to use local binding for external symbols
> for -fPIE. It avoids a GOT indirection but the same optimizationis
> obtained with ld's R_X86_64_[REX_]GOTPCRELX optimization (albeit with
> sligh
ks for the good consideration. That said, I am unsure any distro
uses this currently.
I think some just work around the possibly non-existent paths by
creating symlinks.
Perhaps we should prioritize on fixing the scheme before distros start
to rely on the behavior.
> On Wed, Jun 15, 2022 at 4:00 PM Fa
On Wed, Jun 15, 2022 at 2:44 PM H.J. Lu via Gcc-patches
wrote:
>
> On Mon, Jun 13, 2022 at 9:01 AM Richard Biener
> wrote:
> >
> >
> >
> > > Am 13.06.2022 um 16:36 schrieb H.J. Lu :
> > >
> > > On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
> > > wrote:
> > >>
> > >>> On Tue, Jun 7, 2022 at
This was introduced in 2014-12 to use local binding for external symbols
for -fPIE. It avoids a GOT indirection but the same optimizationis
obtained with ld's R_X86_64_[REX_]GOTPCRELX optimization (albeit with
slightly longer code).
One design goal of -fPIE was to avoid copy relocations.
This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.
The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962
let GCC pass -m emulation to ld and let the ld emulation configure
default library paths. This scheme is problematic:
* It's not ld's business to specify default
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
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
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
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
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
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
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
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
On 2021-05-12, Rainer Orth wrote:
Hi Fangrui,
Hi Rainer,
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
Solaris/x86 ld doesn't support this, so HAVE_LD_PIE_COPYRELOC needs to
This was introduced in 2014-12 to use local binding for external symbols
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
One design goal of -fPIE was to avoid copy relocations.
On 2021-01-14, Martin Liška wrote:
On 1/14/21 11:07 AM, Richard Biener wrote:
I see no particular reason to allow arbitrary garbage to be used as
linker. It just asks for users to shoot themselves in the foot and
for strange bugreports to pop up.
Well, for a strange bug report, we'll see
Attached v3 to address nits.
On 2020-07-23, Martin Liška wrote:
On 7/21/20 6:07 AM, Fangrui Song wrote:
If the value does not contain any path component separator (e.g. a
slash), the linker will be searched for using COMPILER_PATH followed by
PATH. Otherwise, it is either an absolute path
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
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 by
> 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
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
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
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.*/
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
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
-fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging
information by itself. This makes it easier to be plugged into a build
system without worrying that unnecessary debugging information may be
generated.
2020-05-12 Fangrui Song
PR debug/95096
* common.opt
On 2020-03-11, Martin Liška wrote:
On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote:
Hello.
Thank you for the patch. You haven't received a review because we are right now
in stage4 of the development cycle:
https://gcc.gnu.org/develop.html#stage4
Thanks for the review!
According
Alternatively, we can delete it, because no user code should call it.
It may be weird that libc is expected to define this function.
This function is a language runtime interface that has nothing to do
with a libc.
---
libstdc++-v3/libsupc++/cxxabi.h | 2 +-
1 file changed, 1 insertion(+), 1
On 2020-02-24, Fangrui Song wrote:
On 2020-02-13, Fangrui Song wrote:
On 2020-02-09, Fangrui Song wrote:
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c
On 2020-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.
1 - 100 of 106 matches
Mail list logo
