On Sun, 30 Jan 2011, Alexander Best wrote:
> i might have described things a bit too complicated. basically i want to
> have CPUTYPE ?= core2 in my make.conf. clang is capable of producing
> core2 specific code, however core2 always gets downgraded by
> share/mk/bsd.cpu.mk to nocona in order not
Pedro kindly made me aware of
http://svn.freebsd.org/viewvc/base?view=revision&revision=181538
where David made -fno-math-errno the default for GCC with the following
background:
Our libm doesn't support the SysV mistake of setting errno, and never
has. This will need to be fixed upstrea
On Sun, 6 Feb 2011, David Schultz wrote:
> That is correct. Basically nobody sets errno in the math library
> anymore, except for compatibility with old apps written for the
> System V math library. BSD never has and never will. IEEE 754
> floating point exception flags are much saner and faster
On Mon, 7 Feb 2011, Gerald Pfeifer wrote:
> I'll see what I can do about it. (I also checked, and this plus
> the one on -mfancy-math-387 are the only open issues from someone
> @freebsd.org.)
Good news, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37072 does
not actually se
On Tue, 15 Feb 2011, Pedro F. Giffuni wrote:
> I think gcc/config/i386/freebsd.h needs an integral revision.
I understand Loren Rittle has done that some two years ago, which
lead to quite some changes to upstream GCC.
> The FreeBSD port already uses CC1_SPEC and ASM_SPEC, just like is
> done for
Hi guys,
just wondering whether any of you has input/guidance on the mail
below regarding FreeBSD and profile handing in GCC?
Feel free to let Joseph know directly (cc:ing me), or I'll be
happy to relay back anything.
Gerald
-- Forwarded message --
From: Joseph S. Myers
To: gcc
On Wed, 22 Jun 2011, Damjan Marion wrote:
> I see 3 options to fix this:
>
> 1. Ask clang folks to patch llvm to use old mnemonics ("mov r0, r0, rrx"
> instead of "rrx r0,r0")
> 2. Maintain same patch for freebsd only
> 3. patch binutils to support this new mnemonics
4. Finally upgrade to a m
On Mon, 17 Oct 2011, Alexander Best wrote:
> any chance we could disable -Wtautological-compare for clang? i don't
> think comparing an unsigned int against < 0 is worth a warning. actually
> it's always nice to have such a seatbelt, in case somebody changes the
> type to int and forgets to intr
On Tue, 18 Oct 2011, Matthias Andree wrote:
>> any chance we could disable -Wtautological-compare for clang? i don't
>> think comparing an unsigned int against < 0 is worth a warning.
>> actually it's always nice to have such a seatbelt, in case somebody
>> changes the type to int and forgets to
On Mon, 12 Dec 2011, Kostik Belousov wrote:
> Does anybody on toolchain@ know how to submit the gas change to
> maintainers for inclusion into mainline, or better, can submit it
> himself ? I assume that no copyright assignment is required for this
> trivial flip of settings.
I would just send to
On Tue, 11 Sep 2012, Erik Cederstrand wrote:
> So can we do a sweep on the ports tree and mark the 2232 ports with
> USE_GCC=4.2 until they can actually build with clang? This could allow
> the clang switch to proceed. Hopefully, waiting for GCC to compile just
> to install some tiny port will b
On Fri, 12 Oct 2012, Andriy Gapon wrote:
> $ gcc46 --version
> gcc46 (FreeBSD Ports Collection) 4.6.3
>
> I think that the above should have just "gcc" instead of "gcc46". The
> version is reported separately from the compiler name.
I dug into this, and from what I can tell this is basically pr
ssage --
From: Gerald Pfeifer
To: ports-committ...@freebsd.org, svn-ports-...@freebsd.org,
svn-ports-h...@freebsd.org
Date: Sat, 22 Dec 2012 02:11:32 + (UTC)
Subject: svn commit: r309380 - head/emulators/wine-devel
Author: gerald
Date: Sat Dec 22 02:11:32 2012
New Revision: 30938
On Sat, 22 Dec 2012, Roman Divacky wrote:
> Can you send me the preprocessed source file? It when it crashes
> it tells you where it is, ie:
>
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> cc: note: diagnostic msg:
On Fri, 25 Jan 2013, David Chisnall wrote:
> In 10.0, the plan is not to ship any GPL'd code, so I'd like to
> start disconnecting things from the default build, starting with
> gcc. I've been running a gcc-free system for a while, and I think
> all of the ports that don't build with clang are now
On Sat, 26 Jan 2013, Konstantin Belousov wrote:
> Ports should use port-provided compiler, and be untangled from the base
> toolchain. I believe that forcing ports committers to port 20K+ packages
> to clang is a waste of the FreeBSD resources and is is destined to fail
> despite the efforts.
I ag
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote:
> A possible hack could be to add a check for USE_GCC=any to behave like
> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
> from ports for a lot of people on HEAD I suppose.
I am planning to work on this a bit more once the two
On Sat, 24 Aug 2013, Warner Losh wrote:
>> "If you push gcc out to a port, and you have the 'external compiler'
>> toolchain support working correctly enough to build with this, why
>> don't we just push clang out to a port, and be done with it?"
> This is a stupid idea. It kills the tightly inte
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote:
> lang/gcc42 is on the list of ports that have USE_GCC=any. So you would
> need to fix it first to be able to compile it with clang 3.3 from base.
I don't think so. :-)
You can install lang/gcc which builds just fine with clang, and
then use lang/gcc
On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be
> compiled with lang/gcc. I checked this once and the number of ports
> that require strictly gcc 4.2.1 was bigger for me then number of
> ports that can't be compiled with clang b
On Wed, 9 Apr 2014, Anton Shterenlikht wrote:
> I haven't tried gfortran on amd64 for a long time,
> so I'm probably doing something wrong:
>
> On ia64 11-current:
>
> $ cat z.f90
> end
> $ gfortran47 z.f90
> $ ./a.out
> $
>
> On amd64 11-current:
>
> $ cat z.f90
> end
> $ gfortran47 z.f90
On Thu, 12 Nov 2015, William A. Mahaffey III wrote:
> I pkg-installed amd64-gcc over the weekend hoping for Graphite
> (auto-loop parallelization) support, but no go.
When you say "amd64-gcc" where did you obtain that from? As a
FreeBSD port/package, or somewhere else?
> just did a 'portsnap f
Hi William,
On Tue, 17 Nov 2015, William A. Mahaffey III wrote:
I have found & apparently isolated what looks like a compiler bug in
(pkg-installed, box-stock) gcc48 under FreeBSD 9.3R, see attached. I
also prepped a tarball w/ the files that produced the problem for me.
Do I post that here or
On Sun, 15 Nov 2015, Gerald Pfeifer wrote:
> I just committed changes to lang/gcc6-devel and lang/gcc5-devel to
> add support for Graphite with a new option GRAPHITE. This is off
> by default, but you can enable it, rebuild the port, and then have
> what you've been looking for.
On Thu, 3 Dec 2015, Dimitry Andric wrote:
>> I just did a pkg-upgrade of gcc5, & upgraded the port as well. I noticed
>> that a 'make showconfig' in the port now shows Graphite support enabled by
>> default. However, a 'gcc -v --help' on the pkg installed version shows no
>> libisl, req'd for Gr
Hi William,
On Thu, 10 Dec 2015, William A. Mahaffey III wrote:
> However, pkg did reinstall gcc5-devel-5.2.1.s20151124 due to changed
> options. I cd'ed to /usr/ports/lang/gcc5-devel & poked around a bit. I
> saw no files or directories dated today, the latest was dated Dec 02,
> the last time
On Tue, 1 Mar 2016, William A. Mahaffey III wrote:
> When I run gcc5 from the CLI or under make as a regular user, it reports no
> Graphite support compiled in. When I update the gcc5-devel port, it reports
> Graphite enabled:
>
>
> [root@devbox, gcc5-devel, 10:24:47am] 504 % make showconfig
> ==
I got a user report, and could reproduce this, that building
GCC (lang/gcc, but also current HEAD, so probably pretty much
any version) with FreeBSD 11 and LANG = en_US.UTF-8 we get
conflicting entires in $BUILDDIR/gcc/options.h such as
OPT_d = 135, /* -d */
OPT
On Mon, 13 Jun 2016, Andreas Tobler wrote:
> Should be fixed. I forgot to commit the lang/gcc6 patch.
Thanks, Andreas!
I see this in the lang/gcc6 now (and in case anyone is wondering,
lang/gcc6-devel gets new stuff earlier from upstream, whereas
lang/gcc6 needs to wait for the next release --
On Sat, 28 May 2016, Warner Losh wrote:
> armv6*-*-freebsd is only hard float ABI for FreeBSD 11.
:
> Are you saying that we need to get these changes to the ports in place
> to support hard float?
For the record, this has now happened with the great help of
Andreas Tobler (both upstream and in o
On Thu, 13 Apr 2017, Pedro Giffuni wrote:
> I didn’t want to get into this but the problem is that as part of it's
> build/bootstrapping process, GCC historically takes system headers
> and attempts to “fix” them. I am unsure the fixes do anything at all
> nowadays but the effect is that the compil
Hi everyone,
I am testing a patch for gcc5-devel right now that will disable fixincludes (or
rather its fixed files) being packaged.
Should that work fine for you, I will push this back to gcc5 the following days.
That said, the change that triggered this is what I would expect on CURRENT,
not
Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard :
>A primary test is building lang/gcc5-devel under release/11.0.1
>and then using it under stable/11 or some draft of release/11.1.0 .
Thank you, Mark. Let me know how it went. In the meantime I'll prepare the
change for gcc5 itself.
>I
Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard :
>I'm not currently set up to run more than head on
>any of amd64, powerpc64, powerpc, aarch64, or armv6/7
>(which are all I target). And I'm in the middle of
>attempting a fairly large jump to head -r320458 on
>those.
Oh, then I had misu
Am 3. Juli 2017 13:30:13 GMT+08:00 schrieb Mark Millard :
>[More on the behavior: it is more complicated than
>previously shown.]
It's actually pretty simple (I think). Mk/bsd.gcc.mk only uses lang/gcc* ports
that represent releases, not lang/gcc*-devel that represent snapshots.
So your patch
On Tue, 4 Jul 2017, Mark Millard wrote:
> I have submitted: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315
> for the below, presuming for now that the problem is on the GCC side
> of things. Hopefully it is not tied to include-fixed/ now being empty.
>
> [We will see if the GCC folks object to
On Wed, 8 Jun 2016, Dimitry Andric wrote:
>> I got a user report, and could reproduce this, that building
>> GCC (lang/gcc, but also current HEAD, so probably pretty much
>> any version) with FreeBSD 11 and LANG = en_US.UTF-8 we get
>> conflicting entires in $BUILDDIR/gcc/options.h such as
>>
>>
On Fri, 14 Apr 2017, Alexander Kabaev wrote:
> it was suggested multiple times that the whole fixinc step is
> ultimately harmful and serves no useful purpose and probably should be
> disabled in built packages outright. Is there a reason not to do it?
> Even Redhat appears to do the slimming in th
On Sun, 29 Oct 2017, Eddy Petrișor wrote:
> Yep --and it is even more complicated: gcc vs. clang are sometimes
> different for the target listed. . .
>
> For example -m32 for amd64 changes the clang result:
>
> # clang -dumpmachine
> x86_64-unknown-freebsd12.0
>
> ..
>
> # gcc7 -dumpmachine
>
Hi Mark,
On Sat, 14 Jul 2018, Mark Millard via freebsd-toolchain wrote:
> Looks like gcc8 was not added to, for example,
> https://svnweb.freebsd.org/ports/head/Mk/bsd.gcc.mk :
I've done that earlier today:
r474663 | gerald | 2018-07-15 05:59:51 + (So, 15 Jul 2018) | 6 lines
Add support
On Sun, 15 Jul 2018, Gerald Pfeifer wrote:
>> https://svnweb.freebsd.org/ports/head/Mk/bsd.default-versions.mk :
>>
>> # Possible values: 4.9, 5, 6, 7
>> GCC_DEFAULT?= 6
> Given that this is still the first release of the GCC 8 series,
> I'm a bit
Hi Tijl, hi everyone,
and let me add Andreas who has been helping on the GCC side (both
ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
And first of all, let me apologize. Clearly the experience both Tijl
as a contributor made, as well as the one some of our users inclu
Hmm, I received zero feedback on this proposal, when it appeared
important for a number of users.
What's your take, Andreas, Tijl (your patch essentially with a bit
of an updated description), and toolchain?
Gerald
On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
> Hi Tijl, hi everyone,
>
On Mon, 8 Apr 2019, Tijl Coosemans wrote:
>> This patch make 3 the default for gfortran.
> s/make/makes/ but otherwise the patch looks fine.
Thank you, Tijl.
I updated lang/gcc8 (including bumping its PORTREVISION) and will
apply the same to lang/gcc8-devel next, and then lang/gcc9-devel
so lang/
On Thu, 26 Dec 2019, Mark Millard wrote:
> I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an
> ELFv1 clang environment) and it reported (listing just one of the
> examples that pointed to vec_step):
I maintain this is a bug in clang which should be address there.
https://bugs.free
45 matches
Mail list logo
