Date: Wed, 17 Apr 2013 12:07:47 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Jan Beich <jbeich@tormail.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, FreeBSD ports <freebsd-ports@freebsd.org> Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ Message-ID: <FC566DC6-486C-4741-8491-BEAB2BAAF4CA@FreeBSD.org> In-Reply-To: <1USKxR-00025i-Tt@internal.tormail.org> References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> <1URs5b-000B9U-A2@internal.tormail.org> <E15F2208-0A57-4C40-B7B0-FEA7953500AD@FreeBSD.org> <1USKxR-00025i-Tt@internal.tormail.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 17, 2013, at 07:31, Jan Beich <jbeich@tormail.org> wrote: > Dimitry Andric <dim@FreeBSD.org> writes: > On Apr 16, 2013, at 00:42, Jan Beich <jbeich@tormail.org> wrote: ... >>> Maybe -O3 overoptimizes regex in libc e.g., >>>=20 >>> $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' >>> #if @GNULIB_EUIDACCESS@ >>>=20 >>> $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//' >>> aaaaaaaaaaaaaaaaxxxaaaa >>=20 >> How did you arrive at this result? >=20 > 1/ chroot into poudriere jail for /head amd64 > 2/ echo CFLAGS+=3D-O3 >> /etc/make.conf > 3/ make -j2 (in /usr/src/lib/libc) > 4/ prepend LD_LIBRARY_PATH=3D. before sed(1) > 5/ rebuild regcomp.o, regcomp.So with -O2 to confirm I have been able to reproduce this on amd64, with -O3, but not on i386. It seems regcomp() is either miscompiled at -O3, or it contains some bug triggered only by the vectorizer. I am still investigating. > My luck is poor even with -O2 e.g., firefox20 crash on = stackoverflow.com >=20 > [New LWP 101222] > [New Thread 801b02400 (LWP 101222)] > [New Thread 81060e800 (LWP 101372 StreamTrans #1)] > [New Thread 810ee8800 (LWP 101373 DOM Worker)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 801b02400 (LWP 101222)] > PodCopy<JS::Value> (dst=3D<optimized out>, nelem=3D<optimized out>, > src=3D<optimized out>, dst=3D<optimized out>, src=3D<optimized = out>, > nelem=3D<optimized out>) at ../../../js/src/jsutil.h:238 > 238 PodAssign(dst, src); > (gdb) bt > #0 PodCopy<JS::Value> (dst=3D<optimized out>, nelem=3D<optimized = out>, > src=3D<optimized out>, dst=3D<optimized out>, src=3D<optimized = out>, > nelem=3D<optimized out>) at ../../../js/src/jsutil.h:238 > #1 getCallFrame (cx=3D<optimized out>, flags=3D<optimized out>, = fun=3D<optimized out>, > report=3D(unknown: 2266652928), this=3D<optimized out>, args=3D..., = script=3D...) > at ../../../js/src/vm/Stack-inl.h:454 > #2 getFixupFrame (cx=3D<optimized out>, initial=3D<optimized out>, > fun=3D<optimized out>, ncode=3D<optimized out>, dummy=3D0, = report=3D<optimized out>, > this=3D<optimized out>, cx=3D<optimized out>, report=3D<optimized = out>, args=3D..., > fun=3D<optimized out>, script=3D..., ncode=3D<optimized out>, > initial=3D<optimized out>, stackLimit=3D<optimized out>) > at ../../../js/src/vm/Stack-inl.h:513 > #3 js::mjit::stubs::FixupArity (f=3D..., nactual=3D4294945312) > at = /wrkdirs/usr/ports/www/firefox/work/mozilla-release/js/src/methodjit/Invok= eHelpers.cpp:213 > #4 0x00000008019c48c2 in ?? () > #5 0x00000008019b56b8 in ?? () > #6 0x0000000000000001 in ?? () > #7 0x0000000000000000 in ?? () This is a completely different issue. Is there any way you can reduce the test case? Or maybe upstream has already fixed it?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FC566DC6-486C-4741-8491-BEAB2BAAF4CA>