Update PNaCl to LLVM/Clang/Libcxx 223109 (nacl-change)

Update PNaCl to LLVM/Clang/Libcxx 223109 (nacl-change)

Update driver scripts to say 3.6 instead of 3.5.
Update llvm, clang, libcxx, and subzero.

Rebased localmods for clang: https://codereview.chromium.org/887223008/

Rebased localmods for libcxx:
https://codereview.chromium.org/904473004/

Stuff for llvm:
https://codereview.chromium.org/940243003/
https://codereview.chromium.org/939073008/

Changes for subzero:
https://codereview.chromium.org/897873004/

BUG= https://code.google.com/p/nativeclient/issues/detail?id=4026
R=jfb@chromium.org, kschimpf@google.com

Committed: https://chromium.googlesource.com/native_client/src/native_client/+/ab8a5c605e1502be0605783bfe477d1a3d315817

[Karl, 2015-02-20 16:30:42]

kschimpf@google.com changed reviewers:
+ kschimpf@google.com

[Karl, 2015-02-20 16:30:43]

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
File pnacl/driver/tests/path_length_test.py (right):

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
pnacl/driver/tests/path_length_test.py:36: # Create a directory whose path will
be exactly 235 chars long
Should there be a check to verify that the path isn't greater than 235?

[JF, 2015-02-23 21:50:41]

jfb@chromium.org changed reviewers:
+ jfb@chromium.org

[JF, 2015-02-23 21:50:43]

https://codereview.chromium.org/800553003/diff/260001/pnacl/driver/pnacl-ld.py
File pnacl/driver/pnacl-ld.py (left):

https://codereview.chromium.org/800553003/diff/260001/pnacl/driver/pnacl-ld.p...
pnacl/driver/pnacl-ld.py:40: 'OPT_LTO_FLAGS': '-std-link-opts
-disable-internalize',
Why isn't -disable-internalize necessary anymore? It came from:
  https://codereview.chromium.org/12843006

https://codereview.chromium.org/800553003/diff/260001/tools/toolchain_tester/...
File tools/toolchain_tester/known_failures_pnacl.txt (right):

https://codereview.chromium.org/800553003/diff/260001/tools/toolchain_tester/...
tools/toolchain_tester/known_failures_pnacl.txt:114: 20031003-1.c
What fails in the test?

[jvoung (off chromium), 2015-02-23 22:12:00]

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
File pnacl/driver/tests/path_length_test.py (right):

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
pnacl/driver/tests/path_length_test.py:36: # Create a directory whose path will
be exactly 235 chars long
On 2015/02/20 16:30:43, Karl wrote:
> Should there be a check to verify that the path isn't greater than 235?

Added an assert that it's exactly 235 (if that's what you meant).

I guess this really shouldn't have regressed:
https://code.google.com/p/nativeclient/issues/detail?id=4098

But I haven't had time to fully investigate the windows build (make -j1 !). I
know upstream has some changes to add support for extended path lengths which
may have affected this. On the other hand, spaces in paths were only fixed
recently, and longish files w/ spaces is supported (just 235 + x instead of 240
+ x)...

https://codereview.chromium.org/800553003/diff/260001/pnacl/driver/pnacl-ld.py
File pnacl/driver/pnacl-ld.py (left):

https://codereview.chromium.org/800553003/diff/260001/pnacl/driver/pnacl-ld.p...
pnacl/driver/pnacl-ld.py:40: 'OPT_LTO_FLAGS': '-std-link-opts
-disable-internalize',
On 2015/02/23 21:50:42, JF wrote:
> Why isn't -disable-internalize necessary anymore? It came from:
>   https://codereview.chromium.org/12843006


Well, the main thing is that -disable-internalize doesn't exist anymore:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229502.html

and the default is what Internalize=false used to do.

https://codereview.chromium.org/800553003/diff/260001/tools/toolchain_tester/...
File tools/toolchain_tester/known_failures_pnacl.txt (right):

https://codereview.chromium.org/800553003/diff/260001/tools/toolchain_tester/...
tools/toolchain_tester/known_failures_pnacl.txt:114: 20031003-1.c
On 2015/02/23 21:50:43, JF wrote:
> What fails in the test?

The test does:

int f1()
{
  return (int)2147483648.0f;
}

