o intent to install as stands.)
>
> base/binutils did not have such problems. (Actually installed on 32-bit
> powerpc so more ports can build.)
I think the devel/freebsd-gcc* ports have a workaround for this when being built
on aarch64. We probably need the same fix
On 1/3/20 2:34 AM, Mark Millard wrote:
> John Baldwin jhb at FreeBSD.org wrote on
> Thu Jan 2 21:41:07 UTC 2020 :
>
>> On 1/2/20 1:34 PM, John Baldwin wrote:
>>> Author: jhb
>>> Date: Thu Jan 2 21:34:44 2020
>>> New Revision: 356289
>>> UR
the plugins don't build
when aarch64 is the native host.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
his in clang properly, though.
I think using the hack patch in devel/freebsd-gcc* is fine for now, but can
you confirm if both 6 and 9 need it or only 9?
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listin
ll a BUTARGET-ld binary anywhere. I might end up
axeing /usr/BUTARGET/bin from the base/binutils package. I've
trimmed most of the similar type files from base/gcc6 recently.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.fr
On 12/19/19 12:06 PM, Ryan Libby wrote:
> On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
>>
>> In the interest of supporting newer versions of GCC for a base system
>> toolchain, I've renamed the external GCC packages from -gcc
>> to -gcc6. These are built as fla
On 12/18/19 4:16 PM, Mark Millard wrote:
>
>
> On 2019-Dec-18, at 13:48, John Baldwin wrote:
>
>> In the interest of supporting newer versions of GCC for a base system
>> toolchain, I've renamed the external GCC packages from -gcc
>> to -gcc6. These are built as
on
newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x).
I do plan to switch the default toolchains for make universe/tinderbox
for targets using -xtoolchain-gcc based on GCC 6 over to the
freebsd-gcc6 variants in the next week or so.
--
John Baldwin
e
of work) for existing releases, so we want to provide different packages for
different major compiler versions to cope with newer OS releases supporting
newer compilers (e.g. we will patch head to work with freebsd-gcc9, but if
we only had a single powerpc64-gcc port
have max ULP of 2.9 (the
> desired result); with the latter you have a max ULP of 23.xxx.
> I have observed a 6 billion ULP issue when running my testsuite.
> As pointed out by John Baldwin, GCC is aware of the FPU setting.
> The problem with clang is that it seems to unconditiona
t is gcc doing different than clang
in this case. I assume neither GCC _nor_ clang are adjusting the FPU in
compiler-generated code, and in fact as Steve's earlier tests shows, the
precision is set to PD by default when a clang-built binary is run.
--
John Baldwin
On 3/13/19 9:40 AM, Steve Kargl wrote:
> On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
>> On 3/13/19 8:16 AM, Steve Kargl wrote:
>>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>>>>
>>>> gcc8 --version
>>>> gcc
nt
>> main(void)
>> {
>>double re, im, u, ur, ui;
>>float complex f;
>>float x, y;
>
> this line to "volatile float x, y".
So it seems to be a regression in clang 7 vs clang 6?
--
John Baldwin
normally but I try base/gcc in case it
> turns out that I need it.)
Patch pending review at https://reviews.freebsd.org/D19484
Thanks.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-too
On 2/25/19 12:24 PM, Brooks Davis wrote:
> On Mon, Feb 25, 2019 at 10:50:40AM -0800, John Baldwin wrote:
>> Hmm, cross compiling is indeed a bear. My original version of this was to
>> have base/gcc install a special 'freebsd-gcc.mk' toolchain file to
>> /usr/share/
On 2/22/19 8:05 PM, Rodney W. Grimes wrote:
>> On Fri, Feb 22, 2019, 5:09 PM John Baldwin wrote:
>>
>>> On 2/22/19 11:45 AM, Rodney W. Grimes wrote:
>>>>> I was recently able to install base/binutils and base/gcc into an amd64
>>> VM
>>>>&g
rts
>> patches can be finished.
>>
>> The source patches are here:
>> https://github.com/bsdjhb/freebsd/compare/master...base_gcc
>
> Phabricator?
Eventually, wanted a first cut of the entire patchset in context to see
++
XCPP=/usr/bin/cpp
X_COMPILER_TYPE=gcc
WITH_BASE_GCC=yes
WITHOUT_GCC=yes
WITHOUT_CLANG_IS_CC=yes
Thoughts?
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https
ine to match GCC's behavior.
So to be clear, this isn't saying that the implicit PIC setting is
wrong. It is saying that the llvm backend incorrectly interprets
the clang front-end's implicit PIC setting as being an explicit PIC
setting for the purposes of choosing the TLS model to us
On 10/15/18 11:55 AM, Warner Losh wrote:
>
>
> On Mon, Oct 15, 2018 at 12:25 PM John Baldwin <mailto:j...@freebsd.org>> wrote:
>
> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Ba
On 10/15/18 11:06 AM, Warner Losh wrote:
>
>
> On Mon, Oct 15, 2018, 10:20 AM John Baldwin <mailto:j...@freebsd.org>> wrote:
>
> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via pou
poudriere in a qemu image of mips64 would
be very unpleasant). I think probably base/binutils just needs to drop the
names with a full tuple if possible.
--
John Baldwin
___
On 10/12/18 5:48 PM, Mark Millard wrote:
> On 2018-Oct-10, at 3:13 PM, John Baldwin wrote:
>
>> On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote:
>>> [Actually devel/gettext-tools is a build time dependency: it should not be
>>> using
>>>
;> has that information. /usr/ports/base/README does not
>> reference https://wiki.freebsd.org/ExternalGCC either.
The README predates the wiki page by a fair bit.
The current known issue I need to get back to with base/gcc is that it
improperly look
N} >= 120
+CONFIGURE_ARGS+= --enable-initfini-array
+.endif
+
.if ${ARCH:Mmips*}
PLIST_SUB+=MIPS=""
.else
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
guarantee ABI stable in a stable branch.
For the xtoolchain packages I want to strip the versions entirely since they
are the OS version of the machine that built the package and not the target
version of the OS being built (and they should really
cc on a regular basis on platforms they have been ported to to
detect regressions. At some point we are going to want to have
package repositories with those available as well, but perhaps I can
work with Xin Li to start building worlds via external toolchains
which can then be used as CROSS_SYSROOTs t
On Monday, April 09, 2018 08:58:29 PM Alexander Kabaev wrote:
> On Mon, 09 Apr 2018 12:27:18 -0700
> John Baldwin <j...@freebsd.org> wrote:
>
> > On Saturday, April 07, 2018 10:14:47 PM Alexander Kabaev wrote:
> > > On Sat, 7 Apr 2018 17:01:30 -0700
> > >
-freebsd12.0-gnueabihf -dM -E - -i neon
> #define __ARM_NEON 1
> #define __ARM_NEON_FP 0x4
> #define __ARM_NEON__ 1
Re: runtime, I have patches in review to add AT_HWCAP for native FreeBSD/arm
binaries. Right now it doesn't support a NEON hwcap but it should be easy to
from-scratch build:
This was fixed in HEAD in r309775 which hasn't been MFC'd. There were some
followup fixes in r312897 as well. I'll merge those two to 11 in a sec.
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.f
On Friday, August 25, 2017 12:30:11 PM Warner Losh wrote:
> On Fri, Aug 25, 2017 at 12:27 PM, Ed Maste <ema...@freebsd.org> wrote:
>
> > On 25 August 2017 at 14:07, Ryan Libby <rli...@gmail.com> wrote:
> > > On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin <j.
gt; This GDB was configured as "powerpc-marcel-freebsd"...
> Failed to open vmcore: unsupported architecture
This is a different problem with libkvm. I would start with 'ps -M' and use
a debugger to step through the _powerpc_probe and _powerpc64_probe routines in
libkvm to see why th
ich they
# understand. Do this unconditionally as it is harmless when not needed,
# but critical for these newer versions.
#
.if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
CFLAGS+=-gdwarf-2
.endif
--
John Baldwin
__
Only a few comments in reply to avoid banging my head against a brick wall and
then I'm done:
On Friday, August 30, 2013 3:33:21 am David Chisnall wrote:
On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote:
Also, unless you plan on desupporting all non-x86 platforms, you _still_
it in 10.x either. I have not seen any convincing
argument as to why leaving GCC in the base for 10.x impedes anything.
Because clang isn't sufficient for so many non-x86 platforms we can't
really start using clang-specific features yet anyway.
--
John Baldwin
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote:
To summarise the current issues:
Our libstdc++ is ancient. It supports C++98 well, it kind-of supports
C++03. It doesn't support C++11 at all and never will, nor
On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote:
On 14 Jan 2013, at 18:58, John Baldwin wrote:
I'm less certain. Note that you can't inline mutex ops until you expose
the mutexes themselves to userland (that is, making pthread_mutex_t not
be opaque).
This is one
cases.
I'm less certain. Note that you can't inline mutex ops until you expose
the mutexes themselves to userland (that is, making pthread_mutex_t not
be opaque).
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org
format provide any sort of notation for
encoding the path to the interpreter (similar to ELF)? If not, you might want
to at least make the path to 'lli' be configurable via a tunable and/or sysctl
(e.g. if using a newer version of clang in /usr/local).
--
John Baldwin
as your single-user shell. Of course, that would
perhaps let you still be able to recompile things if you had a static
toolchain. :)
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
40 matches
Mail list logo
