re: strange gfortran problem

[Sean Farley]

(cc'ing macports-dev)

> The problem is actually with MacPorts 4.3.2. A little more accurately, this 
> is NOT an actual bug. The problem is that the behavior you are seeing is 
> allowed under the Fortran standard -- that's why selected_int_kind exists in 
> the first place.

This is wrong. The Fortran standard, and in particular gfortran, call
for the *smallest* integer type:

http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fINT_005fKIND.html

For selected_int_kind(5), this *must* be INTEGER*4 (4 bytes = 32 bits;
pow(2,32)/2-1 will suffice 5 for digits)

> I had to issue a patch for a piece of software that used 
> selected_real_kind(), but assumed that it would always return 8 as used. From 
> all the searching I did, I found that this behavior was perfectly within the 
> Fortran standard, and that we had to become compliant with it.
>
> My suggestion is to avoid roll-your-own precision to avoid problems like 
> this. If you need to use it, make sure you always use the enquiry intrinsics 
> (selected_real_kind and selected_int_kind), and never assume it will take a 
> particular value.

That's what this piece of software does, actually (uses select_*_kind).

> To reiterate, this behavior ONLY arose when I built all my ports with Xcode 
> 4.3.2, and never with older Xcodes (that is, if I built gcc4x with Xcode 
> 4.3.2, it would happen regardless of which FCC I built).
>
> I agree the behavior differs in my experiences with Linux, but there are 
> other OSes and compilers that behave differently as well (or so I read)

There is a bug here but it's not with gcc / gfortran. It appears to be
gmp; and it seems to occur when missing the 10.6 sdk. I don't know why
it happens, but that look like the common failure (i.e. using
MacPorts's gmp generated from the buildbot will expose this bug). Or
it could be the +universal logic in the gmp Portfile.

For my machine, I have the 10.6 sdk so I needed to uninstall gmp and
build it from source (using the -s option):

$ sudo port uninstall --follow-dependents gmp
$ sudo port -vs install gcc47 (or gcc46, gcc48; all gcc ports
experience this bug with gmp)

This really, *really* needs to be fixed on the buildbot. Is there any
particular reason the buildbot doesn't have the 10.6 SDK? The test
case is easy to see with Victor's attached fortran test (which I
reattached to this email). The output should be:

$ ./a.out
 int4:4
 int8:8

Are there any other macport devs that can test building gmp / gcc47 on
their local machine to see if the output matches (e.g. just run my two
above command that uninstalls gmp and its dependents, then install
gcc47 and its dependencies from source)?

Also, it would be nice if all compilers included their debug symbols
(i.e. run dsymutil *.dylib in the destroot phase) which I put a patch
here:

https://trac.macports.org/attachment/ticket/33821/base-create-dsym.patch

This would stop millions of warnings when using gdb with *anything*
compiled by one of the compilers provided by MacPorts. The impact of
including the .dSYM files is extremely low but saves so much
frustration on the users.


sizeof-ftn.f90
Description: Binary data
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: strange gfortran problem

[Frédéric Dubois]

Hello,
I don't understand the last comment of this mail.
Following IBM link its said:


   Examples

SELECTED_INT_KIND (9) has the value 4, signifying that an INTEGER with 
kind type 4 can represent all values from 10^-9 to 10^9 .




Regards

Le 27/04/12 08:02, Brandon Allbery a écrit :
On Fri, Apr 27, 2012 at 01:14, Victor Eijkhout 
mailto:eijkh...@tacc.utexas.edu>> wrote:


On Apr 26, 2012, at 11:22 PM, Jason Swails wrote:
> The problem is that the behavior you are seeing is allowed under
the Fortran standard

I'll take your word for it. I ran into this when I compiling some
software that used kind(5) as a synonym for INTEGER*4 (after all,
32k is 5 digits) and such, and I was getting type errors.


IBM claims: 
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.xlf101l.doc%2Fxlflr%2Fintkind.htm


*SELECTED_INT_KIND(R)*

Returns a value of the kind type parameter of an integer data type 
that represents all integer values n with -10^R < n < 10^R .


Neither -99,999 nor 99,999 fit in INTEGER*4.

--

brandon s allbery allber...@gmail.com 
wandering unix systems administrator (available) (412) 475-9364 vm/sms



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


--
Frédéric Dubois, Eng, PhD
LMGC - UMR CNRS 5508
Université de Montpellier 2, cc 048
Place Eugène Bataillon
34095 Montpellier Cedex 05
Tel 33/0 467144984 - Fax 33/0 467143923
http://www.lmgc.univ-montp2.fr/~dubois
http://www.lmgc.univ-montp2.fr/~dubois/LMGC90

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: strange gfortran problem

[Brandon Allbery]

On Fri, Apr 27, 2012 at 01:14, Victor Eijkhout wrote:

> On Apr 26, 2012, at 11:22 PM, Jason Swails wrote:
> > The problem is that the behavior you are seeing is allowed under the
> Fortran standard
>
> I'll take your word for it. I ran into this when I compiling some software
> that used kind(5) as a synonym for INTEGER*4 (after all, 32k is 5 digits)
> and such, and I was getting type errors.
>

IBM claims:
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.xlf101l.doc%2Fxlflr%2Fintkind.htm

*SELECTED_INT_KIND(R)*

Returns a value of the kind type parameter of an integer data type that
represents all integer values n with -10R < n < 10R.

Neither -99,999 nor 99,999 fit in INTEGER*4.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: strange gfortran problem

[Victor Eijkhout]

On Apr 26, 2012, at 11:22 PM, Jason Swails wrote:

> The problem is that the behavior you are seeing is allowed under the Fortran 
> standard

I'll take your word for it. I ran into this when I compiling some software that 
used kind(5) as a synonym for INTEGER*4 (after all, 32k is 5 digits) and such, 
and I was getting type errors.

I'll pass on your information to the authors.

Victor.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: strange gfortran problem

[Jason Swails]

The problem is actually with MacPorts 4.3.2. A little more accurately, this is 
NOT an actual bug. The problem is that the behavior you are seeing is allowed 
under the Fortran standard -- that's why selected_int_kind exists in the first 
place. 

I had to issue a patch for a piece of software that used selected_real_kind(), 
but assumed that it would always return 8 as used. From all the searching I 
did, I found that this behavior was perfectly within the Fortran standard, and 
that we had to become compliant with it. 

My suggestion is to avoid roll-your-own precision to avoid problems like this. 
If you need to use it, make sure you always use the enquiry intrinsics 
(selected_real_kind and selected_int_kind), and never assume it will take a 
particular value. 

To reiterate, this behavior ONLY arose when I built all my ports with Xcode 
4.3.2, and never with older Xcodes (that is, if I built gcc4x with Xcode 4.3.2, 
it would happen regardless of which FCC I built). 

I agree the behavior differs in my experiences with Linux, but there are other 
OSes and compilers that behave differently as well (or so I read). 

HTH,
Jason

--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032

On Apr 26, 2012, at 11:23 PM, Victor Eijkhout  wrote:

> 
> On Apr 26, 2012, at 9:58 PM, Ryan Schmidt wrote:
> 
>> Test with gcc47 and gcc48
> 
> I did, at least version 4.8. But the problem is that it behaves differently 
> with MacPorts than the gcc distribution on Linux, so the package maintainer 
> for gcc might know more about it.
> 
> Victor.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: strange gfortran problem

[Victor Eijkhout]

On Apr 26, 2012, at 9:58 PM, Ryan Schmidt wrote:

> Test with gcc47 and gcc48

I did, at least version 4.8. But the problem is that it behaves differently 
with MacPorts than the gcc distribution on Linux, so the package maintainer for 
gcc might know more about it.

Victor.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: strange gfortran problem

[Ryan Schmidt]

On Apr 26, 2012, at 20:02, Victor Eijkhout wrote:

> this may be more suited for the dev list….

I think we're probably not fortran experts here; you may have to ask the 
developers of gcc instead. Test with gcc47 and gcc48 first of course to make 
sure it's not a problem they've already fixed.


> I have a  small fortran program that gives different (read: wrong) output on 
> macports from on linux.
> 
> [albook:~/Current/petsc-course/course20120514/fsolutions] %% gfortran 
> --version
> GNU Fortran (GCC) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> 
> GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute copies of GNU Fortran
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING
> 
> [albook:~/Current/petsc-course/course20120514/fsolutions] %% gfortran 
> sizeof.f 
> [albook:~/Current/petsc-course/course20120514/fsolutions] %% a.out
> int4:8
> int8:   16
> ### that should be 4 & 8
> [albook:~/Current/petsc-course/course20120514/fsolutions] %% cat sizeof.f 
>   program main
>   integer(kind=selected_int_kind(5)) a
>   integer(kind=selected_int_kind(10)) b
>   write(*,*) 'int4:',sizeof(a)
>   write(*,*) 'int8:',sizeof(b)
>   end
> [albook:~/Current/petsc-course/course20120514/fsolutions] %% which gfortran 
> /opt/local/bin/gfortran
> [albook:~/Current/petsc-course/course20120514/fsolutions] %% ls -l `!!`
> ls -l `which gfortran `
> lrwxr-xr-x  1 root  admin  30 Apr 26 19:44 /opt/local/bin/gfortran@ -> 
> /opt/local/bin/gfortran-mp-4.6



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users