--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-18 21:20 ---
Can you attach a working example? I failed to apply your patch and figure out
which diffed file is what.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-19 11:36 ---
Another related item are complex parts; contrary to the type parameter inquiry
above, those are lvalues and can be assigned to. (Again a F2003 feature, quote
is however from F2008.)
"R615 complex-part-desig
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-20 06:01 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00310.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-20 12:43 ---
The dump is the following. gfortran_select_string returns only 0, 1, or 2, but
the middle end does not know this.
Manuel, do you have an idea how to solve this?
case_num.1 = _gfortran_select_string ((void
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-20 13:40 ---
switch (case_num.1)
{
case 1 ... 1:;
case 2 ... 2:;
__result_char2type = 1;
goto L.1;
case 0 ... 0:;
__result_char2type = -1234;
goto L.1
: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40246
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-25 23:02 ---
The following should be enough. gfc_can_put_var_on_stack is also called
elsewhere but those calls shouldn't matter so much.
Index: trans-d
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-26 08:32 ---
The following patch to gfc_match_nullify fixes it; however, I think one should
additionally add
gfc_free_expr (new_st.expr1);
new_st.expr1 = NULL;
gfc_free_expr (new_st.expr2);
new_st.expr2 = NULL;
to
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-26 14:45 ---
> > The following patch to gfc_match_nullify fixes it; however, I think one
> > should additionally add
> > gfc_free_expr (new_st.expr1);
> > gfc_free_expr (new_st.expr2);
>
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-26 19:23 ---
Subject: Bug 40246
Author: burnus
Date: Tue May 26 19:23:45 2009
New Revision: 147879
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147879
Log:
2009-05-26 Tobias Burnus
PR fortr
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-26 19:29 ---
s/main_program/is_main_program/
CLOSE as WONTFIX. As Andrew pointed out, there are a couple of issues using
static memory:
1. The middle end does not optimize static variables that well as it does not
know about
--- Comment #6 from burnus at gcc dot gnu dot org 2009-05-26 19:30 ---
Fixed on the trunk (4.5). Thanks Xavier for reporting it!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
ity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40264
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-26 21:20 ---
Subject: Bug 39178
Author: burnus
Date: Tue May 26 21:19:57 2009
New Revision: 147883
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147883
Log:
fortran/
2009-05-26 Tobias Burnus
PR fortr
04
--
Summary: Eventually get rid of libgfortranbegin.a
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-27 07:29 ---
FIXED on the trunk (4.5).
Regarding libgfortranbegin.a, see PR 40267.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 07:44 ---
I don't think your patch fixes the following,
print *, leadz(-1_1), leadz(-1_2), leadz(-1_4), leadz(-1_8), leadz(-1_16)
which yields
7 15 31 63 127
--
--- Comment #21 from burnus at gcc dot gnu dot org 2009-05-27 13:02 ---
Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for
invalid program with -fwhole-file).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-27 14:26 ---
Thanks for reporting it. I don't quite understand why I did not see it. Anyhow,
for
PROGRAM TEST
END PROGRAM TEST
one gets the dump:
test ()
{
(void) 0;
}
main (integer(kind=4) argc, character(k
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-27 15:06 ---
> Some tests fail such as:
> /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/actual_procedure_1.f90
> Undefined symbols:
> "_proc_ext_", referenced from:
> _proc_ext_$non_lazy_ptr
--- Comment #8 from burnus at gcc dot gnu dot org 2009-05-27 16:43 ---
(In reply to comment #6)
> The patch in comment #5 fixes most of the issues, not all. Remaining
[...]
> parameter_unused and blockdata_3 fail because it complains that argc and argv
> are unused, even t
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 17:29 ---
See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
rsion: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40276
--- Comment #9 from burnus at gcc dot gnu dot org 2009-05-27 19:49 ---
Subject: Bug 40270
Author: burnus
Date: Wed May 27 19:49:22 2009
New Revision: 147926
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147926
Log:
2009-05-27 Tobias Burnus
PR fortr
--- Comment #10 from burnus at gcc dot gnu dot org 2009-05-27 20:12 ---
> The patch below fixes the elemental_dependency_1 and vector_subscript_4
> failures:
Janne committed it as Rev. 147919.
Together with the fix of comment 9 and with the ABI revert-patch
http://gcc.gnu.
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 21:40 ---
Created an attachment (id=17922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17922&action=view)
Very initial draft patch
Some patch; now it prints:
call gen(sub)
1
Error: Type/rank m
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-27 21:48 ---
Now that PR 40270 is fixed, can you re-check? If it is still broken, I need
more details. (I don't have access to SPEC CPU.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40271
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-28 21:50 ---
Before removal, one may deprecate it as explained at:
http://gcc.gnu.org/ml/fortran/2009-05/msg00400.html
http://gcc.gnu.org/ml/fortran/2009-05/msg00401.html
(I needed to remove the , "rd" to get i
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-29 07:43 ---
Is this a duplicate of PR 40040?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24526
--- Comment #12 from burnus at gcc dot gnu dot org 2009-05-29 07:44 ---
Jakub, I think this PR is fixed and can be closed. The remaining issue (ld or
gcc bug) is tracked in PR 40040. Can we close it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
--- Comment #26 from burnus at gcc dot gnu dot org 2009-05-29 18:42 ---
> Even identical types are not identical, unless they are sequence type.
... or BIND(C)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-29 21:28 ---
Subject: Bug 40019
Author: burnus
Date: Fri May 29 21:27:54 2009
New Revision: 147987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147987
Log:
2009-05-29 Francois-Xavier Coudert
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-29 21:33 ---
Checked into the trunk (4.5). Keep open for potential back porting to 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40019
--- Comment #8 from burnus at gcc dot gnu dot org 2009-05-30 21:14 ---
Latest patch - fixing the main_identifier_node (__main() call) problem as in
comment 4 plus fixes the "PROGRAM main" problem.
http://gcc.gnu.org/ml/fortran/2009-05/msg00458.html
--
burnus at gcc dot g
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-01 07:00 ---
Subject: Bug 40309
Author: burnus
Date: Mon Jun 1 07:00:35 2009
New Revision: 148035
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148035
Log:
2009-06-01 Tobias Burnus
PR fortr
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-01 07:34 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-01 11:09 ---
Regarding the run-time evaluation, note that Fortran sets (internally) the
-fcx-fortran-rules flag, which modifies the complex evaluation.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-01 17:41 ---
If we can have a warning/error at compile time it would be great.
However, I'm inclined to allow it for -std=gnu at run time. (I'm personally
against too much standard diagnostics at run time. If suc
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-01 20:33 ---
> Oh yuck. I just checked n1124.pdf In Annex G.5.1, it explicitly
> defines this behavior:
Note: Annex G is "only" informative and not normative; still it makes probably
sense to follow the inform
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-03 18:58 ---
(In reply to comment #7)
> Fixed on trunk.
> I'll backport to 4.4. branch in a week.
* ping *
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-03 19:39 ---
Subject: Bug 40019
Author: burnus
Date: Wed Jun 3 19:39:09 2009
New Revision: 148143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148143
Log:
2009-06-03 Francois-Xavier Coudert
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2009-06-03 19:40 ---
Now also FIXED on the 4.4 branch. -> CLOSE
--
burnus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-04 05:36 ---
> Thanks, don't wait too long with 4.4 as this should make it in 4.4.1 which
> could be released this month, and some further testing on the branch would be
> good:
Planned for June 21, see (bett
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-04 06:41 ---
With trunk 2009-04-05-r145558 I get
HELLO
correct
while with trunk 2009-04-06-r145580 the result is
HELLO
error2: not at eof
It is not surprising that the following patch was checked in between those
revisions
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-04 06:43 ---
Can this PR now be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-04 11:47 ---
Cf. also thread at http://gcc.gnu.org/ml/fortran/2009-06/msg00057.html
(Maybe if -fwhole-file is the permanent default and this problem is fixed, the
hack at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-04 12:51 ---
(In reply to comment #10)
> That hack is already gone ... ;)
The truck hack yes, the question is whether one can also do something about the
following? Or is this a wider problem?
/* ??? Array types are
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-04 20:48 ---
> ld: FATAL 2 : Internal: at ../../ld/multigot.c lgot_local_got_offset()
> seg_ndx exceeds per_seg_lgot_table
Sounds like a linker bug. What was actually the solution for
http://gcc.gnu.
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-04 21:52 ---
Subject: Bug 37203
Author: burnus
Date: Thu Jun 4 21:52:32 2009
New Revision: 148190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148190
Log:
gcc/fortran/
2009-06-04 Daniel Franke
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-04 21:59 ---
Merged patch from the fortran-dev branch to the trunk (4.5).
Close bug as FIXED. Thanks for the patches, Thomas and Daniel!
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-06 18:51 ---
Subject: Bug 32890
Author: burnus
Date: Sat Jun 6 18:51:29 2009
New Revision: 148237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148237
Log:
fortran/
2009-06-06 Daniel Franke
PR fortr
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-06 21:10 ---
Subject: Bug 37203
Author: burnus
Date: Sat Jun 6 21:09:57 2009
New Revision: 148238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148238
Log:
2009-06-06 Daniel Franke
PR fortr
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-06 21:17 ---
FIXED on the trunk (4.5). Close.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-07 11:53 ---
Subject: Bug 25104
Author: burnus
Date: Sun Jun 7 11:53:21 2009
New Revision: 148243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243
Log:
2009-06-07 Daniel Franke
PR fortr
--- Comment #17 from burnus at gcc dot gnu dot org 2009-06-07 11:53 ---
Subject: Bug 29962
Author: burnus
Date: Sun Jun 7 11:53:21 2009
New Revision: 148243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243
Log:
2009-06-07 Daniel Franke
PR fortr
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-07 13:46 ---
Subject: Bug 36874
Author: burnus
Date: Sun Jun 7 13:45:47 2009
New Revision: 148247
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148247
Log:
2009-06-07 Daniel Franke
* check.c (dim_ra
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-07 13:59 ---
Compile time check is now there (4.5 trunk). Missing is a run-time check.
Example:
real, dimension(1,0) :: a, b, c
integer :: sp(3), i
a = 4.0
sp = 1
i = 1
b = eoshift (a,sp(1:i)) ! Invalid
end
NAG
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-07 14:37 ---
> Does this need a 4.4 backport? I'm inclined to think not.
Good question. As it is no regression, backporting is not required; it is a
wrong-code bug, but strides are rather special. Thus for me eith
--- Comment #17 from burnus at gcc dot gnu dot org 2009-06-07 16:35 ---
Subject: Bug 25104
Author: burnus
Date: Sun Jun 7 16:35:06 2009
New Revision: 148249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148249
Log:
2009-06-07 Daniel Franke
PR fortr
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-07 16:35 ---
Subject: Bug 29962
Author: burnus
Date: Sun Jun 7 16:35:06 2009
New Revision: 148249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148249
Log:
2009-06-07 Daniel Franke
PR fortr
--- Comment #19 from burnus at gcc dot gnu dot org 2009-06-07 17:33 ---
Subject: Bug 29962
Author: burnus
Date: Sun Jun 7 17:33:34 2009
New Revision: 148250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148250
Log:
2009-06-07 Daniel Franke
PR fortr
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-07 17:33 ---
Subject: Bug 25104
Author: burnus
Date: Sun Jun 7 17:33:34 2009
New Revision: 148250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148250
Log:
2009-06-07 Daniel Franke
PR fortr
iority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40377
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-08 09:11 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/fc7bdedfa4afc785
and note that the realloc shall not always happen: If has TARGET
attribute and the size is the same, no pointer to
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-08 19:02 ---
As this is my texi cleanup bug: Dump the following in order to not forget it.
Index: intrinsic.texi
===
--- intrinsic.texi (Revision 148274
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-09 10:29 ---
I think the patch for PR fortran/37746 is OK, but something else goes wrong:
f1 (character(kind=1)[1:80] * a, character(kind=1)[1:80] * b,
character(kind=1)[1:80] * c, character(kind=1)[1:80] * d, integer(kind=4) _a
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-09 12:09 ---
The problem is that fsym->ts.cl of all of "a", "b", "c" and "d" to the same
struct:
(gdb) p sym->formal->sym->name
$17 = 0x2ab31ec8 "a"
(gdb) p s
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-09 12:24 ---
Richard, can you try to reproduce this? I don't have SPEC and anyhow it sounds
like a middle-end problem.
--
burnus at gcc dot gnu dot org changed:
What|Removed |
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-10 06:45 ---
> I was able to do a regression hunt. Going to r145209 just before the big I/O
> patch eliminates the error. I then moved forward to r145636 and confirmed the
> breakage.
Is 4.5 also affected?
-
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-10 12:02 ---
Patch -- I believe it does the right thing; especially, it preserves
backend_decl. If one copied the type earlier, the backend_decl would be
different and the backend does not like it, when the same type has
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-10 12:05 ---
Forgot to mention: I will not be able to regtest/submit the patch before Monday
evening.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 07:46 ---
Paul, I CC you as you are our generic-resolution expert.
* * *
gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
print the following:
E
S, S
E
E, E ! << you expect an "
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 08:52 ---
(In reply to comment #2)
> COmplete code for the test case including the module iso_varying_string
Works with: gfortran 4.3.3, ifort 11, sunf95, NAG f95 5.1 (w/o flush
statements)
Fails (abort) with gfortran 4.
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 11:24 ---
> > gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> > print the following:
Correction, ifort 9.1 to 11.1 all print "S, S" - sorry for missing it. But the
other
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-15 12:16 ---
Note: syntax_get_rule_ptr is defined as:
function syntax_get_rule_ptr (syntax, key) result (rule)
type(syntax_rule_t), pointer :: rule
type(syntax_t), intent(in), target :: syntax
type(string_t
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-15 13:09 ---
Juergen: Thanks for the report, but it is not a regression - it might not crash
with 4.3 (or your 4.4) but I think that's just by chance.
Paul, I think also this bug touches code for which you have the expe
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 21:10 ---
Post script: With your current patch, the error message is:
Error: Interface mismatch in procedure pointer assignment at (1): 'sin' has the
wrong number of arguments
--
http://gcc.gnu.org/bugzilla/sh
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-15 22:40 ---
Also for OPTIONAL a suitable error message would be useful. For finding a
specific interface, the OPTIONAL attribute could be ignored similarly to
INTENT; however, one needs to be careful as for ambiguity checks and
ds: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40453
--- Comment #6 from burnus at gcc dot gnu dot org 2009-06-16 06:57 ---
Subject: Bug 40383
Author: burnus
Date: Tue Jun 16 06:57:09 2009
New Revision: 148517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148517
Log:
2009-06-16 Tobias Burnus
PR fortr
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-16 06:57 ---
FIXED on the trunk (4.5).
Patch was: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01147.html
See also follow-up PR 40452.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-16 08:19 ---
(In reply to comment #0)
> The challenge is diagnose this properly. The problem is that the array size is
> _not_ passed. One solution would be to enable the check only with -std=f95.
And for scalar dummy arg
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-16 14:22 ---
Add c.l.f link, mentioned in comment 9
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7bbe1ee44c505be8/
Regarding TARGET_MANGLE_DECL_ASSEMBLER_NAME (comment 2):
Currently, the decorating
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-16 16:35 ---
Note information I got from Kai. (He was not 100% sure for some of the items
and I probably misunderstood also parts thus take with a grain of salt.)
With the stdcall attribute on Win32 the @ suffix is
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-16 17:36 ---
I think the error is a valid error. For comparison, NAG f95 5.1 shows the
following error message:
Error: line 19: Dummy proc DERIV arg 1 has different INTENT from actual proc
LOGISTIC4 arg
Error: line 19
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-16 21:32 ---
Wrong quote - and wrong statement. It is not a F2003 change, but already in
F95.
Fortran 95 has (12.4.1.4 Sequence association)
"If the actual argument is of type default character and is an array
expre
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-18 08:49 ---
I close this as INVALID. If you have suggestions how to improve the diagnostics
or if you disagree, feel free to reopen the bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-18 09:00 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-06/msg00188.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-18 14:45 ---
> I am not sure that your testcase should be allowed at all! I am not sure that
> I understand what it means.
I think it is valid and not different from:
integer, pointer :: ptr
allocate(ptr)
ptr = 5
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-18 15:17 ---
(In reply to comment #7)
> I'm still convinced that this is a problem of the compiler, since it works
> with the
> NAG and Intel compilers.
Well, compilers can have all bugs - and not all invalid p
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-18 20:06 ---
Subject: Bug 40061
Author: burnus
Date: Thu Jun 18 20:06:04 2009
New Revision: 148668
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148668
Log:
2009-06-18 Tobias Burnus
Mikael Pe
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-18 20:06 ---
Hopefully now really FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-18 21:15 ---
(In reply to comment #10)
> Yes, I understood after a bit of dyslexia about it :-(
>
> Since the function result is a pointer, it is an ultimate component and, I
> think, the deallocation of the
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-19 07:31 ---
(In reply to comment #1)
> Here is a preliminary patch which fixes the test case:
> if (fsym && e->expr_type != EXPR_NULL
> &am
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-19 07:32 ---
Patch by Janus: http://gcc.gnu.org/ml/fortran/2009-06/msg00177.html
(I try to get it reviewed soon.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40427
201 - 300 of 4285 matches
Mail list logo
