[Bug target/66563] New: [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[Bug target/66563] New: [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

            Bug ID: 66563
           Summary: [4.9 Regression] ICE (segmentation fault) on
                    sh4-linux-gnu
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35792&action=edit
preprocessed source

seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898):

sh4-linux-gnu-gcc -c -DHAVE_CONFIG_H -g -O1  -I.
-I../../src/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  -fpic ../../src/libiberty/floatformat.c -o
pic/floatformat.o
../../src/libiberty/floatformat.c: In function 'floatformat_to_double':
../../src/libiberty/floatformat.c:529:2: internal compiler error: Segmentation
fault
  dto = ldexp (1.0, exponent);
  ^
Please submit a full bug report,
with preprocessed source if appropriate.

Not checked with GCC 5.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #1 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Hi Matthias!

Thanks for the bug report but I think this might actually a problem with the
host compiler or its libraries. I have seen segfaults in multiple packages now
[1-3] and so I am very sure this is not an issue with gcc but with the
gcc-4.9_4.9.2-20+sh4 package that I built.

The problem occurred after I built gcc-4.9_4.9.2-20+sh4 manually to re-add
libstdc++6 back which was missing yet and I am suspecting that I messed
something up while doing that. I have even seen segfaults during packages
postinst scripts, for example, so I suspect an issue with the libstdc++6
library being broken.

The buildd tirpitz is currently [4] building gcc-4.9_4.9.2-21 which will be
your vanilla gcc-4.9 package and I hope that this will fix the issue.

Cheers,
Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gnutls28&arch=sh4&ver=3.3.15-7&stamp=1434506763
> [2] http://buildd.debian-ports.org/status/fetch.php?pkg=wmfire&arch=sh4&ver=1.2.4-1&stamp=1434405734
> [3] http://buildd.debian-ports.org/status/fetch.php?pkg=cdebconf&arch=sh4&ver=0.194&stamp=1434394400
> [4] http://buildd.debian-ports.org/status/package.php?p=gcc-4.9&suite=sid

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.3

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #2 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Just as a heads up: Once the buildd has finished building the latest
gcc-4.9_4.9.2-21 package, I will update all buildds and reschedule all affected
packages to see if that fixes the problem.

If not, we might actually see really a regression here which could certainly be
attributed to any of the recent changes listed here [1].

But I really hope it's just this single package built which is broken :).

Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979#c8

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #3 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
So, it seems Matthias is right, there is definitely a regression in gcc-4.9 in
the code generation. Packages that were recently build with gcc-4.9_4.9.2-20 or
newer tend to segfault.

I noticed this with systemd, for example on tirpitz:

systemd_220-2 works fine (compiled with gcc-4.9_4.9.2-10):

root@tirpitz:~/systemd-test> journalctl --version
systemd 220
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN
root@tirpitz:~/systemd-test>

systemd_220-6 segfaults (compiled with gcc-4.9_4.9.2-20):

root@tirpitz:~/systemd-test> ./systemd/bin/journalctl --version
systemd 220
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN
Segmentation fault
root@tirpitz:~/systemd-test>

Attaching the strace for this segfault if that could be in any way helpful.

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #4 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35807&action=edit
strace of journalctl_220-6-sh4 during segfault

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #5 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #0)
> Created attachment 35792 [details]
> preprocessed source
> 
> seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898):

I can't reproduce the problem with all my 4.9 compilers:

cross 4.9 (SVN rev. 224552) compiler
native 4.9 (SVN rev. 224552) compiler built with the above cross 4.9 compiler
native 4.9 (SVN rev. 222859) compiler built with bootstrap

against the test case in my environment.  The last target specific
change of 4.9 SVN tree was

r221686 | olegendo | 2015-03-26 16:46:51 +0900 (Thu, 26 Mar 2015) | 6 lines

So if the test case fails with the vanilla gcc 4.9 rev 223898 built
on Debian, the issue isn't caused by the target specific changes or it
depends on the environment weirdly.  I'll try a new bootstrap on 4.9
SVN rev. 224552 and see it's ok with the test case.  It'll take ~2
weeks, though.  Perhaps it's better to run your cc1 under gdb or
strace and see where/why that segfault happens.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #6 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #5)
> (In reply to Matthias Klose from comment #0)
> > Created attachment 35792 [details]
> > preprocessed source
> > 
> > seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898):
> 
> I can't reproduce the problem with all my 4.9 compilers:
> 
> cross 4.9 (SVN rev. 224552) compiler
> native 4.9 (SVN rev. 224552) compiler built with the above cross 4.9 compiler
> native 4.9 (SVN rev. 222859) compiler built with bootstrap

Hmm, can you maybe try to compile "wmfire"? It's a comparably small package, so
it shouldn't take too long to build even natively.

Log a failed build can be found here [1].

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=wmfire&arch=sh4&ver=1.2.4-1&stamp=1434405734

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3851 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #7 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Alright, I did some further tests. I downloaded the source package for "wmfire"
with "apt-get source wmfire" and installed its build dependencies with "apt-get
build-dep wmfire".

Then I just tried to compile "wmfire.c":

glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o
wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0)
wmfire.c: In function ‘draw_fire’:
wmfire.c:559:6: internal compiler error: Segmentation fault
      psi = i * 3.14 / 20.0;
      ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.

Preprocessed source stored into /tmp/ccSeTi7v.out file, please attach this to
your bugreport.
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$

I did a second run with strace:

glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ strace -o
gcc-segfault-wmfire gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0)
$(pkg-config --cflags libgtop-2.0)
wmfire.c: In function ‘draw_fire’:
wmfire.c:559:6: internal compiler error: Segmentation fault
      psi = i * 3.14 / 20.0;
      ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cchKm9Ad.out file, please attach this to
your bugreport.
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$

Attaching the strace output as well as the preprocessed source.

Adrian
>From gcc-bugs-return-489396-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 19 13:27:37 2015
Return-Path: <gcc-bugs-return-489396-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1583 invoked by alias); 19 Jun 2015 13:27:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1471 invoked by uid 48); 19 Jun 2015 13:27:33 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
Date: Fri, 19 Jun 2015 13:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-66563-4-eJENqVvBzR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01728.txt.bz2
Content-length: 294

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf563

--- Comment #8 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5808&actioníit
strace of gcc segfaulting when compiling wmfire.c on sh4

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #9 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35809&action=edit
Pre-processed source for wmfire.c test compile (run with strace)

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35810&action=edit
Pre-processed source for wmfire.c test compile (run without strace)

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #11 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35811&action=edit
Same compiler invocation, but this time with strace -f

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #12 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
All my 4.9 compilers don't fail for given pre-processed source.
Could you show us segfaultlog with running the following commands?

gcc -E wmfire.c -o wmfire.i
strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 9721 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #13 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Alright:

glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc -E wmfire.c -o
wmfire.i $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0)
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ strace -i -f -o
segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i
 __bswap_32 __bswap_64 g_bit_nth_lsf g_bit_nth_msf g_bit_storage
