[llvm-dev] Mem2reg: load before single store

[László Radnai via llvm-dev]

A small note:

Definitions
The C11 draft (or whatever I found; link
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>) says it is the
"use" of the uninitialized value:

Under the *Undefined* Behavior section:
i) "- The value of an object with automatic storage duration is used while
it is indeterminate" (see indeterminate value later)

Where indeterminate value is defined as "either an unspecified value or a
trap representation"...

On the other hand, at the definition of the term "Unspecified behavior",
the following is the definition:
ii) "*unspecified* behavior: use of an unspecified value, or other behavior
[...]"

Consequences?

It seems to me that these two statements/definitions (i) and (ii)
contradict each other, however, neither one is stricter than the other
one...

So, we use an object. It can be *with* or *without* automatic storage
duration. The object can hold unspecified value or can be a trap
representation. The question is, using the value is *unspecified* or
*undefined*?

1) Based on this: the behavior is *unspecified*, if the object "used" is
*without* automatic storage duration.

2) The value is *undefined*, if an object is "used" *with* automatic
storage duration, which has a trap representation.

So, if I understand correctly, an object *with* automatic storage duration
has an unspecified value before the first modification (I've yet to find an
explicit statement of this, however, it seems reasonable...). Which of the
two contradicting statements holds? Is it *unspecified* or *undefined*?

László

On Mon, Sep 14, 2020 at 6:48 PM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:

>
> On 9/14/20 9:30 AM, James Y Knight via llvm-dev wrote:
> > On Mon, Sep 14, 2020 at 3:19 AM László Radnai via llvm-dev <
> > llvm-dev at lists.llvm.org> wrote:
> >
> >> A problem arises, and I am not sure if it is really a problem or just
> >> weird C-compliant behavior.
> >>
> >> int a; // or, equally, int a=0;
> >>
> >> int main(){
> >>   int b;
> >>   if (b) // (*)
> >>
> > At this line, you invoke undefined behavior by reading the value of "b",
> > before it's been initialized. At this point, the compiler may do whatever
> > it likes.
>
> FTR, it is *not* UB to read the value of b, you will read undef which is
> totally fine. It is however UB to branch on undef.
> At that point we can stop discussing what "happens next".
>
> ~ Johannes
>
>
>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200915/eb1a5e1d/attachment.html>