Greetings,
Sorry if this question has been asked before but do we extend out the
core tree type for SSA or
is there a actual dominator tree type. It seems to be we just extend or
override the core tree
type parameters but was unable to verify it by looking in the manual.
Thanks,
Nick
On 1/15/20 11:45 PM, Martin Jambor wrote:
Therefore, first and foremost, I would like to ask all (moderately)
seasoned GCC contributors to consider mentoring a student this year and
ideally also come up with a project that they would like to lead. I'm
collecting proposal on our wiki page
@Davi
On Mon, 2020-01-27 at 10:18 -0500, Nicholas Krause wrote:
> Greetings,
>
> Sorry if this question has been asked before but do we extend out the
> core tree type for SSA or
> is there a actual dominator tree type. It seems to be we just extend or
> override the core tree
> type parameters but wa
On 1/27/20 10:46 AM, Jeff Law wrote:
On Mon, 2020-01-27 at 10:18 -0500, Nicholas Krause wrote:
Greetings,
Sorry if this question has been asked before but do we extend out the
core tree type for SSA or
is there a actual dominator tree type. It seems to be we just extend or
override the core
On Sat, 2020-01-25 at 09:31 +, Richard Sandiford wrote:
> TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an
> associated source-level decl and neither of which are in an anchor block:
>
> (Q1) can a valid byte access at X+C alias a valid byte access at Y+C?
>
> (Q2) can
Hello,
I have a problem with a transformation I'm working on and I would appreciate
some help. The transformation I am working on removes fields in structs early
during link-time. For the purposes of development and this example, my
transformation deletes the field identified as "delete_me" from t
Joseph Myers wrote:
> On Tue, 21 Jan 2020, Ulrich Weigand wrote:
>
> > It looks like there's multiple cases here. For the two flags
> > -fassociative-math and -freciprocal-math, it seems to have happened just as
> > you describe: they were created (split out of -funsafe-math-optimizations)
> > in
On Mon, 27 Jan 2020, Ulrich Weigand wrote:
> I see. I guess that makes me wonder what -fno-fast-math *ever* does
> (except canceling a -ffast-math earlier on the command line). Looking
> at the current code, -fno-fast-math (just like -ffast-math) only ever
> sets flags whose default is not overr
On 1/24/20, Richard Earnshaw (lists) wrote:
> On 24/01/2020 10:27, Jonathan Wakely wrote:
>> On Fri, 24 Jan 2020 at 03:39, Nicholas Krause
>> wrote:
>>> Sorry for the second message Allan but make -j does not scale well
>>> beyond 4 or
>>> 8 threads and that's considering a 4 core or 8 machine. T