g_mutex_locker_new g_mutex_locker_free g_steal_pointer g_string_append_c_inline
g_trash_stack_push g_trash_stack_pop g_trash_stack_peek g_trash_stack_height
g_autoptr_cleanup_generic_gfree glib_autoptr_cleanup_GAsyncQueue
glib_autoptr_cleanup_GBookmarkFile glib_autoptr_cleanup_GBytes
glib_autoptr_cleanup_GChecksum glib_autoptr_cleanup_GDateTime
glib_autoptr_cleanup_GDir glib_autoptr_cleanup_GError
glib_autoptr_cleanup_GHashTable glib_autoptr_cleanup_GHmac
glib_autoptr_cleanup_GIOChannel glib_autoptr_cleanup_GKeyFile
glib_autoptr_cleanup_GList glib_autoptr_cleanup_GArray
glib_autoptr_cleanup_GPtrArray glib_autoptr_cleanup_GByteArray
glib_autoptr_cleanup_GMainContext glib_autoptr_cleanup_GMainLoop
glib_autoptr_cleanup_GSource glib_autoptr_cleanup_GMappedFile
glib_autoptr_cleanup_GMarkupParseContext glib_autoptr_cleanup_GNode
glib_autoptr_cleanup_GOptionContext glib_autoptr_cleanup_GOptionGroup
glib_autoptr_cleanup_GPatternSpec glib_autoptr_cleanup_GQueue
glib_auto_cleanup_GQueue glib_autoptr_cleanup_GRand glib_autoptr_cleanup_GRegex
glib_autoptr_cleanup_GMatchInfo glib_autoptr_cleanup_GScanner
glib_autoptr_cleanup_GSequence glib_autoptr_cleanup_GSList
glib_autoptr_cleanup_GStringChunk glib_autoptr_cleanup_GThread
glib_auto_cleanup_GMutex glib_autoptr_cleanup_GMutexLocker
glib_auto_cleanup_GCond glib_autoptr_cleanup_GTimer
glib_autoptr_cleanup_GTimeZone glib_autoptr_cleanup_GTree
glib_autoptr_cleanup_GVariant glib_autoptr_cleanup_GVariantBuilder
glib_auto_cleanup_GVariantBuilder glib_autoptr_cleanup_GVariantIter
glib_autoptr_cleanup_GVariantDict glib_auto_cleanup_GVariantDict
glib_autoptr_cleanup_GVariantType g_set_object glib_auto_cleanup_GStrv
glib_autoptr_cleanup_GObject glib_autoptr_cleanup_GInitiallyUnowned
glib_auto_cleanup_GValue glib_autoptr_cleanup_GListModel G_LIST_MODEL
G_IS_LIST_MODEL G_LIST_MODEL_GET_IFACE glib_autoptr_cleanup_GListStore
G_LIST_STORE G_IS_LIST_STORE glib_autoptr_cleanup_GAction
glib_autoptr_cleanup_GActionMap glib_autoptr_cleanup_GAppInfo
glib_autoptr_cleanup_GAppLaunchContext glib_autoptr_cleanup_GAppInfoMonitor
glib_autoptr_cleanup_GApplicationCommandLine glib_autoptr_cleanup_GApplication
glib_autoptr_cleanup_GAsyncInitable glib_autoptr_cleanup_GAsyncResult
glib_autoptr_cleanup_GBufferedInputStream
glib_autoptr_cleanup_GBufferedOutputStream glib_autoptr_cleanup_GBytesIcon
glib_autoptr_cleanup_GCancellable glib_autoptr_cleanup_GCharsetConverter
glib_autoptr_cleanup_GConverter glib_autoptr_cleanup_GConverterInputStream
glib_autoptr_cleanup_GConverterOutputStream glib_autoptr_cleanup_GCredentials
glib_autoptr_cleanup_GDataInputStream glib_autoptr_cleanup_GDataOutputStream
glib_autoptr_cleanup_GDBusActionGroup glib_autoptr_cleanup_GDBusAuthObserver
glib_autoptr_cleanup_GDBusConnection glib_autoptr_cleanup_GDBusInterface
glib_autoptr_cleanup_GDBusInterfaceSkeleton glib_autoptr_cleanup_GDBusMenuModel
glib_autoptr_cleanup_GDBusMessage glib_autoptr_cleanup_GDBusMethodInvocation
glib_autoptr_cleanup_GDBusNodeInfo glib_autoptr_cleanup_GDBusObject
glib_autoptr_cleanup_GDBusObjectManagerClient
glib_autoptr_cleanup_GDBusObjectManager
glib_autoptr_cleanup_GDBusObjectManagerServer
glib_autoptr_cleanup_GDBusObjectProxy glib_autoptr_cleanup_GDBusObjectSkeleton
glib_autoptr_cleanup_GDBusProxy glib_autoptr_cleanup_GDBusServer
glib_autoptr_cleanup_GDrive glib_autoptr_cleanup_GEmblemedIcon
glib_autoptr_cleanup_GEmblem glib_autoptr_cleanup_GFileEnumerator
glib_autoptr_cleanup_GFile glib_autoptr_cleanup_GFileIcon
glib_autoptr_cleanup_GFileInfo glib_autoptr_cleanup_GFileInputStream
glib_autoptr_cleanup_GFileIOStream glib_autoptr_cleanup_GFileMonitor
glib_autoptr_cleanup_GFilenameCompleter glib_autoptr_cleanup_GFileOutputStream
glib_autoptr_cleanup_GFilterInputStream
glib_autoptr_cleanup_GFilterOutputStream glib_autoptr_cleanup_GIcon
glib_autoptr_cleanup_GInetAddress glib_autoptr_cleanup_GInetAddressMask
glib_autoptr_cleanup_GInetSocketAddress glib_autoptr_cleanup_GInitable
glib_autoptr_cleanup_GInputStream glib_autoptr_cleanup_GIOModule
glib_autoptr_cleanup_GIOStream glib_autoptr_cleanup_GLoadableIcon
glib_autoptr_cleanup_GMemoryInputStream
glib_autoptr_cleanup_GMemoryOutputStream glib_autoptr_cleanup_GMenu
glib_autoptr_cleanup_GMenuItem glib_autoptr_cleanup_GMenuModel
glib_autoptr_cleanup_GMenuAttributeIter glib_autoptr_cleanup_GMenuLinkIter
glib_autoptr_cleanup_GMount glib_autoptr_cleanup_GMountOperation
glib_autoptr_cleanup_GNativeVolumeMonitor glib_autoptr_cleanup_GNetworkAddress
glib_autoptr_cleanup_GNetworkMonitor glib_autoptr_cleanup_GNetworkService
glib_autoptr_cleanup_GNotification glib_autoptr_cleanup_GOutputStream
glib_autoptr_cleanup_GPermission glib_autoptr_cleanup_GPollableInputStream
glib_autoptr_cleanup_GPollableOutputStream glib_autoptr_cleanup_GPropertyAction
glib_autoptr_cleanup_GProxyAddressEnumerator glib_autoptr_cleanup_GProxyAddress
glib_autoptr_cleanup_GProxy glib_autoptr_cleanup_GProxyResolver
glib_autoptr_cleanup_GRemoteActionGroup glib_autoptr_cleanup_GResolver
glib_autoptr_cleanup_GSeekable glib_autoptr_cleanup_GSettingsBackend
glib_autoptr_cleanup_GSettingsSchema glib_autoptr_cleanup_GSettings
glib_autoptr_cleanup_GSimpleActionGroup glib_autoptr_cleanup_GSimpleAction
glib_autoptr_cleanup_GSimpleAsyncResult glib_autoptr_cleanup_GSimplePermission
glib_autoptr_cleanup_GSimpleProxyResolver
glib_autoptr_cleanup_GSocketAddressEnumerator
glib_autoptr_cleanup_GSocketAddress glib_autoptr_cleanup_GSocketClient
glib_autoptr_cleanup_GSocketConnectable glib_autoptr_cleanup_GSocketConnection
glib_autoptr_cleanup_GSocketControlMessage glib_autoptr_cleanup_GSocket
glib_autoptr_cleanup_GSocketListener glib_autoptr_cleanup_GSocketService
glib_autoptr_cleanup_GSubprocess glib_autoptr_cleanup_GSubprocessLauncher
glib_autoptr_cleanup_GTask glib_autoptr_cleanup_GTcpConnection
glib_autoptr_cleanup_GTcpWrapperConnection glib_autoptr_cleanup_GTestDBus
glib_autoptr_cleanup_GThemedIcon glib_autoptr_cleanup_GThreadedSocketService
glib_autoptr_cleanup_GTlsBackend glib_autoptr_cleanup_GTlsCertificate
glib_autoptr_cleanup_GTlsClientConnection glib_autoptr_cleanup_GTlsConnection
glib_autoptr_cleanup_GTlsDatabase glib_autoptr_cleanup_GTlsFileDatabase
glib_autoptr_cleanup_GTlsInteraction glib_autoptr_cleanup_GTlsPassword
glib_autoptr_cleanup_GTlsServerConnection glib_autoptr_cleanup_GVfs
glib_autoptr_cleanup_GVolume glib_autoptr_cleanup_GVolumeMonitor
glib_autoptr_cleanup_GZlibCompressor glib_autoptr_cleanup_GZlibDecompressor
main update_cpu update_mem update_net update_file change_cpu change_flame
setup_cursor burn_spot draw_fire
wmfire.c: In function ‘draw_fire’:
wmfire.c:559:6: internal compiler error: Segmentation fault
      psi = i * 3.14 / 20.0;
      ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$

