-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/13 19:48, Mischa Baars wrote:
[...]
I have written a couple of new trigonometric functions for use in
the library, and actually I need this to function properly.
The point is that 1.1 simply cannot be represented precisely as a IEEE
David Malcolm wrote:
[...]
Out of interest, how portable is open_memstream (and if not, is there a
good portable way of doing this)? I have to do similar things in my
python plugin for GCC, and currently I'm using fmemopen. IIRC that
latter one is not available on OS X, and was one of the
I am having a great deal of trouble getting register elimination (and
stack frame layouts in general) working properly on my architecture.
There is some fundamental issue I'm simply not getting here.
My architecture is a fairly vanilla RISC system with a link pointer. The
stack frame layout I'm
Konstantin Vladimirov wrote:
[...]
x = (y ~(1 7)) | (((value 9) 1) 7);
[...]
x = y 4294967167 | (value 9) 7 255; - WAT?
((value 9) 1) 7
== ((value 9) 7) (1 7)
== ((value 9) 7) 0x80
== ((value 9) 7) 0xff
...I think.
That last step is probably being done
David Given wrote:
[...]
When I actually try to build stuff, however, the branch gets emitted but
then silently deleted during the mach pass.
Solved: turned out to be old code in the TARGET_MACHINE_DEPENDENT_REORG,
dating from the port I was basing my backend on, which was mangling my
code. I
So I'm trying to get compare-and-branch working on my architecture. I
have the following patterns:
(define_expand cbranchsf4
[(set
(reg:CC CC_REGNO)
(compare:CC
(match_operand:SF 1 register_operand)
(match_operand:SF 2 register_operand)))
(set
(pc)
Michael Matz wrote:
[...]
As you didn't adjust any cost I would guess the high value comes from the
default implementation of address_cost, which simply uses arithmetic cost,
and the MULT in there is quite expensive by default.
See TARGET_ADDRESS_COST in several ports.
Oddly,
I'm working on a gcc backend for an architecture. The architecture has
instructions for indexed array access; so, ld r0, (r1, r2) is equivalent
to r0 = r1[r2] where r1 is a int32_t*.
I'm representing this in the .md file with the following pattern:
(define_insn *si_load_indexed
[
(set
I think I have found a bug. This is in stock gcc 4.8.1...
My backend does not use the 'enabled' attribute; therefore the following
code in insn-attr.h kicks in:
#ifndef HAVE_ATTR_enabled
#define HAVE_ATTR_enabled 0
#endif
Therefore the following code in gcc/lra-constraints.c is enabled:
