From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 23:21:50 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D952C8; Sun, 22 Mar 2015 23:21:50 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 709046E4; Sun, 22 Mar 2015 23:21:50 +0000 (UTC) Received: by lagg8 with SMTP id g8so121918103lag.1; Sun, 22 Mar 2015 16:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oiL2vrrT5PIPZmTnbWngtkHzy9QqKDZJBZC84uZyYuY=; b=DtVxJii3lPpTB9gvNoD5P/GsN5aVPCecKp7QQ7ptYTaGC5KHErdztA4vS+HxYozjZB U5xDP9p3on8BWcS8gkiF5Kpc2qWHkD/JNnuxyK5M2sRdQVxZYMR/H8FhKxYawjTntd56 Fs/KfCLIuJ0fZ25hyU0hVZj8Cr4lcNu+OAoEsrf9epJ2/SamvMfEKkg8veQPSdWBMszT IS525yyZq61UOG29223zyzVgBG9IdDKpBFAh9yt2uAyUblBagPVPvEBnCBIV31lICaPT oLUt9VzfaMB67zoEqmOgILQhX1QiV5uHA3eqjYYHukTSDwHrwMOg0c8B4tjYcb1Ud/ek /oBg== MIME-Version: 1.0 X-Received: by 10.152.234.108 with SMTP id ud12mr61998006lac.81.1427066508535; Sun, 22 Mar 2015 16:21:48 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Sun, 22 Mar 2015 16:21:48 -0700 (PDT) In-Reply-To: References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> Date: Sun, 22 Mar 2015 16:21:48 -0700 X-Google-Sender-Auth: ZPKE2ILuCH-vTojAgLI-Pf3tUDA Message-ID: Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 23:21:51 -0000 On Sun, Mar 22, 2015 at 3:01 PM, Craig Rodrigues wrote: > > > On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric wrote: > >> On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: >> > >> > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric >> 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. > > Thanks for committing the fix. I wasn't aware of this topic, but it is explained quite nicely in this LLVM blog post: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html#signed_overflow Do you think we should further change expr.y with something like this: Index: expr.y =================================================================== --- expr.y (revision 280357) +++ expr.y (working copy) @@ -445,12 +445,13 @@ } /* - * We depend on undefined behaviour giving a result (in r). - * To test this result, pass it as volatile. This prevents - * optimizing away of the test based on the undefined behaviour. + * We depend on undefined signed integer overflow behaviour + * giving a result (in r). + * This file must be compiled with the "-fwrapv" compiler + * flag which forces defined behavior for signed integer overflow. */ void -assert_times(intmax_t a, intmax_t b, volatile intmax_t r) +assert_times(intmax_t a, intmax_t b, intmax_t r) { /* * If the first operand is 0, no overflow is possible, -- Craig