Hi,
I'm trying to define the standard pattern maddsidi4. To do this I wrote this in
my backend (gcc4.5.2) :
(define_insn "maddsidi4"
[(set (match_operand:DI 0 "register_operand" "=a")
(plus:DI
(mult:DI
(sign_extend:DI (match_operand:SI 1 "
This merge was quite convoluted. It brought in the new macro
location features which required several changes in the line
table routines.
With it, I fixed the bug I had introduced with the PPH skipping
that left holes in the line map table. Instead of saving
absolute index numbers for the includ
Hello colleagues,
I've come across a suspicious error with inline asm and register allocation,
and am looking for a clarification of the rules.
What aspect of inline asm processing is preventing gcc from allocating
register eax to both %0 and %1's address in the following test case?
gcc -m32
All,
I'm trying to build trunk with C only on NetBSD 5.1. I've gotten to the point
where libgcc is built with xgcc and I get a failure when linking libgcc_s.so
with:
/usr/bin/ld: /usr/local/lib: No such file:
I replaced ld with echo to see the link line and /usr/local/lib is sent to the
linker
On 11/22/2011 10:55 AM, Bodart, Mitch L wrote:
> What aspect of inline asm processing is preventing gcc from allocating
> register eax to both %0 and %1's address in the following test case?
>
> gcc -m32 -S foo.c
> foo.c: In function 'foo':
> foo.c:20: error: can't find a register in c
Generally questions about building or using gcc should go to the
gcc-help mailing list, not here.
On 22 November 2011 19:01, Aran Clauson wrote:
> I tried removing this line, but the file is regenerated by the make system.
> Since others have built and are building trunk, I assume that I have a
>
Thanks for the quick response Richard!
Unfortunately the source change suggestion didn't work, but that's OK because I
can make the asm work by eliminating some register pressure.
Bottom line is I was looking to find out if there was a compiler problem under
the hood.
Sounds like the answer is
On 11/22/2011 12:11 PM, Bodart, Mitch L wrote:
> Unfortunately the source change suggestion didn't work, but that's OK because
> I can make the asm work by eliminating some register pressure.
Hmm. Well, if you keep that "memory" clobber there, you don't actually
need to represent the RW memory a
Snapshot gcc-4.4-2022 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-2022/
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
The configure string was:
sh ../gcc-4.6.2/configure --enable-cloog-backend=isl
--program-suffix=4.6.2-g --enable-lto --enable-werror
--with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local
--with-ppl=/usr/local --enable-cloog-backend=isl --prefix=/usr/local
--enable-static=all --enable
Hi,
I have been hand optimising a loop that GCC 4.6 was not able to vectorise.
I have been keeping an eye on the assembly output of this loop and
have noticed GCC inserting unnecessary MOVAPS instructions.
It only happens when I use the same variable for both inputs to a SSE intrinsic.
E.g:
__x
On 22 November 2011 07:58, Eric Botcazou wrote:
>> On cygwin, current gcc trunk, I get this new problem:
>>
>> /usr/local/src/trunk/objdir.withada/./gcc/xgcc
>> -B/usr/local/src/trunk/objdir.withada/./gcc/
>> -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem
>> /usr/i686-pc-cygwin/incl
> /usr/local/src/trunk/objdir.withada/./gcc/xgcc
> -B/usr/local/src/trunk/objdir.withada/./gcc/
> -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem
> /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include
> -c -g -O2-W -Wall -gnatpg -nostdinc g-socthi.adb -o g-soct
> But grep is your friend. See s-oscons-tmplt.c lines 1343 and below.
phew, beyond my abilities yet again. someone more cygwin knowledgable
would need to look into that I suppose...
--
Cheers,
/ChJ
14 matches
Mail list logo
