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 this will be the
>> last incarnation of
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 this will be the
> last incarnation of the patch. If there is no more feedback in the
>
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 specify
Am 17.07.2018 um 19:19 schrieb Janus Weil:
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.
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. Regtesting now ...
>
> Would not this
On Tue, Jul 17, 2018 at 10:32 AM Janus Weil wrote:
>
> 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
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 attached.
>
>
> Huh, after actually
> 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
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-elimination, could be reused for this,
>>> or
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-elimination, could be reused for this,
or something else
I don't actually see such a flag in the manual.
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
Hi Janus,
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.
However, one point: I think that the warning should be under a separate
warning,
Hi all,
here is another update of the patch. It cures the previously-mentioned
problems with generic interfaces, adds some documentation (as
suggested by Dominique) and slightly enhances the error message
(mentioning the impurity of the function we're warning about).
I tested it on a fairly
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 the patch,
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
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 false, therefore the rest need not be evaluated :-)
Hi all,
here is a minor update of the patch, which cures some problems with
implicitly pure functions in the previous version.
Most implicitly pure functions were actually detected correctly, but
implicitly pure functions that called other implicitly pure functions
were not detected properly,
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
> Le 12 juil. 2018 à 16:12, Janus Weil a écrit :
>
> 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
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
Hi Janus,
> 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 patch is missing the only point I
Hi all,
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.
As a reminder (and recap of the previous discussion), the
22 matches
Mail list logo
