On 03/27/2016 04:09 PM, Jake Hamby wrote:
Thank you for the offer. I already tested it on an Amiga 3000 w/
68040 card when I made the fix. The bug manifested as the
cross-compiler crashing with a failure to find a suitable insn,
because it couldn’t find the correct FP instruction to expand to. I
believe it manifested when running ./build.sh release with “-m68040”
set in CPUFLAGS. I will test it myself and see if it’s still an issue
without the patch. If you look at the .md file, there’s an entirely
different code path to generate the same instructions when
"TARGET_68881 && TUNE_68040" aren't defined.
At the time I made the change, I had already been testing the code on
an Amiga 3000 w/ 68040 card, so I know that the generated code is
likely correct (also, the assembler accepted it). So I’m assuming
that it’s a fairly safe thing. It was the difference between the
build succeeding or failing, and not an issue with the generated
code.
So the only thing I can suggest is that you can try a build with the
patch and make sure it's stable. I was never able to produce a build
without it, because "TARGET_68881 && TUNE_68040" was excluding the
other choices when building, I believe, libm or libc or the kernel or
something like that. I do have a test case for C++ exceptions on VAX,
which I will send separately.
We'd really like to have a test for this -- a blind change without
analysis is strongly discouraged. Analysis is virtually impossible
without a testcase.
My suggestion would be to remove your hack, rebuild (and yes, I know
it'll take a *long* time) & capture the failure. We'll want the .i/.ii
preprocessed code as well as the options used to trigger the failure.
Given those things it ought to be relatively easy for someone to analyze
the problem, determine if your patch or something else is the best
solution, and reduce the test for use within the testsuite.
jeff
