[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- 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 passes19140 # of unexpected failures1438 # 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 0x800214c8 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 passes19319 # of unexpected failures1315 # 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
--- 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 passes20431 # of unexpected failures231 # 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
--- 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=gccview=revrev=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
--- 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=14210action=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=14208action=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
-- 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
--- 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
--- 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|-00-00 00:00:00 |2005-10-25 19:44:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- 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
