Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Eric Wing]

I mentioned a few months ago that I had similar struggles with the gcc
4.9 requirement. I've been trying to build JavaScriptCore in a way
that it is redistributable for Steam Linux/SteamOS (aka "Steam
Runtime"). For those that don't know, building redistributable
binaries is a nightmare in the Linux eco-system. (Linus Torvalds has
ranted about this...see Debconf 14 as an example.) Steam is one of the
most ambitious attempt to address/solve this problem, where Steam
developers can actually just compile their application in Steam
Runtime and their binaries should work everywhere Steam works (and
interestingly some other places.)

I won't go into all the details, but this means being tied to Steam
Runtime's toolchain, so they are effectively another distro. I
previously mentioned they ship gcc 4.8.1 and clang 3.6.0. I had a lot
of problems with the gcc 4.9 requirement and consider myself lucky
clang 3.6 didn't have any problems. But I'm worried this current
mentality of ditching 3 year old compilers is going to break me at
some point and leave me stranded. I am not a distro maintainer so I
have no say in what gets shipped. And if I want to distribute binaries
that work on other platforms, I can't simply upgrade my compiler.

Updating everything in general is not easy or fast. I can turn this on
WebKit and criticize why doesn't WebKit compile under Visual Studio
2015? Cross-platform takes care and time.

Thanks,
Eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizlo]

> On Apr 19, 2016, at 12:55 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.04.2016, 18:23, "Filip Pizło" >:
>>>  On Apr 19, 2016, at 5:50 AM, Carlos Alberto Lopez Perez >> > wrote:
>>> 
  On 18/04/16 21:50, Filip Pizlo wrote:
  I don't want a buildbot for MIPS. It's not a relevant architecture
  anymore. I don't think that JSC developers should have to expend
  effort towards keeping this architecture working.
>>> 
>>>  MIPS is still relevant on embedded devices (mainly set-top boxes).
>>>  It is also a popular platform for IoT projects.
>> 
>> This doesn't seem like a big enough deal to have in trunk.
>> 
>> Have you considered an out-of-tree port?
> 
> Sorry but I don't see how can it work. MIPS contributors are working on 
> different WebKit ports and trunk is the only place where we can collaborate.

Can you elaborate on this?

> 
> Also, I would like to thank WebKit reviewers for valuable input that you are 
> providing on MIPS patches. Sorry if it wastes a bit of your time, but I hope 
> it is not that much.

That’s not the point.  I’m trying to understand if MIPS qualifies as an in-tree 
port.

> 
>> 
>> -Filip
>> 
>>>  I understand that you don't want to spend time supporting this
>>>  architecture, and that is ok. Nobody is proposing here that JSC
>>>  developers should spend time maintaining JSC on MIPS.
>>> 
>>>  However, if someone is willing to do the work, I think we should let
>>>  them do it and don't actively block it.
>>> 
>>>  Having a buildbot testing JSC on MIPS certainly helps anyone interested
>>>  in maintaining this architecture.
>>> 
>>>  And anybody not interested in MIPS, can just ignore this bot.
>>> 
>>>  ___
>>>  webkit-dev mailing list
>>>  webkit-dev@lists.webkit.org
>>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> 
> -- 
> Regards,
> Konstantin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

19.04.2016, 18:23, "Filip Pizło" :
>>  On Apr 19, 2016, at 5:50 AM, Carlos Alberto Lopez Perez  
>> wrote:
>>
>>>  On 18/04/16 21:50, Filip Pizlo wrote:
>>>  I don't want a buildbot for MIPS. It's not a relevant architecture
>>>  anymore. I don't think that JSC developers should have to expend
>>>  effort towards keeping this architecture working.
>>
>>  MIPS is still relevant on embedded devices (mainly set-top boxes).
>>  It is also a popular platform for IoT projects.
>
> This doesn't seem like a big enough deal to have in trunk.
>
> Have you considered an out-of-tree port?

Sorry but I don't see how can it work. MIPS contributors are working on 
different WebKit ports and trunk is the only place where we can collaborate.

Also, I would like to thank WebKit reviewers for valuable input that you are 
providing on MIPS patches. Sorry if it wastes a bit of your time, but I hope it 
is not that much.

>
> -Filip
>
>>  I understand that you don't want to spend time supporting this
>>  architecture, and that is ok. Nobody is proposing here that JSC
>>  developers should spend time maintaining JSC on MIPS.
>>
>>  However, if someone is willing to do the work, I think we should let
>>  them do it and don't actively block it.
>>
>>  Having a buildbot testing JSC on MIPS certainly helps anyone interested
>>  in maintaining this architecture.
>>
>>  And anybody not interested in MIPS, can just ignore this bot.
>>
>>  ___
>>  webkit-dev mailing list
>>  webkit-dev@lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

19.04.2016, 22:22, "Anders Carlsson" :
>> On Apr 19, 2016, at 12:21 PM, Konstantin Tokarev  wrote:
>>
>> 19.04.2016, 22:11, "Anders Carlsson" :
  On Apr 19, 2016, at 12:09 PM, Konstantin Tokarev  
 wrote:

  19.04.2016, 21:38, "Anders Carlsson" :
>  I’d like us to switch over to using C++14 in WebKit2 so we can get the 
> new generalized lambda capture 
> (https://isocpp.org/files/papers/N3648.html), so we can capture move-only 
> types in lambdas. According to 
> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.

  This code compiles fine with GCC 4.8 with -std=c++1y flag:

  auto f(std::unique_ptr ptr)
  {
 [value = std::move(ptr)] {return *value;};
  }
>>>
>>> GCC 4.8 has “partial” support, which may or may not be OK for our purposes. 
>>> I’d rather be safe than sorry.
>>
>> From https://gcc.gnu.org/gcc-4.9/changes.html#cxx:
>>
>> "
>> G++ supports C++1y lambda capture initializers:
>>
>>    [x = 42]{ ... };
>>
>> Actually, they have been accepted since GCC 4.5, but now the compiler 
>> doesn't warn about them with -std=c++1y, and supports parenthesized and 
>> brace-enclosed initializers as well.
>> "
>>
>> So it states pretty clearly what is supported only since 4.9
> According do  https://gcc.gnu.org/projects/cxx-status.html (which I linked in 
> original e-mail), GCC 4.5 has “partial” support.
>

...and quote from release notes above explains that "partial" means "without 
parenthesized and brace-enclosed initializers".

Also, you cannot be safe with GCC anyway, it often has bugs in newly introduced 
features which are discovered only after you write sufficiently sofisticated 
code using this feature.

However, this is fine with me if you start using C++14 constructions 
incompatible with GCC 4.8 in WebKit2. I was asking only about allowing GCC 4.8 
for WTF and JSC.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

