On Sat, 23 Jun 2018, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 10:43:16PM +, Joseph Myers wrote:
> > On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> >
> > > The comment doesn't make much sense. If long double is IBM, the long
> > > double complex mode is ICmode, not KCmode. "To g
On Fri, Jun 22, 2018 at 05:04:14PM -0400, Michael Meissner wrote:
> Here is the patch redone to disable multilib support altogether. I verified
> that without --{enable,disable}-multilib that it no longer builds a multilib
> compiler. Can I install this into the trunk and to the GCC 8.x branch?
On Thu, Jun 21, 2018 at 07:11:37PM -0400, Michael Meissner wrote:
> On Thu, Jun 21, 2018 at 06:07:36PM -0500, Segher Boessenkool wrote:
> > On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> > > This patch fixes the tests in the testsuite that implicitly were
> > > expecting long
On Thu, Jun 21, 2018 at 10:43:16PM +, Joseph Myers wrote:
> On Thu, 21 Jun 2018, Segher Boessenkool wrote:
>
> > The comment doesn't make much sense. If long double is IBM, the long
> > double complex mode is ICmode, not KCmode. "To get the IEEE128 complex
> > type", perhaps? And can't you
On Thu, Jun 21, 2018 at 02:22:50PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 01:26:19PM -0400, Michael Meissner wrote:
> > On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> > > > * config.gcc (powerpc64le*): Remove multilib support for IEEE
> > > > and
On Thu, Jun 21, 2018 at 06:12:52PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:49:41AM -0400, Michael Meissner wrote:
> > These patches fix the tests in the testsuite that check whether
> > -mno-float128
> > works properly. In these cases, I explicitly run them with long double
On Wed, Jun 20, 2018 at 10:49:41AM -0400, Michael Meissner wrote:
> These patches fix the tests in the testsuite that check whether -mno-float128
> works properly. In these cases, I explicitly run them with long double being
> set to IBM extended double.
So what happened without this patch?
Seg
On Thu, Jun 21, 2018 at 06:07:36PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> > This patch fixes the tests in the testsuite that implicitly were expecting
> > long
> > double to be IBM extended double to use __ibm128 if long double is
>
On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> This patch fixes the tests in the testsuite that implicitly were expecting
> long
> double to be IBM extended double to use __ibm128 if long double is configured
> to be IEEE 128-bit floating point.
And just always using __ibm128
On Thu, Jun 21, 2018 at 05:18:19PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:42:38AM -0400, Michael Meissner wrote:
> > This patch prevents the special overriding of the complex float128
> > multiply/divide functions from being run twice if there are clone or target
> > attribut
On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> The comment doesn't make much sense. If long double is IBM, the long
> double complex mode is ICmode, not KCmode. "To get the IEEE128 complex
> type", perhaps? And can't you do _Complex __ieee128 or such?
You can do _Complex _Float128, in C only
On Wed, Jun 20, 2018 at 10:46:04AM -0400, Michael Meissner wrote:
> This patch fixes a thinko that I had that prevented negation of __ibm128
> values
> if long double is IEEE 128-bit binary floating point.
>
> I have checked this on a little endian power8 system with builds where the
> long
> do
On Wed, Jun 20, 2018 at 10:42:38AM -0400, Michael Meissner wrote:
> This patch prevents the special overriding of the complex float128
> multiply/divide functions from being run twice if there are clone or target
> attributes. I wasn't aware that the hook used to initialize the built-in
> function
On Thu, Jun 21, 2018 at 04:25:29PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 20, 2018 at 10:32:06AM -0400, Michael Meissner wrote:
> > In reworking the ordering of the 128-bit floating point modes (June 18th,
> > 2018
> > patch), I missed one conversion insn. This meant the compiler
On Wed, Jun 20, 2018 at 10:38:10AM -0400, Michael Meissner wrote:
> This patch fixes the tests that use IEEE 128-bit float complex to use long
> double _Complex on systems where the default is IEEE 128-bit. Due to needing
> to use the same internal type for long double and __float128 (to get the
>
Hi!
On Wed, Jun 20, 2018 at 10:32:06AM -0400, Michael Meissner wrote:
> In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
> patch), I missed one conversion insn. This meant the compiler would generate
> a
> conversion to using the IF name.
Is there some existing tes
On Thu, Jun 21, 2018 at 01:26:19PM -0400, Michael Meissner wrote:
> On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> > > * config.gcc (powerpc64le*): Remove multilib support for IEEE and
> > > IBM long double.
> > > * config/rs6000/rs6000.c (rs6000_option_override_interna
On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 12:58:06PM -0400, Michael Meissner wrote:
> > On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> > > On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > > > This code d
On Thu, Jun 21, 2018 at 12:58:06PM -0400, Michael Meissner wrote:
> On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> > On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > > This code disables the automatic multilib creation unless you use the
> > > --with-adva
On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > This code disables the automatic multilib creation unless you use the
> > --with-advance-toolchain= option and the Advance Toolchain directoy has
> > been modi
On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> This code disables the automatic multilib creation unless you use the
> --with-advance-toolchain= option and the Advance Toolchain directoy has
> been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> multili
This patch fixes the tests in the testsuite that implicitly were expecting long
double to be IBM extended double to use __ibm128 if long double is configured
to be IEEE 128-bit floating point.
Note, test pr70117.c will still fail due to bugs in isnormal code generation
for __ibm128. However, expl
These patches fix the tests in the testsuite that check whether -mno-float128
works properly. In these cases, I explicitly run them with long double being
set to IBM extended double.
I have tested these on a little endian power8 system using two builds with long
double being set to IEEE and IBM 1
This patch fixes a thinko that I had that prevented negation of __ibm128 values
if long double is IEEE 128-bit binary floating point.
I have checked this on a little endian power8 system with builds where the long
double is set to IEEE and IBM 128-bit binary floating point, and it fixes some
tests
This patch prevents the special overriding of the complex float128
multiply/divide functions from being run twice if there are clone or target
attributes. I wasn't aware that the hook used to initialize the built-in
functions is run each time you change the target options. The built-in
function h
This patch fixes the tests that use IEEE 128-bit float complex to use long
double _Complex on systems where the default is IEEE 128-bit. Due to needing
to use the same internal type for long double and __float128 (to get the
mangling correct and make templates work), you can't really use KF or KC
In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
patch), I missed one conversion insn. This meant the compiler would generate a
conversion to using the IF name.
I have tested this on a little endian power8 system with long double set to
IEEE 128-bit and IBM extended,
When we started down the road of transitioning long double to IEEE 128-bit, we
thought the only way to do it was to add multi-lib support. Since then with
work underway in both GLIBC and libstdc++ we no longer feel that we need to use
multilibs.
The code as it is now for GCC 8.x and trunk will au
I'm going to post long double transition fixes that fix most of the problems
when you switch the long double format as follow-ups to this message. A few of
the fixes to the tests were previously posted, but I've added some comments.
Here are the remaining failures in the C/C++ tests after these p
29 matches
Mail list logo
