Hi!
On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote:
> One additional point. The linker does not understand
> -mno-gnu-attribute:
That is a GCC option, not an ld one. If you use it to compile some
file there will be no .gnu.attributes section generated for that
translation unit.
Hi Piotr,
On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote:
> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
Declared, not defined. These are required to be real functions (on all
platforms that have these functions), not macros or inlines or whatever.
So what
On Fri, May 13, 2022 at 12:34:05PM +0200, Piotr Kubaj wrote:
> On 22-05-13 10:59:59, Kewen.Lin wrote:
> > on 2022/5/13 04:16, Segher Boessenkool wrote:
> > > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote:
> > >> FreeBSD/powerpc* has feenableexc
On Thu, Sep 01, 2022 at 10:19:59AM +0200, Jakub Jelinek via Gcc wrote:
> On Thu, Sep 01, 2022 at 10:04:58AM +0200, FX wrote:
> > 2. All the functions are available as GCC type-generic built-ins (yeah!),
> > except there is no __builtin_ iseqsig
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=779
On Wed, May 19, 2021 at 02:32:02PM +0200, Tobias Burnus wrote:
> Regarding gfortran.dg/pr96711.f90:
>
> On my x86-64-gnu-linux, it PASSes.
> On our powerpc64le-linux-gnu it FAILS with
> 'STOP 3' (→ also scan-dump count) and 'STOP 4'.
>
> Contrary to PR96983's bug summary, I don't get an ICE.
>
>
Hi!
On Wed, May 19, 2021 at 08:35:26PM +0200, Tobias Burnus wrote:
> On 19.05.21 17:15, Segher Boessenkool wrote:
> >>real(16) :: y ! 128bit REAL
> >>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
> >>
Hi!
On Tue, Aug 10, 2021 at 10:29:08AM +0200, Tobias Burnus wrote:
> On 09.08.21 23:42, Sandra Loosemore wrote:
> In terms of Fortran, REAL types do not need to follow IEEE
> (there are IEEE intrinsic modules to handle IEEE); thus, REAL(16)
> does not need to be an IEEE type – albeit most users im
Hi!
On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
> OK. I used your wording verbatim for the first one. For the second
> one, I'm still pretty confused as I think it is at least theoretically
> possible on PowerPC to have a target with 64-bit long double (AIX?) that
Some
Hi!
On Wed, Aug 11, 2021 at 12:29:06PM +0100, Iain Sandoe wrote:
> > On 11 Aug 2021, at 11:55, Segher Boessenkool
> > wrote:
> > On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
> >> OK. I used your wording verbatim for the first one. For the
Hi!
On Mon, Oct 04, 2021 at 04:14:10PM +0200, Jakub Jelinek wrote:
> Based on some IRC discussion, yet another option would be bump libgfortran
> SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
> always IEEE quad (starting with GCC 12) and if wanted add support for
> real(kind
Hi Joseph,
On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote:
> On Mon, 4 Oct 2021, Segher Boessenkool wrote:
> > Some current Power GCC targets support neither. Some support only
> > double-double. Making IEEE QP float work on those (that is, those that
> &g
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
> On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
> >Based on some IRC discussion, yet another option would be bump libgfortran
> >SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
> >always IEEE quad (starti
On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> On 05.10.21 23:54, Segher Boessenkool wrote:
> >>There is also the issue of binary data. If some user has written
> >>out data in double double and wants to read it in as IEEE quad,
> >>the results are
On Wed, Oct 06, 2021 at 05:41:07PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > >That means flipping the default on all PowerPC to no longer be double-
On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> wrote:
> >
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >
On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example). This can
> > magically make -msoft-float work as well everywhere, btw.
>
> E
On Wed, Oct 06, 2021 at 07:07:43PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
>
On Wed, Oct 06, 2021 at 05:13:59PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:
> > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > We can emulate it everywhere (using libquadmath for example). This can
> > >
On Wed, Oct 06, 2021 at 07:42:31PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > Soft float is not described in any formal ABI btw (well, except the
> > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
>
> It's fully
On Wed, Oct 06, 2021 at 10:03:59PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > With "not in any" I mean: not for other architectures either! All archs
> > that do not say anything about floating point in their machine
> > de
On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >>
Hi!
On Mon, Oct 11, 2021 at 08:11:50PM +, Joseph Myers wrote:
> On Fri, 8 Oct 2021, Segher Boessenkool wrote:
> > But many CPUs do not have hardware floating point in any variant, and
> > their ABIs / calling conventions do not mention floating point at all.
> > Still
On Thu, Oct 14, 2021 at 02:39:47PM -0500, Bill Schmidt wrote:
> On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> > The last release (version 1.9) was in 2004. If there is interest in
> > making updates to it that coulde be done of course, it is GFDL, there is
> > no red ta
On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote:
> If we do implement double-double support, I think KIND=15 would be better
> than KIND=17, it is true that double-double has for certain numbers much
> higher precision than IEEE quad, but the precision depends on the numbers
> and mos
Thank you for writing this out Bill!
On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote:
> Longer term, we have the question of supporting more Power targets. AIX will
> continue to
> use only double-double.
Yes. So it will be virtually no cost to continue supporting
double-double on
On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
> > I assume we would to the development on a branch. My git fu
> > is extremely weak, so I would appreciate if somebody did that
> > for me.
>
> Sure, we can create an IBM vendor branch.
It should not be an IBM branch, we should
On Fri, Nov 19, 2021 at 01:36:33PM -0600, Peter Bergner wrote:
> On 11/19/21 1:09 PM, Thomas Koenig wrote:
> >> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
> >>> Sure, we can create an IBM vendor branch.
> >>
> >> It should not be an IBM branch, we should not mix that with com
27 matches
Mail list logo