Attaching the strace log as well.
>From gcc-bugs-return-489404-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 19 14:29:07 2015
Return-Path: <gcc-bugs-return-489404-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13014 invoked by alias); 19 Jun 2015 14:29:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12935 invoked by uid 48); 19 Jun 2015 14:29:02 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
Date: Fri, 19 Jun 2015 14:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-66563-4-39e3LE1e3u@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01736.txt.bz2
Content-length: 318

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf563

--- Comment #14 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5812&actioníit
Log for strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #15 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #14)
> Created attachment 35812 [details]
> Log for strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1
> wmfire.i

30836 [00763a40] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x454} ---

Could you see the code near the address 0x00763a40 in
/usr/lib/gcc/sh4-linux-gnu/4.9/cc1 binary with objdump or gdb?

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #16 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I included some more context:

glaubitz@tirpitz:~/debian/segfault-test$ objdump -d 
/usr/lib/gcc/sh4-linux-gnu/4.9/cc1 |grep -C20 763a40
  763a18:       10 38           cmp/eq  r1,r8
  763a1a:       39 8d           bt.s    763a90
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x90>
  763a1c:       00 e4           mov     #0,r4
  763a1e:       7d 90           mov.w   763b1c
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x11c>,r0
      ! a8
  763a20:       52 2f           mov.l   r5,@r15
  763a22:       10 e6           mov     #16,r6
  763a24:       7b 95           mov.w   763b1e
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x11e>,r5
      ! ff7c
  763a26:       fc 30           add     r15,r0
  763a28:       71 1f           mov.l   r7,@(4,r15)
  763a2a:       0c 35           add     r0,r5
  763a2c:       3e d0           mov.l   763b28
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x128>,r0
      ! 4cee84 <mpfr_get_str@plt>
  763a2e:       0b 40           jsr     @r0
  763a30:       00 e7           mov     #0,r7
  763a32:       08 20           tst     r0,r0
  763a34:       6d 8d           bt.s    763b12
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x112>
  763a36:       03 68           mov     r0,r8
  763a38:       03 c8           tst     #3,r0
  763a3a:       05 8f           bf.s    763a48
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x48>
  763a3c:       03 61           mov     r0,r1
  763a3e:       00 e3           mov     #0,r3
  763a40:       16 62           mov.l   @r1+,r2
  763a42:       3c 22           cmp/str r3,r2
  763a44:       fc 8b           bf      763a40
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x40>
  763a46:       fc 71           add     #-4,r1
  763a48:       14 62           mov.b   @r1+,r2
  763a4a:       28 22           tst     r2,r2
  763a4c:       fc 8f           bf.s    763a48
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x48>
  763a4e:       83 66           mov     r8,r6
  763a50:       01 76           add     #1,r6
  763a52:       68 31           sub     r6,r1
  763a54:       73 e2           mov     #115,r2
  763a56:       26 31           cmp/hi  r2,r1
  763a58:       5b 8d           bt.s    763b12
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x112>
  763a5a:       f9 57           mov.l   @(36,r15),r7
  763a5c:       f3 6a           mov     r15,r10
  763a5e:       28 7a           add     #40,r10
  763a60:       08 47           shll2   r7
  763a62:       79 1f           mov.l   r7,@(36,r15)
  763a64:       80 60           mov.b   @r8,r0
  763a66:       2d 88           cmp/eq  #45,r0
  763a68:       33 8d           bt.s    763ad2
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0xd2>
  763a6a:       a3 64           mov     r10,r4
  763a6c:       2f d0           mov.l   763b2c
