[Bug libfortran/21185] New: libgfortran unusable for cross-testing for newlib targets

[Bug libfortran/21185] New: libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

fortran.log shows that functions not present in newlib are referenced:

Executing on host: /home/hp/combined/cris-sim/gcc/testsuite/../gfortran
-B/home/hp/combined/cris-sim/gcc/testsuite/../ /home/hp/c\
ombined/combined/gcc/testsuite/gfortran.dg/PR19754_2.f90   -O0  
-pedantic-errors   -isystem /home/hp/combined/cris-sim/cris-elf/\
./newlib/targ-include -isystem /home/hp/combined/combined/newlib/libc/include
-B/home/hp/combined/cris-sim/cris-elf/./libgloss/cr\
is/ -L/home/hp/combined/cris-sim/cris-elf/./libgloss/cris
-L/home/hp/combined/combined/libgloss/cris -L/home/hp/combined/cris-sim\
/ld -B/home/hp/combined/cris-sim/cris-elf/./newlib/
-L/home/hp/combined/cris-sim/cris-elf/./newlib -sim3  -L/home/hp/combined/cri\
s-sim/cris-elf/./libgfortran/.libs
-L/home/hp/combined/cris-sim/cris-elf/./libiberty  -lm   -o ./PR19754_2.exe   
(timeout = 300)
/home/hp/combined/cris-sim/cris-elf/./libgfortran/.libs/libgfortran.a(unix.o):
In function `fd_truncate':^M
/home/hp/combined/combined/libgfortran/io/unix.c:516: undefined reference to
`_ftruncate'^M
/home/hp/combined/cris-sim/cris-elf/./libgfortran/.libs/libgfortran.a(unix.o):
In function `fix_fd':^M
/home/hp/combined/combined/libgfortran/io/unix.c:198: undefined reference to
`_dup'^M
/home/hp/combined/combined/libgfortran/io/unix.c:208: undefined reference to
`_dup'^M
/home/hp/combined/combined/libgfortran/io/unix.c:203: undefined reference to
`_dup'^M
/home/hp/combined/cris-sim/cris-elf/./libgfortran/.libs/libgfortran.a(unix.o):
In function `inquire_access':^M
/home/hp/combined/combined/libgfortran/io/unix.c:1443: undefined reference to
`_access'^M
collect2: ld returned 1 exit status^M

-- 
           Summary: libgfortran unusable for cross-testing for newlib
                    targets
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: cris-axis-elf (or any newlib target)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-24 00:01 -------
All I can say is that libgfortran depends on some UNIX^wPOSIX functions being there.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #23 from hp at gcc dot gnu dot org  2007-09-16 02:29 -------
Created an attachment (id=14210)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14210&action=view)
bzip2:ed gfortran.log for cris-elf for r128489 plus access_dup2.diff plus
toplevel patch to enable gfortran for cris-elf.

As requested in email.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[fxcoudert at gcc dot gnu dot org]

------- Comment #22 from fxcoudert at gcc dot gnu dot org  2007-09-15 14:53 -------
Subject: Bug 21185

Author: fxcoudert
Date: Sat Sep 15 14:52:46 2007
New Revision: 128512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128512
Log:
        PR libfortran/21185
        * runtime/compile_options.c (set_options): Fix typo.
        * runtime/main.c (store_exe_path): If getcwd is not available,
        don't use it.
        * intrinsics/getcwd.c: Same thing here.
        * io/unix.c (fallback_access): New fallback function for access.
        (fix_fd): Don't use dup if it's not available.
        * configure.ac: Check for dup and getcwd.
        * configure: Regenerate.
        * config.h.in: Regenerate.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/config.h.in
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/intrinsics/getcwd.c
    trunk/libgfortran/io/unix.c
    trunk/libgfortran/runtime/compile_options.c
    trunk/libgfortran/runtime/main.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #21 from hp at gcc dot gnu dot org  2007-09-15 11:12 -------
For cris-elf, results look promising:

                === gfortran Summary ===

