Patch preapproved. Jakub
Hi,
Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-06/msg00646.html
Thanks, K
On Jun 19, 2013, at 1:38 AM, Richard Biener wrote:
> On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
>> On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
>>> Right, as you did for other cases. It works here as well.
>>
>> Patch preapproved.
>
> I wonder how much code breaks t
On Jun 19, 2013, at 1:44 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 10:38:47AM +0200, Richard Biener wrote:
>> On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
>>> On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
Right, as you did for other cases. It works here as
On Wed, Jun 19, 2013 at 10:38:47AM +0200, Richard Biener wrote:
> On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
> > On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
> >> Right, as you did for other cases. It works here as well.
> >
> > Patch preapproved.
>
> I wonder how mu
On Wed, Jun 19, 2013 at 9:22 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
>> Right, as you did for other cases. It works here as well.
>
> Patch preapproved.
I wonder how much code breaks these days when we enable -fno-common by
default? ...
Richard.
On Wed, Jun 19, 2013 at 11:12:21AM +0400, Igor Zamyatin wrote:
> Right, as you did for other cases. It works here as well.
Patch preapproved.
Jakub
Right, as you did for other cases. It works here as well.
Thanks,
Igor
On Wed, Jun 19, 2013 at 11:05 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 11:01:59AM +0400, Igor Zamyatin wrote:
>> The change also affects vectorizer in avx case which could be seen for
>> gcc.dg/tree-ssa/loop-19.c t
On Thu, Jun 13, 2013 at 11:37 AM, Alan Modra wrote:
> Revised patch with offsettable_ok_by_alignment change, avoiding dumb
> idea of using statement expressions. This one actually bootstraps and
> passes regression testing.
>
> * config/rs6000/rs6000.h (enum data_align): New.
> (
On Fri, Jun 14, 2013 at 12:54:40PM +0200, Jakub Jelinek wrote:
> On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
> > I see your point, but for there to be a real problem we'd need
> > a) A library exporting such a type with (supposed) increased
> >alignment, and,
> > b) gcc would ne
On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
> > As for the
> > typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
> >
> > vec_align x = { 0, 0, 0, 0 };
On Fri, Jun 14, 2013 at 10:59:52AM +0200, Jakub Jelinek wrote:
> On Fri, Jun 14, 2013 at 08:18:19AM +0930, Alan Modra wrote:
> > It is handling !DECL_P trees, which must be local. I know I saw
> > STRING_CST here when I wrote offsettable_ok_by_alignment, hence the
> > use of CONSTANT_ALIGNMENT. I
On Fri, Jun 14, 2013 at 08:18:19AM +0930, Alan Modra wrote:
> On Thu, Jun 13, 2013 at 05:42:17PM +0200, Jakub Jelinek wrote:
> > On Fri, Jun 14, 2013 at 01:07:01AM +0930, Alan Modra wrote:
> > > @@ -5774,10 +5818,11 @@ offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT
> > >type = TREE_TYPE
On Thu, Jun 13, 2013 at 05:42:17PM +0200, Jakub Jelinek wrote:
> On Fri, Jun 14, 2013 at 01:07:01AM +0930, Alan Modra wrote:
> > @@ -5774,10 +5818,11 @@ offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT
> >type = TREE_TYPE (decl);
> >
> >dalign = TYPE_ALIGN (type);
> > + dal
On Fri, Jun 14, 2013 at 01:07:01AM +0930, Alan Modra wrote:
> @@ -5774,10 +5818,11 @@ offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT
>type = TREE_TYPE (decl);
>
>dalign = TYPE_ALIGN (type);
> + dalign = DATA_ABI_ALIGNMENT (type, dalign);
>if (CONSTANT_CLASS_P (dec
On Thu, Jun 13, 2013 at 05:10:51PM +0930, Alan Modra wrote:
> On Wed, Jun 12, 2013 at 12:52:03PM -0500, Edmar Wienskoski wrote:
> > The e500v2 (SPE) hardware is such that if the address of vector (double
> > world
> > load / stores) are not double world aligned the instruction will trap.
> >
> >
On Wed, Jun 12, 2013 at 12:52:03PM -0500, Edmar Wienskoski wrote:
> The e500v2 (SPE) hardware is such that if the address of vector (double world
> load / stores) are not double world aligned the instruction will trap.
>
> So this alignment is not optional.
Vector type alignment is also specified
The e500v2 (SPE) hardware is such that if the address of vector (double world
load / stores) are not double world aligned the instruction will trap.
So this alignment is not optional.
Edmar
On Fri, Jun 7, 2013 at 3:43 PM, Richard Henderson wrote:
> On 06/07/2013 12:25 PM, Jakub Jelinek wrote:
Thanks!
On Mon, Jun 10, 2013 at 08:44:05PM -0400, DJ Delorie wrote:
>
> > @@ -986,12 +1053,10 @@ align_variable (tree decl, bool dont_out
> > if (! DECL_THREAD_LOCAL_P (decl) || const_align <= BITS_PER_WORD)
> > align = const_align;
> > }
> > -#endif
> > }
> > +#endif
>
> I think t
> @@ -986,12 +1053,10 @@ align_variable (tree decl, bool dont_out
> if (! DECL_THREAD_LOCAL_P (decl) || const_align <= BITS_PER_WORD)
> align = const_align;
> }
> -#endif
> }
> +#endif
I think this change in get_variable_align() is wrong; it results in
unbalanced brac
On Mon, Jun 10, 2013 at 11:44 AM, Jakub Jelinek wrote:
> On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
>> On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
>> >> > When the linker merges common blocks, it chooses both maximum size and
>> >> > maximum
>> >> > alignment. Thus for a
On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
> On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
> >> > When the linker merges common blocks, it chooses both maximum size and
> >> > maximum
> >> > alignment. Thus for any common block for which we can prove the block
> >> > must
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
>> > When the linker merges common blocks, it chooses both maximum size and
>> > maximum
>> > alignment. Thus for any common block for which we can prove the block must
>> > reside in the module (any executable, or hidden common in shared object),
>>
Richard Henderson wrote:
> s390 comment mentions LARL instruction
On s390(x) it is indeed an ABI requirement that all global symbols
are at least 2-aligned. (Note that we skip that alignment requirement
if a symbol is marked as attribute((aligned(1)), but that attribute
must then be present for
On 06/10/2013 12:55 PM, Jakub Jelinek wrote:
> On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote:
>> On 06/07/2013 10:43 PM, Richard Henderson wrote:
>>> But these I think require a good hard look to see if they really intended an
>>> ABI alignment:
>>>
>>> c6x comment explicitly mentio
On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote:
> On 06/07/2013 10:43 PM, Richard Henderson wrote:
> > But these I think require a good hard look to see if they really intended an
> > ABI alignment:
> >
> > c6x comment explicitly mentions abi
>
> The ABI specifies a minimum alignme
On 06/07/2013 10:43 PM, Richard Henderson wrote:
> But these I think require a good hard look to see if they really intended an
> ABI alignment:
>
> c6x comment explicitly mentions abi
The ABI specifies a minimum alignment for arrays.
Bernd
On Fri, Jun 07, 2013 at 11:14:19PM +0200, Jakub Jelinek wrote:
> > This structure would seem to do the wrong thing if DATA_ABI_ALIGNMENT is
> > defined, but DATA_ALIGNMENT isn't. And while I realize you documented it, I
> > don't like the restriction that D_A /must/ return something larger than
>
On Fri, Jun 07, 2013 at 06:56:34PM -0400, Hans-Peter Nilsson wrote:
> > criscompiler options for alignment -- systemwide or local?
>
> No, DATA_ALIGNMENT in cris.h is not intended as an ABI
> indication, but as an optimization when emitting data.
> (This was the way to do it at the time.
On Fri, 7 Jun 2013, Richard Henderson wrote:
> I've had a brief look over the instances of D_A within the tree atm. Most of
> them carry the cut-n-paste comment "for the same reasons". These I believe
> never intended an ABI change, and were really only interested in optimization.
>
> But these I
On Fri, Jun 07, 2013 at 01:43:27PM -0700, Richard Henderson wrote:
> On 06/07/2013 12:25 PM, Jakub Jelinek wrote:
> > This PR is about DATA_ALIGNMENT macro increasing alignment of some decls
> > for optimization purposes beyond ABI mandated levels. It is fine to emit
> > the vars aligned as much a
On 06/07/2013 12:25 PM, Jakub Jelinek wrote:
> This PR is about DATA_ALIGNMENT macro increasing alignment of some decls
> for optimization purposes beyond ABI mandated levels. It is fine to emit
> the vars aligned as much as we want for optimization purposes, but if we
> can't be sure that referen
32 matches
Mail list logo
