Quoting DJ Delorie :
I was talking about what addresses are allowed by the
TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
what the register allocator is guided to produce; some optimizers
can get quite 'creative' in mashing rtl together.
I've never seen it actually do that
> I was talking about what addresses are allowed by the
> TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
> what the register allocator is guided to produce; some optimizers
> can get quite 'creative' in mashing rtl together.
I've never seen it actually do that and get it past th
Swing-ul exista de pe vremea romanilor si a intrat in istorie sub denumirea de
Orgiile Romane. De-a lungul timpului a luat diferite denumiri si infatisari, in
anii 60 se numea wife-swapping â schimb de nevasta si era mai mult controlat
de catre barbatul care opta pentru a negocia schimbul neve
Quoting DJ Delorie :
m32c.c:m32c_legitimate_address_p allows any rubbish inside a
PRE_MODIFY, as long as the address register is the stack pointer.
OTOH, it does not define any HAVE_*_MODIFY_* macro.
m32c has push/pop and no other pre/post modify
I was talking about what addresses are allow
Thanks a lot !
--
TAKAHASHI Kohei
On 26/10/11 02:00, Gerald Pfeifer wrote:
On Mon, 24 Oct 2011, Kohei Takahashi wrote:
I'm GCC mirror admin of ftp.tsukuba.wide.ad.jp. Could you change my mail
address of mirror lists to tsukuba-ftp-serv...@tsukuba.wide.ad.jp ?
Sure, just done by means of the
> m32c.c:m32c_legitimate_address_p allows any rubbish inside a
> PRE_MODIFY, as long as the address register is the stack pointer.
> OTOH, it does not define any HAVE_*_MODIFY_* macro.
m32c has push/pop and no other pre/post modify
Quoting amyl...@spamcop.net:
The issue with this patch is that we'll have to check if gen_add3_insn might
fail on any target, and also we have to identify on which targets it will
create an insn that clobbers potentially live hard registers
(like a flags register), and make the substitution fail
Snapshot gcc-4.4-20111025 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20111025/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
"Hammer, Tim" writes:
> About 3 years ago (August, 2008) there was a discussion here about (not)
> getting a backtrace from abort(3) on ARM:
> http://gcc.gnu.org/ml/gcc/2008-08/msg00060.html
>
> That thread discussed why core files generated from a call to abort() do not
> have a stack to
About 3 years ago (August, 2008) there was a discussion here about (not)
getting a backtrace from abort(3) on ARM:
http://gcc.gnu.org/ml/gcc/2008-08/msg00060.html
That thread discussed why core files generated from a call to abort() do not
have a stack to review and some possible approach
On Mon, 24 Oct 2011, Kohei Takahashi wrote:
> I'm GCC mirror admin of ftp.tsukuba.wide.ad.jp. Could you change my mail
> address of mirror lists to tsukuba-ftp-serv...@tsukuba.wide.ad.jp ?
Sure, just done by means of the patch below. Thanks for letting us
know!
Gerald
Index: mirrors.html
=
On Tue, 25 Oct 2011, Frederic Riss wrote:
> When I read the paragraph on expression contraction, it seems that a
> lot of liberty is left to the implementation wrt the kind of
> contraction it does. The footnotes even talk about different accuracy,
> loss of predictability and fast machine specifi
On 25 October 2011 16:45, Joseph S. Myers wrote:
> On Tue, 25 Oct 2011, Frederic Riss wrote:
> Contracting (which is independent from excess precision) is controlled by
> -ffp-contract. This can operate at the very latest at the GIMPLE level
> (it needs to know about original expression boundarie
Kai Tietz wrote:
> 2011/10/24 Bob Breuer :
>> Kai Tietz wrote:
>>> Hi,
>>>
>>> For trunk-version I have a tentative patch for this issue. On 4.6.x
>>> and older branches this doesn't work, as here we can't differenciate
>>> that easy between ms- and sysv-abi.
>>>
>>> But could somebody give this p
On Tue, 25 Oct 2011, Frederic Riss wrote:
> Some time ago, I tried to read the C standard to see what ports were
> authorized to do with regard to that kind of issues. I (most
> certainly wrongly) came to the conclusion that it was conformant to
> generate an insn doing (set x (mul:DF (float_ext
> > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
> > allows us in particular to use dwarf-2/3 debug info.
>
> Is AdaCore maintaining GNU Binutils on AIX?
We're "maintaining" it sufficiently for our needs, yes.
> I do not believe that
> Binutils implements some toolchai
On Tue, Oct 25, 2011 at 4:15 AM, Arnaud Charlet wrote:
>> I wonder if it might make sense to more strongly suggest to use GNU as
>> on AIX? The install manual currently says
>>
>> The native @command{as} and @command{ld} are recommended for
>> bootstrapping
>> on AIX@. The GNU Assembler, GNU Lin
On Mon, 24 Oct 2011 16:04:02 +0100, Nick Clifton wrote:
> Hi Ben,
>
> > To my
> > surprise, I found that the compiler instead[2] produced the deprecated
> > R_ARM_PLT32 relocation. Considering the deprecated state of this
> > relocation type, should this be considered a bug?
>
> Yes...
>
> > Be
> cc1-checksum.o main.o libbackend.a ../libcpp/libcpp.a
> ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a
> ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
> -L/opt/bw/lib/sparcv8 -L/opt/bw/lib/sparcv8 -L/opt/bw/lib/sparcv8 -lmpc
> -lmpfr -lgmp -ldl -L../zlib -lz
>
Thanks, Andrew. I also implemented a quick patch on our port (based on GCC
4.5).
I noticed it produced better code now for our applications. Maybe eliminating
control flow in earlier stage helps other optimizing passes. Currently, tree
if-conversion pass is not turned on by default (only with tr
[ warning - obscenely long with no lack of detail ]
I was very surprised to see the following in my bootstrap of
gcc-4.6.2-RC-20111019-build at stage two :
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/xgcc
-B/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/
-B/opt/bw/sparc-sun-s
With the following, small C test program
typedef struct
{
unsigned char a, b, c, d;
} s_t;
unsigned char func1 (s_t *x, s_t *y, s_t *z)
{
unsigned char s = 0;
s += x->a;
s += y->a;
s += z->a;
s += x->b;
s += y->b;
s += z->b;
s += x->c;
s += y->c;
s +
On Tue, Oct 25, 2011 at 11:12:25AM +0200, Frederic Riss wrote:
> Could you explain why the overflow is required here with respect to
> the standard?
Because most of gcc targets (the only exception is i386 and m68k I think)
define FLT_EVAL_METHOD 0, so say that floating point expressions are
evalua
Hi
On 25 October 2011 10:00, Jakub Jelinek wrote:
> On Mon, Oct 24, 2011 at 11:12:29PM -0400, David Miller wrote:
>> While working on some test cases I noticed that the 'fsmuld'
>> instruction on sparc was not being matched by the combiner for
>> things like:
>>
>> double fsmuld (float a, float b
From: Jakub Jelinek
Date: Tue, 25 Oct 2011 10:00:50 +0200
> I bet
> double fsmuld (float a, float b)
> {
> return (double) a * b;
> }
> instead will match your pattern, then the operands are first extended
> into double and then multiplied into a double product.
Right, in existing testcases I'
> I wonder if it might make sense to more strongly suggest to use GNU as
> on AIX? The install manual currently says
>
> The native @command{as} and @command{ld} are recommended for
> bootstrapping
> on AIX@. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20
> is required to bootstrap
On Tue, Oct 25, 2011 at 1:25 AM, David Edelsohn wrote:
> On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith wrote:
>
>> One more question on this quest (drifting a little more off topic).
>> In my log files I see a lot of these errors:
>>
>> ld: 0711-768 WARNING: Object
>> ../libsupc++/.libs/libsupc++c
On Mon, Oct 24, 2011 at 11:12:29PM -0400, David Miller wrote:
> While working on some test cases I noticed that the 'fsmuld'
> instruction on sparc was not being matched by the combiner for
> things like:
>
> double fsmuld (float a, float b)
> {
> return a * b;
> }
>
> Combine does try to match
Eric Botcazou wrote:
>> I just need to save it. It needs to be saved so that the FPU
>> pipeline is flushed.
>
> Then why not save it just below the stack pointer?
>
Wow, yes, that seems the right way! How simple, Thanks.
29 matches
Mail list logo
