[llvm-dev] Mem2reg: load before single store

[Juneyoung Lee via llvm-dev]

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>