[PATCH 2.95.3] Fix powerpc-wrs-vxworks eabi backwards incompatibility.

[Bernd Schmidt]

On Mon, 11 Dec 2000, David Korn wrote:

> In particular, the alignment of DFmode function
> arguments has changed, and the entire std/varargs handling has been 
> rewritten in a fundamental way.

Sorry, I overlooked this bit of your mail.  Are these the only problems,
or are there additional ones?

Some more comments on particular pieces of your patch:

>  o   The patchset includes an unrelated but obviously-correct fix to the 
>    rs6000 port in general: CALL_V4_SET_FP_ARGS and CALL_V4_CLEAR_FP_ARGS are
>    swapped throughout, in both usage and semantics! So although it's just a
>    #def that doesn't mean what it says, and the generated code is correct, 
>    I swapped them back. But people might feel I should send this as a 
>    separate patch.

You should, and if this really doesn't affect anything, it's not appropriate
for 2.95.3.

>  o   The patchset also implements a -mlongcall flag, which specifies that
> all
>    calls to functions that are not known to be in the current compilation
> unit
>    are made using indirect calls, unless a "shortcall" attribute is applied
> to
>    the function declaration, to get around the +- 32 MB range of PPc
> pc-relative
>    branch instructions. This seemed so useful that I've made it independent
> of
>    the VxWorks compilation - it applies to all rs6000 targets - but maybe it
>    should be a separate patch set?

Yes.  This one is not appropriate for 2.95.3 either.

>  o   The approach I've taken is debatable as to whether it's a crude hack
>    or an elegant application of the principle that form should reflect
>    function. In several major routines that have substantial differences
>    between 2.7.2 and 2.95.2, I've simply wrappered the entire function
> bodies
>    of the old and new versions with
> 
>    if (TARGET_VXCOMPAT)
>    { 
>      /* entire contents of v2.7.2 function body here */
>    }
>    else
>    {
>      /* entire contents of v2.95.2 function body here */
>    }
> 
>      Now, if it was the right thing to do, I could factor out the unchanged
>    code between the then and else blocks, and remove the outer level of
>    conditional, but I didn't think it *was* the right thing to do. After
> all,
>    we don't want any future changes to break the compatibility again, which
>    would be a danger if the two code blocks were intermingled. Indeed this 
>    invalidates what would be the normal argument against such a crude bit of
>    coding, which would be the danger of forgetting to maintain changes in
>    parallel in both sections of the code! So I think it's ok myself, but am
>    looking for comments.

Depends on the amount of changes you've made.  If it's only a one-liner, then
this sort of thing is excessive.

>  o   In order to replicate the behaviour of VxWorks in dumping a detailed
>    listing of the compiler flags at the start of all .s files (which it does
>    regardless of the -fverbose-asm flag), I have had to expose the arrays of
>    lang_indepedent_options in toplev.c to the rest of the code.
> Alternatively,
>    I could have put a routine that is only ever relevant to rs6000.c into
>    toplev.c directly. Neither solution struck me as 100% desirable, so I
> went
>    with making the arrays global. Comments?

Why bother?  Surely nothing relies on this behaviour?


Bernd