On 11 Sep 2012, at 09:18, Dimitry Andric wrote:
> So I am a bit reluctant to change clang's default standard to c89,
> unless clang upstream agrees with this. In the interest of prodding
> people to update their software, I would rather have the default stay
> c99, personally. :)
I'm not proposi
On 12 Sep 2012, at 10:09, Doug Barton wrote:
> Also, users who actually are helping with testing clang for ports
> continue to report runtime problems, even with things that build fine.
I hope that you are encouraging maintainers of ports that don't work as
expected with clang to submit bug repo
On 2 Nov 2012, at 05:24, Jan Beich wrote:
>> Known Issues
>
> emulators/wine doesn't work with lib32 built by clang, probably due to
> wine bugs.
Is this still the case? There was an issue preventing WINE from working
because it required stricter stack alignment than clang provided by default,
On 2 Nov 2012, at 08:18, Mehmet Erol Sanliturk wrote:
> Very many years ago , when 2010 was a very distant future , I do not
> remember the name of the writer , who wrote approximately :
>
> "In 2010 , there will be Fortran , but a Fortran which may be different ."
I remember a talk in the mid '
On 7 Nov 2012, at 08:20, Warren Block wrote:
> It's not saying that hald is run by default, merely that xorg-server will try
> to use it by default.
And will fail to detect any input devices if hald is not running, but will
correctly detect them if the X server is compiled without HAL support.
On 16 Nov 2012, at 07:41, Dimitry Andric wrote:
> And regarding clang, I don't have the time to implement this very soon,
> and I doubt it is very high on the bug priority list with upstream
> either. They just branched for the 3.2 release, and they are much
> busier squashing bugs now. :)
Imple
On 13 Dec 2012, at 21:48, Johannes Dieterich wrote:
> GNU gdb 6.1.1 [FreeBSD]
You might try with gdb 7.x from ports. gdb 6.1.1 from the base system doesn't
do a good job of understanding the newer version of DWARF that clang emits.
David
___
freebsd-
Looks like it's been imported to the 3.2 branch, so we should get it when dim
pulls in the latest version.
David
On 14 Dec 2012, at 14:14, Guido Falsi wrote:
> I have stumbled upon a solved bug in clang 3.2 while testing some ports:
>
> http://llvm.org/bugs/show_bug.cgi?id=14491
>
> Fixed in
Is this on 9.1? In -CURRENT and 9.1, libstdc++ is a filter library, and
libsupc++ or or libcxxrt are the filtee. This means that the __cxa_throw
symbol appears to be in libstdc++ (for symbol versioning purposes), but is
actually in the ABI library. If you tell gdb to put the breakpoint on
__
On 4 Jan 2013, at 12:49, Stefan Farfeleder wrote:
> On Fri, Jan 04, 2013 at 12:38:44PM +0000, David Chisnall wrote:
>> Is this on 9.1? In -CURRENT and 9.1, libstdc++ is a filter library, and
>> libsupc++ or or libcxxrt are the filtee. This means that the __cxa_throw
>>
On 4 Jan 2013, at 20:39, Rick Macklem wrote:
> What about capturing a few examples, like this one for a system with
> 16Gb of Ram. Basically cases of:
> - this is my hardware config and here's what works well for me
> It's pretty easy for people to choose the example closest to their
> setup as a
On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote:
> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
>> Here's a minimal test case that reproduces the bug:
> [...]
>
> Until someone fixes this bug, could we apply something like this as a
> work-around?
>
> Stefan
>
> Index: gn
On 6 Jan 2013, at 12:55, O. Hartmann wrote:
> Having a crippled LLVM aboard AND the need having installed a port is a
> kind of none-sense. Why should I install port devel/llvm to have a
> working LLVM backend?
The issue is the same as the issue for anything in the FreeBSD base system,
which is:
On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote:
> No. It's completely broken at all optimization levels. There do not
> appear to be any flags that change the behavior. Building unwind-dw2.c
> either with gcc or with the previous import of clang in our tree does
> fix it, however.
Do you have an
On 6 Jan 2013, at 20:38, Erik Cederstrand wrote:
> You can't seriously blame LLVM for making progress. If ports rely on a
> specific version of LLVM, it would be far better to create devel/llvm31,
> devel/llvm32 etc.
Well, I can (and, even with my LLVM committer hat on, do) blame LLVM for not
On 7 Jan 2013, at 23:21, Dimitry Andric wrote:
> This is at least the direction I'm looking at. It seems that in some
> cases with __builtin_eh_return(), llvm does not see that registers can
> be clobbered, and it doesn't save and restore them.
Do you mean that some registers were clobbered by a
This appears to be caused by your addition of -stdlib=libc++ -std=c++11 to
your CXXFLAGS. So, first of all, thank you for testing libc++!
I tested with libc++ while I was developing dtc, but then was building with
libstdc++ while I was removing extraneous includes. Unfortunately, libstdc++
On 29 Jan 2013, at 10:48, O. Hartmann wrote:
> On 01/29/13 11:08, David Chisnall wrote:
>> On 29 Jan 2013, at 10:06, O. Hartmann wrote:
>>
>>> I receive this error since yesterday building world and it is still
>>> sticky on most recent sources (r24
On 29 Jan 2013, at 10:06, O. Hartmann wrote:
> I receive this error since yesterday building world and it is still
> sticky on most recent sources (r246057) and I was wondering why the
> tinderboxes do not pick this up on the 10.0-CURRENT builds ... just for
> a notice for the development folks ..
On 31 Jan 2013, at 04:37, O. Hartmann wrote:
> First, I suspected the c++ option "-std=c++11" I issued in /etc/src.conf
> when building the sources - I did this before without any problems.
> Then, leaving the build without "-std=c++11" option, I get the following
> error below and compilation sto
On 30 Jan 2013, at 21:23, AN wrote:
> VirtualBox: dlopen("/usr/local/lib/virtualbox/VBoxRT.so",) failed:
> /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by
> /usr/local/lib/virtualbox/VBoxRT.so not found
GLIBCXX_3.4.15 is the symbol version of the libstdc++ that ships with gcc 4.6.
On 1 Feb 2013, at 00:37, AN wrote:
> I sincerely apologize to theraven@, and all developers. My intention was not
> to flame or disrespect anyone. I appreciate and am grateful to all the
> developers who work on FreeBSD, thank you for your efforts.
Bug reports are always helpful, even when no
On 11 Feb 2013, at 10:48, Fabian Keil wrote:
> It's unfortunate that the builworld time roughly trippled since
> 2010 but I guess that's progress and a more powerful system
> should fix it. I certainly welcome clang in general, though.
In that case, it's worth noting that you can shave a fair bi
On 11 Feb 2013, at 13:56, Fabian Keil wrote:
> real350m42.363s
> user253m5.477s
> sys 50m0.024s
These numbers look a bit wrong. You've got 300 minutes of CPU time, but 350
minutes of real time. In an ideal world, on your dual-core system you'd see
150 minutes of real time. Seein
I forwarded this thread to Christopher Bergstöm and got this reply:
>
> FreeBSD simply isn't a scientific computing platform - There isn't any market
> demand, it's not designed for it, many of the tools commonly used aren't
> available and the amount of work to change that is s
On 26 Apr 2012, at 12:38, Bob Bishop wrote:
> Hi,
>
> On 26 Apr 2012, at 10:35, Konstantin Belousov wrote:
>
>> I think it is time to stop building the toolchain static. I was told that
>> original reasoning for static linking was the fear of loosing the ability
>> to recompile if some problem a
If you have a test case, I can commit it to the libc++ test suite.
David
On 10 May 2012, at 21:42, Kohji Okuno wrote:
> Hi Eric,
>
>> I'm left wondering how this was not caught by the libc++ test
>> suite. The current toupper.c shouldn't pass
>> http://llvm.org/svn/llvm-project/libcxx/trunk/tes
On 28 May 2012, at 05:35, Rainer Hurling wrote:
> Yesterday r236148 (Allow inclusion of libc++ to work after including
> math.h) was comitted to head, many thanks.
>
> Does this mean, that extra long double functions like acoshl, expm1l or
> log1pl are now "really implemented"? As far as I und
On 28 May 2012, at 13:30, Rainer Hurling wrote:
> On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
>> On 28 May 2012, at 05:35, Rainer Hurling wrote:
>
> Ok, that's what I had supposed. Because the main difference between r236147
> and r2136148 seems to be the define
On 13 Jul 2012, at 13:18, John Baldwin wrote:
> On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote:
>> AFAIK, none of the relevant standards (POSIX, IEEE754) have any
>> precision requirements for functions other than +-*/ and sqrt() - all
>> of which we have correctly implemented. I therefor
On 13 Jul 2012, at 17:40, Warner Losh wrote:
> We shouldn't be gating the new math on an issue that only affects sparc64
> machines
Mostly agreed, but it's worth noting that the APCS for ARMv8[1] specifies that
long double should be IEEE 754- 2008 quad precision. I think ARMv8 is going
to be
On 20 Jul 2012, at 17:33, Konstantin Belousov wrote:
> It is not related to dtrace at all, and indeed OFFSETOF_CURTHREAD is 0.
> This is a bug in clang, we compile our kernel in freestanding environment.
The copies of the C spec that I have do not differentiate between freestanding
and hosted en
On 21 Jul 2012, at 00:16, Konstantin Belousov wrote:
> Ok, I stand corrected. But the standard does not say what you claim
> either. It only specifies that NULL pointer is unequal to any pointer
> to object or function (implicitely saying that you can create a C object
> or function pointer to whi
On 21 Jul 2012, at 22:16, Konstantin Belousov wrote:
> On Sat, Jul 21, 2012 at 04:00:45PM -0400, Kim Culhan wrote:
>> On Fri, Jul 20, 2012 at 11:40 AM, Dimitry Andric wrote:
>>> On 2012-07-20 16:49, Kim Culhan wrote:
Seeing this for r:238655
>>> ...
In file included from
/usr/src
On 23 Jul 2012, at 20:18, Konstantin Belousov wrote:
> Longer description is that pc_curthread is offset 0 if %gs-based.
> The dereferenced pointer point to the struct thread, which contains
> td_proc pointer at offset 8. Instead, clang seems to dereference
> td_proc from offset 8 based on %gs, or
On 23 Jul 2012, at 20:53, David Chisnall wrote:
> On 23 Jul 2012, at 20:18, Konstantin Belousov wrote:
>
>> Longer description is that pc_curthread is offset 0 if %gs-based.
>> The dereferenced pointer point to the struct thread, which contains
>> td_proc pointer at
On 24 Jul 2012, at 23:43, Konstantin Belousov wrote:
> As kan rightfully notes, the assumption that &%fs:0 == *%fs:0 holds for
> userspace on amd64, and the same is true for %gs userspace on i386.
> The change you committed to clang/llvm/whatever it called just breaks
> useful optimization for Fre
On 29 Jul 2012, at 10:58, Luigi Rizzo wrote:
> 3. nuke inet_ntoa_r() from libc
inet_ntoa_r is a public symbol and therefore part of our ABI contract with
userspace applications. Even if no one that we are aware of is using it, we
should officially deprecate it for one major release before remo
On 2 Aug 2012, at 05:30, Doug Barton wrote:
> I used to ask the PTB to provide *some* form of remote participation for
> even a fraction of the events at the dev summit. I don't bother asking
> anymore because year after year my requests were met with any of:
> indifference, hostility, shrugged sh
On 2 Aug 2012, at 17:46, Doug Barton wrote:
> Well that's a start. :) And where was this availability announced? If I
> missed it, that's on me. But providing remote access that you don't tell
> people about isn't really any better than not providing it at all.
It's not widely advertised, because
On 2 Aug 2012, at 18:28, Doug Barton wrote:
> Welcome to the 21st Century. :) There are widely available audio and
> video conferencing solutions that easily scale into the thousands of
> users, at minimal cost.
>
> Yes, "It takes effort." I get that. I've been part of the effort to
> provide rem
On 2 Aug 2012, at 18:47, Doug Barton wrote:
> Cheap copout. And quite sad, especially coming from a newly elected core
> team member.
FreeBSD is a volunteer project. Our DevSummits are not run by a commercial
organisation, they are run by volunteers. I am not being paid to organise the
Cambri
Thank you for your thoughtful reply,
On 2 Aug 2012, at 19:33, Doug Barton wrote:
> However, my point is that in spite of the fact that it's non-trivial,
> the mindset on this topic needs to change if the dev summits are going
> to continue to be significant focii of both work being done and
> dec
On 13 Aug 2012, at 07:57, Volodymyr Kostyrko wrote:
> 1. It's targeted at fixing Linux bugs, not FreeBSD ones. FreeBSD sound system
> had in-kernel virtual channel mixing support for years.
I found this to be the major issue. There were very few things on the list
that weren't already supporte
On 9 Sep 2013, at 14:27, Ulrich Spörlein wrote:
> Case in point, I only recently switched to clang in base and now the
> newsbeuter port crashes during startup (yeah, it builds fine). So all
> I'm asking for now is: how can I override a random port to be built with
> gcc (either from base or port
On 11 Sep 2013, at 21:06, "David O'Brien" wrote:
> It is still very useful for folks to test changes in order to help ensure
> one doesn't break the build on platforms still using GCC.
If you want to do this test, then you should do make universe or make tinderbox
(you should do one or the othe
On 15 Sep 2013, at 23:28, "Joe Holden" wrote:
> Are you still playing with this? Reason I ask is that I tried to build
> world with clang for the crack and it bails with:
>
> /usr/obj/mips.mips64/pseudosrc/tmp/usr/bin/ld:
> /usr/obj/mips.mips64/pseudosrc/tmp/usr/lib/crtn.o: warning: linking PI
On 16 Sep 2013, at 07:52, Dimitry Andric wrote:
> On Sep 16, 2013, at 03:08, Adrian Chadd wrote:
>>> The results are interesting. On amd64:
>>>
>>> - devd suddenly becomes 500 KB in size, instead of a megabyte,
>>> - init's size drops from 900 KB to 600 KB,
>>> - clang becomes a megabyte smalle
On 18 Sep 2013, at 07:22, Konstantin Belousov wrote:
> I think this is a wrong direction. First, the split should be done at
> the source level, as it was usually done forever.
Until we are all using toolchains that support LTO (which requires importing a
new linker and will make people who com
This looks like the namespace pollution that was caused by iconv.h including
stdbool.h, which I have already fixed.
David
On 18 Sep 2013, at 14:57, Ricardo Campos Passanezi wrote:
> Hello, I was trying to install gnome2 port but it ends up with an error
> in evolution-data-server. Any clues?
>
On 18 Sep 2013, at 16:26, Tijl Coosemans wrote:
> On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote:
>>> I am still working on libc++ issues but it is much more
>>> complicated. :-(
>>
On 18 Sep 2013, at 19:31, Tijl Coosemans wrote:
> There are some pointers to the start such as the caughtExceptions field
> in struct __cxa_eh_globals and the nextException field in struct
> __cxa_exception itself.
These are not part of the public API.
David
___
On 18 Sep 2013, at 19:49, David Chisnall wrote:
> These are not part of the public API.
Oh. Yes it is. Ho hum...
David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
This looks like it's compiling C++ with clang and trying to link it with gcc.
Is there a CXXLD=g++ in there somewhere?
David
On 28 Sep 2013, at 15:23, Alexander Panyushkin wrote:
> Hi all
>
> After upgrade ports graphics/poppler-glib not build anymore.
>
>
> pkg_info -R poppler-glib-0.22.2
'-pthread'
> c++: warning: argument unused during compilation: '-pthread'
> /usr/bin/ld: cannot find -lstdc++
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[3]: *** [libpoppler-glib.la] Error 1
>
> *** Error code 1
>
&
On 7 Oct 2013, at 22:14, Lyndon Nerenberg wrote:
> "Install from ports" is a non-starter. Our development systems will never be
> connected to the internet for a ports upgrade. In this environment, in-base
> RCS is a very useful tool.
Why is install from packages any harder than installing t
On 22 Oct 2013, at 00:43, Sean Bruno wrote:
> Heh, Matthew suggested the obvious in private mail, it seems that this
> would be better "spelled" as "isalpha" :-)
This looks wrong. The behaviour of isalpha() depends on the current locale.
You probably want isalpha_l(), with the "C" locale.
Da
On 24 Oct 2013, at 21:13, Sean Bruno wrote:
> On Tue, 2013-10-22 at 09:47 +0100, David Chisnall wrote:
>> On 22 Oct 2013, at 00:43, Sean Bruno wrote:
>>
>>> Heh, Matthew suggested the obvious in private mail, it seems that this
>>> would be better "spell
On 24 Oct 2013, at 21:50, Sean Bruno wrote:
> On Thu, 2013-10-24 at 21:24 -0400, David Chisnall wrote:
>>
>> Don't forget the freelocale() at the end.
>>
> ah, ok. I wish that there was some kind of example that I could go off
> of in the man page. I&#x
On 12 Nov 2013, at 16:32, Steve Kargl wrote:
> Trying to build news/pan with clang++ dies with
>
> gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general'
> CXXfile-util.o
> In file included from file-util.cc:38:
> In file included from ./log.h:26:
> /usr/include/c++/v
On 12 Nov 2013, at 16:54, Steve Kargl wrote:
> On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote:
>> On 12 Nov 2013, at 16:32, Steve Kargl
>> wrote:
>>
>>> Trying to build news/pan with clang++ dies with
>>>
>>> gmake[3]: Enter
On 12 Nov 2013, at 18:21, John Baldwin wrote:
>> struct foo {
>> struct foo bar;
>> }
>
> Except it isn't. It's declaring the head of a container. This is more
> like:
>
> struct foo {
> TAILQ_HEAD(, foo) messages;
> };
Eitan is correct here. The definition of std:
On 13 Nov 2013, at 19:40, Dimitry Andric wrote:
> On the other hand, different C++ standard libraries simply cannot be
> mixed. The internal implementations are usually completely different.
> This is not really news at all, certainly not to the ports people. :-)
That said, it should still be p
On 28 Nov 2013, at 15:13, jb wrote:
> Luigi Rizzo iet.unipi.it> writes:
>
>> ...
>> But I don't understand why you find ksize()/malloc_usable_size() dangerous.
>> ...
>
> The original crime is commited when *usable size* (an implementation detail)
> is exported (leaked) to the caller.
> To b
Hi Ed,
How are you planning on building the LLVM / Clang libraries? Will they be
statically linked to the compiler and the debugger, or do you intend to make
them dynamic too? I found about a small slowdown with a dynamic clang, but the
link times were much lower when building.
Currently,
On 16 Dec 2013, at 21:35, Dimitry Andric wrote:
> In any case, if anything like this is implemented, I would really prefer
> something like CMake does, e.g. give you a percentage counter that
> provides some information about how 'far' the build is progressing.
I haven't seen this for a while, b
On 19 Dec 2013, at 09:40, Luigi Rizzo wrote:
>
>> If a command produces warning output but exits with success, then that
>> command's output is dumped to stdout (explicitly serialised by Ninja so that
>> it's never interleaved with another command's output).
>>
>> If a command exits with a fa
Hi Johannes,
Are you using the packaged Xorg in both cases? Currently, the default for 10
is the old (pre-KMS) X.org and the default for 11 (HEAD) is the newer
(post-KMS) one. If you're using the default one, would you mind trying the new
one? You can build it from ports by putting this in y
On 10 Jan 2014, at 00:37, Lundberg, Johannes
wrote:
> Creating a user who is only added to one group (for example wheel) works
> fine.
I created a user with bsdconfig for the first time yesterday and found that
their new home directory was owned by root. Did you experience this, or is it
jus
On 21 Jan 2014, at 07:13, Antonio Olivares wrote:
> On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras wrote:
>> Hi,
>>
>> Is there any way I can avoid manually resolving hundreds of merge
>> conflicts of the following type while using freebsd-update ?
>>
>> 1 <<< current version
>>
>>
>> 2
On 29 Jan 2014, at 15:08, Michael Schmiedgen wrote:
> Can we expect a current version of spring in ports soon? That would
> be nice! AFAIK newer versions require OpenMP. Will this compile with
> our (new 3.4 soon) base clang?
Base clang doesn't support OpenMP. We should probably import Intel's
On 29 Jan 2014, at 15:37, Michael Schmiedgen wrote:
> On 29.01.2014 16:16, David Chisnall wrote:
>> On 29 Jan 2014, at 15:08, Michael Schmiedgen wrote:
>>
>>> Can we expect a current version of spring in ports soon? That would
>>> be nice! AFAIK newer versions
On 6 Feb 2014, at 18:34, Julian H. Stacey wrote:
> Best avoid the obscure word `Deprecated' in manuals:
> It's not common/ plain English. Maybe a geek import, or USA
> dialect ? It's not easily internationaly understood English.
> Best make manuals easier for non native English speakers (& n
This looks like a bug, please file an llvm PR. The offending code seems to be
createUniqueEntity() in lib/Support/Unix/Path.inc, which does... something.
Something weird and convoluted that seems to try to implement mkstemp() /
mkdtemp() in an incomprehensible way.
David
On 13 Feb 2014, at 1
On 16 Feb 2014, at 20:38, Dimitry Andric wrote:
> I hope it will be ready to appear in 3.5 release. There is currently an
> experimental version, based on clang 3.3, published here:
>
> http://clang-omp.github.io/
I'd like to see this version in ports so that we could build ports with an
Open
On 17 Feb 2014, at 11:16, Gleb Smirnoff wrote:
> Now for the new sendfile. The core idea is that sendfile()
> schedules the I/O, but doesn't wait for it to complete. It
> returns immediately to the process, and I/O completion is
> processed in kernel context. Unlike aio(4), no additional
> threa
Hi Bruno,
To preface this, I'd like to say that I do believe that FreeBSD does need a
more modern init system. SMF on Solaris and Launchd on Darwin both have some
advantages. These are what I see as the limitations in our current design (not
in priority order):
1) Options are implicit. Beca
On 23 Feb 2014, at 18:11, Allan Jude wrote:
> sysrc solves this nicely, it is in base now, and is great for
> programmatically adding, removing and changing lines in rc.conf style
> files. It is also in ports for older versions of FreeBSD where it is not
> in base.
The problem is, there is no su
On 23 Feb 2014, at 18:31, Freddie Cash wrote:
> The main developer for systemd is very anti-portability and anti-!Linux. He
> had actively rejected patches that made his projects work on non-Linux
> systems. In order to port systemd to a non-Linux system, he wants you to
> first implement every L
On 24 Feb 2014, at 07:34, Baptiste Daroussin wrote:
> Usual complains about sendmail in base until now has been:
> - complex configuration
> - long history of security concerns
> - no need for a full mta in base
The other complaint is that sendmail is only half of a useable MTA in base. If
you
On 24 Feb 2014, at 08:35, Baptiste Daroussin wrote:
> dma can exactly do that :) while being smaller than opensmtpd (which is very
> very nice as well, this is the one I use when I need a full smtp setup :))
Sounds excellent then. We definitely should be moving to a world where all of
the base
On 24 Feb 2014, at 13:25, Matthias Gamsjager wrote:
> How about delaying the startup of services that are not necessary right at
> the start. For example sshd, samba etc could be loaded after xdm ( or even
> after the DE has loaded).
It's a good idea, but it depends on a far more complex system
On 24 Feb 2014, at 16:39, Lyndon Nerenberg wrote:
> If the above doesn't work, you have to fall back to ports. And this is where
> things get really hairy. Just generating the list of required distfiles is
> problematic. 'make fetch-recursive-list' will give you a script to run to
> pull dow
On 25 Feb 2014, at 08:09, Daniel Kalchev wrote:
> What we risk with "everything is a port" concept is that we live in a world
> that there is a lot of software to chose from, but from time to time, the
> software happens to be incompatible with FreeBSD in one way, or another.
> Another risk is
On 27 Feb 2014, at 02:41, Michael Butler wrote:
> .. way back in the late 70's or maybe early 80's when I was
> actually doing some work on compilers, we had a saying: "produce correct
> code even if it's not optimal or exit and tell the user why".
In the late '70s, the number of transforms tha
On 28 Feb 2014, at 01:51, Michael Butler wrote:
> I guess what I'm trying to get at is that I am used to a compiler which
> takes one of two actions, irrespective of the complexities of the source
> language or target architecture ..
>
> 1) the compiler has no definitive translation of "semantic
On 6 Mar 2014, at 16:53, Dimitry Andric wrote:
> Now on a side note, it would be very nice if our kernel debugging
> extensions were ported to the ports version of gdb, which is
> non-ancient... :-)
I believe that emaste has an lldb-based kgdb replacement on his todo list,
although not yet quit
On 7 Mar 2014, at 16:41, Rui Paulo wrote:
> On 6 Mar 2014, at 23:30, David Xu wrote:
>> it seems filename ended with a dot is illegal on Windows, if someone
>> wants to check out freebsd source code on Windows, it will be a problem.
>
> Is this something we want to support?
Yes, definitely. B
On 12 Mar 2014, at 02:07, Roger Pau Monné wrote:
> I've found out that the value PTHREAD_STACK_MIN is currently set (2048
> bytes) seems to be way too low
This looks like an error in your code. The spec says:
> PTHREAD_STACK_MIN
> Minimum size in bytes of thread stack storage.
> Minimum Accept
On 20 Mar 2014, at 14:08, John Baldwin wrote:
> No, the compiler should provide a working "wmmintrin.h" header in one of
> its built-in paths if it supports the AES instructions. This is akin to
> saying that code that uses "stdio.h" should use -I/usr/src/include.
It does, however our build sys
On 1 Apr 2014, at 08:11, Jordan Hubbard wrote:
> 1. Power. As you point out, being truly power efficient is a complete
> top-to-bottom engineering effort and it takes a lot more than just trying to
> idle the processor whenever possible to achieve that. You need to optimize
> all of the hot-
On 1 Apr 2014, at 23:10, Kevin Oberman wrote:
> Audio output is pretty system dependent, but I had little problem getting
> my audio to auto-switch to headphones when I plugged them in. The setup is
> a bit ugly,but I only had to check the available PINs (ugly, ugly) and set
> up stuff once. It j
On 2 Apr 2014, at 13:40, Daniel Kalchev wrote:
>
> On 02.04.14 12:22, David Chisnall wrote:
>> The use case that PulseAudio was [over]designed to fix was plugging in USB
>> headphones (or connecting a Bluetooth headset) and having existing audio
>> streams redirected
Hi,
I'm trying to reproduce this, but I don't seem to be able to get the same error
as you. I do get a warning with GCC about a cast to an anonymous struct, which
the attached patch fixes, but even without this I'm able to build both with the
gcc in 9 and the gcc in ports. Can you let me know
On 2 Apr 2014, at 20:53, Michael Butler wrote:
> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
>
> .. on ..
>
> FreeBSD 11.0-CURRENT #22 r263969: Mon Mar 31 10:45:56 EDT 2014
>
> Splitting it like ..
>
> - fn.fn_ptr.cxa_func = (void(*)(void*))GET_BLOCK_FUNCTION(func);
> + fn.fn_ptr.cx
On 2 Apr 2014, at 21:21, Steve Kargl wrote:
> Who is "we" in "even if we don't encourage it..."?
"We" is the FreeBSD project, collectively. For a larger list of things that
"we" recommend, look at the src.conf man page, which contains a long list of
things that we encourage, codified as the
On 3 Apr 2014, at 00:23, Warner Losh wrote:
> So less carping and more fixing is needed here.
Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it
isn't...
libc now builds for me with gcc and clang.
David
___
freebsd-current@
On 3 Apr 2014, at 14:26, Warner Losh wrote:
>
> On Apr 3, 2014, at 2:11 AM, David Chisnall wrote:
>
>> On 3 Apr 2014, at 00:23, Warner Losh wrote:
>>
>>> So less carping and more fixing is needed here.
>>
>> Should be fixed in r264069 - I
Hi Marcel,
This error is a warning for me with gcc 4.7.3 when I try. With 4.2.1 in the
tree, it appears to be silenced by something (or possibly we're using the
native blocks code path with gcc and clang doesn't emit that warning in
non-blocks mode). We could pull out the structure definition
qsort_r(base, nel, width, compar,
(int (*)(void *, const void *, const void *))
On 4 Apr 2014, at 23:48, David Chisnall wrote:
> Hi Marcel,
>
> This error is a warning for me with gcc 4.7.3 when I try. With 4.2.1 in the
> tree, it appears to be silenced by som
101 - 200 of 315 matches
Mail list logo