> On Apr 19, 2016, at 12:21 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.04.2016, 22:11, "Anders Carlsson" :
>>>  On Apr 19, 2016, at 12:09 PM, Konstantin Tokarev  wrote:
>>> 
>>>  19.04.2016, 21:38, "Anders Carlsson" :
  I’d like us to switch over to using C++14 in WebKit2 so we can get the 
 new generalized lambda capture 
 (https://isocpp.org/files/papers/N3648.html), so we can capture move-only 
 types in lambdas. According to 
 https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.
>>> 
>>>  This code compiles fine with GCC 4.8 with -std=c++1y flag:
>>> 
>>>  auto f(std::unique_ptr ptr)
>>>  {
>>> [value = std::move(ptr)] {return *value;};
>>>  }
>> 
>> GCC 4.8 has “partial” support, which may or may not be OK for our purposes. 
>> I’d rather be safe than sorry.
> 
> From https://gcc.gnu.org/gcc-4.9/changes.html#cxx:
> 
> "
> G++ supports C++1y lambda capture initializers:
> 
>[x = 42]{ ... };
> 
> Actually, they have been accepted since GCC 4.5, but now the compiler doesn't 
> warn about them with -std=c++1y, and supports parenthesized and 
> brace-enclosed initializers as well. 
> "
> 
> So it states pretty clearly what is supported only since 4.9

According do  https://gcc.gnu.org/projects/cxx-status.html 
 (which I linked in original 
e-mail), GCC 4.5 has “partial” support.

- Anders

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

19.04.2016, 22:11, "Anders Carlsson" :
>>  On Apr 19, 2016, at 12:09 PM, Konstantin Tokarev  wrote:
>>
>>  19.04.2016, 21:38, "Anders Carlsson" :
>>>  I’d like us to switch over to using C++14 in WebKit2 so we can get the new 
>>> generalized lambda capture (https://isocpp.org/files/papers/N3648.html), so 
>>> we can capture move-only types in lambdas. According to 
>>> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.
>>
>>  This code compiles fine with GCC 4.8 with -std=c++1y flag:
>>
>>  auto f(std::unique_ptr ptr)
>>  {
>> [value = std::move(ptr)] {return *value;};
>>  }
>
> GCC 4.8 has “partial” support, which may or may not be OK for our purposes. 
> I’d rather be safe than sorry.

From https://gcc.gnu.org/gcc-4.9/changes.html#cxx:

"
G++ supports C++1y lambda capture initializers:

[x = 42]{ ... };

Actually, they have been accepted since GCC 4.5, but now the compiler doesn't 
warn about them with -std=c++1y, and supports parenthesized and brace-enclosed 
initializers as well. 
"

So it states pretty clearly what is supported only since 4.9


>
> - Anders

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

> On Apr 19, 2016, at 12:09 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.04.2016, 21:38, "Anders Carlsson" :
>> I’d like us to switch over to using C++14 in WebKit2 so we can get the new 
>> generalized lambda capture (https://isocpp.org/files/papers/N3648.html), so 
>> we can capture move-only types in lambdas. According to 
>> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.
> 
> This code compiles fine with GCC 4.8 with -std=c++1y flag:
> 
> auto f(std::unique_ptr ptr)
> {
>[value = std::move(ptr)] {return *value;};
> }

GCC 4.8 has “partial” support, which may or may not be OK for our purposes. I’d 
rather be safe than sorry.

- Anders

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

19.04.2016, 21:38, "Anders Carlsson" :
> I’d like us to switch over to using C++14 in WebKit2 so we can get the new 
> generalized lambda capture (https://isocpp.org/files/papers/N3648.html), so 
> we can capture move-only types in lambdas. According to 
> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.

This code compiles fine with GCC 4.8 with -std=c++1y flag:

auto f(std::unique_ptr ptr)
{
[value = std::move(ptr)] {return *value;};
}


>
> - Anders
>
>> On Apr 19, 2016, at 11:14 AM, Filip Pizlo  wrote:
>>
>> I did a quick look over the trac query of GCC 4.8 changes that you provided. 
>>  None of the ones I looked at were scary but they were annoying.  They 
>> seemed to be things like:
>>
>> - Sometimes saying { } to initialize a variable doesn’t work.
>> - Sometimes you need to say “const”.
>> - Sometimes you need to play with variables to get around internal compiler 
>> errors.
>>
>> I didn’t find any cases of GCC 4.8 not supporting a language feature that we 
>> want to use.  Do you think that’s correct?
>>
>> -Filip
>>
>>> On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
 I am sympathetic to the principle that we should support the
 compilers that ship on the most popular versions of Linux.
>>>
>>> Great. :)
>>>
 I’d like to understand if that argument is sufficient to support GCC
 4.8.

 Can you clarify, is it the case that if I installed the latest stable
 Fedora, I’d get GCC 4.8?
>>>
>>> No, all currently-supported versions of Fedora include GCC 5 (only).
>>> Different distros have very different release cycles and policies for
>>> compiler upgrades. Fedora releases roughly every six months, and each
>>> release is supported for roughly 13 months. GCC releases once per year.
>>> The GCC developers coordinate with Fedora release planning to time GCC
>>> releases to coincide with spring Fedora releases; in the winter before
>>> a new GCC release, we rebuilt all of Fedora with the GCC beta so the
>>> GCC developers can collect bug reports. So we will never have issues
>>> with Fedora, as the oldest Fedora will be at most one year behind
>>> upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
>>> I'm making sure all supported Fedoras get updates.)
>>>
>>> But Fedora is exceptional in this regard. Other distros are supported
>>> for much longer than 13 months (5 years for Ubuntu LTS and newly also
>>> for Debian, 10 years for enterprise distros) and therefore have much
>>> older compilers. The question is where do we draw the line. We
>>> obviously cannot support a 10 year old distro; those are maintained by
>>> rich corporations, and if they cared about WebKit security, they could
>>> take responsibility for that. We could handle 5 years, but do we really
>>> want to? (It's clear Apple doesn't.) It's really inconvenient to not
>>> have access to newer dependencies or language features for so long. We
>>> might start by saying that we only support the latest release of [list
>>> of major distros that have recently been shipping WebKit updates]. Most
>>> of these distros are currently built using GCC 4.9, though they might
>>> have GCC 5 or GCC 6 packaged as well, but not used by default. The big
>>> one still using GCC 4.8 is openSUSE.
>>>
>>> We don't *need* to consider Ubuntu right now, because they rarely ever
>>> take our updates, nor Debian, because they never take our updates. I
>>> think WebKit updates for Debian is all but totally a lost cause, but
>>> I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
>>>
>>> Also, different distros have different policies on using alternative
>>> compilers. E.g. in Fedora we are usually required to always use
>>> Fedora's GCC, and only one version is available at a time... but if a
>>> package *really* has no chance of being built with GCC, we're allowed
>>> to use Fedora's Clang instead. I'm not sure what the policies are for
>>> Debian and Ubuntu, but they always have available a newer GCC than is
>>> used for building packages, and until recently were using Clang to
>>> build Chromium, so alternative compilers must be permitted at least in
>>> exceptional cases. I was trying to convince the openSUSE folks to use
>>> Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
>>> enthusiastic. (But consider that all these distros will have older
>>> versions of Clang as well.)
>>>
>>> Now, whether openSUSE is important enough on its own to justify holding
>>> back or lowering our GCC requirement... maybe not. But anyway, since we
>>> have significant contributors like Konstantin stuck with GCC 4.8, and
>>> since this doesn't require giving up on any significant language
>>> features, I think it's OK. If it's only a little work to support that
>>> compiler (on the level we already have in trunk), I think 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

19.04.2016, 21:34, "Filip Pizlo" :
>> On Apr 19, 2016, at 11:33 AM, Konstantin Tokarev  wrote:
>>
>> 19.04.2016, 21:15, "Filip Pizlo" :
>>> I did a quick look over the trac query of GCC 4.8 changes that you 
>>> provided. None of the ones I looked at were scary but they were annoying. 
>>> They seemed to be things like:
>>>
>>> - Sometimes saying { } to initialize a variable doesn’t work.
>>> - Sometimes you need to say “const”.
>>> - Sometimes you need to play with variables to get around internal compiler 
>>> errors.
>>>
>>> I didn’t find any cases of GCC 4.8 not supporting a language feature that 
>>> we want to use. Do you think that’s correct?
>>
>> According to [1], GCC provides complete C++11 feature list since 4.8.1. 
>> However, it fails to compile FTLLazySlowPathCall.h, see complete set of 
>> diagnostics in [2].
>
> Ouch!  Is there a bug for this?

GCC bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933

No WebKit bug because GCC 4.8 was not officially supported


>
> -Filip
>
>> There is another minor bug: 4.8 does not allow aggregate initialization for 
>> structs which have deleted constructors [3].
>>
>> [1] https://gcc.gnu.org/projects/cxx-status.html#cxx11
>> [2] http://pastebin.com/ikyDTZ9s
>> [3] https://bugs.webkit.org/show_bug.cgi?id=155698
>>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707
>>
>>> -Filip
>>>
  On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  
 wrote:

  Hi,

  On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
>  I am sympathetic to the principle that we should support the
>  compilers that ship on the most popular versions of Linux.

  Great. :)

>  I’d like to understand if that argument is sufficient to support GCC
>  4.8.
>
>  Can you clarify, is it the case that if I installed the latest stable
>  Fedora, I’d get GCC 4.8?

  No, all currently-supported versions of Fedora include GCC 5 (only).
  Different distros have very different release cycles and policies for
  compiler upgrades. Fedora releases roughly every six months, and each
  release is supported for roughly 13 months. GCC releases once per year.
  The GCC developers coordinate with Fedora release planning to time GCC
  releases to coincide with spring Fedora releases; in the winter before
  a new GCC release, we rebuilt all of Fedora with the GCC beta so the
  GCC developers can collect bug reports. So we will never have issues
  with Fedora, as the oldest Fedora will be at most one year behind
  upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
  I'm making sure all supported Fedoras get updates.)

  But Fedora is exceptional in this regard. Other distros are supported
  for much longer than 13 months (5 years for Ubuntu LTS and newly also
  for Debian, 10 years for enterprise distros) and therefore have much
  older compilers. The question is where do we draw the line. We
  obviously cannot support a 10 year old distro; those are maintained by
  rich corporations, and if they cared about WebKit security, they could
  take responsibility for that. We could handle 5 years, but do we really
  want to? (It's clear Apple doesn't.) It's really inconvenient to not
  have access to newer dependencies or language features for so long. We
  might start by saying that we only support the latest release of [list
  of major distros that have recently been shipping WebKit updates]. Most
  of these distros are currently built using GCC 4.9, though they might
  have GCC 5 or GCC 6 packaged as well, but not used by default. The big
  one still using GCC 4.8 is openSUSE.

  We don't *need* to consider Ubuntu right now, because they rarely ever
  take our updates, nor Debian, because they never take our updates. I
  think WebKit updates for Debian is all but totally a lost cause, but
  I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.

  Also, different distros have different policies on using alternative
  compilers. E.g. in Fedora we are usually required to always use
  Fedora's GCC, and only one version is available at a time... but if a
  package *really* has no chance of being built with GCC, we're allowed
  to use Fedora's Clang instead. I'm not sure what the policies are for
  Debian and Ubuntu, but they always have available a newer GCC than is
  used for building packages, and until recently were using Clang to
  build Chromium, so alternative compilers must be permitted at least in
  exceptional cases. I was trying to convince the openSUSE folks to use
  Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
  enthusiastic. (But consider that all these distros will have 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

I’d like us to switch over to using C++14 in WebKit2 so we can get the new 
generalized lambda capture (https://isocpp.org/files/papers/N3648.html 
), so we can capture move-only 
types in lambdas. According to https://gcc.gnu.org/projects/cxx-status.html 
 that would require GCC 4.9.

- Anders

> On Apr 19, 2016, at 11:14 AM, Filip Pizlo  wrote:
> 
> I did a quick look over the trac query of GCC 4.8 changes that you provided.  
> None of the ones I looked at were scary but they were annoying.  They seemed 
> to be things like:
> 
> - Sometimes saying { } to initialize a variable doesn’t work.
> - Sometimes you need to say “const”.
> - Sometimes you need to play with variables to get around internal compiler 
> errors.
> 
> I didn’t find any cases of GCC 4.8 not supporting a language feature that we 
> want to use.  Do you think that’s correct?
> 
> -Filip
> 
> 
>> On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  
>> wrote:
>> 
>> Hi,
>> 
>> On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
>>> I am sympathetic to the principle that we should support the
>>> compilers that ship on the most popular versions of Linux.
>> 
>> Great. :)
>> 
>>> I’d like to understand if that argument is sufficient to support GCC
>>> 4.8.
>>> 
>>> Can you clarify, is it the case that if I installed the latest stable
>>> Fedora, I’d get GCC 4.8?
>> 
>> No, all currently-supported versions of Fedora include GCC 5 (only).
>> Different distros have very different release cycles and policies for
>> compiler upgrades. Fedora releases roughly every six months, and each
>> release is supported for roughly 13 months. GCC releases once per year.
>> The GCC developers coordinate with Fedora release planning to time GCC
>> releases to coincide with spring Fedora releases; in the winter before
>> a new GCC release, we rebuilt all of Fedora with the GCC beta so the
>> GCC developers can collect bug reports. So we will never have issues
>> with Fedora, as the oldest Fedora will be at most one year behind
>> upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
>> I'm making sure all supported Fedoras get updates.)
>> 
>> But Fedora is exceptional in this regard. Other distros are supported
>> for much longer than 13 months (5 years for Ubuntu LTS and newly also
>> for Debian, 10 years for enterprise distros) and therefore have much
>> older compilers. The question is where do we draw the line. We
>> obviously cannot support a 10 year old distro; those are maintained by
>> rich corporations, and if they cared about WebKit security, they could
>> take responsibility for that. We could handle 5 years, but do we really
>> want to? (It's clear Apple doesn't.) It's really inconvenient to not
>> have access to newer dependencies or language features for so long. We
>> might start by saying that we only support the latest release of [list
>> of major distros that have recently been shipping WebKit updates]. Most
>> of these distros are currently built using GCC 4.9, though they might
>> have GCC 5 or GCC 6 packaged as well, but not used by default. The big
>> one still using GCC 4.8 is openSUSE.
>> 
>> We don't *need* to consider Ubuntu right now, because they rarely ever
>> take our updates, nor Debian, because they never take our updates. I
>> think WebKit updates for Debian is all but totally a lost cause, but
>> I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
>> 
>> Also, different distros have different policies on using alternative
>> compilers. E.g. in Fedora we are usually required to always use
>> Fedora's GCC, and only one version is available at a time... but if a
>> package *really* has no chance of being built with GCC, we're allowed
>> to use Fedora's Clang instead. I'm not sure what the policies are for
>> Debian and Ubuntu, but they always have available a newer GCC than is
>> used for building packages, and until recently were using Clang to
>> build Chromium, so alternative compilers must be permitted at least in
>> exceptional cases. I was trying to convince the openSUSE folks to use
>> Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
>> enthusiastic. (But consider that all these distros will have older
>> versions of Clang as well.)
>> 
>> Now, whether openSUSE is important enough on its own to justify holding
>> back or lowering our GCC requirement... maybe not. But anyway, since we
>> have significant contributors like Konstantin stuck with GCC 4.8, and
>> since this doesn't require giving up on any significant language
>> features, I think it's OK. If it's only a little work to support that
>> compiler (on the level we already have in trunk), I think it's a good
>> idea.
>> 
>> But there is another problem here. openSUSE seems to have no intention
>> of upgrading to a newer GCC anytime soon, because they have started to
>> inherit core 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizlo]

> On Apr 19, 2016, at 11:33 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.04.2016, 21:15, "Filip Pizlo" >:
>> I did a quick look over the trac query of GCC 4.8 changes that you provided. 
>> None of the ones I looked at were scary but they were annoying. They seemed 
>> to be things like:
>> 
>> - Sometimes saying { } to initialize a variable doesn’t work.
>> - Sometimes you need to say “const”.
>> - Sometimes you need to play with variables to get around internal compiler 
>> errors.
>> 
>> I didn’t find any cases of GCC 4.8 not supporting a language feature that we 
>> want to use. Do you think that’s correct?
> 
> According to [1], GCC provides complete C++11 feature list since 4.8.1. 
> However, it fails to compile FTLLazySlowPathCall.h, see complete set of 
> diagnostics in [2].

Ouch!  Is there a bug for this?

-Filip


> 
> There is another minor bug: 4.8 does not allow aggregate initialization for 
> structs which have deleted constructors [3].
> 
> [1] https://gcc.gnu.org/projects/cxx-status.html#cxx11 
> 
> [2] http://pastebin.com/ikyDTZ9s 
> [3] https://bugs.webkit.org/show_bug.cgi?id=155698 
> 
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707 
> 
> 
>> 
>> -Filip
>> 
>>>  On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  
>>> wrote:
>>> 
>>>  Hi,
>>> 
>>>  On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
  I am sympathetic to the principle that we should support the
  compilers that ship on the most popular versions of Linux.
>>> 
>>>  Great. :)
>>> 
  I’d like to understand if that argument is sufficient to support GCC
  4.8.
 
  Can you clarify, is it the case that if I installed the latest stable
  Fedora, I’d get GCC 4.8?
