Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: jb at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
--- Comment #2 from jb at gcc dot gnu dot org 2006-05-23 15:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01186.html
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jb at gcc dot gnu dot org 2006-05-25 20:44 ---
Seems this work is getting closer:
http://gcc.gnu.org/ml/fortran/2006-04/msg00173.html
I'm adding this bug as blocking 27740, as before taking symbol versioning into
use, it would be nice to clean up the li
Priority: P3
Component: libfortran
AssignedTo: jb at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27919
--- Comment #2 from jb at gcc dot gnu dot org 2006-06-08 04:52 ---
(In reply to comment #1)
> At the same time the so version needs to change, as this is an ABI change in
> the library.
>
Yes. However, I think a single so version increase is enough for 4.1->4.2, and
I plan
--- Comment #1 from jb at gcc dot gnu dot org 2008-11-20 14:04 ---
I'm looking at I/O performance as part of PR 25561 (see also PR 37754, perhaps
this is a dup?), but my changes are invasive enough that they are 4.5 material.
Thanks for the report.
--
jb at gcc dot gnu do
--- Comment #8 from jb at gcc dot gnu dot org 2008-11-21 07:43 ---
(In reply to comment #7)
> From some experiments I have done, we can make substantial improvement by
> streamlining next_char. What I have in mind is reading a whole or partial
> block of a file and returning
--- Comment #13 from jb at gcc dot gnu dot org 2008-12-23 19:36 ---
As testing with a newer binutils apparently isn't forthcoming, closing as
invalid.
As an aside, while AFAIK this is not documented, my intuition is that
libgfortran requires a somewhat up to date libc, so maybe
--- Comment #11 from jb at gcc dot gnu dot org 2009-01-05 22:14 ---
Patch that improves countlines.f test (and a bunch of other things):
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
--- Comment #11 from jb at gcc dot gnu dot org 2009-01-05 22:15 ---
Patch getting rid of ASF for external files:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #12 from jb at gcc dot gnu dot org 2009-01-18 09:30 ---
Small patch on top of the big patch in comment #11 in order to fix a couple
minor issues:
http://gcc.gnu.org/ml/fortran/2009-01/msg00152.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
--- Comment #3 from jb at gcc dot gnu dot org 2009-01-18 09:38 ---
My patch for PR25561 fixes this partially, with the patch the strace output is:
write(3, "a", 1)= 1
write(3, "a", 1)= 1
write(3, "a", 1)
--- Comment #5 from jb at gcc dot gnu dot org 2009-05-15 23:45 ---
Subject: Bug 39872
Author: jb
Date: Fri May 15 23:45:08 2009
New Revision: 147601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147601
Log:
Backport fix for PR libfortran/39872 from trunk.
--- Comment #11 from jb at gcc dot gnu dot org 2009-05-15 23:50 ---
Backported to 4.4 branch as r147601.
Backporting to 4.3 caused regressions, so I'm tempted to just skip that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #3 from jb at gcc dot gnu dot org 2009-05-19 06:42 ---
Assigning to myself.
HJL is right, we should use the _r functions if available, if not we must
protect the calls with a mutex.
--
jb at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from jb at gcc dot gnu dot org 2009-05-20 08:37 ---
Both the mixed C/Fortran and the pure Fortran version by Dominique works as
expected for me on x86_64-linux. I.e. I get the same results as reported by
Dominique in comments #1 and #6.
This looks like a target bug
--- Comment #6 from jb at gcc dot gnu dot org 2009-05-27 16:15 ---
The patch in comment #5 fixes most of the issues, not all. Remaining
gfortran.dg/elemental_dependency_1.f90
gfortran.dg/parameter_unused.f90
gfortran.dg/blockdata_3.f90
gfortran.dg/vector_subscript_4.f90
--- Comment #7 from jb at gcc dot gnu dot org 2009-05-27 16:42 ---
The patch below fixes the elemental_dependency_1 and vector_subscript_4
failures:
diff --git a/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
b/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
index 3e1f67b
--- Comment #2 from jb at gcc dot gnu dot org 2009-05-27 17:44 ---
(In reply to comment #1)
> See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
>
Yes, I know; I added the note to the wiki page after I filed this bug. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
--- Comment #6 from jb at gcc dot gnu dot org 2009-05-29 21:04 ---
Fixed on trunk as of r147985, closing as fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-01 14:21 ---
Whatever you do, as long as the Fortran standard is silent on this matter, can
you hide it behind some -fC99-wankery or such option and not enable it by
default, so that those of us who care less about which of (NaN, NaN
--- Comment #7 from jb at gcc dot gnu dot org 2009-06-03 17:39 ---
Confirmed on trunk.
This seems to be due to the format caching stuff?
The regression on the 4.4 branch would be explained by the I/O backport
(r147887).
--
jb at gcc dot gnu dot org changed:
What
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-03 18:49 ---
Created an attachment (id=17949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17949&action=view)
Proposed patch
This patch seems to fix it, will formally submit as soon as it regtests.
--
http://gcc.
--- Comment #9 from jb at gcc dot gnu dot org 2009-06-03 19:19 ---
Proper patch submitted.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
URL
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-03 21:07 ---
Subject: Bug 40330
Author: jb
Date: Wed Jun 3 21:07:19 2009
New Revision: 148149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148149
Log:
PR libfortran/40330
Use heap memory for cached format
--- Comment #17 from jb at gcc dot gnu dot org 2009-06-04 07:40 ---
(In reply to comment #16)
> Can this PR now be closed?
Yes, I think so. There are still some remnants of ASF in internal I/O, but I
don't think it hurts.
--
jb at gcc dot gnu dot org changed:
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-09 20:29 ---
Subject: Bug 40334
Author: jb
Date: Tue Jun 9 20:29:33 2009
New Revision: 148324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148324
Log:
PR libfortran/40334 backspace regression
Added:
t
--- Comment #13 from jb at gcc dot gnu dot org 2009-06-09 20:56 ---
Subject: Bug 40330
Author: jb
Date: Tue Jun 9 20:55:53 2009
New Revision: 148326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148326
Log:
PR libfortran/40330 Use heap memory for format cache
--- Comment #14 from jb at gcc dot gnu dot org 2009-06-09 20:57 ---
Closing as fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #24 from jb at gcc dot gnu dot org 2009-06-10 21:17 ---
Further reduced testcase:
program pr40330
implicit none
call s1()
call s1()
contains
subroutine s1()
character(LEN=100) :: a
a = "(3X)"
write(*,FMT='('//trim(a)//",a,
--- Comment #5 from jb at gcc dot gnu dot org 2009-07-15 17:19 ---
I don't get it; for some reason bytes_left_subrecord has been set to 0, hence
the seek gets messed up.
--
jb at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from jb at gcc dot gnu dot org 2009-07-15 21:42 ---
Ok, so the problem is that due to the EOF the first read hits, the
current_record marker is not properly reset to 0 at the end of the data
transfer, and from that it follows that stuff isn't correctly initialized a
--- Comment #9 from jb at gcc dot gnu dot org 2009-07-17 19:40 ---
Subject: Bug 40714
Author: jb
Date: Fri Jul 17 19:40:23 2009
New Revision: 149757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149757
Log:
When finalizing I/O transfer, set current_record to 0 before r
--- Comment #4 from jb at gcc dot gnu dot org 2009-07-29 12:46 ---
(In reply to comment #3)
> Is there a particular reason why we can not change this to off_t with 4.5.?
>
Yes, it would break the ABI. As it's such a minor issue, IMHO it can be
postponed until we need to br
--- Comment #11 from jb at gcc dot gnu dot org 2005-11-06 18:28 ---
Subject: Bug 24174
Author: jb
Date: Sun Nov 6 18:28:22 2005
New Revision: 106563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106563
Log:
gfortran ChangeLog
2005-11-06 Janne Blomqvist <[EMAI
--- Comment #3 from jb at gcc dot gnu dot org 2005-11-06 18:28 ---
Subject: Bug 24305
Author: jb
Date: Sun Nov 6 18:28:22 2005
New Revision: 106563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106563
Log:
gfortran ChangeLog
2005-11-06 Janne Blomqvist <[EMAI
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-11 20:41 ---
The recent patch on 2005-11-06 AFAICS fixes this bug.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jb at gcc dot gnu dot org 2005-11-11 20:46 ---
This is fixed by the 2005-11-06 patch.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jb at gcc dot gnu dot org 2005-11-11 21:02 ---
Thomas,
the test programs you provided in #1 and #7 now work correctly for me on
i686-pc-linux-gnu. Perhaps it has something to do with my recent fix to PR
24174, I don't know. But if it works for you too I guess
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-11 21:55 ---
Seems like libgfortran vectorizes much better now. Compiling with
"-ftree-vectorize -ftree-vectorizer-verbose=5 -msse2" added to CFLAGS (I didn't
try with FCFLAGS) and grepping the output for LOOP V
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-11 23:13 ---
Actually, by marking the arguments to matmul as restrict pointers, I was able
to vectorize the main loop for unit stride.
I'll produce a patch at some point..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
--- Comment #6 from jb at gcc dot gnu dot org 2005-11-13 19:42 ---
Patch for matmul here: http://gcc.gnu.org/ml/fortran/2005-11/msg00366.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-14 19:48 ---
Subject: Bug 21468
Author: jb
Date: Mon Nov 14 19:48:31 2005
New Revision: 106898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106898
Log:
2005-11-14 Janne Blomqvist <[EMAIL PROTECTED]>
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-16 06:53 ---
Right. I think I know how to fix this bug, and it shouldn't be too hard.
--
jb at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from jb at gcc dot gnu dot org 2005-11-16 23:00 ---
As discussed on IRC, the solution is to use noinst_LTLIBRARIES instead of
EXTRA_LTLIBRARIES. It was also suggested to name the library
libmatmul_convenience.a. Example in libffi/Makefile.am
--
jb at gcc dot gnu dot
--- Comment #2 from jb at gcc dot gnu dot org 2005-11-17 08:26 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01271.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-17 10:00 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01277.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
--- Comment #6 from jb at gcc dot gnu dot org 2005-11-19 21:36 ---
Subject: Bug 24862
Author: jb
Date: Sat Nov 19 21:36:06 2005
New Revision: 107228
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107228
Log:
fortran ChangeLog:
2005-11-19 Janne Blomqvist <[EMAI
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-19 22:03 ---
Subject: Bug 24862
Author: jb
Date: Sat Nov 19 22:03:41 2005
New Revision: 107234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107234
Log:
fortran ChangeLog:
2005-11-20 Janne Blomqvist <[EMAI
--- Comment #8 from jb at gcc dot gnu dot org 2005-11-20 14:46 ---
The above commit to trunk and 4.1 should fix this issue.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jb at gcc dot gnu dot org 2005-11-20 21:39 ---
rth committed a fix to trunk and 4.1:
http://gcc.gnu.org/ml/fortran/2005-11/msg00548.html
It should now work again on all supported platforms.
Unless new problems are reported I'll close this in a few
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-21 16:01 ---
Just as a general note, the deadline for dwarf3 comments is Dec 1, 2005. So if
anyone with some clue about how to improve support for debugging fortran has
some good suggestions that would require changes in the debug
--- Comment #10 from jb at gcc dot gnu dot org 2005-11-22 08:59 ---
With the fix by rth, it seems to work again on Solaris (#9) and Darwin (
http://gcc.gnu.org/ml/fortran/2005-11/msg00571.html ); closing the bug.
--
jb at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from jb at gcc dot gnu dot org 2005-11-24 13:38 ---
Just to be sure, you should be building outside the gcc directory hierarchy.
This is (a cleaned up version of the) script I use for doing a clean build:
#!/bin/sh
GCCDIR=trunk
cd $GCCDIR
contrib/gcc_update
cd ..
rm
c
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
GCC build triplet: i68
n: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: jb at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25036
--- Comment #1 from jb at gcc dot gnu dot org 2005-11-25 19:13 ---
Also, g77 (and pathscale and ifort) support reopening files with
status='unknown'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25036
--- Comment #2 from jb at gcc dot gnu dot org 2005-11-25 20:39 ---
Patch here: http://gcc.gnu.org/ml/fortran/2005-11/msg00677.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25036
--- Comment #3 from jb at gcc dot gnu dot org 2005-11-26 08:52 ---
*** Bug 25036 has been marked as a duplicate of this bug. ***
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-26 08:52 ---
This seems to be a duplicate of PR 24945. Sorry.
*** This bug has been marked as a duplicate of 24945 ***
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-26 09:12 ---
Subject: Bug 24945
Author: jb
Date: Sat Nov 26 09:12:36 2005
New Revision: 107538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107538
Log:
libgfortran ChangeLog:
2005-11-26 Janne Blomqvist <[EMAI
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-26 09:27 ---
Subject: Bug 24945
Author: jb
Date: Sat Nov 26 09:27:22 2005
New Revision: 107539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107539
Log:
libgfortran ChangeLog:
2005-11-26 Janne Blomqvist <[EMAI
--- Comment #6 from jb at gcc dot gnu dot org 2005-11-26 09:32 ---
Subject: Bug 24945
Author: jb
Date: Sat Nov 26 09:32:21 2005
New Revision: 107540
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107540
Log:
testsuite ChangeLog:
2005-11-26 Janne Blomqvist <[EMAI
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-29 18:37 ---
It doesn't have anything to do with array transfers. The following test program
is equivalent to the one in #3, but uses the scalar transfer_integer instead of
transfer_array:
program test3
integer dat(5)
dat =
--- Comment #7 from jb at gcc dot gnu dot org 2005-12-04 22:39 ---
No problems have been reported with the patch, closing the bug as fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jb at gcc dot gnu dot org 2005-12-10 16:17 ---
Confirmed. I guess this is because rec=n is transferred to the library as a
gfc_integer_4, but it should be gfc_offset.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
ONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25377
--- Comment #2 from jb at gcc dot gnu dot org 2005-12-13 16:13 ---
Unfortunately the goto blas library where I noticed this error is not free
software. But here is a simple testcase that shows the same problem.
File hello.c:
#include
#include
#include
#define NUM_THREADS 2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-li
--- Comment #3 from jb at gcc dot gnu dot org 2005-12-14 18:29 ---
VASP is a commercial code, you shouldn't post large portions of it here.
FWIW, I have been able to compile and run vasp with trunk as of October 2005.
IIRC it never worked with gfortran 4.0.
--
http://gcc.gn
--- Comment #2 from jb at gcc dot gnu dot org 2005-12-14 18:40 ---
Richard Guenther made a patch to get rid of gfc_conv_function_call and replace
all usage of it with build_function_call_expr:
http://gcc.gnu.org/ml/fortran/2005-12/msg00235.html .
If we're lucky that patch migh
--- Comment #4 from jb at gcc dot gnu dot org 2005-12-15 06:18 ---
(In reply to comment #3)
> I doubt it, this seems to be about gfc_conv_function_call.
>
Oh, right, your patch replaces gfc_build_function_call and not
gfc_conv_function_call. Sorry for the confusion.
--
ntually get rid of the Alloc Stream Facility
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: jb at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu do
--- Comment #9 from jb at gcc dot gnu dot org 2006-01-06 14:47 ---
Reopening since many of the intrinsics could still vectorize better.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jb at gcc dot gnu dot org 2006-01-07 17:58 ---
Confirmed.
Incidentally, you can find the final draft of F2003 (which differs very little
from the published standard) at
http://www.j3-fortran.org/doc/year/04/04-007.pdf
--
jb at gcc dot gnu dot org changed
--- Comment #3 from jb at gcc dot gnu dot org 2006-01-07 18:02 ---
Confirmed
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-07 18:09 ---
Actually, you got the syntax slightly wrong (sorry for not noticing it right
away).
The standard (and from my reading of the ibm docs it seems that they agree with
the standard) specifices the use statement as
use
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
OtherBugsDependingO 20585,25561
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25828
nhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
OtherBugsDependingO 20585,25561
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
jb at gcc dot gnu dot org
OtherBugsDependingO 18918,25561
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830
--- Comment #1 from jb at gcc dot gnu dot org 2006-01-17 22:07 ---
Change severity to enhancement.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jb at gcc dot gnu dot org 2006-01-17 22:10 ---
Switched dependencies to the correct order.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-20 17:57 ---
Confirmed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from jb at gcc dot gnu dot org 2006-07-19 16:52 ---
Subject: Bug 27919
Author: jb
Date: Wed Jul 19 16:51:49 2006
New Revision: 115593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115593
Log:
2006-07-19 Janne Blomqvist <[EMAIL PROTECTED]>
--- Comment #5 from jb at gcc dot gnu dot org 2006-07-19 16:52 ---
Subject: Bug 27919
Author: jb
Date: Wed Jul 19 16:52:45 2006
New Revision: 115594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115594
Log:
2006-07-19 Janne Blomqvist <[EMAIL PROTECTED]>
--- Comment #6 from jb at gcc dot gnu dot org 2006-07-19 21:13 ---
Above commit remove dot_product from libgfortran, and this this PR should be
fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jb at gcc dot gnu dot org 2006-08-16 19:09 ---
(In reply to comment #3)
> Isn't this fixed as Steve bumped 4.2/TRUNK to libgfortran.so.2 ?
>
Umm, no. Symbol versioning is still not implemented. As you can see in the
thread starting from the patch subm
--- Comment #10 from jb at gcc dot gnu dot org 2006-08-20 09:22 ---
Subject: Bug 25828
Author: jb
Date: Sun Aug 20 09:22:04 2006
New Revision: 116271
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116271
Log:
2006-08-20 Janne Blomqvist <[EMAIL PROTECTED]>
ot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
--- Comment #4 from jb at gcc dot gnu dot org 2007-01-30 23:06 ---
As an aside, aren't -Wtabs and -Wno-tabs reversed? Now -Wno-tabs warns against
tabs, but shouldn't it be -Wtabs that warns against using them and -Wno-tabs
should turn the warning off?
--
http://g
--- Comment #6 from jb at gcc dot gnu dot org 2007-02-01 11:30 ---
Right, I guess that's an equally valid POV. Thus, I don't think it's worth the
trouble to reverse them and confuse our users.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
--- Comment #11 from jb at gcc dot gnu dot org 2007-04-18 19:05 ---
(In reply to comment #10)
> > What happend to this? I can't find the patch in the tracker anymore, but
> > there's no indication in the ChangeLog(s) that is was applied.
>
> The last patc
--- Comment #12 from jb at gcc dot gnu dot org 2007-04-18 19:49 ---
> The reason why the patch is in limbo (besides me being busy with real life :(
> )
> is that while it worked fine under Linux, it turned out that it doesn't work
> on
> many other platforms sinc
--- Comment #14 from jb at gcc dot gnu dot org 2007-04-20 07:45 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01253.html
Also removed the dependency on PR25709 (ISO_C_BINDING), since we don't depend
on that one anymore for this functionality.
--
jb at gcc dot gn
--- Comment #15 from jb at gcc dot gnu dot org 2007-04-24 10:09 ---
Subject: Bug 27740
Author: jb
Date: Tue Apr 24 10:08:52 2007
New Revision: 124098
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124098
Log:
2007-04-24 Janne Blomqvist <[EMAIL PROTECTED]>
--- Comment #7 from jb at gcc dot gnu dot org 2007-04-25 09:41 ---
BTW, here's some slides describing NAG:s experience, they use lazy symbol
lookup combined with caching, and claim it is up to 1000 times faster than
non-lazy (which gfortran uses AFAICS).
http://www.fortran.bcs.org
--- Comment #1 from jb at gcc dot gnu dot org 2007-04-26 10:36 ---
Confirmed. It occurs also on i686-pc-linux-gnu.
My observations:
- -march specific optimizations do not seem to have any effect. What does have
an effect is that on i686-pc-linux-gnu I need either -march= or -msse2 or
--- Comment #2 from jb at gcc dot gnu dot org 2007-04-26 10:47 ---
FYI, I am unable to confirm this on i686-pc-linux-gnu. aermod seems to work no
matter what switches I throw at the compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31697
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
1 - 100 of 269 matches
Mail list logo
