2018-06-05 3:00 GMT+02:00 Mark H Weaver <m...@netris.org>:
> l...@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
>
>
>
>
