Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-06 03:31:46 +0100, Erik Trulsson wrote:
> Even with your interpretation of the C99 standard that example would be
> allowed only if  '*pu' is a valid lvalue of type  'union u'.  (Since pu->x
> is equivalent to (*pu).x)
> 
> First of all the conversion  (union u*)&i is valid only if the alignment
> of 'i' is suitable for an object of type 'union u'.  Lets assume that is the
> case. (Otherwise just making that conversion would result in undefined
> behaviour.)  (See 6.3.2.3 clause 7.)
> 
> There is however no guarantee that the conversion yields a valid "pointer to
> union u".  If not then dereferencing it (with the expression '*pu') has
> undefined behaviour. (See 6.5.3.2 clause 4)

I wonder what you mean by "valid pointer to union u". If alignment
is OK, the pointer itself is valid. The only problem could be memory
representation. I wonder whether 6.2.5p20 could be sufficient if
there are no padding bytes.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Why Thumb-2 only allows very limited access to the PC?

[Carrot Wei]

So thumb2 can also use the instructions similar to thumb1, right? It
potentially has better performance and smaller code size.

thanks
Carrot

On Tue, Jan 5, 2010 at 7:06 PM, Richard Earnshaw  wrote:
>
> On Tue, 2010-01-05 at 15:42 +0800, Carrot Wei wrote:
>> Hi
>>
>> In function arm_load_pic_register in file arm.c there are following code:
>>
>>       if (TARGET_ARM)
>>       {
>>               ...
>>       }
>>       else if (TARGET_THUMB2)
>>       {
>>         /* Thumb-2 only allows very limited access to the PC.  Calculate the
>>            address in a temporary register.  */
>>         if (arm_pic_register != INVALID_REGNUM)
>>           {
>>             pic_tmp = gen_rtx_REG (SImode,
>>                                    thumb_find_work_register (saved_regs));
>>           }
>>         else
>>           {
>>             gcc_assert (can_create_pseudo_p ());
>>             pic_tmp = gen_reg_rtx (Pmode);
>>           }
>>
>>         emit_insn (gen_pic_load_addr_thumb2 (pic_reg, pic_rtx));
>>         emit_insn (gen_pic_load_dot_plus_four (pic_tmp, labelno));
>>         emit_insn (gen_addsi3 (pic_reg, pic_reg, pic_tmp));
>>       }
>>       else /* TARGET_THUMB1 */
>>       {
>>               ...
>>       }
>>
>> The comment said "Thumb-2 only allows very limited access to the PC.
>> Calculate the address in a temporary register.". So the generated code
>> is a little more complex than thumb1. Could anybody help to give more
>> explanation on the limitation thumb2 has compared to thumb1?
>>
>> The generated instructions by this function for thumb1 is listed
>> following, both instructions are available under thumb2.
>>
>>         ldr     r3, .L2
>> .LPIC0:
>>         add     r3, pc
>
> I didn't write the comment, but I think the limitation is relative to
> ARM not thumb1.  Thumb2 code generator is a variation on the ARM code
> generator, so the author was most likely thinking of that rather than
> Thumb1.
>
> R.
>
>

Re: GCC aliasing rules: more aggressive than C99?

[Andrew Haley]

On 01/06/2010 04:09 AM, Joshua Haberman wrote:
> Erik Trulsson  student.uu.se> writes:
>> On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
>>> The aliasing policies that GCC implements seem to be more strict than
>>> what is in the C99 standard.  I am wondering if this is true or whether
>>> I am mistaken (I am not an expert on the standard, so the latter is
>>> definitely possible).
>>> -
>>> The relevant text is:
>>> -
>>>   An object shall have its stored value accessed only by an lvalue
>>>   expression that has one of the following types:
>>> -
>>>   * a type compatible with the effective type of the object,
>>>   [...]
>>>   * an aggregate or union type that includes one of the aforementioned
>>> types among its members (including, recursively, a member of a
>>> subaggregate or contained union), or
>>> -
>>> To me this allows the following:
>>> -
>>>   int i;
>>>   union u { int x; } *pu = (union u*)&i;
>>>   printf("%d\n", pu->x);
>>> -
>>> In this example, the object "i", which is of type "int", is having its
>>> stored value accessed by an lvalue expression of type "union u", which
>>> includes the type "int" among its members.
>> -
>> Even with your interpretation of the C99 standard that example would be
>> allowed only if  '*pu' is a valid lvalue of type  'union u'.  (Since pu->x
>> is equivalent to (*pu).x)
>> -
>> First of all the conversion  (union u*)&i is valid only if the alignment
>> of 'i' is suitable for an object of type 'union u'.  Lets assume that is the
>> case. (Otherwise just making that conversion would result in undefined
>> behaviour.)  (See 6.3.2.3 clause 7.)
> 
> This is true.  You could get around this particular point by saying:
> 
>   int *i = malloc(sizeof(*i));
>   *i = 5;
>   union u { int x; } *pu = (union u*)i;
>   printf("%d\n", pu->x);
> 
> ...since the return from malloc() is guaranteed to be suitably aligned for
> any object (7.20.3).  But your point is taken.
> 
>> There is however no guarantee that the conversion yields a valid
>> "pointer to union u".  If not then dereferencing it (with the
>> expression '*pu') has undefined behaviour. (See 6.5.3.2 clause 4)
> 
> I think this is a bit of a stretch.  It is true that 6.5.3.2 says that
> dereferencing invalid values has undefined behavior.  But if you are
> saying that the standard has to explicitly say that a pointer conversion
> will not result in an invalid value (even when suitably aligned), then
> the following is also undefined:
> 
>   int i;
>   unsigned int *pui = (unsigned int*)&i;
>   unsigned int ui = *pui;
> 
> Andrew cited 6.3.2.3p2 as support for why this is defined, but that
> paragraph deals with qualifiers (const, volatile, and restrict).
> "unsigned" is not a qualifier.

You are correct, and I was completely wrong about this.  I thought you
were talking about qualifiers: I didn't read what you'd written
carefully enough and I responded too quickly.

> There is no part of the standard that guarantees that a pointer
> conversion from "int*" to "unsigned int*" will not result in an
> invalid value.

That's right.

Andrew.

RE: PowerPC : GCC2 optimises better than GCC4???

[Mark Colby]

>>> Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
>> 
>> Probably because the RTL on x86_64 uses and's and ior's, but PPC uses
>> set's of zero_extract's (insvsi).
>
> Aha!  Yes, that'll probably be it.  It should be easy to fix cse to
> recognize those too.
>
> Andrew

I'm not familiar with the gcc source yet, but just in case I get the time to 
look at this, could anyone give me a file/line ref to dive into and examine? 
Thanks for your attention on this.

Mark


*
This email has been checked by the altohiway Mailcontroller Service
*

Re: threading jumps makes niter changed from INTEGER_CST to chrec_dont_know

[Eric Fisher]

2010/1/6 Jeff Law :
> Please file a bug report with a complete testcase so that we can see what's
> happening rather than trying to speculate.
>
> jeff
>

Uh, seems this problem doesn't occur on trunk. Because before
pass_dominator, pass_complete_unrolli is able to unroll the following
test case.

void
foo (int x)
{
  int i;

  for (i=0; i < 2 ; i++)
if (x)
  {
if (i == 0)
  fun_1 ();
else
  fun_2 ();
  }
}

I found this problem on gcc-4.4.0. The pass_complete_unrolli doesn't
unroll this loop, but if -fno-tree-dominator-opts is applied,
pass_complete_unroll is able to unroll it.

And pass_dominator does cause the loop's exit bb never dominate its latch bb.

Thanks
Eirc

Re: PowerPC : GCC2 optimises better than GCC4???

[Andrew Haley]

On 01/06/2010 09:59 AM, Mark Colby wrote:
 Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
