llvm dev - Feb 2012 - [LLVMdev] Is it an opt bug ?

Hi Seb,
> Already done here : http://llvm.org/bugs/show_bug.cgi?id=12130
that doesn't describe the original issue (second store removed), it is
talking
about a different issue that appeared at -O1 (and it first seemed to explain
your original problem; but now I think the -O1 transform was correct and does
not explain your original problem).

Ciao, Duncan.
>
> Thanks for your answers
> Best Regards
> Seb
>
> 2012/2/29 Duncan Sands <baldrick at free.fr <mailto:baldrick at
free.fr>>
>
>     Hi Seb,
>
>
>         If I remove datalayout definition, code is not optimized and work
as
>         expected.
>         So my question is:
>
>         What attribute/value/interpretation of data-layout would cause this
type
>         of bug?
>
>
>     all kinds of optimizers use datalayout (and are disabled if there is
none).  For
>     example, alias analysis, anything that needs to understand
getelementptr
>     offsets, the list is endless.
>
>     I suggest you open a bug report, describing your original problem as in
your
>     first email.
>
>     Ciao, Duncan.
>
>         Thanks for your answers
>         Seb
>
>         2012/2/28 Duncan Sands <baldrick at free.fr <mailto:baldrick
at free.fr>
>         <mailto:baldrick at free.fr <mailto:baldrick at
free.fr>>>
>
>
>             On 28/02/12 17:48, John Regehr wrote:
>          >> void t2(double *x)
>          >> {
>          >>       long long a[2];
>          >>       a[0] = 3;
>          >>       a[1] = 5;
>          >>       *x = * ((double *) a);
>          >>       *(x+1) = * ((double *) &a[a[0]-2]);
>          >> }
>          >
>          > Doesn't this code violate the strict aliasing rules?
>
>             Maybe, but the LLVM IR he showed seems perfectly well defined.
>
>             Ciao, Duncan.
>             ______________________________ _________________
>             LLVM Developers mailing list
>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>         <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at
cs.uiuc.edu>>
>         http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev
>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>
>

Hi Duncan,

I included original email in BUG description which described original issue
with store being removed.

BR
Seb

2012/2/29 Duncan Sands <baldrick at free.fr>
> Hi Seb,
>
>
>  Already done here :
http://llvm.org/bugs/show_bug.**cgi?id=12130<http://llvm.org/bugs/show_bug.cgi?id=12130>
>>
>
> that doesn't describe the original issue (second store removed), it is
> talking
> about a different issue that appeared at -O1 (and it first seemed to
> explain
> your original problem; but now I think the -O1 transform was correct and
> does
> not explain your original problem).
>
> Ciao, Duncan.
>
>
>> Thanks for your answers
>> Best Regards
>> Seb
>>
>> 2012/2/29 Duncan Sands <baldrick at free.fr <mailto:baldrick at
free.fr>>
>>
>>
>>    Hi Seb,
>>
>>
>>        If I remove datalayout definition, code is not optimized and
work
>> as
>>        expected.
>>        So my question is:
>>
>>        What attribute/value/interpretation of data-layout would cause
>> this type
>>        of bug?
>>
>>
>>    all kinds of optimizers use datalayout (and are disabled if there is
>> none).  For
>>    example, alias analysis, anything that needs to understand
>> getelementptr
>>    offsets, the list is endless.
>>
>>    I suggest you open a bug report, describing your original problem as
>> in your
>>    first email.
>>
>>    Ciao, Duncan.
>>
>>        Thanks for your answers
>>        Seb
>>
>>        2012/2/28 Duncan Sands <baldrick at free.fr
<mailto:baldrick at free.fr>
>>        <mailto:baldrick at free.fr <mailto:baldrick at
free.fr>>>
>>
>>
>>
>>            On 28/02/12 17:48, John Regehr wrote:
>>         >> void t2(double *x)
>>         >> {
>>         >>       long long a[2];
>>         >>       a[0] = 3;
>>         >>       a[1] = 5;
>>         >>       *x = * ((double *) a);
>>         >>       *(x+1) = * ((double *) &a[a[0]-2]);
>>         >> }
>>         >
>>         > Doesn't this code violate the strict aliasing rules?
>>
>>            Maybe, but the LLVM IR he showed seems perfectly well
defined.
>>
>>            Ciao, Duncan.
>>            ______________________________ _________________
>>            LLVM Developers mailing list
>>        LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>>        <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at
cs.uiuc.edu>>
>>
>>        http://llvm.cs.uiuc.edu
>>        http://lists.cs.uiuc.edu/ mailman/listinfo/llvmdev
>>       
<http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120229/436df21c/attachment.html>

Hi Seb,
> I included original email in BUG description which described original issue
with
> store being removed.
it is generally preferred to have different bug reports for different issues,
rather than one bug report that mutates itself as time goes on.  Any casual
reader will see the bug as being about the -O1 issue, and not realize that
there is another issue hidden in the accompanying email.  The -O1 issue is not
an issue, thus I closed the bug report.  Please open a new one with the -O2
issue.

Thanks, Duncan.