--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-13 08:19
---
Subject: Bug 21435
Author: fxcoudert
Date: Fri Oct 13 08:18:50 2006
New Revision: 117685
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117685
Log:
PR fortran/21435
* io.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-13 08:22
---
And now, we even diagnose this at compile-time on mainline. Closing this PR
accordingly.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-13 08:33
---
Not worth a backport. Closing as fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-10-13 12:20
---
Subject: Bug 29391
Author: fxcoudert
Date: Fri Oct 13 12:20:28 2006
New Revision: 117691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117691
Log:
PR fortran/29391
* trans-intrinsic.c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail|4.2.0 4.1.2 |4.1.2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: fxcoudert at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-10-15 08:40
---
(In reply to comment #10)
This trimmed down example is invalid code. The if (i0)
statement tries to use before it is defined.
Sorry about that: the following code is valid, and also fails to compile
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-10-17 10:45
---
LBOUND and UBOUND also need to be fixed in simplify.c:
program fred
call jackal (3, 2)
contains
subroutine jackal (b, c)
integer :: b, c
integer :: soda(b:c, 1:2)
print *, SIZE = , size(soda
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-17 10:45
---
(In reply to comment #1)
I have seen what the problem is, in the meantime: LBOUND (soda, 2) is being
processed in simplify.c(simplify_bound), which does not kow about your middle
end mods!
Hum, I knew I
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2006-10-17 13:01
---
Hurray! I can now also reproduce this on x86_64-linux with ElectricFence. Run
f951 inside gdb and preload ElectricFence (in gdb: set environment LD_PRELOAD
/usr/lib64/libefence.so). The segfault backtrace
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-18 12:31
---
The Fortran people are interested in this. For full F2003 support, we need the
Fortran front-end to know during code generation which integer mode correspond
to certain C integer types, including the int_fastN_t
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:50
---
Confirmed, and Andrew will soon have a patch for this.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:52
---
(In reply to comment #6)
Since you are actively working on this, I have reassigned it to you. I hope
that's OK?
It was OK, but I spent time looking at it and looking again, and I can't figure
it out
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:59
---
Fixed on 4.2, won't backport to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:59
---
Fixed on 4.2, won't backport to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-18 21:02
---
Paul, I need to be Enlightened as to why the gfc_evaluate_now statements in
your patch are needed here. If and when you have a little time, that is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-18 22:05
---
Yet another bug found, yet another patch. I think this one is the last:
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 117862
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-19 09:07
---
So that it doesn't get lost, here's another UBOUND problem:
$ cat a.f90
subroutine foo (x,n)
integer x(7,n,2,*)
print *, ubound(x,1)
print *, ubound(x,2)
print *, ubound(x,3)
! print *, ubound(x,4
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC target triplet: i386-apple-darwin8.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-19 21:49
---
Subject: Bug 27895
Author: fxcoudert
Date: Thu Oct 19 21:48:50 2006
New Revision: 117890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117890
Log:
PR libfortran/27895
* intrinsics
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-10-19 21:59
---
It's still not working for RESHAPE. Uncomment the test_reshape line in the
newly added zero_sized_1.f90 test and see how it fails :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-19 22:16
---
The generated code emitted for the TRANSPOSE for i386-darwin is stupid:
atmp.13.dtype = parm.12.dtype;
atmp.13.dim[0].stride = parm.12.dim[1].stride;
atmp.13.dim[0].lbound = parm.12.dim[1].lbound
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-21 17:30
---
It's an enhancement (and actually, it's being worked on).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-21 17:39
---
Thomas, isn't the 4.3 branching a good time to work on this? Would you have
time for that?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:15
---
(In reply to comment #1)
- A compile-time-error is shown (probably fixed by FX patch, not checked)
Yes, it's fixed by my patch. Confirming this bug.
Tobias, if you want to submit a global patch to resolve
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:18
---
No, it's implemented, it's only that the subroutine and function with the same
name cannot be called in the same scoping unit.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:19
---
Confirmed.
This one will probably be implemented after ISO_C_BINDING.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:42
---
Subject: Bug 26025
Author: fxcoudert
Date: Sun Oct 22 07:41:48 2006
New Revision: 117948
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117948
Log:
PR fortran/26025
* lang.opt: Add
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:43
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-22 07:45
---
I don't think we want to have a real .mod file somewhere, but I know how I'll
implement it internally. I'll do it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-22 12:26
---
Fixed in 4.2 and later, thanks to Tobias.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-22 18:45
---
The current code already recognizes matrix transposition and gives BLAS gemm
functions the right TRANSA and TRANSB argument in this case.
Confirmed for CONJG, which we don't currently handle.
--
fxcoudert
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-22 21:01
---
Having thought about it some more, MODULO should be implemented using
fmod{f,,l} and MOD should use remainder{f,,l}. See how BUILT_IN_POWL is used,
for example, to emit the same kind of code
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-22 23:14
---
I've been thinking a bit about this. It's a common case, and it would probably
be worth optimizing it.
We could detect in iresolve.c (gfc_resolve_matmul) that one (or both) of the
arguments to MATMUL is a call
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 06:19
---
Created an attachment (id=12477)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12477action=view)
Example patch
I don't know if it's giving correct results in all cases, or if it works even
on platforms
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-23 17:11
---
Further reduced testcase, confirmed on ppc-darwin:
type element_t
integer :: gid
end type element_t
type(element_t) :: element(1)
call hash_read_key(element%gid)
call hash_read_key(element%gid
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:05
---
(In reply to comment #4)
Can this PR be closed?
I'd say yes.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:07
---
Fixed on 4.2 branch and probably earlier:
In file a.f90:1
integer*1 :: i1 = 255_1
1
Error: Integer too big for its kind at (1)
In file a.f90:2
integer*2 :: i2 = 65535_2
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:28
---
We now reject the reporter's code as we should. We could still reject the code
in comment #1, but none of the other compilers I tried reject it. Marking this
as low priority (I think it will be fixed by Paul
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-23 21:56
---
(In reply to comment #2)
We could detect in iresolve.c (gfc_resolve_matmul) that one (or both) of the
arguments to MATMUL is a call to CONJ, and then rewrite the code to be
MATMUL(A,B,2) instead of MATMUL
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 29321
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 29284
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 29322
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 25091
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 25092
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-24 22:51
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-25 08:19
---
I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :)
(In reply to comment #6)
Revision 118024 clears the way for MOD and MODULO implementation:
http://gcc.gnu.org/ml/gcc-cvs/2006-10
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-25 13:53
---
(In reply to comment #8)
In the later case, expansion will fall-back to normal library call.
OK. So on system where the math library doesn't have remainderl, for example,
we shouldn't use BUILT_IN_REMAINDERL
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
OtherBugsDependingO 20585
nThis:
http
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
OtherBugsDependingO 20585
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29601
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
OtherBugsDependingO 20585
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29602
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
BugsThisDependsOn: 29539
http://gcc.gnu.org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-29 10:45
---
An ICE at the same line of code was reported as PR 29634. Maybe your patch
fixes both?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29539
at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
OtherBugsDependingO 24546
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-29 14:19
---
Hi Janne,
As we've discussed on IRC, the inclusion of the ISO_C_BINDING patch is still
uncertain. For other work (implementation of the IEEE intrinsic modules), I've
felt the need to add an option to gfortran
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-29 14:20
---
Created an attachment (id=12507)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12507action=view)
Patch implementing namespace separation, to go with symbol versioning
--
http://gcc.gnu.org/bugzilla
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-30 08:30
---
(In reply to comment #3)
real c
if (loc(c) == 0) call abort
end
This one has been fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-30 12:16
---
The rename-list works, it's only the F2003 USE :: that prevents it in your
example. This is already tracked by PR 25707, and I submitted a patch to fix
this (see http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01539
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-30 12:16
---
*** Bug 29643 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-30 12:18
---
Once my patch for pre-compiled intrinsic modules is reviewed (which should be
soon) and when ISO_C_BINDING is integrated (which might take a little longer),
it will be almost trivial to integrate your module
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-30 12:24
---
I think it's better to file it with the library.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-30 14:24
---
(In reply to comment #7)
- ASYNCHRONOUS: 'YES', 'NO'
- BLANK: 'NULL', 'ZERO'
- DECIMAL: 'COMMA', 'POINT'
- DELIM: 'APOSTROPHE', 'QUOTE', 'NONE
- PAD: 'YES', 'NO'
- ROUND: 'UP', 'DOWN', 'ZERO', 'NEAREST
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-10-30 16:46
---
The following patch fixes the problem:
Index: data.c
===
--- data.c (revision 118134)
+++ data.c (working copy)
@@ -155,7 +155,8
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-31 00:09
---
Created an attachment (id=12516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12516action=view)
Tentative patch
This patch doesn't work :)
It's working fine except that the following code:
implicit
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: fxcoudert at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
BugsThisDependsOn: 25708
http://gcc.gnu.org/bugzilla
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-31 07:00
---
(In reply to comment #2)
I have proposed to introduce module namespaces that are built just once per
compiled file per module; either from source or a mod file. Subsequent usage
can lift the symbol
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:01
---
(In reply to comment #3)
coredumping is easy, simply call abort() or kill(0,SIGSEGV)
The usual signal to request a core dump is SIGQUIT.
However, I'm more a fan of either coredumping
Same opinion here
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:46
---
(In reply to comment #16)
I understood that remainder (a, b) = a - round (a/b) * b, whereas
mod (a, b) = a - int (a/b) * b
and modulo (a, b) = a - floor (a/b) * b
Right you
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:05
---
(In reply to comment #14)
It also does MODULO correctly
Why not use remainder{f,,l}? Is it incorrect?
although I am not sure that I understand why anybody
would use this intrinsic knowingly!
Agreed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:02
---
Created an attachment (id=12519)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12519action=view)
Example of how to use unwind for backtrace purposes
The patch I was quoting in my previous comment; here
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-10-31 20:15
---
Subject: Bug 29067
Author: fxcoudert
Date: Tue Oct 31 20:15:22 2006
New Revision: 118338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118338
Log:
PR fortran/29067
* decl.c
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-01 08:03
---
Does not appear in the recent published testresults (eg
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01392.html).
Is this regression still there?
--
fxcoudert at gcc dot gnu dot org changed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-01 08:16
---
Using gfortran-4.1.1, I tried to reproduce your bug by adding a file foo.f90,
but can't:
$ cat foo.f90
use ackland
use ackland_zbl
use alloys
use bcc
use constants
use filter
use inifile
use materials
use
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-02 09:47
---
(In reply to comment #1)
I presented a patch for this problem and for detected unassigned r-values that
was rejected. I don't know what to say; I think that it's a bug, in
principle,
but the standard does
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-02 14:34
---
Some incomplete patch proposals here:
http://gcc.gnu.org/ml/fortran/2006-10/msg00825.html and there:
http://gcc.gnu.org/ml/fortran/2006-11/msg00017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-11-02 23:52
---
We can fork+exec addr2line, but we can't link libbfd because it's GPL.
It was mentionned on IRC tonight that Daniel Berlin has a library that extracts
line and file information from DWARF2 info. It's internal
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-11-03 11:51
---
Subject: Bug 27895
Author: fxcoudert
Date: Fri Nov 3 11:51:09 2006
New Revision: 118455
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118455
Log:
PR libfortran/27895
* intrinsics
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-11-03 12:24
---
The patch in comments 10 and 12 will need to be backported to 4.2 and 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-11-03 12:29
---
Subject: Bug 29067
Author: fxcoudert
Date: Fri Nov 3 12:28:57 2006
New Revision: 118456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118456
Log:
PR fortran/29067
* decl.c
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-11-03 14:11
---
Adding %REF and %DESCR to the summary. Documentation available here:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Functions-and-Subroutines.html
--
fxcoudert at gcc dot gnu dot org changed:
What
101 - 200 of 3175 matches
Mail list logo