>>>
>>> Probably because the RTL on x86_64 uses and's and ior's, but PPC uses
>>> set's of zero_extract's (insvsi).
>>
>> Aha!  Yes, that'll probably be it.  It should be easy to fix cse to
>> recognize those too.

> I'm not familiar with the gcc source yet, but just in case I get the
> time to look at this, could anyone give me a file/line ref to dive
> into and examine?

Would you believe cse.c?  :-)

I can't find the line without investigating further.

Andrew.

P.S.  This is a nontrivial task if you don't know gcc, but might be a
good place for a beginner to start.  OTOH, might be hard: no way to
know without digging.

RE: PowerPC : GCC2 optimises better than GCC4???

[Mark Colby]

>>> Aha!  Yes, that'll probably be it.  It should be easy to fix cse to
>>> recognize those too.

>> I'm not familiar with the gcc source yet, but just in case I get the
>> time to look at this, could anyone give me a file/line ref to dive
>> into and examine?

> Would you believe cse.c?  :-)

Ha! I'll look before asking next time :-)

> I can't find the line without investigating further.

> Andrew.

> P.S.  This is a nontrivial task if you don't know gcc, but might be a
> good place for a beginner to start.  OTOH, might be hard: no way to
> know without digging.

Many thanks. I'll take a look.


*
This email has been checked by the altohiway Mailcontroller Service
*

Re: adding -fnoalias ... would a patch be accepted ?

[Richard Guenther]

On Tue, Jan 5, 2010 at 5:39 PM, torbenh  wrote:
> On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
>> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
>> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
>> >>
>> >> The -fno-alias-X things do not make much sense for user code (they
>> >> have been historically used from Frontends).  If restrict doesn't work
>> >> for you (do you have a testcase that can reproduce your issue?)
>> >> then you probably need to wait for IPA pointer analysis to be
>> >> fixed in GCC 4.6.
>> >
>> > sorry... forget the attachment :S
>>
>> Yes, in this case you can fix it by making ramp static.  Otherwise its
>> address may be takein in another translation unit.  For Fortran we
>> have the DECL_RESTRICTED_P which we could expose to other
>> languages via an attribute.  It tells that a decl is not aliased by
>> restrict qualified pointers, so
>>
>> struct Ramp {
>>     float phase;
>>     inline float process() { return phase++; }
>> } ramp __attribute__((restrict));
>>
>> void fill_buffer( float * __restrict buf, size_t nframes )
>> {
>>     for( size_t i=0; i>         buf[i] = ramp.process();
>> }
>
> would that also work with this stuff:
>
>
> template
> class Mixer;
>
> template
> class Mixer : public Block
> {
>    private:
>        T1 t1 __attribute__((restrict));
>        Mixer t2;
>    public:
>        inline float process() {
>            return t1.process() + t2.process();
>        }
> };
>
> template
> class Mixer : public Block
> {
>    private:
>        T1 t1 __attribute__((restrict));
>        T2 t2 __attribute__((restrict));
>    public:
>        inline float process() {
>            return t1.process() + t2.process();
>        }
> };
>
> Mixer mix __attribute__((restrict))
>
> ?

I don't see a restrict qualified pointer here.  Note that the
restrict attribute would only disambiguate against those.
Also I think you need the restrict attribute on the Mixer
objects, not its members.

> i still dont understand whats the problem with -fnolias,
> as in attached patch.

The patch will miscompile everything.

Richard.

>>
>> would then be optimized as well.  Can you file an enhancement
>> bugreport according to this?
>>
>> Thanks,
>> Richard.
>
> --
> torben Hohn
>

[PATCH] Re: PowerPC : GCC2 optimises better than GCC4???

[Jakub Jelinek]

On Wed, Jan 06, 2010 at 10:15:58AM +, Andrew Haley wrote:
> On 01/06/2010 09:59 AM, Mark Colby wrote:
>  Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
> >>>
> >>> Probably because the RTL on x86_64 uses and's and ior's, but PPC uses
> >>> set's of zero_extract's (insvsi).
> >>
> >> Aha!  Yes, that'll probably be it.  It should be easy to fix cse to
> >> recognize those too.
> 
> > I'm not familiar with the gcc source yet, but just in case I get the
> > time to look at this, could anyone give me a file/line ref to dive
> > into and examine?
> 
> Would you believe cse.c?  :-)
> 
> I can't find the line without investigating further.
> 
> Andrew.
> 
> P.S.  This is a nontrivial task if you don't know gcc, but might be a
> good place for a beginner to start.  OTOH, might be hard: no way to
> know without digging.

I've digged a little bit and this optimizes the testcase on PowerPC 32-bit.
The patch is completely untested though.

On PowerPC 64-bit which apparently doesn't use ZERO_EXTRACT in this case I
see a different issue.  It generates
li 3,0
ori 3,3,32820
sldi 3,3,16
while IMHO 2 insns to load the constant would be completely sufficient,
apparently rs6000_emit_set_long_const needs work.
lis 3,0x8034
extsw 3,3
or
li 3,0x401a
sldi 3,3,17
etc. do IMHO the same.

2010-01-06  Jakub Jelinek  

* cse.c (cse_insn): Optimize lhs ZERO_EXTRACT if only CONST_INTs are
involved.

--- gcc/cse.c.jj2009-11-25 16:47:36.0 +0100
+++ gcc/cse.c   2010-01-06 16:00:41.0 +0100
@@ -4436,6 +4436,7 @@ cse_insn (rtx insn)
 
   for (i = 0; i < n_sets; i++)
 {
+  bool repeat = false;
   rtx src, dest;
   rtx src_folded;
   struct table_elt *elt = 0, *p;
@@ -5029,6 +5030,72 @@ cse_insn (rtx insn)
break;
}
 
