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
On 22-05-13 10:59:59, Kewen.Lin wrote:
> on 2022/5/13 04:16, Segher Boessenkool wrote:
> > Hi Piotr,
> >
> > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote:
> >> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
> >
> > Declared, not defined. These are required
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 failures6
> # of expected
Here are gmake check-gfortran results requested by FX.
Before patching:
=== gfortran Summary ===
# of expected passes65106
# of unexpected failures6
# of expected failures 262
# of unsupported tests 367
After patching:
===
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 not all freebsd? Do they
> > differ?
>
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,
Hello,
can you check the following patch?
On 22-04-13 17:27:11, FX wrote:
> Hi,
>
> > the problem is that configure checks for feenableexcept() in libm:
> > AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes
> > AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
> >
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
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 (including changelog, which is
>
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 Boessenkool
Hello again,
sorry to reopen this issue, but one part was skipped. It was just now found
out, because it doesn't cause build issues, but only runtime issues (GCC fails
to build binaries):
/usr/local/bin/ld: /usr/local/lib/gcc10/libgcc_s.so: undefined reference to
`.__udivmodti4'
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
> > generic one (ppc970 for BE)
>
> But that is not
Hello,
this patch implements support for powerpc64le architecture on FreeBSD. Since we
don't have powerpcle (32-bit), I did not add support for powerpcle here. This
remains to be changed if there is powerpcle support in the future.
Patch implements similar endian detection to what linux64.h
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 up only -mtune, -mcpu is the
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,
19 matches
Mail list logo
