On 06/16/2018 05:05 PM, Jonathan Wakely wrote:
Oops, that message got bounced from the lists and was the wrong
version of the patch anyway - this is the one I meant to attach.
On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely wrote:
Here's what I wanted to test, which removes the new
Oops, that message got bounced from the lists and was the wrong
version of the patch anyway - this is the one I meant to attach.
On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely wrote:
>
> Here's what I wanted to test, which removes the new AC_CHECK_FUNCS (replacing
> them with
On Sat, 16 Jun 2018 at 14:06, Jonathan Wakely wrote:
>
>
> On Sat, 16 Jun 2018 at 02:04, Sandra Loosemore
> wrote:
>
>> On 05/31/2018 01:19 PM, Jonathan Wakely wrote:
>> > This adds incomplete but functional support for std::filesystem and
>> > std::experimental::filesystem on MinGW. In theory
Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig :
>Hi Janus,
>
>> I happen to hold the opinion that optimizing out a call to a pure
>> function may be reasonable if it does not influence the result of an
>> expression, but optimizing out an effectively impure function (i.e.
>one
>> with
On Sat, Jun 16, 2018 at 11:14:08PM +0200, Thomas Koenig wrote:
> Hi Janus,
>
> > I happen to hold the opinion that optimizing out a call to a pure
> > function may be reasonable if it does not influence the result of an
> > expression, but optimizing out an effectively impure function (i.e. one
On Sat, Jun 16, 2018 at 10:42:16PM +0200, Janus Weil wrote:
>
> Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl
> :
> >On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
> >>
> >>
> >> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
> >:
> >> >On Sat, Jun 16, 2018 at 01:09:36PM
Hi Janus,
I happen to hold the opinion that optimizing out a call to a pure
function may be reasonable if it does not influence the result of an
expression, but optimizing out an effectively impure function (i.e. one
with side effects) is not a good idea at any time, since such an
Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl
:
>On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
>>
>>
>> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
>:
>> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>> >>
>> >>
>> >> Am 15. Juni 2018 20:38:17 MESZ
On Sat, Jun 16, 2018 at 01:00:14PM -0700, Steve Kargl wrote:
> Untested.
>
> Index: trans-expr.c
> ===
> --- trans-expr.c (revision 261674)
> +++ trans-expr.c (working copy)
> @@ -3429,6 +3429,10 @@ gfc_conv_expr_op (gfc_se
Hey everyone,
Here is the next version of the async I/O patch. It adds the
documentation, renames the testcases, uses "gthr.h", follows the style
guidelines and has been regression tested cleanly.
As for adding additional flags, I think it would be better to follow
ifort to minimize
On Sat, Jun 16, 2018 at 12:43:08PM -0700, Steve Kargl wrote:
>
> This is a different answer than what you gave in
> the PR when I asked if you were special casing
> .and. and .or. It is trivial to force the evaluation
> of operands. I already posted the diff in the PR
> where I special cased
On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
>
>
> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
> :
> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
> >>
> >>
> >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
> >:
> >> >> But at least for pure
Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
:
>On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>>
>>
>> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
>:
>> >> But at least for pure functions, this optimization looks Ok.
>> >>
>> >
>> >Why is everyone fixated on PURE
On Sat, Jun 16, 2018 at 06:56:49PM +0100, graham stott wrote:
> if i read this correctly it appears that IMPURE/PURE are not the normal
> pure attribute used by gcc but some entirely diff attribute specific to
> FORTAN so people are taking about different things
>
PURE and IMPURE are prefix-spec
if i read this correctly it appears that IMPURE/PURE are not the normal pure
attribute used by gcc but some entirely diff attribute specific to FORTANso
people are taking about different things
Original message
From: Steve Kargl
Date: 16/06/2018 17:38 (GMT+00:00)
To:
On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>
>
> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
> :
> >> But at least for pure functions, this optimization looks Ok.
> >>
> >
> >Why is everyone fixated on PURE vs IMPURE functions?
>
> Simply because it makes a difference
On Sat, 16 Jun 2018, Glen Fernandes wrote:
Use __builtin_memmove for trivially copy assignable types
2018-06-14 Glen Joseph Fernandes
* include/bits/stl_algobase.h
(__is_simple_copy_move): Defined helper.
(__copy_move_a): Used helper.
(__copy_move_backward_a):
On Sat, 16 Jun 2018 at 07:01, Glen Fernandes wrote:
> Use __builtin_memmove for trivially copy assignable types
>
I'll review the patch later, just a quick comment for now.
Every use of memcpy, memmove etc. makes it harder to make everything in
constexpr (as we're now required to do). But
On Sat, 16 Jun 2018 at 02:04, Sandra Loosemore
wrote:
> On 05/31/2018 01:19 PM, Jonathan Wakely wrote:
> > This adds incomplete but functional support for std::filesystem and
> > std::experimental::filesystem on MinGW. In theory there should be no
> > changes to the existing behaviour for POSIX
> Now committed after successful bootstrap/regtest on x86_64-linux and
> i686-linux. Is the cfgrtl.c change ok for trunk too?
> http://gcc.gnu.org/ml/gcc-patches/2018-06/msg00967.html
Don't we actually need to verify that all incoming edges are EH or none is?
--
Eric Botcazou
Am 16.06.2018 um 12:53 schrieb Janus Weil:
Yes. Back when I followed c.l.f, several experts did advise people to
never
use functions unless they were pure (or more or less effectively so, if
they didn't fulfill the standard requirements for purity). Considering
that
at least some of those same
Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
:
>> But at least for pure functions, this optimization looks Ok.
>>
>
>Why is everyone fixated on PURE vs IMPURE functions?
Simply because it makes a difference in this context!
That the Fortran standard does not acknowledge this fact is
Am 15. Juni 2018 19:49:42 MESZ schrieb Janne Blomqvist
:
>On Fri, Jun 15, 2018 at 12:22 PM, Janus Weil wrote:
>
>> Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist <
>> blomqvist.ja...@gmail.com>:
>> In Fortran, it still feels like functions as such are second-class
>> citizens. People
Am 15. Juni 2018 19:10:01 MESZ schrieb Thomas Koenig :
>Am 14.06.2018 um 10:38 schrieb Janus Weil:
>>> Also, there are AFAIU other similar weirdness with impure functions.
>>> The
>>> standard allows a compiler to optimize
>>>
>>> y = f(x) + f(x)
>>>
>>> into
>>>
>>> y = 2 * f(x)
>>>
>>> even
On Fri, Jun 15, 2018 at 11:33:10PM +0200, Eric Botcazou wrote:
> > So like this (if it passes another bootstrap/regtest together with the
> > cfgrtl.c change)? It fixes the testcase too.
> >
> > 2018-06-15 Jakub Jelinek
> >
> > PR rtl-optimization/86108
> > * bb-reorder.c
On June 15, 2018 9:08:05 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR, all traces of this warning option except these
>were removed earlier, so the warning option does nothing.
>
>The following patch removes its documentation and makes it clear it
>does
>nothing.
In this testcase, N is only used in the lambda for its constant value,
so it should not be captured. The problem was that we didn't call
mark_rvalue_use on N when instantiating the lambda, because it was
wrapped in a NOP_EXPR converting it to the type of the template
argument. Rather than try to
Use __builtin_memmove for trivially copy assignable types
2018-06-14 Glen Joseph Fernandes
* include/bits/stl_algobase.h
(__is_simple_copy_move): Defined helper.
(__copy_move_a): Used helper.
(__copy_move_backward_a): Likewise.
*
28 matches
Mail list logo
