[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

2016-09-21 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Jerry DeLisle  ---
(In reply to Steve Kargl from comment #5)
> On Wed, Sep 21, 2016 at 04:25:00PM +, jvdelisle at gcc dot gnu.org wrote:
> > 
> > I will try to study the script some more later today. Changing status to
> > unconfirmed while we look into this a bit.
> > 
> 
> I closed this bug a long time ago, because the initial report
> indicated that OP was not using GCC sources.  OP is using 
> something supplied by Google for Android.  This is not a 
> gfortran problem.

Yes Steve understood. Will take this off line. I am more curious than anything
else. I have an Android tablet that I am fiddling with.

[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

2016-09-21 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #4 from Jerry DeLisle  ---
(In reply to Paul Mustiere from comment #3)
---snip---
> 
> The issue being that long double = double in this case.
> 
> When kind=16 match in C is defined, there's the check:
> 16) if [ $long_double_kind -eq 10 ]; then
> 
> Could it be that kind=16 should be match to __float128,
> and the check should be $long_double_kind -neq 16?

kind=16 is float128.  So something wrong if long double = double

I will try to study the script some more later today. Changing status to
unconfirmed while we look into this a bit.

[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

2016-09-21 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

--- Comment #5 from Steve Kargl  ---
On Wed, Sep 21, 2016 at 04:25:00PM +, jvdelisle at gcc dot gnu.org wrote:
> 
> I will try to study the script some more later today. Changing status to
> unconfirmed while we look into this a bit.
> 

I closed this bug a long time ago, because the initial report
indicated that OP was not using GCC sources.  OP is using 
something supplied by Google for Android.  This is not a 
gfortran problem.

[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

2016-09-21 Thread paul.mustiere at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

--- Comment #3 from Paul Mustiere  ---
In the script:
possible_real_kinds="4 8 10 16" i.e. it tries them all

In the for loop, when it tries to compile the dummy Fortran program to check
each kind=k existance, only 4, 8 & 16 exists.

kind=4 is defined as float,
kind=8 is defined as double,
kind=16 is defined as long double.

The issue being that long double = double in this case.

When kind=16 match in C is defined, there's the check:
16) if [ $long_double_kind -eq 10 ]; then

Could it be that kind=16 should be match to __float128,
and the check should be $long_double_kind -neq 16?

[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

2016-09-21 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
(In reply to Paul Mustiere from comment #0)
> Hello,
> 
> I am building the GNU toolchain for Android with support for Fortran, and
> encountered an issue when targeting x86 for the runtime library.
> 
> Note: I'm using the toolchain sources provided by Google, but as far as I
> can tell the Fortran part is simply 4.9 since they are not trying to build
> with Fortran.
> 
> In intrisics/cshift0.c, I get a 'duplicate case value'
> (http://paste.ubuntu.com/16861425/). As far as I can tell:
> 
> - GFC_DTYPE_REAL_16 is defined (but not GFC_DTYPE_REAL_10), hence
> GFC_REAL_16 is defined as long double.
> - sizeof(long double) = sizeof(double) = 8, which causes the duplicate case.
> 
> I find a workaround which consists of detecting both sizes in mk-kinds-h.sh
> and checking that they are not equal before defining GFC_REAL_16. The rest
> of the toolchain compiles fine, but I am not sure it's ideal.
> Also, I'm curious as to why Fortran seems to be fine with real (kind=16) but
> C doesn't seem to be able to hold variables that big.
> 
> I know I'm not using the regular GNU toolchain but any help is appreciated.
> 
> Cheers,
> Paul Mustiere

Paul,

Look for where "for k in $possible_real_kinds" is in the mk-kinds script. Where
is $possible_real_kinds set?

[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

2016-06-01 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Paul Mustiere from comment #0)
> Hello,
> 
> I am building the GNU toolchain for Android with support for Fortran, and
> encountered an issue when targeting x86 for the runtime library.
> 
> Note: I'm using the toolchain sources provided by Google, but as far as I
> can tell the Fortran part is simply 4.9 since they are not trying to build
> with Fortran.
> 
> In intrisics/cshift0.c, I get a 'duplicate case value'
> (http://paste.ubuntu.com/16861425/). As far as I can tell:
> 
> - GFC_DTYPE_REAL_16 is defined (but not GFC_DTYPE_REAL_10), hence
> GFC_REAL_16 is defined as long double.
> - sizeof(long double) = sizeof(double) = 8, which causes the duplicate case.
> 
> I find a workaround which consists of detecting both sizes in mk-kinds-h.sh
> and checking that they are not equal before defining GFC_REAL_16. The rest
> of the toolchain compiles fine, but I am not sure it's ideal.
> Also, I'm curious as to why Fortran seems to be fine with real (kind=16) but
> C doesn't seem to be able to hold variables that big.
> 
> I know I'm not using the regular GNU toolchain but any help is appreciated.
> 
> Cheers,
> Paul Mustiere

Unless you can reproduce the problem with sources from head (aka 7.0),
the 6-branch, or 5-branch, I afraid you are on your own.  If you can
reproduce the problem with "official" source feel free to re-open the
bug report.