| Message ID | CAFULd4atfy2fYm-LP3+7FEzMedFFrTP9FsEnJsaoEo+XUsZ8-A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Fri, 2 Sep 2016, Uros Bizjak wrote: > argument. Passing _Complex float as a variable argument never > worked on alpha. Thus, we have no backward compatibility issues Presumably there should be an architecture-independent execution test of passing _Complex float in variable arguments - either new, or a pre-existing one whose XFAIL or skip for alpha can be removed. (That is, one in the GCC testsuite rather than relying on a libffi test to test GCC.)
On Fri, Sep 02, 2016 at 12:09:30PM +0000, Joseph Myers wrote: > On Fri, 2 Sep 2016, Uros Bizjak wrote: > > > argument. Passing _Complex float as a variable argument never > > worked on alpha. Thus, we have no backward compatibility issues > > Presumably there should be an architecture-independent execution test of > passing _Complex float in variable arguments - either new, or a > pre-existing one whose XFAIL or skip for alpha can be removed. (That is, > one in the GCC testsuite rather than relying on a libffi test to test > GCC.) And if it is in g*.dg/compat/, it can even test ABI compatibility between different compilers or their versions. Jakub
On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Fri, Sep 02, 2016 at 12:09:30PM +0000, Joseph Myers wrote: >> On Fri, 2 Sep 2016, Uros Bizjak wrote: >> >> > argument. Passing _Complex float as a variable argument never >> > worked on alpha. Thus, we have no backward compatibility issues >> >> Presumably there should be an architecture-independent execution test of >> passing _Complex float in variable arguments - either new, or a >> pre-existing one whose XFAIL or skip for alpha can be removed. (That is, >> one in the GCC testsuite rather than relying on a libffi test to test >> GCC.) > > And if it is in g*.dg/compat/, it can even test ABI compatibility between > different compilers or their versions. It looks to me that we have no tests for _Complex float variable arguments passing in g*.dg/compat/. There are no xfails for alpha* in this directory, and these arguments would fail for sure for this target. Uros.
On Fri, Sep 2, 2016 at 2:37 PM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Fri, Sep 02, 2016 at 12:09:30PM +0000, Joseph Myers wrote: >>> On Fri, 2 Sep 2016, Uros Bizjak wrote: >>> >>> > argument. Passing _Complex float as a variable argument never >>> > worked on alpha. Thus, we have no backward compatibility issues >>> >>> Presumably there should be an architecture-independent execution test of >>> passing _Complex float in variable arguments - either new, or a >>> pre-existing one whose XFAIL or skip for alpha can be removed. (That is, >>> one in the GCC testsuite rather than relying on a libffi test to test >>> GCC.) >> >> And if it is in g*.dg/compat/, it can even test ABI compatibility between >> different compilers or their versions. > > It looks to me that we have no tests for _Complex float variable > arguments passing in g*.dg/compat/. There are no xfails for alpha* in > this directory, and these arguments would fail for sure for this > target. Indeed. The only scalar _Complex float processing is in scalar-by-value-4*, and the test lacks varargs. Uros.
On Fri, 2 Sep 2016, Uros Bizjak wrote: > It looks to me that we have no tests for _Complex float variable > arguments passing in g*.dg/compat/. There are no xfails for alpha* in > this directory, and these arguments would fail for sure for this > target. I suppose compat tests should be added for _Complex double and _Complex long double variable argument passing as well along with _Complex float, if those types aren't tested for variable argument passing either.
On Sep 2, 2016, at 6:31 AM, Joseph Myers <joseph@codesourcery.com> wrote: > > On Fri, 2 Sep 2016, Uros Bizjak wrote: > >> It looks to me that we have no tests for _Complex float variable >> arguments passing in g*.dg/compat/. There are no xfails for alpha* in >> this directory, and these arguments would fail for sure for this >> target. > > I suppose compat tests should be added for _Complex double and _Complex > long double variable argument passing as well along with _Complex float, > if those types aren't tested for variable argument passing either. I concur.
On 09/02/2016 02:35 AM, Uros Bizjak wrote: > --q-- > /* Pass float and _Complex float variable arguments by reference. > This avoids 64-bit store from a FP register to a pretend args save area > and subsequent 32-bit load from the saved location to a FP register. > > Note that 32-bit loads and stores to/from a FP register on alpha reorder > bits to form a canonical 64-bit value in the FP register. This fact > invalidates compiler assumption that 32-bit FP value lives in the lower > 32-bits of the passed 64-bit FP value, so loading the 32-bit value from > the stored 64-bit location using 32-bit FP load is invalid on alpha. > > This introduces sort of ABI incompatibility, but until _Float32 was > introduced, C-family languages promoted 32-bit float variable arg to > a 64-bit double, and it was not allowed to pass float as a varible > argument. Passing _Complex float as a variable argument never > worked on alpha. Thus, we have no backward compatibility issues > to worry about, and passing un-promoted _Float32 and _Complex float > as a variable argument will actually work in the future. */ > --/q-- This sounds like a good plan to me. > (I was not able to find the > authoritative OSF/1 ABI document on the net...) As far as I know, it was never available online. I have a paper copy. r~
On Fri, Sep 2, 2016 at 7:17 PM, Richard Henderson <rth@twiddle.net> wrote: > On 09/02/2016 02:35 AM, Uros Bizjak wrote: >> --q-- >> /* Pass float and _Complex float variable arguments by reference. >> This avoids 64-bit store from a FP register to a pretend args save area >> and subsequent 32-bit load from the saved location to a FP register. >> >> Note that 32-bit loads and stores to/from a FP register on alpha reorder >> bits to form a canonical 64-bit value in the FP register. This fact >> invalidates compiler assumption that 32-bit FP value lives in the lower >> 32-bits of the passed 64-bit FP value, so loading the 32-bit value from >> the stored 64-bit location using 32-bit FP load is invalid on alpha. >> >> This introduces sort of ABI incompatibility, but until _Float32 was >> introduced, C-family languages promoted 32-bit float variable arg to >> a 64-bit double, and it was not allowed to pass float as a varible >> argument. Passing _Complex float as a variable argument never >> worked on alpha. Thus, we have no backward compatibility issues >> to worry about, and passing un-promoted _Float32 and _Complex float >> as a variable argument will actually work in the future. */ >> --/q-- > > This sounds like a good plan to me. Thanks! >> (I was not able to find the >> authoritative OSF/1 ABI document on the net...) > > As far as I know, it was never available online. > I have a paper copy. FYI, after some more involved deep searching (and luck ;) I found one at [1]. It is under "Programming Documentation Bookshelf" section, the document is called "Calling Standard for Alpha Systems" [2]. [1] http://h41361.www4.hpe.com/docs/pub_page/V51B_DOCS/v51b_doclist.htm [2] http://h41361.www4.hpe.com/docs/base_doc/DOCUMENTATION/V51B_ACRO_DUX/ARH9MCTE.PDF Uros.
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c index 702cd27..81cef4e 100644 --- a/gcc/config/alpha/alpha.c +++ b/gcc/config/alpha/alpha.c @@ -5754,8 +5754,29 @@ static bool alpha_pass_by_reference (cumulative_args_t ca ATTRIBUTE_UNUSED, machine_mode mode, const_tree type ATTRIBUTE_UNUSED, - bool named ATTRIBUTE_UNUSED) + bool named) { + /* Pass float and _Complex float variable arguments by reference. + This avoids 64-bit store from a FP register to a pretend args save area + and subsequent 32-bit load from the saved location to a FP register. + + Note that 32-bit loads and stores to/from a FP register on alpha reorder + bits to form a canonical 64-bit value in the FP register. This fact + invalidates compiler assumption that 32-bit FP value lives in the lower + 32-bits of the passed 64-bit FP value, so loading the 32-bit value from + the stored 64-bit location using 32-bit FP load is invalid on alpha. + + This introduces sort of ABI incompatibility, but until _Float32 was + introduced, C-family languages promoted 32-bit float variable arg to + a 64-bit double, and it was not allowed to pass float as a varible + argument. Passing _Complex float as a variable argument never + worked on alpha. Thus, we have no backward compatibility issues + to worry about, and passing unpromoted _Float32 and _Complex float + as a variable argument will actually work in the future. */ + + if (mode == SFmode || mode == SCmode) + return !named; + return mode == TFmode || mode == TCmode; }
Hello! I would like to propose an ABI adjustment for the aloha OSF/1 ABI. To quote explanation in the patch: --q-- /* Pass float and _Complex float variable arguments by reference. This avoids 64-bit store from a FP register to a pretend args save area and subsequent 32-bit load from the saved location to a FP register. Note that 32-bit loads and stores to/from a FP register on alpha reorder bits to form a canonical 64-bit value in the FP register. This fact invalidates compiler assumption that 32-bit FP value lives in the lower 32-bits of the passed 64-bit FP value, so loading the 32-bit value from the stored 64-bit location using 32-bit FP load is invalid on alpha. This introduces sort of ABI incompatibility, but until _Float32 was introduced, C-family languages promoted 32-bit float variable arg to a 64-bit double, and it was not allowed to pass float as a varible argument. Passing _Complex float as a variable argument never worked on alpha. Thus, we have no backward compatibility issues to worry about, and passing un-promoted _Float32 and _Complex float as a variable argument will actually work in the future. */ --/q-- Another rationale for the adjustment is, that "other" compilers do not know about _Float32 and _Complex float, the official ABI pre-dates some of these types by a decade or more (I was not able to find the authoritative OSF/1 ABI document on the net...), and lastly ... gcc is the last compiler that keeps this dead architecture alive, so IMO we can consider it as a de-facto implementer of the ABI. Following this ABI adjustment, we can also fix libffi, where libffi.complex/cls_complex_va_float.c says: --q-- /* Alpha splits _Complex into two arguments. It's illegal to pass float through varargs, so _Complex float goes badly. In sort of gets passed as _Complex double, but the compiler doesn't agree with itself on this issue. */ /* { dg-do run { xfail alpha*-*-* } } */ --/q-- 2016-09-02 Uros Bizjak <ubizjak@gmail.com> * config/alpha/alpha.c (alpha_pass_by_reference): Pass un-named SFmode and SCmode arguments by reference. Patch was bootstrapped and regression tested on alphaev68-linux-gnu for all default languages plus obj-c++ and go. Any comments? Uros.