+ /* Try to optimize
+(set (reg:M N) (const_int A))
+(set (reg:M2 O) (const_int B))
+(set (zero_extract:M2 (reg:M N) (const_int C) (const_int D))
+ (reg:M2 O)).  */
+ if (GET_CODE (SET_DEST (sets[i].rtl)) == ZERO_EXTRACT
+ && CONST_INT_P (trial)
+ && CONST_INT_P (XEXP (SET_DEST (sets[i].rtl), 1))
+ && CONST_INT_P (XEXP (SET_DEST (sets[i].rtl), 2))
+ && REG_P (XEXP (SET_DEST (sets[i].rtl), 0))
+ && (GET_MODE_BITSIZE (GET_MODE (SET_DEST (sets[i].rtl)))
+ >= INTVAL (XEXP (SET_DEST (sets[i].rtl), 1)))
+ && ((unsigned) INTVAL (XEXP (SET_DEST (sets[i].rtl), 1))
+ + (unsigned) INTVAL (XEXP (SET_DEST (sets[i].rtl), 2))
+ <= HOST_BITS_PER_WIDE_INT))
+   {
+ rtx dest_reg = XEXP (SET_DEST (sets[i].rtl), 0);
+ rtx width = XEXP (SET_DEST (sets[i].rtl), 1);
+ rtx pos = XEXP (SET_DEST (sets[i].rtl), 2);
+ unsigned int dest_hash = HASH (dest_reg, GET_MODE (dest_reg));
+ struct table_elt *dest_elt
+   = lookup (dest_reg, dest_hash, GET_MODE (dest_reg));
+ rtx dest_cst = NULL;
+
+ if (dest_elt)
+   for (p = dest_elt->first_same_value; p; p = p->next_same_value)
+ if (p->is_const && CONST_INT_P (p->exp))
+   {
+ dest_cst = p->exp;
+ break;
+   }
+ if (dest_cst)
+   {
+ HOST_WIDE_INT val = INTVAL (dest_cst);
+ HOST_WIDE_INT mask;
+ unsigned int shift;
+ if (BITS_BIG_ENDIAN)
+   shift = GET_MODE_BITSIZE (GET_MODE (dest_reg))
+   - INTVAL (pos) - INTVAL (width);
+ else
+   shift = INTVAL (pos);
+ if (INTVAL (width) == HOST_BITS_PER_WIDE_INT)
+   mask = ~(HOST_WIDE_INT) 0;
+ else
+   mask = ((HOST_WIDE_INT) 1 << INTVAL (width)) - 1;
+ val &= ~(mask << shift);
+ val |= (INTVAL (trial) & mask) << shift;
+ val = trunc_int_for_mode (val, GET_MODE (dest_reg));
+ validate_unshare_change (insn, &SET_DEST (sets[i].rtl),
+  dest_reg, 1);
+ validate_unshare_change (insn, &SET_SRC (sets[i].rtl),
+  GEN_INT (val), 1);
+ if (apply_change_group ())
+   {
+ rtx note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
+ if (note)
+   {
+ remove_note (insn, note);
+ df_notes_rescan (insn);
+   }
+ repeat = true;
+ break;
+   }
+   }
+   }
+
  /* We don't normally have an insn matching (set (pc) (pc)), so
 

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
> On Tue, Jan 5, 2010 at 5:39 PM, torbenh  wrote:
> > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
> >> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
> >> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> >> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
> >> >>
> >> >> The -fno-alias-X things do not make much sense for user code (they
> >> >> have been historically used from Frontends).  If restrict doesn't work
> >> >> for you (do you have a testcase that can reproduce your issue?)
> >> >> then you probably need to wait for IPA pointer analysis to be
> >> >> fixed in GCC 4.6.
> >> >
> >> > sorry... forget the attachment :S
> >>
> >> Yes, in this case you can fix it by making ramp static.  Otherwise its
> >> address may be takein in another translation unit.  For Fortran we
> >> have the DECL_RESTRICTED_P which we could expose to other
> >> languages via an attribute.  It tells that a decl is not aliased by
> >> restrict qualified pointers, so
> >>
> >> struct Ramp {
> >>     float phase;
> >>     inline float process() { return phase++; }
> >> } ramp __attribute__((restrict));
> >>
> >> void fill_buffer( float * __restrict buf, size_t nframes )
> >> {
> >>     for( size_t i=0; i >>         buf[i] = ramp.process();
> >> }
> >
> > would that also work with this stuff:
> >
> >
> > template
> > class Mixer;
> >
> > template
> > class Mixer : public Block
> > {
> >    private:
> >        T1 t1 __attribute__((restrict));
> >        Mixer t2;
> >    public:
> >        inline float process() {
> >            return t1.process() + t2.process();
> >        }
> > };
> >
> > template
> > class Mixer : public Block
> > {
> >    private:
> >        T1 t1 __attribute__((restrict));
> >        T2 t2 __attribute__((restrict));
> >    public:
> >        inline float process() {
> >            return t1.process() + t2.process();
> >        }
> > };
> >
> > Mixer mix __attribute__((restrict))

void fill_buffer( float * __restrict buf, size_t nframes )
{
    for( size_t i=0; i >
> > ?
> 
> I don't see a restrict qualified pointer here.  Note that the
> restrict attribute would only disambiguate against those.
> Also I think you need the restrict attribute on the Mixer
> objects, not its members.

so the attribute would promote down to all member vars of 
member objects ?


> > i still dont understand whats the problem with -fnolias,
> > as in attached patch.
> 
> The patch will miscompile everything.

point taken. 
obviously reading code for a few hours without knowing enough about the
code isnt enough :)

__attribute__((restrict)) is the better solution.
although not portable to other compilers. 

but i need this kind of functionality now, to test my concepts. 
thats why i am spending a bit time on this. 

when do you plan to add this feature ?
since you know the code, there would be no point for me to tackle
it if you do it soonish. 

(and you dont need to deal with dumb patches from me :)


speaking of dumb patches:

would you care to comment this patch for gcc-4.4 ?
this one seems to work for simple examples.

-- 
torben Hohn

Re: adding -fnoalias ... would a patch be accepted ?

[Richard Guenther]

On Wed, Jan 6, 2010 at 4:25 PM, torbenh  wrote:
> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
>> On Tue, Jan 5, 2010 at 5:39 PM, torbenh  wrote:
>> > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
>> >> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
>> >> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>> >> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
>> >> >>
>> >> >> The -fno-alias-X things do not make much sense for user code (they
>> >> >> have been historically used from Frontends).  If restrict doesn't work
>> >> >> for you (do you have a testcase that can reproduce your issue?)
>> >> >> then you probably need to wait for IPA pointer analysis to be
>> >> >> fixed in GCC 4.6.
>> >> >
>> >> > sorry... forget the attachment :S
>> >>
>> >> Yes, in this case you can fix it by making ramp static.  Otherwise its
>> >> address may be takein in another translation unit.  For Fortran we
>> >> have the DECL_RESTRICTED_P which we could expose to other
>> >> languages via an attribute.  It tells that a decl is not aliased by
>> >> restrict qualified pointers, so
>> >>
>> >> struct Ramp {
>> >>     float phase;
>> >>     inline float process() { return phase++; }
>> >> } ramp __attribute__((restrict));
>> >>
>> >> void fill_buffer( float * __restrict buf, size_t nframes )
>> >> {
>> >>     for( size_t i=0; i> >>         buf[i] = ramp.process();
>> >> }
>> >
>> > would that also work with this stuff:
>> >
>> >
>> > template
>> > class Mixer;
>> >
>> > template
>> > class Mixer : public Block
>> > {
>> >    private:
>> >        T1 t1 __attribute__((restrict));
>> >        Mixer t2;
>> >    public:
>> >        inline float process() {
>> >            return t1.process() + t2.process();
>> >        }
>> > };
>> >
>> > template
>> > class Mixer : public Block
>> > {
>> >    private:
>> >        T1 t1 __attribute__((restrict));
>> >        T2 t2 __attribute__((restrict));
>> >    public:
>> >        inline float process() {
>> >            return t1.process() + t2.process();
>> >        }
>> > };
>> >
>> > Mixer mix __attribute__((restrict))
>
> void fill_buffer( float * __restrict buf, size_t nframes )
> {
>     for( size_t i=0; i         buf[i] = mix.process();
> }
>
> there is your pointer :)

ok ;)

>> >
>> > ?
>>
>> I don't see a restrict qualified pointer here.  Note that the
>> restrict attribute would only disambiguate against those.
>> Also I think you need the restrict attribute on the Mixer
>> objects, not its members.
>
> so the attribute would promote down to all member vars of
> member objects ?

Yes.  In fact the example above would work I guess.

>
>> > i still dont understand whats the problem with -fnolias,
>> > as in attached patch.
>>
>> The patch will miscompile everything.
>
> point taken.
> obviously reading code for a few hours without knowing enough about the
> code isnt enough :)
>
> __attribute__((restrict)) is the better solution.
> although not portable to other compilers.
>
> but i need this kind of functionality now, to test my concepts.
> thats why i am spending a bit time on this.
>
> when do you plan to add this feature ?

For GCC 4.6 earliest.

> since you know the code, there would be no point for me to tackle
> it if you do it soonish.

It should be simple - just look into c-common.c, add this attribute
and in the handler, for VAR_DECLs simply set
DECL_RESTRICTED_P like:

static tree
handle_restrict_attribute (tree *node, ..., bool *no_add_attrs)
{
  if (TREE_CODE (*node) == VAR_DECL)
DECL_RESTRICTED_P (*node) = true;
  *no_add_attrs = true;
  return NULL_TREE;
}

> (and you dont need to deal with dumb patches from me :)
>
>
> speaking of dumb patches:
>
> would you care to comment this patch for gcc-4.4 ?
> this one seems to work for simple examples.

Which patch?

Richard.

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Wed, Jan 06, 2010 at 04:25:59PM +0100, torbenh wrote:
> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
> > On Tue, Jan 5, 2010 at 5:39 PM, torbenh  wrote:
> > > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
> > >> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
> > >> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> > >> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
> > >> >>
> > >> >> The -fno-alias-X things do not make much sense for user code (they
> > >> >> have been historically used from Frontends).  If restrict doesn't work
> > >> >> for you (do you have a testcase that can reproduce your issue?)
> > >> >> then you probably need to wait for IPA pointer analysis to be
> > >> >> fixed in GCC 4.6.
> > >> >
> > >> > sorry... forget the attachment :S
> > >>
> > >> Yes, in this case you can fix it by making ramp static.  Otherwise its
> > >> address may be takein in another translation unit.  For Fortran we
> > >> have the DECL_RESTRICTED_P which we could expose to other
> > >> languages via an attribute.  It tells that a decl is not aliased by
> > >> restrict qualified pointers, so
> > >>
> > >> struct Ramp {
> > >>     float phase;
> > >>     inline float process() { return phase++; }
> > >> } ramp __attribute__((restrict));
> > >>
> > >> void fill_buffer( float * __restrict buf, size_t nframes )
> > >> {
> > >>     for( size_t i=0; i > >>         buf[i] = ramp.process();
> > >> }
> > >
> > > would that also work with this stuff:
> > >
> > >
> > > template
> > > class Mixer;
> > >
> > > template
> > > class Mixer : public Block
> > > {
> > >    private:
> > >        T1 t1 __attribute__((restrict));
> > >        Mixer t2;
> > >    public:
> > >        inline float process() {
> > >            return t1.process() + t2.process();
> > >        }
> > > };
> > >
> > > template
> > > class Mixer : public Block
> > > {
> > >    private:
> > >        T1 t1 __attribute__((restrict));
> > >        T2 t2 __attribute__((restrict));
> > >    public:
> > >        inline float process() {
> > >            return t1.process() + t2.process();
> > >        }
> > > };
> > >
> > > Mixer mix __attribute__((restrict))
> 
> void fill_buffer( float * __restrict buf, size_t nframes )
> {
>     for( size_t i=0; i         buf[i] = mix.process();
> }
> 
> there is your pointer :)
> 
> > >
> > > ?
> > 
> > I don't see a restrict qualified pointer here.  Note that the
> > restrict attribute would only disambiguate against those.
> > Also I think you need the restrict attribute on the Mixer
> > objects, not its members.
> 
> so the attribute would promote down to all member vars of 
> member objects ?
> 
> 
> > > i still dont understand whats the problem with -fnolias,
> > > as in attached patch.
> > 
> > The patch will miscompile everything.
> 
> point taken. 
> obviously reading code for a few hours without knowing enough about the
> code isnt enough :)
> 
> __attribute__((restrict)) is the better solution.
> although not portable to other compilers. 
> 
> but i need this kind of functionality now, to test my concepts. 
> thats why i am spending a bit time on this. 
> 
> when do you plan to add this feature ?
> since you know the code, there would be no point for me to tackle
> it if you do it soonish. 
> 
> (and you dont need to deal with dumb patches from me :)
> 
> 
> speaking of dumb patches:
> 
> would you care to comment this patch for gcc-4.4 ?
> this one seems to work for simple examples.

meh... i always forget attachments :(
> 
> -- 
> torben Hohn

-- 
torben Hohn
diff --git a/gcc/common.opt b/gcc/common.opt
index 023d773..e02db8a 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -790,6 +790,10 @@ fnon-call-exceptions
 Common Report Var(flag_non_call_exceptions) Optimization
 Support synchronous non-call exceptions
 
+fnoalias
+Common Report Var(flag_noalias) Optimization
+Assume no aliasing is happening
+
 fomit-frame-pointer
 Common Report Var(flag_omit_frame_pointer) Optimization
 When possible do not generate stack frames
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index 4dd4fb7..35b6a99 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -2430,8 +2430,9 @@ compute_flow_insensitive_aliasing (struct alias_info *ai)
 
   FOR_EACH_REFERENCED_VAR (var, rvi)
 	{
-	  if (var_ann (var)->is_heapvar)
-	add_may_alias (tag, var);
+	  if (!flag_noalias)
+	if (var_ann (var)->is_heapvar)
+	  add_may_alias (tag, var);
 	}
 }
 
@@ -2949,6 +2950,9 @@ may_alias_p (tree ptr, alias_set_type mem_alias_set,
   return false;
 }
 
+  if (flag_noalias)
+return false;
+
   /* If -fargument-noalias-global is > 2, pointer arguments may
  not point to anything else.  */
   if (flag_argument_noalias > 2 && TREE_CODE (ptr) == PARM_DECL)

