Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.5.0
http
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: i386-apple-darwin8.6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27183
ReportedBy: dir at lanl dot gov
GCC host triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27561
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC target triplet: powerpc-apple-darwin8.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27575
: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.6.0
http
--- Comment #2 from dir at lanl dot gov 2006-05-17 17:04 ---
no problem with 4.1.1 -
[dranta:~] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran4.1
--enable-languages=c,f95
Thread model: posix
gcc
rtran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
--- Comment #2 from dir at lanl dot gov 2006-05-22 14:41 ---
Hi Paul,
I down loaded a completely new tree this morning and did a new build with
about the same results -
Test Run By dir on Mon May 22 07:08:14 2006
Native configuration is powerpc-apple-darwin8.6.0
--- Comment #3 from dir at lanl dot gov 2006-05-22 14:58 ---
I grabbed one of the tests that failed and tried it with today's 4.2.0 version
and version 4.1.1 and it failed with the new and passed with the old -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_lo
--- Comment #4 from dir at lanl dot gov 2006-05-22 20:51 ---
There is no problem on LINUX or the Intel Macintosh version - only having
trouble with the powerPC version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
--- Comment #5 from dir at lanl dot gov 2006-05-23 19:16 ---
Has anybody else with a powerPC Macintosh tried the testsuite recently ?
I down loaded and rebuild 4.1.1 and 4.2.0 today. 4.1.1 is Ok. 4.2.0 has the
same errors.
The test problem in comment #3 works with -g, but when
--- Comment #8 from dir at lanl dot gov 2006-05-24 18:27 ---
Hi Jerry,
I tried rev 113947 and rev 113923 that I think are just before your
patches and gfortran still failed. I did a "svn update -r 113923 gcc" to create
the old version. I hope that is the correct wa
--- Comment #10 from dir at lanl dot gov 2006-05-25 13:36 ---
I restored and rebuilt the 20060508 version that I had archived and I still get
the error -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical
write_logical.f90
[dranta:~/tests/gfortran-D] dir% write_logical
At
--- Comment #12 from dir at lanl dot gov 2006-05-25 14:35 ---
I rebuild version 20060508 from the full source tree that I had saved and I
find the problem - I am beginning to wonder if the update to CCTOOLS or the
system is causing the problem - except for the fact that I can build the
--- Comment #14 from dir at lanl dot gov 2006-05-25 14:47 ---
The version from the wiki also fails -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical
write_logical.f90
[dranta:~/tests/gfortran-D] dir% write_logical
At line 9 of file write_logical.f90
Fortran runtime error
--- Comment #15 from dir at lanl dot gov 2006-05-25 14:54 ---
At last one that works (I knew that I did the testsuite on this one) - version
20060405 -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical
write_logical.f90
[dranta:~/tests/gfortran-D] dir% write_logical
--- Comment #16 from dir at lanl dot gov 2006-05-25 16:33 ---
Works at rev 112998 just before the updates for bug 27138 on April 17 -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical
write_logical.f90
[dranta:~/tests/gfortran-D] dir% write_logical
[dranta:~/tests/gfortran
--- Comment #17 from dir at lanl dot gov 2006-05-25 20:53 ---
It runs after (bug fix 20257) rev 113373 and fails after (bug fix 27360) rev
113396. I think that narrows it down to one of two updates - if the problem was
caused by changes to gfortran.
--
http://gcc.gnu.org/bugzilla
--- Comment #21 from dir at lanl dot gov 2006-05-26 17:45 ---
It is rev 113395 that is causing the problem. I backed out that change and
built today's version of gfortran - it now correctly runs one of the tests that
has been failing -
[dranta:~/tests/gfortran-D] dir% gfortran -
--- Comment #23 from dir at lanl dot gov 2006-05-26 19:36 ---
Here is the good and the bad -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -save-temps -o write_logical2
write_logical2.f90
[dranta:~/tests/gfortran-D] dir% write_logical2
At line 9 of file write_logical2.f90
Fortran
--- Comment #5 from dir at lanl dot gov 2006-05-30 16:34 ---
It is strange - gfortran under cygwin does not seem to have the problem. I
wonder why GMP/MPFR is different under MSYS ? I also tried your test under MSYS
on my system and got the same answer (+one digit) that you got under
--- Comment #6 from dir at lanl dot gov 2006-05-30 17:01 ---
I also forced it to use the gcc that came with gfortran getting the same
result. I built with mpfr-2.1.2 and gmp-4.1.4 a while ago when I unsucessfully
tried to build gfortran on my PC. I noticed your MSYS version is printing
ary: gfortran: Internal error: Illegal instruction
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #2 from dir at lanl dot gov 2005-11-07 16:11 ---
It failed under 10.4.2 from a completely new down load - then I upgraded to
10.4.3 to see if that would help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #3 from dir at lanl dot gov 2005-11-07 16:47 ---
Here is another try from another complete download under 10.4.3 -
# When builting multilibbed target libraries, all the required
# When builting multilibbed target libraries, all the required
# libraries are expected to
--- Comment #5 from dir at lanl dot gov 2005-11-07 19:17 ---
I do the get with -
[dranta:~/utlib] dir% cat gfortranGet
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
I do the configure with -
[dranta:~/utlib] dir% cat gfortranConfig
configure --prefix=/Users/dir/gfortran --enable
--- Comment #6 from dir at lanl dot gov 2005-11-07 19:19 ---
I have a dual 2.5 GHZ PowerPC G5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #8 from dir at lanl dot gov 2005-11-07 21:14 ---
If -
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
is now wrong, what is the correct CVS command to use ?
Changing the directory make no difference, I have done exactly the same thing
for the last year or so and I had
--- Comment #10 from dir at lanl dot gov 2005-11-08 14:18 ---
The make bootstrap ends with -
make bootstrap
...
...
checking for .preinit_array/.init_array/.fini_array support... no
checking if mkdir takes one argument... no
Using `../.././gcc/config/rs6000/rs6000.c' for ma
--- Comment #11 from dir at lanl dot gov 2005-11-08 15:15 ---
Down loading gfortran using svn took 40 percent longer and gave the same
results on the build -
By the way the GNU Fortran Page -
http://gcc.gnu.org/fortran/
still says to use anonymous CVS
MLIBS=`/Users/dir/gfortran
--- Comment #13 from dir at lanl dot gov 2005-11-08 18:14 ---
Here is what I do -
12 9:21mkdir gfortran
13 9:21cd gfortran
14 9:25svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
15 9:56cd gcc
16 9:56configure --prefix=/Users/dir/bin
--- Comment #15 from dir at lanl dot gov 2005-11-08 21:46 ---
The problem is still there -
34 13:14 svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
35 13:29 cd gcc
36 13:30 mkdir objdir
37 13:30 cd objdir
38 13:30 ../configure --prefix=/Users
--- Comment #18 from dir at lanl dot gov 2005-11-09 15:13 ---
That was it - my system had two versions of strip.
Thanks,
Dale
The final library build has some warning messages, but they do not seem to hurt
anything -
ranlib -c .libs/libgfortranbegin.a
creating libgfortranbegin.la
--- Comment #20 from dir at lanl dot gov 2005-11-09 15:29 ---
It was in /usr/local/bin along with a 100 or so other programs - I suppose that
one of them installed it .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24988
default.h: No
such file or directory
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
--- Comment #2 from dir at lanl dot gov 2005-11-23 14:09 ---
I applied the patch to what I had yesterday and did a make and install. I build
a program with it but the program would not run. I got -
[dranta:~/sage/ibar/ibarOne] dir% rage2005GF.x ibarOne.input
dyld: lazy symbol
--- Comment #5 from dir at lanl dot gov 2005-11-23 17:47 ---
Nothing called gthrw_pthread_mutex_lock (Darwin only has pthread_mutex_lock)is
in any of the libraries as a terminator. If I run gcc directly, I do not know
how to get all the flags set correctly to get a meaningful
--- Comment #7 from dir at lanl dot gov 2005-11-23 19:45 ---
I did a complete rebuild with the same results -
mkdir gfortran
cd gfortran
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
cd gcc
patch -p0 < /Users/dir/Desktop/gcc41-pr24991.patch
configure --prefix=/Users/dir/gfort
--- Comment #9 from dir at lanl dot gov 2005-11-23 21:18 ---
Created an attachment (id=10329)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10329&action=view)
The preprocessed output for environ.c
The preprocessed output for environ.c
--
http://gcc.gnu.org/b
--- Comment #11 from dir at lanl dot gov 2005-11-23 22:09 ---
Created an attachment (id=10330)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10330&action=view)
nm of the gfortran libraries
References to the "gthrw" routines seem to be everywhere.
(I am out
--- Comment #36 from dir at lanl dot gov 2005-11-28 15:53 ---
With patches "gcc41-pr24991.patch" (I also need this to build on LINUX) and
"gcc-weakref-darwin.patch" (the patch gcc/ChangeLog failed, but that did not
matter) installed and a fresh down load of gfort
stop
end
--
Summary: Fortran runtime error: Invalid argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot g
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25271
--- Comment #1 from dir at lanl dot gov 2005-12-05 21:16 ---
Created an attachment (id=10411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10411&action=view)
problem file
This is the original problem file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25271
--- Comment #3 from dir at lanl dot gov 2005-12-06 13:47 ---
If you look at the output from format 2030, you will see that that comma at the
end of the "44h e n d..." statement is printed, but the comma is the 45th
character after the 44h . Like wise the '/' af
--- Comment #5 from dir at lanl dot gov 2005-12-08 14:16 ---
Your are likely correct - it probability is not in the standard, but for the
first 15 years of FORTRAN, keypunches and card readers were the only way to
create and submit a program and they always pad to 80 characters - by
--- Comment #7 from dir at lanl dot gov 2005-12-12 16:37 ---
This patch works for the reduced test case, but the original test case still
fails for me -
[dranta:~/tests/gfortran-D] dir% gfortran -o write08 write08.f
[dranta:~/tests/gfortran-D] dir% write08
[dranta:~/tests/gfortran-D
--- Comment #8 from dir at lanl dot gov 2005-12-12 16:50 ---
Looking into unformatted_backspace, there does not seem to be anything there to
prevent "u->last_record" from going negative - may be that is problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
--- Comment #9 from dir at lanl dot gov 2005-12-13 14:39 ---
I generated random I/O sequences doing 100,000 tests at each I/O operation
count staring at five here is the shortest one to fail (somewhere in the
eights) -
[dranta:~/tests/gfortran-D] dir% gfortran -o write10 write10.f
--- Comment #10 from dir at lanl dot gov 2005-12-13 15:21 ---
Removing the constraint of no read after write gives a slightly shorter one -
[dranta:~/tests/gfortran-D] dir% gfortran -o write11 write11.f
[dranta:~/tests/gfortran-D] dir% write11
At line 14 of file write11.f
Fortran
--- Comment #11 from dir at lanl dot gov 2005-12-16 20:35 ---
When the array of size 2045 or larger the error goes away -
[dranta:~/tests/gfortran-D] dir% gfortran -o write11 write11.f
[dranta:~/tests/gfortran-D] dir% write11
At line 14 of file write11.f
Fortran runtime error: Invalid
--- Comment #14 from dir at lanl dot gov 2005-12-21 19:36 ---
After tracing the errors for a while, it became clean that "active" pointer
into the read/write buffer was not being correctly updated. Adding one line (
s->active=0; ) to the bottom of routine "fd_truncat
--- Comment #16 from dir at lanl dot gov 2005-12-21 21:43 ---
I down loaded gfortran and built it on the Macintosh with -
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
cd gcc
configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
make -j 4
make install
When, I try the
--- Comment #20 from dir at lanl dot gov 2005-12-22 14:00 ---
Thanks FX - You gave me the first good explaination of how it should be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
--- Comment #21 from dir at lanl dot gov 2005-12-22 14:18 ---
The second example in comment 3 should fail as it does - since it does try read
beyond the end of file. As far as I can tell, the FX patch does not fix any of
the test cases on the Macintosh and I think that it actually is
--- Comment #23 from dir at lanl dot gov 2005-12-22 16:01 ---
What is happening here is actually quite simple. The program reads the green
word for the previous record from the file from location "file_position (u->s)
- length)", that word gives the length of the previ
--- Comment #24 from dir at lanl dot gov 2005-12-22 16:32 ---
Also, I just noticed that, if length != sizeof (gfc_offset) then 'm' has not
been correctly read - so the routine should quit. Using a bad number to
calculate 'new' will not likely useful.
--
http://
--- Comment #26 from dir at lanl dot gov 2005-12-22 19:23 ---
I ran the "check-gfortran" tests before and after putting in the two changes
that I suggested on the Macintosh and the results were identical and my real
programs now run Ok with the changes, but someone is currec
--- Comment #27 from dir at lanl dot gov 2005-12-22 21:14 ---
In the second example in comment #3, the first read reads the end of file and
the end=1008 works correctly. On the second read, the end of file has been
passed so that the end=1011 does not and should not catch it - it is an
at
fortran/trans-decl.c:1130
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC h
at
fortran/trans-decl.c:1130
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC h
--- Comment #1 from dir at lanl dot gov 2005-12-22 21:59 ---
I don't know why this showed up twice
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25539
--- Comment #31 from dir at lanl dot gov 2005-12-23 15:14 ---
Hi Jerry,
Would you go ahead and commit this ? A test case something like that in
Comment #9 shows the problem before and the fix after or may be you have a
better one from NIST. The change suggest in comment #14 fixes
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25550
gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
--- Comment #3 from dir at lanl dot gov 2005-12-27 21:46 ---
This was after a complete new download and rebuild.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
--- Comment #1 from dir at lanl dot gov 2005-12-29 15:34 ---
Here is another test example that more clearly shows the problem (The f90
output is correct) -
[dranta:~/tests/gfortran-D] dir% f90 -o sage03 sage03.f90
[dranta:~/tests/gfortran-D] dir% sage03
1
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25598
--- Comment #2 from dir at lanl dot gov 2006-01-04 19:51 ---
It also fails on 4.1-
[dranta:~/tests/gfortran-D] dir% gfortran -o sage03 sage03.f90
[dranta:~/tests/gfortran-D] dir% sage03
1
2FFFDFFFD
3
on
unformatted read
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
htt
--- Comment #1 from dir at lanl dot gov 2006-01-06 20:11 ---
Here is a shorter one that also crashes on the Macintosh -
[dranta:~/tests/gfortran-D] dir% gfortran -o write20 write20.f
[dranta:~/tests/gfortran-D] dir% write20
Segmentation fault
[dranta:~/tests/gfortran-D] dir% cat
--- Comment #4 from dir at lanl dot gov 2006-01-09 01:52 ---
Having a read immediately follow a write - seems to cause the errors. I have
run several million I/O tests where the only legal thing not permitted is a
read immediately after a write - without getting a single error
--- Comment #6 from dir at lanl dot gov 2006-01-09 18:18 ---
Hurray - Let there be an end to I/O problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
--- Comment #8 from dir at lanl dot gov 2006-01-11 15:34 ---
That fixed all the posted examples and it passed the 1048576 tests of all
combinations of read,write,backspace, and rewind taken 10 at a time writing a
single word, but when I increased the write size to 500 words it failed
--- Comment #9 from dir at lanl dot gov 2006-01-11 16:02 ---
With a larger amount of data it only takes one write -
[dranta:~/tests/gfortran-D] dir% gfortran -o write22 write22.f
[dranta:~/tests/gfortran-D] dir% write22
Bus error
[dranta:~/tests/gfortran-D] dir% cat write22.f
--- Comment #10 from dir at lanl dot gov 2006-01-11 16:50 ---
My thought on a possible fix is that the I/O buffers should be dumped before
the read whenever a read immediately follows a write, but I have no idea how
you would detect the situation.
--
http://gcc.gnu.org/bugzilla
ion: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25753
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
--- Comment #2 from dir at lanl dot gov 2006-01-13 18:06 ---
It also fails with a "double precision" argument -
[dranta:~/tests/gfortran-D] dir% gfortran -c present02.f90
In file present02.f90:3
if (present(data_c1)) then
1
Error: The upper bo
--- Comment #4 from dir at lanl dot gov 2006-01-17 15:30 ---
Opps, I think that the change suggested in Comment #1 actually does fix the
problem on the LINUX version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
--- Comment #5 from dir at lanl dot gov 2006-01-17 20:07 ---
This bug has now migrated into the 4.1 tree. Sometime after the 20060104
version Would it not be easier to elminate the offending updates rather than
debug them ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
--- Comment #9 from dir at lanl dot gov 2006-01-18 14:20 ---
Paul,
I am sorry that I upset you. It was completely unintentional.
Dale.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: Darwin 8.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29142
rsion: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
--- Comment #3 from dir at lanl dot gov 2006-10-16 12:39 ---
Created an attachment (id=12442)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12442&action=view)
config.log file from gfortran/ibin/powerpc-apple-darwin8.7.0/libjava
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #4 from dir at lanl dot gov 2006-10-16 12:42 ---
Created an attachment (id=12443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12443&action=view)
config.log file from /Users/dir/gfortran/ibin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
--- Comment #5 from dir at lanl dot gov 2006-10-16 15:53 ---
powerpc-apple-darwin8.7.0 does not come with 64 bit libraries for x-windows -
is there some way to turn of the 64 bit branch of the build ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #7 from dir at lanl dot gov 2006-10-16 18:53 ---
I tried installing the patch (the two patch files in comment #6 were identical)
into 4.2 , but it failed -
[dranta:~/gfortran/gcc/libjava] dir% patch -p2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #10 from dir at lanl dot gov 2006-10-16 19:57 ---
What does --disable-multilib do ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #16 from dir at lanl dot gov 2006-10-16 20:18 ---
The patch from comment #8 partly fails on a 4.2 tree created this afternoon -
[dranta:~/gfortran/gcc/libjava] dir% patch -p2 < gcc42-java-nomulti.patch
patching file Makefile.in
Hunk #1 FAILED at 9006.
1 out of 1 hunk FAI
failed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29491
failed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29492
--- Comment #2 from dir at lanl dot gov 2006-10-18 14:37 ---
This turned out to be a gtk bug - a rebuild of glib-2.12.4 followed by a
rebuild of gtk+-2.10.6 fixed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29491
--- Comment #8 from dir at lanl dot gov 2007-01-29 13:45 ---
It hangs on a Intel iMac -
[pactech01:~/tests] dir% gfortran -o recursiveio recursiveio.f90
[pactech01:~/tests] dir% recursiveio
test
1.00
^C
[pactech01:~/tests] dir% cat recursiveio.f90
external fun
ED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: Darwin 8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
--- Comment #3 from dir at lanl dot gov 2007-04-13 15:28 ---
I do not see why you say the numbers over flow - g95 gives exactly the correct
answer when I print them out
[dranta:~/junk] dir% g95 -o mask mask.f90
[dranta:~/junk] dir% mask
8000
FF00
[dranta:~/junk] dir% cat
1 - 100 of 274 matches
Mail list logo