>>> 
>>>  No, all currently-supported versions of Fedora include GCC 5 (only).
>>>  Different distros have very different release cycles and policies for
>>>  compiler upgrades. Fedora releases roughly every six months, and each
>>>  release is supported for roughly 13 months. GCC releases once per year.
>>>  The GCC developers coordinate with Fedora release planning to time GCC
>>>  releases to coincide with spring Fedora releases; in the winter before
>>>  a new GCC release, we rebuilt all of Fedora with the GCC beta so the
>>>  GCC developers can collect bug reports. So we will never have issues
>>>  with Fedora, as the oldest Fedora will be at most one year behind
>>>  upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
>>>  I'm making sure all supported Fedoras get updates.)
>>> 
>>>  But Fedora is exceptional in this regard. Other distros are supported
>>>  for much longer than 13 months (5 years for Ubuntu LTS and newly also
>>>  for Debian, 10 years for enterprise distros) and therefore have much
>>>  older compilers. The question is where do we draw the line. We
>>>  obviously cannot support a 10 year old distro; those are maintained by
>>>  rich corporations, and if they cared about WebKit security, they could
>>>  take responsibility for that. We could handle 5 years, but do we really
>>>  want to? (It's clear Apple doesn't.) It's really inconvenient to not
>>>  have access to newer dependencies or language features for so long. We
>>>  might start by saying that we only support the latest release of [list
>>>  of major distros that have recently been shipping WebKit updates]. Most
>>>  of these distros are currently built using GCC 4.9, though they might
>>>  have GCC 5 or GCC 6 packaged as well, but not used by default. The big
>>>  one still using GCC 4.8 is openSUSE.
>>> 
>>>  We don't *need* to consider Ubuntu right now, because they rarely ever
>>>  take our updates, nor Debian, because they never take our updates. I
>>>  think WebKit updates for Debian is all but totally a lost cause, but
>>>  I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
>>> 
>>>  Also, different distros have different policies on using alternative
>>>  compilers. E.g. in Fedora we are usually required to always use
>>>  Fedora's GCC, and only one version is available at a time... but if a
>>>  package *really* has no chance of being built with GCC, we're allowed
>>>  to use Fedora's Clang instead. I'm not sure what the policies are for
>>>  Debian and Ubuntu, but they always have available a newer GCC than is
>>>  used for building packages, and until recently were using Clang to
>>>  build Chromium, so alternative compilers must be permitted at least in
>>>  exceptional cases. I was trying to convince the openSUSE folks to use
>>>  Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
>>>  enthusiastic. (But consider that all these distros will have older
>>>  versions of Clang as well.)
>>> 
>>>  Now, whether openSUSE is 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

