[llvm-dev] Mem2reg: load before single store

[László Radnai via llvm-dev]

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

Ah, thanks, I've missed that point. So it is undefined behavior.

> 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 [...]"

So I can also say that it is *unspecified *behavior, as it is an
unspecified value (I guess, not a trap representation?) that is used.
That's a contradiction, which is my point :)

László

On Tue, Sep 15, 2020 at 2:01 PM Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr>
wrote:

> 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/107c7fa8/attachment.html>