Re: Fix for LTO compromised autoconf test in libiberty

2020-01-15 Thread Andreas Schwab
On Jan 14 2020, Jeff Law wrote: > On Tue, 2020-01-14 at 23:21 +0100, Andreas Schwab wrote: >> On Jan 14 2020, Jeff Law wrote: >> >> > diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4 >> > index bf8a907100f..381ed3b27e3 100644 >> > --- a/libiberty/aclocal.m4 >> > +++ b/libiberty/aclocal.m4

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Jeff Law
On Tue, 2020-01-14 at 23:33 +, Joseph Myers wrote: > My preference is still what I said in > ;: either > eliminate C alloca from libiberty, or don't build it with any compiler > defining __GNUC__. I'd be surprised if there are host c

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Jeff Law
On Tue, 2020-01-14 at 23:33 +, Joseph Myers wrote: > My preference is still what I said in > ;: either > eliminate C alloca from libiberty, or don't build it with any compiler > defining __GNUC__. I'd be surprised if there are host c

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Joseph Myers
My preference is still what I said in : either eliminate C alloca from libiberty, or don't build it with any compiler defining __GNUC__. I'd be surprised if there are host compilers that build libiberty, have the relevant optimizations

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Jeff Law
On Tue, 2020-01-14 at 23:09 +0100, Jakub Jelinek wrote: > On Tue, Jan 14, 2020 at 03:02:01PM -0700, Jeff Law wrote: > > Bootstrapped and regression tested on x86_64. Verified STACK_DIRECTION > > is correct via hand inspection. > > > > OK for the trunk? > > Wouldn't that fail due to warnings if c

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Jeff Law
On Tue, 2020-01-14 at 23:21 +0100, Andreas Schwab wrote: > On Jan 14 2020, Jeff Law wrote: > > > diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4 > > index bf8a907100f..381ed3b27e3 100644 > > --- a/libiberty/aclocal.m4 > > +++ b/libiberty/aclocal.m4 > > @@ -147,7 +147,7 @@ if test $ac_cv_o

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Andreas Schwab
On Jan 14 2020, Jeff Law wrote: > diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4 > index bf8a907100f..381ed3b27e3 100644 > --- a/libiberty/aclocal.m4 > +++ b/libiberty/aclocal.m4 > @@ -147,7 +147,7 @@ if test $ac_cv_os_cray = yes; then > fi > > AC_CACHE_CHECK(stack direction for C al

Re: Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Jakub Jelinek
On Tue, Jan 14, 2020 at 03:02:01PM -0700, Jeff Law wrote: > Bootstrapped and regression tested on x86_64. Verified STACK_DIRECTION > is correct via hand inspection. > > OK for the trunk? Wouldn't that fail due to warnings if compiled e.g. by gcc that doesn't support noclone attribute? Can't we e

Fix for LTO compromised autoconf test in libiberty

2020-01-14 Thread Jeff Law
GCC's ability to inline/clone self-recursive calls compromises the find_stack_direction test in libiberty's configure. The test essentially takes the address of a local in an outer and inner context then compares their addresses to determine the direction of stack growth. Inlining causes the loc