[Bug fortran/36325] New: specific or generic INTERFACE implies the EXTERNAL attribute
I think the following code is invalid: interface subroutine foo end subroutine end interface external foo Because the INTERFACE statement already specifies the EXTERNAL attribute, which is thus specified twice. This code *is* actually rejected (as of rev. 135859), but the error message is completely wrong: external :: foo 1 Error: EXTERNAL attribute conflicts with SUBROUTINE attribute at (1) (which it does *not* for this case) Quoting the Fortran 2003 standard (section 5.1.2.6): The EXTERNAL attribute speciï¬es that an entity is an external procedure, dummy procedure, procedure pointer, or block data subprogram. This attribute may also be speciï¬ed by an EXTERNAL statement (12.3.2.2), a procedure-declaration-stmt (12.3.2.3) or an interface body that is not in an abstract interface block (12.3.2.1). And further on in section 12.3.2.1: An interface body in a generic or speciï¬c interface block speciï¬es the EXTERNAL attribute and an explicit speciï¬c interface for an external procedure or a dummy procedure. If the name of the declared procedure is that of a dummy argument in the subprogram containing the interface body, the procedure is a dummy procedure; otherwise, it is an external procedure. -- Summary: specific or generic INTERFACE implies the EXTERNAL attribute Product: gcc Version: 4.4.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=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- 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)
@@ -439,7 +439,7 @@ check_conflict (symbol_attribute *attr,
conf (external, intrinsic);
conf (entry, intrinsic);
- if ((attr-if_source !attr-procedure) || attr-contained)
+ if ((attr-if_source == IFSRC_DECL !attr-procedure) || attr-contained)
{
conf (external, subroutine);
conf (external, function);
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 135859)
+++ gcc/fortran/parse.c (working copy)
@@ -1917,12 +1917,26 @@ loop:
new_state = COMP_SUBROUTINE;
gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
gfc_new_block-formal, NULL);
+ if (current_interface.type != INTERFACE_ABSTRACT
+gfc_add_external (gfc_new_block-attr, gfc_current_locus) ==
FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
break;
case ST_FUNCTION:
new_state = COMP_FUNCTION;
gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
gfc_new_block-formal, NULL);
+ if (current_interface.type != INTERFACE_ABSTRACT
+gfc_add_external (gfc_new_block-attr, gfc_current_locus) ==
FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
break;
case ST_PROCEDURE:
This removes the conflict between EXTERNAL and SUBROUTINE for this case, and
adds the EXTERNAL attribute for a non-abstract INTERFACE statement.
Checking for regressions ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- 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 constraint from R504 is implemented correctly here, or if it constrains too much. Others testcases (like argument_checking_3.f90) fail because they define lots of specific interfaces, but no external implementation for those. So I guess they are actually invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- 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 can be committed to trunk quite soon. Cheers, Janus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- 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), ubound(a), size(a) if ((lbound(a,dim=1) /= 1) .or. (ubound(a,dim=1) /= 3)) call abort() print *, a if (any(a /= [1,2,3])) call abort() end subroutine one end module m program test use m implicit none call foo(one) contains subroutine foo(f) interface subroutine f(a) integer a(:) end subroutine end interface call f([1,2,3]) end subroutine foo end program test The only difference being that f is specified by an INTERFACE statement instead of a PROCEDURE statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/36114] [4.4 Regression] f951: internal compiler error: Bus error due to revision 134867
--- 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 easily be fixed by the following small patch: Index: gcc/fortran/misc.c === --- gcc/fortran/misc.c (revision 134867) +++ gcc/fortran/misc.c (working copy) @@ -77,6 +77,7 @@ gfc_clear_ts (gfc_typespec *ts) ts-derived = NULL; ts-kind = 0; ts-cl = NULL; + ts-interface = NULL; /* flag that says if the type is C interoperable */ ts-is_c_interop = 0; /* says what f90 type the C kind interops with */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36114
[Bug fortran/36114] [4.4 Regression] f951: internal compiler error: Bus error due to revision 134867
--- 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
[Bug libfortran/36044] user-requested backtrace
--- 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 program running after the backtrace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug libfortran/36044] New: user-requested backtrace
It would be nice to have an intrinsic function to generate a user-requested backtrace, like ifort's TRACEBACKQQ. Of course this would be a non-standard extension, but a useful one which many other compilers also provide. There has already been some discussion on this in PR30498, with suggested workarounds like producing an FPE with 1.0/0.0 or calling 'kill' via ISO_C_BINDING to generate a backtrace. But these of course terminate the program. For debugging purposes it can be helpful to generate a backtrace at some point while keeping the program running, which is what e.g. TRACEBACKQQ does. -- Summary: user-requested backtrace Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- 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 type and rank of the arguments is checked. To require full equality of all array borders (as suggested in my comment #2), one could simply add if (!gfc_compare_array_spec (f1-sym-as, f2-sym-as)) return 1; into the above mentioned routine. This would result in gfortran behaving the same way as ifort in this case, may it be standard-conforming or not. If on the other hand Tobias is right in the assumption he made in comment #3, then one could something along the lines of if (f1-sym-as-type != f2-sym-as-type) return 1; to require only the array types to be equal, or something similar to at least prevent assumed-shape arrays from being passed instead of eplicit-shape arrays. My feeling is that at least the array size should match for explicit-shape arrays, but this is just a feeling and I couldn't find anything in the standard to confirm this. I'm not sure if the changes I'm suggesting would interfere with any other case where 'operator_correspondence' is called, but at least they don't seem to trigger any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- 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 subroutine two(a) integer a(2:3) end subroutine two end module program test use m implicit none ! PROCEDURE dummy !call foo(two) ! Interface dummy call bar(two) contains ! subroutine foo(f) ! procedure(one) :: f ! end subroutine foo subroutine bar(f) interface subroutine f(a) integer a(1:2) end subroutine f end interface end subroutine bar end program test In this test case both arrays are explicit-sized, and even have the same size, but their upper and lower bounds are shifted. gfortran currently does not even check if both arrays have the same size, only their ranks are compared. ifort gives the following error message: fortcom: Error: test35831.f90, line 23: The characteristics of dummy argument 1 of the associated actual procedure differ from the characteristics of dummy argument 1 of the dummy procedure. (12.2) [TWO] call bar(two) ---^ I would change this bug's status from UNCONFIRMED to NEW, but apparently I don't have the canconfirm permission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- 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
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- 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_' because there is only an interface for two but no actual implementation. Now, if I apply the fix for PR35830, i.e. adding the following line in copy_formal_args: formal_arg-sym-as = gfc_copy_array_spec (curr_arg-sym-as); Then also the error message for call foo(two) goes away! So this Type/rank mismatch in argument 'f' you saw before was apparently due to that array-handling bug in copy_formal_args! -- jaydub66 at gmail dot com changed: What|Removed |Added CC||jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- 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 also be called with a different
number of arguments like call f(1,2) without any error message.
In fact this check is currently omitted for any procedure which has the
EXTERNAL attribute (which includes all procedures declared via the
PROCEDURE():: statement). But I guess this check should better be omitted
only for procedures which have an implicit interface, right?
This can be cured with the following patch:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 133905)
+++ gcc/fortran/interface.c (working copy)
@@ -2419,8 +2419,7 @@ gfc_procedure_use (gfc_symbol *sym, gfc_
}
}
- if (sym-attr.external
- || sym-attr.if_source == IFSRC_UNKNOWN)
+ if (sym-attr.if_source == IFSRC_UNKNOWN)
{
gfc_actual_arglist *a;
for (a = *ap; a; a = a-next)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- 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-ts; + formal_arg-sym-as = curr_arg-sym-as; I guess one should rather use: formal_arg-sym-as = gfc_copy_array_spec (curr_arg-sym-as); With this addition your test case works at least with an explicit-size array: integer a(1:3) With an assumed-size integer a(:) it still fails. Will try to find out more tomorrow. module m contains subroutine one(a) integer a(:) print *, lbound(a), ubound(a), size(a) if ((lbound(a,dim=1) /= 1) .or. (ubound(a,dim=1) /= 3)) call abort() print *, a if (any(a /= [1,2,3])) call abort() end subroutine one end module m program test use m implicit none call foo(one) contains subroutine foo(f) ! The following interface block is needed ! for NAG f95 as it wrongly does not like ! use-associated interfaces for PROCEDURE ! (It is not needed for gfortran) interface subroutine one(a) integer a(:) end subroutine end interface procedure(one) :: f call f([1,2,3]) end subroutine foo end program test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- 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 of VOPs not partitioned. Well, it may not be earth-shattering, but it's still a solid improvement - of more than a few %! With rev. 131446 I get the following numbers: -O1 -fstrict-aliasing: 11sec, 201825 kB -O2: 22sec, 392166 kB -O3: 24sec, 388802 kB Compile time is reduced by a factor of 4 for -O2, and memory usage is halved for -O1! Nice job, Richard. So I'd say compile time really isn't an issue any more. But memory consumption is still a factor of 10 above what it was last year. Most of that comes from 'tree FRE' (~140MB), but all the junk in 'tree operand scan' is gone. For -O2 and -O3 another large chunk appears in 'tree PRE' (~160MB). Are you sure you want to close this bug? For me memory consumption is still an issue, and I would really like to see this fixed at some point. And if there is another bug which is a duplicate of this, could you point me to it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- 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 -O3: 50sec, 392669 kB This is of course better than a few days ago (thanks to Richard's patches). But it's not even close to the numbers in comment #16. What worries me about this is not the 33sec compile time (I could live with that, if I'd have to), but the really large amount of memory. On a machine with only 256MB compiling takes several minutes, due to massive swapping. Richard: You said that the remaining issue is probably not gonna be fixed for 4.3. I don't quite see the reason for this, since this apparently *was* fixed at some point in the 4.3 trunk (see comment 16). Also this would really be a shame since it would make GCC 4.3 practically unusable for our project (http://gibuu.physik.uni-giessen.de/GiBUU/). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- 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. But then compiling with older 4.3 trunk builds works much better: I have a version from August 24 of last year, which runs the test case at full -O3 in a perfect 8sec, with 32MB memory usage (that is with --enable-checking=release). And I have two other builds from October 8 and November 9, which both run the test case in about 38s with 85MB mem-usage (they are built with --enable-checking=debug, so this is probably just debugging overhead). At least none of them takes the crazy 800MB of recent builds. To sum up: It seems like trunk versions up to at least November 9 seem to work fine on this test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing
--- 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
[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing
--- 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.f90 Execution times (seconds) garbage collection: 0.21 ( 0%) usr 0.02 ( 2%) sys 0.24 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 299 kB ( 0%) ggc callgraph optimization: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 62 kB ( 0%) ggc trivially dead code : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc df live regs : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 127 kB ( 0%) ggc register information : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 196 kB ( 0%) ggc rebuild jump labels : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc parser: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 1848 kB ( 0%) ggc inline heuristics : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 1 kB ( 0%) ggc tree gimplify : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 847 kB ( 0%) ggc tree CFG construction : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 769 kB ( 0%) ggc tree CFG cleanup : 4.20 ( 5%) usr 0.06 ( 7%) sys 4.60 ( 5%) wall 2550 kB ( 0%) ggc tree copy propagation : 0.25 ( 0%) usr 0.01 ( 1%) sys 0.31 ( 0%) wall 24 kB ( 0%) ggc tree PTA : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 67 kB ( 0%) ggc tree alias analysis : 0.01 ( 0%) usr 0.01 ( 1%) sys 0.01 ( 0%) wall 2 kB ( 0%) ggc tree call clobbering : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree flow sensitive alias: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 16 kB ( 0%) ggc tree memory partitioning: 0.07 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc tree SSA rewrite : 0.48 ( 1%) usr 0.01 ( 1%) sys 0.53 ( 1%) wall 8455 kB ( 1%) ggc tree SSA other: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental : 3.26 ( 4%) usr 0.08 ( 9%) sys 3.62 ( 4%) wall 19615 kB ( 2%) ggc tree operand scan : 49.67 (63%) usr 0.48 (52%) sys 57.11 (64%) wall 247409 kB (30%) ggc dominator optimization: 0.85 ( 1%) usr 0.02 ( 2%) sys 1.57 ( 2%) wall 14019 kB ( 2%) ggc tree SRA : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 27 kB ( 0%) ggc tree STORE-CCP: 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 1 kB ( 0%) ggc tree CCP : 0.07 ( 0%) usr 0.01 ( 1%) sys 0.08 ( 0%) wall 15 kB ( 0%) ggc tree PHI const/copy prop: 0.35 ( 0%) usr 0.00 ( 0%) sys 0.37 ( 0%) wall 0 kB ( 0%) ggc tree split crit edges : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 2489 kB ( 0%) ggc tree reassociation: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 72 kB ( 0%) ggc tree FRE : 16.12 (20%) usr 0.17 (18%) sys 16.75 (19%) wall 505793 kB (62%) ggc tree code sinking : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 41 kB ( 0%) ggc tree forward propagate: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 7 kB ( 0%) ggc tree conservative DCE : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc tree aggressive DCE : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 1879 kB ( 0%) ggc tree loop bounds : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 160 kB ( 0%) ggc loop invariant motion : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1 kB ( 0%) ggc tree canonical iv : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 138 kB ( 0%) ggc scev constant prop: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 68 kB ( 0%) ggc complete unrolling: 0.30 ( 0%) usr 0.01 ( 1%) sys 0.36 ( 0%) wall 2694 kB ( 0%) ggc tree iv optimization : 0.17 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 3958 kB ( 0%) ggc tree loop init: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 52 kB ( 0%) ggc tree copy headers : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 1280 kB ( 0%) ggc tree SSA uncprop : 0.03 ( 0%) usr 0.00 ( 0%) sys
[Bug tree-optimization/34683] New: compile-time problem with -fstrict-aliasing
The attached Fortran file takes unusually long to compile with full optimization on the latest GCC trunk builds. I tried a lot of the optimization flags, and found that -fstrict-aliasing seems to trigger the long compile-time. Without this flag the compile-time is perfectly reasonable, as you can see from the following numbers (using trunk revision 131325 on i686-pc-linux-gnu, Pentium M 1,7Ghz and 1GB memory): -O0: 0.9s -O1: 4.5s -O2 -fno-strict-aliasing: 8.0s -O3 -fno-strict-aliasing: 10.4s But once I use -fstrict-aliasing, compile-time explodes: -O1 -fstrict-aliasing: 1m10s -O2: 2m16s -O3: 1m43s (-fstrict-aliasing is included in -O2 and -O3, but not in -O1) I don't know why -O3 is faster than -O2 here (which seems funny), but anyway all three numbers are way too large in my opinion. I mean: compile-time rises by a factor of roughly 15, just due to this one flag! I don't even know what the flag is supposed to do for this code. Maybe someone can explain this to me? I didn't examine memory consumption very carefully, but this also seems unusually high, as a similar file failed to compile on an old machine (with only 256MB) due to lack of memory(!). Am I right to assume that something goes wrong here somehow, or can someone tell me why I should expect this kind of behaviour for this code? -- Summary: compile-time problem with -fstrict-aliasing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: 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
[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing
--- 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=14885action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34335] New: valid code rejected when reordering USE statements
Consider the following piece of code: module A type A_type real comp end type end module A module B use A private type(A_type) :: B_var public:: B_var end module B program C use B use A type(A_type):: A_var end program C This is rejected with the error message type(A_type):: A_var 1 Error: Derived type 'a_type' at (1) is being used before it is defined Please note that the error is only thrown under the condition that the USE statements in program C appear in the same order as shown above. When you exchange them and put use A first (or remove use B), then the error goes away. This makes me wonder if this bug is somehow related to PR33295. Also the error only appears with the funny combination of PUBLIC and PRIVATE in module B. Admittedly, it looks a little strange and is not very useful, but nevertheless I think it's valid Fortran (someone correct me if I'm wrong). -- Summary: valid code rejected when reordering USE 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=34335
[Bug fortran/34335] [4.3 Regression] valid code rejected when reordering USE statements
--- 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: What|Removed |Added Keywords||rejects-valid Known to fail||4.3.0 Known to work||4.2.1 Summary|valid code rejected when|[4.3 Regression] valid code |reordering USE statements |rejected when reordering USE ||statements http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34335
[Bug fortran/34335] [4.3 Regression] valid code rejected when reordering USE statements
--- 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
[Bug fortran/34335] [4.3 Regression] valid code rejected when reordering USE statements
--- 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 this. I don't think your guess is uneducated at all. I nailed the error down to revision 130395, which is Paul's fix for PR33541. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34335
[Bug fortran/33162] INTRINSIC functions as ACTUAL argument
--- 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(1.0) end program Seems like this is due to the stuff which you added to decl.c (match_procedure_decl): + if (proc_if != NULL proc_if-attr.intrinsic + gfc_intrinsic_actual_ok (proc_if-name, 0)) + goto set_if; + if (!sym-attr.pointer gfc_add_external (sym-attr, NULL) == FAILURE) return MATCH_ERROR; if (gfc_add_proc (sym-attr, sym-name, NULL) == FAILURE) return MATCH_ERROR; /* Set interface. */ +set_if: This prevents the procedure from getting the external and procedure attributes, if the interface is an intrinsic routine. This is wrong. A symbol declared by a PROCEDURE() statement should always get the procedure attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162
[Bug fortran/33295] New: ICE in fold_const.c (fold_convert) when reordering USE statements
The following code produces the error internal compiler error: in fold_convert, at fold-const.c:2626 when compiled with GCC trunk rev. 128037: module A type A_type real comp end type end module A module B contains function initA() use A implicit none type(A_type):: initA initA%comp=1.0 end function end module B program C use B use A implicit none type(A_type):: A_var A_var = initA() end program C The crucial part here are the USE statements in program C. The error only pops up when they appear as listed above. Exchanging them to use A use B makes the error vanish. The error is also killed by A_var = initA() It happens for GCC 4.3.0 (trunk) as well as 4.1.3 and 4.2.1. The target system is i686-pc-linux-gnu. -- Summary: ICE in fold_const.c (fold_convert) when reordering USE 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
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- 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
[Bug fortran/32946] New: ICE (segfault) when compiling with -O3 (-fpredictive-commoning)
consider the following code: module mo contains subroutine sub(epstab) implicit none real epstab(52) integer i,ib,ib2,ie do i = 1, ie ib2 = ib+2 epstab(ib) = epstab(ib2) ib = ib2 end do end subroutine sub end module mo this fails with an ICE (segmentation fault) when it is compiled with -O3, but shows no problems with -O2. I found that the flag which causes this is -fpredictive-commoning (but this only causes the segfault in combination with -O1 or -O2). to sum up, the following sets of flags cause a segfault for me: * gfortran-4.3 -O3 * gfortran-4.3 -O2 -fpredictive-commoning * gfortran-4.3 -O1 -fpredictive-commoning in contrast, the following flags cause no segfault: * gfortran-4.3 -O1 * gfortran-4.3 -O2 * gfortran-4.3 -fpredictive-commoning I'm using GCC trunk rev 127088 on i686-pc-linux-gnu. -- Summary: ICE (segfault) when compiling with -O3 (-fpredictive- commoning) 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=32946
[Bug fortran/32813] New: [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
I get an ICE when compiling the following code with the -fbounds-check option: program emptyif implicit none integer i,K(4) if (K(i)==0) then ! do absolutely nothing end if end program the error message is: emptyif.f90: In function MAIN__: emptyif.f90:6: internal compiler error: in annotate_all_with_locus, at gimplify.c:806 this error only occurs under the following circumstances: * GCC version 4.3 (4.1 and 4.2 work) * compilation with -fbounds-check option * if statement is empty (contains no further statements/does nothing) * an array expression is involved I noticed this bug in rev. 126726 and I suspect it's a relatively new regression, probably introduced during the last week (or two), because I think around July 9 I was still able to compile code like the above without errors. -- Summary: [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check 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=32813
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- 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
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- 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): Expand a scalar initializer for a parameter array into an array expression with the right shape. * array.c (spec_dimen_size): Remove static attribute. * gfortran.h : Prototype for spec_dimen_size. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00406.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug fortran/32710] New: ICE: namelist and subroutine with the same name
program samename contains subroutine readInput implicit none integer:: a,b,c NAMELIST /name/ a,b,c read(5,nml=name) end subroutine readInput subroutine name() end subroutine name end program this code fails with the following error (gfortran 4.3 and 4.1.3): samename.f90: In function readinput: samename.f90:6: internal compiler error: Segmentation fault for gfortran 4.2 the error message is: samename.f90: In function readinput: samename.f90:6: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:693 just defining the namelist works fine, only the read statement triggers the ICE -- Summary: ICE: namelist and subroutine with the same name 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=32710
[Bug fortran/32682] New: [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
consider the following program: program matrix implicit none real,dimension(2,2),parameter::c=0 real,dimension(2,2)::m m=f()+c m=c+f() call sub(m+f()) call sub(c+m) call sub(f()+c) call sub(c+f()) contains function f() implicit none real, dimension(2,2)::f f=0 end function f subroutine sub(a) implicit none real, dimension(2,2)::a end subroutine sub end program matrix this gives the error message: matrix.f90: In function MAIN__: matrix.f90:11: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1664 though the message claims an error in line 11, the program only fails in the presence of line 12: call sub(c+f()) all the lines before (7-11) are ok. the ICE only appears in exactly this configuration, i.e. c is a parameter, f is a function, and c+f() is fed as an argument to a subroutine it happens in trans-array.c(gfc_trans_array_constructor), line 1664: /* We should have a 1-dimensional, zero-based loop. */ gcc_assert (loop-dimen == 1); this fails with loop-dimen==2 in our case happens only with 4.3 (trunk), but not with 4.1 or 4.2 -- Summary: [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664 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=32682
[Bug fortran/32669] New: Actual argument contains too few elements for dummy argument is triggered for valid code
The following piece of code is rejected: program tfe implicit none real ,dimension(1:4) :: x real ,dimension(0:3) :: y real ,dimension(-1:2) :: z call sub(x(:)) call sub(y(:)) call sub(z(:)) contains subroutine sub(a) implicit none real,dimension(1:4) :: a end subroutine sub end program tfe with these error messages: too_few_elements.f90:10.9: call sub(y(:)) 1 Warning: Actual argument contains too few elements for dummy argument 'a' (3/4) at (1) too_few_elements.f90:11.9: call sub(z(:)) 1 Warning: Actual argument contains too few elements for dummy argument 'a' (2/4) at (1) Seems like for arrays with the notation x(:) the actual size is miscomputed if they appear as an argument to a subroutine. Apparently this just happens for arrays whose lower bound is zero or less (y,z), while for positive lower bound everything is fine (x). Also there is no problem if the array is given in the form y(0:3) or just y. The code above is accepted by gcc 4.1 and 4.2, but rejected by recent 4.3 trunk builds. So it seems to be a regression introduced in 4.3. The error messages come from interface.c(compare_actual_formal), line 1608. The size of the actual argument is computed by actual_size = get_expr_storage_size(a-expr); Maybe there is a problem in this routine? -- Summary: Actual argument contains too few elements for dummy argument is triggered for 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
