Hi,
In the course of verifying my data race fix patch series[1] with a BWX
system (credit to Magnus Lindholm <[email protected]> for sharing hardware
for the purpose of this effort) I came across a suspicious progression
triggered with the newly-added `-msafe-partial' option and certain
optimisations enabled:
FAIL: gcc.c-torture/execute/pr64242.c -O0 execution test
FAIL: gcc.c-torture/execute/pr64242.c -O1 execution test
-FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test
-FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test
FAIL: gcc.c-torture/execute/pr64242.c -Os execution test
-FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
and my assessment was this is pure luck from instruction shuffling with an
otherwise broken `builtin_longjmp' handler in the Alpha backend, which
needs a similar fix to ones made for other backends such as the MIPS one.
This mini patch series fixes PR64242 for Alpha, on top of a port of
commit 41439bf6a647 ("builtins.c (expand_builtin_longjmp): Added two
memory clobbers.")[2], back from 2003.
Verified with the `alpha-linux-gnu' target using EV45 hardware, except
for the Go frontend testsuite verified with the `alphaev56-linux-gnu'
target and the `-mcpu=ev4' option using said BWX system, due to Go tests
intermittently exhausting the virtual memory limit set to 112MiB with my
test system (which I'd consider a conceptual problem and an unreasonable
requirement with the test cases, which are supposed to be small, aren't
they?).
OK to apply?
Maciej
References:
[1] "Fix data races with sub-longword accesses on Alpha",
<https://inbox.sourceware.org/gcc-patches/[email protected]/>
[2] "Nonlocal gotos: wrong frame pointer handling",
<https://inbox.sourceware.org/gcc-patches/[email protected]/>
Maciej
