Hi,
I apologize for the poor quality of the initial version of the patch that I
submitted. I think I may have also mangled it by not disabling the "smart
quotes" feature on my Mac before I pasted in the diff from the terminal window.
I intentionally did not use gmail for fear of adding word wraps or converting
tabs to spaces, but apparently I mangled the patch anyway. I emailed Christos a
.tar.gz version separately.
Yes, the file you highlighted is definitely not correct and I need to figure
out how to fix it properly. For some reason the optimizer is deleting the
emit_move_insn() on VAX, while it seems to work on all the other platforms that
define EH_RETURN_HANDLER_RTX() and depend on that instruction. So I'm looking
into fixing it in gcc/config/vax/something. My next step to try to figure out
what's going on is to dump the trees for all the phases when building
unwind-dw2.o (the only file where __builtin_eh_return() has to work in GCC when
libgcc is compiled in order for C++ exceptions to work) with and without "-O",
and figure out when the instruction is being deleted and why. This only affects
functions that call __builtin_eh_return() instead of return, but I think
cc1plus may also need it to be defined correctly for some code that it
generates.
My theory is that it has to do with liveness detection and a write into the
stack frame being incorrectly seen as updating a local variable, but that could
be completely wrong. I was hoping that by cc'ing gcc-patches that somebody more
familiar with why some phase of the optimizer might decide to delete this
particular insn that copies data into the stack (to overwrite the return
address, e.g. to move to EH_RETURN_HANDLER_RTX) immediately before returning.
So far I haven't found any actual bugs in GCC that should be fixed. Perhaps it
isn't correct to check in a hack like the change to gcc/except.c into
netbsd-current except temporarily, until there's a correct fix for that part of
the issue, which is what I'd like to figure out. In the meantime, I would
highly recommend adding an #ifdef __vax around that line to avoid trouble with
the other ports.
Now that I think about it, please do not check in the patch to
gcc/dist/gcc/except.c without an #ifdef __vax, and certainly this isn't ready
to go into GCC mainline. But I think it will be ready with a few more
adjustments. The important thing is that I think most, if not all of the
necessary fixes will be entirely modifications to VAX-related files that can be
locally patched in NetBSD regardless of whether the GCC maintainers accept them
or not.
To be honest, my hope by sending out my work now, even in such a rough state,
would be to try to avoid deprecating the GCC port to VAX, if only because: 1)
there doesn't seem to be a compelling reason to remove support for it since it
doesn't use any really old code paths that aren't also used by other backends
(e.g. m68k and Atmel AVR use cc0, IBM S/390 uses non-IEEE FP formats), so it
doesn't seem to be preventing any optimizations or code refactoring elsewhere
in GCC that I could see, 2) even though NetBSD could continue to support VAX
GCC, I noticed in the ChangeLogs that whenever somebody has made a change to a
definition that affects the backends, they're usually very good about updating
all of the backends so that they continue to compile, at least. So leaving the
VAX backend in the tree would be beneficial from a maintenance standpoint for
users of it, 3) the VAX backend is perhaps somewhat useful as a test case for
GCC because so many unusual RTX standard instructions were obviously defined
*for* it (although x86 defines a lot of them, too), although my interest is
personally in preserving an interesting piece of computer history, and for
nostalgia purposes.
I sent an earlier email to port-vax suggesting that future discussions of this
project aren't relevant to gcc-patches, but I did want to get it on a few
people's radar on the NetBSD side and try to solicit a bit of help on the
questions I had as to how to avoid having to add that hack to gcc/except.c to
make the optimizer not delete the insns. All of the other stuff can be worked
on in NetBSD-current and avoid bothering the 99% of people who subscribe to
gcc-patches who have no interest in the VAX backend.
Best regards,
Jake
> On Apr 1, 2016, at 04:37, Bernd Schmidt <bschm...@redhat.com> wrote:
>
> Cc'ing Matt Thomas who is listed as the vax maintainer; most of the patch
> should be reviewed by him IMO. If he is no longer active I'd frankly rather
> deprecate the port rather than invest effort in keeping it running.
>
>> Index: gcc/except.c
>> ===================================================================
>> RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/except.c,v
>> retrieving revision 1.3
>> diff -u -r1.3 except.c
>> --- gcc/except.c 23 Mar 2016 15:51:36 -0000 1.3
>> +++ gcc/except.c 28 Mar 2016 23:24:40 -0000
>> @@ -2288,7 +2288,8 @@
>> #endif
>> {
>> #ifdef EH_RETURN_HANDLER_RTX
>> - emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
>> + rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX,
>> crtl->eh.ehr_handler);
>> + RTX_FRAME_RELATED_P (insn) = 1; // XXX FIXME in VAX backend?
>> #else
>> error ("__builtin_eh_return not supported on this target");
>> #endif
>
> This part looks highly suspicious and I think there needs to be further
> analysis.
>
>
> Bernd
>
