Hi,
On Tue, 3 Feb 2015, Jakub Jelinek wrote:
> It can be lowered during gimplification to some internal call.
That's what my patch does :)
> What arguments and return values will it have can be decided based on
> what will be most suitable for the lowering.
And that as well, just the concrete
On Tue, Feb 03, 2015 at 02:36:53PM +0100, Michael Matz wrote:
> Hi,
>
> On Tue, 3 Feb 2015, Tom de Vries wrote:
>
> > Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so
> > I've disabled that by default for now.
> >
> > I've done a non-bootstrap and bootstrap build using all
Hi,
On Tue, 3 Feb 2015, Tom de Vries wrote:
> Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so
> I've disabled that by default for now.
>
> I've done a non-bootstrap and bootstrap build using all languages.
>
> The non-bootstrap test shows (at least) two classes of real fa
On 02-02-15 16:47, Michael Matz wrote:
Hi,
On Mon, 2 Feb 2015, Tom de Vries wrote:
I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
series as gcc.target/x86_64/abi/callabi/vaarg-4.c.
The problem is in this code:
...
e = va_arg (argp, char *);
e = va_arg (argp
Hi,
On Mon, 2 Feb 2015, Tom de Vries wrote:
> I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
> series as gcc.target/x86_64/abi/callabi/vaarg-4.c.
>
> The problem is in this code:
> ...
> e = va_arg (argp, char *);
> e = va_arg (argp, char *);
> ...
>
> which is
On 30-01-15 14:11, Michael Matz wrote:
Hi,
On Fri, 30 Jan 2015, Tom de Vries wrote:
Maybe you want to pick up the work?
In principle yes, depending on the amount of work (at this point I have no
idea what remains to be done and how long that would take me).
Michael, are your patches posted
Hi,
On Fri, 30 Jan 2015, Tom de Vries wrote:
> > Maybe you want to pick up the work?
>
> In principle yes, depending on the amount of work (at this point I have no
> idea what remains to be done and how long that would take me).
>
> Michael, are your patches posted somewhere?
I don't think I e
On 30-01-15 09:41, Richard Biener wrote:
I don't like adding more hacks to aid the stdarg pass.
It's not required
for GCC 5 anyway and for GCC 6 we should push the lowering change.
Richard,
I agree that that's the best solution (the posted patch is just a solution that
helps me along for now)
On Thu, Jan 29, 2015 at 11:20 PM, Tom de Vries wrote:
> On 29-01-15 18:25, Jakub Jelinek wrote:
>>
>> The stdarg pass can't grok too heavy optimizations, so if at all possible,
>> don't schedule such passes early, and if you for some reason do, avoid
>> optimizing in there the va_list related acce
On 29-01-15 18:25, Jakub Jelinek wrote:
The stdarg pass can't grok too heavy optimizations, so if at all possible,
don't schedule such passes early, and if you for some reason do, avoid
optimizing in there the va_list related accesses.
This patch work for the example.
In pass_lim1, I get:
...
On Thu, Jan 29, 2015 at 07:44:29PM +0100, Richard Biener wrote:
> On January 29, 2015 6:25:35 PM CET, Jakub Jelinek wrote:
> >On Thu, Jan 29, 2015 at 06:19:45PM +0100, Tom de Vries wrote:
> >> consider attached patch, which adds pass_lim after fre1 (a
> >simplification of
> >> my oacc kernels patc
On January 29, 2015 6:25:35 PM CET, Jakub Jelinek wrote:
>On Thu, Jan 29, 2015 at 06:19:45PM +0100, Tom de Vries wrote:
>> consider attached patch, which adds pass_lim after fre1 (a
>simplification of
>> my oacc kernels patch series).
>>
>> The included testcase lim-before-stdarg.c fails.
>>
>>
On Thu, Jan 29, 2015 at 06:19:45PM +0100, Tom de Vries wrote:
> consider attached patch, which adds pass_lim after fre1 (a simplification of
> my oacc kernels patch series).
>
> The included testcase lim-before-stdarg.c fails.
>
> The first sign of trouble is in lim-before-stdarg.c.088t.stdarg (a
13 matches
Mail list logo
