NetBSD Problem Report #52660

From www@NetBSD.org  Thu Oct 26 18:32:33 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 9A3F67A0F3
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 26 Oct 2017 18:32:33 +0000 (UTC)
Message-Id: <20171026183231.39A577A200@mollari.NetBSD.org>
Date: Thu, 26 Oct 2017 18:32:31 +0000 (UTC)
From: macallan@netbsd.org
Reply-To: macallan@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: gcc on sparc crashes when optimizing
X-Send-Pr-Version: www-1.0

>Number:         52660
>Category:       toolchain
>Synopsis:       gcc on sparc crashes when optimizing
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 26 18:35:00 +0000 2017
>Closed-Date:    
>Last-Modified:  Thu Jun 21 17:55:01 +0000 2018
>Originator:     Michael
>Release:        at least since 7.99.*
>Organization:
TNF
>Environment:
NetBSD poteen 8.99.4 (POTEEN.MP) #0: Wed Oct 25 13:00:03 EDT 2017
 ml@paddy:/home/build/obj_sparc/sys/arch/sparc/compile/POTEEN.MP sparc
>Description:
gcc does this with any kind of optimization enabled:
gcc -O hello.c -o hello
main.c: In function 'main':
main.c:7:1: internal compiler error: Floating point exception
 }
 ^
no stack trace because unwind library not available
Please submit a full bug report,
with processed source if appropriate

I have not seen this on anything other than sparc, not even sparc64, this is a userland built from yesterday's sources. The compiler works with optimization disabled.

gcc version 5.4.0 (nb1 20160606)

The source used:
#include <stdio.h>

int main()
{
  printf("hello world!\n");
  return 0;
}

>How-To-Repeat:
try to compile anything with -On with n > 0
>Fix:

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660: gcc on sparc crashes when optimizing
Date: Fri, 27 Oct 2017 10:50:06 +0200

 I can not reproduce it:

 [/tmp] martin@krups > gcc -O hello.c -o hello                  
 [/tmp] martin@krups > ./hello 
 hello world!
 [/tmp] martin@krups > cc -v
 Using built-in specs.
 COLLECT_GCC=cc
 COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper
 Target: sparc--netbsdelf
 Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=sparc--netbsdelf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb1 20160606' --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads --with-diagnostics-color=auto-if-env --with-mpc-lib=/var/obj/mknative/sparc/usr/src/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/sparc/usr/src/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/sparc/usr/src/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src/external/lgpl3/gmp/lib/libgmp/arch/sparc --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd7.1 --host=sparc--netbsdelf --with-sysroot=/var/obj/mknative/sparc/usr/src/destdir.sparc
 Thread model: posix
 gcc version 5.4.0 (nb1 20160606) 

 Martin

From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660: gcc on sparc crashes when optimizing
Date: Fri, 27 Oct 2017 13:00:44 -0400

 I see it on SuperSPARC and HyperSPARC CPUs, going to check some
 MicroSPARCs now. I had a suspicion that it was somehow CPU dependent.

From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660: gcc on sparc crashes when optimizing
Date: Fri, 27 Oct 2017 13:29:32 -0400

 Confirmed, I do not see this on an SS5 with a TurboSPARC CPU.

From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660: gcc on sparc crashes when optimizing
Date: Fri, 27 Oct 2017 15:01:01 -0500 (CDT)

 Just to be sure, on a 110-MHz microSPARC SS5:

 cpu0 at mainbus0: MB86904 @ 110 MHz, on-chip FPU
 cpu0: 16K instruction (32 b/l), 8K data (16 b/l): cache enabled

 compilation succeeds with all levels of optimization (0-3).

 While I have a couple of SuperSPARC and HyperSPARC machines, I cannot
 at this time set them up for testing.

 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: toolchain/52660: gcc on sparc crashes when optimizing
Date: Sat, 04 Nov 2017 08:10:44 +1100

 i don't see this on my supersparc:

 russian-intervention ~> cat hello.c
 #include <stdio.h>
 int main() {
         printf("hello world\n");
         return 0;
 }
 russian-intervention ~> cc -O3 hello.c
 0.001u 0.002s 0:06.14 66.2%     0+0k 0+0io 1147pf+0w
 russian-intervention ~> ./a.out
 hello world
 russian-intervention ~> sysctl hw.model
 hw.model =3D SUNW,SPARCstation-20 (TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-=
 chip FPU)


 .mrg.

State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sun, 13 May 2018 17:14:05 +0000
State-Changed-Why:
Can someone who can reproduce this bug provide a backtrace for GCC?
You can run gcc ... -wrapper gdb,--args.
This may need netbsd-8's gcc now.