# of expected passes            20431
# of unexpected failures        231
# of expected failures          6
# of unresolved testcases       48
# of unsupported tests          100

Lots of the failures seem to be calls to "abort" while some should be xfailed
(lack of certain functions, see comment #20) and some tests/machinery should be
adjusted (like removing ^M from output before matching multiple lines).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[rask at gcc dot gnu dot org]

------- Comment #20 from rask at gcc dot gnu dot org  2007-09-15 10:19 -------
arm-unknown-elf has 8000+ failures.
Some of them are similar to this one (which happen on the other targets as
well):
/n/12/rask/src/all/gcc/testsuite/gfortran.dg/chmod_1.f90:0: warning: 'const'
attribute directive ignored
/n/12/rask/src/all/gcc/testsuite/gfortran.dg/chmod_1.f90:0: warning: 'nothrow'
attribute directive ignored
/tmp/cc2tVIvn.o: In function `MAIN__':
chmod_1.f90:(.text+0x18c): undefined reference to `_gfortran_chmod_i4_sub'
chmod_1.f90:(.text+0x1f0): undefined reference to `_gfortran_chmod_i4_sub'
chmod_1.f90:(.text+0x200): undefined reference to `_gfortran_getuid'
collect2: ld returned 1 exit status

FAIL: gfortran.dg/chmod_1.f90  -O1  (test for excess errors)

The full list of functions (not all of which are missing on all targets):
_gfortran_access_func
_gfortran_chmod_func
_gfortran_chmod_i4_sub
_gfortran_fstat_i4
_gfortran_fstat_i4_sub
_gfortran_getgid
_gfortran_getuid
_gfortran_lstat_i4
_gfortran_lstat_i4_sub
_gfortran_specific__acosh_r4
_gfortran_specific__acosh_r8
_gfortran_specific__acos_r8
_gfortran_specific__asin_r8
_gfortran_specific__atanh_r4

Another type of failure is this one:
At line 13 of file /n/12/rask/src/all/gcc/testsuite/gfortran.dg/PR19872.f (unit
= 1, file = 'fort.1')
Fortran runtime error: End of file

Counts for each target:
arm: 1264
frv: 1192
mipsisa64: 32
sh: 0
v850: 1192

frv-unknown-elf looks reasonable:
# of expected passes            19140
# of unexpected failures        1438
# of expected failures          6
# of unresolved testcases       96
# of untested testcases         8
# of unsupported tests          100

mipsisa64-unknown-elf: 8000+ failures, many of which are this one:
mips-core: 1 byte read to unmapped address 0x0 at 0xffffffff800214c8
program stopped with signal 10.
FAIL: gfortran.fortran-torture/execute/write_logical.f90 execution,  -O3 -g

sh-unknown-elf: 8000+ failures, of which 6000+ are linker errors. There are
many of this one:
/n/12/rask/src/all/newlib/libc/sys/sh/syscalls.c:210: undefined reference to
`_main'

v850-unknown-elf looks reasonable:
# of expected passes            19319
# of unexpected failures        1315
# of expected failures          6
# of unresolved testcases       50
# of unsupported tests          100


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #19 from hp at gcc dot gnu dot org  2007-09-14 21:36 -------
(In reply to comment #18)
> So, I'll update your patch to get rid of the getcwd call, attach the result and
> start a new test.

Never mind, I see you've taken care of it in the access_dup2 patch here. Doh!
Starting test...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #18 from hp at gcc dot gnu dot org  2007-09-14 21:31 -------
(In reply to comment #17)
> We'll see whether the test-results are meaningful; it's likely there's more to
> fix.

Unfortunately not very meaningful without a getcwd.  I got curious why getcwd
would be needed, so I looked around, and it seems the stored absolute exe path
is only reachable by full_exe_path(), called only from
runtime/backtrace.c:show_backtrace()
- which is #if GLIBC_BACKTRACE'd out; empty for newlib targets!
So, I'll update your patch to get rid of the getcwd call, attach the result and
start a new test.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #17 from hp at gcc dot gnu dot org  2007-09-14 14:13 -------
(In reply to comment #14)
The build succeeds with my locally fixed version.
We'll see whether the test-results are meaningful; it's likely there's more to
fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[rask at gcc dot gnu dot org]

------- Comment #16 from rask at gcc dot gnu dot org  2007-09-14 13:43 -------
I get the same build failure on sh-unknown-elf and mipsisa64-unknown-elf. I'm
continuing without the static keyword and with s/amod/amode/g.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[fxcoudert at gcc dot gnu dot org]

------- Comment #15 from fxcoudert at gcc dot gnu dot org  2007-09-14 13:38 -------
Created an attachment (id=14208)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14208&action=view)
Updated patch

(In reply to comment #13)
> /home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static declaration
> of 'access' follows non-static declaration
> /home/hp/combe/combined/newlib/libc/include/sys/unistd.h:19: error: previous
> declaration of 'access' was here

Oh, you have a prototype for access() in standard headers but no function in
the libc? That's weird! Embedded targets will always surprise me.

> Besides the obvious s/amod/amode/ typo

Hum, how did that even get past my testing? I thought I had commented out
HAVE_ACCESS on my x86_64-linux.

> maybe use a different name for the internal function

Yup, you're right (the second version). I'm attaching an updated patch that
should do the same thing you did.

(In reply to comment #12)
> Testing on v850-unknown-elf suggests that getcwd() is also needed by
> libgfortran.

Also fixed in the attached new patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #14 from hp at gcc dot gnu dot org  2007-09-14 13:22 -------
(In reply to comment #13)
Oops, I mean:
#ifndef HAVE_ACCESS
... libgfortran_access implementation
#undef access
#define access libgfortran_access
#endif


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #13 from hp at gcc dot gnu dot org  2007-09-14 13:19 -------
Sorry, build fails for cris-elf with:
libtool: compile:  /home/hp/combe/cris-regobj/./gcc/xgcc
-B/home/hp/combe/cris-regobj/./gcc/ -nostdinc -B/home/hp/combe/cris-rego\
bj/cris-unknown-elf/newlib/ -isystem
/home/hp/combe/cris-regobj/cris-unknown-elf/newlib/targ-include -isystem
/home/hp/combe/comb\
ined/newlib/libc/include
-B/home/hp/combe/cris-regobj/cris-unknown-elf/libgloss/cris
-L/home/hp/combe/cris-regobj/cris-unknown-el\
f/libgloss/libnosys -L/home/hp/combe/combined/libgloss/cris
-B/tmp/reg-cris/cris-unknown-elf/bin/ -B/tmp/reg-cris/cris-unknown-el\
f/lib/ -isystem /tmp/reg-cris/cris-unknown-elf/include -isystem
/tmp/reg-cris/cris-unknown-elf/sys-include -L/home/hp/combe/cris-\
regobj/./ld -DHAVE_CONFIG_H -I. -I/home/hp/combe/combined/libgfortran -I.
-iquote/home/hp/combe/combined/libgfortran/io -I/home/h\
p/combe/combined/libgfortran/../gcc
-I/home/hp/combe/combined/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -W\
all -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite-strings -O2 -g -O2 -MT unix.lo -MD -MP -MF .d\
eps/unix.Tpo -c /home/hp/combe/combined/libgfortran/io/unix.c -o unix.o
/home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static declaration
of 'access' follows non-static declaration
/home/hp/combe/combined/newlib/libc/include/sys/unistd.h:19: error: previous
declaration of 'access' was here
/home/hp/combe/combined/libgfortran/io/unix.c: In function 'access':
/home/hp/combe/combined/libgfortran/io/unix.c:1795: error: 'amod' undeclared
(first use in this function)
/home/hp/combe/combined/libgfortran/io/unix.c:1795: error: (Each undeclared
identifier is reported only once
/home/hp/combe/combined/libgfortran/io/unix.c:1795: error: for each function it
appears in.)
/home/hp/combe/combined/libgfortran/io/unix.c:1793: warning: unused parameter
'amode'
make[5]: *** [unix.lo] Error 1
make[5]: Leaving directory
`/home/hp/combe/cris-regobj/cris-unknown-elf/libgfortran'

Besides the obvious s/amod/amode/ typo, maybe use a different name for the
internal function, and
#ifndef HAVE_ACCESS
... libgfortran_access implementation
#else
#define libgfortran_access access
#endif
to avoid problems with the access prototype.

I'm testing such an updated patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[rask at gcc dot gnu dot org]

------- Comment #12 from rask at gcc dot gnu dot org  2007-09-14 13:12 -------
Testing on v850-unknown-elf suggests that getcwd() is also needed by
libgfortran.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[hp at gcc dot gnu dot org]

------- Comment #11 from hp at gcc dot gnu dot org  2007-09-14 12:10 -------
(In reply to comment #9)
> Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01219.html. I'd
> be glad if some with access to cris-axis-elf

I'll test that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[rask at gcc dot gnu dot org]

------- Comment #10 from rask at gcc dot gnu dot org  2007-09-14 10:42 -------
I'm testing mipsisa64-unknown-elf, sh-unknown-elf and v850-unknown-elf right
now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-09-13 22:56 -------
Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01219.html. I'd
be glad if some with access to cris-axis-elf (or another similar newlib target)
could try and build libgfortran with this patch.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2007-
                   |                            |09/msg01219.html
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-09-13 09:33 -------
I'm coming back to that issue...

(In reply to comment #4)
> I guess we could try to provide a graceful degradation for such systems...
> The use of dup() can probably be avoided if dup() isn't available
> without too much degradation in the library features.

I still think it's better than nothing. It will gives weird results when people
start closing preconnected units, but we can document that behaviour.

Otherwise, we can use another technique to create new descriptors for
stdin/stdout/stderr, but I can't think of something that would work easily.

> access() can probably be emulated, or at least its basic features.

libgfortran only use it with modes R_OK, W_OK and R_OK | W_OK. These uses can
be emulated with calls to open().

> For ftruncate(), however, I don't see how to make it work.

ftruncate() is now protected by HAVE_FTRUNCATE, so this one shouln't be a
problem any more.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-01-05 10:06:52         |2007-09-13 09:33:48
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[rask at sygehus dot dk]

------- Comment #7 from rask at sygehus dot dk  2007-06-14 10:36 -------
I've thought about adding ENOSYS stubs for the missing functions to libgloss.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-01-05 23:57 -------
The only problem with spu-elf right now with respect of fortran compiler is
that the spu compiler says it supports TI mode but libgcc does not fully
support TI mode, this will get fixed but later.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-01-05 16:51 -------
(In reply to comment #4)
> I guess we could try to provide a graceful degradation for such systems... The
> use of dup() can probably be avoided if dup() isn't available, without too much
> degradation in the library features. access() can probably be emulated, or at
> least its basic features. For ftruncate(), however, I don't see how to make it
> work.

Except for newlib for spu-elf actually has dup, access and ftruncate now so 
this is not a generic newlib issue really.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[fxcoudert at gcc dot gnu dot org]

------- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-01-05 10:06 -------
I guess we could try to provide a graceful degradation for such systems... The
use of dup() can probably be avoided if dup() isn't available, without too much
degradation in the library features. access() can probably be emulated, or at
least its basic features. For ftruncate(), however, I don't see how to make it
work.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Last reconfirmed|2006-02-05 18:02:49         |2007-01-05 10:06:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|16991                       |
              nThis|                            |
           Severity|normal                      |enhancement
   Last reconfirmed|2006-01-26 05:23:00         |2006-02-05 18:02:49
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-01-26 05:23 -------
I am going to mark this as blocking PR 16991 even though it really is not a
build failure.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |16991
              nThis|                            |
   Last reconfirmed|2005-10-25 19:44:07         |2006-01-26 05:23:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-25 19:44 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-25 19:44:07
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185