https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #15 from Alexander Monakov ---
malloc and friends modify 'errno' on failure, so in they would have to be
special-cased for alias analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
--- Comment #6 from Alexander Monakov ---
(In reply to Jimi Huotari from comment #0)
> (By the by, is ADCX a typo of ADX? I see -madx as an option but only one
> use of it otherwise, and no -adcx as an option and lots of mentions of it...
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
--- Comment #10 from Alexander Monakov ---
Right, those are different issues. Any chance of a standalone testcase
extracted from Wine? If you already see a function where stack realignment is
missing, just give us preprocessed containing source,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #3 from Alexander Monakov ---
Seems to work fine with explicit '-mincoming-stack-boundary=2' on the command
line, even though it should make no difference for the 32-bit MinGW target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #4 from Alexander Monakov ---
Further reduced:
void f()
{
int c[4] = { 0, 0, 0, 0 };
int cc[8] = { 0 };
asm("" :: "m"(c), "m"(cc));
}
Also reproducible with -march=skylake-avx512 or even plain -mavx512f,
retitling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #6 from Alexander Monakov ---
Huh? Just compile the supplied testcases without avx512, you'll see proper
stack realignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #3 from Alexander Monakov ---
Do you have older versions of GCC to check on this testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #5 from Alexander Monakov ---
It's not necessary yet for this particular bug, but might be helpful for future
bugs (if disk space is not an issue).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #6 from Alexander Monakov ---
Cross-compiler needs HAVE_AS_EXPLICIT_RELOCS=1.
With checking enabled, we get:
t.c:8:1: error: flow control insn inside a basic block
(call_insn 97 96 98 4 (parallel [
(set (reg:DI 0 $0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #8 from Alexander Monakov ---
REG_EH_REGION is handled further down that function, but
copy_reg_eh_region_note_backward does not copy the note. Perhaps it needs
diff --git a/gcc/except.cc b/gcc/except.cc
index e728aa43b6..cfe140c4d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #10 from Alexander Monakov ---
I think the first patch may result in duplicated notes, so I wouldn't recommend
picking it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110369
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #13 from Alexander Monakov ---
Note to self: check how control_flow_insn_p relates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #11 from Alexander Monakov ---
The trapping angle seems valid, but I have a really hard time understanding the
DSE issue, and the preceding issue about disambiguation based on RTL aliasing.
How would DSE optimize out 'd[5] = 1' in y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #13 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #12)
> As explained in comment#3 the issue is related to the tree alias oracle
> part that gets invoked on the MEM_EXPR for the load where there is
> no infor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #8 from Alexander Monakov ---
(In reply to Sam James from comment #7)
> We keep getting quite a few reports of this downstream.
Of this mingw32 stack realignment issue specifically, i.e. Wine breakage when
AVX512 is enabled via CFLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #16 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #14)
> vectors of T and scalar T interoperate TBAA wise. What we disambiguate is
>
> int a[2];
>
> int foo(int *p)
> {
> a[0] = 1;
> *(v4si *)p = {0,0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #18 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #17)
> Yes, we do the same to loads. I hope that's not a common technique
> though but I have to admit the vectorizer itself assesses whether it's
> safe to
-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Inspired by bug 110237 comment 19:
int b, a;
int main()
{
int *pa = &a, *pb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #21 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #19)
> But the size argument doesn't have anything to do with TBAA (and
> may_alias is about TBAA). I don't think we have any way to circumvent
> C object ac
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
VPTERNLOG is never a dependency-breaking instruction on existing x86
implementations, so generating a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438
--- Comment #1 from Alexander Monakov ---
We might want to omit PXOR when optimizing for size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
--- Comment #7 from Alexander Monakov ---
Note that vpxor serves as a dependency-breaking instruction (see PR 110438). So
in negate1 we do the right thing for the wrong reasons, and in negate2 we can
cause a substantial stall if the previous com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
--- Comment #9 from Alexander Monakov ---
(In reply to Hongtao.liu from comment #8)
>
> For this one, we can load *a into %zmm0 to avoid false_dependence.
>
> vmovdqau ZMMWORD PTR [rdi], zmm0
> vpternlogq zmm0, zmm0, zmm0, 85
Yes, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438
--- Comment #3 from Alexander Monakov ---
Patch available:
https://inbox.sourceware.org/gcc-patches/8f73371d732237ed54ede44b7bd88...@ispras.ru/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113293
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #20 from Alexander Monakov ---
Sam, can you provide more context? It seems there is no downstream bugreport?
How does the alleged miscompilation manifest?
Note that effects of interplay of fp-contract=fast and vectorization can be
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #22 from Alexander Monakov ---
Similar to the RawTherapee issue, SLP opportunities are created by predcom, so
either -fno-predictive-commoning or -fno-tree-slp-vectorize avoids numerical
runaway on the small testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #23 from Alexander Monakov ---
I suggest it to close this a dup of PR 106902 if there are no better ideas.
By the way, in both cases SLP introduces vectors in a loop where scalar
computations it's attempting to replace are not elimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #26 from Alexander Monakov ---
(In reply to Richard Biener from comment #24)
>
> That's because of -fno-vect-cost-model, it wouldn't be vectorized otherwise.
Thanks, I forgot. The testcase in PR 106902 was vectorized at plain -O3 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #15 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Alexander Monakov from comment #13)
> > fldt does not convert (otherwise there's no way to spill/reload x87
> > registers).
>
> Doesn't it st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #15 from Alexander Monakov ---
No, I didn't do older AMDs (btver2 & bdver3) and newer AMD (znver4) regressed
this once again. Here's the current picture of top 10:
nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #2 from Alexander Monakov ---
Amazing bug. Note that it depends on high-order bits of return address
overwriting o.i, so may need -no-pie -fno-pie to reproduce. Alternatively,
changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #2)
> Alternatively,
> changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduce with PIE as well.
^
I meant 'if (o.i ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
: wrong-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
void bar(int tag, ...);
void foo32(void) {
bar(1, -1, 0);
}
void foo64(void) {
bar(1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #1 from Alexander Monakov ---
Created attachment 59528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59528&action=edit
executable testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #6 from Alexander Monakov ---
compare_operand is used in compare_asm_inputs_outputs, so this is broken too:
void foo32(void) {
asm("" :: "r"(-1));
}
void foo64(void) {
asm("" :: "r"(-1LL));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #12 from Alexander Monakov ---
On IRC Jakub mentioned gcc_assert (token() == TYPEDEF) in gengtype and Richi
further noted
tree-ssa-loop-ivopts.cc:gcc_assert (use->op_p = gimple_call_arg_ptr (call, 0));
cgraph.cc: gcc_assert (++edge
||amonakov at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Alexander Monakov ---
In all likelihood a dup of PR 117476.
*** This bug has been marked as a duplicate of bug 117476 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #22 from Alexander Monakov ---
*** Bug 117532 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117421
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116947
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
It is not really possible to define (not just declare) a returns_twice function
in C. The only possibilities I see are:
1) a "naked" function, on targets where that's s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
--- Comment #2 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #1)
> So if the tail-call uses [[musttail]] the alternative 3 should be "fine"?
Yes, plus annotating the callees that return twice with the attribute is still
require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
--- Comment #4 from Alexander Monakov ---
The code in comment #3 is invalid: siglongjmp is called when the state saved in
env is no longer valid: plat_setjmp has returned (and the stack slot where its
return address is stored is overwritten).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
--- Comment #5 from Alexander Monakov ---
Thanks, here's a variant of the small testcase that fails on gcc-14 too, just
needed to make the integer field the first in the struct:
struct s {
int i[2];
float f[2];
double d;
};
void f(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118818
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
Minimized from Firefox mysteriously segfaulting when built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118570
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #10 from Alexander Monakov ---
Yeah, I would expect compare_operand to be the proper place for a fix, not its
callers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #36 from Alexander Monakov ---
We can flip the default from =fast to =on for -std=gnuXX any time we like, but
it must remain at =off for =std=cXX as long as STDC FP_CONTRACT pragma is not
implemented.
I have not attempted any mass r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #31 from Alexander Monakov ---
I am certainly missing some interesting history here, because on one hand, I
see that a.out uses call-pop combo in function prologue to find out current PC,
and then uses %ebx-relative addressing in PIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #23 from Alexander Monakov ---
That's probably just copying existing behavior from 32-bit x86.
Can we preserve previous behavior that under -fpic -mno-direct-extern-access
mcount is called via GOT (and else emit mcount@PLT if -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #21)
> GOT indirection for mcount has been there from the very beginning:
> https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.
> h?id=c98f874233428d7e6ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #30 from Alexander Monakov ---
Sorry, sent too soon: a.out had the concept of PLT as well as GOT:
https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.c?id=c98f874233428d7e6ba83def7842fd703ac0ddf1#n820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #34 from Alexander Monakov ---
We have -mcmodel=kernel already, which is incompatible with -fpic.
Ard, where is -fpic in the kernel context coming from? Kernel's top-level
Makefile passes -fno-PIE, and arch/x86/Makefile passes -mcmo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #38 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #37)
> Yes, we can drop -mcmodel=kernel, and use -mcmodel=small instead. This is
> why I'm not keen on relying on that - it is ill-defined and there is really
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #40 from Alexander Monakov ---
> In Linux, we don't even bother with PIC codegen, even though we link with
> -pie.
Earlier you said that building with -fPIC may be desirable, and your patch was
dealing with PIC codegen in GCC for m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #21 from Alexander Monakov ---
GOT indirection for mcount has been there from the very beginning:
https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.h?id=c98f874233428d7e6ba83def7842fd703ac0ddf1#n623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #36 from Alexander Monakov ---
Today, gcc rejects -fpic -mcmodel=kernel on the command line though, and it
doesn't look like you can drop -mcmodel=kernel, so... was there some plan for
dealing with that?
(considering new flags to co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #42 from Alexander Monakov ---
> In Linux, we don't even bother with PIC codegen, even though we link with
> -pie.
My git-grep for that is coming up empty, where should I look?
> ... on x86_64, where PIC and non-PIC codegen are r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #46 from Alexander Monakov ---
A small correction: -static-pie is not a linker option, it's a gcc (compiler
driver) option, which it decomposes into -static -pie --no-dynamic-linker -z
text for the linker; --no-dynamic-linker was add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #44 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #43)
> arch/arm64/Makefile specifies '-shared' for the linker flags, but does not
> pass -fpic of -fpie to the compiler. We used to pass '-pie -shared' but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #19 from Alexander Monakov ---
The question is why prior to your patch GCC emitted mcount@GOT (i.e. avoiding
the PLT trampoline for mcount on purpose), going all the way back to gcc-3.4
(and probably further).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #54 from Alexander Monakov ---
I think the x86_64 behavior is simply copied as-is from i386.
On i386, there was a time when Glibc wouldn't preserve eax+ecx+edx in the PLT
trampoline, but preserving those became necessary when GCC ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119733
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #51 from Alexander Monakov ---
Michael, can you give your ack/nack for Ard's proposal in comment #24 (the
second variant, I guess keying off -m[no-]direct-extern-access doesn't make
sense here). I think it properly addresses what you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #49 from Alexander Monakov ---
Aha, and I see the kernel employs the trick of preincluding a file containing '
'#pragma GCC visibility push(hidden)' when building PIE objects since 2020. So
the mcount-emitting macro in the i386 backe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #47 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #43)
> Non-PIC might be more efficient, but there are cases where we cannot use it.
> The early startup code on x86 runs from a different virtual mapping than it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #25 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #24)
> - never emit 'call mcount'
> - emit 'call *mcount@GOTPCREL(%rip)' if -fno-plt
> - emit 'call mcount@PLT' otherwise
As discussed, gcc was always using GOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #15 from Alexander Monakov ---
Any idea why prior to introduction of this bug, gcc always emitted a
GOT-indirect call for mcount? It looks like it is avoiding lazy PLT resolver,
but why is that necessary?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #56 from Alexander Monakov ---
I think you mean -fno-plt, not -mno-plt (here and your previous comment)?
Ideally we would be able to express a relocation to PLT, but without admitting
lazy binding (i.e. the trampoline will be in .pl
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Noticed by Evan Martin.
typedef int int_u __attribute__((aligned(1)));
void f(int *);
void g(int_u *p)
{
f(p);
}
-Wcast-align should warn on the implicit cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119845
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90253
--- Comment #3 from Alexander Monakov ---
clang-15 and newer warn for this, enabled by default:
warning: due to lvalue conversion of the controlling expression, association of
type 'const char' will never be selected because it is qualified
[-Wu
1101 - 1199 of 1199 matches
Mail list logo
