Prev: The Fortran 2003 Handbook
Next: WatFor77 -- Re: Command-line argument capture
From: paul.richard.thomas on 17 Dec 2008 09:32
George,

> I think 'twixt has to be 'mong here.:-)  I see on the mailing list how

Betwixt == 'twixt == "prep. and adv. archaic between. [Old English
betweox, from Germanic]." I guess that I like my Shakespeare too
much:-)

> active Tobias is in this effort.  I guess the thing I wonder is how you
> know the patch you're nailing on won't puncture the plumbing.

Our testsuite is updated with every patch to exclude (in principle!)
the possibility of the carpet getting wet. This does not always work
but we are currently down to two regressions, one of which is on
performance and anothre for something that has never really worked
correctly in gfortran.

In detail, we use DejaGnu to check that the testcases do as expected
and that the bugs are really fixed. DejaGnu directives are added to
the testcases to check for compilation messages or the content of a
code dump and to run the produced code with different levels of
optimization and check the output. You can find the gfortran
testsuite as subdirectories in ~/gcc/testsuite. There are also fortran
testcases in the omp and vector testsuites. At present, there are
~30000 tests.

At various times it has been suggested that we have a bottom-up
testsuite that starts with the standard and tests it from start to
finish. We do not have the effort for such a thing.

As for the triage: Check out http://gcc.gnu.org/wiki/GFortran under
the heading "For gfortran developers".

Cheers

Paul
From: James Van Buskirk on 17 Dec 2008 13:45
<paul.richard.thomas(a)gmail.com> wrote in message
news:745a7743-9143-4b4c-8720-d46fd1c68027(a)d42g2000prb.googlegroups.com...

> Our testsuite is updated with every patch to exclude (in principle!)
> the possibility of the carpet getting wet. This does not always work
> but we are currently down to two regressions, one of which is on
> performance and anothre for something that has never really worked
> correctly in gfortran.

There are other kinds of problems that arise that can't be tested
for. I am trying to get gfortran from
http://sourceforge.net/projects/mingw-w64/ to work, but the x86-64
hosted version is too old to be usable:

C:\gfortran\james\iobug>gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
/var/tmp/scripts/build/gcc-svn/gcc/configure --target=x86_64-pc
-mingw32 --host=x86_64-pc-mingw32 --prefix=/tmp/rt --with-sysroot=/tmp/rt -q
--s
ilent
Thread model: win32
gcc version 4.4.0 20081123 (experimental) (GCC)

C:\gfortran\james\iobug>gfortran iobug.f90 -oiobug

C:\gfortran\james\iobug>iobug
0.009
0.00:
0.00;
0.00<
0.00=
0.00>
0.00?
0.016

while the i686 hosted version simply is unusable:

C:\gfortran\james\iobug>x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
.../gcc/configure --target=x86_64-pc-mingw32 --prefix=/c/buildbo
t/vista64-mingw32/mingw-x86/build/root --with-sysroot=/c/buildbot/vista64-mingw3
2/mingw-x86/build/root --disable-multilib --enable-languages=all,obj-c++
Thread model: win32
gcc version 4.4.0 20081215 (experimental) (GCC)

C:\gfortran\james\iobug>x86_64-pc-mingw32-gfortran iobug.f90 -oiobug
c:/gcc_mingw64a/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-min
gw32/bin/ld.exe: crt2.o: No such file: No such file or directory
collect2: ld returned 1 exit status

Now, problems like this with ld.exe can usually be fixed by setting
the path or lib environmental variables appropriately, but that
approach didn't work in this case. What did work was to find
C:\gcc_mingw64a\x86_64-pc-mingw32\lib64\crt2.o and copy it into
the C:\gfortran\james\iobug directory:

C:\gfortran\james\iobug>x86_64-pc-mingw32-gfortran iobug.f90 -oiobug
c:/gcc_mingw64a/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-min
gw32/bin/ld.exe: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status

OK, now do the same for crtbegin.o:

C:\gfortran\james\iobug>x86_64-pc-mingw32-gfortran iobug.f90 -oiobug
c:/gcc_mingw64a/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-min
gw32/bin/ld.exe: cannot find -lmingw32
collect2: ld returned 1 exit status

