gcc 4.9.1 and VMS

[Simon Clubley]

I've just finished trying to build gcc 4.9.1 as a cross compiler
for a VMS Alpha target (using a Linux host) and I thought I would
let anyone interested know the results are no better than my previous
efforts with gcc 4.8.0.

(A reminder: building a cross compiler first as a pre-requisite to
building a VMS hosted gcc is the approach taken by ACT these days.)

The C frontend builds ok and a Hello World program ran ok on Eisner.
I didn't bother trying to use the cross compiler to build binutils
in VMS hosted mode this time.

The Fortran frontend builds ok but any compiled test programs fail
during startup in the same way as they did with gcc 4.8.0.

The C++ frontend fails to build with the same vms/vms-c.c "undefined
reference to `c_default_pointer_mode'" error which was present in
gcc 4.8.0. This one doesn't look like a major problem to solve, but
understanding the Fortran problem first would be my approach in case
the same problem shows up in the C++ and Ada RTLs.

The Ada frontend fails to build with the same basic internal compiler
error as gcc 4.8.0:

+===========================GNAT BUG DETECTED==============================+
| 4.9.1 (alpha-dec-vms) in plus_constant, at explow.c:87 |
| Error detected around a-direct.adb:763:59 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==========================================================================+

NOTE: before anyone tries to press gang me into spending more time on
this, note this was just a little diversion as I thought about some
design issues on another unrelated hobbyist project.

My time on this is now over and I just wanted to report the results
in the newsgroup in case anyone else was interested.

Some final thoughts:

I've built a good number of cross compilers over the years and apart
from the time I tried to get a bare metal target Ada cross compiler
running, this is easily the most frustrating target I've come across.

Part of the frustration is that it came out last time that ACT use
their own headers (which are not public) in their own commercial
GNAT products and I've had to create a process, including patches,
for using the VMS supplied headers in my own efforts with the FSF
gcc branch.

This has a major feeling of stabbing in the dark about it and given
some of the subtle behaviour changes which can occur as a result,
I'm not sure if this is contributing to the build problems.

It's not made easier with things like the Fortran issues as I don't
know if they are down to me not using some very specific and
undocumented required build options or if ACT have simply not pushed
all the required changes to the FSF gcc tree.

The sheer size of the gcc tree also makes understanding some of the
problems a challenge without a significant time investment.

A decade ago, when VMS was still a primary hobby interest for me,
I would have spent much more time on this, but I have other interests
now so no firing off emails to other people trying to rope me into
spending more time on this. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[John E. Malmberg]

On 9/6/2014 7:08 PM, Simon Clubley wrote:
> I've just finished trying to build gcc 4.9.1 as a cross compiler
> for a VMS Alpha target (using a Linux host) and I thought I would
> let anyone interested know the results are no better than my previous
> efforts with gcc 4.8.0.

Have you tried building minimal C++ and Fortran Programs using the VMS
compilers and disassembling them to compare with what GCC is generating?

On C++ your undefined symbol does not have a VMS decc$ or other prefix,
which may be all that is missing for it to be resolved.

Regards,
-John
wb8...@qsl.network
Personal Opinion Only

[Simon Clubley]

The C++ cross compiler build is failing on Linux and the symbol is an
internal gcc symbol. A quick look around seems to reveal it's an actual
gcc bug. Fixing it should not be a major problem, but the far deeper
issues revealed means there's no point unless you can have confidence
the rest of the VMS specific code is in a state that's suitable for use.

The Fortran test programs are going down early on the image activation
sequence and fail in VMS debug before the program entry point is reached.
This may be a missing piece of code or may simply be an incorrect build
option (although I tried a range of them, including various exception
models, the last time around).

This brings me back to the size of the gcc code base, both in terms of
understanding _all_ the various bits of the code used for VMS and their
inter-relationships as well as the time it takes to rebuild gcc whenever
I change anything.

One of the problems here is that ACT use their own internal GCC tree for
their professional and GPL compiler products and every so often they
push bits of it into the public FSF tree. Hence, there's no confidence
on my part that all the required VMS bits to actually bring up a cross
compiler are present in the FSF tree.

In fact, if you remember last time around in 2013, they actually said
in the email discussions that not all the bits had been pushed into the
public FSF tree at that time but it's wasn't clear if this was required
core functionality or not.

Anyway, other hobbyist projects await me, so that's it for VMS for now.