<_Z14real_from_mpfrP10real_valuePK13__mpfr_structP9tree_node10mpfr_rnd_t+0x12c>,r0
      ! 4cd3b8 <sprintf@plt>
glaubitz@tirpitz:~/debian/segfault-test$

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #17 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #16)
>From the dump and

floatformat.c:529:2: internal compiler error: Segmentation fault
  dto = ldexp (1.0, exponent);

wmfire.c:559:6: internal compiler error: Segmentation fault
      psi = i * 3.14 / 20.0;

it looks that the segfaults happen on some computations of floating
point numbers in compiler itself.  I suspect mpfr libraries of which
functions are used in the dump.
Which version of mpfr/gmp is used for compilers?  mpfr has self
test and you could run it with "make check" in its build directory.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #18 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #17)
> Which version of mpfr/gmp is used for compilers?  mpfr has self
> test and you could run it with "make check" in its build directory.

You seem to be on to something here as, in fact, mpfr had problems previously
when built with "make check" [1]:

PASS: tcheck
PASS: tisnan
../../test-driver: line 107:  5759 Segmentation fault      "$@" > $log_file
2>&1
FAIL: texceptions
PASS: tset_exp

I have to admit that I recently disabled checks during builds on some buildds
to speed up the build process and this may have triggered the whole dilemma.

Assuming that mpfr would be the origin of this, would this also explain the
segmentation faults in the recently compiled systemd package? Because
apparently the systemd binaries crash because gcc has produced broken code
here. Could it be possible that the compiler made some float calculation which
gave a weird result, embedded that into systemd which in turns segfaults?

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=mpfr4&arch=sh4&ver=3.1.2-3&stamp=1425025691

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #19 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #18)
> You seem to be on to something here as, in fact, mpfr had problems
> previously when built with "make check" [1]:

I see many segfaults and bus errors in [1].  Clearly this mpfr
is problematic to use in compiler.  It might show some other
problem of the compiler which was used to build mpfr, though I
have no experience for such failures.  Anyway your current mpfr
looks broken and should be replaced with the sane one.

> Assuming that mpfr would be the origin of this, would this also explain the
> segmentation faults in the recently compiled systemd package? Because
> apparently the systemd binaries crash because gcc has produced broken code
> here. Could it be possible that the compiler made some float calculation
> which gave a weird result, embedded that into systemd which in turns
> segfaults?

There is too little information to say something and there are
many possibilities, I think.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #20 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #16)
>                               ...
>   763a3c:	03 61       	mov	r0,r1
>   763a3e:	00 e3       	mov	#0,r3
>   763a40:	16 62       	mov.l	@r1+,r2
>   763a42:	3c 22       	cmp/str	r3,r2
>   763a44:	fc 8b       	bf	763a40
>                               ...

That's a code snippet of the builtin strlen which has been added in 4.9...

I'm curious... Kaz, when bootstrapping the native 4.9 on sh4-linux, did you use
the 4.9 native compiler to build mpfr, mpc, gmp libraries?  They might indeed
be silently miscompiled due to some unknown hidden bug.
>From gcc-bugs-return-489495-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 20 13:56:14 2015
Return-Path: <gcc-bugs-return-489495-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 128748 invoked by alias); 20 Jun 2015 13:56:14 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 128695 invoked by uid 48); 20 Jun 2015 13:56:10 -0000
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
Date: Sat, 20 Jun 2015 13:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kkojima at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66563-4-KCAz4rhPIC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01827.txt.bz2
Content-length: 496

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf563

--- Comment #21 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #20)
> I'm curious... Kaz, when bootstrapping the native 4.9 on sh4-linux, did you
> use the 4.9 native compiler to build mpfr, mpc, gmp libraries?  They might
> indeed be silently miscompiled due to some unknown hidden bug.

No, I use always 'system' compiler to build these libraries.
In this case, 4.6.3 is my native system compiler.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #22 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #20)
> (In reply to John Paul Adrian Glaubitz from comment #16)
> >                               ...
> >   763a3c:	03 61       	mov	r0,r1
> >   763a3e:	00 e3       	mov	#0,r3
> >   763a40:	16 62       	mov.l	@r1+,r2
> >   763a42:	3c 22       	cmp/str	r3,r2
> >   763a44:	fc 8b       	bf	763a40
> >                               ...
> 
> That's a code snippet of the builtin strlen which has been added in 4.9...

That's strange. As Kaz has observed correctly, gcc always seems to segfault
when it comes to float arithmetics as I posted in #7.

Provided that you're right, how would a bug in strlen this explain that gcc
always segfaults when it needs to do float arithmetics?

Hmm.

I will do some further testing with a downgraded libmpfr.
>From gcc-bugs-return-489501-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 20 17:50:33 2015
Return-Path: <gcc-bugs-return-489501-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 61628 invoked by alias); 20 Jun 2015 17:50:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 61602 invoked by uid 48); 20 Jun 2015 17:50:29 -0000
From: "tps@vr-web.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
Date: Sat, 20 Jun 2015 17:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tps@vr-web.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66104-4-Van31QD9AZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66104-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66104-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01833.txt.bz2
Content-length: 225

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf104

