RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

erger; cfe-commits Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits <cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>> wrote: On Mon, Dec 07, 2015

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

> --paulr > > > > *From:* meta...@gmail.com [mailto:meta...@gmail.com] *On Behalf Of *Richard > Smith > *Sent:* Tuesday, December 08, 2015 11:42 AM > *To:* Robinson, Paul > *Cc:* Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org) > > *Subject:* Re: r254574 -

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[mailto:meta...@gmail.com] On Behalf Of Richard Smith Sent: Wednesday, December 09, 2015 12:43 PM To: Robinson, Paul Cc: Joerg Sonnenberger; cfe-commits (cfe-commits@lists.llvm.org) Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled On Wed, Dec 9

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote: > Worse, it seems > > even using __builtin_nan() for example doesn't work. > > > > __builtin_nan() works fine for me, can you provide a testcase? I take this part back, pilot error. Joerg

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote: > C11 6.3.1.5/1: "If the value being converted is outside the range of values > that can be represented, the behavior is undefined." The value of 1e100 can be represented as +inf, even if not precisely. This is a bit

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

consistent with past practice, that's fine. Thanks, --paulr From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith Sent: Monday, December 07, 2015 7:25 PM To: Robinson, Paul Cc: cfe-commits (cfe-commits@lists.llvm.org) Subject: Re: r254574 - PR17381: Treat undefined behavior

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Okay, I'll bite: so what *does* UINT128_MAX actually convert to? From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Richard Smith via cfe-commits Sent: Tuesday, December 08, 2015 10:52 AM To: Joerg Sonnenberger; cfe-commits Subject: Re: r254574 - PR17381: Treat undefined

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

... which gives a NaN in this case. *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On Behalf >> Of *Richard Smith via cfe-commits >> *Sent:* Tuesday, December 08, 2015 10:52 AM >> *To:* Joerg Sonnenberger; cfe-commits >> *Subject:* Re: r254574 - PR17381:

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

@f = global float undef, align 4 > *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On > Behalf Of *Richard Smith via cfe-commits > *Sent:* Tuesday, December 08, 2015 10:52 AM > *To:* Joerg Sonnenberger; cfe-commits > *Subject:* Re: r254574 - PR17381: Trea

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits wrote: > Author: rsmith > Date: Wed Dec 2 19:36:22 2015 > New Revision: 254574 > > URL: http://llvm.org/viewvc/llvm-project?rev=254574=rev > Log: > PR17381: Treat undefined behavior during expression evaluation as an

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Two more questions: (1) Commit message implied this is only for C, but I see it with C++11 (but not C++03). $ cat t.cpp enum { foo = 123456 * 234567 }; $ clang -c t.cpp -std=c++03 $ clang -c t.cpp -std=c++11 t.cpp:1:14: error: expression is not an integral constant expression (2) Shouldn't

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

s to "finite value" wrt conversion to an >> integer type. >> >> --paulr >> >> >> >> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On >> Behalf Of *Richard Smith via cfe-commits >> *Sent:* Monday, December 07, 2015 1:3

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 5:26 PM, Reid Kleckner via cfe-commits < cfe-commits@lists.llvm.org> wrote: > It wasn't Chrome, it was some internal dependency on torch-cephes. I > submitted a patch for it upstream: > >

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits > wrote: > > Author: rsmith > > Date: Wed Dec 2 19:36:22 2015 > > New Revision: 254574 > > > > URL:

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

ommits Sent: Monday, December 07, 2015 1:32 PM To: Joerg Sonnenberger; cfe-commits Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits <cfe-commits@lists.llvm.org<mailto:cfe-comm

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits >> wrote: >>

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer wrote: > > > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits > wrote: >> >> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits >> wrote:

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg wrote: > On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer > wrote: > > > > > > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits > > wrote: > >> > >> On Mon, Dec 7,

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

I've amended this change to permit constant-foldable UB in C variable initializers again in r254992. On Mon, Dec 7, 2015 at 6:45 PM, Robinson, Paul via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Two more questions: > > (1) Commit message implied this is only for C, but I see it with

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 9:51 PM, Richard Smith wrote: > On Mon, Dec 7, 2015 at 5:26 PM, Reid Kleckner via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> It wasn't Chrome, it was some internal dependency on torch-cephes. I >> submitted a patch for it upstream: >> >>

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Mon, Dec 7, 2015 at 7:20 PM, David Majnemer wrote: > On Mon, Dec 7, 2015 at 9:51 PM, Richard Smith > wrote: > >> On Mon, Dec 7, 2015 at 5:26 PM, Reid Kleckner via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> It wasn't Chrome, it

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

It wasn't Chrome, it was some internal dependency on torch-cephes. I submitted a patch for it upstream: https://github.com/deepmind/torch-cephes/commit/9c4a97c90dc200ecbecb883e7230fe3c847954df It's not a pretty, though. I know LLVM IR rules are not C++ rules, but LLVM generally believes in NaN.