19.04.2016, 21:15, "Filip Pizlo" :
> I did a quick look over the trac query of GCC 4.8 changes that you provided. 
> None of the ones I looked at were scary but they were annoying. They seemed 
> to be things like:
>
> - Sometimes saying { } to initialize a variable doesn’t work.
> - Sometimes you need to say “const”.
> - Sometimes you need to play with variables to get around internal compiler 
> errors.
>
> I didn’t find any cases of GCC 4.8 not supporting a language feature that we 
> want to use. Do you think that’s correct?

According to [1], GCC provides complete C++11 feature list since 4.8.1. 
However, it fails to compile FTLLazySlowPathCall.h, see complete set of 
diagnostics in [2].

There is another minor bug: 4.8 does not allow aggregate initialization for 
structs which have deleted constructors [3].

[1] https://gcc.gnu.org/projects/cxx-status.html#cxx11
[2] http://pastebin.com/ikyDTZ9s
[3] https://bugs.webkit.org/show_bug.cgi?id=155698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707

>
> -Filip
>
>>  On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  
>> wrote:
>>
>>  Hi,
>>
>>  On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
>>>  I am sympathetic to the principle that we should support the
>>>  compilers that ship on the most popular versions of Linux.
>>
>>  Great. :)
>>
>>>  I’d like to understand if that argument is sufficient to support GCC
>>>  4.8.
>>>
>>>  Can you clarify, is it the case that if I installed the latest stable
>>>  Fedora, I’d get GCC 4.8?
>>
>>  No, all currently-supported versions of Fedora include GCC 5 (only).
>>  Different distros have very different release cycles and policies for
>>  compiler upgrades. Fedora releases roughly every six months, and each
>>  release is supported for roughly 13 months. GCC releases once per year.
>>  The GCC developers coordinate with Fedora release planning to time GCC
>>  releases to coincide with spring Fedora releases; in the winter before
>>  a new GCC release, we rebuilt all of Fedora with the GCC beta so the
>>  GCC developers can collect bug reports. So we will never have issues
>>  with Fedora, as the oldest Fedora will be at most one year behind
>>  upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
>>  I'm making sure all supported Fedoras get updates.)
>>
>>  But Fedora is exceptional in this regard. Other distros are supported
>>  for much longer than 13 months (5 years for Ubuntu LTS and newly also
>>  for Debian, 10 years for enterprise distros) and therefore have much
>>  older compilers. The question is where do we draw the line. We
>>  obviously cannot support a 10 year old distro; those are maintained by
>>  rich corporations, and if they cared about WebKit security, they could
>>  take responsibility for that. We could handle 5 years, but do we really
>>  want to? (It's clear Apple doesn't.) It's really inconvenient to not
>>  have access to newer dependencies or language features for so long. We
>>  might start by saying that we only support the latest release of [list
>>  of major distros that have recently been shipping WebKit updates]. Most
>>  of these distros are currently built using GCC 4.9, though they might
>>  have GCC 5 or GCC 6 packaged as well, but not used by default. The big
>>  one still using GCC 4.8 is openSUSE.
>>
>>  We don't *need* to consider Ubuntu right now, because they rarely ever
>>  take our updates, nor Debian, because they never take our updates. I
>>  think WebKit updates for Debian is all but totally a lost cause, but
>>  I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
>>
>>  Also, different distros have different policies on using alternative
>>  compilers. E.g. in Fedora we are usually required to always use
>>  Fedora's GCC, and only one version is available at a time... but if a
>>  package *really* has no chance of being built with GCC, we're allowed
>>  to use Fedora's Clang instead. I'm not sure what the policies are for
>>  Debian and Ubuntu, but they always have available a newer GCC than is
>>  used for building packages, and until recently were using Clang to
>>  build Chromium, so alternative compilers must be permitted at least in
>>  exceptional cases. I was trying to convince the openSUSE folks to use
>>  Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
>>  enthusiastic. (But consider that all these distros will have older
>>  versions of Clang as well.)
>>
>>  Now, whether openSUSE is important enough on its own to justify holding
>>  back or lowering our GCC requirement... maybe not. But anyway, since we
>>  have significant contributors like Konstantin stuck with GCC 4.8, and
>>  since this doesn't require giving up on any significant language
>>  features, I think it's OK. If it's only a little work to support that
>>  compiler (on the level we already have in trunk), I think it's a good
>>  idea.
>>
>>  But there is another problem here. 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizlo]

