On Jan 15, 2021, David Malcolm wrote:
> I think an issue here was that I assumed check_effective_target_alloca
> checks that "alloca" is supported, whereas I now see that I was wrong;
> it actually checks for "__builtin_alloca".
Yeah, it's a little misleading. And it only tests
On Fri, 2021-01-15 at 14:45 -0300, Alexandre Oliva wrote:
> On Jan 15, 2021, Olivier Hainque wrote:
>
> > On 14 Jan 2021, at 22:13, Alexandre Oliva
> > wrote:
> > > Would you mind if I submitted an alternate patch to do so?
> > Not at all, thanks for your feedback and for proposing
> > an
On Jan 15, 2021, Olivier Hainque wrote:
> On 14 Jan 2021, at 22:13, Alexandre Oliva wrote:
>> Would you mind if I submitted an alternate patch to do so?
> Not at all, thanks for your feedback and for proposing
> an alternative!
Here's the modified patch. Regstrapped on x86_64-linux-gnu,
Hi Alex,
> On 14 Jan 2021, at 22:13, Alexandre Oliva wrote:
>
> Hello, Olivier,
>
> On Dec 18, 2020, Olivier Hainque wrote:
>
>> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html
>> (copied below for convenience), please ?
>
> I think defining alloca as a macro in
Hello, Olivier,
On Dec 18, 2020, Olivier Hainque wrote:
> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html
> (copied below for convenience), please ?
I think defining alloca as a macro in analyzer-alloca.h might conflict
with system headers included before or after
Hello,
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html
(copied below for convenience), please ?
Thanks in advance!
With Kind Regards,
Olivier
> On 29 Oct 2020, at 21:45, Olivier Hainque wrote:
>
> Hello,
>
> Some of the tests in gcc.dg/analyzer exercize alloca
>
Hello,
Some of the tests in gcc.dg/analyzer exercize alloca
and #include .
Some systems, e.g. VxWorks, don't feature alloca.h and
the aforementioned tests fail.
Other tests in the suite have been in this situation and
the usual way around consists in resorting to __builtin_alloca
directly.
