This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 17 Aug 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> Alexander Monakov <amonakov at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |amonakov at gcc dot gnu.org
> 
> --- Comment #7 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
> Small C testcase demonstrating the issue with -O2 -fno-tree-sra:
> 
> void g(int *out)
> {
>   struct s {int x;} s;
> #pragma GCC ivdep
>   for (int i = 0; i < 100; i++)
>     {
>       int *x = &s.x;
>       asm("" : "+r"(x));
>       *x = 42;
>       out[i] = s.x;
>     }
> }
> 
> I think the main question is how safelen introduced via pragma-ivdep or
> do-concurrent is supposed to interact with addressable vars written in the loop
> body? It doesn't seem well-defined?..

I think this one is simply undefined given the must-alias dependency
isn't "obvious" (aka literal).  The fortran case would be similar
(it has a function call).

But of course GCC itself could introduce above obfuscation.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]