On Wed, 13 Apr 2016, Jakub Jelinek wrote:
> On Wed, Apr 13, 2016 at 09:50:29AM +0200, Richard Biener wrote:
> > But I wonder why expansion doesn't simply "re-compute" TREE_STATIC
> > here. That is, do we rely on TREE_STATIC constructors for correctness
> > purposes as set by frontends?
>
> Clear
On Wed, Apr 13, 2016 at 09:50:29AM +0200, Richard Biener wrote:
> But I wonder why expansion doesn't simply "re-compute" TREE_STATIC
> here. That is, do we rely on TREE_STATIC constructors for correctness
> purposes as set by frontends?
Clearly we do rely on it. If we did not rely on it, would t
On Tue, 12 Apr 2016, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, gimplification of the VECTOR_TYPE CONSTRUCTOR
> elements can turn previously valid initializer_constant_valid_p
> into a temporary (thus no longer initializer_constant_valid_p).
>
> The following patch just clears TREE_ST
Hi!
As the testcase shows, gimplification of the VECTOR_TYPE CONSTRUCTOR
elements can turn previously valid initializer_constant_valid_p
into a temporary (thus no longer initializer_constant_valid_p).
The following patch just clears TREE_STATIC on the ctor if that happens,
so that we expand it pr
