CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import
Hi, I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import, and am getting new build failures related to C++ such as: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87: error: use of deleted function 'clang::Sema::TypoExprState::TypoExprState(const clang::Sema::TypoExprState)' sizeof(__is_convertible_imp::__test_T2(__is_convertible_imp::__source_T1())) == 1 See full build logs here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/console Any ideas what the problem might be? Thanks. -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Mar 22, 2015, at 14:36, Dimitry Andric d...@freebsd.org wrote:
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed
caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
Before doing that — what changed in the past week that changed the behavior of
expr?
Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed
caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is
indeed caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
--
Craig
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there might be other potential issues lurking around that need to be solved (either here, in ports, or both). Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
11.0-CURRENT -r276514's ncurses .vs gcc5-based buildworld: the generated lib_gen.c has problems
Basic context (more details later):
I ran into the below while exploring FreeBSD via a powerpc64 context. But
unlike most things I've run into this is probably not powerpc64 (or powerpc)
context specific. Nor does it appear to be as simple as the out-of-order and/or
incomplete includes issue that I ran into.
gcc5 use is not likely where anyone is focused either.
Still I figured I'd send out this note about the oddity as a FYI.
# dmesg | head
...
FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015
root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc
gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)
...
(I used powerpc64-xtoolchain-gcc in a powerpc64 context to self-host,
WITHOUT_CLANG= WITHOUT_LLDB= WITHOUT_GCC= WITHOUT_GNUCXX= WITHOUT_BOOT=
WITHOUT_LIB32= .)
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
05:15:23 PDT 2015
root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64
1100062 1100062
make -j 8 \
WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \
WITHOUT_LLDB= \
WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \
WITH_BOOT= WITH_LIB32= \
buildworld buildkernel \
KERNCONF=GENERIC64vtsc-NODEBUG
TARGET=powerpc TARGET_ARCH=powerpc64
For the context set by the following in order to use gcc5/g++5/... :
# more /etc/src.conf
NO_WERROR=
WITH_LIBCPLUSPLUS=
#
#
# For trying gcc5...
#
CC=/usr/local/bin/gcc5
CXX=/usr/local/bin/g++5
CPP=/usr/local/bin/cpp5
AS=/usr/local/powerpc64-portbld-freebsd11.0/bin/as
R=/usr/local/powerpc64-portbld-freebsd11.0/bin/ar
LD=/usr/local/powerpc64-portbld-freebsd11.0/bin/ld
NM=/usr/local/powerpc64-portbld-freebsd11.0/bin/nm
OBJCOPY=/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy
OBJDUMP=/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump
RANLIB=/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib
SIZE=/usr/local/powerpc64-portbld-freebsd11.0/bin/size
STRINGS=/usr/local/powerpc64-portbld-freebsd11.0/bin/strings
The problem when gcc5 was used:
/usr/local/bin/gcc5 -O2 -pipe -I.
-I/usr/obj/usr/srcC/lib/ncurses/ncurses/../ncurses
-I/usr/srcC/lib/ncurses/ncurses/../ncurses
-I/usr/srcC/lib/ncurses/ncurses/../ncurses
-I/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/include
-I/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall
-DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c lib_gen.c -o
lib_gen.o
_2624.c:754:3: error: _Bool after # is not a positive integer
In file included from
/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv.h:313:0,
from lib_gen.c:19:
_2624.c:755:2: error: expected ')' before 'int'
*** Error code 1
Stop.
make[4]: stopped in /usr/srcC/lib/ncurses/ncurses
*** Error code 1
Comparing the tail of the generated lib_gen.c from another 11.0-CURRENT
(non-gcc5) tree that I have around...
First the tail from that other tree (the normal one):
# tail -20 lib_gen.c | more
T((T_CALLED(getmaxy(%p)), (const void *)z)); returnCode(((z) ?
((z)-_maxy + 1) : (-1)));
}
NCURSES_EXPORT(int) (getparx) (const WINDOW * z)
{
T((T_CALLED(getparx(%p)), (const void *)z)); returnCode(((z) ?
(z)-_parx : (-1)));
}
NCURSES_EXPORT(int) (getpary) (const WINDOW * z)
{
T((T_CALLED(getpary(%p)), (const void *)z)); returnCode(((z) ?
(z)-_pary : (-1)));
}
NCURSES_EXPORT(NCURSES_BOOL) (mouse_trafo) (int * a1, int * a2, NCURSES_BOOL
z)
{
T((T_CALLED(mouse_trafo(%p,%p,%#lx)), (const void *)a1, (const void
*)a2, (long)z)); returnBool(wmouse_trafo(stdscr,a1,a2,z));
}
Then the tail for the generated file from the gcc5 based tree (the odd one):
# tail -20 lib_gen.c
NCURSES_EXPORT(int) (getpary) (const WINDOW * z)
{
T((T_CALLED(getpary(%p)), (const void *)z)); returnCode(((z) ?
(z)-_pary : (-1)));
}
# 753 _2624.c 3 4
NCURSES_BOOL
# 753 _2624.c
mouse_trafo (int * a1, int * a2,
# 753 _2624.c 3 4
NCURSES_BOOL
# 753 _2624.c
z)
{
T((T_CALLED(mouse_trafo(%p,%p,%#lx)), (const void *)a1, (const void
*)a2, (long)z)); returnBool(wmouse_trafo(stdscr,a1,a2,z));
}
Context details:
# more /etc/make.conf
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=
# svnlite info /usr/srcC/
Path: /usr/srcC
Working Copy Root Path: /usr/srcC
URL: https://svn0.us-west.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric d...@freebsd.org wrote:
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is
indeed caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
OK, converting expr.y to use unsigned integers would require a bit of work.
Can you commit your patch to the Makefile? It fixes the problem for now.
--
Craig
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there might be other potential issues lurking around that need to be solved (either here, in ports, or both). Because this version optimizes better around undefined behavior. There are most likely many issues lurking around, and most certainly in ports. I would recommend using UBSan to tackle this kind of thing. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import
I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and its powerpc64-gcc port: use of CROSS_TOOLCHAIN=powerpc64-gcc used on a powerpc64. No solution, just notes about what was going on after looking at the source code related to the messages. If you care, see: CROSS_TOOLCHAIN=powerpc64-gcc mishandles Substitution Failure Is Not An Error when compiling clang and stops the build ( https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001506.html ) sizeof(__is_convertible_imp::__test_T2(__is_convertible_imp::__source_T1())) == 1 is the core place involved in your example and mine but the order of compilation for my context means a different starting place that ended up using the above. lang/gcc5 did the same when I later tried it. I doubt that host-type or TARGET or TARGET_ARCH matter. I doubt xtoolchain vs. normal port matters. I expect that the issue spans a range of g++ versions. Unfortunately that probably also means that the effectively Substitution Failure of this kind Is An Error rule now in use will probably be around for a while: it is likely not some local accident that has a quick fix. The best case is if it is simple but each version/variant needs to release with the change. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
