On Sat, Aug 6, 2011 at 5:00 PM, Paolo Bonzini wrote:
> On 08/04/2011 01:10 PM, Andrew Haley wrote:
>> It's the sort of thing that gets done in threaded interpreters,
>> where you really need to keep a few pointers in registers and
>> the interpreter itself is a very long fun
On Fri, Aug 05, 2011 at 09:32:05AM +0200, Richard Guenther wrote:
> Well, but unless your training coverage is 100% all parts with no coverage
> get optimized with -O3 instead of -Os. And I bet coverage for mozilla
> isn't even close to 100%. Thus I think recommending -O3 for FDO is
> usually a b
Ayal Zaks writes:
>> OK. For the follow-on iv patch, it seemed easier to keep both bounds
>> inclusive for the loop, then make the "end" exclusive when setting the
>> out parameters. (Note that there shouldn't be any problem with overflow
>> when making the bound exclusive, because the size of t
Hi there! We just raised a new mirror in US, Missouri, Saint Louis.
It has 100Mb/s connection and synced twice a day from main site gcc.gnu.org
URL of mirror is: gcc.petsads.us
My email s.kutse...@gmail.com
My name is Sergey Kutserey
Hopefully you can add this mirror into public mirror list for GC
On 08/08/2011 10:06 AM, Richard Guenther wrote:
Like if
register unsigned char *ip;
would increase spill cost of ip compared to
unsigned char *ip;
?
Remember we're talking about a function with 11000 pseudos and 4000
allocnos (not to mention a 1500 basic blocks). You cannot really blame
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>> Ulrich Weigand wrote:
>>> This means that problems like the one you're seeing have been hidden
>>> so far. I've started looking into fixing this, but since I don't
>>> have a target where this is needed, this effort never really went
>>> anywhere.
On Mon, Aug 08, 2011 at 11:25:56AM +0200, Mike Hommey wrote:
> On Fri, Aug 05, 2011 at 09:32:05AM +0200, Richard Guenther wrote:
> > Well, but unless your training coverage is 100% all parts with no coverage
> > get optimized with -O3 instead of -Os. And I bet coverage for mozilla
> > isn't even c
On Thu, Aug 04, 2011 at 08:51:41PM +0200, Jan Hubicka wrote:
> > +Mark who has done size optimization tuning with FDO.
> >
> > On Thu, Aug 4, 2011 at 7:05 AM, Mike Hommey wrote:
> > > Hi,
> > >
> > > We (Mozilla) are trying to get the best of the ARM toolchain for our
> > > Android build. I recen
Uros Bizjak wrote:
> Although, it would be nice for reload to subsequently fix CSE'd
> non-offsetable memory by copying address to temporary reg (*as said in
> the documentation*), we could simply require an XMM temporary for
> TImode reloads to/from integer registers, and this fixes ICE for x32.
On 8 August 2011 13:20, Mike Hommey wrote:
>
> I unfortunately hit several problems with gcc 4.7 (latest snapshot).
> One is bug 50022 that I filed today.
>
> Another is the following error in stlport headers:
> error: invalid use of incomplete type 'std::string {aka struct
> std::basic_string, s
On Mon, Aug 8, 2011 at 5:30 PM, Ulrich Weigand wrote:
> Uros Bizjak wrote:
>
>> Although, it would be nice for reload to subsequently fix CSE'd
>> non-offsetable memory by copying address to temporary reg (*as said in
>> the documentation*), we could simply require an XMM temporary for
>> TImode r
On Mon, Aug 8, 2011 at 10:11 AM, Uros Bizjak wrote:
> On Mon, Aug 8, 2011 at 5:30 PM, Ulrich Weigand wrote:
>> Uros Bizjak wrote:
>>
>>> Although, it would be nice for reload to subsequently fix CSE'd
>>> non-offsetable memory by copying address to temporary reg (*as said in
>>> the documentation
Hi
Le 16 juil. 2011 à 08:52, Ian Lance Taylor a écrit :
> I would like to propose this patch as a step toward building gcc using a
> C++ compiler. This patch builds stage1 with the C compiler as usual,
> and defaults to building stages 2 and 3 with a C++ compiler built during
> stage 1. This me
Romain Geissler writes:
> This new build behavior broke former plugins built with gcc. Indeed,
> all cc1 function symbols are now mangled and thus with the current
> trunk, plugins should also look for mangled symbols (and so built
> with g++).
>
> What's the new GCC policy about that ? Do plugin
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
Ulrich Weigand wrote:
This is pretty much working as expected. "pallo" is a string literal
which (always) resides in the default address space. According to the
named address space specification (TR 18037) there are no string literals
in non-d
2011/8/8 Richard Sandiford
>
> Ayal Zaks writes:
> >> OK. For the follow-on iv patch, it seemed easier to keep both bounds
> >> inclusive for the loop, then make the "end" exclusive when setting the
> >> out parameters. (Note that there shouldn't be any problem with overflow
> >> when making th
Le 8 août 2011 à 20:49, Ian Lance Taylor a écrit :
>
> However, since we currently permit plugins to call anything in gcc, I
> think the answer is going to have to be that plugins which do that
> should be compiled with C++.
Ok, i'll move to C++ then, until a dedicated C plugin API comes out.
>
On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka wrote:
>> >
>> > In a way I like the current scheme since it is simple and extending it
>> > should IMO have some good reason. We could refine -Os behaviour without
>> > changing current predicates to optimize for speed in
>> > a) functions declared as "
> On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka wrote:
> >> >
> >> > In a way I like the current scheme since it is simple and extending it
> >> > should IMO have some good reason. We could refine -Os behaviour without
> >> > changing current predicates to optimize for speed in
> >> > a) functions d
19 matches
Mail list logo
