Some ports, notably MMIX, are using different definitions of
EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
the same instruction may be considered invalid in reload.c and valid by
recog.c.
The opposite would be bad because after reload everything must still
adhere to
Hello everyone,
I am upgrading a cross compiler from 3.2 to 3.4.6
I had to change some of the TARGET description macros
in target.h file
for otherwise while building i am getting "attempt to
use poisoned" errors
Presently what is written in target.h is
1. #define CPP_PREDEFINES \
2. #define CONST_COSTS(RTX, CODE, OUTER_CODE) \
case CONST_INT: \
return target_const_costs (RTX, OUTER_CODE);
\
case CONST: \
return 5;
On Thu, 24 Aug 2006, Paolo Bonzini wrote:
> Some ports, notably MMIX, are using different definitions of
> EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
> the same instruction may be considered invalid in reload.c and valid by
> recog.c.
When I wrote that code, accounti
I have been able to use the command...
make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
to check my multilib gcc trunk build on Darwin ppc from within
the darwin_objdir/gcc directory of the build tree. However
this doesn't seem to allow both the -m32 and -m64 testsuite
runs for the o
Hans-Peter Nilsson wrote:
Some ports, notably MMIX, are using different definitions of
EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
the same instruction may be considered invalid in reload.c and valid by
recog.c.
When I wrote that code, accounting for REG_OK_STR
You should look at a small back-end, e.g. pdp11, and see how to rewrite
these macros into functions (target hooks).
Its been a great help... thanks for the direction.
When i looked into the machine macros of GNU supported
processors i found that all of the macros previously
defined in target.h
[no private mail]
Just to move code from target.h to target.c.
Paolo
I didnt get you?
Do you mean to say that i should also move the code to
stick to standard ?
You should move code from target.h to target.c, or it won't compile.
Macros became "target hooks" defined in the target.c fi
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> My simulator now segfaults for every single execution test built with
> mainline; when I try gdb, it also segfaults,
> somewhere in the dwarf handling code.
> Unless someone comes up with a viable concept how to maintain sh64
> support in gcc, I think w
Note: forwarded message attached.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --- Begin Message ---
Hai,
> > i dont know the corresponding macro in
>
I should add that I see the same problem if I execute...
make -k check RUNTESTFLAGS='--target_board "unix{,-m32}"'
...from the toplevel of the linux_obj directory on gcc trunk
built on a x86_64 Fedora Core 5 machine. The behavior is the
same as on darwin. If I execute the above command from t
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int -> string, float -> string, double-> string).
After changing the ostringstream conversion to sprintf, the crash in the
app
On Aug 23, 2006, at 4:43 PM, Jack Howarth wrote:
--- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23
18:33:56.0 -0400
+++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23
18:41:28.0 -0400
@@ -43,6 +43,7 @@
regsub -all "(^|\n)\[^\n\]*file path
Mike,
I just created PR28837 with the patch to prune.exp that
prunes the ld64 warnings. I have only tested this with the
core gcc at the moment because I can't get...
make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
...to work from the toplevel of the darwin_obj directory...
http://g
On Thu, Aug 24, 2006 at 09:28:11AM -0400, Jack Howarth wrote:
> I should add that I see the same problem if I execute...
>
> make -k check RUNTESTFLAGS='--target_board "unix{,-m32}"'
>
> ...from the toplevel of the linux_obj directory on gcc trunk
> built on a x86_64 Fedora Core 5 machine. Th
On Thu, Aug 24, 2006 at 12:02:25PM -0400, Jack Howarth wrote:
> Mike,
>I just created PR28837 with the patch to prune.exp that
> prunes the ld64 warnings. I have only tested this with the
> core gcc at the moment because I can't get...
>
> make -k check RUNTESTFLAGS='--target_board "unix{,-m64
Janis,
THANKS! Using either...
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,}'"
or
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
..works from the toplevel directory (at least for x86_64
on Fedora Core 5...I'll try darwin when I get home to my G5).
Jac
On Thu, 24 Aug 2006, Paolo Bonzini wrote:
> Anyway, I was not meaning to *not* account for anything, but just to
> replace REG_OK_STRICT with checks on reload_in_progress and
> reload_completed. I understand the semantics that you wanted for 'U'.
>
> The bug may be that in some cases, 'U' is check
Jordan, Laszlo (GE Healthcare) wrote:
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int -> string, float -> string, double-> string).
After changing the ostringstream co
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
> Hi,
>
> I had a crash in our software, which occured randomly. The valgrind logs
> and the stack trace pointed to a code snippet, which uses ostringstream
> for data conversion. (int -> string, float -> string, doub
Paul Brook <[EMAIL PROTECTED]> writes:
> On Tuesday 22 August 2006 20:14, Mike Stump wrote:
> > I hate to even bring this up, but... should things like:
> >
> >int m[1 << 27] = {0};
> >
> > be put in .bss? I'm tempted to say no, if you want that, you have to
> > remove {0}.
>
> What makes
[EMAIL PROTECTED] (Jack Howarth) writes:
>Is it the expected behavior for dejagnu to always report warnings
> as errors in the "test for excess errors" check? Is this a design
> decision or just how dejagnu currently works? I ask because the
> current output of "test for excess errors" when a
>
> else if (rld[r].out_reg == 0
>&& rld[r].in != 0
>&& ((REG_P (rld[r].in)
> && REGNO (rld[r].in) >= FIRST_PSEUDO_REGISTER
> && !REGNO_REG_SET_P (®_has_output_reload,
> REGNO (rld[r].in))
>
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
>
> Hi,
>
> I had a crash in our software, which occured randomly. The valgrind logs
> and the stack trace pointed to a code snippet, which uses ostringstream
> for data conversion. (int -> string, float -> str
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
> > I had a crash in our software, which occured randomly. The valgrind logs
> > and the stack trace pointed to a code snippet, which uses ostringstream
> > for data conversion
> > The problem occured with gcc
Snapshot gcc-4.0-20060824 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060824/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
gcc try.c -o try would give me linking problem
/tmp/ccQOkXtu.o: In function `serial_echo_print':
try.c:(.text+0x31e): undefined reference to `__inb'
try.c:(.text+0x34a): undefined reference to `__outb'
try.c:(.text+0x360): undefined reference to `__inb'
try.c:(.text+0x387): undefined reference to
wizard00 <[EMAIL PROTECTED]> writes:
> gcc try.c -o try would give me linking problem
>
> /tmp/ccQOkXtu.o: In function `serial_echo_print':
> try.c:(.text+0x31e): undefined reference to `__inb'
> try.c:(.text+0x34a): undefined reference to `__outb'
> try.c:(.text+0x360): undefined reference to `_
If the general replacement of REG_OK_STRICT is indeed
reload_in_progress || reload_completed, then the substitution
*should* of course be in principle be correct (as in: subject to
testing. ;)
Sure. After I'm done with the base_reg_class changes, I will try
modifying address_operand to be some
>
> Hi,
>
> I had a crash in our software, which occured randomly. The valgrind logs
> and the stack trace pointed to a code snippet, which uses ostringstream
> for data conversion. (int -> string, float -> string, double-> string).
> After changing the ostringstream conversion to sprintf,
fl wrote:
probably a library version mismatch, libstdc++.so.6.0.7 belongs to GCC
4.1.0.
regards,
lajos
Aren't libstdc++.so.6.0.n supposed to be compatible with each other
(regardless
of the value of n)?
Michael
31 matches
Mail list logo
