This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!
- To: gcc at gcc dot gnu dot org
- Subject: Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!
- From: msokolov at ivan dot Harhan dot ORG (Michael Sokolov)
- Date: Tue, 19 Dec 00 23:48:34 PST
John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> Unfortunately, recent changes to the mainline CVS source have broken
> the vax machine definition again.
Hmm, you've told me that it bootstraps and works for you on VAX Ultrix. Or has
it broken again in the last few days?
> No. Defining call and call_value is OK because RETURN_POPS_ARGS is
> defined. The call and call_value forms will only be used when there
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> are no arguments to pop. Thus, defining them shouldn't break the ARM.
^^^^^^^^^^^^^^^^^^^^^^^^
Are you sure that this is a gcc rule and not just an aspect of the current
implementation that can change at any time?
I still think that defining these patterns is wrong, and I recommend removing
this part from your patch. The whole purpose of the machine description is to
describe the machine as accurately as possible to the gcc engine. New
optimisations can come in at any time, and the gcc engine must be able to do
anything that the MD says is OK to do without worrying about breaking
something. Defining call and call_value means saying to the gcc engine "it's OK
to use these on this machine at any time for any function." If these are
implemented with a calls $0, this translates into "it's OK to use calls $0 to
call any function," which violates the VARM.
> The `calls $0' form is also used when the number of arguments exceeds 255.
Well, VARM doesn't provide for procedures with more than 255 arguments.
> I have enclosed a patch to vax.md that I am currently testing to fix
> the new requirement for contiguous operands.
and in another message:
> There is a typo in the above. I knew I shouldn't have sent this until
> it was tested.
Are you working on making gcc-2.97 work on VAX again and making a correct
patch?
--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force
1351 VINE AVE APT 27 Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA (home office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)