--- Comment #2 from tobi at gcc dot gnu dot org 2009-09-28 19:58 ---
The way usually recommended is to use a struct for interoperability with
Fortran common blocks, say http://support.microsoft.com/kb/51614
Unfortunately, the idiom "use a single variable common block, say commo
--- Comment #41 from tobi at gcc dot gnu dot org 2009-08-17 22:39 ---
(In reply to comment #40)
One more thing: my previous benchmarks were wrong, I had an error in my setup.
With a correct benchmark, polyhedron improves slightly in the testcases where
the change is outside the
--- Comment #40 from tobi at gcc dot gnu dot org 2009-08-17 22:08 ---
Created an attachment (id=18392)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18392&action=view)
Patch for savin function arguments
This patch copies do loops which are passed as actual argumen
--- Comment #39 from tobi at gcc dot gnu dot org 2009-08-16 17:00 ---
Sigh, with the patch capacita.f90 loses 4%. Your testcase really is nasty,
Thomas! :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #38 from tobi at gcc dot gnu dot org 2009-08-16 16:20 ---
Thanks(In reply to comment #37)
> Subject: Re: Invariant DO loop variables and subroutines
>
> On Sun, 2009-08-16 at 15:57 +0000, tobi at gcc dot gnu dot org wrote:
> > Now I only need to figure out h
--- Comment #36 from tobi at gcc dot gnu dot org 2009-08-16 15:57 ---
I have a patch which copies DO loop variables that are passed as arguments to
functions, which gives the same speedup as enclosing the arguments into
parentheses. Now I only need to figure out how to make that patch
--- Comment #31 from tobi at gcc dot gnu dot org 2009-08-15 09:51 ---
(In reply to comment #30)
> Escaping pointers for non-target dummy arguments can't happen in
> Fortran, can they? Could we just disable this (or ad a
> TREE_CANNOT_ALIAS flag to the middle end, which is
--- Comment #26 from tobi at gcc dot gnu dot org 2009-08-14 22:58 ---
(In reply to comment #25)
> (In reply to comment #23)
>
> Actually, you're right. In nested loops, there's no way without copying.
>
If it weren't for the outermost loop it would act
--- Comment #25 from tobi at gcc dot gnu dot org 2009-08-14 22:46 ---
(In reply to comment #23)
Actually, you're right. In nested loops, there's no way without copying.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #24 from tobi at gcc dot gnu dot org 2009-08-14 22:38 ---
(In reply to comment #23)
That's sad. I'm guessing that everytime it enters one of the inner loops, it
has to deal with the fact that the upper bound escaped. A way without all the
copying would be to
--- Comment #22 from tobi at gcc dot gnu dot org 2009-08-14 21:46 ---
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > From quickly looking at the code, the copy to real_to is probably
> > unnecessary
> > because loo
--- Comment #21 from tobi at gcc dot gnu dot org 2009-08-14 21:44 ---
(In reply to comment #19)
> (In reply to comment #17)
> From quickly looking at the code, the copy to real_to is probably unnecessary
> because loop bounds are passed through gfc_evaluate_now befor
--- Comment #20 from tobi at gcc dot gnu dot org 2009-08-14 21:31 ---
Created an attachment (id=18369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18369&action=view)
updated patch
Corrected patch, I copied the variables in the wrong order on loop entry,
clobbering th
--- Comment #17 from tobi at gcc dot gnu dot org 2009-08-14 19:55 ---
Created an attachment (id=18368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18368&action=view)
Speed up loops where the loop variable is used as function argument inside the
loop
This patch gives t
--- Comment #16 from tobi at gcc dot gnu dot org 2009-08-14 19:28 ---
Created an attachment (id=18367)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18367&action=view)
use const * when writing
Thomas, can you please test the attached patch with your testcase from comment
--- Comment #15 from tobi at gcc dot gnu dot org 2009-08-14 18:12 ---
I'm wondering if instead we can't simply mark all arguments to the transfer
functions in PRINT, WRITE and INTENT(IN) arguments as 'const *' instead of '*'.
Are there any reasons again
--- 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 #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 #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 #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 #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 #9 from tobi at gcc dot gnu dot org 2009-03-29 19:38 ---
Fixed on trunk.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from tobi at gcc dot gnu dot org 2009-03-29 17:16 ---
Subject: Bug 38507
Author: tobi
Date: Sun Mar 29 17:15:48 2009
New Revision: 145245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145245
Log:
fortran/
PR fortran/38507
* gfortran.h (gfc_st_label): Fix
--- 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
--
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 #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
--- Comment #3 from tobi at gcc dot gnu dot org 2008-08-17 12:43 ---
I've not had the time to finish this, and now I don't remember the details of
my analysis. Sorry, unassigning myself.
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from tobi at gcc dot gnu dot org 2008-08-10 20:43 ---
The GFORTRAN_STDOUT_UNIT environment variable mentioned above should make your
life a lot easier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
--- Comment #1 from tobi at gcc dot gnu dot org 2008-04-06 21:03 ---
I'm on it.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #3 from tobi at gcc dot gnu dot org 2008-04-06 19:27 ---
Fixed on the trunk.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from tobi at gcc dot gnu dot org 2008-04-06 18:59 ---
Subject: Bug 35832
Author: tobi
Date: Sun Apr 6 18:58:34 2008
New Revision: 133964
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133964
Log:
2008-04-06 Tobias Schlter <[EMAIL PROTECTED]>
PR
--- Comment #1 from tobi at gcc dot gnu dot org 2008-04-05 22:34 ---
I think I know how to fix this, and I will do this as an exercise to keep me
fluent in the parser code.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tobi at gcc dot gnu dot org 2008-03-26 21:09 ---
A lovely design by committee feature that is.
An alternative implementation strategy would be to use the same calling
convention as for pass-by-reference arguments and then copy on entry (if
present, and as an
--- Comment #3 from tobi at gcc dot gnu dot org 2008-03-01 23:15 ---
I checked the code leading up to this, and if I didn't miss a codepath, stride
will always be of type gfc_array_index_type, so I'm inclined to believe that
the bug, if any, is in fold. It is of course pos
--- Comment #14 from tobi at gcc dot gnu dot org 2007-10-28 19:08 ---
Closing. Wolfgang, if you still see similar problems please open a new PR and
CC me.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tobi at gcc dot gnu dot org 2007-10-28 18:53 ---
Subject: Bug 32147
Author: tobi
Date: Sun Oct 28 18:53:27 2007
New Revision: 129701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129701
Log:
fortran/
PR fortran/32147
* module.c (write_symb
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu
--- Comment #16 from tobi at gcc dot gnu dot org 2007-10-21 21:18 ---
Re this testcase:
(In reply to comment #5)
> program array_char
> implicit none
> character (len=2) :: x, y
> character (len=2) :: z(2)
> x = "a "
> y = "cd"
> z = (/y(1:len
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from tobi at gcc dot gnu dot org 2007-10-13 22:28 ---
Dominique, I forgot to say: your testcase is also fixed by Paul's patch, and
it's really the same problem, so the testcase I added is enough.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
--- Comment #13 from tobi at gcc dot gnu dot org 2007-10-13 21:47 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from tobi at gcc dot gnu dot org 2007-10-13 21:45 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from tobi at gcc dot gnu dot org 2007-10-13 21:44 ---
Subject: Bug 33254
Author: tobi
Date: Sat Oct 13 21:43:49 2007
New Revision: 129286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129286
Log:
2007-10-13 Tobias Schlueter <[EMAIL PROTECTED]>
--- Comment #6 from tobi at gcc dot gnu dot org 2007-10-13 21:44 ---
Subject: Bug 33727
Author: tobi
Date: Sat Oct 13 21:43:49 2007
New Revision: 129286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129286
Log:
2007-10-13 Tobias Schlueter <[EMAIL PROTECTED]>
--- Comment #11 from tobi at gcc dot gnu dot org 2007-10-11 14:14 ---
I'm adding Paul to the CC list, as perhaps he immediately knows what's
happening (Paul, see comment #5). Otherwise I will investigate tomorrow
evening or Saturday.
--
tobi at gcc dot gnu dot o
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-10 20:15 ---
Created an attachment (id=14337)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14337&action=view)
A small cleanup patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-10 20:12 ---
The problem is that at the time we enter resolve_entries cx_radc has type
BT_UNKNOWN. I have no idea why that's the case. Removing the interface fixes
this. It's also a QOI issue that an error message
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-10 14:40 ---
OTOH this works:
program array_char
implicit none
character (len=2) :: x
character (len=1) :: z
x = "a "
z = x(1:len(trim(x)))
end program array_char
So the problem is with array constructors.
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-10 14:34 ---
(In reply to comment #1)
> There's a disabled check in bounds_check_10.f90 (to be submitted) which
> depends
> on this bug, please enable it after fixing.
Scratch that, of course after the first run
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-10 14:25 ---
There's a disabled check in bounds_check_10.f90 (to be submitted) which depends
on this bug, please enable it after fixing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-10 14:23 ---
The failure from #2 is now PR 33727.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
tructor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu do
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-10 12:59 ---
I have a patch for this. Unfortunately, while playing around with testcases I
found a new segfault, so I'll have to look into this before submitting.
Failing testcase:
! { dg-do run }
! { dg-options "-fbo
--- Comment #8 from tobi at gcc dot gnu dot org 2007-10-08 22:10 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from tobi at gcc dot gnu dot org 2007-10-08 20:54 ---
Subject: Bug 33689
Author: tobi
Date: Mon Oct 8 20:54:47 2007
New Revision: 129139
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129139
Log:
PR fortran/33689
fortran/
* resolve.c (gfc_resolve_ex
--- Comment #5 from tobi at gcc dot gnu dot org 2007-10-08 18:25 ---
I think I have a fix. Needs some more testing, though.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tobi at gcc dot gnu dot org 2007-10-07 21:48 ---
The current set of warnings is:
../../../libgfortran/runtime/backtrace.c:66: warning: 'local_strcasestr'
defined but not used
../../../libgfortran/runtime/environ.c:312: warning: 'init_choice'
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-07 20:03 ---
If we reject the common as syntactically wrong, it should never be resolved.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-07 19:52 ---
Probably more of a target issue than a frontend issue. Please push back to the
frontend with an explanation what the FE is doing wrong if the backend does the
right thing.
--
tobi at gcc dot gnu dot org changed
--- Comment #5 from tobi at gcc dot gnu dot org 2007-10-07 19:49 ---
(In reply to comment #4)
> E.g. the following is legal:
iff PRECISION(X) <= 350 :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-07 19:43 ---
E.g. the following is legal:
INTEGER :: I(350)
INTEGER, PARAMETER :: K(500) = (/ i, i=1,500 /)
REAL :: X
DATA I(4+K(PRECISION(X))) / 1 /
whereas
DATA I(PRECISION(X)) / 1 /
isn't.
--
tobi at gc
--- Comment #8 from tobi at gcc dot gnu dot org 2007-10-07 17:16 ---
Something like the patch below fails unfortunately -- when resolving arglists
we still don't know enough about the callee (viz the checks of ptype, that are
already a hack on top of my original patch attemp
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-07 12:01 ---
(In reply to comment #3)
> I think we need to use tgamma() where available. If it isn't, we
> need a test to check whether gamma() is equivalent to tgamma() or
> to lgamma().
>
> Yuck.
It may be
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-07 11:46 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-07 11:45 ---
Subject: Bug 20851
Author: tobi
Date: Sun Oct 7 11:45:15 2007
New Revision: 129069
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129069
Log:
PR fortran/20851
fortran/
* expr.c (check_inquiry): Typ
--- Comment #9 from tobi at gcc dot gnu dot org 2007-10-06 14:43 ---
And this looks like the right place for an attack:
/* Given an array constructor, determine if the constructor is
constant or not by expanding it and making sure that all elements
are constants. This is a bit of
--- Comment #9 from tobi at gcc dot gnu dot org 2007-10-06 14:09 ---
There's no related bug field, but it's worth mentioning that PR20923 and this
should probably be attacked at the same time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #8 from tobi at gcc dot gnu dot org 2007-10-06 14:08 ---
There's no related bug field, but it's worth mentioning that PR19925 and this
should probably be attacked at the same time.
--
tobi at gcc dot gnu dot org changed:
What
--- Comment #5 from tobi at gcc dot gnu dot org 2007-10-06 09:10 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-06 08:55 ---
Subject: Bug 25076
Author: tobi
Date: Sat Oct 6 08:55:30 2007
New Revision: 129050
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129050
Log:
PR fortran/25076
fortran/
* resolve.c (gfc_find_fora
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-05 22:33 ---
Ok, last comment for tonight: the second option would fail for the perfectly
legal
subroutine a(arr)
implicit none
dimension arr(5)
real arr
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29813
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-05 21:47 ---
Sorry if I appear talking to myself, alternative fixes that I pondered, and
that may be cleaner, would be the following:
- record both the place where a symbol is given a type and where it is first
used. Then verify
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-05 21:40 ---
Perhaps I should add that my hack seems to hold up against the testsuite.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-05 21:38 ---
Created an attachment (id=14306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14306&action=view)
A patch
Here's a quick hack to fix this problem. It is not complete (INTRINSIC_USER is
not handl
--- Comment #11 from tobi at gcc dot gnu dot org 2007-10-05 19:51 ---
Wonderful, I just had a look at this bug. Implementing transformational
functions in the compiler will be a lot of joy. See gfc_simplify_reshape for
the delights this brings.
--
tobi at gcc dot gnu dot org
--- Comment #11 from tobi at gcc dot gnu dot org 2007-10-05 17:33 ---
Created an attachment (id=14305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14305&action=view)
A patch
Wolfgang, this patch works for your testcase, but it is somewhat dependent on
the history of
--- Comment #10 from tobi at gcc dot gnu dot org 2007-10-05 15:55 ---
I'm down to 14 differences. Looking into the remaining ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32147
--- Comment #9 from tobi at gcc dot gnu dot org 2007-10-04 22:15 ---
I thought this would fix it, but this gives internal errors. I'll investigate
further when I have time.
2007-10-04 Tobias Schlüter <[EMAIL PROTECTED]>
PR fortran/32147
* module.c (wr
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-04 21:58 ---
It should be sufficient to convert all case-selectors to the same kind as the
case-expression. We should then be giving exactly the same error as g95,
unless I'm missing something.
--
tobi at gcc dot gnu do
--- Comment #9 from tobi at gcc dot gnu dot org 2007-10-04 21:46 ---
Can this be closed?
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #11 from tobi at gcc dot gnu dot org 2007-10-04 21:44 ---
(In reply to comment #10)
> Ok, I guess I blew looking at this for a year. Too busy with work really :).
> Anyways maybe next weekend.
So, did you have time? :-)
--
tobi at gcc dot gnu dot org c
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-04 21:33 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00267.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25076
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-04 19:05 ---
I'm testing a patch.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #13 from tobi at gcc dot gnu dot org 2007-10-04 15:24 ---
Yes, I only happened to leave before the commit message arrived.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33626
--- Comment #11 from tobi at gcc dot gnu dot org 2007-10-04 07:34 ---
Subject: Bug 33626
Author: tobi
Date: Thu Oct 4 07:34:38 2007
New Revision: 129002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129002
Log:
PR fortran/33626
fortran/
* resolve.c (resolve_operator)
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-03 16:22 ---
Created an attachment (id=14292)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292&action=view)
Putative patch redux
Coming to think of it, the charlen thing can probably also be moved to the
first swi
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-03 16:12 ---
Created an attachment (id=14291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291&action=view)
Putative patch
This patch fixes the testcase.
FX, I take it that you have a ready-built compiler wi
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-03 15:01 ---
Fixed on trunk.
--
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
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-03 11:37 ---
Subject: Bug 33198
Author: tobi
Date: Wed Oct 3 11:37:44 2007
New Revision: 128980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128980
Log:
PR fortran/33198
fortran/
* resolve.c (has_default_ini
--- Comment #10 from tobi at gcc dot gnu dot org 2007-10-02 18:51 ---
There are only two later patches to min/maxloc, namely those for PRs 33297 and
32954, which both seem unrelated. So I agree that this should be safe to
backport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from tobi at gcc dot gnu dot org 2007-09-29 08:00 ---
I added a testcase for this. Can this bug be closed or does anyone feel
strongly enough about it to fix it in 4.2?
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-29 07:57 ---
Subject: Bug 33354
Author: tobi
Date: Sat Sep 29 07:57:37 2007
New Revision: 128882
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128882
Log:
PR fortran/33354
* gfortran.dg/minmaxloc_4.f90: New
--- Comment #1 from tobi at gcc dot gnu dot org 2007-09-28 08:57 ---
I have a patch, but I can't test it right now.
--
tobi at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from tobi at gcc dot gnu dot org 2007-09-27 21:41 ---
I'm unassigning myself for the time being, as I couldn't think of a fix that
does the right thing and doesn't involve overhauling parts of the compiler.
--
tobi at gcc dot gnu dot org changed:
--- Comment #3 from tobi at gcc dot gnu dot org 2007-09-27 12:09 ---
Weird, I tried essentially the same patch (where I modeled the code after
gfc_conv_intrinsic_nint), but the failure persisted. I wonder what's different
now.
--
tobi at gcc dot gnu dot org ch
--- Comment #10 from tobi at gcc dot gnu dot org 2007-09-25 05:39 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from tobi at gcc dot gnu dot org 2007-09-24 21:15 ---
Subject: Bug 33269
Author: tobi
Date: Mon Sep 24 21:15:00 2007
New Revision: 128732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128732
Log:
PR fortran/33269
fortran/
* io.c (check_format_string): M
--- Comment #7 from tobi at gcc dot gnu dot org 2007-09-22 12:53 ---
Created an attachment (id=14244)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14244&action=view)
Unfinished patch
Here's a patch. I won't have time for the final cosmetics for a few day
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-20 13:03 ---
Created an attachment (id=14231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14231&action=view)
Failed attempt at a patch
This is a first attempt at a patch. Unfortunately, when I wrote the e-m
1 - 100 of 965 matches
Mail list logo
