--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-04-25 06:04
---
(In reply to comment #2)
> This was fixed for the non windows case for sure.
Yes:
$ cat ftesti.f90
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
end subrout
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-04-27 09:49
---
(In reply to comment #5)
> This bug is one of the issues preventing cp2k from compiling. I get this error
> in timings.f90:335.
This bug is still there. With mainline, on i686-linux, it seems to be th
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-04-27 11:50
---
Patch (at least partial) submitted for approval. The patch allows CP2K to
compile.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-04-27 13:14
---
(In reply to comment #11)
> The only solution in these cases it to remove the assert and let it
> generate bad code, but I want to fix other issues first before removing
> the assert.
What's the
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-04-29 16:31
---
Subject: Bug 25681
Author: fxcoudert
Date: Sat Apr 29 16:31:26 2006
New Revision: 113376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113376
Log:
PR fortran/25681
* si
--
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 #17 from fxcoudert at gcc dot gnu dot org 2006-05-05 07:04
---
(In reply to comment #15)
> I probably do something wrong, but with
> GNU Fortran 95 (GCC) 4.2.0 20060504 (experimental)
> from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-x86_64-linux.tar.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-05 07:10
---
(In reply to comment #0)
> Currently, gfortran only detects that the IO format descriptor contains
> insufficient data at run time. It would be great (though of low priority) if
> it would find them a
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-05 09:00
---
Subject: Bug 25681
Author: fxcoudert
Date: Fri May 5 09:00:25 2006
New Revision: 113551
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113551
Log:
PR fortran/25681
* si
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-05-05 09:01
---
Fixed on mainline and 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
NFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:07
---
(In reply to comment #4)
> would you care to replace rystride == ycount with rystride == xcount
> as a fix for this, independent of the matmul BLAS issue?
>
> I think this is definitely worth it, es
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:08
---
Subject: Bug 26985
Author: fxcoudert
Date: Fri May 5 11:08:23 2006
New Revision: 113552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113552
Log:
PR libfortran/26985
* m4/m
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:12
---
This is indeed fixed on 4.1 branch, that should be (soon?) released as 4.1.1.
This was previously reported as bug #26716.
*** This bug has been marked as a duplicate of 26716 ***
--
fxcoudert at gcc dot gnu
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:12
---
*** Bug 27401 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail||4.1.1
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-05 21:47
---
I'll commit a testcase when I find some time this week-end...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-06 06:55
---
Any reason to keep this open? gfortran doesn't have a problem with irix6.5 any
more, as far as I know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16322
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-07 11:08
---
Patch proposed here: http://gcc.gnu.org/ml/fortran/2006-05/msg00108.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-05-07 13:02
---
Subject: Bug 26985
Author: fxcoudert
Date: Sun May 7 13:02:39 2006
New Revision: 113600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113600
Log:
PR libfortran/26985
* m4/m
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-07 13:29
---
Hum, I can confirm that this bug disappeared at some point. I don't have it any
more, so I'm closing this PR.
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-07 13:50
---
I don't see this failure any more on powerpc-apple-darwin7.9.0. Can anyone
confirm it's still present? (perhaps Steve on amd64)
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-07 14:09
---
I don't see that failure any more (on powerpc64-unknown-linux-gnu). It was
present on 20060423, but disappeared on 20060430.
Janis, do you still see it? (its brother bug, PR 26119, also disapp
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-07 15:49
---
Fixed on both 4.1 and mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-07 16:27
---
(In reply to comment #6)
> I'm not a language lawyer, but if I read it correctly, then
> INT is a standard intrinsic function and thus allowed in a
> restricted expression (F2003 draft standard, 7.1
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-07 16:33
---
Subject: Bug 27378
Author: fxcoudert
Date: Sun May 7 16:33:30 2006
New Revision: 113603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113603
Log:
PR fortran/27378
*
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-07 16:37
---
> Looks like an "Obviously correct" patch.
Commited the "Obviously correct" patch after regtesting on i686-linux.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-07 16:41
---
This one a very strange: what do the comments #4 and #5 do in this PR?
Anyhow, we know have -std=legacy for such features, including REAL DO loop
indices. The remaining question is: do we want to mark REAL array
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-07 16:48
---
(In reply to comment #7)
>> Anyhow, we know have -std=legacy for such features
>
> (we didn't have STD_LEGACY when this PR was opened)
Yes, I meant "we now have -std=legacy" :)
>
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-08 08:37
---
A good documentation for PROTECTED, in addition to the standard itself, is
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlf101a.doc/xlflr/protected.htm
--
fxcoudert at gcc
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:22
---
It appears that the original testcase, involving INT in as specification
expression, is valid F95 and F2003. It was not valid F90, however, because the
return type of INT is real. This is confirmed by the results
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:32
---
Andrew, what is the status on that bug? Do you still observe mismatch in the
testsuite, or can we close the PR?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:48
---
Humpf, I created a testcase for inclusion in the testsuite, but it reveals that
overlap of logical cases is not detected when they're separated from each
other:
select case (l)
case (.true.)
case (.
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:57
---
(In reply to comment #10)
> I do not understand why you are closing this one as INVALID,
> since you just argued that it VALID F95 and F2003.
I'm saying that the bug report, which says "This
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-05-08 09:59
---
Subject: Bug 18271
Author: fxcoudert
Date: Mon May 8 09:59:09 2006
New Revision: 113627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113627
Log:
PR libfortran/18271
* gfo
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-05-08 10:03
---
Subject: Bug 18271
Author: fxcoudert
Date: Mon May 8 10:03:11 2006
New Revision: 113628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113628
Log:
PR libfortran/18271
* gfo
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-08 10:43
---
Subject: Bug 27378
Author: fxcoudert
Date: Mon May 8 10:43:18 2006
New Revision: 113629
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113629
Log:
PR fortran/27378
*
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-08 10:46
---
Fixed on 4.1 and mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-09 22:10
---
OK, closing as fixed, then.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-10 09:07
---
I can reproduce this ICE with mainline on i686-linux. I propose the following
patch:
Index: parse.c
===
--- parse.c (revision 113603
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
This is a duplicate of PR24549 (it's fixed by the same one-line patch).
*** This bug has been marked as a duplicate of 24549 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
*** Bug 27487 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:51
---
Subject: Bug 24549
Author: fxcoudert
Date: Wed May 10 14:51:26 2006
New Revision: 113671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113671
Log:
PR fortran/24549
*
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:58
---
Subject: Bug 20460
Author: fxcoudert
Date: Wed May 10 14:58:48 2006
New Revision: 113672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113672
Log:
PR fortran/20460
* r
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-10 21:36
---
Below is a patch for this ICE. I suspect that there a lots more ICEs lurking in
dump-parse-tree.c, which looks like it's not really written to be fed with
incomplete structures (as might happen during
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
BugsThisDependsOn: 20585
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-11 06:08
---
(In reply to comment #7)
> FX: Fixing gfortran's error recovery is not the answer to this PR,
> but to the other one.
Yes, I know. Since this PR was already used for tracking the ICE, I planned on
op
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/show_bug.cgi?id=27552
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/show_bug.cgi?id=27553
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-11 11:36
---
File entry-4.f90 from the gfortran testsuite also ICEs with -ff2c:
$ gfortran -c entry_4.f90 -ff2c
src/entry_4.f90: In function f2:
src/entry_4.f90:12: internal compiler error: in make_decl_rtl, at varasm.c
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/show_bug.cgi?id=27554
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-11 17:08
---
I think this is taken care of by the following patch:
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (revision 113671)
+++ dump-parse-tree.c
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-11 18:46
---
The ICE is due to -Wunused-labels. We try to issue a warning about the label
(already marked as an error because it contains a non-numeric character) being
unused, but said label has no locus (because the parser
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-11 20:58
---
Patched formally submitted for review on the ml:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00485.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:37
---
Subject: Bug 27553
Author: fxcoudert
Date: Thu May 11 21:37:10 2006
New Revision: 113712
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113712
Log:
PR fortran/27553
* parse.c (n
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:38
---
Commited on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:39
---
Subject: Bug 24549
Author: fxcoudert
Date: Thu May 11 21:39:06 2006
New Revision: 113713
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113713
Log:
PR fortran/20460
PR fortr
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:39
---
Subject: Bug 20460
Author: fxcoudert
Date: Thu May 11 21:39:06 2006
New Revision: 113713
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113713
Log:
PR fortran/20460
PR fortr
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:39
---
Fixed on mainline and 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:40
---
Fixed on mainline and 4.1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-12 21:18
---
Well, the testcase is valid F2003 but not valid F95. We have to get it working
(for F2003 mode), which probably means adding a simplification function for
MAXLOC. And the same is true for all the intrinsics
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-14 09:00
---
Any progress on this one? It's blocking a few widely-used Fortran codes from
compiling (and being used and benchmarked) with mainline gfortran.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-17 12:04
---
Subject: Bug 27553
Author: fxcoudert
Date: Wed May 17 12:04:17 2006
New Revision: 113854
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113854
Log:
PR fortran/27553
* parse.c (n
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-17 12:06
---
Subject: Bug 27320
Author: fxcoudert
Date: Wed May 17 12:06:42 2006
New Revision: 113855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113855
Log:
PR fortran/27320
* dump-pars
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-17 12:07
---
Fixed on 4.1 and mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-17 14:11
---
Subject: Bug 26551
Author: fxcoudert
Date: Wed May 17 14:11:40 2006
New Revision: 113860
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113860
Log:
PR fortran/26551
* r
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-17 14:15
---
Subject: Bug 26551
Author: fxcoudert
Date: Wed May 17 14:14:56 2006
New Revision: 113861
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113861
Log:
Testcase forgotten in the previou
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
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:43
---
Andrew, any news on this one? If I remember correctly, you're waiting for
paperwork with your new employer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19777
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:45
---
I think we can close this one, now, can't we?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |
--- Comment #41 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:51
---
I'm puzzled by this PR and PR 26893: what is the status on those reports? Did
you reproduce this on a given platform, with *known good* GMP and MPFR and with
a gfortran >= 4.1 ?
Otherwise, I supposed
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:59
---
Not sure if it's a duplicate. Here's a reduced testcase, anyhow:
print *, F()
contains
function F()
integer :: F(1)
f = 1
end function F
end
$ gfortran -v
Usin
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-19 17:04
---
We currently have the following warnings when building libgfortran on
i686-linux:
../../../gcc/libgfortran/io/transfer.c: In function 'read_block':
../../../gcc/libgfortran/io/transfer.c:279: warnin
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-19 17:05
---
Adding Jerry in CC list since he's likely to be the one who introduced the
warning in transfer.c :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-19 17:14
---
(In reply to comment #7)
> I will be working on this after the students leave, starting in June. Please
> keep this ticket open.
OK.
> I note that the versions of GMP & MPFR I'm using work *
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2006-05-20 20:07
---
(In reply to comment #18)
> The error
> /usr/src/local/gcc/libgfortran/mk-kinds-h.sh: Unknown type
> happens because gfortran was compiled without -Wl,-R/usr/local/lib, so it
> cannot find libmpr.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:02
---
Unless we have some more information about this one, I'd like to close it
because it's most likely to be a timeout error than a real problem in the code.
Especially if it only fails at -O0, while being
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:03
---
Confirmed. I don't understand why, though. I'll try it harder when I have some
leisure time.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:05
---
Confirmed. I think that having a io/io.h file instead of having all prototypes
in libgfortran.h is fundamentally a bad idea, especially since things are now
spread all around the libgfortran directory
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:11
---
Yes, this is confirmed. I'm not sure what is the less dirty way to make the
warnings disappear (and not fix the code, which is, as Andrew said, expected
not to work well on 64bits platforms).
--
fxcoude
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:37
---
Why is this code invalid? (the keywork ice-on-invalid-code is set)
No error is reported with Sun, Intel and g95.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:49
---
Proposed patch (wording from the g95 error message). With that patch, compiling
the testcase is a bit noisy (additional errors after the first error message),
I'll try to find a cleaner solution.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-21 22:06
---
(In reply to comment #1)
> The code as given is not valid, but since we segfault at runtime even with
> -fbounds-check one can argue that this is a real deficiency.
With the inline dot_product on mainli
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 22:07
---
Of course, I wanted to close it also. This is now done, please reopen if you
think I'm wrong.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-24 06:14
---
Reduced testcase (fails at -O1 and higher):
character*1 b
b = ''
write (*, '()')
end
is compiled into (-gfump-original-tree):
MAIN__ ()
{
char b[1:1];
_
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-24 09:20
---
> function F()
> integer :: F(1)
> f = 1
> end function F
Compiling this simple function without and with -fbounds-check and dumping the
GIMPLE tree generated gives the fo
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-24 18:58
---
(In reply to comment #18)
> it is still broken on powerpc{,64}
Hi Jakub, I'm not sure exactly what is still broken. On
powerpc-apple-darwin7.9.0, with mainline gfortran 20060512:
$ cat foo.f90
! { d
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2006-05-24 20:34
---
(In reply to comment #20)
> Darwin is broken a different way and it is a mess that I was trying to fix but
> it is still broken because I don't care that much anymore.
Could you give a Fortran testc
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-24 20:52
---
(In reply to comment #3)
> I think the cuplrit here is gfc_trans_dummy_array_bias(), around line 3728
> (where the offset is built), although I'm not skilled enough in all this to
> understand how
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=27765
: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
BugsThisDependsOn: 19777,24401,26801,27524,27588,27765
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-24 21:51
---
With gfortran mainline 20060517 (and the patch for PR 27524), here is a list of
failures recorder when the testsuite is run with -fbounds-check (command line
is make check-gfortran RUNTESTFLAGS="-target_
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-05-24 22:00
---
Short enough for commit. Will do some testing before, and then check it in.
Thanks Andrew!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-26 08:31
---
(In reply to comment #18)
> This patch is beyond my current understanding, so someone else needs to look
> at
> it.
I think our best chance here is to find the exact patch that broke it. You said
it&
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-26 21:18
---
Subject: Bug 27524
Author: fxcoudert
Date: Fri May 26 21:18:45 2006
New Revision: 114142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114142
Log:
PR fortran/27524
* trans
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2
Known to work||4.2.0
--
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 #1 from fxcoudert at gcc dot gnu dot org 2006-05-27 08:12
---
Bug confirmed, not i686-linux specific.
The problem is that the front-end sorts the different possibilities inside a
case statement so that a binary search can be performed at runtime by the
library. But, for
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-27 08:29
---
*** Bug 27760 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-27 08:29
---
Already fixed on mainline, this was PR 27524.
*** This bug has been marked as a duplicate of 27524 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 3201 matches
Mail list logo
