--- Comment #2 from jaydub66 at gmail dot com 2008-05-25 14:45 ---
Ok, this produces an impressive list of regressions.
Many of those (e.g. actual_procedure_1.f90) seem to be related to
conf (external, dimension); /* See Fortran 95's R504. */
I'm not sure if the const
--- Comment #1 from jaydub66 at gmail dot com 2008-05-25 14:02 ---
Here is a first patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 135859)
+++ gcc/fortran/symbol.c(working copy
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
--- Comment #8 from jaydub66 at gmail dot com 2008-05-24 17:52 ---
I have a patch which can handle this test case, see
http://gcc.gnu.org/ml/fortran/2008-05/msg00296.html
It's not complete yet, and some details need to be fixed, but the basic
functionality is there. I hope it c
--- Comment #6 from jaydub66 at gmail dot com 2008-05-15 21:48 ---
I noticed that while the test case from comment #1 still fails, the following
variation actually works with the patch from comment #2:
module m
contains
subroutine one(a)
integer a(:)
print *, lbound(a
--- Comment #2 from jaydub66 at gmail dot com 2008-05-03 20:44 ---
Fixed with rev. 134918.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36114
--- Comment #1 from jaydub66 at gmail dot com 2008-05-03 20:11 ---
Confirmed. The ICEs you get are really due to my rev. 134867, which actually
also triggered some testsuite failures (use_only_1.f90 and g77/970915-0.f). I
have no idea why I didn't notice it (sorry!).
This can easi
--- Comment #2 from jaydub66 at gmail dot com 2008-04-28 15:44 ---
(In reply to comment #1)
> I think compiling with -fbacktrace and calling the STOP intrinsic should emit
> a
> backtrace.
I don't think it does. Anyway I'm looking for a solution that keeps the pr
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
--- Comment #4 from jaydub66 at gmail dot com 2008-04-10 21:09 ---
To me it's also not completely clear what the standard says on this, but the
way to fix it would probably be to insert some additional check into
operator_correspondence (interface.c), where currently only the typ
--- Comment #5 from jaydub66 at gmail dot com 2008-04-09 18:48 ---
(In reply to comment #4)
> If we are lucky this fixes PR 35831.
Actually it does not, but I think I know how to fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
--- Comment #2 from jaydub66 at gmail dot com 2008-04-09 18:23 ---
Here is a modified version of the original test case, which is also accepted by
gfortran, while it is rejected by ifort:
module m
contains
subroutine one(a)
integer a(1:2)
end subroutine one
--- Comment #1 from jaydub66 at gmail dot com 2008-04-08 20:58 ---
Tobias,
I can confirm the behaviour you described for this test case, provided of
course that "one" and "two" are implemented somewhere externally. Otherwise one
gets
undefined reference to `two
--- Comment #3 from jaydub66 at gmail dot com 2008-04-07 22:01 ---
Another thing I just noticed is that dummy procedures are currently not checked
for being called with the right arguments (-> compare_actual_formal), e.g. in
the above test case "call f([1,2,3])" could a
--- Comment #2 from jaydub66 at gmail dot com 2008-04-05 18:03 ---
(In reply to comment #1)
> @@ -3649,4 +3667,5 @@ void copy_formal_args (gfc_symbol *dest,
>formal_arg->sym->attr = curr_arg->sym->attr;
>formal_arg->sym->ts = curr_arg->sym
--- Comment #45 from jaydub66 at gmail dot com 2008-01-10 20:14 ---
(In reply to comment #42)
> This is probably all we can get for now - maybe another few % with minor
> tweaks,
> but nothing earth-shattering. After all, we _do_ have a much larger IL due
> to the number
--- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38 ---
> How does the trunk compare now to the numbers mentioned in comment #16 ?
Compiling with rev. 131414 gives:
-O1 -fstrict-aliasing: 33sec, 438197 kB
-O2: 97sec, 669637 kB
--- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 ---
I've done some experimenting with older GCC versions I have floating around on
my machines:
Compiling the test case with both 4.1.2 and 4.2.1 gives an ICE, so I guess we
can't exactly call this a regression.
--- Comment #4 from jaydub66 at gmail dot com 2008-01-05 23:51 ---
But 800MB of memory is definitely *a lot* for such a small file!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #3 from jaydub66 at gmail dot com 2008-01-05 23:46 ---
(In reply to comment #2)
> Can you give the output of the compiler when -ftime-report is added?
Sure thing, thanks for the remark. Here it goes:
gfortran-4.3 -c -ftime-report -O1 -fstrict-aliasing Amplitudes.
--- Comment #1 from jaydub66 at gmail dot com 2008-01-05 23:36 ---
Created an attachment (id=14885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14885&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
everity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #4 from jaydub66 at gmail dot com 2007-12-04 21:16 ---
(In reply to comment #3)
> Paul, do you have an idea? My (un)educated guess is that the fix for PR 33541
> (patch to not import "y" when using "use foo; use foo, only: x => y") caused
> th
--- Comment #2 from jaydub66 at gmail dot com 2007-12-04 14:55 ---
The error also appears on x86_64. It must have been introduced somewhere
between Nov. 23 and 26:
- rev. 130365 works
- rev. 130431 fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34335
--- Comment #1 from jaydub66 at gmail dot com 2007-12-04 13:44 ---
The code above fails for recent trunk builds (rev. 130582) on
i686-pc-linux-gnu, but is known to work for 4.2.1 as well as 4.3.0 rev. 127773
(from August 24, 2007).
--
jaydub66 at gmail dot com changed
ortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34335
--- Comment #19 from jaydub66 at gmail dot com 2007-11-02 20:53 ---
Hi Jerry,
I tried your patch (part 3b), and noticed that it fails on the following code:
real function t(x)
real ::x
t = x
end function
program p
implicit none
intrinsic sin
procedure(sin):: t
print *,t
--- Comment #1 from jaydub66 at gmail dot com 2007-09-03 18:05 ---
> The error is also killed by
>
> A_var = initA()
Sorry. The error is killed by *removing* this line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
statements
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
t org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32946
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
--- Comment #4 from jaydub66 at gmail dot com 2007-07-11 21:39 ---
Paul,
I tested your patch, and indeed it does fix the problem for me. I also checked
it for regressions, and it doesn't seem to break anthing.
Cheers,
Janus
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32710
--- Comment #2 from jaydub66 at gmail dot com 2007-07-09 19:17 ---
I checked it: The ICE is really introduced by rev. 124541.
> r124541 | pault | 2007-05-08 13:58:25 +0200 (Tue, 08 May 2007) | 18 lines
> PR 29397, PR 29400
> * decl.c (add_init_expr_to_sym):
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
valid code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaydub66 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32669
36 matches
Mail list logo
