On 11.08.21 00:46, Sandra Loosemore wrote:
On 8/10/21 2:29 AM, Tobias Burnus wrote:
[snip]
To conclude: I like the code changes (LGTM); the
'__float128' -> 'TFmode' comment change also matches the code.
However, I think both longer comments need to be updated.
OK. I used your wording verba
> build3 currently does no special processing for the FIELD_DECL operand,
> it just sets TREE_THIS_VOLATILE from operand zero for tcc_references.
>
> The C and C++ frontends have repeated patterns like
>
> ref = build3 (COMPONENT_REF, subtype, datum, subdatum,
>
On Wed, 11 Aug 2021, Richard Biener wrote:
> On Tue, 10 Aug 2021, Eric Botcazou wrote:
>
> > > The question is whether we instead want to amend build3 to
> > > set TREE_THIS_VOLATILE automatically when the FIELD_DECL has
> > > it set. At least for the Fortran FE cases the gimplifier
> > > fails
> So I'm leaning towards leaving build3 alone and fixing up frontends
> as issues pop up.
FWIW fine with me.
--
Eric Botcazou
Hi!
On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
> OK. I used your wording verbatim for the first one. For the second
> one, I'm still pretty confused as I think it is at least theoretically
> possible on PowerPC to have a target with 64-bit long double (AIX?) that
Some
Hi Folks
> On 11 Aug 2021, at 11:55, Segher Boessenkool
> wrote:
> On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
>> OK. I used your wording verbatim for the first one. For the second
>> one, I'm still pretty confused as I think it is at least theoretically
>> possible on
Hi!
On Wed, Aug 11, 2021 at 12:29:06PM +0100, Iain Sandoe wrote:
> > On 11 Aug 2021, at 11:55, Segher Boessenkool
> > wrote:
> > On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
> >> OK. I used your wording verbatim for the first one. For the second
> >> one, I'm still pretty
On Wed, 11 Aug 2021, Eric Botcazou wrote:
> > So I'm leaning towards leaving build3 alone and fixing up frontends
> > as issues pop up.
>
> FWIW fine with me.
OK, so I pushed the original change (reposted below).
Bootstrapped / tested on x86_64-unknown-linux-gnu.
Richard.
>From e5a23d54d189f3
On 8/11/21 2:05 AM, Tobias Burnus wrote:
On 11.08.21 00:46, Sandra Loosemore wrote:
On 8/10/21 2:29 AM, Tobias Burnus wrote:
[snip]
To conclude: I like the code changes (LGTM); the
'__float128' -> 'TFmode' comment change also matches the code.
However, I think both longer comments need to be
Dear all,
the checks for the STAT= and ERRMSG= arguments to the coarray SYNC statements
did not properly handle several cases, such as named constants (parameters).
While fixing this, I adjusted the code similarly to what was recently done
for (DE)ALLOCATE. We now also accept function references
*Ping*
> Gesendet: Dienstag, 03. August 2021 um 23:17 Uhr
> Von: "Harald Anlauf"
> An: "Harald Anlauf"
> Cc: "Tobias Burnus" , "Bernhard Reutner-Fischer"
> , "Harald Anlauf via Gcc-patches"
> , "fortran"
> Betreff: Re: [PATCH] PR fortran/100950 - ICE in
> output_constructor_regular_field, at
*Ping*
> Gesendet: Mittwoch, 04. August 2021 um 23:09 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH, part2] PR fortran/98411 [10/11/12 Regression] Pointless:
> Array larger than ‘-fmax-stack-var-size=’, ...
>
> Dear all,
>
> here's the second part that should fix
On Wed, Aug 11, 2021 at 05:55:39AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
> > OK. I used your wording verbatim for the first one. For the second
> > one, I'm still pretty confused as I think it is at least theoretically
> >
I had a file-path to sources with the substring "new" in it,
and (only) this test regressed compared to results from
another build without "new" in the name.
The test does
! { dg-final { scan-tree-dump-times "new" 4 "original" } }
i.e. the contents of the tree-dump-file .original needs to match
t
14 matches
Mail list logo
