Re: SIGSEGV in test 316 on SPARCv9

[Martin Rehak]

Hi Akim,

it really seems that I am hitting kind of compiler optimization issue on 
64bit SPARC with gcc 9.3.0. I have set -O2 and now it seems it passes 
constantly. I don't think I need to bother you with this one any more.

Thanks much for your help!
-- 
m.

On December 3, 2020 10:00 pm Akim Demaille wrote:
> Hi Martin,
> 
> Thanks a lot for your reports.  Sorry for not answering sooner,
> but rest assured that your reports are on the radar.
> 
>> Le 30 nov. 2020 à 18:20, Martin Rehak <martin.rehak@oracle.com> a écrit :
>> 
>> stderr:                   
>> 1.1                                                        
>> 1.1: syntax error    
>> ./testsuite[2584]: .: line 181: 19978: Memory fault(coredump)
> 
> Wow...
> 
>> It is reproducible just on SPARCv9, it passes on SPARCv7.
> 
> Same compiler?
> 
>> I have done some debugging on it. These are the arguments of bison and 
>> g++ commands used:
>> 
>> $ bison --color=no -fno-caret -o input.cc input.y
>> $ g++ -g -m64 -O3 -mno-app-regs 
>> -ffile-prefix-map=/builds/mrehak/workspace/bison/components/bison=. \
>>  -I/builds/mrehak/workspace/bison/components/bison/bison-3.7.3/tests 
>> -D_REENTRANT -o input input.cc \
>>  /builds/mrehak/workspace/bison/components/bison/build/sparcv9/lib/libbison.a
> 
> Great job, thanks!
> 
> What version of GCC is this?
> 
> 
>> This is what gdb catches:
>> 
>> Reading symbols from ./input...
>> (gdb) r
>> Starting program: 
>> /builds/mrehak/workspace/bison/components/bison/build/sparcv9/tests/testsuite.dir/316/input
>>  
>> [Thread debugging using libthread_db enabled]
>> 1.1
>> 1.1: syntax error
>> [New Thread 1 (LWP 1)]
> 
> W00t???  I have no idea why it creates a thread here.  There's no such thing 
> in the generated parser.
> 
>> Thread 2 received signal SIGSEGV, Segmentation fault.
> 
> What on Earth is going on here???
> 
>> And here is how yydestruct looks like in input.cc:
>> 
>> static void                                                                  
>>                                           
>> yydestruct (const char *yymsg, int yytype, YYSTYPE *yyvaluep, YYLTYPE 
>> *yylocationp, yy::parser& yyparser)              
>> {                                                                            
>>                                           
>>  YYUSE (yyvaluep);                                                           
>>                                          
>>  YYUSE (yylocationp);                                                        
>>                                          
>>  YYUSE (yyparser);                                                           
>>                                          
>>  if (!yymsg)                                                                 
>>                                          
>>    yymsg = "Deleting";                                                       
>>                                          
>>  YY_SYMBOL_PRINT (yymsg, yytype, yyvaluep, yylocationp);   // <- 1464
>> 
>>  YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN                                         
>>                                          
>> YYUSE (yytype);                                                              
>>                                         
>> YY_IGNORE_MAYBE_UNINITIALIZED_END                                            
>>                                         
>> }
> 
> So if I understood correctly you have a crash in line 1464 when traces are 
> not enabled (i.e., but YYDEBUG is not set).  Which is weird, since:
> 
> # define YY_SYMBOL_PRINT(Title, Kind, Value, Location)                  \
>   do {                                                                  \
>     if (yydebug)                                                        \
>       {                                                                 \
>         YY_FPRINTF ((stderr, "%s ", Title));                            \
>         yy_symbol_print (stderr, Kind, Value, Location, yyparser);        \
>         YY_FPRINTF ((stderr, "\n"));                                    \
>       }                                                                 \
>   } while (0)
> 
> In other words, there is nothing to run here!
> 
> If you inline the macro by hand in line 1464, and compile again, what happens?
> 
> I'm very tempted to call this a compiler bug.