|
|
 Up |
|
|
  |
Author: James Van BuskirkJames Van Buskirk Date: Apr 26, 2008 13:43
I was writing some code with gfortran and found that spacing only
worked in initialization expressions. Doesn't anyone else use the
floating point manipulation functions in ordinary expressions and
specification expressions? Testing with gfortran I found that
RRSPACING, SCALE, SET_EXPONENT, and, SPACING were broken like this,
while EXPONENT, FRACTION, and NEAREST seemed to work:
C:\gfortran\james\archpi>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../../trunk/configure --prefix=/home/FX/irun64 --build=i586-pc-
mingw32 --target=x86_64-pc-mingw32 --with-gmp=/home/FX/local --enable-languages=
c,fortran --disable-werror --disable-nls --enable-threads
Thread model: win32
gcc version 4.4.0 20080421 (experimental) [trunk revision 134506] (GCC)
|
| Show full article (2.71Kb) |
|
| | 41 Comments |
|
|
Author: Steven G. KarglSteven G. Kargl Date: Apr 26, 2008 14:52
In article <6_6dnatLa7meCY7VnZ2dnUVZ_qiinZ2d@ comcast.com>,
"James Van Buskirk" comcast.net> writes:> I was writing some code with gfortran and found that spacing only
> worked in initialization expressions. Doesn't anyone else use the
> floating point manipulation functions in ordinary expressions and
> specification expressions? Testing with gfortran I found that
> RRSPACING, SCALE, SET_EXPONENT, and, SPACING were broken like this,
> while EXPONENT, FRACTION, and NEAREST seemed to work:
>
(snip)
|
| Show full article (1.60Kb) |
|
| | no comments |
|
|
|
|
|
Author: Steven G. KarglSteven G. Kargl Date: Apr 26, 2008 15:54
In article comcast.com>,
"James Van Buskirk" comcast.net> writes:> "Steven G. Kargl" troutmask.apl.washington.edu> wrote in message
> news:fv086u$roe$1@gnus01.u.washington.edu...
> >> Appears to work for me. Perhaps, it's an OS problem.
>
> Thank you for testing. Maybe an OS problem or a regression. What
> version are you using? I'm on 20080421.
On i386-*-freebsd, I have
mobile:kargl[203] gfc --version
GNU Fortran (GCC) 4.2.3 20080130 (prerelease)
On amd64-*-freebsd, I have
troutmask:kargl[201] gfc --version
GNU Fortran (GCC) 4.2.3 20071024 (prerelease)
and
troutmask:kargl[202] ../sgk/work/4x/bin/gfortran --version
GNU Fortran (GCC) 4.4.0 20080415 (experimental)
All versions give the same results.
|
| Show full article (3.67Kb) |
| no comments |
|
|
Author: AnonyAnony Date: Apr 26, 2008 16:25
"James Van Buskirk" comcast.net> wrote in message
news:6_6dnatLa7meCY7VnZ2dnUVZ_qiinZ2d@comcast.com...> I was writing some code with gfortran and found that spacing only
> worked in initialization expressions. Doesn't anyone else use the
> floating point manipulation functions in ordinary expressions and
> specification expressions? Testing with gfortran I found that
> RRSPACING, SCALE, SET_EXPONENT, and, SPACING were broken like this,
> while EXPONENT, FRACTION, and NEAREST seemed to work:
>
>
C:\gfortran\james\archpi>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran -v
> Using built-in specs.
> Target: x86_64-pc-mingw32
> Configured with:
> ../../trunk/configure --prefix=/home/FX/irun64 --build=i586-pc-
>
mingw32 --target=x86_64-pc-mingw32 --with-gmp=/home/FX/local --enable-langua
ges=
> c,fortran --disable-werror --disable-nls --enable-threads
> Thread model: win32 ...
|
| Show full article (3.42Kb) |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: Apr 26, 2008 19:10
"Anony" equation.com> wrote in message
news:9SOQj.2034$e26.671@trnddc02...
> On Windows, my result ( 4.4.0 20080425) is as: > C:\TEMP\fortran>a
> ulps1*spacing(x1) = 4.76837158E-07
> rrspacing(x1) = 13176795.
> scale(x1,ulps1) = 12.566371
> set_exponent(x1,ulps1) = 3.1415927
> ulps*spacing(x) = 4.76837158E-07
> rrspacing(x) = 13176795.
> scale(x,ulps) = 12.566371
> set_exponent(x,ulps) = 3.1415927
> size(j1) = 0
> size(j2) = 131
> size(j3) = 12
> size(j4) = 3
C:\gfortran\james\archpi>c:\gcc_equation\bin\x86_64-pc-mingw32-gfortran -v
Built by Equation Solution ( http://www.Equation.com).
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc...
|
| Show full article (2.48Kb) |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: Apr 26, 2008 19:55
"James Van Buskirk" comcast.net> wrote in message
news:QdCdnaPuP40qNo7VnZ2dnUVZ_hWdnZ2d@comcast.com...
> I ran into another problem that may be with the documentation.
Here's another item from the docs:
http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#Code-Gen-Options
"-frepack-arrays
In some circumstances GNU Fortran may pass assumed shape array
sections via a descriptor describing a noncontiguous area of memory.
This option adds code to the function prologue to repack the data
into a contiguous block at runtime.
This should result in faster accesses to the array. However it can
introduce significant overhead to the function call, especially when
the passed data is noncontiguous."
It is not mentioned here that this is one of the options that makes
the program behave contrary to the standard:
|
| Show full article (2.23Kb) |
| no comments |
|
|
Author: Tobias BurnusTobias Burnus Date: Apr 27, 2008 01:25
On Apr 27, 4:55 am, "James Van Buskirk" comcast.net> wrote:> "James Van Buskirk" comcast.net> wrote in messagenews:QdCdnaPuP40qNo7VnZ2dnUVZ_hWdnZ2d@comcast.com...
> "-frepack-arrays
>
> It is not mentioned here that this is one of the options that makes
> the program behave contrary to the standard:
Confirmed. The problem is that in the function "point" a temporary
array is created to contain the repacked data of the dummy argument
"x". Thus, the pointer points to the temporary array and not to the
dummy array.
Solution: Do not repack dummy arguments with the TARGET attribute. I
filled now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36059
Thanks for the bug report. (Maybe I should re-read at some point the
gfortran documentation, there are options I have never heard of.)
Tobias
|
| |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: Apr 27, 2008 02:32
> Confirmed. The problem is that in the function "point" a temporary
> array is created to contain the repacked data of the dummy argument
> "x". Thus, the pointer points to the temporary array and not to the
> dummy array.
I think that both the actual argument and the dummy argument must
have the target attribute for a problem to arise. If the actual
argument doesn't have the target attribute any pointers that think
they are associated with it have in fact undefined association
status, and same for the dummy. Since the interface must be explicit
if the dummy argument has the target attribute (N1601.pdf, section
12.3.1.1 (2)(a)) the compiler knows when it is deciding whether to
repack the array (i.e. when compiling the caller) whether or not
both actual and dummy arguments have the target attribute.
|
| Show full article (1.69Kb) |
| no comments |
|
|
|
|
|
Author: AnonyAnony Date: Apr 27, 2008 05:34
"James Van Buskirk" comcast.net> wrote in message
news:eZudnecxz7swfY7VnZ2dnUVZ_remnZ2d@comcast.com...>
>
> So I presume your test was carried out on 32-bit Windows. As you
> can see, same date build fails on 64-bit Windows. I recall that in
> the earliest versions of gfortran for 64-bit Windows, all the single
> precision intrinsics were missing. This may be a continuation of
> that problem, but now for a subset of intrinsics rather than a
> subset of KINDs. Steven Kargl's intuition about platform specificity
> seems to have been accurate.
>
Yes. I was on 32-bit windows when I copied and pasted your program. Sorry,
not to see you are on win64.
It is nice to know there are people working on win64. Win64 seems not ready
yet. There are some problems, even affecting binutuls. RANLIB and AR also
have problem (It cannot be reproduced everytime.). There was one user who
complined "hang forever" without providing a code example (I never
eperienced the problem, and I have no idea).
|
| |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
