on x86_64-unknown-linux-gnu. Ok for trunk? 4.9/4.8?
Cheers,
Janus
2015-01-11 Janus Weil ja...@gcc.gnu.org
PR fortran/63733
* interface.c (gfc_extend_expr): Look for type-bound operators before
non-typebound ones.
2015-01-11 Janus Weil ja...@gcc.gnu.org
PR fortran/63733
Hi all,
I have just committed as obvious a small patch for an ICE-on-invalid
problem with procedure-pointer components:
https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=219439
Cheers,
Janus
Committed as r219431. Thanks for the review!
Cheers,
Janus
2015-01-11 16:16 GMT+01:00 Paul Richard Thomas paul.richard.tho...@gmail.com:
Dear Janus,
As you say, the patch is pretty straightforward :-) OK for trunk.
Thanks for the patch
Paul
On 11 January 2015 at 11:21, Janus Weil ja
Well done for sorting that out. OK for trunk.
Thanks, Paul. Committed as r219440.
What about the branches?
Cheers,
Janus
On 11 January 2015 at 14:38, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
this patch fixes a wrong-code regression related to operators, by
making sure that we look
, according to the usual rules.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-06 Janus Weil ja...@gcc.gnu.org
PR fortran/64508
* interface.c (compare_parameter): Interface check for
procedure-pointer component as actual argument.
2015-01-06 Janus
Hi Andre,
For the
second one (in gfc_conv_expr), I don't directly see how it's related
to deferred char-len. Why is this change needed?
That change is needed, because in some rare case where an associated
variable in a select type () is used, then the type and f90_type match
the
Hi Andre,
1) There are still two TODO markers in the patch. It might be a good
idea to take care of them before committing the patch. In particular
for the first one (adding the initializer in gfc_build_class_symbol)
it would be good to understand where those problems come from.
I started
?
Cheers,
Janus
2015-01-03 Janus Weil ja...@gcc.gnu.org
PR fortran/63552
* primary.c (gfc_match_varspec): Handle type-bound procedures as actual
argument to dummy procedure.
2015-01-03 Janus Weil ja...@gcc.gnu.org
PR fortran/63552
* gfortran.dg/typebound_proc_34.f90: New
Committed as r219144.
Cheers,
Janus
2015-01-02 17:13 GMT+01:00 Janus Weil ja...@gcc.gnu.org:
2015-01-02 17:02 GMT+01:00 Tobias Burnus bur...@net-b.de:
+ int ext = dt-attr.extension;
+ while (ext0 gfc_find_component (dt-components-ts.u.derived,
pick-name,
+ true, true
2015-01-02 17:02 GMT+01:00 Tobias Burnus bur...@net-b.de:
+ int ext = dt-attr.extension;
+ while (ext0 gfc_find_component (dt-components-ts.u.derived,
pick-name,
+ true, true))
+{
+ dt = dt-components-ts.u.derived;
+ c = gfc_constructor_first
Hi Tobias,
Looking through the stashed patches, I realized a pending (unsubmitted)
patch, showing that both a test case for CO_REDUCE was missing and that
libcaf_single didn't include co_reduce.
This patch adds them.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
looks rather
2014-12-31 19:13 GMT+01:00 Tobias Burnus bur...@net-b.de:
here is a patch to improve diagnostics for dummy procedures. Regtested
on x86_64-unknown-linux-gnu. Ok for trunk?
Looks good to me. Thanks for the patch!
Thanks, committed as r219141.
Cheers,
Janus
2014-12-29 Janus Weil ja
2015-01-02 17:24 GMT+01:00 Tobias Burnus bur...@net-b.de:
Looking through the stashed patches, I realized a pending (unsubmitted)
patch, showing that both a test case for CO_REDUCE was missing and that
libcaf_single didn't include co_reduce.
This patch adds them.
Build and regtested on
is located and fetch the corresponding constructor
component.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-02 Janus Weil ja...@gcc.gnu.org
PR fortran/57562
* expr.c (find_component_ref): Deal with extended types.
2015-01-02 Janus Weil ja...@gcc.gnu.org
PR
Hi Andre,
Now, the patch was not intended to solve 61337. Although I have looked into
the
pseudo code generated for 61337, I couldn't figure easily what is going on
there. In my impression, this is something from incorrectly computed bounds to
an integer(8),pointer integer(4),pointer mix
Hi Tobias,
It often happens that one wants to debug PURE procedures but as I/O is not
permitted, this can be difficult. F2008's IMPURE ELEMENTAL helps a bit not
completely.
Fortran 2015 adds another aid – not I/O which is intrinsically impure – but
at least ERROR STOP is now permitted.
(early) ping!
2014-12-29 13:50 GMT+01:00 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is a patch to improve diagnostics for dummy procedures. Regtested
on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-29 Janus Weil ja...@gcc.gnu.org
PR fortran/60507
you're making. I extended the test case
accordingly and committed the whole thing as r219098. Thanks for the
review!
PS happy New Year!
Same to you and everyone else on this mailing list!
Cheers,
Janus
On 27 December 2014 at 18:35, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
here is a small
Hi all,
here is a patch to improve diagnostics for dummy procedures. Regtested
on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-29 Janus Weil ja...@gcc.gnu.org
PR fortran/60507
* interface.c (is_procptr_result): New function to check if an
expression
Hi all,
here is a small patch for an F08 extension: Allocatable components
don't have to be specified in structure constructors any more.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-27 Janus Weil ja...@gcc.gnu.org
PR fortran/60357
* array.c
Hi all,
here is a small patch which enhances the diagnostics for the intrinsic
KIND function. Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-22 Janus Weil ja...@gcc.gnu.org
PR fortran/63363
* check.c (gfc_check_kind): Reject polymorphic and non-data
here is a small patch which enhances the diagnostics for the intrinsic
KIND function. Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK.
Thanks, committed as r219027.
Cheers,
Janus
2014-12-18 0:14 GMT+01:00 Tobias Burnus bur...@net-b.de:
As testing by Alessandro revealed, vector subscripts weren't properly
handled.
This patch fixes the compiler side (or at least those issues I found). In
particular, for expressions (get) it wrongly passed a NULL pointer,
additionally,
their _def_init
is NULL and we simply failed to check for that condition. That's what
the patch does. It regtests cleanly on x86_64-unknown-linux-gnu.
Ok for trunk?
Cheers,
Janus
2014-12-19 Janus Weil ja...@gcc.gnu.org
PR fortran/64209
* trans-expr.c (gfc_trans_class_array_init_assign
2014-12-19 14:48 GMT+01:00 Tobias Burnus tobias.bur...@physik.fu-berlin.de:
As you write yourself, the issue can only occur for CLASS(*). Hence,
please apply this only for UNLIMITED_POLY() to avoid unneccessary code side
increase and performance decrease.
Good point, thanks for reviewing. An
Committed as r218968.
Cheers,
Janus
2014-12-19 18:24 GMT+01:00 Janus Weil ja...@gcc.gnu.org:
2014-12-19 14:48 GMT+01:00 Tobias Burnus tobias.bur...@physik.fu-berlin.de:
As you write yourself, the issue can only occur for CLASS(*). Hence,
please apply this only for UNLIMITED_POLY() to avoid
such code.
In fact the patch uncovered a good number of cases in the testsuite,
which are invalid in this respect. I fixed all of them by making the
encompassing procedure impure. After that the patch regtests cleanly.
Ok for trunk?
Cheers,
Janus
2014-12-19 Janus Weil ja...@gcc.gnu.org
PR
Hi all,
I have just committed as obvious a one-line fix for an ICE-on-valid
problem with procedure pointer components:
https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=218834
Cheers,
Janus
2014-12-16 7:58 GMT+01:00 Tobias Burnus bur...@net-b.de:
Hi Janus, hi all,
Janus Weil wrote:
here is a regression fix for a problem with the NON_OVERRIDABLE
attribute. For non-overridable type-bound procedures we do not have to
generate a call to the vtable, but can just translate
2014-12-15 7:34 GMT+01:00 Tobias Burnus bur...@net-b.de:
Can you change non-pure to impure? That would better match the Fortran
naming, where impure is the default unless pure or elemental is used.
(It was added to permit impure elemental procedures.)
Yes, sure. I have committed this change as
,
Janus
2014-12-15 Janus Weil ja...@gcc.gnu.org
PR fortran/63727
* resolve.c (resolve_actual_arglist): Check for elemental procedure
pointer components.
2014-12-15 Janus Weil ja...@gcc.gnu.org
PR fortran/63727
* gfortran.dg/coarray_collectives_14.f90: Address FIXME item
2014-12-15 14:49 GMT+01:00 Tobias Burnus tobias.bur...@physik.fu-berlin.de:
Janus Weil wrote:
here is another small diagnostic enhancement for procedure pointer
components. Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Looks good to me. Thanks for the patch!
Thanks for the review
call has to be resolved to a
specific one first).
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? And
for 4.8/4.9 after some time?
Cheers,
Janus
2014-12-15 Janus Weil ja...@gcc.gnu.org
PR fortran/64244
* resolve.c (resolve_typebound_call): New argument to pass out
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
s/'%s'/%qs/g
nowadays.
Good point, thank you. Updated patch attached.
I guess I still new formal approval by someone with reviewer status ...
Cheers,
Janus
Index: gcc/fortran/resolve.c
2014-12-14 12:00 GMT+01:00 FX fxcoud...@gmail.com:
Good point, thank you. Updated patch attached.
I guess I still new formal approval by someone with reviewer status …
OK
Thanks, committed as r218717.
Cheers,
Janus
some diagnostics
for the PURE attribute.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-13 Janus Weil ja...@gcc.gnu.org
PR fortran/63674
* resolve.c (pure_function): Treat procedure-pointer components.
(check_pure_function): New function
Hi Tobias,
this patch fixes a problem with the conversion of scalars to descriptors.
There one assigns the address of the scalar to the base_address field of the
descriptor. The ICE occurred when the RHS (the scalar) wasn't a pointer.
looks good to me. Ok for trunk!
It does not fully solve
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Looks good to me - and simple enough for the 4.9 trunk.
Thanks, committed as r208590.
Cheers,
Janus
for the modified behavior.
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Cheers,
Janus
2014-03-14 Janus Weil ja...@gcc.gnu.org
PR fortran/55207
* decl.c (match_attr_spec): Variables in the main program implicitly
get the SAVE attribute in Fortran 2008
Hi Mikael,
here is a fix for a wrong code issue, where we pass a descriptor with
broken bounds when the actual argument is a transposed array and the
dummy an assumed shape dummy.
The bug comes from the interaction of the transpose optimization,
which creates a descriptor with transposed
2014-03-08 8:38 GMT+01:00 Tobias Burnus bur...@net-b.de:
An update the gfortran.texi's F2003/F2008 status.
OK for the trunk?
Sounds good. Ok!
Cheers,
Janus
know.
Also Tobias already told me privately that his mixed feeling were
not strong enough to oppose against committing the patch. So right now
the only thing standing between the patch and trunk seems to be you ;)
Cheers,
Janus
On Mar 5, 2014 2:53 PM, Janus Weil ja...@gcc.gnu.org wrote:
Hi
Hi,
In that case, go for it! I am on vacation in Tenerife right now and have
very limited access.
wow, in that case I guess you better enjoy your holidays ;)
Please commit the patch to trunk.
Will do!
Thanks,
Janus
On Mar 6, 2014 9:59 PM, Janus Weil ja...@gcc.gnu.org wrote:
Hi Paul
Please commit the patch to trunk.
Will do!
I have just committed the patch as r208386, thereby implementing
deferred-length character components on 4.9 trunk. One big plea to the
users: Please test this as soon as possible!
Cheers,
Janus
On Mar 6, 2014 9:59 PM, Janus Weil ja
Hi Mikael,
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
I'm asking for one more minor change, namely:
@@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
return false;
}
+ /* Add the hidden deferred length field. */
+ if
Hi Mikael, hi all,
2014-02-22 16:38 GMT+01:00 Mikael Morin mikael.mo...@sfr.fr:
Le 19/02/2014 16:51, Janus Weil a écrit :
The patch was not applying cleanly any more, so here is a re-diffed
version for current trunk. It works nicely on the included test case
as well as the one provided
2014-02-21 8:25 GMT+01:00 Tobias Burnus bur...@net-b.de:
Hi Janus,
Janus Weil wrote:
What the patch does is to defer the building of the vtabs to a later
stage. Previously this was done only for some rare cases, now we do it
basically for all vtabs. This is necessary with finalization
Hi Tobias,
A rather simple patch.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
the patch looks pretty much trivial, int the sense that you just
hard-wire the expected values for the std* units as a special case. I
wonder why the 'inquire_read' and 'inquire_write' functions
Hi,
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
the patch looks pretty much trivial, int the sense that you just
hard-wire the expected values for the std* units as a special case. I
wonder why the 'inquire_read' and 'inquire_write' functions don't
actually return the
point already started preparations for a
trans-class.c). However, this is a major effort and clearly can not be
tackled before the next stage 1.
Anyway, the patch regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-20 Janus Weil ja...@gcc.gnu.org
PR fortran
to
the corresponding procedure-pointer component in the vtab.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-19 Janus Weil ja...@gcc.gnu.org
PR fortran/60232
* expr.c (gfc_get_variable_expr): Don't add REF_ARRAY for dimensionful
functions, which
Hi,
The problem is this: When using a dimensionful function as an
EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment),
we wrongly add a REF_ARRAY, because we are tricked to believe that the
expression is dimensionful
The patch was regtested on x86_64-unknown-linux-gnu. Ok
Hi all,
the patch below has been posted a long time ago, but was never
actually committed (although it seems close to being finished).
Could it still be considered for trunk? I think it is a rather popular
feature, which would be helpful for many users ...
Cheers,
Janus
2013-03-19 22:17
think it cannot hurt to add more cases that
work for 4.9 (even if still not all possible cases work).
Please let me know what you think ...
Cheers,
Janus
2014-02-19 16:16 GMT+01:00 Janus Weil ja...@gcc.gnu.org:
Hi all,
the patch below has been posted a long time ago, but was never
actually
Hi Tobias,
This patch fixes an ICE on valid error - and a missed diagnostic.
Wording from the standard F2008, Corr2:
C729 (R742) A procedure-name shall be the name of a module or dummy
procedure, a specific intrinsic function listed in 13.6 and not marked with
a bullet ($\bullet$), a
This is OK for trunk, 4.8 and 4.7.
Thanks, Paul. Committed to trunk as r207823. Will do the backports soon.
Cheers,
Janus
On 16 February 2014 23:11, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
here is a small patch for a ICE-on-valid regression. Regtested on
x86_64-unknown-linux-gnu. Ok
Hi all,
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Cheers,
Janus
2014-02-17 Janus Weil ja...@gcc.gnu.org
PR fortran/60231
* resolve.c
2014-02-17 21:36 GMT+01:00 Tobias Burnus bur...@net-b.de:
Janus Weil wrote:
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
There is something odd with your test case - and possibly with the patch.
You state
2014-02-18 7:56 GMT+01:00 Tobias Burnus bur...@net-b.de:
Am 17.02.2014 21:51, schrieb Janus Weil:
2014-02-17 21:36 GMT+01:00 Tobias Burnus bur...@net-b.de:
Janus Weil wrote:
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args
Hi all,
here is a small patch for a ICE-on-valid regression. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
Cheers,
Janus
2014-02-16 Janus Weil ja...@gcc.gnu.org
PR fortran/55907
* resolve.c (build_default_init_expr): Don't initialize character
variable if -fno
Hi Mikael,
thanks for your suggestions and the approval of the patch.
maybe add gcc_assert to
make it clear that fini-proc_tree should be set at this point.
Or better: a comment ;-)
I'm going for the gcc_assert *plus* a comment ;)
The thusly updated patch in the attachment regtests cleanly.
2014-02-08 22:47 GMT+01:00 Steve Kargl s...@troutmask.apl.washington.edu:
On Sat, Feb 08, 2014 at 10:28:24PM +0100, Dominique Dhumieres wrote:
I can't remember. Do you have commit privilege?
No.
If not, why?
Probably because I did not asked for it explicitly.
I have only hinted a
But after all I think that the patch should not hurt. After giving it
some second thoughts, the only alternative I could see is this:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 207485)
+++
to work around some other problem in the finalization
implementation, and there is no evidence it's actually needed.
The patch regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-06 Janus Weil ja...@gcc.gnu.org
PR fortran/58470
* resolve.c (resolve_fl_derived0
Hi Mikael,
thanks for your comments ...
attached is a small patch which fixes an ICE-on-invalid regression
with finalization. In the PR, Dominique objected to the patch, but I
think it's the correct thing to do after all. The line that I'm
removing was added in a patch authored by Tobias and
the attached patch fixes an OOP-related 4.7-only regression. Pretty
much straightforward, for details see PR.
Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
Yes, thanks.
Thanks, Mikael. Committed as r207417.
Cheers,
Janus
Hi all,
the attached patch fixes an OOP-related 4.7-only regression. Pretty
much straightforward, for details see PR.
Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
Cheers,
Janus
2014-02-02 Janus Weil ja...@gcc.gnu.org
PR fortran/59941
* expr.c (replace_comp): Check for isym
Did you bootstrap test the 4.7 backport?
Yes, works like a charm here.
I also see the build problem (configuring with
--enable-languages=c,fortran --disable-bootstrap).
Looks like you committed C++ code there, in module.c:
...
3867 static void
3868 skip_list (int nest_level = 0)
Hi Paul,
This is a straightforward patch that is completely described in the
ChangeLog entry. I am surprised that this could be a 4.8 regression
since, as far as I am aware, SELECT_TYPE was not capable of handling
array selectors before... Nonetheless, it flagged it up for me :-)
well,
2014/1/11 Mikael Morin mikael.mo...@sfr.fr:
Le 09/01/2014 16:30, Janus Weil a écrit :
Hi all,
the attached patch started out as an ICE-on-invalid regression fix,
but after the ICE had been fixed recently by other means, it was
degraded to a mere error-recovery improvement. It removes some
2014/1/11 Mikael Morin mikael.mo...@sfr.fr:
Le 09/01/2014 14:33, Janus Weil a écrit :
After noticing that the bug is actually a regression (see PR 57042):
Ok to backport to 4.7 and 4.8?
Sure!
Thanks. Committed to 4.8 as r206556. Will do 4.7 soon.
Cheers,
Janus
Hi,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by the way the association of
component pointers (if
Ping!
The patch is also ok with me. Regarding the wording I'd vote for
Tobias' suggestion NULL() intrinsic not permitted in data-transfer
statement, but I'm also ok with the other variants.
Paul, please commit.
Cheers,
Janus
2013/12/1 Tobias Burnus bur...@net-b.de:
Paul Richard Thomas
After noticing that the bug is actually a regression (see PR 57042):
Ok to backport to 4.7 and 4.8?
Cheers,
Janus
2013/12/29 Janus Weil ja...@gcc.gnu.org:
Hi all,
I have just committed an obvious patch for a segfault with
-fdump-fortran-original (plus a small documentation fix):
http
on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-01-09 Janus Weil ja...@gcc.gnu.org
PR fortran/58026
* decl.c (gfc_match_data_decl): Improve error recovery.
2014-01-09 Janus Weil ja...@gcc.gnu.org
PR fortran/58026
* gfortran.dg/alloc_comp_basics_6.f90: New.
Index
Hi all,
I just committed an 'obvious' patch for a ICE-on-invalid regression on trunk:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206429
Cheers,
Janus
love to
see others join me and Mikael in the regbashing game ... ;)
Cheers,
Janus
On 3 January 2014 10:29, Janus Weil ja...@gcc.gnu.org wrote:
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil ja...@gcc.gnu.org:
Hi all,
... and the reg-bashing
is to encapsulate the code
necessary to detect finalizable components into a function, which is
then used in two different places. This makes the code less
error-prone and more readable.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-01-06 Janus Weil ja...@gcc.gnu.org
2014/1/3 Mikael Morin mikael.mo...@sfr.fr:
Le 22/12/2013 11:28, Janus Weil a écrit :
Hi all,
here is a patch for a rejects-valid problem with type-bound
procedures, which is due to the fact that the PURE attribute is being
propagated too late. (I'm not sure if this problem could show up also
Hi Mikael,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by the way the association of
component pointers
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil ja...@gcc.gnu.org:
Hi all,
... and the reg-bashing continues: Here is a small patch to fix a
bind(c) problem. It essentially prevents 'resolve_global_procedure' to
be applied to bind(c) procedures
Hi all,
I have just committed as obvious a one-line-removal patch which fixes
a wrong-code OOP regression:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206281
Since the regression also affects 4.8, I would like to backport the
patch (after waiting a few days and letting the reporter
Hi Mikael,
I have just committed as obvious a one-line-removal patch which fixes
a wrong-code OOP regression:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206281
Sometimes computer programming is more witchcraft than (computer) science.
You add some code, it fixes a bug.
Now you
Hi all,
... and the reg-bashing continues: Here is a small patch to fix a
bind(c) problem. It essentially prevents 'resolve_global_procedure' to
be applied to bind(c) procedures.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-31 Janus Weil ja...@gcc.gnu.org
Janus Weil ja...@gcc.gnu.org
PR fortran/58998
* resolve.c (resolve_symbol): Check that symbol is not only flavorless
but also untyped.
2013-12-30 Janus Weil ja...@gcc.gnu.org
PR fortran/58998
* gfortran.dg/generic_28.f90: New.
Index: gcc/fortran/resolve.c
The rather straightforward one-line patch was regtested on
x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
OK.
Thanks, Steve. Committed as r206249.
Cheers,
Janus
Hi all,
I have just committed an obvious patch for a segfault with
-fdump-fortran-original (plus a small documentation fix):
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206237
Cheers,
Janus
-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-22 Janus Weil ja...@gcc.gnu.org
PR fortran/59547
* class.c (add_proc_comp): Copy pure attribute.
2013-12-22 Janus Weil ja...@gcc.gnu.org
PR fortran/59547
* gfortran.dg/typebound_proc_32.f90: New.
Index: gcc/fortran/class.c
2013-12-18 Janus Weil ja...@gcc.gnu.org
PR fortran/59493
* gfortran.h (gfc_find_intrinsic_vtab): Removed prototype.
(gfc_find_vtab): New prototype.
* class.c (gfc_find_intrinsic_vtab): Rename to 'find_intrinsic_vtab' and
make static. Minor modifications.
(gfc_find_vtab
2013/12/18 Tobias Burnus bur...@net-b.de:
Janus Weil wrote:
here is a follow-up to my recent patch for PR59493, doing some cleanup
related to the generation of vtab symbols:
1) Since the function gfc_find_intrinsic_vtab, contrary to its name,
handles not only intrinsic but also derived types
the patch is
worth backporting.]
Cheers,
Janus
2013-12-16 Janus Weil ja...@gcc.gnu.org
PR fortran/54949
* symbol.c (check_conflict): Forbid abstract procedure pointers.
(gfc_add_abstract): Check for attribute conflicts.
2013-12-16 Janus Weil ja...@gcc.gnu.org
PR fortran
attached is a close-to-trivial patch which rejects the declaration of
'abstract procedure pointers' (which is not a valid Fortran concept),
and thereby fixes an ICE-on-invalid.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Looks good to me. Thanks for the patch!
Thanks! Committed as
Hi Tobias,
here is a rather simple fix for a problem with the pointer assignment
of an unlimited polymorphic variable. The patch regtests cleanly on
x86_64-unknown-linux-gnu.
Firstly, I would like to commit to trunk, of course. Ok?
Secondly, the bug reporter asked me (privately) for the
this is anyway prevented by the already-bumped
MOD_VERSION).
Cheers,
Janus
On 11 December 2013 22:57, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
the PR in the subject line involves a module procedure whose result
has array bounds which contain a type-bound procedure call. Since the
procedure
Hi all,
I have just committed an 'obvious' patch to fix an ICE-on-invalid
problem with class pointer assignments:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=205990
Cheers,
Janus
). So, is the
patch ok for 4.8 also?
[Btw, I plan to do some more cleanup related to the vtab generation on
trunk soon, but I tried to keep the present patch as simple as
possible, in order to keep it safe for backporting.]
Cheers,
Janus
2013-12-14 Janus Weil ja...@gcc.gnu.org
PR fortran
Hi all,
attached is a small patch which fixes accepts-invalid and
ICE-on-invalid problems on allocation with source. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-11 Janus Weil ja...@gcc.gnu.org
PR fortran/58916
* resolve.c (conformable_arrays): Treat
It looks good to me - OK for trunk.
Thanks, Paul. Committed as r205894.
Cheers,
Janus
On 11 December 2013 14:02, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
attached is a small patch which fixes accepts-invalid and
ICE-on-invalid problems on allocation with source. Regtested on
x86_64
patch). Up to now we basically did the same already, but
only including two cases (ordinary and intrinsic functions).
The patch has been regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Should I also bump the MOD_VERSION?
Cheers,
Janus
2013-12-11 Janus Weil ja...@gcc.gnu.org
PR
(asynchronous, contiguous, value, volatile). The relevant
standard reference is F08:12.3.2.
Included is also a test case and a fix for one testsuite case which
was rejected with the patch.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-10 Janus Weil ja...@gcc.gnu.org
301 - 400 of 749 matches
Mail list logo
