--- 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
--- 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_o
--- 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
--- 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 ign
--- 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 t
--- 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 looke
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.c
--- 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
--- 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.
--
--- 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
--- 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
--- 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.
--- 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 libr
--- 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 prob
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|16991 |
nThis||
Severi
--- 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
--
--- 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|UNCON
--- 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
24 matches
Mail list logo
