if (get_attr_cirrus (prev_active_insn(insn)) == CIRRUS_COMPARE)
return \"beq\\t%l0\;bvs\\t%l0\"; else return \"bge\\t%l0\;nop\";
"
[(set_attr "conds" "jump_clob")
(set_attr "length" "8")]
)
As you can see, I need to replace all bge with a maverick crunch
equivalent. However, "bg
On 6/26/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
After the dataflow merge (and after doing a couple of other patches that
were needed just to boostrap GCC on IA64 HP-UX), I am still getting some
failures in the GCC testsuite and am hoping for some advise / help on
figuring out what is going on
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> In the lto world we will be reading in a function and then hacking on
> it. Many (most) of those hacks are not in place changes, but adding,
> deleting and rearranging instructions into the stream.
>
> Doing in place mapping puts severe restrictions
G'day all,
As I wrote previously on gcc-patches (
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00244.html ), I'm working
on code to get the MaverickCrunch Floating-Point Co-processor supported
on ARM. I mentioned previously that you can't use the same opcodes for
testing GE on the MaverickCrunch,
Ian Lance Taylor wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
>
>> But, first, I'd like to know what folks think about this. Would it be
>> generally useful for us to have the IL data structures auto-generated
>> this way? I can see the benefits in the reader/writer. But also, we
>> a
On Tue, 26 Jun 2007, Andrew Pinski wrote:
> On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
> > Having the same layout makes them "the same".
> Not in C or C++ and in most cases of fortran too (unless you add an
> attribute).
Yes, it's clear now, thanks. However, it brings a new question: th
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Having the same layout makes them "the same".
Not in C or C++ and in most cases of fortran too (unless you add an attribute).
-- Pinski
On Tue, 26 Jun 2007 [EMAIL PROTECTED] wrote:
> On Tue, Jun 26, 2007 at 11:42:27PM +0200, Herman Geza wrote:
> > struct Point {
> > float x, y, z;
> > };
> > struct Vector {
> > float x, y, z;
> >
> > Point &asPoint() {
> > return reinterpret_cast(*this);
> > }
> > };
On Tue, Jun 26, 2007 at 11:42:27PM +0200, Herman Geza wrote:
> struct Point {
> float x, y, z;
> };
> struct Vector {
> float x, y, z;
>
> Point &asPoint() {
> return reinterpret_cast(*this);
> }
> };
> Point and Vector have the same layout, but GCC treats th
On Tue, 26 Jun 2007, Silvius Rus wrote:
> Herman Geza wrote:
> > aliasing when GCC (I think) incorrectly treats types different, but they're
> > the same. For example, I have:
> >
> > struct Point {
> > float x, y, z;
> > };
> >
> > struct Vector {
> > float x, y, z;
> >
> > Poin
Diego Novillo <[EMAIL PROTECTED]> writes:
> But, first, I'd like to know what folks think about this. Would it be
> generally useful for us to have the IL data structures auto-generated
> this way? I can see the benefits in the reader/writer. But also, we
> are going to have to re-implement the
On 6/26/07, Silvius Rus <[EMAIL PROTECTED]> wrote:
I also think this case should not be flagged. I have seen similar usage
in network programming. Did it actually result in bad code or was it
just the warning that bothered you?
This case is valid only if you go back to original type of Vector
After the dataflow merge (and after doing a couple of other patches that
were needed just to boostrap GCC on IA64 HP-UX), I am still getting some
failures in the GCC testsuite and am hoping for some advise / help on
figuring out what is going on.
A bunch of tests like the following one:
v
Herman Geza wrote:
aliasing when GCC (I think) incorrectly treats types different, but
they're the same. For example, I have:
struct Point {
float x, y, z;
};
struct Vector {
float x, y, z;
Point &asPoint() {
return reinterpret_cast(*this);
}
On Tue, 26 Jun 2007, Silvius Rus wrote:
> Herman Geza wrote:
> > void foo(float *a) {
> > int *b = (int*)a; // type-punning warning
> >
> > // here, access to a and b shouldn't be optimized, as the compiler
> > knows that a and b point to the same address
> > }
> >
> > Is this reasonab
Venkatesan Jeevanandam <[EMAIL PROTECTED]> wrote on
26/06/2007 09:26:18:
> Hi,
>
> I have been given a set of cross-compiler binaries (like arch-gcc,
> arch-as, arch-ld, arch-ar, arch-gdb, etc.,).
> How can i test "arch-gcc" cross-compiler binary using GCC testsuite ?
Do you have an access to suc
Herman Geza wrote:
void foo(float *a) {
int *b = (int*)a; // type-punning warning
// here, access to a and b shouldn't be optimized, as the compiler
knows that a and b point to the same address
}
Is this reasonable?
Even if it were trivial to implement, I would vote against it, be
Mark Mitchell wrote:
> Kenny --
>
> I tried to get the simplest C program containing a function:
>
> void f() {}
>
> to go through LTO today, but the LTO reader says:
>
> ./empty-function.o:0: internal compiler error: in lto_static_init_local,
> at lto-tree-flags.def:747
>
> Apparently, this is b
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Let me elaborate. If the compiler can detect invalid type-punning,
Not really.
void foo(float *a) {
int *b = (int*)a; // type-punning warning
}
This is actually valid if we don't access both a and b and also the
original type is in
On Tue, 26 Jun 2007, Andrew Pinski wrote:
> On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
> > Maybe GCC shouldn't optimize around invalid type-punnings?
>
> That is what -fno-strict-aliasing is for.
> Also GCC has done this since 3.0.0 (and also 2.95 and 2.95.1 and then
> in 2.95.2 it was c
kerneltest.c:22: error: unrecognizable insn:
(jump_insn 26 25 29 3 (set (pc)
(create_body_after (cre (reg:DI 75)
(const_int 0 [0x0]))
(label_ref 13)
(pc))) -1 (nil)
(nil))
kerneltest.c:22: internal compiler error: in extract_insn, at recog.c:2096
I chatted briefly with Ken today about the reader/writer being
implemented for LTO. One of the difficulties in keeping the
reader/writer up-to-date is the evolving IL data structures. Whenever
these change, the reader must be adapted to the new format.
So, while the reader/writer is fairly stra
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Maybe GCC shouldn't optimize around invalid type-punnings?
That is what -fno-strict-aliasing is for.
Also GCC has done this since 3.0.0 (and also 2.95 and 2.95.1 and then
in 2.95.2 it was changed back while most of the free source world
fixes t
Thanks for the answers!
> > Why? Won't the following work?
> >
> > void setNaN(float &v) {
> > union { float f; int i; } t;
> > t.i = 0x7f81;
> > v = t.f;
> > }
> >
> As far as I know, this is guaranteed to work with GCC. But it is not kosher
> according to language standards, so ot
Mark Mitchell wrote:
> Kenny --
>
> I tried to get the simplest C program containing a function:
>
> void f() {}
>
> to go through LTO today, but the LTO reader says:
>
> ./empty-function.o:0: internal compiler error: in lto_static_init_local,
> at lto-tree-flags.def:747
>
> Apparently, this is b
Kenny --
I tried to get the simplest C program containing a function:
void f() {}
to go through LTO today, but the LTO reader says:
./empty-function.o:0: internal compiler error: in lto_static_init_local,
at lto-tree-flags.def:747
Apparently, this is because the static set-up in lto_static_i
Mark Mitchell wrote:
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_ reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears t
Acronymed GREPS (... just what you were looking for), is to be held on
September 16 in Brasov, Romania, co-located with PACT. We'd like to bring
this workshop to your attention; the submission site is now open until July
24, after the upcoming GCC Developers' Summit. For more details see
http://sy
28 matches
Mail list logo
