From: "Gábor Boskovits" <boskovits@gmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: 31708@debbugs.gnu.org
Subject: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC segfaults
Date: Fri, 8 Jun 2018 12:04:03 +0200 [thread overview]
Message-ID: <CAE4v=pjMs5=H-4h=YqxAR79tYk=VK1frqkHfBsAtSFpv7awgUg@mail.gmail.com> (raw)
In-Reply-To: <87sh623v4a.fsf@netris.org>
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]
2018-06-05 3:00 GMT+02:00 Mark H Weaver <mhw@netris.org>:
> ludo@gnu.org (Ludovic Courtès) writes:
>
> > On current ‘core-updates’, we have:
> >
> > $ readlink -f $(type -P gcc)
> > /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
> > ludo@ribbon /home/ludo/src/guix/+core-updates$ cat strmov-ice.c
> > #define _GNU_SOURCE
> > #include <string.h>
> >
> > void foo (char *x)
> > {
> > static const char buf[12];
> > memcpy (x, buf, 12);
> > }
> > $ gcc -dH -O2 -Wall -c strmov-ice.c
> > strmov-ice.c: In function ‘foo’:
> > strmov-ice.c:7:3: internal compiler error: Segmentation fault
> > memcpy (x, buf, 12);
> > ^
> > gcc: internal compiler error: Aborted (program cc1)
>
> [...]
>
> > This is because DECL_INITIAL returns NULL_TREE for ‘buf’, but
> > ‘store_reference_p’ doesn’t check whether we got NULL_TREE.
> >
> > The fix is very simple (adding a NULL_TREE check), but in the meantime
> > we need to work around it.
> >
> > A simple workaround is to pass an initializer to the static const array:
> >
> > $ cat strmov-ice.c
> > #define _GNU_SOURCE
> > #include <string.h>
> >
> > void foo (char *x)
> > {
> > static const char buf[12] = { 0, };
> > memcpy (x, buf, 12);
> > }
> > $ gcc -dH -O2 -Wall -c strmov-ice.c
> > $ echo $?
> > 0
> >
> > The meaning of the program is unchanged but the bug is not triggered.
>
> Thanks for tracking this down. This explains why I've been seeing an
> unusually large number of internal compiler errors in this core-updates
> cycle. It was a bit surprising since we used the same compiler in the
> previous cycle, so I was wondering what might be causing it.
>
> At the moment, the most pressing failure caused by this bug is 'doxygen'
> on armhf, which causes GCC to crash deterministically in the same place
> every time, with many important dependency failures.
>
> https://hydra.gnu.org/build/2669344
>
> However, it's not obvious to me how best to work around the issue in
> this case. Here's the error message:
>
> --8<---------------cut here---------------start------------->8---
> [ 36%] Building CXX object qtools/CMakeFiles/qtools.dir/qutfcodec.cpp.o
> cd /tmp/guix-build-doxygen-1.8.13.drv-0/build/qtools && /gnu/store/
> cd5q2pni1d95fs3cdabbclyh9hqhw2nq-gcc-5.5.0/bin/c++ -I/gnu/store/
> zjgd0wcbwxz8469skx5s83kibycf1n5p-glibc-2.27/include
> -I/tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/. -O2 -g
> -DNDEBUG -o CMakeFiles/qtools.dir/qutfcodec.cpp.o -c
> /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfcodec.cpp
> /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfcodec.cpp:
> In member function ‘virtual QCString QUtf16Encoder::fromUnicode(const
> QString&, int&)’:
> /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfcodec.cpp:212:61:
> internal compiler error: Segmentation fault
> memcpy(d.rawData(),&QChar::byteOrderMark,sizeof(QChar));
> ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [qtools/CMakeFiles/qtools.dir/build.make:391:
> qtools/CMakeFiles/qtools.dir/qutfcodec.cpp.o] Error 1
> --8<---------------cut here---------------end--------------->8---
>
> Here's the declaration of QChar::byteOrderMark from qtools/qstring.h,
> included in the doxygen tarball:
>
> --8<---------------cut here---------------start------------->8---
> class Q_EXPORT Q_PACKED QChar {
> public:
> QChar();
> QChar( char c );
> QChar( uchar c );
> QChar( uchar c, uchar r );
> QChar( const QChar& c );
> QChar( ushort rc );
> QChar( short rc );
> QChar( uint rc );
> QChar( int rc );
>
> QT_STATIC_CONST QChar null; // 0000
> QT_STATIC_CONST QChar replacement; // FFFD
> QT_STATIC_CONST QChar byteOrderMark; // FEFF
> QT_STATIC_CONST QChar byteOrderSwapped; // FFFE
> QT_STATIC_CONST QChar nbsp; // 00A0
> --8<---------------cut here---------------end--------------->8---
>
> and here's its definition, from qtools/qstring.cpp line 12179:
>
> QT_STATIC_CONST_IMPL QChar QChar::byteOrderMark((ushort)0xfeff);
>
> Any suggestions? I've managed to avoid working with C++ so far in this
> millenium, so I'm a bit rusty.
>
>
I'm willing to investigate the possibilities we have in this case. Can you
help me reproduce this, if it is still a problem?
> Mark
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 6189 bytes --]
next prev parent reply other threads:[~2018-06-08 10:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-04 9:36 bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC segfaults Ludovic Courtès
2018-06-05 1:00 ` Mark H Weaver
2018-06-05 22:24 ` Mark H Weaver
2018-06-06 13:29 ` Ludovic Courtès
2018-06-08 10:04 ` Gábor Boskovits [this message]
2018-06-08 19:34 ` Ludovic Courtès
2018-06-08 13:26 ` Ludovic Courtès
2018-06-08 18:11 ` Mark H Weaver
2018-06-13 21:06 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE4v=pjMs5=H-4h=YqxAR79tYk=VK1frqkHfBsAtSFpv7awgUg@mail.gmail.com' \
--to=boskovits@gmail.com \
--cc=31708@debbugs.gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).