On 06/12/10 16:16, M. Warner Losh wrote:
I plan on fixing this problem
That's good news, since I'm obviously too stupid to understand why it
exists. :) I look forward to seeing your solution.
Doug
--
... and that's just a little bit of history repeating.
-
- Original Message
> From: Hans Petter Selasky
> To: PseudoCylon
> Cc: freebsd-...@freebsd.org; freebsd-current@freebsd.org
> Sent: Sat, June 12, 2010 12:30:18 AM
> Subject: Re: run(4) patch
>
>> On Friday 11 June 2010 08:27:53 PseudoCylon wrote:
>> Hello,
>>
>>
>> Here is a patch for
(from the freebsd-current mailing list)
Dnia 06.06.2010 b. f. napisał/a:
> Is anybody planning to update the base system heimdal, which has been
> largely untouched since May 2008? In addition to the many other
> bug-fixes and improvements in the current version 1.3.3 (see, for
> example:
I de
In message: <4c13f53f.3050...@freebsd.org>
Doug Barton writes:
: On 06/12/10 08:10, M. Warner Losh wrote:
: > In message:<4c1315f9.6000...@freebsd.org>
: > Doug Barton writes:
: > : On 06/11/10 14:18, M. Warner Losh wrote:
: > :> "This" is building the proper set of tools
On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote:
> I'm at least sure that the compiler can't if it is linked from another
> object file.
Is that still true if LTO is enabled?
--
Bruce Cran
___
freebsd-current@freebsd.org mailing list
http:
Bernd Walter wrote:
> But calling my_abolsutely_not_inlineable_memset should work IMHO.
Try gcc -fno-builtin-memset
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "f
On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > I'm not sure when removing a memset is allowed.
>
> Always, if the compiler can determine that the data will not be used
> later.
I'm at least sure that the compiler can't if it is linked from another
TB --- 2010-06-12 20:57:45 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 20:57:45 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-06-12 20:57:45 - cleaning the object tree
TB --- 2010-06-12 20:57:54 - cvsupping the source tree
TB --- 2010-06-12 20:57:54 - /usr/b
TB --- 2010-06-12 20:10:37 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 20:10:37 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-12 20:10:37 - cleaning the object tree
TB --- 2010-06-12 20:10:48 - cvsupping the source tree
TB --- 2010-06-12 20:10:48 - /usr
TB --- 2010-06-12 20:37:20 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 20:37:20 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-06-12 20:37:20 - cleaning the object tree
TB --- 2010-06-12 20:37:30 - cvsupping the source tree
TB --- 2010-06-12 20:37:30 - /usr
On 06/12/10 08:10, M. Warner Losh wrote:
In message:<4c1315f9.6000...@freebsd.org>
Doug Barton writes:
: On 06/11/10 14:18, M. Warner Losh wrote:
:> "This" is building the proper set of tools for the target. It is easy
:> to do, and only a couple lines of Makefile foo in Makefile
TB --- 2010-06-12 18:41:25 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 18:41:25 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-06-12 18:41:25 - cleaning the object tree
TB --- 2010-06-12 18:41:38 - cvsupping the source tree
TB --- 2010-06-12 18:41:38 - /usr/bin/c
Bernd Walter writes:
> I'm not sure when removing a memset is allowed.
Always, if the compiler can determine that the data will not be used
later.
In more general terms, the compiler is allowed to make any changes it
likes to the program as long as the end result behaves exactly like it
would if
On Thu, Jun 10, 2010 at 12:46 PM, John Baldwin wrote:
> I've had several folks ask me recently about importing etcupdate
> (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate
> tool for updating /etc during upgrades. Do folks have any strong objections
> to doing so? Mor
On Sat, Jun 12, 2010 at 05:35:28PM +0200, Ulrich Spörlein wrote:
> On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote:
> > Ulrich Spörlein writes:
> > > optimizing compilers have a tendency to remove assignments that have
> > > no side effects. The code in sys/crypto/sha2/sha2.c is do
On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote:
> Ulrich Spörlein writes:
> > optimizing compilers have a tendency to remove assignments that have
> > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of
> > zeroing variables, which is however optimized away. [..
In message: <4c1315f9.6000...@freebsd.org>
Doug Barton writes:
: On 06/11/10 14:18, M. Warner Losh wrote:
: > "This" is building the proper set of tools for the target. It is easy
: > to do, and only a couple lines of Makefile foo in Makefile.inc1
: > instead of in bsd.own.mk. It is
* Dag-Erling Smørgrav wrote:
> Ed Schouten writes:
> > Well, I've been thinking about this as well, but keep in mind that
> > tblgen really has no use by itself and strongly depends on the version
> > of your source tree. Even if we backport a tiny patch from the Clang
> > repository, we cannot t
On 12.06.10 15:57, Andreas Tobler wrote:
On 12.06.10 12:59, FreeBSD Tinderbox wrote:
TB --- 2010-06-12 09:19:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 09:19:14 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-12 09:19:15 - cleaning the object tree
On 12.06.10 12:59, FreeBSD Tinderbox wrote:
TB --- 2010-06-12 09:19:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 09:19:14 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-12 09:19:15 - cleaning the object tree
TB --- 2010-06-12 09:19:27 - cvsupping the
Ed Schouten writes:
> Well, I've been thinking about this as well, but keep in mind that
> tblgen really has no use by itself and strongly depends on the version
> of your source tree. Even if we backport a tiny patch from the Clang
> repository, we cannot trust tblgen to do the right thing anymor
Hi All!
The linked[1][2] stackgap patches why not included in FreeBSD tree? I
used this patches for a long while (~2 year ago), without problem. And
I have an updated patch for 7-STABLE:
http://peonia.teteny.elte.hu/freebsd/patches/stable/stable/20091229025818-randomize_mmap.patch
[1] http://peop
Quoting Mario Sergio Fujikawa Ferreira :
> Hi,
>
> On 25/05/2010 05:45, Bernhard Froehlich wrote:
>> On Thu, 20 May 2010 23:05:53 -0300, Mario Sergio Fujikawa Ferreira
>> wrote:
>>> Hi,
>>>
>>> I recently reinstalled my FreeBSD 8-STABLE box to move from
>>> i386 to amd64. The h
On 12.06.2010 14:57, Sam Fourman Jr. wrote:
> On Thu, Jun 10, 2010 at 1:14 PM, Joel Dahl wrote:
>> On 10-06-2010 13:46, John Baldwin wrote:
>>> I've had several folks ask me recently about importing etcupdate
>>> (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate
>>> tool
On Thu, Jun 10, 2010 at 1:14 PM, Joel Dahl wrote:
> On 10-06-2010 13:46, John Baldwin wrote:
>> I've had several folks ask me recently about importing etcupdate
>> (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate
>> tool for updating /etc during upgrades. Do folks have
On 06/10/2010 20:45, Lawrence Stewart wrote:
> +1 for adding to base (and updating handbook chapters "makeworld.html"
> and "small-lan.html", plus maybe /usr/src/Makefile and an UPDATING entry).
As soon as this was said the idea popped into mind to just tie etcupdate
into the source directly. Add
Hi!
-
% uname -a
FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r208799: Fri Jun 4
13:58:47 MSD 2010 b...@host.ipt.ru:/storage/obj/storage/src/sys/HOST i386
% make extract
===> Vulnerability check disabled, database not found
===> License check disabled, port has not defined
TB --- 2010-06-12 10:05:03 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 10:05:03 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-06-12 10:05:03 - cleaning the object tree
TB --- 2010-06-12 10:05:12 - cvsupping the source tree
TB --- 2010-06-12 10:05:12 - /usr/b
TB --- 2010-06-12 09:19:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 09:19:14 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-12 09:19:15 - cleaning the object tree
TB --- 2010-06-12 09:19:27 - cvsupping the source tree
TB --- 2010-06-12 09:19:27 - /usr
TB --- 2010-06-12 09:48:38 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 09:48:38 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-06-12 09:48:38 - cleaning the object tree
TB --- 2010-06-12 09:48:47 - cvsupping the source tree
TB --- 2010-06-12 09:48:47 - /usr
TB --- 2010-06-12 07:47:44 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 07:47:44 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-06-12 07:47:44 - cleaning the object tree
TB --- 2010-06-12 07:48:05 - cvsupping the source tree
TB --- 2010-06-12 07:48:05 - /usr/bin/c
On Sat, 12 Jun 2010 13:19:22 +0930
Matt Thyer wrote:
> However my Soekris net4801 board still takes about 2.5 minutes to boot
> and I think time could be saved by parallel probing of hardware where
> possible.
>
> Much work has been done on fast boot times in the Linux world
> including an impre
32 matches
Mail list logo