I did a quick look over the trac query of GCC 4.8 changes that you provided.  
None of the ones I looked at were scary but they were annoying.  They seemed to 
be things like:

- Sometimes saying { } to initialize a variable doesn’t work.
- Sometimes you need to say “const”.
- Sometimes you need to play with variables to get around internal compiler 
errors.

I didn’t find any cases of GCC 4.8 not supporting a language feature that we 
want to use.  Do you think that’s correct?

-Filip


> On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
>> I am sympathetic to the principle that we should support the
>> compilers that ship on the most popular versions of Linux.
> 
> Great. :)
> 
>> I’d like to understand if that argument is sufficient to support GCC
>> 4.8.
>> 
>> Can you clarify, is it the case that if I installed the latest stable
>> Fedora, I’d get GCC 4.8?
> 
> No, all currently-supported versions of Fedora include GCC 5 (only).
> Different distros have very different release cycles and policies for
> compiler upgrades. Fedora releases roughly every six months, and each
> release is supported for roughly 13 months. GCC releases once per year.
> The GCC developers coordinate with Fedora release planning to time GCC
> releases to coincide with spring Fedora releases; in the winter before
> a new GCC release, we rebuilt all of Fedora with the GCC beta so the
> GCC developers can collect bug reports. So we will never have issues
> with Fedora, as the oldest Fedora will be at most one year behind
> upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
> I'm making sure all supported Fedoras get updates.)
> 
> But Fedora is exceptional in this regard. Other distros are supported
> for much longer than 13 months (5 years for Ubuntu LTS and newly also
> for Debian, 10 years for enterprise distros) and therefore have much
> older compilers. The question is where do we draw the line. We
> obviously cannot support a 10 year old distro; those are maintained by
> rich corporations, and if they cared about WebKit security, they could
> take responsibility for that. We could handle 5 years, but do we really
> want to? (It's clear Apple doesn't.) It's really inconvenient to not
> have access to newer dependencies or language features for so long. We
> might start by saying that we only support the latest release of [list
> of major distros that have recently been shipping WebKit updates]. Most
> of these distros are currently built using GCC 4.9, though they might
> have GCC 5 or GCC 6 packaged as well, but not used by default. The big
> one still using GCC 4.8 is openSUSE.
> 
> We don't *need* to consider Ubuntu right now, because they rarely ever
> take our updates, nor Debian, because they never take our updates. I
> think WebKit updates for Debian is all but totally a lost cause, but
> I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
> 
> Also, different distros have different policies on using alternative
> compilers. E.g. in Fedora we are usually required to always use
> Fedora's GCC, and only one version is available at a time... but if a
> package *really* has no chance of being built with GCC, we're allowed
> to use Fedora's Clang instead. I'm not sure what the policies are for
> Debian and Ubuntu, but they always have available a newer GCC than is
> used for building packages, and until recently were using Clang to
> build Chromium, so alternative compilers must be permitted at least in
> exceptional cases. I was trying to convince the openSUSE folks to use
> Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
> enthusiastic. (But consider that all these distros will have older
> versions of Clang as well.)
> 
> Now, whether openSUSE is important enough on its own to justify holding
> back or lowering our GCC requirement... maybe not. But anyway, since we
> have significant contributors like Konstantin stuck with GCC 4.8, and
> since this doesn't require giving up on any significant language
> features, I think it's OK. If it's only a little work to support that
> compiler (on the level we already have in trunk), I think it's a good
> idea.
> 
> But there is another problem here. openSUSE seems to have no intention
> of upgrading to a newer GCC anytime soon, because they have started to
> inherit core packages like GCC from the SUSE enterprise distro. So I
> might need to negotiate with them if it would be possible to build
> WebKit with clang after all.
> 
>> Can you clarify what you mean by “backport”?  I’m trying to get a
>> picture of how your releases work.  For example, are you saying that
>> RHEL wouldn’t take a security update that you backported, or that
>> they won’t invest energy into backporting it themselves?
> 
> We don't try to convince distros to take individual security fixes as
> patches, because there are way too many for that to be 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

Hi,

On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
> I am sympathetic to the principle that we should support the
> compilers that ship on the most popular versions of Linux.

Great. :)

> I’d like to understand if that argument is sufficient to support GCC
> 4.8.
> 
> Can you clarify, is it the case that if I installed the latest stable
> Fedora, I’d get GCC 4.8?

No, all currently-supported versions of Fedora include GCC 5 (only).
Different distros have very different release cycles and policies for
compiler upgrades. Fedora releases roughly every six months, and each
release is supported for roughly 13 months. GCC releases once per year.
The GCC developers coordinate with Fedora release planning to time GCC
releases to coincide with spring Fedora releases; in the winter before
a new GCC release, we rebuilt all of Fedora with the GCC beta so the
GCC developers can collect bug reports. So we will never have issues
with Fedora, as the oldest Fedora will be at most one year behind
upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
I'm making sure all supported Fedoras get updates.)

