On 5/16/24 4:05 PM, Lorenzo Salvadore wrote:
On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov
wrote:
gcc13 from ports
`# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 fini 4
fini 5 fini 2 fini 1`
The above order is not expected. I think clang's one is correct
> On May 17, 2024, at 2:26 AM, Konstantin Belousov wrote:
>
> On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote:
>> Hi,
>>
>> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
>> that gcc behaves weirdly.
>>
>> A simple source file to demonstrate that.
>>
On Thu, May 16, 2024 at 08:05:57PM +, Lorenzo Salvadore wrote:
> On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov
> wrote:
> > > gcc13 from ports
> > > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3
> > > fini 4 fini 5 fini 2 fini 1`
> > >
> > > The above
On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov
wrote:
> > gcc13 from ports
> > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3
> > fini 4 fini 5 fini 2 fini 1`
> >
> > The above order is not expected. I think clang's one is correct.
> >
> > Further hacking w
On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote:
> Hi,
>
> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
> that gcc behaves weirdly.
>
> A simple source file to demonstrate that.
>
> ```
> # cat ctors.c
>
> #include
>
> __attribute__((constructor(101
> On 10. Jun 2020, at 20:30, Damjan Jovanovic wrote:
>
> MAP_FIXED is generally bad news, as it overwrites any prior mappings within
> the range of addresses being mapped to.
>
> They should use MAP_FIXED | MAP_EXCL instead, which will fail if any mappings
> already exist in the range, and the
> On 10. Jun 2020, at 18:59, Mark Johnston wrote:
>
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> consider the following program test.c:
>>
>> #include
>> #include
>>
>> int
>> main(void)
>> {
>> void *p;
>>
>> p = mmap((void *)0x200
MAP_FIXED is generally bad news, as it overwrites any prior mappings within
the range of addresses being mapped to.
They should use MAP_FIXED | MAP_EXCL instead, which will fail if any
mappings already exist in the range, and then maybe retry with another
range if it fails. Linux and NetBSD have M
> On 10. Jun 2020, at 18:59, Mark Johnston wrote:
>
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> consider the following program test.c:
>>
>> #include
>> #include
>>
>> int
>> main(void)
>> {
>> void *p;
>>
>> p = mmap((void *)0x20
On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
> Dear all,
>
> consider the following program test.c:
>
> #include
> #include
>
> int
> main(void)
> {
> void *p;
>
> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
> PROT_EXEC, MAP_ANON | M
On Tue, Nov 26, 2019 at 3:57 AM Dennis Clarke wrote:
>
>
>
> I will cross post this as there are very few options left.
>
> rv64imafdc folks :
>
> I will send this
On 25/7/18 12:40 am, Julian Elischer wrote:
On 22/7/18 4:32 am, Dimitry Andric wrote:
On 21 Jul 2018, at 21:11, Yuri Pankov wrote:
Yuri Pankov wrote:
Julian Elischer wrote:
...
anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?
In later GCC versions the cpp's -lang-asm seems
On 22/7/18 3:11 am, Yuri Pankov wrote:
Yuri Pankov wrote:
Julian Elischer wrote:
I would really like ot get some pointers as to who are our tools
committers at the moment, in particular who might know about these
issues.
The main issue for me at the moment is the ability to compile the
aesni
On 22/7/18 4:32 am, Dimitry Andric wrote:
On 21 Jul 2018, at 21:11, Yuri Pankov wrote:
Yuri Pankov wrote:
Julian Elischer wrote:
...
anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?
In later GCC versions the cpp's -lang-asm seems to be deprecated in
favor of -x assembler-wit
On 21 Jul 2018, at 21:11, Yuri Pankov wrote:
>
> Yuri Pankov wrote:
>> Julian Elischer wrote:
...
anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?
>> In later GCC versions the cpp's -lang-asm seems to be deprecated in
>> favor of -x assembler-with-cpp as it conflicts with -l
Yuri Pankov wrote:
Julian Elischer wrote:
I would really like ot get some pointers as to who are our tools
committers at the moment, in particular who might know about these issues.
The main issue for me at the moment is the ability to compile the
aesni code in Samba from clang..
Julian
On 20
Julian Elischer wrote:
I would really like ot get some pointers as to who are our tools
committers at the moment, in particular who might know about these issues.
The main issue for me at the moment is the ability to compile the
aesni code in Samba from clang..
Julian
On 20/7/18 7:32 pm, Julia
I would really like ot get some pointers as to who are our tools
committers at the moment, in particular who might know about these issues.
The main issue for me at the moment is the ability to compile the
aesni code in Samba from clang..
Julian
On 20/7/18 7:32 pm, Julian Elischer wrote:
comp
On 24 May 2018 at 03:34, Mark Millard wrote:
> [This submittal is in part an experiment with how Eitan's
> MUA classifies the Email using an alternate yahoo.com
> address. Eitan: the subject and this note are all unique
> to this message.]
>
>
Gmail still considers all your mails as spam :(
> Th
I got this. not marked as spam
On 23 May 2018 at 18:34, Mark Millard wrote:
> [This submittal is in part an experiment with how Eitan's
> MUA classifies the Email using an alternate yahoo.com
> address. Eitan: the subject and this note are all unique
> to this message.]
>
> I've reported to Eitan
On Wed, Jul 8, 2015 at 9:36 PM, Dimitry Andric wrote:
> On 08 Jul 2015, at 19:05, Luigi Rizzo wrote:
> >
> > the r281316 commit introduces the following lines
> > which break compilation with gcc on amd64 (as far as i know
> > immintrin.h is only available in our clang).
> > If there are no obje
On 08 Jul 2015, at 19:05, Luigi Rizzo wrote:
>
> the r281316 commit introduces the following lines
> which break compilation with gcc on amd64 (as far as i know
> immintrin.h is only available in our clang).
> If there are no objections I'd like to add a further check
> for the use of clang, see
On 08/15/2014 12:31, Alexander Pyhalov wrote:
Hello.
I just stumped on the following gcc bug -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15992 (std::locale is not
working for non-C locales).
Related libstdc++ bug - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495
--
Best regards,
Alexan
On Apr 3, 2014, at 7:35 AM, David Chisnall wrote:
> 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
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'm sure Jenkins / Tinderbox will tell me if it
>> is
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'm sure Jenkins / Tinderbox will tell me if it
> isn't...
>
> libc now builds for me with gcc and clang.
th
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 Apr 2, 2014, at 1:15 PM, Michael Butler wrote:
> /usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b':
> /usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a
> pointer type
> *** Error code 1
This also breaks mips*, sparc64, armeb and ia64. I’ve seen the carping about
disco
On Wed, Apr 02, 2014 at 09:46:19PM +0100, David Chisnall wrote:
> 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,
There is a significant
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 Wed, Apr 02, 2014 at 08:58:21PM +0100, David Chisnall wrote:
>
> Well, I wouldn't object to that, but it would be good to fix this - we
> still want to be able to build the base system with gcc (or another
> compiler), even if we don't encourage it...
Who is "we" in "even if we don't encourage
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 04/02/14 15:30, David Chisnall wrote:
> 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
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 23.11.2013 22:23, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After SVN r258501, I get ..
===> gnu/usr.bin/cc/cc1 (all)
- --- cc1-dummy ---
cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H
- -DPREFIX=\"/usr/obj/usr/src/tmp/usr\"
- -I/usr/obj/usr/src/tmp/usr/src/
Wiadomość napisana przez Michael Butler w dniu 18
paź 2013, o godz. 14:15:
> -current kernel compiled with gcc fails with:
>
> cc1: warnings being treated as errors
> /usr/src/sys/geom/label/g_label.c: In function 'g_label_resize':
> /usr/src/sys/geom/label/g_label.c:135: warning: null format st
On Thu, Aug 29, 2013 at 06:02:06PM +0100, David Chisnall wrote:
> rather busy organising the DevSummit. The notes for the sessions will
> be posted to various mailing lists soon (and summarised for a special
> status report), but since the ports and toolchain build sessions are
> already largely u
On Sep 1, 2013, at 12:03 PM, Mark Linimon wrote:
> On Fri, Aug 30, 2013 at 10:41:18AM -0400, 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.
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, David Chisnal
On Fri, Aug 30, 2013 at 10:41:18AM -0400, 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
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
Sorry for adding to the long thread.
On Sat, 31 Aug 2013, David Chisnall wrote:
However, we want to be able to make it unsupported at some point in the
10.x series when there is a polished alternative for every supported
architecture (either when they've moved to clang or when the XCC stuff
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
John Baldwin wrote this message on Fri, Aug 30, 2013 at 10:41 -0400:
> So I think the crux of the issue might be this:
>
> I have no doubt that this has been discussed extensively on toolchain@ and in
> toolchain-specific devsummit sessions. The proposal to disable GCC by default
> does not appea
On Fri, Aug 30, 2013 at 04:11:08PM +0100, David Chisnall wrote:
> Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's
> an executive summary of what I'm ACTUALLY proposing:
>
> - On platforms where clang is cc, don't build libstdc++, make libc++ the
> default. Provide l
>Subject: Re: GCC withdraw
>From: Warner Losh
>Date: Thu, 29 Aug 2013 10:00:19 -0600
> Gcc is still an absolute requirement on all non-x86 platforms (including arm)
> due to the issues with clang. Some of these issues are bugs in specific
> things (arm) that keep coming up
On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall wrote:
> 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.
On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote:
>
> On 30 Aug 2013, at 08:56, Jonathan Anderson wrote:
>
> > ... then people wanting to compile the base system with gcc/g++ ...
>
>
> I'm still curious *why* some people want this?
>
Buildworld completes in 1/4th the amount of ti
On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote:
> On 29 Aug 2013, at 18:44, John Baldwin wrote:
>
> > default every time, that we're telling people not to use, won't help with
> > that...
> >
> > This is your worst argument as clang is known to take far longer than GCC
> > to bu
On Fri, Aug 30, 2013 at 6:47 AM, Ian Lepore wrote:
> On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote:
> > I had a long, rambling reply to this that corrected many of the factual
> errors made in it. But why bother. You have your world view, it doesn't
> match what people are doing today and
Only a few comments in reply to avoid banging my head against a brick wall and
then I'm done:
On Friday, August 30, 2013 3:33:21 am David Chisnall wrote:
> On 29 Aug 2013, at 18:44, John Baldwin wrote:
> > Also, unless you plan on desupporting all non-x86 platforms, you _still_
> > have to do al
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 08/30/13 00:35, David Chisnall wrote:
> 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 deprecate
30.08.2013 11:33, David Chisnall пишет:
> The time to raise objections for this was when the plan was originally raised
> over a year ago
David, can you please point me to the original plan with gcc removal at
10.x? (I do remember only a plan to make clang the default compiler, but
I may be wron
On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote:
> I had a long, rambling reply to this that corrected many of the factual
> errors made in it. But why bother. You have your world view, it doesn't match
> what people are doing today and this mismatch is going to cause people pain
> and suff
I had a long, rambling reply to this that corrected many of the factual errors
made in it. But why bother. You have your world view, it doesn't match what
people are doing today and this mismatch is going to cause people pain and
suffering in the embedded world far beyond what you think. And you
I've been reading this thread and must confess that I'm a little confused
about what exactly is being discussed.
* I presume we've all agreed that "clang" is installed by default in FreeBSD-10.
* I presume everyone agrees that "cc" is "clang" in FreeBSD-10.
* There obviously needs to be a "gcc"
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 Friday, 30 August 2013 at 08:35, David Chisnall wrote:
> 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 timeframe.
> - libstdc++ is gone (the amount of pain it's causing ports is phenomenal).
Wouldn't this
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 8/30/13 1:02 AM, David Chisnall wrote:
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-specifi
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin wrote:
> To summarise the current issues:
>
> Our libstdc++ is ancient. It supports C++98 well, it kind-of supports
C++03. It doesn't support C++11 at all and never will, nor does it support
On Aug 29, 2013, at 11:02 AM, David Chisnall wrote:
> 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 st
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 Aug 25, 2013, at 8:21 AM, Ian Lepore wrote:
> On Sat, 2013-08-24 at 23:44 +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 build error log.
>>
>> Please file clang bu
On Aug 29, 2013, at 8:57 AM, John Baldwin wrote:
> On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
>> 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
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
> 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?)
>
2013/8/25 David Chisnall :
> Oh, and it's worth noting that clang, as an extension, supports using
> initialiser lists to create complex values and so this particular case is
> trivial to avoid if you use this feature, which you will if you create
> complex numbers using the macro that the C spe
On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote:
> 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: por
On Sun, Aug 25, 2013 at 05:24:23PM +0200, Erik Cederstrand wrote:
> Expecting FreeBSD Clang maintainers to respond to compilation issues
> in FreeBSD base seems perfectly reasonable. Expecting them to
> respond to random issues in the ~24.000 ports is not.
OK, how FreeBSD Clang maintainers can r
Den 25/08/2013 kl. 16.21 skrev Ian Lepore :
>> Please file clang bugs at http://llvm.org/bugs/
>
> And THIS is a major reason why FreeBSD needs a compiler in base instead
> of all tools being ports. The last thing we need is to start responding
> to every problem with "this is not my problem, g
On Sat, 2013-08-24 at 23:44 +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 build error log.
>
> Please file clang bugs at http://llvm.org/bugs/
>
> David
>
And THIS is
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 build error log.
>>
>> Please file cla
On Sun, Aug 25, 2013 at 12:23:45AM -0700, Rui Paulo wrote:
> On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote:
>
> > On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
> >
> >> On 24 Aug 2013, at 16:06, Steve Kargl
> >> wrote:
> >>
> >>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, Da
On Sun, Aug 25, 2013 at 02:23:54AM -0500, Scot Hetzel wrote:
> On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote:
> > On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote:
> >
> >> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
> >>
> >> > On 24 Aug 2013, at
On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote:
> On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote:
>
>> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
>>
>> > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote:
>> >
>> > > Oh, I remember. mplayer on
On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote:
> On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
>
>> On 24 Aug 2013, at 16: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
On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
> On 24 Aug 2013, at 16: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/1
On 24 Aug 2013, at 16: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 build error log.
>>
>> Please file cla
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 build error log.
>
> Please file clang bugs at http://llvm.org/bugs/
>
As if this is go
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 Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote:
> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
>
> > 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
On Aug 24, 2013, at 6:11 AM, Sam Fourman Jr. wrote:
>> In my opinion this just needs to happen, if ports break, we deal with that
>
>>> on a case by case basis.
>>
>> Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
>> don't understand inlined asm.
>>
>>
> Well, in this
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
> 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 as
On 8/24/13 3:41 PM, Roman Divacky wrote:
On Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote:
On 8/24/13 3:23 AM, Mark Felder wrote:
On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote:
On 8/23/13 7:55 PM, Poul-Henning Kamp wrote:
In message <52174d51.2050...@digsys.bg>, Daniel
On 8/24/13 7:19 PM, David Chisnall wrote:
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
On Sat, Aug 24, 2013 at 12:11:16PM +, Sam Fourman Jr. wrote:
> > In my opinion this just needs to happen, if ports break, we deal with that
>
> > > on a case by case basis.
> >
> > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
> > don't understand inlined asm.
> >
> >
> In my opinion this just needs to happen, if ports break, we deal with that
> > on a case by case basis.
>
> Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
> don't understand inlined asm.
>
>
Well, in this case, you would just have the mplayer maintainer configure the
port
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 Sat, Aug 24, 2013 at 06:30:24AM -0400, Sam Fourman Jr. wrote:
> > If the 150 ports that only work with gcc, all work with a ports
>
> > > gcc and do not need the gcc from base, would the following be OK ?
> > >
> > > - 9.x gcc default and clang in base;
> > > - 10.x clang default and gcc in po
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
> If the 150 ports that only work with gcc, all work with a ports
> > gcc and do not need the gcc from base, would the following be OK ?
> >
> > - 9.x gcc default and clang in base;
> > - 10.x clang default and gcc in ports;
>
> Well, we write rules and we brake them. ;-)
>
> Just say that we know
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 Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote:
> On 8/24/13 3:23 AM, Mark Felder wrote:
> > On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote:
> >> On 8/23/13 7:55 PM, Poul-Henning Kamp wrote:
> >>> In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes:
> >>>
> >
On 8/24/13 3:23 AM, Mark Felder wrote:
On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote:
On 8/23/13 7:55 PM, Poul-Henning Kamp wrote:
In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes:
- 9.x gcc default and clang in base;
- 10.x clang default and gcc in ports;
I believe thi
On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote:
> On 8/23/13 7:55 PM, Poul-Henning Kamp wrote:
> > In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes:
> >
> >>> - 9.x gcc default and clang in base;
> >>> - 10.x clang default and gcc in ports;
> >> I believe this is the best idea
On 8/23/13 7:55 PM, Poul-Henning Kamp wrote:
In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes:
- 9.x gcc default and clang in base;
- 10.x clang default and gcc in ports;
I believe this is the best idea so far. As long as these ports work with
gcc in ports, that is.
+1
well as
> As for me I expect something like this:
> . 9.x gcc default and clang in base;
> . 10.x clang default and gcc in base;
> . 11.x gcc withdraw.
There is also the concern whether clang in base will reliably build gcc
required for some ports, and then there are those CPU architectures for which
cl
1 - 100 of 704 matches
Mail list logo
