hed a new
patch.
Yes, *all* OCTEON CPUs have always been r2 (or better).
At the time the code was written, there were good reasons not to set:
#define cpu_has_mips32r2 0
This was discussed on the lmo mailing lists, but I forget what they were
at this point.
David Daney
Thanks,
James
it further, find the reason about
this SIGBUS, and if it's a compiler issue at all.
It is a userspace program that is generating SIGBUS. Why not attach gdb
and get a dissassembly of the region of code that is crashing as well as
backtraces and register contents?
David Daney
to be functionally equivalent.
I was going to suggest the same thing. It makes it more clear what is
happening. Not only is MOVE functionally equivalent, it is causes the
exact same code to be emitted, so you might say it is identical.
David Daney
--
To UNSUBSCRIBE, email to debian-bugs
We will try to fix it if it affects current GCC versions.
Especially helpful would be preprocessed source and the exact command
line flags used.
Thanks,
David Daney
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
David Daney wrote:
Luk Claes wrote:
Giuseppe Iuculano wrote:
Hi,
Luk Claes ha scritto:
mips and mipsel do now also need the -fPIC compilation flag to make
sure that shared objects only contain position independent code.
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith
ips.o (which is a member of ../../dist/lib/libxptcmd.a)
was compiled.
David Daney
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
6 matches
Mail list logo
