Hello,
Trunk currently fails to bootstrap with SMS flags on ARM machine. (I'm
using -r175900. btw, -r175091 bootstrap OK)
Investigating the problem; it seems that the cause is not related to
SMS but rather to the doloop optimization which is enabled only when
SMS flags are set. (but that also does
On Mon, Jul 18, 2011 at 21:00, Gabriel Charette wrote:
> We probably only want to enforce this for a subset of the flags (i.e.
> we don't care about flags like -Wall and stuff like that, but only
> about the flags actually affecting the binary output).
In principle, this is no different than mix
On Mon, Jul 18, 2011 at 5:52 PM, Diego Novillo wrote:
> On Mon, Jul 18, 2011 at 20:45, Gabriel Charette wrote:
>> To demonstrate my point:
>> add /* { dg-options "-ffinite-math-only -fno-math-errno" } */
>> to c1builin-integral.cc
>>
>> and watch the test pass (since now we are using the flags ac
On Mon, Jul 18, 2011 at 20:45, Gabriel Charette wrote:
> To demonstrate my point:
> add /* { dg-options "-ffinite-math-only -fno-math-errno" } */
> to c1builin-integral.cc
>
> and watch the test pass (since now we are using the flags across all
> compilations).
Ah, OK. That's your fix then.
Di
On Mon, Jul 18, 2011 at 20:29, Gabriel Charette wrote:
> so the asm diff we are seeing in c1builtin-integral is not something
> we are not streaming out, or any other logic being wrong in the pph.
>
> The problem is: we define a dg-options entry in the header file which
> tells deja-gnu to add fl
To demonstrate my point:
add /* { dg-options "-ffinite-math-only -fno-math-errno" } */
to c1builin-integral.cc
and watch the test pass (since now we are using the flags across all
compilations).
Or similarly, remove the same dg-options entry from
c0builtin-integral.h and watch the test pass (sinc
Hey guys,
so the asm diff we are seeing in c1builtin-integral is not something
we are not streaming out, or any other logic being wrong in the pph.
The problem is: we define a dg-options entry in the header file which
tells deja-gnu to add flags to the compilation (so far so good...)
The problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/11 15:20, dpadgett_mail-...@yahoo.com wrote:
> Hello,
>
> Does gcc IRA provide a mechanism to support spilling to registers
> instead of the stack? For the particular target I'm looking at,
> there are some non-general-purpose registers that
Hello,
Does gcc IRA provide a mechanism to support spilling to registers instead of
the stack? For the particular target I'm looking at, there are some
non-general-purpose registers that can be copied to and from more quickly than
the stack, so would be preferable to use as a form of shareable
On 07/18/2011 10:29 AM, Paul Koning wrote:
> Why an add instruction? Is that in the case where address arithmetic
> requires separate adds?
I don't recall. Probably to do with some edge case of reloading addresses.
I know that this affects m68k, which is even CISC-y-er in its addressing
modes th
Cool, happy hacking
--Phil
Thank you very much!
Apparently, it's best to communicate&contribute here with one's real name.
So, here it is: Franck Louarn.
I'm trying to update my e-mail accounts so that I'm no longer identified
here as Franck Z. If I fail, I'll start again with another add
On Jul 18, 2011, at 12:53 PM, Richard Henderson wrote:
> On 07/18/2011 08:01 AM, Paulo J. Matos wrote:
>> The problem is, if addhi3 expands into two insn:
>> (define_insn "addqi3"
>> [(set (match_operand:HI 0 "nonimmediate_operand" "=c")
>> (plus:HI (match_operand:HI 1 "general_operand"
"Paulo J. Matos" writes:
> Where the format specifiers b and t choose the top and bottom 16 bits
> of each operand. add is a 16bit addition operand and addc takes carry
> flag into consideration. Now, there are a lot of simple manipulations
> that can be made if I release GCC from always outputti
On 07/18/2011 08:01 AM, Paulo J. Matos wrote:
> The problem is, if addhi3 expands into two insn:
> (define_insn "addqi3"
>[(set (match_operand:HI 0 "nonimmediate_operand" "=c")
> (plus:HI (match_operand:HI 1 "general_operand" "%0")
> (match_operand:HI 2 "general_opera
This is the beta release of binutils 2.21.53.0.1 for Linux, which is
based on binutils 2011 0716 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Hello,
I am trying to size-optimise one of our instructions. That's addhi3.
HImode is 32 bits and QImode is 16bits, which is what our processor
instructions work with.
So generally an addhi3 looks like:
(define_insn "addhi3"
[(set (match_operand:HI 0 "nonimmediate_operand" "=c")
(
On Mon, Jul 18, 2011 at 4:58 AM, Rohit Arul Raj wrote:
>
> Is this expected behavior?
>
>
yes
Hi,
On Thu, 14 Jul 2011, Mikael Morin wrote:
> Couldn't we simulate the desired behaviour with more than one decl, one of
> them const qualified? Like so:
>
> void
> sub (int *restrict non_aliasing_var)
> {
>*non_aliasing_var = 5;
>{
> const int *non_aliasing_var_tmp = non_aliasin
On 07/17/2011 08:26 PM, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
promoted Vladimir Makarov to Register Allocation Maintainer.
Please join me in congratulating Vlad.
Please update your listing in the MAINTAINERS file.
Happy hacking!
David
Hi,
On Sat, 16 Jul 2011, Richard Guenther wrote:
> > Did you really want to say this? Because I'm very sure we actually
> > loose very much in real-world performance if we wouldn't be using it
> > (or some alterntive that is specified somewhat cleaner).
>
> I meant to say if we are not using
On Fri, Jul 8, 2011 at 8:03 PM, Khem Raj wrote:
> On Fri, Jul 8, 2011 at 1:08 AM, Rohit Arul Raj wrote:
>> On Wed, Mar 23, 2011 at 5:55 PM, Joseph S. Myers
>> wrote:
>>> On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
>>>
Hello All,
I have been trying to build a cross compiler (for Pow
Hello All
I just merged trunk into the MELT branch.
(you probably will need to rebuild the branch in a fresh build tree)
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, F
22 matches
Mail list logo
