Enabling CONFIG_MATH_EMULATION and CONFIG_MATH_EMULATION_HW_UNIMPLEMENTED
configuration options in the kernel fixes this problem without changes to
gcc-7/gcc-8.
This makes unstable run on the e6500 (and probably the e5500 as well)
without a problem.
Sorry about the scare, I should have looked for
On Sun, Feb 11, 2018 at 4:30 AM, Dennis Clarke wrote:
>
This is something that needs to be discussed. A single user alone
shouldn't
warrant such major change in a port. You always have to keep in mind
that
changing the default compiler options also has potential impact on
This is something that needs to be discussed. A single user alone shouldn't
warrant such major change in a port. You always have to keep in mind that
changing the default compiler options also has potential impact on the
performance on more modern ppc64 systems like Apple Macintosh.
Not sure
On Sat, Feb 10, 2018 at 04:02:36PM -0500, Dennis Clarke wrote:
> On 09/02/18 05:34 AM, John Paul Adrian Glaubitz wrote:
> > On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
> > > mator on #debian-ports compiled gcc-7 for me with the attached patch.
> > > With the resulting gcc, I compiled glibc and got
On 09/02/18 05:34 AM, John Paul Adrian Glaubitz wrote:
On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
mator on #debian-ports compiled gcc-7 for me with the attached patch.
With the resulting gcc, I compiled glibc and got a library I can use
sqrtf without running into an illegal instruction excepti
On Fri, Feb 09, 2018 at 11:34:12AM +0100, John Paul Adrian Glaubitz wrote:
> This is something that needs to be discussed. A single user alone shouldn't
> warrant such major change in a port. You always have to keep in mind that
> changing the default compiler options also has potential impact on t
Hi all,
On Fri, Feb 9, 2018 at 1:12 PM, Luuk van Dijk wrote:
> I apologize for the 'reply in 48 hours' spam my extcontacts mailinglist
> caused for any of you that replied here. I asked bas to keep us posted but
> i didn't realize it would send this out. I switched it off.
>
> thanks for all yo
Taking extcont...@daedalean.ai out of the cc list (it has an auto replay I
didn't know about, sorry).
Bas Vermeulen
On Fri, Feb 9, 2018 at 12:56 PM, Bas Vermeulen wrote:
> diff of gcc -dM -E - without and with the patch applied:
>
> --- gcc-default 2018-01-28 18:06:14.11600 +
> +++ gcc-
diff of gcc -dM -E - without and with the patch applied:
--- gcc-default 2018-01-28 18:06:14.11600 +
+++ gcc-powerpc64 2018-01-28 18:03:06.57200 +
@@ -34,7 +34,6 @@
#define __FLT64_DECIMAL_DIG__ 17
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define pixel pixel
-#define _ARCH_PPCS
We need this change too. We have e5500 CPU’s in our AmigaOnes.
— Christian
Sent from my iPhone
> On 9. Feb 2018, at 11:34, John Paul Adrian Glaubitz
> wrote:
>
>> On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
>> mator on #debian-ports compiled gcc-7 for me with the attached patch.
>> With the
On Fri, Feb 9, 2018 at 11:34 AM, John Paul Adrian Glaubitz
wrote:
> On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
>>
>> mator on #debian-ports compiled gcc-7 for me with the attached patch.
>> With the resulting gcc, I compiled glibc and got a library I can use
>> sqrtf without running into an ille
On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
mator on #debian-ports compiled gcc-7 for me with the attached patch.
With the resulting gcc, I compiled glibc and got a library I can use
sqrtf without running into an illegal instruction exception.
Would it be possible to get this applied by default
Hi,
mator on #debian-ports compiled gcc-7 for me with the attached patch. With
the resulting gcc, I compiled glibc and got a library I can use sqrtf
without running into an illegal instruction exception.
Would it be possible to get this applied by default? The resulting binaries
work on e6500, an
On 02/06/2018 07:29 PM, Bas Vermeulen wrote:
> I get that. But configure in the gcc sources doesn't actually process those.
> So while they are in rules2, it doesn't actually change anything.
>
> See
> https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/configure
> a
I get that. But configure in the gcc sources doesn't actually process
those. So while they are in rules2, it doesn't actually change anything.
See
https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/configure
and search for with-cpu (which would catch both --with-cpu-32
On Tue, Feb 06, 2018 at 06:58:55PM +0100, John Paul Adrian Glaubitz wrote:
> It would be nice if anyone who cares about the ppc64 could actually
> post what kind of hardware they have. We should find a consensus on
> where to put the baseline.
Well at least the CPUs listed on https://wiki.debian.o
On 02/06/2018 07:22 PM, Bas Vermeulen wrote:
> I just checked gcc's configure, and that doesn't take --with-cpu= as an
> argument. It doesn't fail when it has it, but it doesn't actually do anything
> with it
> either.
> So my patch would be the correct way to handle this.
That's because you hav
I just checked gcc's configure, and that doesn't take --with-cpu= as an
argument. It doesn't fail when it has it, but it doesn't actually do
anything with it either.
So my patch would be the correct way to handle this.
Bas Vermeulen
On Tue, Feb 6, 2018 at 6:58 PM, John Paul Adrian Glaubitz <
glau
On 02/06/2018 06:03 PM, Bas Vermeulen wrote:
> Mostly because I didn't know/think of that. But you are right, that would be
> better.
So, the file you want to modify is:
> https://sources.debian.org/src/gcc-7/7.3.0-1/debian/rules2/#L380-L392
It would be nice if anyone who cares about the ppc64
Mostly because I didn't know/think of that. But you are right, that would
be better.
Bas Vermeulen
On Tue, Feb 6, 2018 at 5:48 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
>
>
> On Feb 6, 2018, at 5:26 PM, Bas Vermeulen wrote:
>
> I am evaluating the following patch to g
> On Feb 6, 2018, at 5:26 PM, Bas Vermeulen wrote:
>
> I am evaluating the following patch to gcc-7 to fix the problem. It's
> currently building, I'll follow up when I know it works. The patch is added
> to debian/rules.patch to get it included.
Why do you want to patch the upstream sources
On Tue, Feb 06, 2018 at 03:40:20PM +0100, Bas Vermeulen wrote:
> I am trying to run the ppc64 unstable on a Freescale T2080, which uses the
> e6500 CPU. Running python (or any other application using sqrt or sqrtf)
> will cause an illegal instruction exception, because the sqrtf opcode is
> not sup
I am evaluating the following patch to gcc-7 to fix the problem. It's
currently building, I'll follow up when I know it works. The patch is added
to debian/rules.patch to get it included.
Bas Vermeulen
On Tue, Feb 6, 2018 at 5:16 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:
> On T
23 matches
Mail list logo