OK, now we are down to a really mysterious error message: -lmingw32
seems to be a switch to ld.exe telling it to look in libmingw32.a
but it's being interpreted somehow as a file name instead. It
seems to me that the linker script given in
mingw-w64-bin_i686-mingw_20081215.zip is corrupt somehow. Where in the
directory tree would I look for this linker script? My idea is that,
although I am not capable of fixing the script itself, I could perhaps
just get a script that worked from one of the old archives and overwrite
the new one that doesn't work if I could figure out which file it was...

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: paul.richard.thomas on 18 Dec 2008 03:46
On Dec 17, 7:45 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote:
> <paul.richard.tho...(a)gmail.com> wrote in message
>
> news:745a7743-9143-4b4c-8720-d46fd1c68027(a)d42g2000prb.googlegroups.com...
>
> > Our testsuite is updated with every patch to exclude (in principle!)
> > the possibility of the carpet getting wet.  This does not always work
> > but we are currently down to two regressions, one of which is on
> > performance and anothre for something that has never really worked
> > correctly in gfortran.
>
> There are other kinds of problems that arise that can't be tested
> for.  I am trying to get gfortran fromhttp://sourceforge.net/projects/mingw-w64/to work, but the x86-64
> hosted version is too old to be usable:

Please contact the mingw-w64 project to fix this.


> gw32/bin/ld.exe: crt2.o: No such file: No such file or directory
> collect2: ld returned 1 exit status

I have seen this on x86_i64/Linux installations, with multilib
disabled, when using -w32.

> directory tree would I look for this linker script?  My idea is that,

Again, the mingw-64 project should help you on this.

There is an effort underway to renew the regular mingw builds
supported by the gfortran maintainers. Unlike Cygwin builds, which are
very straightforward, mingw requires significant levels of black art,
which we lost with the departure of FX Coudert. Watch our wiki!

Cheers

Paul
From: James Van Buskirk on 18 Dec 2008 15:23
<paul.richard.thomas(a)gmail.com> wrote in message
news:8ecf223e-481d-4158-af6d-09c88bb19f96(a)a12g2000pro.googlegroups.com...

> On Dec 17, 7:45 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote:

> > gw32/bin/ld.exe: crt2.o: No such file: No such file or directory
> > collect2: ld returned 1 exit status

> I have seen this on x86_i64/Linux installations, with multilib
> disabled, when using -w32.

I have found the magic incantation: apparantly the -L switch doesn't
cause ld.exe to look in any new directories for *.o object files,
only things like *.a libraries. Thus you have to copy crt2.o,
crtbegin.o, and crtend.o to the directory containing your *.f90
source files and also specify the directory containing libmingw32.a
on the command line:

C:\gfortran\james\iobug>gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
.../gcc/configure --target=x86_64-pc-mingw32 --prefix=/c/buildbo
t/vista64-mingw32/mingw-x86/build/root --with-sysroot=/c/buildbot/vista64-mingw3
2/mingw-x86/build/root --disable-multilib --enable-languages=all,obj-c++
Thread model: win32
gcc version 4.4.0 20081216 (experimental) (GCC)

C:\gfortran\james\iobug>dir *.o
Volume in drive C has no label.
Volume Serial Number is CCC8-B430

Directory of C:\gfortran\james\iobug

12/18/2008 01:06 AM 20,490 crt2.o
12/18/2008 01:06 AM 500 crtbegin.o
12/18/2008 01:06 AM 500 crtend.o
3 File(s) 21,490 bytes
0 Dir(s) 113,962,762,240 bytes free

C:\gfortran\james\iobug>type iobug.f90
program iobug
implicit none
double precision x
integer i

do i = 9,16
x = i
x = x/1000
write(*,'(f5.3)') x
end do
end program iobug

C:\gfortran\james\iobug>x86_64-pc-mingw32-gfortran
iobug.f90 -Lc:/gcc_mingw64a/x
86_64-pc-mingw32/lib64 -oiobug

C:\gfortran\james\iobug>iobug
0.009
0.00:
0.00;
0.00<
0.00=
0.00>
0.00?
0.016

Ooh, that shows that it's not the age of the build but rather that
www.Equation.com has the bug fixed in their version but not so in
mingw 64:

C:\gfortran\james\iobug>gfortran -v
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
.../gcc-4.4-20081212-mingw/configure --host=x86_64-pc-mingw32 --
build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortra
n/gcc-home/binary/mingw32/native/x86_64/gcc/4.4-20081212 --with-gmp=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home
/binary/mingw32/native/x86_64/mpfr --with-sysroot=/home/gfortran/gcc-home/binary
/mingw32/cross/x86_64/gcc/4.4-20081212 --with-gcc --with-gnu-ld --with-gnu-as
--
disable-shared --disable-nls --disable-tls --enable-libgomp --enable-languages=c
,fortran --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20081212 (experimental) (GCC)

C:\gfortran\james\iobug>gfortran iobug.f90 -oiobug

C:\gfortran\james\iobug>iobug
0.009
0.010
0.011
0.012
0.013
0.014
0.015
0.016

Is this issue in Jerry's domain or Kai's?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


First  |  Prev  | 
Pages: 1 2
Prev: The Fortran 2003 Handbook
Next: WatFor77 -- Re: Command-line argument capture