[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

2023-10-31 Thread rth at gcc dot gnu.org via Gcc-bugs
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

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

2023-10-31 Thread rth at gcc dot gnu.org via Gcc-bugs
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

[Bug ipa/108470] New: Missing documentation for alternate uses of __attribute__((noinline))

2023-01-19 Thread rth at gcc dot gnu.org via Gcc-bugs
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

[Bug middle-end/107389] Always propagate __builtin_assume_aligned

2022-10-26 Thread rth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Alignment

[Bug c/107389] Alignment not inferred from type at -O0

2022-10-25 Thread rth at gcc dot gnu.org via Gcc-bugs
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)).

[Bug c/107389] New: Alignment not inferred from type at -O0

2022-10-25 Thread rth at gcc dot gnu.org via Gcc-bugs
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

[Bug c/105131] New: Warning for mismatched declaration/definition with enum

2022-04-01 Thread rth at gcc dot gnu.org via Gcc-bugs
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

[Bug middle-end/99696] lto looks past aliases to initializers

2021-03-21 Thread rth at gcc dot gnu.org via Gcc-bugs
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.

[Bug middle-end/99696] New: lto looks past aliases to initializers

2021-03-21 Thread rth at gcc dot gnu.org via Gcc-bugs
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:

[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf

2020-10-30 Thread rth at gcc dot gnu.org via Gcc-bugs
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=edit rfc patch The following fixes the ICE. It seems like a hack, done at the wrong level. Should we have in fact

[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf

2020-10-30 Thread rth at gcc dot gnu.org via Gcc-bugs
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.