rgets:
aarch64- AArch64 (little endian)
sparc - Sparc
sparcel- Sparc LE
sparcv9 - Sparc V9
systemz- SystemZ
Pierre Muller
Le 16/09/2022 à 10:38, Richard Henderson a écrit :
On 9/16/22 10:08, Pierre Muller wrote:
I am using gcc230 machine for the gcc compile farm.
This is a big endian mips64 machine runnig Debian Buster.
When compiling the qemu 7.1.0 release source,
the generated binaries are 32-bit
mips32 seems to still be the default arch that gcc uses,
I don't really understand the idea of depreciating big endian mips32.
Is this solely related to cross-compilation issues?
Pierre Muller
More information on gcc230:
muller@gcc230:~$ uname -a
Linux gcc230 4.9.79-UBNT_E300 #9 SMP Tue Jul
Le 12/08/2022 à 06:16, Thomas Huth a écrit :
On 11/08/2022 23.38, Pierre Muller wrote:
I am using qemu to check code generated by Free Pascal compiler
for various CPUs.
Recently, this allowed me to find out that Free Pascal was generating
wrong instructions, leading to SIGBUS errors
Le 11/08/2022 à 23:38, Pierre Muller a écrit :
I am using qemu to check code generated by Free Pascal compiler
for various CPUs.
Recently, this allowed me to find out that Free Pascal was generating
wrong instructions, leading to SIGBUS errors using qemu-mips.
The same binaries
ries
model : IBM,8231-E2B
machine : CHRP IBM,8231-E2B
Is there a way to enable cpu features separately for ppc like is done for
x86_64?
Or would it be possible to define a new cpu inside qemu source that would match
the description above?
Pierre Muller
Le 11/08/2022 à 19:11, Peter Maydell a écrit :
On Thu, 11 Aug 2022 at 14:35, Pierre Muller wrote:
I don't know if this is the right place to submit this report,
but I have a problem with my attempt to check the 7.1.0 release candidate
for linux user powerpc CPU.
I am test
Hello,
I don't know if this is the right place to submit this report,
but I have a problem with my attempt to check the 7.1.0 release candidate
for linux user powerpc CPU.
I am testing a simple executable, compiled with Free Pacal compiler,
but also linked to libc.
This is what I obtain w
generate a warning, to write this?
Adding an explicit typecast to -4096 seems sufficient to silence that warning.
Pierre Muller
Le 16/03/2022 à 06:58, Richard Henderson a écrit :
Errors are not all negative numbers, but only the top 4k.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Ri
I tested, in release 5.2.0, this issue is fixed.
Thanks
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1843651
Title:
m68k fpu bug
St
Le 16/04/2020 à 22:09, Laurent Vivier a écrit :
> Le 16/04/2020 à 22:03, Pierre Muller a écrit :
>> Le 16/04/2020 à 13:18, Laurent Vivier a écrit :
>>> Le 14/04/2020 à 18:56, Alex Bennée a écrit :
>>>>
>>>> Philippe Mathieu-Daudé writes:
>&g
past that has broken that and no one
> noticed. I bisected and found the commit but it was really too complex
> and difficult to fix.
>
> To be able to debug remotely m68k I use gdb from etch-m68k in a chroot
> (or from real hardware).
I do have a fix for gdb-8.3 release: it works fo
$ cat
0001-Fix-floatx80_invalid_encoding-function-for-m68k-cpu.patch
>From a017dc6d43aaa4ffc7be40ae3adee4086be9cec2 Mon Sep 17 00:00:00 2001
From: Pierre Muller
Date: Wed, 18 Sep 2019 08:04:19 +
Subject: [PATCH]Fix floatx80_invalid_encoding function for m68k cpu
As m68k acce
properly handle those m68k infinity patterns.
The patch below seems to fix the reported problem on current git.
Pierre Muller
Member of core development team of Free Pascal compiler
>From e053d3d07b1951faf0b4637ce1ec4194b8d952e5 Mon Sep 17 00:00:00 2001
From: Pierre Muller
Date: Thu, 12
Public bug reported:
On gcc123 cfarm machine,
I was testing m68k executables generated by Free Pascal Compiler.
muller@gcc123:~/pas/check$ cat inf.pp
function get_double(x : double):double;
begin
get_double:=x;
end;
var
y : double;
py : pbyte;
i : byte;
begin
y:=1.0/0.0;
py:=@
15 matches
Mail list logo
