Ed Maste emaste at freebsd.org wrote on
Wed May 23 14:18:34 UTC 2018 :
> On 23 May 2018 at 10:15, Rodney W. Grimes
> wrote:
> >> Author: eadler
> >> Date: Wed May 23 10:45:32 2018
> >> New Revision: 334089
> >> URL: https://svnweb.freebsd.org/changeset/base/334089
> >>
> >> Log:
> >> dumpon: po
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
--- all_subdir_usr.sbin/pmc ---
In file included from
/workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/ios:216:0,
from
/workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/iostrea
Brad Davis brd at FreeBSD.org wrote on
Mon Jun 4 18:41:03 UTC 2018 :
> On Mon, Jun 4, 2018, at 10:57 AM, Rodney W. Grimes wrote:
. . .
> > Iirc some of the make release stuff calls into here, but that
> > may of changed to use src/Makefile targets. distrib-dirs comes
> > to mind.
>
> Sure, but t
On 2018-Jun-5, at 10:49 AM, Dimitry Andric wrote:
> On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain
> wrote:
>>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
>>
>> --- all_subdir_usr.sbin/pmc ---
>> In file included from
>> /workspace/obj/workspace/
[Just fixing a dumb typo in a build number.]
On 2018-Jun-5, at 12:22 PM, Mark Millard wrote:
> On 2018-Jun-5, at 10:49 AM, Dimitry Andric wrote:
>
>> On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain
>> wrote:
>>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleT
Cy Schubert Cy.Schubert at cschubert.com wrote on
Wed Jun 6 04:10:39 UTC 2018 :
> Oops, I should have pasted this into my previous email.
>
> --- cmd_pmc_filter.o ---
> /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0
> --sysroot=/export/obj/opt/src/svn-current/amd64.amd64/tmp
> -B/e
Eitan Adler eadler at FreeBSD.org wrote on
Wed Jun 6 06:42:14 UTC 2018 :
> + err(1, "calloc for kern.smp.maxcpus", size);
What is "size" used for when the string makes no use of it?
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
__
Jonathan T. Looney jtl at freebsd.org wrote on
Thu Jun 7 03:00:00 UTC 2018 :
> I believe the theory is that the compiler (remember, this is
> __builtin_memset) can optimize away portions of the zeroing, or can
> optimize zeroing for small sizes.
>
> For example, imagine you do this:
>
> stru
Eitan Adler eadler at FreeBSD.org wrote on
Mon Jun 11 05:05:22 UTC 2018 :
. . .
> - * positive numbers. If val <= 0 then digits(val) == 0.
> + * non-negative numbers. If val <= 0 then digits(val) == 0.
> */
>
> -int
> +int __pure2
> digits(int val)
> {
> int cnt = 0;
> + if (v
>From https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/6174/consoleText
>:
--- all_subdir_usb/muge ---
cc1: warnings being treated as errors
/usr/src/sys/dev/usb/net/if_muge.c: In function 'lan78xx_chip_init':
/usr/src/sys/dev/usb/net/if_muge.c:1096: warning: implicit declaration of
fun
Warner Losh imp at FreeBSD.org wrote on
Wed Jun 13 22:00:04 UTC 2018 :
> Author: imp
> Date: Wed Jun 13 22:00:02 2018
> New Revision: 335091
> URL:
> https://svnweb.freebsd.org/changeset/base/335091
>
>
> Log:
> Make it possible to use print_controller from another program
>
> Rename pr
Stephen J. Kiernan stevek at FreeBSD.org
Wed Jun 20 00:41:33 UTC 2018
Author: stevek
Date: Wed Jun 20 00:41:30 2018
New Revision: 335399
URL:
https://svnweb.freebsd.org/changeset/base/335399
Log:
MAC/veriexec implements a verified execution environment using the MAC
framework.
. . .
Bu
Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net wrote on
Fri Jan 19 18:39:03 UTC 2018 (quoting style(9)):
> I think everyone glossed over:
>
> Parts of a for loop may be left empty. Do not put declarations inside
> blocks unless the routine is unusually complicated.
>
> Perhaps tha
Andriy Gapon avg at FreeBSD.org wrote on
Fri Jan 19 18:41:07 UTC 2018 :
> On 19/01/2018 20:30, Conrad Meyer wrote:
> > On Fri, Jan 19, 2018 at 9:37 AM, Rodney W. Grimes
> > wrote:
> >> If you think in assembler it is easy to understand why this is UB,
> >> most (all) architectures Right Logic or
Conrad Meyer cem at freebsd.org wrote on
Fri Jan 19 05:07:22 UTC 2018 :
> The spec says the behavior is undefined; not that the compiler has to
> produce a warning or error message. The compiler *does* get to
> arbitrarily decide what it wants to do when it encounters UB. It is
> wholly free to
Warner Losh imp at bsdimp.com wrote on
Fri Jan 26 06:02:04 UTC 2018 :
> It's a flaw in C++ that you have a choice here. All dtors should be
> virtual because you never know when you'll have new derived classes and
> have to hunt down a hard-to-find bug because you didn't go back and make it
> vir
Ian Lepore ian at freebsd.org wrote on
Fri Jan 26 16:56:09 UTC 2018 :
> Modern compilers will warn about a class with virtual functions and no
> virtual dtor, so just blindly including it is more harmful than
> prophylactic these days, IMO.
More reliable is to have non-virtual destructors be, say
> Author: daichi
> Date: Fri Sep 20 17:37:23 2019
> New Revision: 352558
> URL:
> https://svnweb.freebsd.org/changeset/base/352558
>
>
> Log:
> top(1): support multibyte characters in command names (ARGV array)
> depending on locale.
>
>- add setlocale()
>- remove printable() func
> Author: dim
> Date: Tue Aug 20 17:39:32 2019
> New Revision: 351253
> URL:
> https://svnweb.freebsd.org/changeset/base/351253
>
>
> Log:
> Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
>
> Rework recursive_timed_mutex so that it uses __thread_id instead of
> using
Warner Losh imp at bsdimp.com wrote on
Fri Aug 23 22:05:39 UTC 2019 :
> On Fri, Aug 23, 2019 at 12:26 PM Conrad Meyer wrote:
>
> > At expected peril of wading into a thread >4 emails deep,
> >
> > @Warner, modern GCC reports a similar warning; it just doesn't become
> > an error (at least in CI?
Hans Petter Selasky hps at selasky.org wrote on
Sat Jun 20 13:27:13 UTC 2020 :
> On 2020-06-20 13:10, Rodney W. Grimes wrote:
> >> Author: imp
> >> Date: Sat Jun 20 04:19:17 2020
> >> New Revision: 362422
> >> URL:https://svnweb.freebsd.org/changeset/base/362422
> >>
> >> Log:
> >>Increase the
Beyond being a breaking change for existing /boot/blacklist.txt
files, there is the non-operation issue:
. . .
+ram_excludelist_type="ram_excludelist" # Required for the kernel to find
# the blacklist module
. . .
In other words, it is still using the term
The following is more informational than anything as far
as I'm concerned. But there may be implications that I'm
unaware of. (I sometimes experiment with toolchain use
to see what the current status is for such use.)
I attempted to build a system for 32-bit powerpc using clang
and binutils, build
On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
> Am 08.07.20 um 09:01 schrieb Mark Millard:
>> The following is more informational than anything as far
>> as I'm concerned. But there may be implications that I'm
>> unaware of. (I sometimes experiment with toolchain use
>> to see what the current sta
This seems to have broken doing buildworld buildkernel and
other things using make:
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator shou
On 2020-Jul-8, at 20:35, Yuri Pankov wrote:
> Mark Millard wrote:
>> This seems to have broken doing buildworld buildkernel and
>> other things using make:
>> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
>> comparison operator should be either == or !=
>> make[2]: "/
Michal Meloun mmel at FreeBSD.org wrote on
Sat Jul 25 06:32:24 UTC 2020 :
> Author: mmel
> Date: Sat Jul 25 06:32:23 2020
> New Revision: 363510
> URL:
> https://svnweb.freebsd.org/changeset/base/363510
>
>
> Log:
> Revert r363123.
> As Emanuel poited me the Linux processes these clock assi
On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
> Am 08.07.20 um 09:01 schrieb Mark Millard:
>> The following is more informational than anything as far
>> as I'm concerned. But there may be implications that I'm
>> unaware of. (I sometimes experiment with toolchain use
>> to see what the current s
On 2020-Jul-25, at 13:59, Mark Millard wrote:
> On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
>
>> Am 08.07.20 um 09:01 schrieb Mark Millard:
>>> The following is more informational than anything as far
>>> as I'm concerned. But there may be implications that I'm
>>> unaware of. (I sometimes expe
> Author: manu
> Date: Sat Aug 8 16:56:20 2020
> New Revision: 364053
> URL:
> https://svnweb.freebsd.org/changeset/base/364053
>
>
> Log:
> release: RPI3: Add the RPI2 DTB
>
> The RPI2 v1.2 is using the same SoC as the RPI3 so it can boot this image
> but needs the RPI2 dtb.
>
>
> Author: delphij
> Date: Mon Aug 17 05:57:02 2020
> New Revision: 364292
> URL:
> https://svnweb.freebsd.org/changeset/base/364292
>
>
> Log:
> Don't explicitly specify c99 or gnu99 as the default is now gnu99.
>
> . . .
>
> Modified: head/lib/libc/tests/sys/Makefile
> ===
Hartmann, O. o.hartmann at walstatt.org wrote on
Thu Dec 24 21:34:56 UTC 2020 :
> According to the status of the wiki refered to by
> https://wiki.freebsd.org/git,
> most of
> the transition from svn to git has been done.
> According to the recent logs reported at
> https://cgit.freebsd.org/src
> On 2020-Dec-24, at 21:17, Mark Millard wrote:
>
> Hartmann, O. o.hartmann at walstatt.org wrote on
> Thu Dec 24 21:34:56 UTC 2020 :
. . .
I've done more exploring and so am more willing to be
explicit about commands now that I've tried some of this.
>> I can not find (easily) any hints
>>
On 2020-Dec-25, at 22:21, Mark Millard wrote:
>> On 2020-Dec-24, at 21:17, Mark Millard wrote:
>>
>> Hartmann, O. o.hartmann at walstatt.org wrote on
>> Thu Dec 24 21:34:56 UTC 2020 :
> . . .
Looks like I was over specific about where I did "git fetch"
from and so made some sequences overcom
Now it is clang builds that are broken, at least ones that use:
sys/compat/linuxkpi/common/include/linux/compiler.h
An example from:
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/14953/console
is:
14:32:22 --- all_subdir_lindebugfs ---
14:32:22 In file included from /usr/src/sys/compat
> Author: jeff
> Date: Mon Dec 16 20:15:04 2019
> New Revision: 355819
> URL:
> https://svnweb.freebsd.org/changeset/base/355819
>
>
> Log:
> Repeat the spinlock_enter/exit pattern from amd64 on other architectures to
> fix an assert violation introduced in r355784. Without this spinlock_ex
In:
+# Defines a variable for Binutils linker, to be used to workaround some
+# issue with LLVM LLD (i.e. support for PowerPC32 bit on PowerPC64)
+#
+# This is an unavoidable cross coupling with Makefile.inc1 and
+# normal builds works when CROSS_BINUTILS_PREFIX and could be removed
+# when LLD Po
Ronald Klop ronald-lists at klop.ws wrote on
Fri Dec 27 09:39:22 UTC 2019 :
QUOTE
Do powerpc people need to do something special while updating?
Like a clean buildkernel/buildworld. Or is this just a note for historical
bookkeeping?
END QUOTE
See https://lists.freebsd.org/pipermail/freebsd-ppc
On 2019-Dec-24, at 21:26, Mark Millard wrote:
> In:
>
> +# Defines a variable for Binutils linker, to be used to workaround some
> +# issue with LLVM LLD (i.e. support for PowerPC32 bit on PowerPC64)
> +#
> +# This is an unavoidable cross coupling with Makefile.inc1 and
> +# normal builds wor
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
> > URL: https://svnweb.freebsd.org/changeset/base/356289
> >
> > Log:
> > Look for cross toolchain makefil
> Author: jhb
> Date: Sat Jan 4 00:59:47 2020
> New Revision: 356344
> URL:
> https://svnweb.freebsd.org/changeset/base/356344
> . . .
> +MAKE_PARAMS_powerpc?=CROSS_TOOLCHAIN=powerpc64-gcc6
> . . .
> +TOOLCHAINS_powerpc= powerpc64-gcc6
> . . .
(I know that for now gcc9 is not in use b
Justin Hibbits chmeeedalf at gmail.com wrote on
Sun Jan 5 18:03:59 UTC 2020 :
> On Sun, 5 Jan 2020 12:21:53 -0500 Ed Maste wrote: >
> On Sun, 5 Jan 2020 at 11:59, Ed Maste wrote:
> > >
> > > Author: emaste
> > > Date: Sun Jan 5 16:59:24 2020
> > > New Revision: 356379
> > > URL: https://s
(Derived from O. Hartmann's report, despite his not
having the same source version, . . .)
In the code:
823 static struct filestat_list *
824 procstat_getfiles_sysctl(struct procstat *procstat, struct kinfo_proc
*kp,
825 int mmapped)
826 {
827 struct kinfo_file *k
>From https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/15810/console :
--- mmu_oea64.o ---
23:10:11 /usr/src/sys/powerpc/aim/mmu_oea64.c:933:7: error: format specifies
type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'unsigned
int' [-Werror,-Wformat]
===
Mark Millard
[I'm only claiming the new jemalloc is involved and that
reverting avoids the problem.]
I've been reporting to some lists problems with:
dhclient
sendmail
rpcbind
mountd
nfsd
getting SIGSEGV (signal 11) crashes and some core
dumps on the old 2-socket (1 core per socket) 32-bit
PowerMac G4 runnin
On 2020-May-3, at 01:26, nonameless at ukr.net wrote:
> --- Original message ---
> From: "Mark Millard"
> Date: 3 May 2020, 04:47:14
>
>
>
>> [I'm only claiming the new jemalloc is involved and that
>> reverting avoids the problem.]
>>
>> I've been reporting to some lists problems with:
[At around 4AM local time dhcient got a signal 11,
despite the jemalloc revert. The other exmaples
have not happened.]
On 2020-May-2, at 18:46, Mark Millard wrote:
> [I'm only claiming the new jemalloc is involved and that
> reverting avoids the problem.]
>
> I've been reporting to some lists p
[The bit argument ot bitmap_unset seems to be way
too large.]
On 2020-May-3, at 11:08, Mark Millard wrote:
> [At around 4AM local time dhcient got a signal 11,
> despite the jemalloc revert. The other exmaples
> have not happened.]
>
> On 2020-May-2, at 18:46, Mark Millard wrote:
>
>> [I'm on
This note just reports things from looking at 2
.core files (mountd and rpcbind) from the new
jemalloc context's failures. May be someone that
knows more can get something out of it. I've
not included any of the prior message history.
For mountd:
Core was generated by `/usr/sbin/mountd -r'.
Prog
[This report just shows some material for the
sendmail SIGSEGV's, based on truss output.]
I've returned to using the modern jemalloc because
it seems to show problems more, after having
caught the earlier reported dhclient example under
the older jemalloc context. (Again: jemalloc may
be exposing
[This report just shows an interesting rpcbind crash:
a pointer was filled with part of a string instead,
leading to a failed memory access attempt from the junk
address produced.]
Core was generated by `/usr/sbin/rpcbind'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x5024405c
[This explores process crashes that happen during system
shutdown, in a context not having MALLOC_PRODUCTION= .
So assert failures are reported as the stopping points.]
It looks like shutdown -p now, shutdown -r now, and the
like can lead some processes to assert during their exit
attempt, includi
[__je_sz_size2index_tab seems messed up in 2 of the
asserting contexts: first 384 are zero in both. More
before that is also messed up (all zero). I show the
details later below.]
On 2020-May-6, at 16:57, Mark Millard wrote:
> [This explores process crashes that happen during system
> shutdown,
[mountd failure example: also at sz_size2index_lookup assert
for the same zero'd memory problem.]
> On 2020-May-7, at 00:46, Mark Millard wrote:
>
> [__je_sz_size2index_tab seems messed up in 2 of the
> asserting contexts: first 384 are zero in both. More
> before that is also messed up (all zer
[More details for a sshd failure. The other
examples are omitted. The sshd failure also shows
a all-zeros-up-to-a-page-boundary issue, just for
a different address range.]
On 2020-May-7, at 12:06, Mark Millard wrote:
>
> [mountd failure example: also at sz_size2index_lookup assert
> for the same
[I caused nfsd to having things shifted in mmeory some to
see it it tracked content vs. page boundary for where the
zeros stop. Non-nfsd examples omitted.]
> . . .
>> nfsd hit an assert, failing ret == sz_size2index_compute(size)
>
> [Correction: That should have referenced sz_index2size_lookup(i
[A new kind of experiment and partial results.]
Given the zero'ed memory page(s) that for some of
the example contexts include a page that should not
be changing after initialization in my context
(jemalloc global variables), I have attempted the
following for such examples:
A) Run gdb
B) Attach
[Yet another new kind of experiment. But this looks
like I can cause problems in fairly sort order on
demand now. Finally! And with that I've much better
evidence for kernel vs. user-space process for making
the zeroed memory appear in, for example, nfsd.]
I've managed to get:
:
/usr/src/contrib
[stress alone is sufficient to have jemalloc asserts fail
in stress, no need for a multi-socket G4 either. No need
to involve nfsd, mountd, rpcbind or the like. This is not
a claim that I know all the problems to be the same, just
that a jemalloc reported failure in this simpler context
happens and
[I'm adding a reference to an old arm64/aarch64 bug that had
pages turning to zero, in case this 32-bit powerpc issue is
somewhat analogous.]
On 2020-May-13, at 00:29, Mark Millard wrote:
> [stress alone is sufficient to have jemalloc asserts fail
> in stress, no need for a multi-socket G4 eithe
Justin Hibbits chmeeedalf at gmail.com wrote on
Thu May 28 02:41:06 UTC 2020 :
> On Thu, 28 May 2020 00:49:03 + (UTC)
> Brandon Bergren wrote:
>
> > Author: bdragon
> > Date: Thu May 28 00:49:02 2020
> > New Revision: 361568
> > URL: https://svnweb.freebsd.org/changeset/base/361568
> >
> >
Warner Losh imp at bsdimp.com wrote on
Thu Jun 4 02:47:14 UTC 2020 :
> On Wed, Jun 3, 2020, 6:28 PM Rodney W. Grimes
> wrote:
>
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: gonzo
> > > Date: Wed Jun 3 22:18:15 2020
> > > New Revision: 361775
> > > URL: https://svnweb.freebsd.o
On 2020-May-13, at 08:56, Justin Hibbits wrote:
> Hi Mark,
Hello Justin.
> On Wed, 13 May 2020 01:43:23 -0700
> Mark Millard wrote:
>
>> [I'm adding a reference to an old arm64/aarch64 bug that had
>> pages turning to zero, in case this 32-bit powerpc issue is
>> somewhat analogous.]
>>
>
On 2020-Jun-11, at 13:55, Justin Hibbits wrote:
> On Wed, 10 Jun 2020 18:56:57 -0700
> Mark Millard wrote:
>
>> On 2020-May-13, at 08:56, Justin Hibbits wrote:
>>
>>> Hi Mark,
>>
>> Hello Justin.
>
> Hi Mark,
Hello again, Justin.
>>
>>> On Wed, 13 May 2020 01:43:23 -0700
>>> Mark Mi
On 2020-Jun-11, at 14:41, Brandon Bergren wrote:
> An update from my end: I now have the ability to test dual processor G4 as
> well, now that mine is up and running.
Cool.
FYI:
Dual processors are not required for the
problem to happen: the stress based testing
showed the problem just as
On 2020-Jun-11, at 14:42, Justin Hibbits wrote:
On Thu, 11 Jun 2020 14:36:37 -0700
Mark Millard wrote:
> On 2020-Jun-11, at 13:55, Justin Hibbits
> wrote:
>
>> On Wed, 10 Jun 2020 18:56:57 -0700
>> Mark Millard wrote:
. . .
>
>
>> That said, the attached patch effectively copies
>> what's
On 2020-Jun-11, at 16:49, Mark Millard wrote:
> On 2020-Jun-11, at 14:42, Justin Hibbits wrote:
>
> On Thu, 11 Jun 2020 14:36:37 -0700
> Mark Millard wrote:
>
>> On 2020-Jun-11, at 13:55, Justin Hibbits
>> wrote:
>>
>>> On Wed, 10 Jun 2020 18:56:57 -0700
>>> Mark Millard wrote:
> . . .
>>
On 2020-Jun-11, at 19:25, Justin Hibbits wrote:
> On Thu, 11 Jun 2020 17:30:24 -0700
> Mark Millard wrote:
>
>> On 2020-Jun-11, at 16:49, Mark Millard wrote:
>>
>>> On 2020-Jun-11, at 14:42, Justin Hibbits
>>> wrote:
>>>
>>> On Thu, 11 Jun 2020 14:36:37 -0700
>>> Mark Millard wrote:
>>>
[Just a better panic backtrace text copy.]
On 2020-Jun-11, at 20:29, Mark Millard wrote:
> On 2020-Jun-11, at 19:25, Justin Hibbits wrote:
>
>> On Thu, 11 Jun 2020 17:30:24 -0700
>> Mark Millard wrote:
>>
>>> On 2020-Jun-11, at 16:49, Mark Millard wrote:
>>>
On 2020-Jun-11, at 14:42,
There is another oddity in the code structure, in
that if pt was ever NULL the code would misuse the
NULL before the test for non-NULL is made:
pt = moea_pvo_to_pte(pvo, -1);
. . .
old_pte = *pt;
/*
* If the PVO is in the page table
[Yet another oddity.]
On 2020-Jun-11, at 21:05, Mark Millard wrote:
>
> There is another oddity in the code structure, in
> that if pt was ever NULL the code would misuse the
> NULL before the test for non-NULL is made:
>
>pt = moea_pvo_to_pte(pvo, -1);
> . . .
>
[This is not an objection to the version upgrade.]
FYI: I happen to have updated to head -r358132 on multiple
environments, not having done anything to force rebuilds
of things tied to ncurses.
armv7 / 32-bit powerpc : poudriere options displays look normal.
aarch64 / powerpc64 / amd64: they loo
John Baldwin jhb at FreeBSD.org wrote on
Thu Feb 27 16:55:01 UTC 2020:
> On 2/27/20 7:30 AM, Warner Losh wrote:
> > Author: imp
> > Date: Thu Feb 27 15:30:13 2020
> > New Revision: 358392
> > URL: https://svnweb.freebsd.org/changeset/base/358392
> >
> > Log:
> > _Static_assert is to be preferre
On 2020-Feb-27, at 16:37, John Baldwin wrote:
> On 2/27/20 2:45 PM, Mark Millard wrote:
>> John Baldwin jhb at FreeBSD.org wrote on
>> Thu Feb 27 16:55:01 UTC 2020:
>>
>>> On 2/27/20 7:30 AM, Warner Losh wrote:
Author: imp
Date: Thu Feb 27 15:30:13 2020
New Revision: 358392
>>>
[Ignoring llvm-project and libstdc++, I only find
about 24 other instances of "static_assert".]
On 2020-Feb-27, at 19:03, Mark Millard wrote
> On 2020-Feb-27, at 16:37, John Baldwin wrote:
>
>> On 2/27/20 2:45 PM, Mark Millard wrote:
>>> John Baldwin jhb at FreeBSD.org wrote on
>>> Thu Feb 27
In cleaning out my old gcc 4.2.1 related material I have patches in places
that have not been deleted:
M /usr/src/contrib/gcc/unwind-dw2.c
M /usr/src/contrib/gcc/unwind-dw2.h
Is /head/contrib/gcc deliberately being kept? (binutils
needing it for ld for 32-bit powerpc? System gdb needi
> Author: emaste
> Date: Sat Feb 29 13:15:01 2020
> New Revision: 358462
> URL:
> https://svnweb.freebsd.org/changeset/base/358462
>
>
> Log:
> src.opts.mk: simplify Clang and lld bootstrap defaults
>
> With the retirement of GCC 4.2.1 we can assume the host compiler supports
> C++11, a
Pedro Giffuni pfg at FreeBSD.org wrote on
Sat Feb 29 15:42:34 UTC 2020 :
> On 29/02/2020 07:40, Ed Maste wrote:
> > Author: emaste
> > Date: Sat Feb 29 12:40:27 2020
> > New Revision: 358459
> > URL: https://svnweb.freebsd.org/changeset/base/358459
> >
> > Log:
> >Remove contrib/gcc and contri
head -r358439 breaks unmodified ports that use, for example, clang70 and
clang++70:
https://lists.freebsd.org/pipermail/freebsd-emulation/2020-February/017672.html
https://lists.freebsd.org/pipermail/freebsd-emulation/2020-February/017675.html
show things like . . .
kBuild: Compiling HGSMIGuestR
Warner Losh imp at FreeBSD.org wrote on
Sun Mar 1 20:37:45 UTC 2020 :
> +# 20200301: bktr removed
> +OLD_DIRS+=usr/include/dev/bktr
> +OLD_FILES+=usr/include/dev/bktr/ioctl_bktr.h
> +OLD_FILES+=usr/include/dev/bktr/ioctl_meteor.h
> +.if ${TARGET_ARCH} == "i386"
> +OLD_FILES+=usr/include/machine/io
Konstantin Belousov kostikbel at gmail.com wrote on
Mon Mar 2 18:27:05 UTC 2020 ":
> On Mon, Mar 02, 2020 at 09:13:53AM -0800, Ryan Libby wrote:
> > On Mon, Mar 2, 2020 at 12:45 AM Alexander V. Chernikov > ipfw.ru> wrote:
> > >
> > > 28.02.2020, 18:32, "Ryan Libby" :
> > > > Author: rlibby
> > >
Gleb Smirnoff glebius at FreeBSD.org wrote on
Wed Mar 4 23:49:22 UTC 2020 :
> author: glebius
> Date: Wed Mar 4 23:49:20 2020
> New Revision: 358658
> URL:
> https://svnweb.freebsd.org/changeset/base/358658
>
>
> Log:
> Add a missing bktr header.
>
> Modified:
> head/ObsoleteFiles.inc
>
> Author: cem
> Date: Sun Apr 12 18:04:20 2020
> New Revision: 359829
> URL:
> https://svnweb.freebsd.org/changeset/base/359829
>
>
> Log:
> Add queue(2) debug macros as build options
>
> Add QUEUE_MACRO_DEBUG_TRACE and QUEUE_MACRO_DEBUG_TRASH as proper kernel
> options. While here, al
> Author: emaste
> Date: Tue Jun 26 16:50:41 2018
> New Revision: 335672
> URL:
> https://svnweb.freebsd.org/changeset/base/335672
>
>
> Log:
> Build linprocfs and linsysfs also on arm64
>
> Sponsored by: Turing Robotic Industries
>
> . . .
https://ci.freebsd.org/job/FreeBSD-head
These are the gcc/g++ 4.2.1 based targets.
For example . . .
https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6261/consoleText
--- all_subdir_sbin/devd ---
/usr/src/sbin/devd/devd.cc: In member function 'std::string
config::shell_quote(const std::string&)':
/usr/src/sbin/devd/devd.cc:652
[I used the wrong Email address the first time.]
On 2018-Jun-27, at 6:31 PM, Warner Losh wrote:
>
>
>
> On Wed, Jun 27, 2018, 7:27 PM Mark Millard wrote:
> These are the gcc/g++ 4.2.1 based targets.
>
> For example . . .
>
> https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6261/conso
[ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
for FreeBSD-head-amd64-gcc. It looked to me like the most likely
breaking-change was the following but I've not tried personal
builds to confirm.
]
It looks to me that:
> Author: jhb
> Date: Thu Jun 28 21:26:14 2018
> New R
On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
> breaking-change was the following but I've not tried personal
> builds to confirm.
> ]
>
> It looks to me
On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>
>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>> breaking-change was the following but I've not tried
clang example:
( https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9257/consoleText )
--- key_debug.o ---
/usr/src/sys/netipsec/key_debug.c:89:1: error: no previous prototype for
function 'kdebug_sadb_type' [-Werror,-Wmissing-prototypes]
kdebug_sadb_type(uint8_t type)
^
/usr/src/sys/netipsec/
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally builds via a devel/*-gcc .]
On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>>
>>> On 2018-Jun-28, at 5:
On 2018-Jun-29, at 2:37 PM, Mark Millard wrote:
> [I expect this is more than just amd64-gcc related but that is all
> that ci.freebsd.org normally builds via a devel/*-gcc .]
>
> On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
>
>> On 6/28/18 7:54 PM, Mark Millard wrote:
>>> On 2018-Jun-28,
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8358/consoleText
--- all_subdir_armv8crypto ---
/usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:10: fatal error: 'arm_neon.h'
file not found
#include
^~~~
1 error generated.
*** [armv8_crypto_wrap.o] Error code 1
https://c
On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
> On 6/29/18 2:37 PM, Mark Millard wrote:
>> [I expect this is more than just amd64-gcc related but that is all
>> that ci.freebsd.org normally builds via a devel/*-gcc .]
>
> As indicated by my other mail, this is i386 and amd64 specific as it
> o
On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
> On 6/30/18 9:17 AM, Mark Millard wrote:
>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>>
>>> On 6/29/18 2:37 PM, Mark Millard wrote:
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally b
On 2018-Jun-30, at 10:04 AM, Mark Millard wrote:
> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
>
>> On 6/30/18 9:17 AM, Mark Millard wrote:
>>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>>>
On 6/29/18 2:37 PM, Mark Millard wrote:
> [I expect this is more than just amd64-
On 2018-Jun-30, at 11:53 AM, John Baldwin wrote:
> On 6/30/18 10:19 AM, Mark Millard wrote:
>
>
> On 2018-Jun-30, at 10:04 AM, Mark Millard wrote:
>
>> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
>>
>>> On 6/30/18 9:17 AM, Mark Millard wrote:
On 2018-Jun-30, at 7:51 AM, John Bal
https://ci.freebsd.org/job/FreeBSD-head-riscv64-build/9229/consoleText
--- utils.o ---
/usr/local/bin/riscv64-unknown-freebsd11.1-gcc
--sysroot=/workspace/obj/workspace/src/riscv.riscv64/tmp
-B/usr/local/riscv64-unknown-freebsd11.1/bin/ -O2 -pipe -march=rv64imafdc
-mabi=lp64d -g -MD -MF.dep
My brain finally engaged for showing exactly what files are included
for the gcc builds: the .meta files include that information explicitly
(along with other files that are opened during the operation).
amd64 is as I reported, just one header file from gcc: float.h .
powerpc64 builds Lex/Lexer.c
-r335879 broke ci.freebsd.org's FreeBSD-head-amd64-build :
https://ci.freebsd.org/job/FreeBSD-head-amd64-build/
shows:
--- ia32_genassym.o ---
In file included from /usr/src/sys/compat/ia32/ia32_genassym.c:6:
In file included from /usr/src/sys/sys/systm.h:113:
/usr/src/sys/sys/kpilite.h:33:10: f
1 - 100 of 166 matches
Mail list logo