But Fedora is exceptional in this regard. Other distros are supported
for much longer than 13 months (5 years for Ubuntu LTS and newly also
for Debian, 10 years for enterprise distros) and therefore have much
older compilers. The question is where do we draw the line. We
obviously cannot support a 10 year old distro; those are maintained by
rich corporations, and if they cared about WebKit security, they could
take responsibility for that. We could handle 5 years, but do we really
want to? (It's clear Apple doesn't.) It's really inconvenient to not
have access to newer dependencies or language features for so long. We
might start by saying that we only support the latest release of [list
of major distros that have recently been shipping WebKit updates]. Most
of these distros are currently built using GCC 4.9, though they might
have GCC 5 or GCC 6 packaged as well, but not used by default. The big
one still using GCC 4.8 is openSUSE.

We don't *need* to consider Ubuntu right now, because they rarely ever
take our updates, nor Debian, because they never take our updates. I
think WebKit updates for Debian is all but totally a lost cause, but
I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.

Also, different distros have different policies on using alternative
compilers. E.g. in Fedora we are usually required to always use
Fedora's GCC, and only one version is available at a time... but if a
package *really* has no chance of being built with GCC, we're allowed
to use Fedora's Clang instead. I'm not sure what the policies are for
Debian and Ubuntu, but they always have available a newer GCC than is
used for building packages, and until recently were using Clang to
build Chromium, so alternative compilers must be permitted at least in
exceptional cases. I was trying to convince the openSUSE folks to use
Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
enthusiastic. (But consider that all these distros will have older
versions of Clang as well.)

Now, whether openSUSE is important enough on its own to justify holding
back or lowering our GCC requirement... maybe not. But anyway, since we
have significant contributors like Konstantin stuck with GCC 4.8, and
since this doesn't require giving up on any significant language
features, I think it's OK. If it's only a little work to support that
compiler (on the level we already have in trunk), I think it's a good
idea.

But there is another problem here. openSUSE seems to have no intention
of upgrading to a newer GCC anytime soon, because they have started to
inherit core packages like GCC from the SUSE enterprise distro. So I
might need to negotiate with them if it would be possible to build
WebKit with clang after all.

> Can you clarify what you mean by “backport”?  I’m trying to get a
> picture of how your releases work.  For example, are you saying that
> RHEL wouldn’t take a security update that you backported, or that
> they won’t invest energy into backporting it themselves?

We don't try to convince distros to take individual security fixes as
patches, because there are way too many for that to be practical. We
want them to take our tarball updates.

In that mail I was saying that RHEL won't invest energy into
backporting things themselves downstream; consider that we have about
100 security fixes per year, backporting from trunk needs to be handled
upstream so this can be shared among distros, rather than separately by
each distro that wants to provide WebKit updates. Our upstream
WebKitGTK+ releases work like this: every February and August, we
branch off of trunk; this forms a new stable branch, which gets
released in March/September. We then cherry-pick fixes to that branch
and make releases off of it for the next seven months or so. Our goal
is to convince distros to take these releases, because it's the only

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

On Mon, 2016-04-18 at 17:26 -0700, Filip Pizlo wrote:
> Yeah.  If we allow GCC 4.8 then I think we should make all of our
> code compile with it.  If that proves too difficult (like if we had
> to get rid of all lambdas), then I think we need to not allow GCC
> 4.8.

Agreed. And don't worry, we would not have to get rid of lambdas...
that would not be a reasonable proposal.

I can confirm that WebKitGTK+ 2.10.7 works fine with GCC 4.8.5 when
patched to remove the error we added to require use of GCC 4.9, and
when using -DENABLE_DATABASE_PROCESS=OFF and -DENABLE_INDEXED_DB=OFF
(undesirable but acceptable IMO). I'm not sure if the database process
disablement is still required with the latest GCC 4.8 release, but it
was crashing at some point in the past.

Now, there are eight months of changes in trunk since that last
confirmed-working version; if we were to lower the supported GCC
version, we would have to investigate to see if it still works with
trunk.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizło]

> On Apr 19, 2016, at 5:50 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
>> On 18/04/16 21:50, Filip Pizlo wrote:
>> I don't want a buildbot for MIPS. It's not a relevant architecture
>> anymore. I don't think that JSC developers should have to expend
>> effort towards keeping this architecture working.
> 
> MIPS is still relevant on embedded devices (mainly set-top boxes).
> It is also a popular platform for IoT projects.

This doesn't seem like a big enough deal to have in trunk. 

Have you considered an out-of-tree port?

-Filip

> 
> I understand that you don't want to spend time supporting this
> architecture, and that is ok. Nobody is proposing here that JSC
> developers should spend time maintaining JSC on MIPS.
> 
> However, if someone is willing to do the work, I think we should let
> them do it and don't actively block it.
> 
> Having a buildbot testing JSC on MIPS certainly helps anyone interested
> in maintaining this architecture.
> 
> And anybody not interested in MIPS, can just ignore this bot.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS [WARNING - NOT VIRUS SCANNED]

[Filip Pizło]

I think that this is probably OK for the purposes of not creating obligations 
but I don't see it as a viable strategy for making WebKit work of MIPS. 

For example, you guys haven't even shown that JSC can pass all WebKit tests on 
MIPS. You haven't shown that the MIPS JIT produces a speed up over cloop on 
MIPS. My fear is that MIPS lags in correctness and that this will always be the 
case so long as the porting strategy is to track trunk. If that's the case then 
the MIPS changes will just cause noise for us and will not accomplish the goal 
of having a stable version of WebKit that works great on MIPS. 

Can you offer some insight into the current testing and perf status of MIPS?

-Filip

> On Apr 19, 2016, at 5:53 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.04.2016, 15:24, "Osztrogonác Csaba" :
>> Hi,
>> 
>> now the #error macro in Compiler.h is the only one blocker to
>> be able to build JSCOnly port with GCC 4.8 (without FTL JIT):
>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Compiler.h#L73
>> 
>> The existance of a buildbot doesn't mean any obligation for anybody.
>> We have many bots which are allowed to break. Everybody is allowed
>> to break the Apple Mac cmake build, WebKit2 owners can break EFL/GTK
>> builds, JSC developers can break ARM Linux builds.
> 
> 
> I also would like to note that existence of MIPS bot does not oblige JSC 
> developers who don't work on MIPS to keep it green, e.g. by implementing 
> missing MacroAssembler functions. However, having such bot might be useful in 
> case of refactorings which involve moving MIPS code around, which already 
> happened in the past.
> 
>> 
>> br,
>> Ossy
>> 
>> Filip Pizlo írta:
>>>  I don't want a buildbot for MIPS. It's not a relevant architecture 
>>> anymore. I don't think that JSC developers should have to expend effort 
>>> towards keeping this architecture working.
>>> 
>>>  -Filip
>>> 
  On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  
 wrote:
 
  Hello,
 
  I'd like to run build slave for MIPS port of JSC (with JSCOnly port on 
 Linux). On the first iteration it will just ensure that compilation is not 
 broken, afterwards I'm planning to add running tests on target.
 
  However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, 
 the latest one supplied by Broadcom), and unmodified tree won't build 
 because of GCC version check in Source/WTF/wtf/Compiler.h.
 
  Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
 (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
 errors myself.
 
  --
  Regards,
  Konstantin
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS [WARNING - NOT VIRUS SCANNED]

[Konstantin Tokarev]

19.04.2016, 15:24, "Osztrogonác Csaba" :
> Hi,
>
> now the #error macro in Compiler.h is the only one blocker to
> be able to build JSCOnly port with GCC 4.8 (without FTL JIT):
> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Compiler.h#L73
>
> The existance of a buildbot doesn't mean any obligation for anybody.
> We have many bots which are allowed to break. Everybody is allowed
> to break the Apple Mac cmake build, WebKit2 owners can break EFL/GTK
> builds, JSC developers can break ARM Linux builds.


I also would like to note that existence of MIPS bot does not oblige JSC 
developers who don't work on MIPS to keep it green, e.g. by implementing 
missing MacroAssembler functions. However, having such bot might be useful in 
case of refactorings which involve moving MIPS code around, which already 
happened in the past.

>
> br,
> Ossy
>
> Filip Pizlo írta:
>>  I don't want a buildbot for MIPS. It's not a relevant architecture anymore. 
>> I don't think that JSC developers should have to expend effort towards 
>> keeping this architecture working.
>>
>>  -Filip
>>
>>>  On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:
>>>
>>>  Hello,
>>>
>>>  I'd like to run build slave for MIPS port of JSC (with JSCOnly port on 
>>> Linux). On the first iteration it will just ensure that compilation is not 
>>> broken, afterwards I'm planning to add running tests on target.
>>>
>>>  However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, 
>>> the latest one supplied by Broadcom), and unmodified tree won't build 
>>> because of GCC version check in Source/WTF/wtf/Compiler.h.
>>>
>>>  Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>>> errors myself.
>>>
>>>  --
>>>  Regards,
>>>  Konstantin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Carlos Alberto Lopez Perez]

