llvm dev - Sep 2020 - Mem2reg: load before single store

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

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>

Hi,
6.7.9.10 says:

If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate.
> 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)

Combined with this, we can say that the source program has UB.

Juneyoung

On Tue, Sep 15, 2020 at 8:13 PM László Radnai via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200915/2d1af383/attachment-0001.html>