https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696
Bug ID: 99696
Summary: lto looks past aliases to initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696
--- Comment #1 from Richard Henderson ---
Actually, I can reproduce this with gcc 9.3 as well.
My upstream bug report simply uses gcc 11, so I assumed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
--- Comment #9 from Richard Henderson ---
As a data point, this problem can be seen with any
strict-alignment target -- e.g. sparc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
--- Comment #10 from Richard Henderson ---
Created attachment 49473
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49473&action=edit
rfc patch
The following fixes the ICE.
It seems like a hack, done at the wrong level.
Should we have in f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
Bug ID: 108470
Summary: Missing documentation for alternate uses of
__attribute__((noinline))
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105131
Bug ID: 105131
Summary: Warning for mismatched declaration/definition with
enum
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389
Bug ID: 107389
Summary: Alignment not inferred from type at -O0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389
--- Comment #3 from Richard Henderson ---
If __builtin_assume_aligned were to work at -O0,
that would also work for me. Better, probably,
than fiddling with __attribute__((aligned)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|Alignment no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #7 from Richard Henderson ---
(In reply to Richard Biener from comment #5)
> int bad1(void) { return __builtin_constant_p(global++); }
...
> Joseph, Richard, do you have anything to add or remember discussions about
> this semantic d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #9 from Richard Henderson ---
> Thanks. So yes,
>
> macro(x++);
>
> incrementing x twice would have been odd - but that's the usual bug
> in this kind of macro definition. Fixing it by throwing away
> side-effects (and always goi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #36 from Richard Henderson ---
(In reply to Mayshao-oc from comment #34)
> (In reply to Jakub Jelinek from comment #17)
> > Fixed for AMD on the library side too.
> > We need a statement from Zhaoxin and VIA for their CPUs.
>
> Sorr
12 matches
Mail list logo
