On Thu, Apr 07, 2022 at 03:00:14PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 07, 2022 at 06:09:52AM -0500, Segher Boessenkool wrote:
> > On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote:
> > > As PR103623 shows, it's a regression failure due to new built-in
> > > function framework, previously we guard __builtin_{un,}pack_{longdouble,
> > > ibm128} built-in functions under hard float, so they are unavailable
> > > with the given configuration. While with new bif infrastructure, it
> > > becomes available and gets ICE due to incomplete supports.
> > >
> > > Segher and Peter pointed out that we should make them available with
> > > soft float, I agree we can extend them to cover both soft and hard
> > > float. But considering it's stage 4 now and this regression is
> > > classified as P1, also the previous behavior requiring hard float
> > > aligns with what document [1] says, I guess it may be a good idea to
> > > fix it with the attached small patch to be consistent with the previous
> > > behavior. Then we can extend the functionality in upcoming stage 1.
> >
> > Or you could just not take away the existing functionality.
>
> Have those builtins ever worked with 64-bit soft-float?
I thought they did right now, but apparently not :-(
> When I try e.g. gcc 11 on the #c0 testcase from the PR, I get:
> >From what I can see, those builtins were using:
Yes, and we fixed that bug.
Now everything is fine until the insn
(insn 6 5 8 2 (set (reg/v:DF 117 [ x0 ])
(unspec:DF [
(reg:TF 119)
(const_int 0 [0])
] UNSPEC_UNPACK_128BIT)) "103623.c":11:15 1067 {unpacktf_nodm}
(expr_list:REG_DEAD (reg:TF 119)
(expr_list:REG_EQUAL (unspec:DF [
(const_double:TF 1.152921504606846978e+18 [0x0.8000000000000
01p+61])
(const_int 0 [0])
] UNSPEC_UNPACK_128BIT)
(nil))))
no longer recognises during combine. It did in earlier passes, and
nothing changed as far as I can see. Pretty baffled.
Segher
