Comment 13 for bug 1988710

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Mitigation

I tried putting some less load on the register transfer and found that using "-O1" (down from 2) already would work around the issue. This does in no means make the issue go away, but it helps to service qemu until resolved.

Internally this is set statically and can be overwritten from d/rules to use -O1 instead.

--- a/debian/rules
+++ b/debian/rules
@@ -557,7 +557,7 @@ sysdata-components += qboot
 build-palcode-clipper: b/qemu-palcode/palcode-clipper
 b/qemu-palcode/palcode-clipper: | b
        cp -al roms/qemu-palcode b/
- ${MAKE} -C ${CURDIR}/b/qemu-palcode CROSS=${ALPHAEV67_CROSSPFX}
+ ${MAKE} -C ${CURDIR}/b/qemu-palcode CROSS=${ALPHAEV67_CROSSPFX} OPT=-O1
        ${ALPHAEV67_CROSSPFX}strip b/qemu-palcode/palcode-clipper
 install-palcode-clipper: b/qemu-palcode/palcode-clipper
        install -m 0644 $< ${sysdataidir}/palcode-clipper

This is already emulation of alpha code, the performance impact is tolerable to make it overall build again.

This worked locally already, currently building a test in PPA:
https://launchpad.net/~paelzer/+archive/ubuntu/lp-1988710-gcc-crash-qemu/+packages