This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Patches to fix GCC's C++ exception_handling on NetBSD/VAX

From: Jeff Law <law at redhat dot com>
To: Jake Hamby <jehamby420 at me dot com>, Mikael Pettersson <mikpelinux at gmail dot com>
Cc: Christos Zoulas <christos at astron dot com>, gcc-patches at gcc dot gnu dot org
Date: Tue, 26 Apr 2016 09:57:37 -0600
Subject: Re: Patches to fix GCC's C++ exception_handling on NetBSD/VAX
Authentication-results: sourceware.org; auth=none
References: <F48D0C6B-A6DB-410B-BC97-C30D4E8B4612 at me dot com> <ncu3pc$gkd$1 at ger dot gmane dot org> <DB0276A6-0A26-44F7-8FDC-D086EA40C709 at me dot com> <A7B61B19-4CCC-423D-AE9D-7CD700151E44 at me dot com> <22264 dot 5014 dot 884776 dot 206989 at gargle dot gargle dot HOWL> <1099ABF9-0704-4E93-AB8A-5C70B11FD064 at me dot com>

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 withoutanalysis is strongly discouraged. Analysis is virtually impossiblewithout a testcase.

My suggestion would be to remove your hack, rebuild (and yes, I knowit'll take a *long* time) & capture the failure. We'll want the .i/.iipreprocessed code as well as the options used to trigger the failure.Given those things it ought to be relatively easy for someone to analyzethe problem, determine if your patch or something else is the bestsolution, and reduce the test for use within the testsuite.


jeff

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]