Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Sep 2020 14:15:49 -0700
From:      Steve Kargl <sgk@troutmask.apl.washington.edu>
To:        Dimitry Andric <dim@freebsd.org>
Cc:        freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: clang miscompiles OpenLibm on i686-*-freebsd
Message-ID:  <20200908211549.GA84481@troutmask.apl.washington.edu>
In-Reply-To: <66AE2F5B-F150-4D52-BF43-8F453217FC33@FreeBSD.org>
References:  <20200908021002.GA76325@troutmask.apl.washington.edu> <20200908025513.GA76566@troutmask.apl.washington.edu> <20200908174721.GA81469@troutmask.apl.washington.edu> <66AE2F5B-F150-4D52-BF43-8F453217FC33@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 08, 2020 at 09:11:50PM +0200, Dimitry Andric wrote:
> On 8 Sep 2020, at 19:47, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> > 
> > I think I've found the problem, and it appears to be
> > due to a change byt Openlibm developers to the file
> > math_private.h copied from FreeBSD.  Namely, one finds
> > 
> > //VBS
> > #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> > 
> > /* VBS
> > #ifdef FLT_EVAL_METHOD
> > // Attempt to get strict C99 semantics for assignment with non-C99 compilers.
> > #if FLT_EVAL_METHOD == 0 || __GNUC__ == 0
> > #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> > #else
> > #define STRICT_ASSIGN(type, lval, rval) do { \
> > volatile type __lval;   \
> >      \
> > if (sizeof(type) >= sizeof(double)) \
> >  (lval) = (rval);  \
> > else {     \
> >  __lval = (rval);  \
> >  (lval) = __lval;  \
> > }     \
> > } while (0)
> > #endif
> > #endif
> > */
> > 
> > So, STRICT_ASSIGN is broken in Openlibm.  I'll be reporting
> > a bug upstream.  Apoogies for the noise.
> 
> Hi Steve,
> 
> I'm curious what their rationale was, as the commit that changed it is:
> 
> https://github.com/JuliaMath/openlibm/commit/f5fb92746715beb0441a60feca202ee16cb19fc9
> 
> with a description of just "Build with gcc"... Maybe they've assumed gcc
> never needs the volatile approach?
> 

I have no idea why OpenLibm would change math_private.h.  I've 
reported the issue at https://github.com/JuliaMath/openlibm/issues/215

-- 
Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200908211549.GA84481>