https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #6 from Fangrui Song ---
> It is incorrect to reference a non-preemptible symbol with a PC relative
> relocation in a -pie link. GNU ld allows it but the code can be incorrect at
> runtime.
Correction: It is incorrect to reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #10 from Fangrui Song ---
> extern unsigned long _binary_a_c_size;
> unsigned long foo() { return _binary_a_c_size; }
This is incorrect. The code will treat the value of _binary_a_c_size as an
address (load base + size) and dereferen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #23 from Fangrui Song ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
>
> I gave you the correct usage for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8 from
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
-ffunction-sections produces sections .text.foo , .text.bar , etc, which can
take significant amount of string table space.
In clang, -fno-unique-section-names emits
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
-gsplit-dwarf has an undesired property: it sets the debug info level to 2.
When plugged into a build system, this can enable debug info unnecessarily
(when the user does not specify -g or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95096
--- Comment #1 from Fangrui Song ---
Created https://sourceware.org/pipermail/gcc-patches/2020-May/545638.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #1 from Fangrui Song ---
I just learned that `int main() {}` compiles to .text.startup in -O2 or -Os
It seems that .text.startup. may be better to not accidentally move a C
function named `startup` (`startup.` is not a valid C identi
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
DWARF v5 Appendix F. says
> The sections that do not require relocation, however, can be written to the
> relocatable object (.o) file but ignored by the linker, or they
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
% gcc-10 -ffile-prefix-map=/tmp/c=/src --coverage -c -g /tmp/c/a.c
# -ffile-prefix-map implies -fdebug-prefix-map
% llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96092
--- Comment #3 from Fangrui Song ---
(In reply to Martin Liška from comment #2)
> Apparently we've got a patch in queue that does something similar:
>
> +fprofile-prefix-path=
> +Common·Joined·RejectNegative·Var(profile_prefix_path)
> +remove·p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #4 from Fangrui Song ---
https://sourceware.org/pipermail/gcc-patches/2020-July/550659.html [PATCH v3]
Add --ld-path= to specify an arbitrary executable as the linker
I changed the title to --ld-path because -fuse-ld=/absolute/path/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #19 from
ormal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This is a minor display issue.
>a.cc cat<b.cc cat<a.h cat<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #17 from
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I can understand that defaulting -fprofile-update=prefer-atomic in GCC 7 and
using atomic counters when -pthread is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85351
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #5 from Fangrui Song ---
Ping
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
https://wg21.cmeerw.net/cwg/issue546
Change 17.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
void f(){}
% gcc -fpatchable-function-entry=3 -c a.c
% readelf -S a.o
...
[Nr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194
--- Comment #1 from Fangrui Song ---
The SHF_WRITE issue has been fixed.
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00271.html will fix sh_addralign
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.cc
inline void foo() {}
void bar() { foo(); }
% cat b.cc
inline void foo() {}
void
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
__patchable_function_entries is not a GC root, and not referenced by a retained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #7 from Fangrui Song ---
> Is -fasynchronous-unwind-tables compatible with -fpatchable-function-entry?
Apparently the Linux kernel does not care about it. To make it usable in
userspace, we should place .cfi_startproc in a reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
--- Comment #1 from Fangrui Song ---
This is similar to --gc-sections
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93536) but a bit different.
The only reasonable fix I can think of is to place __patchable_function_entries
in the same section g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #11 from Fangrui Song ---
(In reply to H.J. Lu from comment #8)
> Created attachment 47762 [details]
> A patch to handle targetm.asm_out.post_cfi_startproc
I don't work on GCC, so I am hoping other x86 maintainers can review. (I know
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
This feature request generalizes -fuse-ld=bfd -fuse-ld=gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470
and
-fuse-ld=lld
clang -fuse-ld= also supports the following forms:
-fuse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #1 from Fangrui Song ---
Posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html
I agree with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321#c4
we should use a new option, instead of overloading --print-prog-nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52982
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
If configure-time ld does not support SHF_GNU_RETAIN, __has_attribute(retain)
may be true while using it will cause a warning.
% cat x.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99587
--- Comment #6 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Florian Weimer from comment #4)
> > For retain, something along these lines might work:
> >
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
to drop reliance on ld's default linker script
.init_array:
{
PROVIDE_HIDDEN (__init_array_start = .);
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424#c8
% echo 'int main() {}' > a.c
% clang --t
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Per object file .fini_array.00100 wastes space. __gcov_exit can be called in
libgcov. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
#include
int main() {
puts("meow");
}
% gcc -mcmodel=large -fno-plt -O1 -S a.c -fpic -o - -O2
-fno-as
rmal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
After "x86-64: Optimize access to globals in PIE with copy reloc", GCC x86-64
asks the assembler to produce an R_X86_64_PC32 for an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #2 from Fangrui Song ---
Note: -fdirect-access-external-data is architecture-independent. For example,
currently Clang on aarch64 can perform the following optimization:
// clang -target aarch64 -fPIE -O3
adrpx8, :got:var
ldr
erity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcov used _J. C. Tiernan, An Efficient Search Algorithm to Find the Eleme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
--- Comment #10 from Fangrui Song ---
Note: the section key is not just (name, group name "G"). It is a quadruple:
(name, group name "G", linked-to "o", unique ID)
Keeping just name works for the simplest case.
If GCC decides to support PR95095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #3 from Fangrui Song ---
Are you happy with the option name -f[no-]direct-access-external-data ?
https://reviews.llvm.org/D92633 is what I want to add to Clang.
I want GCC and Clang to use the same option names...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
--- Comment #10 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #9)
> I believe this broke building the kernel, see
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561974.html
> for details.
For
> ld: .init.data has both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #5 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Fangrui Song from comment #3)
> > Are you happy with the option name -f[no-]direct-access-external-data ?
>
> Not at all, no :-(
>
> The name d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #7 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Fangrui Song from comment #5)
> > Please read my first comment why copy relocs is a bad name.
>
> Since I reply to some of that (namely, your ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #3 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #2)
> Can't we use ".text%name" for -ffunction-sections, like we did originally,
> in 1996? See cf4403481dd6. This does not conflict with other section
> names, a
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
gcc/testsuite/g++.dg/eh/forced3.C says forced unwinding calls std::unexpected
going through a throw() function.
gcc/testsuite/g++.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #5 from Fangrui Song ---
Linux kernel
include/asm-generic/vmlinux.lds.h currently has
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #7 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #6)
> I was under the impression this unique section thing needed the trailing
> dot thing. This probably is not true.
>
> I still think the old "%" thing is much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #9 from Fangrui Song ---
(In reply to Segher Boessenkool from comment #8)
> I say nothing like that. I say that
> .text.hot.
> is nasty (is easily mistaken for .text.hot).
>
> I also say that and that named-per-function sections a
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
.cfi_* in inline asm is rare, but can be useful if the user wants precise
unwind information.
% cat a.c
int main() {
asm("pu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99282
--- Comment #2 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #1)
> There is the __GCC_HAVE_DWARF2_CFI_ASM predefined macro that tells if .cfi*
> directives are used or not. And, inline asm that wishes to be usable in
> both can u
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
In the demangler, the ('.' (alpha|'_')+) ('.' digit+)* scheme as implemented
for PR40831 allows a decimal but not a hexadecimal.
It'
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
int var;
int foo() { return var; }
(I implemented this for clang 11 x86)
% clang -fpic -fno-semantic-interposition -O2 -S a.c
% cat a.s
...
foo
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Most ELF targets use an absolute relocation (e.g. R_X86_64_32) to take the
address of a default visibility non-definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
--- Comment #1 from Fangrui Song ---
Another request is a new option: -fno-semantic-interposition-function. With
this option, we only assume functions cannot be interposed.
-fno-semantic-interposition assumes both functions and variables cannot
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
The documentation says -fno-semantic-interposition applies to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618
--- Comment #1 from Fangrui Song ---
Perhaps
-fsemantic-interposition=function,variable (default -fpic/-fPIC)
-fsemantic-interposition=variable (compatible with copy relocations but
enable function optimizations)
-fsemantic-interposition= (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Fangrui Song changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #2 from Fangrui Song ---
(In reply to Alexander Monakov from comment #1)
> It is not necessary to change -fno-pic code generation to gain most of the
> -Bsymbolic benefit
It is necessary, otherwise the function address taken from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #4 from Fangrui Song ---
(In reply to Alexander Monakov from comment #3)
> I understand what you're saying, but it seems we're talking past each other.
>
> I agree that if a library is linked with any -Bsymbolic* flag, the main
> ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #6 from Fangrui Song ---
(In reply to Alexander Monakov from comment #5)
> Hm, I still don't think I'm misunderstanding what you're saying. I'm
> familiar with the ELF standard (and FWIW I have read your blog posts on
> related matte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #8 from Fangrui Song ---
Seems that -fno-plt -fno-pic does have the required properties.
A side effect is that all external calls use the (x86-64) call
*f@GOTPCREL(%rip) (x86-32) call *f@GOT form.
The instruction is one byte long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #9 from Fangrui Song ---
I have a patch to implement this Clang.
It'd be good to have a name even if GCC wants to postpone the implementation
for now. How about -fdirect-access-external-function &
-fno-direct-access-external-functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618
Fangrui Song changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #11 from Fangrui Song ---
(In reply to Alexander Monakov from comment #10)
> Is there something wrong or undesirable with making this under -fno-plt (or
> the noplt attribute as in your example)?
>
> (after all, it is a kind of PLT-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #13 from Fangrui Song ---
(In reply to H.J. Lu from comment #12)
> We should handle it in the whole Linux software stack:
>
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
>
> not just in compiler.
It is great that you have
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Add a configure option --enable-default-semantic-interposition to customize
-f(no-)semantic-interposition default.
The suppression of interprocedural optimizations and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
Fangrui Song changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
--- Comment #6 from Fangrui Song ---
Then can you add a -fvisibility=protected variant which only applies to
non-weak defined functions?
Two issues need to be fixed:
(1): https://sourceware.org/bugzilla/show_bug.cgi?id=27973
__attribute__((vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #8 from Fangrui Song ---
I am thinking of __attribute__((no_profile)).
In Clang,
-fprofile-generate(-fcs-profile-generate)/-fprofile-instr-generate/-fprofile-arcs
are all different. It will make sense to have a attribute disabling al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #14 from Fangrui Song ---
(In reply to Martin Liška from comment #13)
> What's likely missing is that the attribute should prevent inlining. I'm
> going to test how it behaves right now. Then, the issue can be closed.
It's not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #18 from Fangrui Song ---
(In reply to Nick Desaulniers from comment #15)
> (In reply to Fangrui Song from comment #14)
> > Can a no_profile_instrument_function function be inlined into a function
> > without the attribute? This may b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #20 from Fangrui Song ---
(In reply to Marco Elver from comment #19)
I am ok with "inlining suppression" as an implementation strategy and I agree
that it should be useful. What I objected strongly is "promised inlining
suppression".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #21 from Fangrui Song ---
(In reply to Fangrui Song from comment #20)
> For example, if an inlining pass happens after instrumentation, then the
> function attribute doesn't necessarily need to suppress inlining. After
> instrumentati
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
In .eh_frame and .gcc_except_table, the aarch64 and riscv ports use
DW_EH_PE_indirect|DW_EH_PE_pcrel for both -fno-pic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108622
--- Comment #1 from Fangrui Song ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611081.html [PATCH]
x86: Use DW_EH_PE_indirect|DW_EH_PE_pcrel encodings for -fno-pic code
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.cc
__attribute__((section("foo"))) void f() {}
__attribute__((section("foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761
--- Comment #3 from Fangrui Song ---
New syntax setting the flags will be useful. Also, currently there is no way to
customize the section type.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
PR c/42579 added __FILE_NAME__. On the Clang side someone is proposing
__builtin_FILE_NAME (https://reviews.llvm.org/D144878) a la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Translate -gz=std to --compress-debug-sections=zstd for as and ld. This
requires that binutils supports zstd, feature request:
https://sourceware.org/bugzilla/show_bug.cgi?id=29397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897
--- Comment #4 from Fangrui Song ---
Yes, the change will be straightforward, basically the files touched by the
pending https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597586.html
("[PATCH] Remove legacy -gz=zlib-gnu").
I sent it because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #13 from Fangrui Song ---
(In reply to Martin Liška from comment #12)
> (In reply to Fangrui Song from comment #11)
> > (In reply to Martin Liška from comment #10)
> > > I replied here:
> > > https://gcc.gnu.org/pipermail/gcc-patches/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #15 from Fangrui Song ---
-- is definitely rare, but not non-existent.
In GCC, there is {-,--}specs.
In Clang, there are --cuda-path, --ptxas-path, --hip-path, --classpath, etc.
(In reply to Martin Liška from comment #14)
> >
> > I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896
--- Comment #5 from Fangrui Song ---
Ah, ok, my /tmp/glibc-many/src/gcc is at releases/gcc-11 while the fix is for
12.0?
Anyway, you may want to clean up gcc/acinclude.m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
--- Comment #11 from Fangrui Song ---
To enable interposition on Mach-O, one needs a non-default configuration like:
ld -interposable, DYLD_FORCE_FLAT_NAMESPACE or
__attribute__((section("__DATA,__interpose"))).
On PE/COFF, such interposition ju
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Many Linux distros configure GCC with --enable-default-pie (at least
Arch/Debian/Fedora/Gentoo/Ubuntu). I think it makes sense to default to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398
--- Comment #2 from Fangrui Song ---
I want to switch the default because:
* It seems to me that every Linux distro uses --enable-default-pie GCC. I use
"many", but it is likely "most" at this point (2021).
* When a user builds GCC on Linux, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #11 from Fangrui Song ---
(In reply to Martin Liška from comment #10)
> I replied here:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573823.html
There are people wanting to use mold
https://www.reddit.com/r/rust/comments/rhc
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
class base;
class b {
public:
void del(base *x);
};
class base {
friend b;
public:
virtual void a
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Under some circumstances,
const size_t allocation_size = 32768;
_Static_assert (allocation_size >= sizeof (str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102502
--- Comment #3 from Fangrui Song ---
OK, Andrew asked me to file it :)
I just wanted to fix glibc and run away from the GCC inconsistency.
I know that
https://www.iso-9899.info/n1570.html#6.6 p10 says
"An implementation may accept other forms o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99759
Fangrui Song changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
1 - 100 of 135 matches
Mail list logo