Re: adding -fnoalias ... would a patch be accepted ?

[Richard Guenther]

On Wed, Jan 6, 2010 at 4:45 PM, Richard Guenther
 wrote:
> On Wed, Jan 6, 2010 at 4:25 PM, torbenh  wrote:
>> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
>>> On Tue, Jan 5, 2010 at 5:39 PM, torbenh  wrote:
>>> > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
>>> >> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
>>> >> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>>> >> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
>>> >> >>
>>> >> >> The -fno-alias-X things do not make much sense for user code (they
>>> >> >> have been historically used from Frontends).  If restrict doesn't work
>>> >> >> for you (do you have a testcase that can reproduce your issue?)
>>> >> >> then you probably need to wait for IPA pointer analysis to be
>>> >> >> fixed in GCC 4.6.
>>> >> >
>>> >> > sorry... forget the attachment :S
>>> >>
>>> >> Yes, in this case you can fix it by making ramp static.  Otherwise its
>>> >> address may be takein in another translation unit.  For Fortran we
>>> >> have the DECL_RESTRICTED_P which we could expose to other
>>> >> languages via an attribute.  It tells that a decl is not aliased by
>>> >> restrict qualified pointers, so
>>> >>
>>> >> struct Ramp {
>>> >>     float phase;
>>> >>     inline float process() { return phase++; }
>>> >> } ramp __attribute__((restrict));
>>> >>
>>> >> void fill_buffer( float * __restrict buf, size_t nframes )
>>> >> {
>>> >>     for( size_t i=0; i>> >>         buf[i] = ramp.process();
>>> >> }
>>> >
>>> > would that also work with this stuff:
>>> >
>>> >
>>> > template
>>> > class Mixer;
>>> >
>>> > template
>>> > class Mixer : public Block
>>> > {
>>> >    private:
>>> >        T1 t1 __attribute__((restrict));
>>> >        Mixer t2;
>>> >    public:
>>> >        inline float process() {
>>> >            return t1.process() + t2.process();
>>> >        }
>>> > };
>>> >
>>> > template
>>> > class Mixer : public Block
>>> > {
>>> >    private:
>>> >        T1 t1 __attribute__((restrict));
>>> >        T2 t2 __attribute__((restrict));
>>> >    public:
>>> >        inline float process() {
>>> >            return t1.process() + t2.process();
>>> >        }
>>> > };
>>> >
>>> > Mixer mix __attribute__((restrict))
>>
>> void fill_buffer( float * __restrict buf, size_t nframes )
>> {
>>     for( size_t i=0; i>         buf[i] = mix.process();
>> }

Btw, the same effect can be obtained by instead writing

void fill_buffer( float * __restrict buf, size_t nframes )
{
 Mixer * restrict mixp = &mix;
 for( size_t i=0; iprocess();
}

at least in theory (if it doesn't work its worth to try to fix it).

Richard.

Re: adding -fnoalias ... would a patch be accepted ?

[Richard Guenther]

On Wed, Jan 6, 2010 at 4:45 PM, torbenh  wrote:
> On Wed, Jan 06, 2010 at 04:25:59PM +0100, torbenh wrote:
>> On Wed, Jan 06, 2010 at 02:27:15PM +0100, Richard Guenther wrote:
>> > On Tue, Jan 5, 2010 at 5:39 PM, torbenh  wrote:
>> > > On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
>> > >> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
>> > >> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>> > >> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
>> > >> >>
>> > >> >> The -fno-alias-X things do not make much sense for user code (they
>> > >> >> have been historically used from Frontends).  If restrict doesn't 
>> > >> >> work
>> > >> >> for you (do you have a testcase that can reproduce your issue?)
>> > >> >> then you probably need to wait for IPA pointer analysis to be
>> > >> >> fixed in GCC 4.6.
>> > >> >
>> > >> > sorry... forget the attachment :S
>> > >>
>> > >> Yes, in this case you can fix it by making ramp static.  Otherwise its
>> > >> address may be takein in another translation unit.  For Fortran we
>> > >> have the DECL_RESTRICTED_P which we could expose to other
>> > >> languages via an attribute.  It tells that a decl is not aliased by
>> > >> restrict qualified pointers, so
>> > >>
>> > >> struct Ramp {
>> > >>     float phase;
>> > >>     inline float process() { return phase++; }
>> > >> } ramp __attribute__((restrict));
>> > >>
>> > >> void fill_buffer( float * __restrict buf, size_t nframes )
>> > >> {
>> > >>     for( size_t i=0; i> > >>         buf[i] = ramp.process();
>> > >> }
>> > >
>> > > would that also work with this stuff:
>> > >
>> > >
>> > > template
>> > > class Mixer;
>> > >
>> > > template
>> > > class Mixer : public Block
>> > > {
>> > >    private:
>> > >        T1 t1 __attribute__((restrict));
>> > >        Mixer t2;
>> > >    public:
>> > >        inline float process() {
>> > >            return t1.process() + t2.process();
>> > >        }
>> > > };
>> > >
>> > > template
>> > > class Mixer : public Block
>> > > {
>> > >    private:
>> > >        T1 t1 __attribute__((restrict));
>> > >        T2 t2 __attribute__((restrict));
>> > >    public:
>> > >        inline float process() {
>> > >            return t1.process() + t2.process();
>> > >        }
>> > > };
>> > >
>> > > Mixer mix __attribute__((restrict))
>>
>> void fill_buffer( float * __restrict buf, size_t nframes )
>> {
>>     for( size_t i=0; i>         buf[i] = mix.process();
>> }
>>
>> there is your pointer :)
>>
>> > >
>> > > ?
>> >
>> > I don't see a restrict qualified pointer here.  Note that the
>> > restrict attribute would only disambiguate against those.
>> > Also I think you need the restrict attribute on the Mixer
>> > objects, not its members.
>>
>> so the attribute would promote down to all member vars of
>> member objects ?
>>
>>
>> > > i still dont understand whats the problem with -fnolias,
>> > > as in attached patch.
>> >
>> > The patch will miscompile everything.
>>
>> point taken.
>> obviously reading code for a few hours without knowing enough about the
>> code isnt enough :)
>>
>> __attribute__((restrict)) is the better solution.
>> although not portable to other compilers.
>>
>> but i need this kind of functionality now, to test my concepts.
>> thats why i am spending a bit time on this.
>>
>> when do you plan to add this feature ?
>> since you know the code, there would be no point for me to tackle
>> it if you do it soonish.
>>
>> (and you dont need to deal with dumb patches from me :)
>>
>>
>> speaking of dumb patches:
>>
>> would you care to comment this patch for gcc-4.4 ?
>> this one seems to work for simple examples.
>
> meh... i always forget attachments :(

Well, it's equally broken, so you'll get very interesting effects from such
a patch.

Richard.

Re: GCC aliasing rules: more aggressive than C99?

[Erik Trulsson]

On Wed, Jan 06, 2010 at 04:09:11AM +, Joshua Haberman wrote:
> Erik Trulsson  student.uu.se> writes:
> > On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
> > > The aliasing policies that GCC implements seem to be more strict than
> > > what is in the C99 standard.  I am wondering if this is true or whether
> > > I am mistaken (I am not an expert on the standard, so the latter is
> > > definitely possible).
> > >-
> > > The relevant text is:
> > >-
> > >   An object shall have its stored value accessed only by an lvalue
> > >   expression that has one of the following types:
> > >-
> > >   * a type compatible with the effective type of the object,
> > >   [...]
> > >   * an aggregate or union type that includes one of the aforementioned
> > > types among its members (including, recursively, a member of a
> > > subaggregate or contained union), or
> > >-
> > > To me this allows the following:
> > >-
> > >   int i;
> > >   union u { int x; } *pu = (union u*)&i;
> > >   printf("%d\n", pu->x);
> > >-
> > > In this example, the object "i", which is of type "int", is having its
> > > stored value accessed by an lvalue expression of type "union u", which
> > > includes the type "int" among its members.
> >-
> > Even with your interpretation of the C99 standard that example would be
> > allowed only if  '*pu' is a valid lvalue of type  'union u'.  (Since pu->x
> > is equivalent to (*pu).x)
> >-
> > First of all the conversion  (union u*)&i is valid only if the alignment
> > of 'i' is suitable for an object of type 'union u'.  Lets assume that is the
> > case. (Otherwise just making that conversion would result in undefined
> > behaviour.)  (See 6.3.2.3 clause 7.)
> 
> This is true.  You could get around this particular point by saying:
> 
>   int *i = malloc(sizeof(*i));
>   *i = 5;
>   union u { int x; } *pu = (union u*)i;
>   printf("%d\n", pu->x);
> 
> ...since the return from malloc() is guaranteed to be suitably aligned for
> any object (7.20.3).  But your point is taken.
> 
> > There is however no guarantee that the conversion yields a valid "pointer to
> > union u".  If not then dereferencing it (with the expression '*pu') has
> > undefined behaviour. (See 6.5.3.2 clause 4)
> 
> I think this is a bit of a stretch.  It is true that 6.5.3.2 says that
> dereferencing invalid values has undefined behavior.  But if you are
> saying that the standard has to explicitly say that a pointer conversion
> will not result in an invalid value (even when suitably aligned), then
> the following is also undefined:
> 
>   int i;
>   unsigned int *pui = (unsigned int*)&i;
>   unsigned int ui = *pui;
> 
> Andrew cited 6.3.2.3p2 as support for why this is defined, but that
> paragraph deals with qualifiers (const, volatile, and restrict).
> "unsigned" is not a qualifier.  There is no part of the standard that
> guarantees that a pointer conversion from "int*" to "unsigned int*" will
> not result in an invalid value.

(First I will assume that 'i' will be assigned some value, to make sure it
does not contain a trap-representation, or the assignment to 'ui' would have
undefined behaviour.)

I think 6.2.5 clause 27 is very relevant for this. It says that 'pointer to
int' and 'pointer to union' do not need to have the same representation as
each other.  It also seems that 'pointer to int' and 'pointer to unsigned
int' do not need to have the same representation requirements (at least I
cannot find anything that says that signed and unsigned variants are
compatible types.) (Which I must admit comes as a bit of a surprise to me.)

So, yes, that example does technically seem to be undefined (but I don't
know of any real-world implementation where it would not work as expected.)

> 
> > So your example contains undefined behaviour even without considering the
> > parts of 6.5 clause 7 that you quoted.
> >-
> > Moreover I think you are misinterpreting 6.5 clause 7 (which I concede is
> > fairly easy since it is not quite as unambiguous as one could wish).
> > I believe that paragraph should not be interpreted as automatically allowing
> > all accesses that correspond to one of the sorts listed.  Rather it should
> > be interpreted as saying that if an access is not included in that list then
> > it is not allowed, but even if it is included in that list there could be
> > other reasons why it is not allowed.  (I.e.  just as the attached footnote
> > suggests it is a list of what types of aliasing are allowed, not of which
> > pointers may be dereferenced.)
> 
> Interesting.  I think it is plausible that this is what the committee
> intended.  It like the committee wanted to give a heads-up to
> implementations that pointers to primitive types can alias pointers to
> those same types within unions and aggregates, just as a result of
> taking the address of a member.
> 
> In any case I definitely agree that this could be clarified, and I hope the
> standards committee will take this up for C1x.
> 
> Thank you fo

Re: GCC aliasing rules: more aggressive than C99?

[Robert Dewar]

Erik Trulsson wrote:


I think 6.2.5 clause 27 is very relevant for this. It says that 'pointer to
int' and 'pointer to union' do not need to have the same representation as
each other.  It also seems that 'pointer to int' and 'pointer to unsigned
int' do not need to have the same representation requirements (at least I
cannot find anything that says that signed and unsigned variants are
compatible types.) (Which I must admit comes as a bit of a surprise to me.)

So, yes, that example does technically seem to be undefined (but I don't
know of any real-world implementation where it would not work as expected.)


undefined = undefined

The notion of "work as expected" is a dangerous one, not to be
encouraged at all.

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Wed, Jan 06, 2010 at 04:49:29PM +0100, Richard Guenther wrote:
> On Wed, Jan 6, 2010 at 4:45 PM, Richard Guenther
>  wrote:
> > On Wed, Jan 6, 2010 at 4:25 PM, torbenh  wrote:
> >>> >
> >>> > Mixer mix __attribute__((restrict))
> >>
> >> void fill_buffer( float * __restrict buf, size_t nframes )
> >> {
> >>     for( size_t i=0; i >>         buf[i] = mix.process();
> >> }
> 
> Btw, the same effect can be obtained by instead writing
> 
> void fill_buffer( float * __restrict buf, size_t nframes )
> {
>  Mixer * restrict mixp = &mix;
>  for( size_t i=0; i  buf[i] = mix->process();
> }
> 
> at least in theory (if it doesn't work its worth to try to fix it).

in gcc-4.4 it doesnt work. didnt test with trunk yet.
but the text here suggests, that it should never work.
from gcc/alias.c get_alias_set (tree t):

  else if (AGGREGATE_TYPE_P (pointed_to_type))
/* For an aggregate, we must treat the restricted
   pointer the same as an ordinary pointer.  If we
   were to make the type pointed to by the
   restricted pointer a subset of the pointed-to
   type, then we would believe that other subsets
   of the pointed-to type (such as fields of that
   type) do not conflict with the type pointed to
   by the restricted pointer.  */
DECL_POINTER_ALIAS_SET (decl)
  = pointed_to_alias_set;

> 
> Richard.

-- 
torben Hohn

reghunt and "trunk" (GCC 4.5.x)?

[Gary Funck]

Hello, 

I'm trying to set up 'reghunt' to track down a change
in behavior from 2009-03-27 (4.4.3) to present.  This is
my first time setting up 'reghunt' - it is quite possible
that I still haven't got things set up properly.

I think that I've got the SVN bits, and most of the config.
settings as they shoold be, but when I try to run my test,
it fails trying to build 'cc1':

/bin/sh gcc-reg-hunt/reghunt/src/gcc/../move-if-change
tmp-options.h options.h
echo timestamp > s-options-h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh gcc-reg-hunt/reghunt/src/gcc/mkconfig.sh
bconfig.h
x86_64-redhat-linux-gcc -c  -g  -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-fno-common  -DHAVE_CO
NFIG_H -DGENERATOR_FILE -I. -Ibuild
-Igcc-reg-hunt/reghunt/src/gcc
-Igcc-reg-hunt/reghunt/src/gcc/build
-Igcc-reg-hunt/reghunt/src/gcc/../include
-Igcc-reg-hunt/reghunt/src/gcc/../libcpp/include
-Igcc-reg-hunt/reghunt/src/gcc/../libdecnumber
-Igcc-reg-hunt/reghunt/src/gcc/../libdecnumber/bid
-I../libdecnumber \
-o build/errors.o
gcc-reg-hunt/reghunt/src/gcc/errors.c
as: line 83: exec: : not found

(above, lines split for readability)

Above 'as' is a script, and at line 83 it is trying to
invoke the assembler, which indirectly will try to invoke
ORIGINAL_AS_FOR_TARGET, but that variable is empty:
ORIGINAL_AS_FOR_TARGET=""

I notice that the build script, 'reghunt/bin/gcc-build-simple does
some explicit configure/make steps:

#msg "configure"
${REG_GCCSRC}/configure \
--prefix=$REG_PREFIX \
--enable-languages=$REG_LANGS \
$REG_CONFOPTS \
  > configure.log 2>&1 || abort "  configure failed"

#msg "make libraries"
make all-build-libiberty > ${LOGDIR}/make.all-build-libiberty.log 2>&1 || true
make all-libcpp > ${LOGDIR}/make.all-libcpp.log 2>&1 || true
make all-libdecnumber > ${LOGDIR}/make.all-libdecnumber.log 2>&1 || true
make all-intl > ${LOGDIR}/make.all-intl.log 2>&1 || true
make all-libbanshee > ${LOGDIR}/make.all-libbanshee.log 2>&1 || true
make configure-gcc > ${LOGDIR}/make.configure-gcc.log  2>&1 || true

and then:
cd gcc
# REG_COMPILER is cc1, cc1plus, or f951
#msg "make $REG_COMPILER"
make $REG_MAKE_J $REG_COMPILER > ${LOGDIR}/make.${REG_COMPILER}.log 2>&1 \
  || abort "  make failed"
msg "build completed"

Which is where we're failing.

I know that in the past, I've had trouble building 'gcc' by first
explicitly running a make on its configure-gcc target, because it
seems that some other precursors might've been left out - and this
area of configuration/build may have experienced some subtle
changes over the past year/two.

I'm guessing that I need to chase a config./set up problem of some
sort, but my top-level question is:

Has anyone used 'reghunt' to find regressions in the current GCC "trunk"
dating back a year/so (in this case, using a "simple" build)?

I'd welcome any help/suggestsions, on setting up 'reghunt'.

thanks.

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Wed, Jan 06, 2010 at 04:45:06PM +0100, Richard Guenther wrote:
> >> I don't see a restrict qualified pointer here.  Note that the
> >> restrict attribute would only disambiguate against those.
> >> Also I think you need the restrict attribute on the Mixer
> >> objects, not its members.
> >
> > so the attribute would promote down to all member vars of
> > member objects ?
> 
> Yes.  In fact the example above would work I guess.

confirmed. works nicely.
although it would be nice, if this would also
apply to FIELD_DECL.

i am not sure if this is really possible.
is the structure hierarchy still available at that layer ?

thanks for your help so far.




> 
> >
> >> > i still dont understand whats the problem with -fnolias,
> >> > as in attached patch.
> >>
> >> The patch will miscompile everything.
> >
> > point taken.
> > obviously reading code for a few hours without knowing enough about the
> > code isnt enough :)
> >
> > __attribute__((restrict)) is the better solution.
> > although not portable to other compilers.
> >
> > but i need this kind of functionality now, to test my concepts.
> > thats why i am spending a bit time on this.
> >
> > when do you plan to add this feature ?
> 
> For GCC 4.6 earliest.

hmm... bah :)


-- 
torben Hohn

Re: GCC aliasing rules: more aggressive than C99?

[Nick Stoughton]

On Sun, 2010-01-03 at 10:31 -0800, Patrick Horgan wrote:
> Richard Guenther wrote:
> > On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman  wrote:
> >   
> >> ... elision by patrick of part of a quote of 6.5 Expressions #7...
> >>  * an aggregate or union type that includes one of the aforementioned
> >>types among its members (including, recursively, a member of a
> >>subaggregate or contained union), or
> >> 
> >
> > Literally interpreting this sentence the way you do removes nearly all
> > advantages of type-based aliasing that you have when dealing with
> > disambiguating a pointer dereference vs. an object reference
> > and thus cannot be the desired interpretation (and thus we do not allow 
> > this).
> >   
> Since it would be hard to read this any other way, it seems then you 
> maintain that you found a bug in the standard, has it been brought up to 
> the committee?  The latest draft I see still has that wording.  Doesn't 
> seem to be on the radar for C1x.  This same thing has bitten me, though 
> I agree with your rationale about how it would be a bad idea, still 
> strictly speaking, gcc is not standards compliant on this one point, and 
> rather than change gcc, the defect in the standard could be changed.  If 
> you don't have anyone participating on the committee right now, you only 
> have to convince some one who is, e.g. Nick Stoughton or P. J. Plauger 
> or Herb Sutter, right?

Herb is C++ ...

The C1x timetable has us finishing the draft for an initial ballot this
summer (the April Florence meeting being the last chance to submit new
material). The best expert I know on the type based aliasing stuff is
Clark Nelson at Intel (clark.nel...@intel.com). We did spend a
considerable amount of time at the recent Santa Cruz meeting discussing
this subject ... see N1409 and N1422 (the minutes including a summary of
the discussion on N1409).
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf

> 
> > It basically would force us to treat *ptr vs. Obj as *ptr vs. *(Obj *)ptr2.
> >
> > ...more elision
> >> I have seen other articles that interpret the standard in this way.
> >> See section "Casting through a union (2)" from this article, which
> >> claims that casts of this sort are legal and that GCC's warnings
> >> against them are false positives:
> >>  
> >> http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
> >> 
> >
> > Yes, this article contains many mistakes but the author failed to listen.
> >   
> This one thing is, you say, not a mistake of the author but a mistake in 
> the standard, and it's unkind to characterize it like that 
> > ...elided a bunch--patrick...
> > Correct.  GCC follows its own documentation here, not some random
> > websites and maybe not the strict reading of the standard.  There are
> > other corner-cases where it does so, namely with the union type rule
> > (which I fail to come up with a std reference at the moment).
> >   
> I hope in all of these cases it's been brought up as an issue, defects 
> in the standard won't get fixed if there are no squeaky wheels!
> 
> Patrick


-- 
Nick

Re: Why Thumb-2 only allows very limited access to the PC?

[Paul Brook]

On Wednesday 06 January 2010, Carrot Wei wrote:
> So thumb2 can also use the instructions similar to thumb1, right? It
> potentially has better performance and smaller code size.

Technically yes, however in ARMv7 the relevant instruction (add.n , pc) 
is deprecated.

Paul

Re: GCC aliasing rules: more aggressive than C99?

[Richard Guenther]

On Wed, Jan 6, 2010 at 7:20 PM, Nick Stoughton  wrote:
> On Sun, 2010-01-03 at 10:31 -0800, Patrick Horgan wrote:
>> Richard Guenther wrote:
>> > On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman  
>> > wrote:
>> >
>> >> ... elision by patrick of part of a quote of 6.5 Expressions #7...
>> >>  * an aggregate or union type that includes one of the aforementioned
>> >>    types among its members (including, recursively, a member of a
>> >>    subaggregate or contained union), or
>> >>
>> >
>> > Literally interpreting this sentence the way you do removes nearly all
>> > advantages of type-based aliasing that you have when dealing with
>> > disambiguating a pointer dereference vs. an object reference
>> > and thus cannot be the desired interpretation (and thus we do not allow 
>> > this).
>> >
>> Since it would be hard to read this any other way, it seems then you
>> maintain that you found a bug in the standard, has it been brought up to
>> the committee?  The latest draft I see still has that wording.  Doesn't
>> seem to be on the radar for C1x.  This same thing has bitten me, though
>> I agree with your rationale about how it would be a bad idea, still
>> strictly speaking, gcc is not standards compliant on this one point, and
>> rather than change gcc, the defect in the standard could be changed.  If
>> you don't have anyone participating on the committee right now, you only
>> have to convince some one who is, e.g. Nick Stoughton or P. J. Plauger
>> or Herb Sutter, right?
>
> Herb is C++ ...
>
> The C1x timetable has us finishing the draft for an initial ballot this
> summer (the April Florence meeting being the last chance to submit new
> material). The best expert I know on the type based aliasing stuff is
> Clark Nelson at Intel (clark.nel...@intel.com). We did spend a
> considerable amount of time at the recent Santa Cruz meeting discussing
> this subject ... see N1409 and N1422 (the minutes including a summary of
> the discussion on N1409).
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf

The case we are discussing here doesn't seem to be covered in that.
Let's modify Example 2 in 4.16 of n1422 to

struct S { int a; };
int i;
int f2 (struct S *ps, struct S s)
{
  *ps = s;
  return i;
}

can the compiler assume that i is not modified through the ps[i] lvalue?
Thus, is calling the above as

f2 ((struct S *)&pi, (struct S){ 1 });

valid?  6.5/7 point 5 may suggest that it is indeed valid, because
the lvalue is of type struct S which is an aggregate type and it
includes int as member which is a type compatible with the
effective type of the object.

What about the slightly different variant

struct S { int a; int b; };
int i;
int f2 (struct S *ps, struct S s)
{
  ps->a = s.a;
  return i;
}

GCC will in both cases assume that the store cannot alias i.

I have no idea on how to raise this issue with the std body, somebody
else might and can pass on the above example please.

Thanks,
Richard.

Re: GCC aliasing rules: more aggressive than C99?

[Patrick Horgan]

Nick Stoughton wrote:

Herb is C++ ...

The C1x timetable has us finishing the draft for an initial ballot this
summer (the April Florence meeting being the last chance to submit new
material). The best expert I know on the type based aliasing stuff is
Clark Nelson at Intel (clark.nel...@intel.com). We did spend a
considerable amount of time at the recent Santa Cruz meeting discussing
this subject ... see N1409 and N1422 (the minutes including a summary of
the discussion on N1409).
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf
  
I've read these, and while they deal with the same section of the 
standard, the issues are quite different.


Patrick

Re: GCC aliasing rules: more aggressive than C99?

[Joshua Haberman]

Richard Guenther  gmail.com> writes:
> On Wed, Jan 6, 2010 at 7:20 PM, Nick Stoughton  msbit.com> 
wrote:
> > The C1x timetable has us finishing the draft for an initial ballot this
> > summer (the April Florence meeting being the last chance to submit new
> > material). The best expert I know on the type based aliasing stuff is
> > Clark Nelson at Intel (clark.nelson  intel.com). We did spend a
> > considerable amount of time at the recent Santa Cruz meeting discussing
> > this subject ... see N1409 and N1422 (the minutes including a summary of
> > the discussion on N1409).
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf
> [...]
> I have no idea on how to raise this issue with the std body, somebody
> else might and can pass on the above example please.

In the notes that Nick referenced it says:

  Is there  anybody that thinks the rules are clear enough?  No one is
  really able to interpret them.  So it seems that they are not
  clear enough.  The problem is how to state them.

  [...]

  ACTION: Clark to work on a clearer formulation of what the rules are,
  re: N1409.

So it wounds like Clark is already working on this.  We should just write
to him and point him to this thread.  I can do this.

With regard to a clearer way to state the rules: I think the rules would
be easier to understand if the normative part only addressed the ways in
which object aliases could be *created*.  For example, the rules could
state that:

  struct A { int x; } a;
  int *pi = &a.x;

...is a valid way to create an int* that aliases a struct member, whereas:

  int i;
  struct A { int x; } *a = (struct u*)&i;

...is not.  Then an informative section could address the consequences of
those rules with respect to the assumptions you can make when optimizing
a function in isolation:

  type3 x;
  void foo(type1 *a, type2 *b) {
// can a and b alias each other?  can either of them alias x?
  }

The root of my confusion at least was thinking that the standard was
describing legal ways aliases could be created, but it was actually
describing what aliases could come to exist through other processes.

Since the rules governing how aliases may be created are simpler, it
makes sense to me to have the normative rules about alising describe the
creation of aliases, and then let compilers implement whatever
optimizations they can dream up that still respect those rules.

I also think the aliasing rules should more directly address the issue
raised in DR#236:
  http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm

Josh

Re: GCC aliasing rules: more aggressive than C99?

[Joshua Haberman]

Erik Trulsson  student.uu.se> writes:
> >   int i;
> >   unsigned int *pui = (unsigned int*)&i;
> >   unsigned int ui = *pui;
>
> (First I will assume that 'i' will be assigned some value, to make sure it
> does not contain a trap-representation, or the assignment to 'ui' would have
> undefined behaviour.)
>
> I think 6.2.5 clause 27 is very relevant for this. It says that 'pointer to
> int' and 'pointer to union' do not need to have the same representation as
> each other.  It also seems that 'pointer to int' and 'pointer to unsigned
> int' do not need to have the same representation requirements (at least I
> cannot find anything that says that signed and unsigned variants are
> compatible types.) (Which I must admit comes as a bit of a surprise to me.)
>
> So, yes, that example does technically seem to be undefined (but I don't
> know of any real-world implementation where it would not work as expected.)

I am wondering how, under this interpretation, an "int" and "unsigned
int" could ever alias each other, as 6.5p7 says they can.  I believe now
(especially after the notes Nick pointed us to) that your interpretation
of 6.5p7 is the intended one.  But if that is the case, then we should
expect to find some legal way in which "int" and "unsigned int" could
come to be aliased.  With your interpretation about pointer conversions,
I don't see how this could be.

Josh

Re: GCC aliasing rules: more aggressive than C99?

[Erik Trulsson]

On Wed, Jan 06, 2010 at 07:29:21PM +, Joshua Haberman wrote:
> Erik Trulsson  student.uu.se> writes:
> > >   int i;
> > >   unsigned int *pui = (unsigned int*)&i;
> > >   unsigned int ui = *pui;
> >
> > (First I will assume that 'i' will be assigned some value, to make sure it
> > does not contain a trap-representation, or the assignment to 'ui' would have
> > undefined behaviour.)
> >
> > I think 6.2.5 clause 27 is very relevant for this. It says that 'pointer to
> > int' and 'pointer to union' do not need to have the same representation as
> > each other.  It also seems that 'pointer to int' and 'pointer to unsigned
> > int' do not need to have the same representation requirements (at least I
> > cannot find anything that says that signed and unsigned variants are
> > compatible types.) (Which I must admit comes as a bit of a surprise to me.)
> >
> > So, yes, that example does technically seem to be undefined (but I don't
> > know of any real-world implementation where it would not work as expected.)
> 
> I am wondering how, under this interpretation, an "int" and "unsigned
> int" could ever alias each other, as 6.5p7 says they can.  I believe now
> (especially after the notes Nick pointed us to) that your interpretation
> of 6.5p7 is the intended one.  But if that is the case, then we should
> expect to find some legal way in which "int" and "unsigned int" could
> come to be aliased.  With your interpretation about pointer conversions,
> I don't see how this could be.

Would not the following be a legal way of having that happen:


 #include 
 void foo(int *i, unsigned int *ui)
 {
...

 }

 int main(void)
 {  
 void *pv;
 int *pi;
 unsigned int *pui;


  pv=malloc(sizeof(int));  /* Assume that the malloc succeeds */

  pi = pv;
  pui = pv;

  foo(pi, pui);

  }

I believe that is legal code where '*i' and '*ui' would refer to the same
object (i.e.  be aliased).  (See 6.5p6 and 6.5p7)


-- 

Erik Trulsson
ertr1...@student.uu.se

Re: reghunt and "trunk" (GCC 4.5.x)?

[Ian Lance Taylor]

Gary Funck  writes:

> Above 'as' is a script, and at line 83 it is trying to
> invoke the assembler, which indirectly will try to invoke
> ORIGINAL_AS_FOR_TARGET, but that variable is empty:
> ORIGINAL_AS_FOR_TARGET=""
>
> I notice that the build script, 'reghunt/bin/gcc-build-simple does
> some explicit configure/make steps:

I think you need to make sure that the script removes any existing
config.cache files.

Ian

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Roland McGrath]

> > Feel free to send some gcc patches.  I see no point in this.
> > We have -Wl.
> 
> I deal with a lot of host systems where shell scripts aren't a viable
> option for ld.  Why make everyone write the wrapper script?  Makes
> sense to me to have gcc decide.

Like I said, I don't object to any new gcc hacks people want to do.  Nor to
people just choosing directories for .../ld symlinks in their packaging and
using -B.  I just don't really care about that.  The --enable-gold=both
installation setup is enough for me and I don't want merging that delayed
any more because of discussing more ideas we might add on top.


Thanks,
Roland

Re: Why Thumb-2 only allows very limited access to the PC?

[Carrot Wei]

Does "deprecated" mean it works currently but may not work in future versions?

In chapter A8.6.6 of document
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406b/index.html
I can't find it is mentioned that (add.n , pc) is deprecated.

thanks
Carrot

On Thu, Jan 7, 2010 at 2:26 AM, Paul Brook  wrote:
> On Wednesday 06 January 2010, Carrot Wei wrote:
>> So thumb2 can also use the instructions similar to thumb1, right? It
>> potentially has better performance and smaller code size.
>
> Technically yes, however in ARMv7 the relevant instruction (add.n , pc)
> is deprecated.
>
> Paul
>

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-06 16:52:50 +0100, Erik Trulsson wrote:
> On Wed, Jan 06, 2010 at 04:09:11AM +, Joshua Haberman wrote:
> > I think this is a bit of a stretch.  It is true that 6.5.3.2 says that
> > dereferencing invalid values has undefined behavior.  But if you are
> > saying that the standard has to explicitly say that a pointer conversion
> > will not result in an invalid value (even when suitably aligned), then
> > the following is also undefined:
> > 
> >   int i;
> >   unsigned int *pui = (unsigned int*)&i;
> >   unsigned int ui = *pui;
> > 
> > Andrew cited 6.3.2.3p2 as support for why this is defined, but that
> > paragraph deals with qualifiers (const, volatile, and restrict).
> > "unsigned" is not a qualifier.  There is no part of the standard that
> > guarantees that a pointer conversion from "int*" to "unsigned int*" will
> > not result in an invalid value.
> 
> (First I will assume that 'i' will be assigned some value, to make sure it
> does not contain a trap-representation, or the assignment to 'ui' would have
> undefined behaviour.)
> 
> I think 6.2.5 clause 27 is very relevant for this. It says that 'pointer to
> int' and 'pointer to union' do not need to have the same representation as
> each other.  It also seems that 'pointer to int' and 'pointer to unsigned
> int' do not need to have the same representation requirements (at least I
> cannot find anything that says that signed and unsigned variants are
> compatible types.) (Which I must admit comes as a bit of a surprise to me.)

I don't see why representations of pointers would matter here.
What's important is the representations of int and unsigned int
(and unions, in other examples), not pointers.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Why Thumb-2 only allows very limited access to the PC?

[Laurent Desnogues]

On Thu, Jan 7, 2010 at 2:10 AM, Carrot Wei  wrote:
> Does "deprecated" mean it works currently but may not work in future versions?
>
> In chapter A8.6.6 of document
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406b/index.html
> I can't find it is mentioned that (add.n , pc) is deprecated.

As far as I know it isn't deprecated.  Or I failed to find anything
saying it is :-)


Laurent