--- Comment #7 from Thomas Schweikle <tps@vr-web.de> ---
If it wouldn't be possible to migrate up to 1.7.x or 1.8.x.
1.6.23 is the last version packaged of the 1.6-stream.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #23 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
It seems that Kaz was right. Downgrading libmpfr fixes the issue for me:

glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o
wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0)
wmfire.c: In function ‘do_help’:
wmfire.c:770:62: error: ‘VERSION’ undeclared (first use in this function)
  fprintf(stderr, "\nWmfire - Flaming Monitor Dock V %s\n\n", VERSION);
                                                              ^
wmfire.c:770:62: note: each undeclared identifier is reported only once for
each function it appears in
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$

Adrian
>From gcc-bugs-return-489506-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 21 00:58:05 2015
Return-Path: <gcc-bugs-return-489506-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 77636 invoked by alias); 21 Jun 2015 00:58:05 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 72181 invoked by uid 48); 21 Jun 2015 00:57:59 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
Date: Sun, 21 Jun 2015 00:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66563-4-VVdYC8aEN4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01838.txt.bz2
Content-length: 506

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf563

--- Comment #24 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #23)
> It seems that Kaz was right. Downgrading libmpfr fixes the issue for me:

In order to test whether this problem is actually a result of a miscompilation
bug in gcc, I suggest building mpfr from source with a current gcc-4.9 and then
run "make check" and see if the segfaults reproduce on native hardware.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #25 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #22)
> Provided that you're right, how would a bug in strlen this explain that gcc
> always segfaults when it needs to do float arithmetics?

I don't know the code of mpfr.  It could use __builtin_strlen for stuff like
parsing numbers etc.  However, the builtin_strlen code looks OK and hasn't been
causing trouble elsewhere.  So I guess that it just runs on broken data and
then causes a buffer overrun.  In other words, the actual bug is somewhere else
-- a quite common scenario for segfault class of bugs.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #26 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #25)
> I don't know the code of mpfr.  It could use __builtin_strlen for stuff like
> parsing numbers etc.  However, the builtin_strlen code looks OK and hasn't
> been causing trouble elsewhere.  So I guess that it just runs on broken data
> and then causes a buffer overrun.  In other words, the actual bug is
> somewhere else -- a quite common scenario for segfault class of bugs.

>From my current observations it seems that many packages seem to be affected
and all were compiled with the new compiler (with the patches since December).

I'm currently trying to localize the issue with procps which is also affected.
I'm doing a build with gcc-4.9_4.9.2-21 now which is svn r224436.

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #27 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Alright, I have tracked it down now! It's definitely a bug in mpfr4 and *not*
gcc.

I rebuilt both mpfr4_3.1.2-1 and mpfr4_3.1.2-3 with the latest compiler we have
in Debian which is gcc-4.9_4.9.2-21 (r224436).

This is the result with the compile test of wmfire with mpfr4_3.1.2-1:

glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o
wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0)     
           wmfire.c: In function ‘do_help’:                                    
                                                                               
                wmfire.c:770:62: error: ‘VERSION’ undeclared (first use in this
function)                                                                      
                       fprintf(stderr, "\nWmfire - Flaming Monitor Dock V
%s\n\n", VERSION);                                                             
                                                                               
              ^                                                                
                                     wmfire.c:770:62: note: each undeclared
identifier is reported only once for each function it appears in               
                                             
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$

This is the result with mpfr4_3.1.2-3:

glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o
wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0)      
wmfire.c: In function ‘draw_fire’:
wmfire.c:559:6: internal compiler error: Segmentation fault
      psi = i * 3.14 / 20.0;
      ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cc4xNN4u.out file, please attach this to
your bugreport.
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src

Again, *both* compiled fresh with the *same* compiler.

Adrian
>From gcc-bugs-return-489662-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 22 18:29:02 2015
Return-Path: <gcc-bugs-return-489662-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31594 invoked by alias); 22 Jun 2015 18:29:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31529 invoked by uid 48); 22 Jun 2015 18:28:59 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
Date: Mon, 22 Jun 2015 18:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66563-4-VN4WpOazPq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66563-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01994.txt.bz2
Content-length: 305

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf563

--- Comment #28 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Addendum: mpfr4_3.1.3-1 seems to be affected as well but I need to perform more
testing. But it's definitely the jump from 3.1.2-1 to 3.1.2-3 that caused the
bug!

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #29 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I've reproduced one problem for mpfr-3.1.3 with the cross
compiler.  For some TLS variables, we need to set GOT address
to the PIC register R12 even in non-PIC objects.  Here is
a hypothetical example what is going on.  Assume that we
computed GOT address twice in a function:

        mova    1f,r0
        mov.l   1f,r12
        add     r0,r12
        ...
1:      .long   _GLOBAL_OFFSET_TABLE_   ! GOTPC relocation
        ...

        mova    2f,r0
        mov.l   2f,r12
        add     r0,r12
        ...
2:      .long   _GLOBAL_OFFSET_TABLE_   ! GOTPC relocation

