so that
`gcc -c a.cc --coverage -fprofile-prefix-map=$PWD=.`
does not emit $PWD in the generated a.gcno file.
PR gcov-profile/96092
---
gcc/coverage.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/coverage.cc b/gcc/coverage.cc
index 1ed55fed547..c6e9aced6fe 1006
On Thu, Sep 26, 2024 at 11:21 AM Ramana Radhakrishnan
wrote:
>
> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
> >
> > From: Fangrui Song
> >
> > -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> > for FDPIC (absolute addressing f
Friendly ping :)
On Thu, Aug 22, 2024 at 7:09 PM Fangrui Song wrote:
>
> On Mon, May 13, 2024 at 2:21 PM Fangrui Song wrote:
> >
> > On Mon, Mar 4, 2024 at 12:13 AM Fangrui Song wrote:
> > >
> > > From: Fangrui Song
> > >
> > > -fno-pi
On Mon, May 13, 2024 at 2:21 PM Fangrui Song wrote:
>
> 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 f
On Mon, May 6, 2024 at 4:09 PM Fangrui Song wrote:
>
> 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:
> > >>
> > >>
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 reco
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 unit
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 `E
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.sourcewar
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. This
+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
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"(&ns::var));
asm(".reloc ., BFD_RELOC_NONE, %0" :: "s"(&ns::a[3]));
}
```
gcc/testsuite/ChangeLo
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 ad
etadata 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/o
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"(&ns::var));
asm(".reloc ., BFD_RELOC_NO
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://maskr
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 are
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".
gcc/Chang
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 numbe
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 in
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
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
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
ections 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")
Si
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 prob
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 f
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
ections 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")
Si
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-gn
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
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
ections 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")
Si
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 adop
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
ections 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/piperm
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
>
wever, 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
---
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
> 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 -mn
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.
gc
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
> > > indirection
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=z
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 a
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 wit
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 ma
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/
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, Alex
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
> > > >
e 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 co
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 f
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=zli
From: Fangrui Song
SHF_COMPRESSED style zlib has been supported since binutils 2.26
and the legacy zlib-gnu option hasn't gain adoption.
According to Debian Code Search (`gz=zlib-gnu`), no project uses
-gz=zlib-gnu (valgrind has a configure to use -gz=zlib).
Remove support for the legacy
On 2022-06-24, Rainer Orth wrote:
Hi Xi,
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several p
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 so
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 li
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 libs
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
>
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 9:0
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_
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 sha
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 Co
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 Co
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 for such
On 2021-05-12, Rainer Orth wrote:
Hi Fangrui,
Hi Rainer,
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
Solaris/x86 ld doesn't support this, so HAVE_LD_PIE_COPYRELOC needs to
stay.
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
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 even
Attached v3 to address nits.
On 2020-07-23, Martin Liška wrote:
On 7/21/20 6:07 AM, Fangrui Song wrote:
If the value does not contain any path component separator (e.g. a
slash), the linker will be searched for using COMPILER_PATH followed by
PATH. Otherwise, it is either an absolute path or a
If the value does not contain any path component separator (e.g. a
slash), the linker will be searched for using COMPILER_PATH followed by
PATH. Otherwise, it is either an absolute path or a path relative to the
current working directory.
--ld-path= complements and overrides -fuse-ld={bfd,gold,lld
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
Siz
> 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
+++
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
r{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 O
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
ctually 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: W
1 - 100 of 111 matches
Mail list logo
