Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

[Xan]

Hi,

Sorry about that. We'll take care of it ASAP.

Cheers,
Xan

On Thu, Jun 27, 2019, 06:23 Fujii Hironori  wrote:

> jsc-i368 EWS is still failing.
> Who is igalia-jsc-i386-ews bot maintainer?
>
> On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori 
> wrote:
>
>> Hi,
>>
>> I'm going to bump cmake_minimum_required version to 3.10 for
>> shining new features.
>>
>> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
>> https://bugs.webkit.org/show_bug.cgi?id=199181
>>
>>
>> GTK and WPE's EWS and BuildBot bots maintainers, could you please
>> update your CMake on your bots?
>>
>> If you are using CMake Visual Studio generator, you need CMake
>> 3.12 or newer to avoid an unnecessary recompilation issue.
>>
>> AppleWin port seems still using old Visual Studio 2017. If it
>> will switch to Visual Studio 2019 for better C++17 support,
>> Visual Studio 2019 needs CMake 3.14 or newer.
>> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>>
>> Happy WebKit 18th
>> birthday
>> 🎂
>>
>> -- Fujii
>>
> ___
> 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] [CMake] Bump cmake_minimum_required version to 3.10

[Fujii Hironori]

jsc-i368 EWS is still failing.
Who is igalia-jsc-i386-ews bot maintainer?

On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori 
wrote:

> Hi,
>
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
>
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181
>
>
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
>
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
>
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>
> Happy WebKit 18th
> birthday
> 🎂
>
> -- Fujii
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows 32-bit support?

[Arunprasad Rajkumar]

Hi Yusuke,

I could see that the following comment from
https://trac.webkit.org/changeset/245906/webkit,

>> We also disable this op_wide16 feature in Windows CLoop, which is used
in AppleWin port. When the code size of
>> CLoop::execute increases, MSVC starts generating CLoop::execute function
with very large stack allocation
>> requirement. Even before introducing this 16bit bytecode, CLoop::execute
in AppleWin takes almost 100KB stack
>> height. After introducing this, it becomes 160KB. While the semantics of
the function is correctly compiled,
>> such a large stack allocation is not essentially necessary, and this
leads to stack overflow errors quite easily,
>> and tests fail with AppleWin port because it starts throwing stack
overflow range error in various places.
>> In this patch, for now, we just disable op_wide16 feature for AppleWin
so that CLoop::execute takes 100KB
>> stack allocation because this patch is not focusing on fixing AppleWin's
CLoop issue. We introduce a new backend
>> type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16
version of code to reduce the code size of
>> CLoop::execute. In the future, we should investigate whether this MSVC
issue is fixed in Visual Studio 2019.
>> Or we should consider always enabling ASM LLInt for Windows.

Does that mean high stack usage in Windows is a known issue?

Thanks & Regards,
Arun

On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar 
wrote:

> Thank you all for your guidance.
>
> I understand that JIT and LLInt bytecode interpreter is not supported on
> X86(32-bit). The only option I can use is C_LOOP, which have high stack
> usage issue in the latest code. I will continue with my investigation on
> C_LOOP's stack usage.
>
> Thanks & Regards,
> Arun
>
>
> On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki  wrote:
>
>>
>>
>> On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro 
>> wrote:
>>
>> I was mistaken about one thing (sorry!), please read below...
>>
>> On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro <
>> ape...@igalia.com> wrote:
>>
>> On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <
>> mcatanz...@igalia.com> wrote:
>>
>> It's great that you find our stable branches helpful, but keep in mind
>> those branches do not include Windows-specific fixes.
>>
>> On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar
>>  wrote:
>>
>> Right. Actually the problem is in 32-bit Windows platform. I see that
>> the JIT support has been dropped some time ago, and CLOOP based
>> backend seems to be unstable on 32-bit Windows. Any thoughts on that?
>>
>>
>> So I'm not an expert here, but I understand there are three ways you
>> can build JSC:
>>
>> (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
>> (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
>> (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
>>
>> (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
>>
>> I believe that nowadays the only 32-bit platforms supported by JIT are
>> Linux, and there only for ARM and MIPS, not x86. So you're almost
>> certainly going to need to use -DENABLE_JIT=OFF. That eliminates option
>> (1).
>>
>>
>> JIT works on x86 as long as your CPU has support for SSE2 instructions.
>>
>>
>> Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the
>> moment.
>>
>> (The JIT compiler does emit SSE2 instructions, though. When/If the JIT is
>> made to work on 32-bit x86, support for SSE2 will be needed.)
>>
>>
>> WebKit no longer supports non-SSE2 x86 CPUs even without JIT.
>> https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html
>>
>> And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin)
>> is recommended.
>>
>> -Yusuke
>>
>>
>> You say the cloop seems unstable for you, which is option (3). So
>> perhaps you should try option (2) if you haven't already. I'm not
>> actually sure if that works, because I'm not an expert, which is why I
>> added that (?) to it. But at least it couldn't hurt to try.
>>
>>
>> Option (2) would be using the LLint bytecode interpreter, without JIT.
>>
>> In principle CLoop is expected to work “everywhere” because the
>> interpreter
>> is generated C/C++ code, which gets then built by the same compiler used
>> to
>> build all the rest of WebKit.
>>
>> Maybe the Windows port maintainers know more about the status of 32-bit
>> Windows support?
>>
>>
>> Cheers,
>> —Adrián
>>
>> ___
>> 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] C++17 is here. Should we use it?

[Guillaume Emont]

Quoting Guillaume Emont (2019-06-24 19:03:53)
> Quoting Sam Weinig (2019-06-17 03:25:15)
> > Did we ever land on conclusion here? 
> > 
> > I tried to use c++17 structured bindings (see 
> > https://bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of 
> > the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not 
> > into it.  Looking at the output, it seems like those bots may still be 
> > using GCC 6.4.0 (but I could be wrong here).
> > 
> > If the issue is getting these bots updated, can we do that? Are there any 
> > other bots that might need updating as well?
> 
> The jsc-mips and jsc-armv7 EWS bots, as well as the corresponding
> buildbots have been updated. They now use gcc 8.3.0. The armv7 softfp
> ABI buildbot[1] still needs updating, but there is no corresponding EWS.
> I hope to have that last update done during the week.

The update of the last bot has now been done.
Also, forgot the address[1] of the bot in my previous email:

[1] 
https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20SoftFP%20Release

Cheers,

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