Hello,
This is a strange problem. Why an operantion that should be a 'xorsi3'
format, yet it comes out with a 'scond' format. I have defined
'xorsi3' indeed. When I use the encluesive operantion '^', it is ok to
emit 'xorsi3'. When I compile the libgcc, it is not ok in _pack_df.o.
So what's the pro
Original Message
Subject: Re: Problem with GNAT Ada floating-point image representation
under HPUX
Date: Sun, 23 Oct 2005 10:43:12 +0200
From: .:SB:. <[EMAIL PROTECTED]>
To: Clarke, Carus V <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
Good reading is "Programming in ADA
Andreas Jaeger <[EMAIL PROTECTED]> wrote on 20/10/2005 18:08:56:
>
> Hi Razya,
>
> you developed the following tests:
>
> 2005-10-12 Razya Ladelsky <[EMAIL PROTECTED]>
>
> * g++.dg/ipa/ipa-1.c: New test.
> * g++.dg/ipa/ipa-2.c: New test.
> * g++.dg/ipa/ipa-3.c: New tes
* Sebastian Pop:
> Steve Ellcey wrote:
>>
>> In the meantime I would be interested in any opinions people have on
>> what level we should be writing things out at. Generic? Gimple? RTL?
>
> Or just dumping plain C code? This is almost what the pretty printers
> are doing, and the way back to
> It does not fail for power and I'm trying to figure out why it fails for
> x86 architecture.
SPARC is also affected, but in 32-bit mode only.
--
Eric Botcazou
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a while
ago:
When compiling for 32bit, we get the following repre
Dorit wrote:
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a
while
> When compiling for 64bit, there is an extra cast:
> In the 64bit case however, the vectorizer dumps show that the
> access-function returned for the index to array b is much more
> compilcated
> - the dataref analyzer doesn't seem to be able to extract the
> evoluti
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk
gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor?
I believe most people do understand these sentences now that FX has
kindly provided a translation
The importance of gfortran as the HIRLAM consorti
On Sat, 15 Oct 2005, Frank Ned wrote:
> I have space to mirror GCC.
>
> What I need do to contribut with GCC project?
>
> name of the server: absoluta.org
> path to the GCC mirror: /gcc
> country/city: Brazil/Brasília
Thanks for the offer to mirror our site. http://absoluta.org/gcc does not
se
According to a comment in line 2694 of gcc/Makefile.in, a dummy command like
@true must be added to a rule to "force gnu make to recheck modification
times.".
But the GNU make manual says that a rule without a command simply states a
dependency.
In gcc, many of those "dependency only" rules de
Eric Fisher wrote:
This is a strange problem. Why an operantion that should be a 'xorsi3'
format, yet it comes out with a 'scond' format.
Probably because it was optimized. If you want a better answer, you
have to give us more info about what happened, such as a C testcase, and
RTL dumps. B
Steven J. Hill wrote:
GCC guts, but could not figure out why I get the symbolic register
representations in the glibc compiled code and not in my stuff. Can
Those aren't symbolic registers. Those are variable names. Try looking
at the input file tst-tls10.c, and notice that it has variable n
Daniel Berlin <[EMAIL PROTECTED]> writes:
> Karl, Ben, have you ever seen a lengthy discussion indicating that
> compressed and no-text base working copies are unlikely to happen?
I once expressed the sentiment that compressed text bases were not as
desirable as simply optional text bases, and sai
>Probably because it was optimized. If you want a better answer, you
>have to give us more info about what happened, such as a C testcase, and
>RTL dumps. But it is probably better if you look at this yourself.
>Generate debugging dumps, -da -fdump-tree-all, and then start looking.
>Presumably an
Jim Wilson wrote:
Those aren't symbolic registers. Those are variable names. Try looking
at the input file tst-tls10.c, and notice that it has variable names a1,
a2, and a3. So somehow, in your output, the variable name a1 got
replaced with the register name $5, which won't work.
*blush
Hello all,
This is my first post! I'm already familiar with
adding new intrinsics, and am familiar with several
files:
rtl.def - added new rtl types for new instructions
simplify-rtx.c - return 0 in the simplify binary
and simplify ternary operations for
instructi
Eric Fisher <[EMAIL PROTECTED]> writes:
> Thanks. And there is another question. I've been told that 'scond'
> operations are not obligatory defined. If they are not defined then
> they will use 'bcond' like. But while I omit 'scond', gcc will fail
> error that such operation rtl doesn't define. S
Razya Ladelsky <[EMAIL PROTECTED]> writes:
> It does not fail for power and I'm trying to figure out why it fails for
> x86 architecture.
> It appears that the type of the constant being passed to a function having
> a short parameter, is an int while I expected it to be short.
>
> call to g :
Hi ,
I am overwhelmed with the jargon and world of alias analysis and
different kinds of it. I was wondering if some one can help me with
this simple question. Is deciding if a pointer is pointing to what
segment (heap/otherwise) a simpler problem than exactly deciding the
points to set?
th
>It shouldn't. What is the actual error message?
>
>Ian
Such as follows,
dp-bit.c: In function `__pack_d':
dp-bit.c:435: error: unrecognizable insn:
(insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159)
(ltu:SI (reg:SI 158 [ .class ])
(const_int 2 [0x2]))) -1 (insn_list 32 (nil))
Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes:
> According to a comment in line 2694 of gcc/Makefile.in, a dummy command like
> @true must be added to a rule to "force gnu make to recheck modification
> times.".
>
> But the GNU make manual says that a rule without a command simply states
Tyler Anderson <[EMAIL PROTECTED]> writes:
> I've already added the new type to i386.h, however, I
> think I'm missing something in the #define
> REG_CLASS_CONTENTS section. Could anyone point me to
> more documentation about what each bit means? We need
> to add a new register type, and extend th
Eric Fisher <[EMAIL PROTECTED]> writes:
> dp-bit.c: In function `__pack_d':
> dp-bit.c:435: error: unrecognizable insn:
> (insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159)
> (ltu:SI (reg:SI 158 [ .class ])
> (const_int 2 [0x2]))) -1 (insn_list 32 (nil))
> (nil))
> dp-bit.c:43
24 matches
Mail list logo
