Hi Tobias,
could you also patches, which you commit as obvious to the mailing lists?
yes, I usually do this, but this time I just forgot. Sorry.
Regarding the last patch, the GNU style puts a line break after the ) in:
+ if (!sym) return NULL;
+
In principle I'm aware of the GNU coding
Weil ja...@gcc.gnu.org
PR fortran/35831
PR fortran/47978
* interface.c (check_dummy_characteristics): New function to check the
characteristics of dummy arguments.
(gfc_compare_interfaces,gfc_check_typebound_override): Call it here.
2011-09-11 Janus Weil
Hi Tobias,
Update: Here is an extended version of the patch, which adds a few
additional checks:
The patch still regtests cleanly. Ok for trunk?
+ switch (compval)
+ {
...
+ default:
+ gfc_internal_error (check_dummy_characteristics: Unexpected
result
+
+ switch (compval)
+ {
...
+ default:
+ gfc_internal_error (check_dummy_characteristics: Unexpected
result
+ %i of gfc_dep_compare_expr, compval);
+ break;
+ }
+ }
I think we really should move to enum.
Agreed.
changed slightly (typebound_proc_6).
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2011-09-09 Janus Weil ja...@gcc.gnu.org
PR fortran/47978
* interface.c (check_dummy_characteristics): New function to check the
characteristics of dummy arguments
(comment #8).
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2011-09-07 Janus Weil ja...@gcc.gnu.org
PR fortran/48095
* primary.c (gfc_match_structure_constructor): Handle parsing of
procedure pointers components in structure constructors
Hi Tobias,
+ if (s2 !gfc_compare_interfaces (comp-ts.interface, s2, name,
0, 1,
+ err, sizeof(err)))
Space after sizeof.
Fixed.
+ gfc_error (In derived type constructor at %L: Interface
mismatch
+
I'll do another regtest with the updated patch (the changed error
messages might need testsuite adaptions?) and then go ahead and commit
it.
Committed as r178665 with some minor corrections.
Cheers,
Janus
Janus Weil ja...@gcc.gnu.org
PR fortran/50225
* trans-decl.c (gfc_generate_function_code): Nullify polymorphic
allocatable function results.
2011-08-29 Janus Weil ja...@gcc.gnu.org
PR fortran/50225
* gfortran.dg/class_result_1.f03: New.
Index: gcc
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK. Looks rather obvious.
Thanks. Committed as r178262.
Cheers,
Janus
2011-08-29 Janus Weilja...@gcc.gnu.org
PR fortran/50225
* trans-decl.c (gfc_generate_function_code): Nullify polymorphic
There is for example (currently) no special handling for operators.
Well, unfortunately one cannot just return -3 for non-matching
operators. Just think of cases like A*(B+C) vs A*B+A*C.
Ah yes. I was thinking expressions themselves were compared; but only their
values are.
I'm not sure
Ping! (Maybe I should have posted the follow-up patch in a separate
thread to make it more visible.)
2011/8/13 Janus Weil ja...@gcc.gnu.org:
Hi Thomas, hi all,
2011/8/7 Thomas Koenig tkoe...@netcologne.de:
When extending the values of gfc_dep_compare_expr, we will need to go
through all
2011/8/7 Thomas Koenig tkoe...@netcologne.de:
When extending the values of gfc_dep_compare_expr, we will need to go
through all its uses (making sure we change == -2 to = -2).
attached is a patch which makes a start with this.
For now, it changes the return value to -3 for two cases:
' to me.
In any case, the patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2011-08-16 Janus Weil ja...@gcc.gnu.org
PR fortran/50070
* resolve.c (resolve_fl_variable): Reject non-constant character lengths
in COMMON variables.
2011-08-16 Janus
Hi all,
I just committed as obvious the fix for an accepts-invalid problem
involving function results. I simply took an existing check, separated
it off into a small function, and called it from another place (where
it was missed previously):
http://gcc.gnu.org/viewcvs?root=gccview=revrev=177745
2011/8/7 Thomas Koenig tkoe...@netcologne.de:
Hi Janus,
Here is a preparational patch (basically a subset of the
previous one), which does not do any real changes yet, only some
preparation and cleanup:
* It moves check_typebound_override to interface.c and prefixes it
with gfc_ (I don't
OK from my side (given Mikael's comments), provided you spell resolve.c with
two e :-)
Thanks, guys. Committed as r177545 (including your comments).
Ok, with the 'trivial' parts out of the way, the remainder of my
previously proposed patch becomes rather compact (see attachment).
Thomas'
2011/8/7 Thomas Koenig tkoe...@netcologne.de:
Am 07.08.2011 12:56, schrieb Janus Weil:
+ /* Check string length. */
+ if (proc_target-result-ts.type == BT_CHARACTER
+ proc_target-result-ts.u.cl old_target-result-ts.u.cl
+ gfc_dep_compare_expr (proc_target-result
2011/8/7 Janus Weil ja...@gcc.gnu.org:
2011/8/7 Thomas Koenig tkoe...@netcologne.de:
Am 07.08.2011 12:56, schrieb Janus Weil:
+ /* Check string length. */
+ if (proc_target-result-ts.type == BT_CHARACTER
+ proc_target-result-ts.u.cl old_target-result-ts.u.cl
Alright then. How about this: I'll commit the attached verision of the
patch (including your suggestions), and we start messing with the
return values afterwards? Patch is regtested on
x86_64-unknown-linux-gnu. I hope the test case is sufficient for a
start.
This is OK. Thanks for the
It is wrong to assume that expressions are unequal because we cannot
prove they are equal, with all the limitations that we currently
have. This will introduce rejects-valid bugs.
In the PR at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638#c8
I quote the standard:
4.5.7.3 (type-bound
Hi Thomas,
The string length expressions of overridden procedures have to be
identical, but with exchanged dummy arguments. Since the dummy
arguments of overridden procedures must have the same name as in the
base procedure, it is sufficient the check for equal names. Checking
for equal
without any regressions. Can anybody think of a case where the names can
be
identical, but the variables different? (I can't).
Well, I'd say this can only happen if both variables reside in
different namespaces (i.e. different modules or procedures).
gfc_are_identical variables is
Here is a variant of the original test case from the PR, which will be
accepted if we only check for names (but it should actually be
rejected):
module world
implicit none
type :: world_1
contains
procedure, nopass :: string = w1_string
end type
type, extends(world_1) ::
2011/8/6 Mikael Morin mikael.mo...@sfr.fr:
On Saturday 06 August 2011 19:10:09 Janus Weil wrote:
Now, if Thomas says it's fine for the other cases, too, then it seems
we can really get away with a much simpler patch. Hope we're not
missing anything, though ...
What about this case: two
Hi Thomas,
+ /* Check string length. */
+ if (proc_target-result-ts.type == BT_CHARACTER
+ proc_target-result-ts.u.cl old_target-result-ts.u.cl
+ gfc_dep_compare_expr (proc_target-result-ts.u.cl-length,
+
For the overriding check, we don't care about which expr is larger, we
want to know whether they are the same or not. So, in many cases we
will just get a warning, although we definitely know that the expr's
are different.
Example: Differing expr_type, e.g. one procedure has len=3, the other
2011/8/6 Thomas Koenig tkoe...@netcologne.de:
Am 06.08.2011 23:10, schrieb Janus Weil:
I'm know that this does not exactly fit in any of your categories.
However, I still think that throwing an error for every case where we
can not prove that the expressions are equal is a good approximation
2011/7/31 Janus Weil ja...@gcc.gnu.org:
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.6?
OK, Thanks.
Thanks, Mikael. Committed to trunk as r176971. Will apply to 4.6 soon.
Committed to 4.6 as r177468.
Cheers,
Janus
Hi Mikael,
The extra
argument controls whether we check variable symbols for equality or
just their names. For the overriding checks it is sufficient to check
for names, because the arguments of the overriding procedure are
required to have the same names as in the base procedure.
Unless
Hi all,
attached is a draft patch fixing the PR in the subject line and
extending the checks for overriding type-bound functions. It regtests
cleanly on x86_64-unknown-linux-gnu already, but I would like to have
some feedback.
The patch is rather large, but most of it is just mechanical, due to
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.6?
OK, Thanks.
Thanks, Mikael. Committed to trunk as r176971. Will apply to 4.6 soon.
Cheers,
Janus
.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.6?
Cheers,
Janus
2011-07-30 Janus Weil ja...@gcc.gnu.org
PR fortran/49112
* resolve.c (resolve_structure_cons): Don't do the full dt resolution,
only call 'resolve_fl_derived0
Fixed on 4.6 with r176659. How about 4.5?
Thanks for the committal. Regarding 4.5, I do not have a strong feeling, but
as the patch is simple and 4.5 is still used, you might want to commit it to
that branch as well.
Agreed. Committed to 4.5 as r176688.
Cheers,
Janus
Fixed on 4.6 with r176659. How about 4.5?
Cheers,
Janus
2011/7/19 Janus Weil ja...@gcc.gnu.org:
Hi all,
I just committed a small patch for an ICE-on-invalid regression with
ALLOCATE, which was approved by Tobias in the PR:
http://gcc.gnu.org/viewcvs?view=revisionrevision=176447
I
OK for trunk and 4.6.
Thanks, Paul.
Committed to trunk as r175779. Will apply to the 4.6 branch in a few days.
Cheers,
Janus
On Tue, Jun 28, 2011 at 5:40 PM, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
here is a patch for a problem which was originally reported as an
ICE-on-invalid
Ping ... !
2011/6/28 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is a patch for a problem which was originally reported as an
ICE-on-invalid regression (assigning to a type-bound function).
In the course of fixing it, I noticed that it becomes valid according
to F08 if the function
?
Cheers,
Janus
2011-06-28 Janus Weil ja...@gcc.gnu.org
PR fortran/49562
* expr.c (gfc_check_vardef_context): Handle type-bound procedures.
2011-06-28 Janus Weil ja...@gcc.gnu.org
PR fortran/49562
* gfortran.dg/typebound_proc_23.f90: New.
Index: gcc
case, the patch was regtested on x86_64-unknown-linux-gnu. I'll
commit to trunk as obvious tomorrow.
Cheers,
Janus
2011-06-21 Janus Weil ja...@gcc.gnu.org
PR fortran/49112
* class.c (gfc_find_derived_vtab): Make vtab and default initialization
symbols SAVE_IMPLICIT
Hi all,
I have just committed to trunk a simple patch for an OOP regression
with MOVE_ALLOC (see comment #9-#11 in the PR):
http://gcc.gnu.org/viewcvs?view=revisionrevision=175151
I will apply this to the 4.6 branch soon.
Cheers,
Janus
Sorry, clearly the test case was missing a dg-error directive. Here's
the corrected version.
Cheers,
Janus
2011/6/15 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is the fix for an OOP-regression reported today by Andrew Benson
(http://gcc.gnu.org/ml/fortran/2011-06/msg00119.html
from module files, since the attribute
itself is not written to the file.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2011-06-15 Janus Weil ja...@gcc.gnu.org
PR fortran/49417
* module.c (mio_component): Make sure the 'class_ok' attribute
here is the fix for an OOP-regression reported today by Andrew Benson
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
The patch is OK - thanks for the quick fix.
Thanks, will commit soon.
The patch has been applied to trunk as r175101. Will commit to the 4.6
branch in a
Hi all,
here is a fix for a problem, where the module loading could not handle
components of extended types. Regtested on x86_64-unknown-linux-gnu.
Ok for trunk?
Cheers,
Janus
2011-05-29 Janus Weil ja...@gcc.gnu.org
PR fortran/47601
* module.c (mio_component_ref): Handle
Ok for trunk?
2011-05-29 Janus Weil ja...@gcc.gnu.org
PR fortran/47601
* module.c (mio_component_ref): Handle components of extended types.
* symbol.c (gfc_find_component): Return is sym is NULL.
2011-05-29 Janus Weil ja...@gcc.gnu.org
PR fortran/47601
Hi all,
I just committed an obvious patch fixing a small problem with SELECT
TYPE (after successful regtest):
http://gcc.gnu.org/viewcvs?view=revisionrevision=174001
Cheers,
Janus
Hi all,
I just committed a rather obvious fix for a type extension problem
(after regtesting and approval by Tobias on bugzilla):
http://gcc.gnu.org/viewcvs?root=gccview=revrev=173966
Cheers,
Janus
support and
advice regarding the present implementation of polymorphism and how to
extend it.
This is all I can promise right now ...
Cheers,
Janus
2011-05-16 Janus Weil ja...@gcc.gnu.org
PR fortran/48700
* trans-intrinsic.c (gfc_conv_intrinsic_move_alloc): Deallocate
Ok, since you guys seem to agree on that, here is the patch without module
version bumping, but this time complete with test case and ChangeLog.
Ok for trunk?
OK. Thanks for the patch.
Thanks. Committed as r170871.
Cheers,
Janus
2011-03-10 Janus Weilja...@gcc.gnu.org
PR
701 - 749 of 749 matches
Mail list logo
