AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27269
--- Comment #1 from tobi at gcc dot gnu dot org 2006-04-23 11:45 ---
Since I still have it on my screen:
(gdb) p eq->expr->where->nextc-18
$6 = 0x8708de9 " use cross_section"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27269
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from tobi at gcc dot gnu dot org 2006-04-26 16:46 ---
Works for me, even though the warning could be a bit more verbose. Should this
really be a default warning?
[EMAIL PROTECTED]:~/src/pr/27327> gfortran t.f90 -Wall -c
t.f90: In function 'opt1':
t.f
--- Comment #1 from tobi at gcc dot gnu dot org 2006-05-06 16:01 ---
Mine. I'm currently testing a patch
--
tobi at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from tobi at gcc dot gnu dot org 2006-05-07 13:46 ---
Subject: Bug 27457
Author: tobi
Date: Sun May 7 13:46:02 2006
New Revision: 113602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113602
Log:
fortran/
PR fortran/27457
* match.c (match_case_eos): Erro
--- Comment #4 from tobi at gcc dot gnu dot org 2006-05-07 13:47 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|19292
--- Comment #3 from tobi at gcc dot gnu dot org 2006-05-08 10:46 ---
reduced testcase (not valid, but this is another bug):
i = j; end
This bug has nothign to do with parsing of STOP, it needs:
* a statement preceding the end statement, and
* the end statement must follow a
--- Comment #4 from tobi at gcc dot gnu dot org 2006-05-08 10:49 ---
woops, of course I decided to make a valid testcase after I wrote that it
wouldn't be valid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20440
--- Comment #5 from tobi at gcc dot gnu dot org 2006-05-08 12:59 ---
Wow. This is actually a bad bug, but after trying some stuff, I believe that
it only does bad things when the code is non-standard anyway (lines beginning
with ';').
E.g.
[EMAIL PROTECTED]:~/src/pr/2044
--- Comment #3 from tobi at gcc dot gnu dot org 2006-05-09 09:41 ---
I don't mind putting it back in, Jim described what needs to be done in
PR24357. I don't have a ratfor processor to test with, so I'd prefer if
someone else wrote (i.e. copied from gcc < 4.0) and te
--- Comment #4 from tobi at gcc dot gnu dot org 2006-05-18 14:40 ---
Paul, I've looked at the patch and it looks ok. You don't seem to have posted
it, at least it's not in the patch tracker. Did you find any problems
associated with it?
--
tobi at gcc dot gnu
--- Comment #7 from tobi at gcc dot gnu dot org 2006-05-18 16:36 ---
Paul, you didn't ask yourself to the CC lsit, so you missed Volker's comments.
--
tobi at gcc dot gnu dot org changed:
What|Removed
rtedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28172
--- Comment #7 from tobi at gcc dot gnu dot org 2006-06-29 17:05 ---
I don't see an internal error any longer, closing as WORKSFORME.
--
tobi at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from tobi at gcc dot gnu dot org 2006-06-29 17:43 ---
Testing a patch.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from tobi at gcc dot gnu dot org 2006-07-01 15:03 ---
Subject: Bug 19259
Author: tobi
Date: Sat Jul 1 15:03:30 2006
New Revision: 115115
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115115
Log:
2006-07-01 Tobias Schlueter <[EMAIL PROTECTED]>
--- Comment #5 from tobi at gcc dot gnu dot org 2006-07-02 18:12 ---
Fixed on the mainline.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tobi at gcc dot gnu dot org 2008-12-15 17:37 ---
According to your readings, is the following valid?
DO 10 I=1,10
IF (.TRUE.) THEN
10 END IF
END
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #7 from tobi at gcc dot gnu dot org 2008-12-15 19:16 ---
(In reply to comment #6)
> (In reply to comment #5)
> > According to your readings, is the following valid?
> > DO 10 I=1,10
> > IF (.TRUE.) THEN
> > 10 END IF
> >END
&g
--- Comment #3 from tobi at gcc dot gnu dot org 2009-05-08 18:53 ---
Note that the C-like equivalent doesn't warn (at least with g++ 4.1.2):
$ cat user/t.cc
namespace {
struct {
} t;
}
static struct {
} s;
$ g++ -c user/t.cc
user/t.cc:3: warning: non-local variable '::
--- Comment #12 from tobi at gcc dot gnu dot org 2009-05-19 15:55 ---
Add an ampersand (&)
(In reply to comment #11)
> write(*,*)kandidat, ' ist nicht Teiler' &
here ^^
and be sure to read the section on conti
--- Comment #14 from tobi at gcc dot gnu dot org 2009-05-26 09:38 ---
- you're lacking a comma before the place I asked you to add an ampersand,
sorry I missed that
- g95 is not gfortran
- please direct beginner's questions somewhere more appropriate
--
http://gcc.gnu.or
--- Comment #9 from tobi at gcc dot gnu dot org 2009-08-12 20:52 ---
Side remark:
DO i = 1,10
call bar(i)
END DO
wouldn't be valid if bar changed its argument, i.e. the compiler should
generate the same, better code it does for the case where you copy the argument
(bar((i))
--- Comment #12 from tobi at gcc dot gnu dot org 2009-08-13 13:39 ---
(In reply to comment #11)
> DO i = 1,10
> call bar(i)
> END DO
>
> if bar may not modify i then the frontend can simply communicate that to the
> middle-end by doing
>
> DO i = 1,10
--- Comment #6 from tobi at gcc dot gnu dot org 2005-11-05 23:06 ---
I did some further research, and while g77 didn't seem to have documented any
of the details of how LOGICALs are implemented, we have the following in
gfortran.texi:755:
@node Implicitly interconvert LOGICA
--- Comment #9 from tobi at gcc dot gnu dot org 2005-11-06 00:22 ---
One can get quite interesting results out of g77, e.g.
[EMAIL PROTECTED]:~/src/tests> cat ugly.f
LOGICAL L, M
equivalence (i,l)
DO i=0,5
M = i
PRINT "(5l2)", l, m,
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-07 12:58 ---
I'm marking this ice-on-invalid-code, as it is not valid Fortran 95 and the bug
is unrelated to the use of IMPORT, the following ICEs the same way:
module gfcbug29_import
interface
subroutine f
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-07 13:07 ---
(In reply to comment #3)
> Thank you Salvatore and Andrew.
>
> The proposed patch is about to be posted on the fortran and gcc-patches list.
> I just have a couple more minutes of testing other, comple
--- Comment #1 from tobi at gcc dot gnu dot org 2005-11-07 13:09 ---
Is this still the case? No other platform seems to be affected.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tobi at gcc dot gnu dot org 2005-11-07 14:49 ---
While the original problem seems to have been fixed, we have a regression here:
if we comment out the line marked as "this works" everything compiles fine and
we get an executable that works (doesn't s
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-07 23:56 ---
I'm adding FX to the CC list, because this looks like it's related to his patch
for FPU exceptions.
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from tobi at gcc dot gnu dot org 2005-11-08 20:55 ---
Correction: implicit types are only assigned during resolution. The issue is:
why does it reject the second statement if the RHS object already exists, but
not otherwise?
--
http://gcc.gnu.org/bugzilla
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24748
--- Comment #11 from tobi at gcc dot gnu dot org 2005-11-08 23:58 ---
Patch posted.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|toon
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-09 18:40 ---
*** This bug has been marked as a duplicate of 24755 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-09 18:40 ---
*** Bug 24655 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24646
--- Comment #12 from tobi at gcc dot gnu dot org 2005-11-10 21:49 ---
Subject: Bug 24643
Author: tobi
Date: Thu Nov 10 21:49:29 2005
New Revision: 106753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106753
Log:
fortran/
PR fortran/24643
* primary.c (match_varspec): C
--- Comment #13 from tobi at gcc dot gnu dot org 2005-11-10 23:10 ---
Subject: Bug 24643
Author: tobi
Date: Thu Nov 10 23:10:51 2005
New Revision: 106757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106757
Log:
Backport r106753
fortran/
PR fortran/24643
* p
--- Comment #14 from tobi at gcc dot gnu dot org 2005-11-10 23:11 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-10 23:15 ---
*** This bug has been marked as a duplicate of 24643 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from tobi at gcc dot gnu dot org 2005-11-10 23:15 ---
*** Bug 22048 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-16 10:58 ---
Subject: Bug 24357
Author: tobi
Date: Wed Nov 16 10:58:41 2005
New Revision: 107078
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107078
Log:
PR 24357
* doc/invoke.texi: Distinguish
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-16 11:00 ---
Fixed on the trunk, 4.0 is still waiting for approval.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-18 12:59 ---
I think that the following patch is the one responsible:
2005-05-15 Andreas Jaeger <[EMAIL PROTECTED]>
* m4/eoshift1.m4: Initialize variables to avoid warnings.
* m4/eoshift3.m4: Init
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25018
4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25034
ion dummy argument not
caught
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Repor
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** This bug has been marked as a duplicate of 20857 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** Bug 25074 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** This bug has been marked as a duplicate of 20857 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** Bug 20859 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
--- Comment #4 from tobi at gcc dot gnu dot org 2005-12-07 16:49 ---
These all amount to the same problem. Being a bit more descriptive would also
make searching for duplicates easier.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from tobi at gcc dot gnu dot org 2005-12-08 12:41 ---
The lines are padded (see scanner.c:810), but this doesn't make it into the
format string, which could be construed to be a bug, but since this is not
something required by the standard (at least I think this wa
--- Comment #14 from tobi at gcc dot gnu dot org 2005-12-22 11:37 ---
Subject: Bug 18990
Author: tobi
Date: Thu Dec 22 11:37:03 2005
New Revision: 108946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108946
Log:
fortran/
PR fortran/18990
* gf
--- Comment #15 from tobi at gcc dot gnu dot org 2005-12-22 16:36 ---
Fixed on the mainline, will commit to 4.1 soon.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from tobi at gcc dot gnu dot org 2005-12-24 13:21 ---
Subject: Bug 18990
Author: tobi
Date: Sat Dec 24 13:20:56 2005
New Revision: 109040
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109040
Log:
Backport r108946 from the trunk
fortran/
PR fortr
--- Comment #17 from tobi at gcc dot gnu dot org 2005-12-24 13:23 ---
Fixed on 4.1 as well.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tobi at gcc dot gnu dot org 2005-12-30 14:11 ---
Paul, I was wondering why you added this PR to the ChangeLogs, as it's still
present, or has the bug reappeared?
--
tobi at gcc dot gnu dot org changed:
What|Removed |
--- Comment #7 from tobi at gcc dot gnu dot org 2005-12-31 16:39 ---
Fixed. BTW, Erik, you can use svn merge to backport patches to the older
branches. That would save you "svn add"ing them on all branches.
--
tobi at gcc dot gnu dot org changed:
What
--- Comment #7 from tobi at gcc dot gnu dot org 2006-01-04 20:32 ---
Toon posted an updated patch here:
http://gcc.gnu.org/ml/fortran/2006-01/msg00048.html
(Toon, I had Andrew add you to the CC list, because somehow I couldn't, and I
think dicussion of the patch should either
--- Comment #17 from tobi at gcc dot gnu dot org 2006-01-08 13:18 ---
Instead of continuing a pointless flame war in a PR which is only
organisationally related to the bug we're talking about, let me explain a few
procedural details which will hopefully make you understand that
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-08 21:42 ---
No, this is not sufficient, because you'll still need to find the label, unless
we have some gross code duplication that I'm not aware of. What needs to be
done is adding a search through the entire program
--- Comment #14 from tobi at gcc dot gnu dot org 2006-01-09 16:46 ---
Coming to think of it, I think that while your speedup would work, it would
probably be easier and even faster if we kept track of the enclosing blocks
while building the blocks and labels, so that the data structure
--- Comment #15 from tobi at gcc dot gnu dot org 2006-01-09 16:50 ---
Forgot to say: the validity check would then look like:
for (b = code->block: b != NULL; b = b->enclosing_block)
if (b == label->block)
/* valid GOTO */
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #17 from tobi at gcc dot gnu dot org 2006-01-09 18:56 ---
(In reply to comment #16)
> The idea of comment #14 and #15 looks better than mine, yes.
I'll continue what I've started, then.
> Which bug is the slowness bug btw? We should really be discussing
--- Comment #7 from tobi at gcc dot gnu dot org 2006-01-09 18:57 ---
Discussion on how to fix this has taken place in PR18540.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tobi at gcc dot gnu dot org 2006-01-10 00:10 ---
(In reply to comment #9)
> We don't get an error message but instead we call _gfortran_internal_malloc
> with a zero value and invoked undefined behavior in malloc.
No. This is specifically guarded agai
--- Comment #5 from tobi at gcc dot gnu dot org 2006-01-10 00:12 ---
All dependencies have been fixed. Closing. If anybody ever gets access to new
SPEC sources, they're free to open a new one.
--
tobi at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from tobi at gcc dot gnu dot org 2006-01-11 14:26 ---
Also fails on i686.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #2 from tobi at gcc dot gnu dot org 2006-01-11 14:29 ---
I'm quite sure it's not, but it would be a first, if Joost were wrong. Is
there anything special about parameters? Something like
real x
common /x/ y
or even
common /x/ x
is perfectly valid.
--
--- Comment #2 from tobi at gcc dot gnu dot org 2006-01-11 14:36 ---
I think the problem is that I does not live in a common block, but i don't have
the standard to check.
--
tobi at gcc dot gnu dot org changed:
What|Removed |
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from tobi at gcc dot gnu dot org 2006-01-11 16:38 ---
I forgot to say that g77 accepts this even with -pedantic. But this is
undocumented and doesn't make much sense, so we can probably do away with it
without alienating anybody.
--
http://gcc.gnu.org/bug
--- Comment #6 from tobi at gcc dot gnu dot org 2006-01-12 00:18 ---
I'm setting this to waiting until someone quotes something from the standard.
Fortran has its quirks, but disallowing this special case would break the
distintion between the names of commons and those of other
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-12 10:13 ---
Thanks, Steve.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #18 from tobi at gcc dot gnu dot org 2006-01-18 20:54 ---
Subject: Bug 18540
Author: tobi
Date: Wed Jan 18 20:54:49 2006
New Revision: 109914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914
Log:
PR fortran/18540
PR fortran/18937
* gfortran.h (BBT_HEADE
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-18 20:54 ---
Subject: Bug 18937
Author: tobi
Date: Wed Jan 18 20:54:49 2006
New Revision: 109914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914
Log:
PR fortran/18540
PR fortran/18937
* gfortran.h (BBT_HEADE
--- Comment #9 from tobi at gcc dot gnu dot org 2006-01-18 21:07 ---
The committed patch fixes only part of the problem, this is still a quadratic
bottleneck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Comment #19 from tobi at gcc dot gnu dot org 2006-01-18 21:08 ---
Fixed on the mainline. I will backport the cross-jumping part to 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
--- Comment #3 from tobi at gcc dot gnu dot org 2006-09-13 16:06 ---
This is intriguing. Why would 'end' be treated any different from 'xxx'?
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from tobi at gcc dot gnu dot org 2006-09-13 16:11 ---
This is another variation of the theme in 26227
*** This bug has been marked as a duplicate of 26227 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tobi at gcc dot gnu dot org 2006-09-13 16:11 ---
*** Bug 28443 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2006-09-13 16:12 ---
Again, the same theme as 26227.
*** This bug has been marked as a duplicate of 26227 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tobi at gcc dot gnu dot org 2006-09-13 16:12 ---
*** Bug 28809 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2006-09-14 10:59 ---
The difference is that 'end' appears in other contexts, see e.g. the difference
between these two testcases:
[EMAIL PROTECTED]:~/src/pr/28526> cat t.f90
module m
public function
interface functio
--- Comment #3 from tobi at gcc dot gnu dot org 2006-10-06 20:36 ---
Slightly reduced testcase, gives the same ice:
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSION(1,2) :: a
a
--- Comment #4 from tobi at gcc dot gnu dot org 2006-10-06 20:37 ---
Another interesting variation:
[EMAIL PROTECTED]:~/src/pr/29267> cat t.f90
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSION(1,2) :: a
a = reshape((/ to_string(1.0) /), (/ 1, 2 /))
END PROGRAM
[EM
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
--- Comment #5 from tobi at gcc dot gnu dot org 2006-10-06 21:01 ---
Actually this is invalid code. The string lengths in the constructor are
different, even though they have to be the same. See 4.5 in the F95 standard.
--
tobi at gcc dot gnu dot org changed:
What
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #7 from tobi at gcc dot gnu dot org 2006-10-09 11:14 ---
(In reply to comment #6)
> please try the testcase in the orignal PR with idental string lengths. It will
> crash gfortran as well.
Works for me. Please provide a testcase.
[EMAIL PROTECTED]:~/src/pr/29267>
--- Comment #2 from tobi at gcc dot gnu dot org 2006-10-09 11:34 ---
As I said, I ran into this when playing around with PR29267, and it was ugly
enough to warrant a PR of its own. Glad you share my opinion :-) Just to make
this clear: I would never do something this ugly outside
1 - 100 of 965 matches
Mail list logo