On 18/04/16 21:50, Filip Pizlo wrote:
> I don't want a buildbot for MIPS. It's not a relevant architecture
> anymore. I don't think that JSC developers should have to expend
> effort towards keeping this architecture working.
> 

MIPS is still relevant on embedded devices (mainly set-top boxes).
It is also a popular platform for IoT projects.

I understand that you don't want to spend time supporting this
architecture, and that is ok. Nobody is proposing here that JSC
developers should spend time maintaining JSC on MIPS.

However, if someone is willing to do the work, I think we should let
them do it and don't actively block it.

Having a buildbot testing JSC on MIPS certainly helps anyone interested
in maintaining this architecture.

And anybody not interested in MIPS, can just ignore this bot.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS [WARNING - NOT VIRUS SCANNED]

[Osztrogonác Csaba]

Hi,

now the #error macro in Compiler.h is the only one blocker to
be able to build JSCOnly port with GCC 4.8 (without FTL JIT):
http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Compiler.h#L73

The existance of a buildbot doesn't mean any obligation for anybody.
We have many bots which are allowed to break. Everybody is allowed
to break the Apple Mac cmake build, WebKit2 owners can break EFL/GTK
builds, JSC developers can break ARM Linux builds.

br,
Ossy

Filip Pizlo írta:

I don't want a buildbot for MIPS. It's not a relevant architecture anymore. I 
don't think that JSC developers should have to expend effort towards keeping 
this architecture working.

-Filip


On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:

Hello,

I'd like to run build slave for MIPS port of JSC (with JSCOnly port on Linux). 
On the first iteration it will just ensure that compilation is not broken, 
afterwards I'm planning to add running tests on target.

However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, the 
latest one supplied by Broadcom), and unmodified tree won't build because of 
GCC version check in Source/WTF/wtf/Compiler.h.

Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 (only 
for JavaScriptCore without B3)? I'm going to fix arising compilation errors 
myself.

--
Regards,
Konstantin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizlo]

> On Apr 18, 2016, at 4:43 PM, Michael Catanzaro  wrote:
> 
> On Mon, 2016-04-18 at 15:01 -0700, Geoffrey Garen wrote:
>> GCC 4.8 is three years old.
> 
> Yeah, unfortunately no Linux distros are ever willing to do major
> compiler upgrades, even Fedora is only willing to take minor compiler
> upgrades, so our willingness to support old compilers is proportional
> to the size of our user base eligible for updates. :/

I am sympathetic to the principle that we should support the compilers that 
ship on the most popular versions of Linux.  I’d like to understand if that 
argument is sufficient to support GCC 4.8.

Can you clarify, is it the case that if I installed the latest stable Fedora, 
I’d get GCC 4.8?

> 
> I understand resistance to restoring support for a compiler we
> previously decided to drop, so let me tone down my request: I just ask
> that when we decide to drop support for a compiler, we consider which
> major distros actually shipping our updates still use that compiler, so
> we can get a feel for how many users will stop getting WebKit updates
> as a consequence. We've just recently gotten to the point where a few
> distros are beginning to take our updates, and I'm really hoping to
> facilitate this by maintaining support for the compilers these distros
> are using as long as possible.
> 
> It's really annoying to be stuck catering to older compilers, but I
> don't see any good solution to this without throwing users under the
> bus. :(

I’m sympathetic to this.

> 
>> I don’t think we should put a three year hold on all current and
>> future C++ language features.
>> 
>> Vendors that want to ship security updates to old, stable OS’s should
>> maintain a branch that cherry-picks fixes from trunk and applies
>> build fixes as necessary, rather than holding back development in
>> trunk.
> 
> I'm not aware of any distributor that has ever attempted to seriously
> backport security fixes; not even enterprise distros like RHEL do this.
> Reality is that distros only ship what we release upstream.

Can you clarify what you mean by “backport”?  I’m trying to get a picture of 
how your releases work.  For example, are you saying that RHEL wouldn’t take a 
security update that you backported, or that they won’t invest energy into 
backporting it themselves?

> 
>>> It's unfortunate as of course we want to be able to use new
>> language
>>> features, but we need to balance this with the desire to ensure our
>>> updates reach users.
>> 
>> I don’t think that shipping trunk as a security update on very old
>> platforms is a viable strategy.
> 
> Nobody ships trunk, they ship our stable releases, which branch off of
> trunk every six months. We don't have the resources to maintain
> compiler support outside of trunk.

How many changes are required to make GCC 4.8 work?  I think this will provide 
important context for this discussion.

-Filip


> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizlo]

Yeah.  If we allow GCC 4.8 then I think we should make all of our code compile 
with it.  If that proves too difficult (like if we had to get rid of all 
lambdas), then I think we need to not allow GCC 4.8.

-Filip


> On Apr 18, 2016, at 12:54 PM, Anders Carlsson  wrote:
> 
> I also don’t think we should require different versions of GCC for different 
> projects. 
> 
> - Anders
> 
>> On Apr 18, 2016, at 12:50 PM, Filip Pizlo  wrote:
>> 
>> I don't want a buildbot for MIPS. It's not a relevant architecture anymore. 
>> I don't think that JSC developers should have to expend effort towards 
>> keeping this architecture working.
>> 
>> -Filip
>> 
>>> On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:
>>> 
>>> Hello,
>>> 
>>> I'd like to run build slave for MIPS port of JSC (with JSCOnly port on 
>>> Linux). On the first iteration it will just ensure that compilation is not 
>>> broken, afterwards I'm planning to add running tests on target.
>>> 
>>> However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, 
>>> the latest one supplied by Broadcom), and unmodified tree won't build 
>>> because of GCC version check in Source/WTF/wtf/Compiler.h.
>>> 
>>> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>>> errors myself.
>>> 
>>> -- 
>>> Regards,
>>> Konstantin
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

