> 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
> /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
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
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
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
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
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
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
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
>
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
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
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
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
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 "
14 matches
Mail list logo
