[Bug tree-optimization/96051] New: alloca(0) triggers TCO for VLA

[fwd at quantentunnel dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96051

Bug ID: 96051
   Summary: alloca(0) triggers TCO for VLA
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fwd at quantentunnel dot de
  Target Milestone: ---

Created attachment 48831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48831&action=edit
TCO with alloca(0)

I have written a function which is properly translated into tail-call-optimized
code.
Then I tried to replace a call to alloca inside that function by a VLA.
Doing so I found a strange behaviour.

Using the VLA in place of alloca, but leaving the statement '(int*)alloca(0)'
in the source code, still triggers TCO. Removing the (unused) call to alloca(0)
prevents the TCO.
It is weird because I expected that alloca(0) is removed because it should have
no effect.

Summary:
1. alloca(n); // n > 0; works as expected (TCO)
2. using VLA and alloca(0); the same output (assembler) as in case 1 (TCO)
3. using VLA without alloca; works as expected (no TCO)


Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

[Bug c/78203] missing warning on return of unitialized variable

[fwd at quantentunnel dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78203

--- Comment #2 from fwd  ---
(In reply to Richard Biener from comment #1)
> There is a duplicate for this, we perform optimistic constant propagation
> which
> makes i == 1 and eliminates the conditional uninitialized use very early.

Well, with optimization -O2 the "optimistic constant propagation" is performed
and the return value is constant.
Nevertheless, I think the warning should be given, at least with '-Wpedantic'.
I wouldn't expect a constant there. If I had tests for this code, the tests
might become dependent on the optimization level.

If the constant value is exchanged by a variable of global scope, the warning
is given.
int e = 0;
int func1(const int x)
{
  int i;
  if (0 == x)
  {
i = e;
  }
  return i;
}

In my opinion, the warning should be given because of "ambiguous" code, even
though "optimistic constant propagation" removes one branch of the conditional.

[Bug c/78203] New: missing warning on return of unitialized variable

[fwd at quantentunnel dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78203

Bug ID: 78203
   Summary: missing warning on return of unitialized variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fwd at quantentunnel dot de
  Target Milestone: ---

Compiling the following code with gcc version 4.9.2 only one warning about the
use of uninitialized variables is issued. I expected a warning in func1 too.

int func1(const int x)
{
  int i;

  if (0 == x)
  {
i = 1;
  }

  return i; // no warning that 'i' may be used uninitialized in this function
}

int func2(const int x)
{
  int i;

  if (0 == x)
  {
return 1;
  }

  return i; // ok, warning is issued
}

environment (output from gcc -v):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) 


Changing func1 to static and adding
int main(void)
{
  int a;
  a = func1(1);
  return a;
}
again does not show the expected warning.


With -O2 there is no warning at all.


clang issues both warning, icc also does not.
Versions 5.4, 6.2 and 7 also do not show a warning.