From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660 (gcc on sparc crashes when optimizing)
Date: Wed, 20 Jun 2018 18:41:39 -0400

 Here's what I get with a userland from a few days ago:

 /home/work/benchmarks/flops/work> gcc -DUNIX -O2 -wrapper gdb,--args -o flops flops.c -lm
 GNU gdb (GDB) 8.0.1
 Copyright (C) 2017 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "sparc--netbsdelf".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 <http://www.gnu.org/software/gdb/bugs/>.
 Find the GDB manual and other documentation resources online at:
 <http://www.gnu.org/software/gdb/documentation/>.
 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from /usr/libexec/cc1...(no debugging symbols found)...done.
 (gdb) run
 Starting program: /usr/libexec/cc1 -quiet -D UNIX flops.c -quiet -dumpbase flops.c -mcpu=v7 -auxbase flops -O2 -o /var/tmp//ccbu0R7N.s
 flops.c: In function 'main':
 flops.c:226:4: warning: implicit declaration of function 'dtime' [-Wimplicit-function-declaration]
     dtime(TimeArray);
     ^~~~~
 flops.c:641:4: warning: implicit declaration of function 'exit' [-Wimplicit-function-declaration]
     exit(0);
     ^~~~
 flops.c:641:4: warning: incompatible implicit declaration of built-in function 'exit'
 flops.c:641:4: note: include '<stdlib.h>' or provide a declaration of 'exit'
 flops.c: At top level:
 flops.c:719:1: warning: return type defaults to 'int' [-Wimplicit-int]
  dtime(p)
  ^~~~~

 Program received signal SIGFPE, Arithmetic exception.
 0xedd059b0 in __divdi3 () from /usr/lib/libgcc_s.so.1
 (gdb) bt
 #0  0xedd059b0 in __divdi3 () from /usr/lib/libgcc_s.so.1
 #1  0x003d2cf0 in sreal::operator/(sreal const&) const ()
 #2  0x00263e4c in estimate_bb_frequencies(bool) ()
 #3  0x00265ea0 in tree_estimate_probability() ()
 #4  0x0026698c in ?? ()
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 (gdb) disassemble __divdi3
 Dump of assembler code for function __divdi3:
 ...
    0xedd059a8 <+336>:   nop 
    0xedd059ac <+340>:   udiv  %g1, 0, %g2
 => 0xedd059b0 <+344>:   clr  %g1
    0xedd059b4 <+348>:   wr  %g1, %y
    0xedd059b8 <+352>:   nop 
 ... err, what?
 Ok, my userland was built with -mcpu=hypersparc, so udiv is allowed.
 But that's an explicit division by 0 if I read that correctly.
 How on earth did it get there?

 have fun
 Michael

State-Changed-From-To: feedback->open
State-Changed-By: maya@NetBSD.org
State-Changed-When: Wed, 20 Jun 2018 23:47:17 +0000
State-Changed-Why:
feedback provided.


From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660 (gcc on sparc crashes when optimizing)
Date: Thu, 21 Jun 2018 19:08:59 +0300

 On Wed, Jun 20, 2018 at 22:45:01 +0000, Michael wrote:

 >  Program received signal SIGFPE, Arithmetic exception.
 >  0xedd059b0 in __divdi3 () from /usr/lib/libgcc_s.so.1
 >  (gdb) bt
 >  #0  0xedd059b0 in __divdi3 () from /usr/lib/libgcc_s.so.1
 >  #1  0x003d2cf0 in sreal::operator/(sreal const&) const ()
 >  #2  0x00263e4c in estimate_bb_frequencies(bool) ()
 >  #3  0x00265ea0 in tree_estimate_probability() ()
 >  #4  0x0026698c in ?? ()
 >  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 >  (gdb) disassemble __divdi3
 >  Dump of assembler code for function __divdi3:
 >  ...
 >     0xedd059a8 <+336>:   nop 
 >     0xedd059ac <+340>:   udiv  %g1, 0, %g2
 >  => 0xedd059b0 <+344>:   clr  %g1
 >     0xedd059b4 <+348>:   wr  %g1, %y
 >     0xedd059b8 <+352>:   nop 
 >  ... err, what?
 >  Ok, my userland was built with -mcpu=hypersparc, so udiv is allowed.
 >  But that's an explicit division by 0 if I read that correctly.
 >  How on earth did it get there?

 In __udivmoddi4 (always inlined):

 	  if (d0 == 0)
 	    d0 = 1 / d0;	/* Divide intentionally by zero.  */

 -uwe

From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/52660 (gcc on sparc crashes when optimizing)
Date: Thu, 21 Jun 2018 13:51:21 -0400

 uwe@ had the right idea - this avoids the crash so far:
 Index: predict.c
 ===================================================================
 RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/predict.c,v
 retrieving revision 1.1.1.4
 diff -u -w -r1.1.1.4 predict.c
 --- predict.c   2 Feb 2018 01:59:20 -0000       1.1.1.4
 +++ predict.c   21 Jun 2018 17:47:06 -0000
 @@ -2908,7 +2908,7 @@
           to outermost to examine frequencies for back edges.  */
        estimate_loops ();

 -      freq_max = 0;
 +      freq_max = 1;
        FOR_EACH_BB_FN (bb, cfun)
         if (freq_max < BLOCK_INFO (bb)->frequency)
           freq_max = BLOCK_INFO (bb)->frequency;

 ... which is followed by:
       freq_max = real_bb_freq_max / freq_max;
 ... which divides by 0 if the FOR_EACH_BB_FN() loop turns up empty.

 Leaves the question why this didn't trigger on v7 builds, or for that
 matter, other archs.

 have fun
 Michael

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.