ivially-destructible object,
indicating that no destructor should run.
- All list objects are built by AGGR_INIT_EXPR (a constructor function call)
instead of CONSTRUCTOR (aggregate initialization). (Guys, those names are
backwards…)
Regtested against r222796 on POWER.
- Cheers,
> On 2015–05–04, at 12:00 AM, David Krauss wrote:
>
> Besides that, are some machines overloaded? If I need to use POWER, will
> there be a learning curve or brittleness as on Darwin? To avoid trial and
> error whilst wading into the process, I’m just asking for some personal
> On 2015–05–03, at 11:27 PM, Marc Glisse wrote:
>
> On Sun, 3 May 2015, David Krauss wrote:
>
>> (Yes, I know that a “compile farm” exists. It appears to be obsolete;
>> perhaps someone could vouch for it?)
>
> What gave you that impression? It doesn'
Hi all,
A couple months ago I created a patch for movable initializer lists, as
proposed in N4166. (A few additional details appeared during implementation,
which I can document if anyone asks.) Reference:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4166.pdf
As I was in the final stag
On Jun 9, 2011, at 7:54 PM, Jason Merrill wrote:
> Looks good, just need ChangeLog and testcase now.
>
> Jason
The changelog is the .clog attachment to previous.
I tried the testcase below but dejagnu seemed to hang with no compiler process
running. I really don't know how to use dg, so perhap
On Jun 6, 2011, at 1:28 PM, Jason Merrill wrote:
> On 06/02/2011 03:25 PM, David Krauss wrote:
>> Optimally the re-opened context would be the preceding operator-> function
>> itself, to create the illusion of nested calls. However, the result of
>> build_new_op m
This is my first frontend contribution. While it fixes the crash and produces
an explanatory error message, the message isn't quite right. I don't understand
the message generation system so I might need help. Or, it looks like there's
an issue with template backtraces at the moment anyway, so t
