On Wed, Mar 09, 2022 at 10:10:07PM +0100, Jakub Jelinek wrote: > On Wed, Mar 09, 2022 at 02:57:20PM -0600, Segher Boessenkool wrote: > > But __ibm128 should *always* be supported, so this is a hypothetical > > problem. > > I bet that will require much more work. I think for the barely supported > (or really unsupported?) case of old sysv IEEE quad
The "q" library routines are double-double. On RIOS2 (POWER2) there were "quad" instructions that worked on a pair of FP regs, but that was handled as a pair of FP regs, and since 2012 we do not support POWER2 anymore anyway. I have no clue if and when the "q_" library routines are used. The do take KFmode params (or TFmode if we use double-double preferably). Or are you thinking of something else still? > or for when long double > is just DFmode we'd need some more (IFmode?) for __ibm128 and deal with > everything it needs (mapping it to libgcc entrypoints etc.). Well, the symbols would be called "tf", as all __ibm128 symbols are, for backwards compatibility; all __ieee128 are "kf", no matter what. This is much simpler than the mess we have with internal modes :-) It also is no big deal if you get link errors for missing libraries if you try to use an unsupported configuration. All the basic stuff will still work. This is similar in ways to what happens if you try to use too old system libraries, or a too old binutils. > > If you are fed up with all this, please commit what you have now (after > > testing of course ;-) ), and I'll pick up things myself. Either way, > > thank you for all your work on this! > > Ok, here is what I'll test momentarily: Thanks again! Segher