GOTPC relocation means that the value should set to (GOT address - .)
by linker.
Unfortunately, 4.9 and later compilers 'optimize' the above code
to the code like

        mova    1f,r0
        mov.l   1f,r12
        mov     r12,r11
        add     r0,r12
        ...
1:      .long   _GLOBAL_OFFSET_TABLE_   ! GOTPC relocation
        ...

        mova    2f,r0
        mov.l   r11,r12
        add     r0,r12
        ...
2:      .long   _GLOBAL_OFFSET_TABLE_   ! GOTPC relocation

i.e. try to memoize the _GLOBAL_OFFSET_TABLE_ 'value'.  This doesn't
work because the 2nd computation gets (GOT address - 1f) + 2f
instead of the correct GOT address.  This issue will affect the non-PIC
objects which use TLS aggressively.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #30 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 35829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35829&action=edit
possible patch for 4.9

The patch adds a counter to unspec vector of (unspec [...] UNSPEC_PIC)
pattern to avoid that memoization when these unspecs are used for TLS.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #31 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #29)
> Unfortunately, 4.9 and later compilers 'optimize' the above code
> to the code like

Just for my understanding ...

In the pattern ...

(define_expand "GOTaddr2picreg"
  [(set (reg:SI R0_REG)
        (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))]
                   UNSPEC_MOVA))
   (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC)))
   (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))]

... the 2nd (set ...) becomes the mov.l load from the constant pool, which is
CSE'ed by some other optimization after the initial RTL expansion.  If so,
wouldn't it be a bit cleaner to avoid CSE by hiding the constant/symref load
from CSE passes by doing something like the following ...

(define_expand "GOTaddr2picreg"
  [(parallel [(set (reg:SI R0_REG)
        (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))]
                   UNSPEC_MOVA))
   (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC)))
   (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))])]
  <... everything else stays the same ...>


(define_insn_and_split "*GOTaddr2picreg"
  [(set (reg:SI R0_REG)
        (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))]
                   UNSPEC_MOVA))
   (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC)))
   (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))]
  ""
  "#"
  "&& reload_completed"
  [(set (reg:SI R0_REG)
        (unspec:SI [(const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC))]
                   UNSPEC_MOVA))
   (set (match_dup 0) (const:SI (unspec:SI [(match_dup 1)] UNSPEC_PIC)))
   (set (match_dup 0) (plus:SI (match_dup 0) (reg:SI R0_REG)))])

Alternatively, can't the mov.l constant load insn be marked as "volatile" so
that it doesn't get optimized away for sure?

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #33 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #32)

I see, thanks.  In this case, could you please add a comment e.g.:

;; Loads of the GOTPC relocation values must not be optimized away
;; by e.g. any kind of CSE and must stay as they are.  Although there
;; are other various ways to ensure this, we use an artificial counter
;; operand to generate unique symbols.
(define_expand "GOTaddr2picreg"

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #36 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Thu Jun 25 10:15:18 2015
New Revision: 224935

URL: https://gcc.gnu.org/viewcvs?rev=224935&root=gcc&view=rev
Log:
PR target/66563
* [SH] Add a new operand to GOTaddr2picreg so to avoid CSE.  Modify caller
  of gen_GOTaddr2picreg.


Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/sh/sh.c
    branches/gcc-5-branch/gcc/config/sh/sh.md

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #41 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #40)
> with my 4.9 native compiler built with 4.9 cross compiler for svn
> gcc-4_9-branch.  I hope that miscompilation for mpfr is gone for
> bootstrapped 4.9 compiler and it fixes the original gcc issue too.
> Matthias, Adrian, what about the original error?

I cannot test yet as I have to fix the buildds first. This miscompilation issue
seems to have affected a couple of packages that found their way into the build
roots now and are causing me headaches.

I am waiting for Matthias to upload a new gcc-4.9 snapshot in the following
days while I will use the time to fix the build roots, then have the buildds
build the latest gcc-4.9 package and finally reschedule as many as possible
affected packages for rebuild.

So, please bear with me until I can give some feedback.

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #42 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #41)
> So, please bear with me until I can give some feedback.

Matthias has uploaded the 4.9.3 release now with additional patches from the
snapshot r225135 SVN revision. I just started building right now and the build
takes around 3 to 4 days. I'll report back once the build is finished and the
new gcc version is installed on all buildds.

Cross your fingers ;).

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #43 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #42) 
> Cross your fingers ;).

Btw, could building the fixed gcc-4.9 with a compiler affected by this
particular bug still propagate the problem? Or, asking the other way around:
Should the latest package version rather be built with an older, unaffected gcc
version?

I'm asking because I am worried the current compiler might generate another
broken gcc. On the other hand, it's also not that trivial to downgrade the
compiler in the build root, albeit it is possible. It just involves lots of
manual work.

Or is the bootstrap process with its 3 stages enough to mitigate such problems?

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #44 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #43)
> Btw, could building the fixed gcc-4.9 with a compiler affected by this
> particular bug still propagate the problem? Or, asking the other way around:
> Should the latest package version rather be built with an older, unaffected
> gcc version?

