On Sat, Sep 8, 2012 at 7:17 AM, Uros Bizjak wrote:
> There are some other cpuid vendor signatures than AMD and Intel,
How about a patch with this complete list?
d-gcc-cpuid-signature
Description: Binary data
Hans-Peter Nilsson schrieb:
Oleg Endo wrote:
Georg-Johann Lay wrote:
The change is definitely in the right direction, but I wonder
how it helps to fix code bloats of 300%-400% as in PR52543?
I'm not familiar with the AVR parts.
BTW, There was a small change in lower-subreg which required some
The attached patch improves the cost estimate for multiplication, etc,
on parisc. It was noted debugging various PRs that the cost for multiplication
of long longs was seriously underestimated.
Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu.
Committed to trunk.
D
Hi,
I've added a libjava unittest which verifies that this patch will not
break Java debug info. I've also incorporated Richard's review in the
previous mail. Attached is the new patch, which passed bootstrap and
all gcc/libjava testsuites on x86.
Is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog
As mentioned in
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01364.html
GCC now is performing optimizations in binds_local_p() that
necessitates adding -fPIC when compiling objects for shared libraries
on AIX. The libtool patch has been accepted upstream.
-fPIC creates unique names for some wea
Oleg Endo wrote:
> On Thu, 2012-09-06 at 14:41 +0200, Georg-Johann Lay wrote:
> > The change is definitely in the right direction, but I wonder
> > how it helps to fix code bloats of 300%-400% as in PR52543?
>
> I'm not familiar with the AVR parts.
> BTW, There was a small change in lower-subreg wh
On Sat, 8 Sep 2012, Mark Kettenis wrote:
> I don't have commit access (or at least I'm not on the write after
> approval list). Would you (or somebody else) be so kind to commit
> this fix for me?
I'll take care of it.
Gerald
On Sat, Sep 08, 2012 at 02:37:18PM -0400, Hans-Peter Nilsson wrote:
> On Thu, 6 Sep 2012, Andi Kleen wrote:
>
> > From: Andi Kleen
>
> > Passed bootstrap and testsuite on x86_64.
>
> > +++ b/gcc/lto/lto.c
> > @@ -2016,6 +2016,8 @@ do_whole_program_analysis (void)
> >/* Show the LTO report b
On Thu, 6 Sep 2012, Andi Kleen wrote:
> From: Andi Kleen
> Passed bootstrap and testsuite on x86_64.
> +++ b/gcc/lto/lto.c
> @@ -2016,6 +2016,8 @@ do_whole_program_analysis (void)
>/* Show the LTO report before launching LTRANS. */
>if (flag_lto_report)
> print_lto_report ();
> +
> Date: Fri, 07 Sep 2012 14:12:29 -0400
> From: Jason Merrill
>
> OK, thanks.
I don't have commit access (or at least I'm not on the write after
approval list). Would you (or somebody else) be so kind to commit
this fix for me?
Thanks,
Mark
Don't have time to look at this in detail, but FWIW:
Steve Ellcey writes:
> On Wed, 2012-09-05 at 08:15 +0200, Jakub Jelinek wrote:
>> On Fri, Aug 31, 2012 at 10:58:51AM -0700, Steve Ellcey wrote:
>> > Here is my patch to fix the bootstrap comparision failure (PR 54128) on
>> > MIPS. The reason
On Sat, Sep 8, 2012 at 7:17 AM, Uros Bizjak wrote:
> There are some other cpuid vendor signatures than AMD and Intel, and
> probably there will be some more.
Sure, if there are still people using those they can easily add those.
> IMO, anybody using __get_cpuid_max
> call should define accepted
Steve Ellcey writes:
> On Fri, 2012-09-07 at 07:52 +0100, Richard Sandiford wrote:
>
>> MIPS_ABI_DEFAULT and MIPS_ISA_DEFAULT are better set in config.gcc.
>> That also allows you to handle (say) mipsisa32-mti-linux-gnu vs.
>> mipsisa64-mti-linux-gnu.
>>
>> I think in general we want more specifi
While examining the Power MD file seeking the explanation for a problem I
saw I have noticed a change in the past separated one of the instruction
splitters from its corresponding instruction pattern. Several unrelated
patterns were inserted between the two, presumably by accident where the
`patc
Hello!
> The x86 cpuid instruction returns a processor ID and the
> __get_cpuid_max function even explicitly makes the %ebx value directly
> available. But users of that function have to use a cryptic constant.
> How about adding a few macros to make this more transparent?
There are some other
On Mon, 3 Sep 2012, Richard Guenther wrote:
Please do the early outs where you compute the arguments. Thus, right
after getting op0 in this case or right after computing n for the n != 1 check.
I think you need to verify that the type of 'op' is actually the element type
of op0. The BIT_FIELD
On Mon, 3 Sep 2012, Richard Guenther wrote:
You do work above and then bail late here. Always do early exists early
to reduce useless compile-time.
[...]
You need to verify that fold_ternary returns something that is valid GIMPLE.
fold () in general happily returns trees that are in the need
17 matches
Mail list logo
