nt 4.
-ffunction-sections -fno-unique-section-names =>
.text.%
.text.startup.%
.text.hot.%
.text.cold.%
...
?
I agree that it is superior. If GCC wants to support this scheme, that looks
fine to me. It is likely that I can migrate Clang to this scheme as well.
I think
.text%
.text.startup%
.text.hot%
.text.cold%
...
is slightly worse.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98673
--- Comment #5 from jojo ---
Sorry for late :)
Please test with following c case:
long
YTableLookup (long xValue, long xEntries, const long *xAxis,
const long *yTable )
{
int i ;
long xDelta ;
long outValue ;
for (i=0; i<(
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
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: mhjacobson at me dot com
Target Milestone: ---
`set_multilib_dir()` is responsible for selecting a multilib directory given
(a) `multilib_select` and (b) the state of the switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100830
--- Comment #1 from Matt Jacobson ---
Another place that exhibits this weirdness is `print_multilib_info()` (which is
used at build time for the target libraries). It also calls `default_arg()`
and omits lines that match the defaults.
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
It's not clear to me that no_profile_instrument_function should prevent
inlining. I'll argue that attributes should be orthogonal.
https://lists.llvm.org/pipermail/llvm-dev/2021-April/150062.html
https://reviews.llvm.org/D101011#271
If the user wants to suppress inli
fully but strongly disagree. It's surprising to developers when
> they ask for no stack protector, or no profiling instrumentation, then get
> one anyways. For long call chains, it's hard for developers to diagnose on
> their own which function they called that missed such
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #9 from Arsen Arsenović ---
(In reply to LIU Hao from comment #8)
> The commit above just lets GCC bootstrap on Windows. The cause of this issue
> is still there.
>
> Maybe it's possible to replace all direct calls to `abort()` in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #11 from Arsen Arsenović ---
(In reply to LIU Hao from comment #10)
> I think Jonathan's proposal makes it unnecessarily complex. Renaming `abort`
> to `gcc_fancy_abort`, as well as all invocations accordingly, should be much
> simpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #5 from Himal ---
(In reply to niXman from comment #4)
> (In reply to niXman from comment #2)
>
> > I don't think the patch is correct because for WIN32 platform `unlink()`
> > will never be called even for non-"nul" files.
>
> mor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #7 from Himal ---
(In reply to niXman from comment #6)
> I think you don't understand me.
>
> with your patch after preprocessing the `unlink_if_ordinary()` will look
> like:
> ```
> int
> unlink_if_
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sergey at polovko dot me
Target Milestone: ---
Starting from GCC 12.1 I see changed compiler behaviour for following snippet
of code:
struct S {
~S() {}
};
int func() {
if (auto s = S{}; false) {
} else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108576
--- Comment #1 from Sergey Polovko ---
Sorry, this line
> * https://godbolt.org/z/8Gq4fjacr (12.3)
should mention GCC 11.3
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: technicallyanonymous at proton dot me
Target Milestone: ---
This code, compiled with GCC 12.2 (-O2 -std=c++20)
#include
int foo(std::byte *arr
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: technicallyanonymous at proton dot me
Target Milestone: ---
This code, compiled with GCC 12.2 (-O2 -std=c++20):
#include
int foo(char *arr
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #1 from Arsen Arsenović ---
The kernel's using wrong C(XX)FLAGS to compile the plugin. IMO, the best
solution would be to dump $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) into a makefile
that gets installed, so that plugins can use that
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.gcc at me dot benboeckel.net
Target Milestone: ---
There is no way to decorate an `export module X;` with an
`__attribute__((visibility("default")))` such that
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arsen at aarsen dot me
Target Milestone: ---
I can reproduce the jump to ud2 on 11.3.0, GCC 12.2.0, as well as
g:b6316324fceaef431799a8b386de5cc9881d6898 but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
--- Comment #1 from Arsen Arsenović ---
Created attachment 53490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53490&action=edit
Preprocessed test (gz-compressed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
--- Comment #2 from Arsen Arsenović ---
Created attachment 53491
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53491&action=edit
Reduced test case
Alright, managed to get a reduced test case out of C-Vise. Though, this doesn't
build on c
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=103626
--- Comment #2 from Arsen Arsenović ---
I started work on marking headers, and I already marked 162 headers (all of
include/{std,bits,backward}, where appropriate) as part of my work on P1642.
This set also lines up with the set of all installe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626
--- Comment #4 from Arsen Arsenović ---
(In reply to Jonathan Wakely from comment #3)
> I don't think we need to add the #error to every header. For a start, users
> never include the bits/* headers directly, and if they do, it's their
> problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626
--- Comment #6 from Arsen Arsenović ---
Agreed. Now that I think about it, it'd be just as easy to spot errors if
something in freestanding is relying on a hosted feature by just trying to
#include those headers on a freestanding install, so mor
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at inclyc dot cn
Target Milestone: ---
https://godbolt.org/z/oz4e7bobT
https://godbolt.org/z/hE6x9G49q
illustrate different occasions about this issue.
Consider passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107135
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at aarsen dot me
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at aarsen dot me
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at aarsen dot me
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147
--- Comment #4 from Arsen Arsenović ---
Ah, my bad, I had checking off in my 12.2.0 build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
--- Comment #7 from Arsen Arsenović ---
Yes, this and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106188 both.
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/
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luizfvalle at pm dot me
Target Milestone: ---
Created attachment 52056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52056&action=edit
Input file (test.cpp)
A global enu
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
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at xecycle dot info
Target Milestone: ---
Running example at https://godbolt.org/z/cEjTWPvYf, code with clang part
removed is:
#include
using std::coroutine_handle
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at elchris dot org
Target Milestone: ---
Created attachment 52405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52405&action=edit
someFunc is made public b
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
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
I found this case in my riscv vector test case, and following is snippets of
problematic RTL:
before register renamer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103296
--- Comment #1 from jojo ---
My patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584589.html
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
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
/issues
/19#issuecomment-903203750
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: me at jhdtl dot ru
Target Milestone
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359
Larkin Nickle changed:
What|Removed |Added
CC||me at larbob dot org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359
--- Comment #6 from Larkin Nickle ---
(In reply to Larkin Nickle from comment #5)
> I am also running into this on HP-UX 11.23 on PA-RISC. I've started with
> HP's distribution of GCC 4.7.1 and have attempted to build 4.7.4, 4.8.5, and
> 4.9.4 an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359
--- Comment #7 from Larkin Nickle ---
For anyone finding this in the future, I'm guessing 32-bit builds of GCC on
HP-UX+PA-RISC were just broken for a while. Building 5.5.0 with libquadmath
enabled worked fine.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: me at larbob dot org
Target Milestone: ---
Created attachment 51410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51410&action=edit
bsd-closefrom.i from -save-temp
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: me at larbob dot org
Target Milestone: ---
Building gcc-12-20210905 seems to result in a bootstrap comparison failure
between stages 2 and 3 on hppa2.0w-hp-hpux11.*.
Comparing stages 2 and 3
warning: hppa2.0w-hp
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
: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: mhjacobson at me dot com
Target Milestone: ---
I am working on a NeXTv2-ABI-compatible Objective-C runtime for a non-Darwin
platform (AVR micros). I'd like my Object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99759
Fangrui Song changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537
--- Comment #2 from Matt Jacobson ---
I certainly haven't spent as much time thinking about this as you, but I think
my personal preference would be to add new values to the `flag_objc_abi`
argument. It's already the case that "objc-next-runtim
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
-fgnu89-inline / C99 / C++ inline modes are all different. For C++, perhaps
neither
__GNUC_STDC_INLINE__ nor __GNUC_GNUC_INLINE__
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pkh dot me
Target Milestone: ---
Following is a code that is sensible to a signed integer overflow. I was under
the impression that this kind of undefined behavior essentially meant that the
value of that integer could
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: me at xenu dot pl
Target Milestone: ---
The error below occurs only with -Od. The code is accepted if one of
-O0, -O1, -O2, -O3 or -Os is used instead.
This happens with GCC 12.1 and 12.2, it doesn't with 11.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #1 from Tomasz Konojacki ---
(In reply to Tomasz Konojacki from comment #0)
> The error below occurs only with -Od.
Sorry, -Og.
PS. It seems that moving the definition of fun4 to the first line
makes the error disappear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #5 from Tomasz Konojacki ---
To sum this thread up, there are undocumented rules that can cause a
semantically identical program to be rejected by the compiler under certain
optimisation levels (with an uninformative error message) a
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Clang introduced the attribute in https://reviews.llvm.org/D108029 (2021-08).
It disables instrumentations for all kinds of sanitizers.
For non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107963
--- Comment #3 from Fangrui Song ---
GCC doesn't implement -fsanitize=memory.
In the absence of it, __attribute__((disable_sanitizer_instrumentation)) is
like __attribute__((no_sanitize("all"))).
When -fsanitize=memory is implemented, the two a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
--- Comment #2 from Ben Boeckel ---
> Perhaps the best option is to default the visibility of the implicit
> functions to the widest visibility of any function or object in module
> purview exposed by the TU.
What to do about `extern "C"` API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107607
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at aarsen dot me
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #7 from Arsen Arsenović ---
Created attachment 54165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54165&action=edit
hang-testing script
With the attached script, I singled out
utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #8 from Arsen Arsenović ---
Created attachment 54166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54166&action=edit
xz'd preprocessed CodeGenDagPatterns.cpp
Cmdline: [220/231] /usr/bin/g++-12 -DGTEST_HAS_RTTI=0 -D_FILE_OFFSE
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: himalr at proton dot me
Target Milestone: ---
Created attachment 54180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54180&action=edit
Handle Windows nul
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
An raw symbolic operand is useful in inline asm (e.g. in C++ to get the mangled
name, or in C to let the compiler do some asm checking). In aarch64 and
401 - 500 of 722 matches
Mail list logo
