[Info-vax] GCC for VMS, was: Re: fortran compiler roadmap?

[Simon Clubley]

On 2013-04-23, gingold at adacore.com <gingold at adacore.com> wrote:
> On Tuesday, April 23, 2013 2:43:31 AM UTC+2, Simon Clubley wrote:
>> 
>> Interesting, thanks.
>> 
>> Given the last sentence above, is the cross-compiler build method still
>> a work in progress or is it regarded as a finished product ?
>
> We are first building a cross compiler to build the native compiler.
>

Clarification: in this context, I just meant finished product as in capable
of been used as a fully functional cross compiler, not finished product as
in selling it to your customers.

> Note that I am pretty sure we still have patches (at least for Ada) that
> aren't merged into FSF gcc.
>

Ok, I'll keep that in mind, thanks.

>> Now I know you have added cross compiler support instead of building
>> everything native on VMS, I've spent a bit of time over the last couple
>> of days trying to build at least the first part of the tool chain.
>
> Humm, good luck :-)
>

Thanks. :-) This is just a little diversion for me from my current hobbyist
projects, so I will not be spending much more time on it anyway.

>> Of course, I have several questions which have cropped up as a result. :-)
>> 
>> Which exception model are you using ? I had _many_ attempts at trying to
>> get unwind-dw2.c to build, before I gave up and switched to sjlj exceptions
>> to bypass this issue.
>
> We are using dwarf-2, but it may be simpler to use sjlj at first.
>

Thanks. That tells me it is possible to build unwind-dw2.c if I can just hit
upon the right set of build conditions.

>> Are you using a sysroot during building and are you replacing the gcc
>> headers with the VMS versions or just adding missing headers as required ?
>
> There is no gcc headers (except a few one that are very compiler dependent, such
> as stdargs or limits)
>

Those are the headers I was thinking of. For example, at one point, I had
some issues, since solved, with __size_t (or similar).

>> After trying various options, I'm currently using the gcc supplied
>> headers instead of the VMS versions to build gcc and adding to the set
>> of headers (ie: stdlib.h) from the VMS headers as required. I also have
>> a full copy of the extracted starlet headers in include/vms/ and I've
>> tweaked the various VMS headers (__int64/resource.h/etc) as required.
>
> Most of the tweaks are handled by fixincludes.
>

Oh, that is interesting.

I haven't got as far as trying to think about streamlining the build yet,
so I've been adding in various headers after build failures. Are you making
the headers available to gcc during the configure stage so fixincludes
can find them ?

>> In the final built and installed compiler, is it intended to have a
>> mixture of gcc supplied and VMS headers on the include search path,
>> or are you removing all the gcc supplied headers and replacing them
>> with the VMS headers ?
>
> No, you cannot remove the gcc supplied headers.
>

I've come to that conclusion myself, but it's nice to know the gcc and
VMS headers are supposed to co-exist.

>> BTW, in case you are not aware, binutils 2.23.2 is broken while
>> assembling crtbegin; you get the following errors:
>> 
>> ../../gcc-4.6.2/gcc/crtstuff.c: In function 'frame_dummy':
>> ../../gcc-4.6.2/gcc/crtstuff.c:381:19: warning: array subscript is above array bounds [-Warray-bounds]
>> /tmp/ccexkclj.s: Assembler messages:
>> /tmp/ccexkclj.s:106: Error: previous .ent not closed by a .end
>> /tmp/ccexkclj.s:149: Error: previous .ent not closed by a .end
>
> No, the latest version of binutils correctly reports issues in the
> assembly file.
>

I may need to use the latest gcc then.

Because these were just experiments and because it appeared Alpha may have
been added a while back, I just used the latest version of gcc I had to
hand locally.

Thanks,

Simon.

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