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 a
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_regis
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 wh
>>> 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 fam
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.
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
>>> 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!
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:
>> >>
>
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).
>
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 Gue
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 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 wr
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 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 wrot
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 wonderin
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 r
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 )
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
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.
> >
> > s
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
>
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
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 a
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
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 t
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 beh
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 cont
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 e
> > 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
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,
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
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
31 matches
Mail list logo
