warn about all possible optimizations that
might be allowed by the standard, but only about those that are
actually problematic in practice and result in compiler-dependent
behavior.
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-07-11 Thomas Koenig
Hi Dominique,
thanks for the comments.
>> after the dust of the heated discussion around this PR has settled a
>> bit, here is another attempt to implement at least some basic warnings
>> about compiler-dependent behavior concerning the short-circuiting of
>> logical expressions. …
>
> IMO your p
2018-07-12 16:35 GMT+02:00 Dominique d'Humières :
>
after the dust of the heated discussion around this PR has settled a
bit, here is another attempt to implement at least some basic warnings
about compiler-dependent behavior concerning the short-circuiting of
logical expression
, and therefore could trigger a warning.
This is fixed in the current version, which still regtests cleanly
(note that alloc-comp-3.f90 currently fails due to PR 86417). The test
case is also enhanced to include the problematic case.
Ok for trunk?
Cheers,
Janus
2018-07-11 23:06 GMT+02:00 Janus Weil
2018-07-12 21:53 GMT+02:00 Thomas Koenig :
> Hi Janus,
>
>> The cleaner approach would certainly be to avoid short-circuiting of
>> impure functions altogether. If we can all agree that this is a good
>> idea,
>
>
> This is a fine example of logical short-circuiting - the condition you
> mention is
Just noticed another problematic case: Calls to generic interfaces are
not detected as implicitly pure, see enhanced test case in attachment.
Will look into this problem on the weekend ...
Cheers,
Janus
2018-07-12 21:43 GMT+02:00 Janus Weil :
> Hi all,
>
> here is a minor update of
airly large code base and found no further false
positives. Also it still regtests cleanly. Ok for trunk?
Cheers,
Janus
2018-07-15 Thomas Koenig
Janus Weil
PR fortran/85599
* dump-parse-tree.c (show_attr): Add handling of implicit_pure.
* gfortran.texi: Add chapt
Hi Thomas,
>> I tested it on a fairly large code base and found no further false
>> positives. Also it still regtests cleanly. Ok for trunk?
>
>
> while I still disagree with this on principle, I will not stand
> in the way.
IIUC you disagree in the sense that you would like gfortran to have
more
2018-07-16 21:50 GMT+02:00 Thomas Koenig :
> Am 16.07.2018 um 10:06 schrieb Janus Weil:
>>>
>>> However, one point: I think that the warning should be under a separate
>>> warning, which should then be enabled by -Wextra.
>>> -Waggressive-function-elimin
> 2018-07-16 21:50 GMT+02:00 Thomas Koenig :
>> What I would suggest is to enable -Wfunction-eliminiation with
>> -Wextra and also use that for your new warning.
>
> Thanks for the comments. Makes sense. Updated patch attached.
Huh, after actually trying -Wfunction-elimination, I'm not so sure an
Did someone actually approve this patch? Apparently it was committed
as r262744 and caused the following regression:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543
Cheers,
Janus
2018-06-27 23:07 GMT+02:00 Fritz Reese :
> The attached patch fixes PR fortran/83184, which is actually two
> di
2018-07-17 9:52 GMT+02:00 Janus Weil :
>> 2018-07-16 21:50 GMT+02:00 Thomas Koenig :
>>> What I would suggest is to enable -Wfunction-eliminiation with
>>> -Wextra and also use that for your new warning.
>>
>> Thanks for the comments. Makes sense. Updated patch
2018-07-17 17:18 GMT+02:00 Fritz Reese :
>> 2018-07-17 9:52 GMT+02:00 Janus Weil :
>> > In other words: Does it make sense to tone down
>> > -Wfunction-elimination, by only warning about impure functions?
>>
>> Here is an update of the patch which does that. R
2018-07-17 19:34 GMT+02:00 Thomas Koenig :
> Am 17.07.2018 um 19:19 schrieb Janus Weil:
>> However, the test case above seems to indicate that the
>> function-elimination optimization is not applied to impure functions
>> anyway (which is good IMHO).
>
> If you sp
2018-07-17 20:55 GMT+02:00 Fritz Reese :
> On Tue, Jul 17, 2018 at 2:36 PM Janus Weil wrote:
>>
>> 2018-07-17 19:34 GMT+02:00 Thomas Koenig :
>> > Am 17.07.2018 um 19:19 schrieb Janus Weil:
> [...]
>>
>> I do hope that things have converged by now and that
(gfc_conv_expr_op): Use short-circuiting operators only
with -ffrontend-optimize. Without that flag, make sure that both
operands are evaluated.
2018-07-20 Janus Weil
PR fortran/57160
* gfortran.dg/actual_pointer_function_1.f90: Fix invalid test case.
Index: gcc/fortran/trans-expr.c
Hi Paul,
2018-07-23 17:51 GMT+02:00 Paul Richard Thomas :
> Ping!
> On Thu, 5 Jul 2018 at 08:51, Paul Richard Thomas
> wrote:
>>
>> The comment in the patch says it all.
>>
>> Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
I don't see anything wrong with the patch, so as far as I'm co
2018-07-24 11:12 GMT+02:00 Dominique d'Humières :
> Hi Janus,
>
>> gfortran currently does short-circuiting, and after my patch for PR
>> 85599 warns about cases where this might remove an impure function
>> call (which potentially can change results).
>>
>> Now, this PR (57160) is about code which
2018-07-24 17:41 GMT+02:00 Janne Blomqvist :
> Optimization bugs that pop up at different optimization levels are hard
> enough for users to figure out
Right, and they're impossible to detect if there is no way to disable
the optimization, which is what this PR is about.
> without the frontend g
Hi Paul,
2018-07-28 9:32 GMT+02:00 Paul Richard Thomas :
> Several attempts, including mine, were made to fix this bug since it
> was posted. They were all attacking the wrong place. Instead of
> providing the free of the class _data as part of the call to
> 'add_a_type' it should be included in t
Hi Paul,
2018-07-31 14:06 GMT+02:00 Paul Richard Thomas :
> Daniel Celis Garza and Damian Rouson have developed a runtime library
> and include file for the TS 29113 and F2018 C descriptors.
> https://github.com/sourceryinstitute/ISO_Fortran_binding
>
> The ordering of types is different to the cu
Hi all,
I have just committed as obvious a one-line patch fixing a bogus warning:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201884
Cheers,
Janus
Hi Mikael,
thanks for the review!
>> + else if (selector->ts.u.derived)
>
> Hum, accessing ts.u.derived is correct only if selector->ts.type is
> BT_DERIVED or BT_CLASS, isn't it?
yes.
> Thus the condition should probably be
> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was hand
Hi,
>> Thus the condition should probably be
>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>> before? OK with that change (if it works).
>
> Good point. And yes, it works.
>
> However, on second thought, I wonder why we need to treat the case
> "selector->ts.type == BT_
>>> The attached new version is what I'm regtesting right now (with the
>>> whole BT_DERIVED branch removed, since it should not be needed). Ok if
>>> it succeeds?
>>
>> It does regtest cleanly. Ok for trunk and 4.8?
>>
> Yes.
Thanks, committed to trunk as r201919. Will backport to 4.8 soon.
Chee
st place, and I hope that no one seriously
depends on the current behavior (the size of the declared type is
probably not really useful after all).
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-08-22 Janus Weil
PR fortran/57305
* intrinsic.t
typebound ones only afterwards). See in particular comment 3 -
5 in the PR.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-08-22 Janus Weil
PR fortran/57843
* interface.c (gfc_extend_assign): Look for type-bound assignment
procedure before non
2013/8/22 Mikael Morin :
> Le 22/08/2013 17:41, Janus Weil a écrit :
>> Hi all,
>>
>> here is a wrong-code fix for type-bound assignments, which makes sure
>> that these are resolved to polymorphic procedure calls. This was not
>> always the case, because we used
Hi Mikael,
>> the SIZEOF intrinsic currently returns the size according to the
>> *declared* type for polymorphic variables. I think this doesn't really
>> make much sense and it also causes ICEs when SIZEOF is called on
>> CLASS(*) variables (which don't really have a declared type).
>> Therefore
>>> I'm slightly inclined to kindly invite the user to switch to
>>> STORAGE_SIZE+SIZE instead. Any other opinion?
>>
>> Since the SIZEOF intrinsic has been around for some time in gfortran
>> (before STORAGE_SIZE was available), I would say we should at least
>> continue to support it for backwar
Janus Weil
PR fortran/55603
* trans-decl.c (create_function_arglist, gfc_trans_deferred_vars): Pass
allocatable scalar results as argument.
* trans-expr.c (gfc_conv_variable): Extra dereferencing for allocatable
scalar results.
(gfc_conv_procedure_call): Pass allocatable
> A rather obvious patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
Looks good to me!
Thanks,
Janus
> Contrary to Janus' second
> patch review of today which didn't went past GCC's mail server.
Huh, indeed. I hadn't noticed ...
> (The same
> problem I had yesterday: Three emails didn't make it.)
Any idea what's the reason for this?
Cheers,
Janus
Hi,
> (Side remark: That's Janus' email which didn't make it past GCC's mail
> server.)
... for whatever reason. I hope this one will make it through.
Fortran 2008 permits assignment to polymorphic variables with some
constraints. The patch, which was sitting in my tree, adds diagnost
Hi,
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>> This looks good to me
>>> but I let Tobias have the final word as he
>>> expressed some concerns in the PR audit trail.
>
> Sorry for the very belated replay. I played with the patch and it looks
> okay.
thanks. Committed as r
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
This looks good to me
but I let Tobias have the final word as he
expressed some concerns in the PR audit trail.
>>
>> Sorry for the very belated replay. I played with the patch and it looks
>> okay.
>
> thanks. Committe
successfully on x86_64-unknown-linux-gnu. Ok for trunk?
Part #1, as a regression fix, should also be backported to 4.7 and 4.8. Ok?
Cheers,
Janus
2013-09-21 Janus Weil
PR fortran/58355
* decl.c (check_extended_derived_type): Prevent segfault, modify error
message.
2013-09-21 Janus
tember 2013 16:31, Janus Weil wrote:
>> Hi all,
>>
>> the straightforward patch in the attachment does two things:
>>
>> 1) It prevents a segfault, which is a regression on 4.7/4.8/trunk (by
>> simply switching the order of two statements).
>> 2) It modif
Hi Thomas,
> not much to say, the patch is pretty straightforward.
> Regression-tested. OK for trunk?
I'm not much of a libgfortran or I/O expert, but after all this looks
ok to me. Thanks for the patch!
Cheers,
Janus
> 2012-09-24 Thomas König
>
> PR fortran/52724
> * list_
ping!
2012/9/23 Janus Weil :
> Hi all,
>
> this patch fixes an ICE recently reported by Andrew Benson. It does so
> by rejecting polymorphic arguments to the C_F_POINTER intrinsic. For
> discussion and standard references, please refer to the PR and today's
> email thread
Hi all,
I have just committed as obvious a patch which re-enables a few class
array checks in the testsuite (removing some FIXMEs):
http://gcc.gnu.org/viewcvs?view=revision&revision=191867
Those tests had been disabled for the 4.6 release, when class arrays
were not supported yet, cf.
http://gcc
Hi Thomas,
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
>
> This looks all right to me (although I'm not really an expert :-)
>
> OK, and thanks for the patch!
thanks for the review. Committed as r191870.
Cheers,
Janus
Hi all,
I have just committed as obvious a one-line patch to fix an
ICE-on-invalid OOP problem:
http://gcc.gnu.org/viewcvs?view=revision&revision=192005
Cheers,
Janus
. Ok for trunk and 4.7?
Cheers,
Janus
2012-10-03 Janus Weil
PR fortran/54784
* trans-stmt.c (gfc_trans_allocate): Correctly determine the reference
to the _data component for polymorphic allocation with SOURCE.
2012-10-03 Janus Weil
PR fortran/54784
formal arguments.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2012-10-03 Janus Weil
PR fortran/45521
* interface.c (generic_correspondence): Implement additional
distinguishability criteria of F08.
(compare_actual_formal
2012/10/4 Tobias Burnus :
> Thanks for the suggestions. The attached patch changes all "."-something
> symbol names, which I found.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk and 4.7? (".saved_dovar" also occurs in 4.6; we could also
> backport that part to 4.6, but I am not su
>> Thanks for the suggestions. The attached patch changes all "."-something
>> symbol names, which I found.
>>
>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk and 4.7? (".saved_dovar" also occurs in 4.6; we could also
>> backport that part to 4.6, but I am not sure whether it is nee
Hi,
>> One more comment: Since its appearance is a bit scattered in the code,
>> how about using a small macro which prepends the "_F" prefix to a
>> given variable name?
>>
>> Btw, note that we are using a double underscore scheme in other places
>> (like __class, __vtab, __vtype, etc). I have ev
Hi all,
>>> Btw, note that we are using a double underscore scheme in other places
>>> (like __class, __vtab, __vtype, etc). I have even used an '@' in one
>>> place, namely (hidden) procedure pointer results ("ppr@"). Is there a
>>> need to unify all those cases?
>>
>>
>> It think it would be use
Hi,
>> the attached patch implements an F08 feature, which allows to
>> distinguish two specific procedures in a generic interface, based on
>> the POINTER and ALLOCATABLE attribute of their arguments.
>>
>> In addition to this, the patch fixes a bug in rejecting data actual
>> arguments passed to
> This is now:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54832
... which I have just fixed by an (obvious and regtested) patch:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192160
Thanks again for reporting this,
Janus
> 2012/10/6 Rouson, Damian :
>> The Gfortran 4.8.0 20120930 ICE
Hi all,
here is a rather straightforward patch, which does 'recursive'
checking of dummy procedures.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2012-10-06 Janus Weil
PR fortran/40453
* interface.c (check_dummy_characteristics): Recursi
Hi Mikael,
>> here is a small patch for a wrong-code regression with polymorphic
>> allocation. The problem is that we falsely detect the allocation
>> variable to be a polymorphic array (although it is a scalar). For
>> further details see the PR, in particular comment 4.
>>
>> Regtested on x86_6
>>> here is a small patch for a wrong-code regression with polymorphic
>>> allocation. The problem is that we falsely detect the allocation
>>> variable to be a polymorphic array (although it is a scalar). For
>>> further details see the PR, in particular comment 4.
>>>
>>> Regtested on x86_64-unkn
Hi Tobias,
> gfortran supports OPTIONAL since quite some time - also some more
> complicated cases involving ELEMENTAL or the new F2008 addition, but as
> testing showed, the support is still incomplete; especially with polymorphic
> arguments there were several bugs.
>
> Besides a simple absent a
ping!
2012/10/7 Janus Weil :
> Hi all,
>
> here is a rather straightforward patch, which does 'recursive'
> checking of dummy procedures.
>
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Cheers,
> Janus
>
>
> 2012-10
Janus Weil
PR fortran/54881
* match.c (select_derived_set_tmp,select_class_set_tmp): Removed and
unified into ...
(select_type_set_tmp): ... this one. Set POINTER argument according to
selector.
* trans-intrinsic.c (gfc_conv_associated): Use
Hi Thomas,
>>> here is a rather straightforward patch, which does 'recursive'
>>> checking of dummy procedures.
>>>
>>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
>
> This is OK. Thanks for the patch!
thanks, committed as r192391.
Cheers,
Janus
Hi Tobias,
>> + for (ref = e->ref; ref; ref = ref->next)
>> +{
>> + if (ref->type == REF_COMPONENT
>> + && ref->u.c.component->ts.type == BT_CLASS)
>> + class_ref = ref;
>> +
>> + if (ref->next == NULL)
>> + break;
>> +}
>>
>> ... I guess the last if statem
ping!
2012/10/11 Janus Weil :
> Hi all,
>
> here is an OOP patch for the above PR, which has two disconnected parts:
>
> 1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
> function as argument (i.e. the ICE in the bug title). This is the
> trans-intrin
trivial conceptually (in
particular I'm not 100% sure what caused this regression in the first
place; it might have been the the commit for PR40973).
Anyway, it regtests cleanly and fixes the problem as advertised. Ok for trunk?
Cheers,
Janus
2012-10-19 Janus Weil
PR fortran/542
Hi Tobias,
>> I have found a fix that is rather trivial in the sense that it's a
>> one-liner.
>
>
> I think it is the proper fix.
good :)
>> However, it may not be as trivial conceptually (in particular I'm not 100%
>> sure what caused this regression in the first place
>
>
> I think it is the
ally 'used' (called/referenced).
Then TREE_USED is set according to this attribute, which in turn
silences the warning in the middle-end.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2012-10-21 Janus Weil
PR fortran/54997
* decl.c (
Minor update to the patch: It now also sets TREE_USED for entry
masters in order to avoid bogus warnings for procedures with ENTRY
(cf. comment 6 in the PR, which like comment 0 is a 4.8 regression).
Still regtests cleanly. Ok?
Cheers,
Janus
2012/10/21 Janus Weil :
> Hi all,
>
>
Hi all,
I have just committed an obvious fix for a recent OOP regression:
http://gcc.gnu.org/viewcvs?view=revision&revision=192768
Cheers,
Janus
ping!
2012/10/22 Janus Weil :
> Minor update to the patch: It now also sets TREE_USED for entry
> masters in order to avoid bogus warnings for procedures with ENTRY
> (cf. comment 6 in the PR, which like comment 0 is a 4.8 regression).
>
> Still regtests cleanly. Ok?
>
ping**2
2012/10/16 Janus Weil :
> ping!
>
>
> 2012/10/11 Janus Weil :
>> Hi all,
>>
>> here is an OOP patch for the above PR, which has two disconnected parts:
>>
>> 1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
>> function a
> With "ASSOCIATE (A => array)", one generates internally "A" as AS_DEFERRED
> array. However, it is neither a pointer nor allocatable, unless "array" is.
>
> When passing "A" as actual argument to a non-descriptor dummy, trans-array.c
> assumed that the actual argument had no descriptor, which lea
Hi Paul,
seems we were pretty well-synchronized in posting this (in the PR it
sounded as if you wanted me to submit it ...)
In any case, the patch is ok for my taste.
Thanks!
Cheers,
Janus
2016-01-25 22:02 GMT+01:00 Paul Richard Thomas :
> Dear All,
>
> The initial report concerns initializa
Hi all,
I have just committed a rather obvious documentation fix to trunk:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=232906
I'll also backport this to the gcc-5 branch soonish ...
Cheers,
Janus
found no occurrence of it in the testsuite. Could someone check if the
flag that I'm using there is correct, please?
As a small extra the patch also mentions the -Wpedantic flag in the
gfortran documentation.
It regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-02-01
Hi,
2016-02-03 10:21 GMT+01:00 Manfred Schwarb :
>> here is a diagnostics patch, which makes sure that the responsible
>> flag is printed in several warning messages (for which this was still
>> missing).
>>
>
>if (source_size < result_size)
> -gfc_warning (0, "Intrinsic TRANSFER at %L has
Hi all,
I have slightly updated the patch now to avoid string-breaking issues
(even if it may not be a problem at all, as mentioned by Jospeh). Also
I removed the questionable part in intrinsic.c that I was not sure
about.
This version of the patch should not be too far from obvious now. Ok for t
ping!
2016-02-05 19:19 GMT+01:00 Janus Weil :
> Hi all,
>
> I have slightly updated the patch now to avoid string-breaking issues
> (even if it may not be a problem at all, as mentioned by Jospeh). Also
> I removed the questionable part in intrinsic.c that I was not sure
> about
double-ping ...
2016-02-12 0:29 GMT+01:00 Janus Weil :
> ping!
>
> 2016-02-05 19:19 GMT+01:00 Janus Weil :
>> Hi all,
>>
>> I have slightly updated the patch now to avoid string-breaking issues
>> (even if it may not be a problem at all, as mentioned
completely separate issue.]
Cheers,
Janus
2013-12-07 Janus Weil
PR fortran/59414
* resolve.c (resolve_specific_f0): Handle CLASS-valued functions.
2013-12-07 Janus Weil
PR fortran/59414
* gfortran.dg/class_result_2.f90: New.
Index: gcc/fortran/resolve.c
2013/12/7 Tobias Burnus :
> Janus Weil wrote:
>>
>> here is a small patch to fix a problem with class-array-valued
>> functions, where the rank was not determined properly. Regtestes on
>> x86_64-unknown-linux-gnu. Ok for trunk?
>>
>> [Note: This patch
Hi Tobias,
first off: I assume the first PR number in the subject line is wrong,
since I don't see how it is related to your patch. I guess you meant
58099?
> This patch is about rejects-valid and accepts-invalid and does essentially
> only:
>
> a) It ensures that sym->attr.pure/elemental gets s
(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
PR fortran
2013/12/10 Tobias Burnus :
> Hi Janus,
>
>
> Janus Weil wrote:
>>
>> here is a straightforward patch for a rather old PR, which deals with
>> argument checking. The patch at hand fixes one of the outstanding todo
>> items of the PR (see comment 17), namely ex
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
PR fortran/58916
* resolve.c (conformable_arrays): Treat scalar &#x
> It looks good to me - OK for trunk.
Thanks, Paul. Committed as r205894.
Cheers,
Janus
> On 11 December 2013 14:02, Janus Weil wrote:
>> Hi all,
>>
>> attached is a small patch which fixes accepts-invalid and
>> ICE-on-invalid problems on allocation with
this
case (see 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
P
't contain TBP
references - however this is anyway prevented by the already-bumped
MOD_VERSION).
Cheers,
Janus
> On 11 December 2013 22:57, Janus Weil wrote:
>>
>> Hi all,
>>
>> the PR in the subject line involves a module procedure whose result
>> has
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=revision&revision=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
PR fortran/59493
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 (privatel
on't think the patch is
worth backporting.]
Cheers,
Janus
2013-12-16 Janus Weil
PR fortran/54949
* symbol.c (check_conflict): Forbid abstract procedure pointers.
(gfc_add_abstract): Check for attribute conflicts.
2013-12-16 Janus Weil
PR fortran/54949
* gfortran
>> 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! C
2013-12-18 Janus Weil
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): Ne
2013/12/18 Tobias Burnus :
> 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 in
64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-22 Janus Weil
PR fortran/59547
* class.c (add_proc_comp): Copy pure attribute.
2013-12-22 Janus Weil
PR fortran/59547
* gfortran.dg/typebound_proc_32.f90: New.
Index: gcc/fortr
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=revision&revision=206237
Cheers,
Janus
2013-12-30 Janus Weil
PR fortran/58998
* resolve.c (resolve_symbol): Check that symbol is not only flavorless
but also untyped.
2013-12-30 Janus Weil
PR fortran/58998
* gfortran.dg/generic_28.f90: New.
Index: gcc/fortran
>> 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,
... 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
PR for
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=revision&revision=206281
Since the regression also affects 4.8, I would like to backport the
patch (after waiting a few days and letting the reporter tr
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=revision&revision=206281
>>
> Sometimes computer programming is more witchcraft than (computer) science.
> You add some code, it fixes a bug
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil :
> 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)
2014/1/3 Mikael Morin :
> 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 t
1 - 100 of 781 matches
Mail list logo
