On 2017-07-24, at 4:36 PM, Niko Tyni wrote:
> Do you know why the GCC optimization issue only seems to affect hppa+sh4?
No.
This hunk of code is wrong:
.loc 1 14875 0 is_stmt 0 discriminator 2
bl Perl_sv_2iv_flags,%r2
copy %r4,%r26
.LVL1245:
copy %r29,%r3
The above line is wrong. r29 is potentially clobbered by the call to
Perl_sv_2iv_flags.
It's a call clobbered register. It sets %r3 which is responsible for the
garbage return value.
I think this probably occurs as a result of the merging of the switch
statements but I'm
not 100% certain.
>
> I wonder if lowering the optimization of the affected
> code would be an easier workaround. On that note, looking
> at the build logs makes me think the cflags fiddling in
> debian/patches/debian/hppa_op_optimize_workaround.diff is still working,
> but the problem here is that op.c is linked to opmini.c for the miniperl
> build and that still gets compiled at -O2.
>
> Does it work for you without the Perl_custom_op_get_field() code
> reorganization if you patch cflags.SH further like this?
>
> - op) : work around http://bugs.debian.org/838613
> + op|opmini) : work around http://bugs.debian.org/838613
>
> This should make it build both op.c and opmini.c at -O0.
Might work.
>
> Or does this hit the hppa "-O0 -fPIC" problem again?
Again, I don't know. I had thought the R_PARISC_DPREL21L relocation problem was
an optimization issue. I have installed perl 5.26+b1 on a couple of systems.
Building
libjavascript-minifier-xs-perl with it doesn't trigger the issue nor does
building it with
DEB_BUILD_OPTIONS=noop. Something is wrong with Adrian's build that doesn't
occur with my patched build. buildd still has Adrian's version.
Dave
--
John David Anglin dave.ang...@bell.net