and expects f1() == 2147483647

I thought this was undefined behavior when the integral part of the float cannot
be represented by "int".

[Karl, 2015-02-23 22:18:18]

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
File pnacl/driver/tests/path_length_test.py (right):

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
pnacl/driver/tests/path_length_test.py:36: # Create a directory whose path will
be exactly 235 chars long
On 2015/02/23 22:12:00, jvoung wrote:
> On 2015/02/20 16:30:43, Karl wrote:
> > Should there be a check to verify that the path isn't greater than 235?
> 
> Added an assert that it's exactly 235 (if that's what you meant).
> 
> I guess this really shouldn't have regressed:
> https://code.google.com/p/nativeclient/issues/detail?id=4098
> 
> But I haven't had time to fully investigate the windows build (make -j1 !). I
> know upstream has some changes to add support for extended path lengths which
> may have affected this. On the other hand, spaces in paths were only fixed
> recently, and longish files w/ spaces is supported (just 235 + x instead of
240
> + x)...

Actually, what I meant (both here and with path test on 240 above), what happens
if cwd_len is greater than 235? In such cases, does the following instruction
make sense?

[JF, 2015-02-23 22:39:46]

lgtm

https://codereview.chromium.org/800553003/diff/260001/tools/toolchain_tester/...
File tools/toolchain_tester/known_failures_pnacl.txt (right):

https://codereview.chromium.org/800553003/diff/260001/tools/toolchain_tester/...
tools/toolchain_tester/known_failures_pnacl.txt:114: 20031003-1.c
On 2015/02/23 22:12:00, jvoung wrote:
> On 2015/02/23 21:50:43, JF wrote:
> > What fails in the test?
> 
> The test does:
> 
> int f1()
> {
>   return (int)2147483648.0f;
> }
> 
> and expects f1() == 2147483647
> 
> I thought this was undefined behavior when the integral part of the float
cannot
> be represented by "int".

Right, this is UB. Even with vanilla clang we get:

int f1()
{
  400530:	55                   	push   %rbp
  400531:	48 89 e5             	mov    %rsp,%rbp
  return (int)2147483648.0f;
  400534:	5d                   	pop    %rbp
  400535:	c3                   	retq   
  400536:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
  40053d:	00 00 00 

Compiling with -emit-after-all shows that clang generates the following IR:

define i32 @f1() #0 {
entry:
  ret i32 undef, !dbg !16
}

From the discussions on the GCC mailing list it sounds like some people fixed
the UB for their platform, but not in general... Meh.

[jvoung (off chromium), 2015-02-23 22:41:22]

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
File pnacl/driver/tests/path_length_test.py (right):

https://codereview.chromium.org/800553003/diff/220001/pnacl/driver/tests/path...
pnacl/driver/tests/path_length_test.py:36: # Create a directory whose path will
be exactly 235 chars long
On 2015/02/23 22:18:18, Karl wrote:
> On 2015/02/23 22:12:00, jvoung wrote:
> > On 2015/02/20 16:30:43, Karl wrote:
> > > Should there be a check to verify that the path isn't greater than 235?
> > 
> > Added an assert that it's exactly 235 (if that's what you meant).
> > 
> > I guess this really shouldn't have regressed:
> > https://code.google.com/p/nativeclient/issues/detail?id=4098
> > 
> > But I haven't had time to fully investigate the windows build (make -j1 !).
I
> > know upstream has some changes to add support for extended path lengths
which
> > may have affected this. On the other hand, spaces in paths were only fixed
> > recently, and longish files w/ spaces is supported (just 235 + x instead of
> 240
> > + x)...
> 
> Actually, what I meant (both here and with path test on 240 above), what
happens
> if cwd_len is greater than 235? In such cases, does the following instruction
> make sense?

I see, I added another check for cwd's len.

[Karl, 2015-02-23 22:43:32]

lgtm

[jvoung (off chromium), 2015-02-26 22:25:06]

Are we pretty much good to go (can add the instcombine patch too)? How should we
handle the COMPONENT_REVISIONS pointing at a branch vs master?

[jvoung (off chromium), 2015-02-27 18:48:54]

Committed patchset #22 (id:420001) manually as
ab8a5c605e1502be0605783bfe477d1a3d315817 (presubmit successful).