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
>
> 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,
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
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 `_
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
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
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
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
>
> 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))
>
[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
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
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
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, 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
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, 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
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
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 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
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
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
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
>
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
[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
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
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
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
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
2. #define CONST_COSTS(RTX, CODE, OUTER_CODE) \
case CONST_INT: \
return target_const_costs (RTX, OUTER_CODE);
\
case CONST: \
return 5;
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 \
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
31 matches
Mail list logo
