On Tue, Jul 2, 2024 at 3:52 PM Georg-Johann Lay <a...@gjlay.de> wrote: > > ...just noticed that disabling -ftree-ter would also fix PR53049 > where it moves a volatile asm across a library call.
As explained in the PR this only avoids the issue by accident (and with the other comment I'm trying to make sure this is not another such case). You can always use -O0 (disable everything) to "fix" bugs, but that's of course not a fix. Disabling TER might hide a bug in TER but it might just do things differently and _not_ fix or hide a bug. Richard. > > Am 02.07.24 um 15:42 schrieb Georg-Johann Lay: > > Hi Jeff, > > > > This is a patch to get correct code out of 64-bit > > loads from address-space __memx. > > > > The AVR address-spaces may require that move insns issue > > calls to library support functions, a fact that -ftree-ter > > doesn't account for. tree-ssa-ter.cc then replaces an > > expression across such a library call, resulting in wrong code. > > > > This patch disables that pass per default on avr, as there is no > > more fine grained way to avoid malicious optimizations. > > The pass can still be re-enabled by means of explicit -ftree-ter. > > > > Ok to apply? > > > > As an alternative, the option could be disabled permanently in > > avr.cc::avr_option_override(). > > > > Johann > > > > -- > > > > AVR: middle-end/87376 - Use -fno-tree-ter per default. > > > > Temporary expression replacement might replace expressions across > > library calls, for example with move insn from address-space __memx > > like in PR87376. -ftree-ter has no way where the backend could hook > > in to avoid only problematic replacements, thus kick it out altogether. > > > > PR middle-end/87376 > > gcc/ > > * common/config/avr/avr-common.cc (avr_option_optimization_table) > > <OPT_ftree_ter>: Set to 0. > > gcc/testsuite/ > > * gcc.target/avr/torture/pr87376-memx.c: New test.
