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 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 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 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 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
'-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
>
&
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
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
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 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. :-(
>>
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 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
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 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 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 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
Hi Everyone,
As of r255321, we are no longer building gcc or libstdc++ as part of the
default install on platforms where clang is cc.
If you are using gcc, you have two options:
1) Install one of the lang/gcc* ports (Warner has been working on separating
out the patches to our GCC, so these sh
On 6 Sep 2013, at 16:59, Steve Kargl wrote:
> Well, your commit has pre-empted any discussion on whether
> there would have been a better kludge. Oh well.
I'm very happy for it to be replaced by something better (and would be ecstatic
for it to go away completely and for all of the functions t
On 5 Sep 2013, at 22:09, Steve Kargl wrote:
> On Thu, Sep 05, 2013 at 09:52:13AM +0100, David Chisnall wrote:
>> On 4 Sep 2013, at 23:38, Baptiste Daroussin wrote:
>>
>>> As a result we have a lot of fallouts of ports complaining about:
>>> undefined reference
On 4 Sep 2013, at 23:38, Baptiste Daroussin wrote:
> As a result we have a lot of fallouts of ports complaining about:
> undefined reference to `powl'
>
> It seems like libc++ is relying on a function we don't have yet in libm, am I
> missing something?
I've attached a diff that I'd like to com
On 5 Sep 2013, at 08:14, Baptiste Daroussin wrote:
> On Thu, Sep 05, 2013 at 09:05:45AM +0200, Dimitry Andric wrote:
>> On Sep 5, 2013, at 00:38, Baptiste Daroussin wrote:
>>> I'm running exp-run to build the whole ports tree with clang using libc++ by
>>> default.
>>>
>>> As a result we have
On 2 Sep 2013, at 03:01, John-Mark Gurney wrote:
> b/crtn.o: warning: linking PIC files with non-PIC files
I think that this is an issue in our import of clang. I'll have to check
whether I upstreamed the code, but it's basically just not setting the e_flags
field in the ELF header correctly
On 1 Sep 2013, at 19:03, Mark Linimon wrote:
> If this is the case, IMHO:
I was going to quote the whole mail, but actually this is enough. As I have
already said in this thread, there is no such plan. I repeat, for those who
missed it the first time:
On 30 Aug 2013, at 16:11, Da
On 1 Sep 2013, at 02:53, Benjamin Kaduk wrote:
> I am worried about the definition of "polished". I held my tongue in Ottawa
> in 2011 when Kirk wanted to turn SU+J on by default, since I figured he knew
> what was going on much better than I did. Then, we discovered the bad
> interactions b
On 31 Aug 2013, at 08:33, John-Mark Gurney wrote:
> Why didn't this come up when John added XSAVE (a year ago) or Pedro
> Giffuni added amdfam10 support (3 months ago)?
>
> Plus, I've sent other patches earlier this year to -toolchain and made
> clear why I was adding them... Had I known that t
On 30 Aug 2013, at 15:53, Nathan Whitehorn wrote:
> So the real driver here is switching to libc++. Is there really no way
> at all to use it with gcc? If, even with hacking, we could arrange that
> to work then it seems that all of our problems would go away.
If we can make our g++ compile C++1
On 30 Aug 2013, at 15:41, John Baldwin wrote:
> So my take away from this is that you have no plans to support any platform
> that
> doesn't support clang as you just expect ia64 and sparc64 to die and not be
> present in 11.0. That may be the best path, but I've certainly not seen that
> goal
On 30 Aug 2013, at 08:56, Jonathan Anderson wrote:
> Wouldn't this mean that we can't build base using the shipped-in-base g++? If
> we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++,
> then people wanting to compile the base system with gcc/g++ will have to
> install
On 30 Aug 2013, at 08:18, Julian Elischer wrote:
> As far as I'm concerned we can even slate it for
> "possible removal in 10.2-- if clang has proven up to the task"
I would be happy to ship gcc, as long as:
- It's explicitly marked as deprecated and due for removal at some point in the
10.x t
On 29 Aug 2013, at 18:44, John Baldwin wrote:
> How does removing GCC from base change this? I already deal with having
> 3 different GCC versions at work by building them from ports and building
> things with the right rpath, etc. so I am familiar with this, and having
> GCC in the base doesn't
On 29 Aug 2013, at 15:57, John Baldwin wrote:
> 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.
Apparently I h
On 25 Aug 2013, at 00:06, Steve Kargl wrote:
> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
>>
>>> And i found PR about clang and mplayer: ports/176272
>>> This PR contains log with bu
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
> And i found PR about clang and mplayer: ports/176272
> This PR contains log with build error log.
Please file clang bugs at http://llvm.org/bugs/
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote:
> Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
> don't understand inlined asm.
Clang supports inline asm. If there is some specific inline asm syntax that
clang does not recognise, then please will you point me to the
On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote:
> So I vote, let's not give ourselves the burden of "lugging" dead weight in
> base
> for another 5 years. (in 2017 do we still want to be worrying about gcc in
> base?)
Perhaps more to the point, in 2017 do we want to be responsible for maintai
On 23 Aug 2013, at 23:37, Warner Losh wrote:
> I'd dispute the 'and surely it seems like it does' part of this. Non x86
> architectures will continue to use gcc because clang just isn't ready at this
> time for them. Some are very close (arm), some are close (powerpc64, mips*),
> some are no w
On 24 Aug 2013, at 02:35, Julian Elischer wrote:
> I don't know.. whatever RootBSD run, but the fact that I needed gcc for
> anything suggests that we should keep it around for a while.
Please point to the FreeBSD PRs and clang bug reports that you have filed about
this. I have been running a
On 23 Aug 2013, at 13:30, 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.
What is the issue with the gcc 4.2.1 build (aside from the fact that it has a
terrifying number o
On 23 Aug 2013, at 14:52, Warner Losh wrote:
> No. That breaks non x86 architecutres. gcc must remain in base for now, or
> there's no bootstrap ability. Nobody has done the lifting to cleanly
> integrate gcc as a port into buildworld, althogh Brooks' work gets us most of
> the way there.
We'
On 23 Aug 2013, at 13:26, Andriy Gapon wrote:
> On the other hand these tools are perfect for building FreeBSD kernel and
> base.
> Extrapolating my experience with base GCC I am very confident in it as a
> FreeBSD development tool.
> Extrapolating my experience with Clang I am not yet confident
On 23 Aug 2013, at 11:42, Julian Elischer wrote:
> no, I believe we have said that 10 would ship with clang by default. NO
> mention was made about gcc being absent, and I am uncomfortable with taking
> that step yet. Having gcc just present, will not hurt you.. even after it is
> gone we wil
On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
> I don't know if you are aware that IF you really do that we will have serious
> problems to ship packages for 10. USE_GCC=any is the fallback in the
> portstree for all ports that are unable to build with clang which was
> introduced
> when HE
I have a patch that I intend to commit before the 10.0 code slush that removes
GCC and libstdc++ from the default build on platforms where clang is the system
compiler. We definitely don't want to be supporting our 6-year-old versions of
these for the lifetime of the 10.x branch.
David
On 2
On 17 Aug 2013, at 15:39, "O. Hartmann" wrote:
> On Sat, 17 Aug 2013 11:24:41 +0100
> David Chisnall wrote:
>
>> On 17 Aug 2013, at 10:48, "O. Hartmann"
>> wrote:
>>
>>> port graphics/blender doesn't compiler neither in CUR
On 17 Aug 2013, at 10:48, "O. Hartmann" wrote:
> port graphics/blender doesn't compiler neither in CURRENT nor 9.2-PRE
> for the moment. On CURRENT (FreeBSD 10.0-CURRENT #4 r254430: Fri Aug 16
> 23:23:08 CEST 2013 amd64), compilation fails with the belwo shown error
> message - for roughly a mont
On 1 Aug 2013, at 20:10, Baptiste Daroussin wrote:
> Thay is with the new ld behaviour, it seems like for some reason, when linking
> with libc++ it lacks an explicit link on libcxxrt, I ll let c++ people find
> out
> why.
I think dim was planning on adding a libc++ linker script that would fix
On 29 Jul 2013, at 21:54, Mateusz Guzik wrote:
> Well, there was linux_kdump in ports but it apparently got obsolete as
> necessary support for included in our regular kdump.
>
> So it may make sense to teach our ldd how to deal with Linux binaries
> for consistency, but its unclear for me if th
On 28 Jul 2013, at 22:27, Raphael Kubo da Costa wrote:
> This seems to have been committed in r253321, and broke some code that
> was working with r253320; namely, some code in x11/kde4-workspace
> includes math.h and calls isnan() with a const double.
Please provide a test case. Specifically,
On 12 Jul 2013, at 22:47, "O. Hartmann" wrote:
> Obviously not really fixed, but even worse:
>
> if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64
> revision 253287) isnan(x) where x is a "const double", I receive now
> the following error (which doesn't appear on previous v
On 12 Jul 2013, at 10:01, "Lundberg, Johannes"
wrote:
>> As the KMS code does not switch the display mode back, once X with KMS
> starts, you can't get a console back.
>
> Is there any solution for this in the works?
Yes. ray@ is currently being funded by the FreeBSD Foundation to improve
Ne
On 11 Jul 2013, at 13:11, Bruce Evans wrote:
> The error message for the __builtin_isnan() version is slightly better up
> to where it says more.
>
> The less-unportable macro can do more classification and detect problems
> at compile time using __typeof().
The attached patch fixes the related
On 11 Jul 2013, at 13:11, Bruce Evans wrote:
> is also not required to be conforming C code, let alone C++ code,
> so there is only a practical requirement that it works when included
> in the C++ implementation.
Working with the C++ implementation is the problem that we are trying to solve.
>
Hi Bruce,
You're joining in this discussion starting in the middle, so you probably
missed the earlier explanation.
On 11 Jul 2013, at 05:21, Bruce Evans wrote:
> I don't see how any conforming program can access the isnan() function
> directly. It is just as protected as __isnan() would be.
On 10 Jul 2013, at 17:33, "O. Hartmann" wrote:
> Hi David,
>
> thanks for the fast response.
>
> The code I was told to check with is this:
>
> #include
> #include
> #include
>
> int
> main(void)
> {
>
>std::cout << typeid(isnan(1.0)).name() << "\n";
>
> }
>
>
> If I compile it
Hi,
On 10 Jul 2013, at 14:58, "O. Hartmann" wrote:
>
> Whe I try to compile the sources of a port in spe (devel/pocl), which
> is now out as RC6, I receive this error shown below:
>
> [...]
> ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> conversion from 'int' to 'boolvec_t' (aka 'bo
On 9 Jul 2013, at 05:40, Tim Kientzle wrote:
> However, this does have an implicit redundant store,
> so changing it to
>
>ptr = func(ptr + 1);
>
> is still a good idea, just not for the reason Clang was claiming.
If the compiler can tell that ptr has not escaped, then it will elide the
r
Hi Everyone,
If English is not your first language and / or you are not confident about your
writing, please don't let this stop you from submitting something. A native
English speaker (probably me) will read through everything before publication
and fix any errors. As long as the technical d
On 10 Jun 2013, at 15:40, Florent Peterschmitt wrote:
> Ok and isn't it a "bad" thing ? I mean, even if the video driver
> crashes, I still want to have the ability to reboot the right way,
> avoiding corrupted files and WIP lose.
>
> Another thing is a non-critical module that can crash, but be
On 28 May 2013, at 05:56, Zaphod Beeblebrox wrote:
> Urm... Isn't the use of shared memory the more obvious way to transfer data
> between processes? Am I missing some nuance?
I can't speak for Luigi's use-case, but the Binder APIs in BeOS and Android
call for this kind of copy. The receiving
On 5 May 2013, at 13:26, Ulrich Spörlein wrote:
> If you can
> lump everything into one run, then it's as simple as 'scan-build make'
> and you get your HTML output.
The most important thing is to remember to do a make clean. As scan-build just
interposes itself in front of the compiler, it wo
On 28 Apr 2013, at 19:09, Stephen Montgomery-Smith wrote:
> But let's not get into the Linux
> bashing the same way he bashed BSD.
There is already a very good Linux Haters' Blog, in the tradition of the UNIX
Haters' Handbook. Unlike the antibsd blog (which contains ill-informed rants
and non
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 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
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 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 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 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 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 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
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 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
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 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 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 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 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 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
>>
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
__
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
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-
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 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 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 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 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 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
I'd add one more thing that needs fixing:
Clang should default to c89 mode when invoked as cc. I had a patch to do this,
but I seem to have misplaced it. I'll try to find or rewrite it in the next
couple of days.
A lot of the ports failures I saw were due to ports using cc as the default C
On 6 Sep 2012, at 09:43, Roman Divacky wrote:
> Was this compiled as amd64 or i386? Also, can you send me the test case?
> So that we can explore the difference. The working theory now is SSE vs FPU
> mathematics, but it would be nice to see the testcase.
There may also be a difference in whether
On 5 Sep 2012, at 10:31, Dimitry Andric wrote:
> These are just the default FreeBSD optimization flags for building
> clang, which are probably used by the majority of users out there.
> This is the case that I was interested in particularly. The
> -fno-strict-aliasing is not really my ch
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
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 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
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 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 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 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 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 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 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 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
201 - 300 of 315 matches
Mail list logo
