<div dir="ltr"><div dir="ltr"><div dir="ltr">Hello Krzysztof,<div><br></div><div>The bot description comes from your bot, that's what in the info/host file.</div><div></div><div>Please update the description of those bots to avoid any confusions.<br><br>Thanks</div><div><br></div><div>Galina</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 31, 2019 at 6:27 AM Krzysztof Parzyszek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The hexagon bots use either clang 6 or clang 3.7 (depending on the <br>
builder). Both of these compilers are installed in non-standard <br>
locations and are not system compilers. I think this is the reason why <br>
the bot page shows gcc, but gcc is not used for building clang.<br>
<br>
-Krzysztof<br>
<br>
On 1/29/2019 3:05 PM, JF Bastien via llvm-dev wrote:<br>
> The patch is about ready to land, which means any older compiler will <br>
> soft-error (which you can turn off with <br>
> LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then <br>
> cherry-pick the patch to the LLVM 8 branch.<br>
> <br>
> The last remaining issue are the buildbots. I audited *all* bots in <br>
> <a href="http://lab.llvm.org:8011/buildslaves" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/buildslaves</a> (there's so many!). Some of them <br>
> are down, I therefore have no idea what they run. Here are the bots that <br>
> will definitely break, with their maintainers:<br>
> <br>
> Galina Kistanova <<a href="mailto:gkistanova@gmail.com" target="_blank">gkistanova@gmail.com</a> <mailto:<a href="mailto:gkistanova@gmail.com" target="_blank">gkistanova@gmail.com</a>>><br>
> am1i-slv1 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4<br>
> as-bldslv4 -- Microsoft (R) Visual Studio (R) 2015 (14.0)<br>
> ps4-buildslave2 -- Microsoft (R) Visual Studio (R) 2015 (14.0)<br>
> <br>
> Hexagon QA <<a href="mailto:llvm.buildmaster@quicinc.com" target="_blank">llvm.buildmaster@quicinc.com</a><br>
> <mailto:<a href="mailto:llvm.buildmaster@quicinc.com" target="_blank">llvm.buildmaster@quicinc.com</a>>><br>
> hexagon-build-02 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2<br>
> hexagon-build-03 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2<br>
> <br>
> Vitaly Buka <<a href="mailto:vitalybuka@google.com" target="_blank">vitalybuka@google.com</a> <mailto:<a href="mailto:vitalybuka@google.com" target="_blank">vitalybuka@google.com</a>>><br>
> sanitizer-buildbot6 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4<br>
> <br>
> Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a> <mailto:<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>>><br>
> sanitizer-windows -- Microsoft (R) Visual Studio (R) 2015 (14.0)<br>
> <br>
> Ilia Taraban <<a href="mailto:mstester.llvm@gmail.com" target="_blank">mstester.llvm@gmail.com</a> <mailto:<a href="mailto:mstester.llvm@gmail.com" target="_blank">mstester.llvm@gmail.com</a>>><br>
> windows7-buildbot -- Microsoft (R) Visual Studio (R) 2015 (14.0)<br>
> <br>
> <br>
> The maintainers have 3 options:<br>
> <br>
> 1. Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bot, suffer <br>
> breakage later.<br>
> 2. Update the bot to a newer compiler version.<br>
> 3. Entirely turn down the bot.<br>
> <br>
> I’ve emailed the maintainers and some have already responded. Once all <br>
> bots are in a good state I’ll commit the patch (unless someone else <br>
> chimes in with new information).<br>
> <br>
> <br>
>> On Jan 25, 2019, at 5:47 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a> <br>
>> <mailto:<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>> wrote:<br>
>><br>
>> +1, thanks again for driving this.<br>
>><br>
>> On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev <br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
>><br>
>> The discussion seems to have died down and gotten good consensus.<br>
>> I’ve therefore create a patch which applies the proposed soft-errors:<br>
>><br>
>> <a href="https://reviews.llvm.org/D57264" rel="noreferrer" target="_blank">https://reviews.llvm.org/D57264</a><br>
>><br>
>><br>
>> We’ll only migrate to hard-error (and start using new features)<br>
>> when we get consensus to do so, at the earliest end of March 2019.<br>
>> The patch will allow us to start warning developers, especially<br>
>> those who only compile branches (in this case, LLVM 8).<br>
>><br>
>><br>
>>> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev<br>
>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
>>><br>
>>> Hello fans of the auto keyword!<br>
>>><br>
>>> We now have a policy on how LLVM toolchains get updated<br>
>>> <<a href="https://reviews.llvm.org/rL351765" rel="noreferrer" target="_blank">https://reviews.llvm.org/rL351765</a>>! Let’s put that policy to<br>
>>> good use, and talk about how we’ll move all monorepo projects<br>
>>> past C++11.<br>
>>><br>
>>><br>
>>> *Previous Discussions*<br>
>>><br>
>>> * LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!<br>
>>> <<a href="http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3" rel="noreferrer" target="_blank">http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3</a>>"<br>
>>> * A Short Policy Proposal Regarding Host Compilers<br>
>>> <<a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html</a>><br>
>>> * Using C++14 code in LLVM (2018)<br>
>>> <<a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html</a>><br>
>>> * Using C++14 code in LLVM (2017)<br>
>>> <<a href="http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html</a>><br>
>>> * Using C++14 code in LLVM (2016)<br>
>>> <<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html</a>><br>
>>> * Document and Enforce new Host Compiler Policy<br>
>>> <<a href="http://llvm.org/D47073" rel="noreferrer" target="_blank">http://llvm.org/D47073</a>><br>
>>> * Require GCC 5.1 and LLVM 3.5 at a minimum<br>
>>> <<a href="http://llvm.org/D46723" rel="noreferrer" target="_blank">http://llvm.org/D46723</a>><br>
>>><br>
>>> *<br>
>>> *<br>
>>> *Migrate to what?*<br>
>>><br>
>>> I’m only proposing that we migrate to C++14 for now. If you want<br>
>>> to propose C++17, please do the work required by the policy. In<br>
>>> particular, document which toolchains this would require, and<br>
>>> what features you’d unlock. As per policy, I want to start<br>
>>> soft-errors when building LLVM 8, so that LLVM 9 can use more<br>
>>> than C++11.<br>
>>><br>
>>><br>
>>> *Timeline*<br>
>>><br>
>>> At the LLVM dev meeting BoF, the room already agreed to move past<br>
>>> C++11. Late March 2019 was proposed as a time when we’d start<br>
>>> migrating, pending large contributors’ readiness. I’m sticking to<br>
>>> that timeline, we’ll see if everyone is ready at the end of<br>
>>> March. I nonetheless want to get the soft-errors into the LLVM 8<br>
>>> branch so that we give a sufficient heads-up to developers who<br>
>>> only compile releases.<br>
>>><br>
>>><br>
>>> *Upsides*<br>
>>><br>
>>> One clear upside of dropping older toolchains: they don’t even<br>
>>> support C++11 very well. We have a handful of workarounds left in<br>
>>> ADT (particularly around type traits) and I’d like to get rid of<br>
>>> them.<br>
>>><br>
>>> The compiler versions I propose allow us to use all of C++14,<br>
>>> which includes:<br>
>>><br>
>>> * Binary literals<br>
>>> <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf</a>><br>
>>> * decltype(auto), Return type deduction for normal functions<br>
>>> <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html</a>><br>
>>> * Initialized/Generalized lambda captures (init-capture)<br>
>>> <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html</a>><br>
>>> * Generic (polymorphic) lambda expressions<br>
>>> <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html</a>><br>
>>> * Variable templates<br>
>>> <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf</a>><br>
>>> * Member initializers and aggregates (NSDMI)<br>
>>> <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html</a>><br>
>>> * A bunch of new constexpr language and library features<br>
>>> * Various other language and library features<br>
>>><br>
>>> See CppReference<br>
>>> <<a href="https://en.cppreference.com/w/cpp/compiler_support" rel="noreferrer" target="_blank">https://en.cppreference.com/w/cpp/compiler_support</a>> for details.<br>
>>><br>
>>> Of these, I think polymorphic lambdas are the big feature. Of<br>
>>> course, just like Almost Always Auto, we should use such things<br>
>>> only where it makes sense.<br>
>>><br>
>>><br>
>>> *Toolchains*<br>
>>><br>
>>> We’re currently mandating:<br>
>>><br>
>>> * Clang 3.1 (/released 2012/05/)<br>
>>> * Apple Clang 3.1 (/released 2012/05/)<br>
>>> * GCC 4.8 (/released 2013/03/)<br>
>>> * Visual Studio 2015 (Update 3) (/released 2016/06/)<br>
>>><br>
>>> I propose instead:<br>
>>><br>
>>> * Clang 3.5 (/released 2014/07/) to get -std=c++14 instead of<br>
>>> -std=c++1y<br>
>>> * Apple Clang 6.0 (/released 2014/07/) to match clang 3.5<br>
>>> * GCC 5.1 (/released 2015/04/) because C++14 mostly came to be<br>
>>> in GCC 5<br>
>>> * Visual Studio 2017 (/released 2017/03/) so that we get<br>
>>> extended constexpr and NSDMI<br>
>>><br>
>>> Version information from:<br>
>>><br>
>>> * Clang <a href="http://releases.llvm.org" rel="noreferrer" target="_blank">http://releases.llvm.org</a> <<a href="http://releases.llvm.org/" rel="noreferrer" target="_blank">http://releases.llvm.org/</a>><br>
>>> * Apple clang<br>
>>> <a href="https://trac.macports.org/wiki/XcodeVersionInfo" rel="noreferrer" target="_blank">https://trac.macports.org/wiki/XcodeVersionInfo</a> and<br>
>>> <a href="https://en.wikipedia.org/wiki/Xcode#Latest_versions" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xcode#Latest_versions</a><br>
>>> * GCC <a href="https://gcc.gnu.org/releases.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/releases.html</a><br>
>>> * MSVC<br>
>>> <a href="https://en.wikipedia.org/wiki/Microsoft_Visual_Studio" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Microsoft_Visual_Studio</a> and<br>
>>> <a href="https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance</a><br>
>>><br>
>>><br>
>>> My previous attempts pointed out that WebKit / Chromium / Firefox<br>
>>> are all past C++11 (WebKit is moving to C++17<br>
>>> <<a href="https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html" rel="noreferrer" target="_blank">https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html</a>> (from<br>
>>> C++14), Chromium started moving to C++14<br>
>>> <<a href="https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ" rel="noreferrer" target="_blank">https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ</a>>,<br>
>>> Firefox uses some C++14<br>
>>> <<a href="https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code</a>>).<br>
>>> This means that platforms which distribute a modern browser can<br>
>>> already bootstrap a browser. That’s a nice datapoint, but isn’t<br>
>>> sufficient for platforms which compile / use LLVM (especially as<br>
>>> a library).<br>
>>><br>
>>> Here’s a table from the LLVM dev meeting BoF detailing version<br>
>>> info for distros that seemed relevant:<br>
>>><br>
>>> *Release*<br>
>>> <br>
>>> *Distro*<br>
>>> <br>
>>> *Compiler*<br>
>>> <br>
>>> *C++14 lang*<br>
>>> *2003-10*<br>
>>> <br>
>>> RHEL 3<br>
>>> <br>
>>> GCC 3.2<br>
>>> <br>
>>> ❌<br>
>>> *2005-02*<br>
>>> <br>
>>> RHEL 4<br>
>>> <br>
>>> GCC 3.4<br>
>>> <br>
>>> ❌<br>
>>> *2007-03*<br>
>>> <br>
>>> RHEL 5<br>
>>> <br>
>>> GCC 4.1<br>
>>> <br>
>>> ❌<br>
>>> *2010-11*<br>
>>> <br>
>>> RHEL 6<br>
>>> <br>
>>> GCC 4.4<br>
>>> <br>
>>> ❌<br>
>>> *2013-05*<br>
>>> <br>
>>> Debian 7 wheezy<br>
>>> <br>
>>> GCC 4.7.2<br>
>>> <br>
>>> ❌<br>
>>> *2013-12*<br>
>>> <br>
>>> RHEL 7<br>
>>> <br>
>>> GCC 4.8<br>
>>> <br>
>>> ❌<br>
>>> *2015-04*<br>
>>> <br>
>>> Debian 8 jessie<br>
>>> <br>
>>> GCC 4.9.2<br>
>>> <br>
>>> ❌<br>
>>> *2015-05*<br>
>>> <br>
>>> OpenBSD 5.7<br>
>>> <br>
>>> LLVM 3.5<br>
>>> <br>
>>> ✅<br>
>>> *2015-10*<br>
>>> <br>
>>> OpenBSD 5.8<br>
>>> <br>
>>> LLVM 3.5<br>
>>> <br>
>>> ✅<br>
>>> *2016-03*<br>
>>> <br>
>>> OpenBSD 5.9<br>
>>> <br>
>>> LLVM 3.5<br>
>>> <br>
>>> ✅<br>
>>> *2016-04*<br>
>>> <br>
>>> Ubuntu 14.04<br>
>>> <br>
>>> GCC 4.8.2<br>
>>> <br>
>>> ❌<br>
>>> *2016-04*<br>
>>> <br>
>>> Ubuntu 16.04<br>
>>> <br>
>>> GCC 5.3.1<br>
>>> <br>
>>> ✅<br>
>>> *2016-09*<br>
>>> <br>
>>> OpenBSD 6.0<br>
>>> <br>
>>> LLVM 3.8<br>
>>> <br>
>>> ✅<br>
>>> *2017-04*<br>
>>> <br>
>>> OpenBSD 6.1<br>
>>> <br>
>>> LLVM 4.0.0<br>
>>> <br>
>>> ✅<br>
>>> *2017-06*<br>
>>> <br>
>>> Debian 9 stretch<br>
>>> <br>
>>> GCC 6.3.0<br>
>>> <br>
>>> ✅<br>
>>> *2017-10*<br>
>>> <br>
>>> Ubuntu 17.10<br>
>>> <br>
>>> GCC 7.2.0<br>
>>> <br>
>>> ✅<br>
>>> *2017-10*<br>
>>> <br>
>>> OpenBSD 6.2<br>
>>> <br>
>>> LLVM 5.0.0<br>
>>> <br>
>>> ✅<br>
>>> *2018-04*<br>
>>> <br>
>>> Ubuntu 18.04<br>
>>> <br>
>>> GCC 7.3.0<br>
>>> <br>
>>> ✅<br>
>>> *2018-04*<br>
>>> <br>
>>> OpenBSD 6.3<br>
>>> <br>
>>> LLVM 5.0.1<br>
>>> <br>
>>> ✅<br>
>>> *2018-10*<br>
>>> <br>
>>> Ubuntu 18.10<br>
>>> <br>
>>> GCC 8.1.0<br>
>>> <br>
>>> ✅<br>
>>> *2018-??*<br>
>>> <br>
>>> Debian 10 buster<br>
>>> <br>
>>> GCC 8.1.0<br>
>>> <br>
>>> ✅<br>
>>><br>
>>><br>
>>> The data comes from the following sources:<br>
>>><br>
>>> * <a href="https://en.cppreference.com/w/cpp/compiler_support" rel="noreferrer" target="_blank">https://en.cppreference.com/w/cpp/compiler_support</a><br>
>>> * <a href="https://packages.ubuntu.com/search?keywords=gcc" rel="noreferrer" target="_blank">https://packages.ubuntu.com/search?keywords=gcc</a><br>
>>> * <a href="https://packages.debian.org/search?keywords=gcc" rel="noreferrer" target="_blank">https://packages.debian.org/search?keywords=gcc</a><br>
>>> * <a href="https://access.redhat.com/solutions/19458" rel="noreferrer" target="_blank">https://access.redhat.com/solutions/19458</a><br>
>>> * <a href="https://www.openbsd.org/63.html" rel="noreferrer" target="_blank">https://www.openbsd.org/63.html</a><br>
>>> * <a href="https://en.wikipedia.org/wiki/Clang" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Clang</a><br>
>>> * <a href="https://releases.llvm.org" rel="noreferrer" target="_blank">https://releases.llvm.org</a> <<a href="https://releases.llvm.org/" rel="noreferrer" target="_blank">https://releases.llvm.org/</a>><br>
>>><br>
>>> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC,<br>
>>> and nobody complained at the BoF. I’d like to understand if we<br>
>>> should care about documenting these: ideally the toolchain update<br>
>>> policy would list which platforms need to be considered and how<br>
>>> far back in time is relevant.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> JF<br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
> <br>
> <br>
> <<a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" rel="noreferrer" target="_blank">http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient</a>> <br>
> Virus-free. <a href="http://www.avg.com" rel="noreferrer" target="_blank">www.avg.com</a> <br>
> <<a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" rel="noreferrer" target="_blank">http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient</a>> <br>
> <br>
> <br>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2><br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</div>