https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #23 from bernd.eggen at gmail dot com ---
Many thanks Tobias, noted - bw, Bernd
On Thu, 20 May 2021 at 09:12, burnus at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
>
> Tobia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #21 from anlauf at gcc dot gnu.org ---
Please see PR96983 for the fallout.
Note that my bandaid fix was rejected in favor of a "real solution" for
powerpc*. See the other PR and the Fortran ML for background.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #20 from Andreas Schwab ---
Any ICE is a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #19 from kargl at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #18)
> Any ICE is a bug.
If powerpc64 does not have REAL(16), then you'll need
to xfail the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #18 from Andreas Schwab ---
Any ICE is a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #17 from Steve Kargl ---
On Wed, Oct 07, 2020 at 07:19:18AM +, sch...@linux-m68k.org wrote:
>
> --- Comment #16 from Andreas Schwab ---
> On powerpc64:
>
> FAIL: gfortran.dg/pr96711.f90 -O0 (internal compiler error)
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #16 from Andreas Schwab ---
On powerpc64:
FAIL: gfortran.dg/pr96711.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/pr96711.f90 -O0 (test for excess errors)
Excess errors:
f951: internal compiler error: Could not find real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #15 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:9164caf25cb210ad0a69357b226e39913aff00d1
commit r11-3042-g9164caf25cb210ad0a69357b226e39913aff00d1
Author: Harald Anlauf
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #13 from Steve Kargl ---
On Thu, Aug 20, 2020 at 03:54:44PM +, bre08 at eggen dot co.uk wrote:
>
> PS (and maybe I need to post this separately as a suggestion) - will
> there be a fast "octuple-precision floating point / integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #12 from B Eggen ---
Thanks for your explanations, and for reminding me of the excellent library etc
by David Bailey. My original quest was to have a fast method to decide for
large integers quickly whether they are perfect squares.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #11 from Steve Kargl ---
On Thu, Aug 20, 2020 at 01:47:58PM +, bre08 at eggen dot co.uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
>
> --- Comment #10 from B Eggen ---
> I've been experimenting with the suggeste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #10 from B Eggen ---
I've been experimenting with the suggested work-around
m = anint(y)
This works for larger numbers, even in quad precision, however, it breaks down
a long way before the integer*16 range is exhausted, consider th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #9 from Steve Kargl ---
On Wed, Aug 19, 2020 at 09:36:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
>
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> A very quick hack seems t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #8 from anlauf at gcc dot gnu.org ---
A very quick hack seems to solve the issue for me. For some reason the
final fold_convert seems to create a problem. Does anybody know why?
It there a shorter solution?
diff --git a/gcc/fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
Toon Moene changed:
What|Removed |Added
CC||toon at moene dot org
--- Comment #7 from T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #5 from kargl at gcc dot gnu.org ---
Trivial workaround.
program nint_error
implicit none
integer(kind=16) :: m
real(8) :: x, y
x = 1
y = x - 1
m = anint(y)
print *, m
end
This will use libqu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #3 from B Eggen ---
Here is the latest f90 file:
program nint_error
integer :: n, m
integer(kind=16) :: i, j, nint
integer, parameter :: idp=selected_real_kind(9,99)
integer, parameter :: i16=selected_int_kind(38)
real(k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #2 from B Eggen ---
adding the compiler flag -fdefault-integer-8 extends the range somewhat, but I
really require NINT() to work for whole range (up to 2^127-1):
-> ./nint_error.e
i16= 16 170141183460469231731687303715884105727
1 1 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
B Eggen changed:
What|Removed |Added
CC||bre08 at eggen dot co.uk
--- Comment #1 from B
24 matches
Mail list logo
