Re: GCC 10 issues

[Camm Maguire]

Greetings, and thank you so much as always for your very helpful feedback!

Will take a look at this on Monday.  Alas, no gcc-10 yet on Debian
porterboxes.   

The first function is designed to supply a warning if EQUAL is not
compiled tail-recursive, such as with -O0.  This will blow out acl2 as
no stack is big enough to handle their equal calls.  The second is
intended to ensure that certain gcc-inserted stack checking code is
actually used and in the linker symbol table, needed for the axiom build
in particular.  There are likely better ways to do all of this.

Take care,

Jerry James <address@hidden> writes:

> Hi Camm,
>
> The Fedora project is currently rebuilding all packages with what will
> soon be GCC 10.  I have encountered two issues so far and thought I
> should give you a heads up.
>
> GCC has long defaulted to -fcommon, but GCC 10 flips the default to
> -fno-common.  As a result, the link step fails with complaints about
> lots of multiply-defined variables.  A quick workaround is to add
> -fcommon to the build flags.  Otherwise, the code would have to be
> altered to ensure that there is exactly one compilation unit
> containing a definition for each variable.
>
> After adding -fcommon, the build still fails like this:
>
> COMPILER>
> Error: ERROR "Caught fatal error [memory may be damaged]"
> Signalled by EQUAL-TAIL-RECURSION-CHECK.
> ERROR "Caught fatal error [memory may be damaged]"
>
> Broken at SYSTEM::DO-BREAK-LEVEL.  Type :H for Help.
>     1  Return to top level.
> COMPILER>>2148155904 heap words available
> NIL
> COMPILER>>
> NIL
> COMPILER>>make[1]: *** [makefile:98: saved_pre_gcl] Error 255
>
> Here is a disassembly of cclear_stack on an x86_64 machine:
>
> 0000000000005370 <cclear_stack>:
>     5370:       f3 0f 1e fa             endbr64
>     5374:       31 c0                   xor    %eax,%eax
>     5376:       c3                      retq
>
> GCC 10 has concluded that it can optimize cclear_stack away, as that
> simply returns 0.  GCC may feel it is justified in doing so because of
> this warning:
>
> main.c: In function 'cclear_stack':
> main.c:454:10: warning: function returns address of local variable
> [ 
> ]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-local-addr
> -Wreturn-local-addr ]8;; ]
>   454 |   return v;
>       |          ^
> In file included from /usr/include/stdlib.h:568,
>                  from main.c:27:
> main.c:452:11: note: declared here
>   452 |   void *v=alloca(size);
>       |           ^~~~~~
>
> The same thing has happened with gcl_strncpy_chk; it just returns 0.
> What are these functions supposed to do?  EQUAL-TAIL-RECURSION-CHECK
> in particular, even if cclear_stack is not optimized away, touches
> memory it isn't allowed to touch, memory belonging to a stack frame
> that has been popped.  A conforming compiler is allowed to generate
> code that segfaults (precisely what GCC 10 is doing).
>
> I should also mention this output from the configure script:
>
> checking finding default linker script... gawk: cmd. line:1: warning:
> regexp escape sequence `\=' is not a known regexp operator
> got it
>
> Perhaps all of the "\=" should be "\\="?
>
> Regards,

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah