On Wed, 2020-11-18 at 01:03 -0500, Michael Meissner wrote: > On Tue, Nov 17, 2020 at 11:33:29PM -0600, will schmidt wrote: > > On Sun, 2020-11-15 at 12:23 -0500, Michael Meissner via Gcc-patches > > wrote: > > > PowerPC: Restrict long double test to use IBM long double. > > > > > > I posted this patch previously as a set of 3 testsuite > > > patches. I have > > > separated them into separate patches. This patch marks the > > > convert-bfp-11.c > > > patch as needing IBM extended double. If you look at the code, > > > it is > > > specifically designed around testing the limits of the IBM 128- > > > bit extended > > > double representation. I added a new target-supports that says > > > the test > > > requires IBM extended long double, and changed the test to > > > require this > > > effective test. Can I check this into the master branch? > > > > > > It's harder to review that without all the history handy here. > > > > This will stand alone better if you lead with what you are adding > > and > > keep it clean. i.e. > > The patch I was referring to was posted on October 22nd: > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556865.html > > > Subject: PowerPC: Add ppc_long_double_ibm effective-target check > > > > "Add a ppc_long_double_ibm dg-require-effective-target check to > > ensure > > tests that require LONG_DOUBLE_IBM128 . " > > An additional statement to clarify it's relationship with > > IEEEEEEEE128 > > wouldn't hurt if that is the case. i.e. > > "This is a counterpart to LONG_DOUBLE_IEEEEEEE 128 " > > At the moment, we don't need a target supports for long double IEEE > 128-bit or > long double 64-bit. I can add them if needed.
I would probably add one for each of the three so you have the complete picture of what is going on. > > > Hmm, I have those backwards in my head apparently. Can the return > > 1 if > > not-defined logic be flattened out so we see the direct > > relationship? > > I'm not sure what you are asking. These are preprocessor macros that > are only > defined in certain cases. And remember this is main returning a > value, so > returning 0 is true and 1 is false. > > In particular: > This: > If your long double is 128-bits and uses the IEEE 128-bit > representation, the > following macros are defined: > > __LONG_DOUBLE_128__ > __LONG_DOUBLE_IEEE128__ > > If your long double is 128-bit and uses the IBM 128-bit > representation (current > default0, the following macros are defined: > > __LONG_DOUBLE_128__ > __LONG_DOUBLE_IBM128__ > > If your long double is 64 bits, neither of those two macros are > defined. > .. clearly defines what is going on, and would be good to add as a comment in/around where the checks are defined. Thats my perspective of course,... :-) thanks -Will
