Re: GCC 10 issues

[Camm Maguire]

Greetings!  I've committed a fix for these to the Version_2_6_13pre
branch.  Thanks for your report!  Please let me know if problems
persist.

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