://cgit.freebsd.org/ports/commit/?id=70d8d9125c9f5b1da36b134408b3d580a39f1aa8
On 22-05-15 12:57:13, Piotr Kubaj wrote:
> GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
> 315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
> PowerPC on FreeBSD, so this co
/ChangeLog
@@ -1,3 +1,7 @@
+2022-05-15 Piotr Kubaj
+
+ * configure.tgt: add powerpc*-*-freebsd*
+
2022-05-05 Martin Liska
* LOCAL_PATCHES: Update.
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index fb89df4935c..affe8964f84 100644
--- a/libsanitizer/configure.tgt
/ChangeLog
@@ -1,3 +1,7 @@
+2022-05-15 Piotr Kubaj
+
+ * configure.tgt: add powerpc*-*-freebsd*
+
2022-05-05 Martin Liska
* LOCAL_PATCHES: Update.
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index fb89df4935c..affe8964f84 100644
--- a/libsanitizer/configure.tgt
I'm abandoning this patch. It was fixed in FreeBSD instead to have
feenableexcept() in libm in
https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a
Thanks for your insight!
On 22-05-13 10:59:59, Kewen.Lin wrote:
> on 2022/5/13 04:16, Segher Boessenkool wrote:
> > Hi
dn't be difficulted but I moved to other thing after
months looking at FPE in kernel, bugs in context switch and msun test cases
failing :-P
As far as I know, there are currently no plans to move it to libm on powerpc.
riscv, arm and arm64 are in the same boat.
I will follow with a next patch
Is there anything more required?
On 22-05-03 12:33:43, Piotr Kubaj wrote:
> Here are gmake check-gfortran results requested by FX.
>
> Before patching:
> === gfortran Summary ===
>
> # of expected passes65106
> # of unexpected failures
But this seems unrelated to my patch.
On 22-05-03 12:21:12, pku...@freebsd.org wrote:
> From: Piotr Kubaj
>
> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
>
> Signed-off-by: Piotr Kubaj
> ---
> libgfort
On 22-04-28 20:55:08, FX wrote:
> > Given that 12 has been branched off, is it OK now to commit this patch?
>
> How does the patch affect the results of “make check-gfortran”? How many
> tests that failed or were unsupported pass?
Actually, test results don't change at all. However, software
Given that 12 has been branched off, is it OK now to commit this patch?
On 22-04-14 16:09:35, Piotr Kubaj wrote:
> On 22-04-14 09:05:17, FX wrote:
> > Hi,
> >
> > > can you check the following patch?
> >
> > Why restrict it to powerpc-freebsd only, and
On 22-04-14 09:05:17, FX wrote:
> Hi,
>
> > can you check the following patch?
>
> Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
amd64 and i386 on all systems use a different setting and are not affected.
For FreeBSD-supported architectures that are not amd64,
>
> Could you test something on your end?
>
> FX
--
From d5e255f09b4cfd2cb3688d0e2d5feba85d1f5dc8 Mon Sep 17 00:00:00 2001
From: Piotr Kubaj
Date: Thu, 14 Apr 2022 02:35:26 +0200
Subject: [PATCH] powerpc: properly detect feenableexcept on FreeBSD
FreeBSD doesn't have fee
On 22-03-20 16:30:08, FX wrote:
> Hi,
>
> (Please send all Fortran (front-end and libgfortran) patches in CC to the
> Fortran list.)
>
> Please hold from pushing the patch as is, I have some questions:
>
> - If FreeBSD has feenableexcept() and related functions, it should already
> use the
fpu-glibc name is a bit incorrect, since it also works on other systems.
I have verified that it builds and can also build other packages
correctly (that were failing before).
From 0feb83fae30070cf250781449670638d7addd947 Mon Sep 17 00:00:00 2001
From: Piotr Kubaj
Date: Sun, 20 Mar 2022 13:03:13
Bumping. Is there anything wrong with this patch?
On 22-02-21 00:37:56, pku...@freebsd.org wrote:
> From: Piotr Kubaj
>
> While FreeBSD currently uses 64-bit long double, there should be no
> problem with adding support for float128.
>
> Signed-off-by: Piotr Kubaj
> --
On 21-10-16 18:57:39, Segher Boessenkool wrote:
> On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote:
> > Only powerpc64-unknown-freebsd was checked for.
> >
> > Signed-off-by: Piotr Kubaj
>
> Thanks!
>
> I pushed this now, with commit message (includi
Only powerpc64-unknown-freebsd was checked for.
Signed-off-by: Piotr Kubaj
---
gcc/configure| 2 +-
gcc/configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index 5ea5a1b7143..8790153cfda 100755
--- a/gcc/configure
+++ b/gcc
Hello again,
it looks like one simple patch got left out by accident. Would it be possible
for you to commit it?
Thank you,
Piotr Kubaj.
On 20-12-28 06:37:23, Segher Boessenkool wrote:
> On Mon, Dec 28, 2020 at 12:44:15PM +0100, Gerald Pfeifer wrote:
> > On Wed, 16 Dec 2020, Segher Bo
t;$target:$tm_file" in
- powerpc64-*-freebsd* | powerpc64*-*-linux* |
powerpc*-*-linux*rs6000/biarch64.h*)
+ powerpc64*-*-freebsd* | powerpc64*-*-linux* |
powerpc*-*-linux*rs6000/biarch64.h*)
case "$target" in
*le-*-linux*)
emul_name="-melf64lppc"
Thanks,
Piotr
Yes, there is, thanks for noticing that!
Fixed patch attached.
On 20-12-15 00:37:02, Gerald Pfeifer wrote:
> On Mon, 14 Dec 2020, Piotr Kubaj via Gcc-patches wrote:
> > --- gcc/configure.ac.orig 2020-12-14 15:22:23 UTC
> > +++ gcc/configure.ac
> > @@ -5874,6 +58
On 20-12-14 10:22:32, Segher Boessenkool wrote:
> On Mon, Dec 14, 2020 at 03:57:27PM +0100, Piotr Kubaj wrote:
> > > It is both, actually (-mcpu= implies -mtune=)
> > Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is the
>
uses.
Would it be ok to backport it to at least GCC 10?
gcc/Changelog:
2020-12-14 Piotr Kubaj
* config.gcc: add support for powerpc64le-unknown-freebsd
--- gcc/config.gcc.orig 2020-12-07 03:00:29 UTC
+++ gcc/config.gcc
@@ -2868,6 +2868,10 @@ powerpc*-*-freebsd*)
extra_options
On 20-12-13 09:48:35, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Dec 13, 2020 at 03:34:57PM +0100, Piotr Kubaj wrote:
> > this is only default tuning (-mtune, not -mcpu).
>
> It is both, actually (-mcpu= implies -mtune=)
Yes, but -mtune doesn't imply -mcpu. If I set
Hello,
this is only default tuning (-mtune, not -mcpu). Linux also does similarly in
linux64.h:
74 #undef PROCESSOR_DEFAULT
75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
76 #undef PROCESSOR_DEFAULT64
77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
Although there is hard to
I have already bisected GCC 10 issue here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
The problem is commit 634afa05a8cbff010480088811fe1f39eca70c1d.
On 20-04-14 21:11:01, Iain Sandoe wrote:
Gerald Pfeifer wrote:
On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:
Hi,
since there has been some misunderstanding, I will explain.
There are 4 possible options here:
1. FreeBSD 12.1-RELEASE, powerpc, GCC 4.2
2. FreeBSD 13.0-CURRENT (head branch), powerpc, LLVM 10.0.0
3. FreeBSD 12.1-RELEASE, powerpc64, GCC 4.2
4. FreeBSD 13.0-CURRENT (head branch), powerpc64,
25 matches
Mail list logo
