Hi,
I have one function (F) that has been specialized for two different calling
contexts (F1 and F2) and two late SIMPLE_IPA_PASSes (A and B). Pass A
changes some MEM_REFs such that the type of MEM_REF is compatible with the
type of the first operand of the expression. Pass A changes both F1 and F
Hi!
... with the usual caveat that I know much more about OpenACC than
OpenMP, and I know (at least a bit) more about nvptx than GCN... ;-)
On 2022-03-02T15:12:30+, "Stubbs, Andrew" wrote:
> Has anyone ever considered having GCC add the "simd" clause to offload (or
> regular) loop nests au
Hi Erik,
On Tue, Mar 08 2022, Erick Ochoa via Gcc wrote:
> Hi,
>
> I have one function (F) that has been specialized for two different calling
> contexts (F1 and F2) and two late SIMPLE_IPA_PASSes (A and B). Pass A
> changes some MEM_REFs such that the type of MEM_REF is compatible with the
> type
Hi Martin!
Thanks for replying, turns out that while I was trying to reply to you I
was able to get the answer. Turns out there is indeed one tree node which
is shared across the two functions. And that is
TREE_OPERAND (MEM_REF, 1).
When I was assigning to
TREE_TYPE ( TREE_OPERAND (MEM_REF, 1)
On 2/4/22 14:40, Matthias Klose wrote:
On 1/31/22 15:06, Martin Liška wrote:
Hello.
It's about 5 months since the last project status update:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html
Now it's pretty clear that it won't be merged before GCC 12.1 gets released.
So where
> > I'm of the opinion that GCC is the one implementing OpenMP as intended
>
> I'm curious: how does one arrive at this conclusion?
Basically, any implementation for which a (significant) directive becomes a
no-op is either a) not implementing the feature as intended, or b) is
implementing it f
Hi GCC community,
I have a few questions that I am struggling to find an answer for:
a. Why does LTO generates a new symbol?
b. Why it does not replace the existing symbol, instead of creating a new one
with "lto_priv.%d" at the end of it [1]?
c. Can we assume the original symbol always will be
Erick my friend,
That's exactly why I'm such a big fan of creating things
anew each time I mess with them. 😉
Later,
Gary
From: Erick Ochoa
Sent: Tuesday, March 8, 2022 7:29 AM
To: Martin Jambor
Cc: gcc@gcc.gnu.org
Subject: Re: Question on updating function b
