--- Comment #1 from erik dot edelmann at iki dot fi 2006-11-13 07:42
---
Isn't this going to be allowed in F2008? (Perhaps it already is in F2003 --
I'm too lazy to check.) We should print an error message if strict standard
conformance is requested, but since it is going t
--- Comment #2 from erik dot edelmann at iki dot fi 2006-08-09 10:54
---
(In reply to comment #1)
> Actually this is worse than what is said here, this is wrong code. In a
> prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
> know at the time we a
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: erik dot edelmann at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
--- Comment #5 from erik dot edelmann at iki dot fi 2005-10-27 09:25
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00587.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24503
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-24 12:53
---
(In reply to comment #1)
> Here is what I get with the mainline of GCC:
> In file t.f90:12
>
> PUBLIC :: s_to_c
>1
> Error: 'string' is a PRIVATE type and cannot be
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-21 14:57
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00481.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-21 12:03
---
(In reply to comment #0)
> It reminds me a bit of bug 16606 but is different as the compiler crashes.
It's indeed basically the same problem as in PR 16606; we assign a default
initializer to variables of
--- Comment #6 from erik dot edelmann at iki dot fi 2005-10-18 20:50
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01079.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21625
--- Comment #5 from erik dot edelmann at iki dot fi 2005-10-17 13:14
---
Working on a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21625
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-13 14:49
---
Patch posted here: http://gcc.gnu.org/ml/fortran/2005-10/msg00292.html
--
erik dot edelmann at iki dot fi changed:
What|Removed |Added
--- Comment #4 from erik dot edelmann at iki dot fi 2005-10-12 12:54
---
(In reply to comment #3)
> Testing a patch.
Patch posted here: http://gcc.gnu.org/ml/fortran/2005-10/msg00229.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
--- Comment #4 from erik dot edelmann at iki dot fi 2005-10-12 12:09
---
I think that this PR is just a symptom of a more general problem: components
(of any kind) of a derived type are not initialized when a pointer/allocatable
variable of derived type is allocated. Also see PR 23924
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-12 12:00
---
*** Bug 23924 has been marked as a duplicate of this bug. ***
--
erik dot edelmann at iki dot fi changed:
What|Removed |Added
--- Comment #4 from erik dot edelmann at iki dot fi 2005-10-12 12:00
---
*** This bug has been marked as a duplicate of 21625 ***
--
erik dot edelmann at iki dot fi changed:
What|Removed |Added
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-11 18:11
---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
--- Comment #1 from erik dot edelmann at iki dot fi 2005-10-06 20:38
---
I think the ICE comes from dump-parse-tree.c/show_symtree() at the line
gfc_status (" from namespace %s", st->n.sym->ns->proc_name->name);
because st->n.sym->ns->proc_n
gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: erik dot edelmann at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-05 21:38
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00171.html
--
erik dot edelmann at iki dot fi changed:
What|Removed |Added
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-29
19:48 ---
(In reply to comment #5)
> Working on a patch.
Turned out to be much more work than I first thought. I'll leave it for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-27
15:21 ---
Working on a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-21
20:36 ---
Patch posted to the mailing list here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01359.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23843
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16
23:08 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01032.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16
23:07 ---
Patch posted to mailinglist:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01032.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15975
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16
21:59 ---
(In reply to comment #1)
> Hmm, I get:
> In file t.f90:2
>
> type t
>1
> Error: Pointer assignment target is neither TARGET nor POINTER at (1)
>
Oh! I'm terrib
: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: erik dot edelmann at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23924
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-06
21:10 ---
With my patch, the reduced testcase by Tobi compiles, but this slightly longer
testcase doesn't:
$ cat bug7.f90
SUBROUTINE A(p,LEN)
CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
IF (
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-02
11:56 ---
(In reply to comment #9)
> According to Erik Richard's patch for PR15326 fixes one of those two bugs (I
> assume the latter?), adding the dependency so that we will keep track of this.
Ye
--- Additional Comments From erik dot edelmann at iki dot fi 2005-08-30
20:28 ---
Hmm ... With current version of gfortran (4.1.0 20050830), the reduced testcase
by Tobias gives the error message
bug.f90: In function 'a':
bug.f90:3: internal compiler error: in gfc_trans_defe
--- Additional Comments From erik dot edelmann at iki dot fi 2005-08-23
19:54 ---
A patch for this bug has been posted to the mailing list:
http://gcc.gnu.org/ml/fortran/2005-08/msg00406.html
--
What|Removed |Added
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28
11:50 ---
This bug has been briefly discussed on the mailing list:
http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28
11:46 ---
(In reply to comment #2)
> A discussion on the mailing list on this bug here:
> http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html
Sorry about the above. That mailing list discussion is about a dif
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28
09:06 ---
(In reply to comment #12)
> > > interfaces. This brings me to a question: what is a "named interface"? I
>
> This is a nameless interface, isn't it?
>
> module
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-27
13:00 ---
(In reply to comment #7)
> Subject: Re: interface body has incorrect scope
>
> Paul, do you have any idea what find_special could be intended for? It seems
> obvious that it does the wrong
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-11
19:52 ---
> Erik,
>
> Have you checked the parse tree for this? It looks OK, from a very
> casual look, but the parse tree would be the clincher.
After comments from Tobi I posted a new patch
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-01
09:49 ---
A discussion on the mailing list on this bug here:
http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22146
35 matches
Mail list logo