Not likely.  The sane gmp/mpfr/mpc libraries are needed, though.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #45 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #44)
> Not likely.  The sane gmp/mpfr/mpc libraries are needed, though.

Hmm, so the gcc I built is still broken. Many packages compiled with it still
segfault right away:

root@tirpitz:..procps/bin>
LD_PRELOAD=/root/procps/lib/sh4-linux-gnu/libprocps.so.4 ./ps
Signal 11 (SEGV) caught by ps (procps-ng version 3.3.10).
./ps:display.c:66: please report this bug
Segmentation fault
root@tirpitz:..procps/bin>

This is procps taken from:

> http://incoming.debian-ports.org/buildd/packages/sid/main/libprocps4_3.3.10-2+b2_sh4.deb
> http://incoming.debian-ports.org/buildd/packages/sid/main/procps_3.3.10-2+b2_sh4.deb

Could this still be the same bug, a different bug or does it happen because my
gmp/mpfr/mpc might not have been sane while building gcc-4.9_4.9.3-1?

This affects many packages that previously built fine. I'm still not sure where
to look for the source of this bug.

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #46 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Furthermore, gcc also built a version of grep that is broken and simply refuses
to read any options:

root@tirpitz:..grep-test2/bin> ls
egrep  fgrep  grep
root@tirpitz:..grep-test2/bin> ./grep 
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin> echo "hello" > bla.txt
root@tirpitz:..grep-test2/bin> grep hello *txt
hello
root@tirpitz:..grep-test2/bin> ./grep hello *txt
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin> ./grep hello *txt j
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin> ./grep hello *txt 1
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin> ./grep -v hello *txt 1
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin> ./grep --help
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin> ./grep --help
Usage: ./grep [OPTION]... PATTERN [FILE]...
Try './grep --help' for more information.
root@tirpitz:..grep-test2/bin>

grep taken from here:

> http://ftp.de.debian.org/debian-ports//pool-sh4/main/g/grep/grep_2.21-2+b1_sh4.deb

Freshly built with gcc-4.9.3 with the patch from this bug report. I don't know
whether this related though.

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #47 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Well, now I just compiled both procps and grep with the latest toolchain
(gcc-4.9_4.9.3 and binutils_2.25-9) from a pristine tarball with no Debian
patches applied and *outside* of the build root and the issues are gone.

So there is something installed in the build root of each buildd that results
in miscompiled packages. But I have absolutely no idea what is is.

Will do more debugging until I can figure out who the culprit is.

Adrian

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #48 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Alright, I found it, -fstack-protector-strong is the culprit. Will file a new
bug report now.

Adrian

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #49 from Matthias Klose <doko at gcc dot gnu.org> ---
Kaz, please could you propose these patches for 5.2 too, even if the branch is
currently frozen?

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #50 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Matthias Klose from comment #49)
> Kaz, please could you propose these patches for 5.2 too, even if the branch
> is currently frozen?

Btw, the main reason for most of these segfaults is probably PR/66780 and I'm
already building gcc-4.9_4.9.3-1+sh4 for "unreleased" which contains Kaz' patch
from the aforementioned PR.

Should be done by tomorrow afternoon (CEST) which means the build queue should
be fixed around next week. I will take care of all the build-related issues on
sh4.

As for gcc-5, I think chances are that gcc-5 will finally build on sh4 with the
latest SVN updates from the gcc-5 branch. But I need to get a fixed gcc-4.9
uploaded first, then rebuild essential packages like grep, xz-utils, openssl,
gnutls28, systemd and so on.

Adrian

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #51 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #49)
> Kaz, please could you propose these patches for 5.2 too, even if the branch
> is currently frozen?

It's too late, I think.

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #52 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #51)
BTW, I've already committed the patch in c#37 for gcc-5 for this PR.
The backport patch for PR/66780 is still in test for gcc-5.

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #53 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #52)
We are lucky:-)  The test for backport of PR66780 patch for gcc-5 was done
and we get a chance to commit it:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00819.html
All known patches are applied to 5-branch and 5.2-release.

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #54 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #53)
> (In reply to Kazumoto Kojima from comment #52)
> We are lucky:-)  The test for backport of PR66780 patch for gcc-5 was done
> and we get a chance to commit it:
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00819.html
> All known patches are applied to 5-branch and 5.2-release.

Woohoo, thanks a fortune!

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #55 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Can we close this as fixed?

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #56 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #55)
> Can we close this as fixed?

Yes.

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #57 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Fixed.

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #58 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Oh, and according to the Debian changelog, it must be a regression that was
introduced somewhere between r218987 and r222750 of the gcc-4.9 branch.

Currently, the buildds did not build any snapshot version between those two
revisions unfortunately, but I can just do more test builds to narrow down the
revision range where we need to look for the change that introduced the
regression.

Adrian

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #59 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #58)
> Oh, and according to the Debian changelog, it must be a regression that was
> introduced somewhere between r218987 and r222750 of the gcc-4.9 branch.

Please ignore this comment! This was supposed to go into PR/target 66312!

The bug tracker just hopped to the next PR with me noticing, sorry!