On Mon, 2016-04-18 at 15:01 -0700, Geoffrey Garen wrote:
> GCC 4.8 is three years old.

Yeah, unfortunately no Linux distros are ever willing to do major
compiler upgrades, even Fedora is only willing to take minor compiler
upgrades, so our willingness to support old compilers is proportional
to the size of our user base eligible for updates. :/

I understand resistance to restoring support for a compiler we
previously decided to drop, so let me tone down my request: I just ask
that when we decide to drop support for a compiler, we consider which
major distros actually shipping our updates still use that compiler, so
we can get a feel for how many users will stop getting WebKit updates
as a consequence. We've just recently gotten to the point where a few
distros are beginning to take our updates, and I'm really hoping to
facilitate this by maintaining support for the compilers these distros
are using as long as possible.

It's really annoying to be stuck catering to older compilers, but I
don't see any good solution to this without throwing users under the
bus. :(

> I don’t think we should put a three year hold on all current and
> future C++ language features.
> 
> Vendors that want to ship security updates to old, stable OS’s should
> maintain a branch that cherry-picks fixes from trunk and applies
> build fixes as necessary, rather than holding back development in
> trunk.

I'm not aware of any distributor that has ever attempted to seriously
backport security fixes; not even enterprise distros like RHEL do this.
Reality is that distros only ship what we release upstream.

> > It's unfortunate as of course we want to be able to use new
> language
> > features, but we need to balance this with the desire to ensure our
> > updates reach users.
> 
> I don’t think that shipping trunk as a security update on very old
> platforms is a viable strategy.

Nobody ships trunk, they ship our stable releases, which branch off of
trunk every six months. We don't have the resources to maintain
compiler support outside of trunk.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Geoffrey Garen]

> On Apr 18, 2016, at 2:08 PM, Michael Catanzaro  wrote:
> 
> On Mon, 2016-04-18 at 22:36 +0300, Konstantin Tokarev wrote:
>> Are there any objections for lowering GCC requirement from 4.9.0 to
>> 4.8.4 (only for JavaScriptCore without B3)? I'm going to fix arising
>> compilation errors myself.
> 
> I've been kinda hoping to do this regardless, since you started
> contributing GCC 4.8 buildfixes. GCC 4.8 is still being used by a
> prominent distributor that's recently started releasing occasional
> WebKit updates. I worked on downstream patches to remove the GCC 4.9
> requirement so that their users can get WebKit updates. Since
> increasing our GCC requirement past the GCC version included in a
> distribution just guarantees users will never receive WebKit security
> updates, we need to recognize that we moved too quickly in increasing
> our requirement to GCC 4.9. (At the time I thought this was OK, but I
> was wrong.) We'll need to be more careful in the future when bumping
> our GCC requirement, lest we leave a large segment of users stuck on
> ancient versions of WebKit.

GCC 4.8 is three years old.

I don’t think we should put a three year hold on all current and future C++ 
language features.

Vendors that want to ship security updates to old, stable OS’s should maintain 
a branch that cherry-picks fixes from trunk and applies build fixes as 
necessary, rather than holding back development in trunk.

> It's unfortunate as of course we want to be able to use new language
> features, but we need to balance this with the desire to ensure our
> updates reach users.

I don’t think that shipping trunk as a security update on very old platforms is 
a viable strategy.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

18.04.2016, 22:56, "Geoffrey Garen" :
>>>   Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>>> errors myself.
>
>  Yes.
>
>  We want to move forward in C++ language support, not backward.
>
>  Any platform not worthy of native compiler development is, a fortiori, also 
> not worthy of JSC compiler development.


MIPS can be targeted with current versions of GCC, including GCC 6.1. However, 
product I'm working on currently uses vendor-provided toolchain, so it would be 
easier for me to set up testing environment with this particular toolchain.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

On Mon, 2016-04-18 at 22:36 +0300, Konstantin Tokarev wrote:
> Are there any objections for lowering GCC requirement from 4.9.0 to
> 4.8.4 (only for JavaScriptCore without B3)? I'm going to fix arising
> compilation errors myself.

I've been kinda hoping to do this regardless, since you started
contributing GCC 4.8 buildfixes. GCC 4.8 is still being used by a
prominent distributor that's recently started releasing occasional
WebKit updates. I worked on downstream patches to remove the GCC 4.9
requirement so that their users can get WebKit updates. Since
increasing our GCC requirement past the GCC version included in a
distribution just guarantees users will never receive WebKit security
updates, we need to recognize that we moved too quickly in increasing
our requirement to GCC 4.9. (At the time I thought this was OK, but I
was wrong.) We'll need to be more careful in the future when bumping
our GCC requirement, lest we leave a large segment of users stuck on
ancient versions of WebKit.

It's unfortunate as of course we want to be able to use new language
features, but we need to balance this with the desire to ensure our
updates reach users.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Geoffrey Garen]

>> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>> errors myself.

Yes.

We want to move forward in C++ language support, not backward.

Any platform not worthy of native compiler development is, a fortiori, also not 
worthy of JSC compiler development.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

I also don’t think we should require different versions of GCC for different 
projects. 

- Anders

> On Apr 18, 2016, at 12:50 PM, Filip Pizlo  wrote:
> 
> I don't want a buildbot for MIPS. It's not a relevant architecture anymore. I 
> don't think that JSC developers should have to expend effort towards keeping 
> this architecture working.
> 
> -Filip
> 
>> On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:
>> 
>> Hello,
>> 
>> I'd like to run build slave for MIPS port of JSC (with JSCOnly port on 
>> Linux). On the first iteration it will just ensure that compilation is not 
>> broken, afterwards I'm planning to add running tests on target.
>> 
>> However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, 
>> the latest one supplied by Broadcom), and unmodified tree won't build 
>> because of GCC version check in Source/WTF/wtf/Compiler.h.
>> 
>> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>> errors myself.
>> 
>> -- 
>> Regards,
>> Konstantin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Filip Pizlo]

I don't want a buildbot for MIPS. It's not a relevant architecture anymore. I 
don't think that JSC developers should have to expend effort towards keeping 
this architecture working.

-Filip

> On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> I'd like to run build slave for MIPS port of JSC (with JSCOnly port on 
> Linux). On the first iteration it will just ensure that compilation is not 
> broken, afterwards I'm planning to add running tests on target.
> 
> However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, the 
> latest one supplied by Broadcom), and unmodified tree won't build because of 
> GCC version check in Source/WTF/wtf/Compiler.h.
> 
> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
> errors myself.
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Build slave for JSCOnly Linux MIPS

[Konstantin Tokarev]

Hello,

I'd like to run build slave for MIPS port of JSC (with JSCOnly port on Linux). 
On the first iteration it will just ensure that compilation is not broken, 
afterwards I'm planning to add running tests on target.

However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, the 
latest one supplied by Broadcom), and unmodified tree won't build because of 
GCC version check in Source/WTF/wtf/Compiler.h.

Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 (only 
for JavaScriptCore without B3)? I'm going to fix arising compilation errors 
myself.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev