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 <hain...@adacore.com> wrote: > > Hello, > > Some of the tests in gcc.dg/analyzer exercize alloca > and #include <alloca.h>. > > 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. > > This patch is a proposal in this direction for gcc.dg/analyzer. > > It introduces a common "analyzer-alloca.h" where we can > stick a common comment and a macro to redirect "alloca" > directly to "__builtin_alloca". > > The intermediate macro in a non system header unfortunately > diverts some of the warning expectations, as the allocation > point for "x = alloca(128);" is shown on the macro definition > and not at the macro invocation point. > > The patch circumvents this by calling __builtin_alloca > directly from the points where the tests perform a warning > check. > > I have verified that all the tests adjusted by the change > now pass in a run for a powerpc-vxworks configuration. > > I'll gladly perform an extra regression test on a native > system if the patch is considered ok. > > Would this be ok to commit ? > > Thanks in advance, > > With Kind Regards, > > Olivier > > 2020-10-29 Olivier Hainque <hain...@adacore.com> > > gcc/testsuite/ > * gcc.dg/analyzer/analyzer-alloca.h: New file. > * gcc.dg/analyzer/alloca-leak.c: Use it. > * gcc.dg/analyzer/data-model-1.c: Use it. > * gcc.dg/analyzer/malloc-1.c: Use it and replace call to > be tracked by a direct call to __builtin_alloca. > * gcc.dg/analyzer/malloc-paths-8.c: Likewise. > > <0001-Relax-dependency-on-alloca.h-in-gcc.dg-analyzer-tests.txt> > >
