| Age | Commit message (Collapse) | Author |
|---|
|
|
|
For us, staying in sync with upstream on issues related to the memory model
is more important. None of clang, gcc, nor icc appear to offer these features.
If such features are desirable, they should ideally be implemented in upstream
clang, in a target-independent way, since this issue would affect users of all
platforms which support threads, not just PNaCl or Emscripten.
|
|
asmjs-unknown-emscripten.
|
|
|
|
|
|
into incoming
|
|
This is pretty minimal right now; eventually this may subsume code currently
in the emscripten wrapper scripts.
|
|
Notable changes from le32-unknown-nacl so far include:
- Set i32 as the legal integer set, to help the optimizer avoid creating
needlessly inefficient code for asm.js.
- We can use llvm.pow.
- Don't predefine __ELF__ or __pnacl__ so that we don't need to undefine
them later.
- Do predefine asm.js and Emscripten macros, so that we don't need to
define them later.
- Don't provide __has_feature(pnacl).
|
|
|
|
|
|
libcalls.
For integer types of sizes 1, 2, 4 and 8, libcompiler-rt (and libgcc)
provide atomic functions that pass parameters by value and return
results directly.
libgcc and libcompiler-rt only provide optimized libcalls for
__atomic_fetch_*, as generic libcalls on non-integer types would make
little sense. This means that we can finally make __atomic_fetch_* work
on architectures for which we don't provide these operations as builtins
(e.g. ARM).
This should fix the dreaded "cannot compile this atomic library call
yet" error that would pop up once every while.
These code generation issues are encountered because PNaCl doesn't
inline some of the atomic instructions, whereas other targets do. This
patch is just after the 3.3 branch and applies cleanly, but it doesn't
fix all issues: there is still at least one with atomic operations on
pointers which isn't as clean to fix as applying one patch, so I'll
leave that one as-is for now.
R=dschuff@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3623
TEST= ./pnacl/scripts/llvm-test.py --libcxx-tests
Review URL: https://codereview.chromium.org/59793007
|
|
add tests."
This is needed for libc++ testing with newlib.
R=dschuff@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3623
TEST= ./pnacl/scripts/llvm-test.py --libcxx-tests
Review URL: https://codereview.chromium.org/47573003
|
|
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/23484011
|
|
This is a companion patch to:
https://codereview.chromium.org/22240002/
https://codereview.chromium.org/22474008/
and deals with the Clang-side of things.
The above patch will handle the fallouts of this Clang patch, including
some changes to un-duplicate work that RewriteAsmDirectives.cpp
does. The goal of this patch is to force some extra ordering on
non-atomics for le32 which LLVM doesn't necessarily provide.
R=eliben@chromium.org
TEST= ninja check-all
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3611
Review URL: https://codereview.chromium.org/22294002
|
|
This is part of a bigger CL to fix C++11 in PNaCl, to commit in the following order:
- https://codereview.chromium.org/20552002
- https://codereview.chromium.org/20554002
- https://codereview.chromium.org/20560002
- https://codereview.chromium.org/20561002
This change is needed in Clang so that it can recognize the builtin and translate it to the intrinsic that 20554002 adds.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
TEST= ./scons run_synchronization_cpp11_test --verbose bitcode=1 platform=x86-64
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/20552002
|
|
signature.
__pnacl_profile_function_x takes a single argument - the name of the current function as a constant string, rather than a pair of function addresses like __cyg takes. This makes it work even in PNaCl and removes the need to track symbol information separately.
BUG=none
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/20000003
|
|
filtering. If omitted entirely, the original behavior is restored.
This also undos the string and __pnacl_profile stuff from the previous
CL. Finally, it fixes and updates the -finstrument-function tests.
BUG=none
R=bradnelson@google.com, dschuff@chromium.org
Review URL: https://codereview.chromium.org/19793007
|
|
Several people have been bitten recently by the strange git cl behavior
that silently fails to push changes if the local branch does not have
the correct upstream branch, so copy our llvm presubmit script that
checks for this. Also create an OWNERS file, because adding a presubmit
script also causes git cl to do an OWNERS check which fails if no
OWNERS file is present
R=jvoung@chromium.org
BUG=none
Review URL: https://codereview.chromium.org/20051011
|
|
Specifically:
r186564 - Fix volatile _Complex alignment test on platforms where 64-bit floating point isn't 64-bit aligned
r186490 - Propagate alignment for _Complex
These should fix GCC torture test failures, as well as the all-important uses of volatile _Complex numbers in C, and their alignment being incorrect.
BUG= PNaCl FYI bots red on torture tests
TEST= ./tools/toolchain_tester/torture_test.py pnacl x86-64 --concurrency=32 >& torture-x86-64.log ; ./tools/toolchain_tester/torture_test.py pnacl x86-32 --concurrency=32 >& torture-x86-32.log ; ./tools/toolchain_tester/torture_test.py pnacl arm --concurrency=32 >& torture-arm.log
R=stichnot@chromium.org
Review URL: https://codereview.chromium.org/19915003
|
|
|
|
Conflicts:
lib/CodeGen/ItaniumCXXABI.cpp
|
|
|
|
SVN log from upstream clang:
r185568 | eliben | 2013-07-03 12:19:12 -0700 (Wed, 03 Jul 2013)
Add target hook CodeGen queries when generating builtin pow*.
Without fmath-errno, Clang currently generates calls to @llvm.pow.* intrinsics
when it sees pow*(). This may not be suitable for all targets (for
example le32/PNaCl), so the attached patch adds a target hook that CodeGen
queries. The target can state its preference for having or not having the
intrinsic generated. Non-PNaCl behavior remains unchanged;
PNaCl-specific test added.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3513
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/18953003
|
|
BUG=None
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/18140003
|
|
Instead, it should generate calls to the pow* library functions, which
get found within the pexe.
This is a LOCALMOD for now, but I'm working on a more generic solution
that can be upstreamed to Clang.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3513
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/18135002
|
|
My previous change set IsARM=true for PNaCl in ItaniumCXXABI.cpp.
This gives us ARM-style representation of method pointers, which we
want, and ARM-style usage of guard variables, which we don't
necessarily want.
Switch the latter back so that the guard variable is tested via "load
i8 and compare with zero" rather than a "load i32 and test the bottom
bit". This should make the Clang-generated code match with how
libstdc++ is using the guard variable.
This makes the code match the patch I sent upstream (which hasn't been
committed yet).
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3450
TEST=test/CodeGenCXX/static-init-pnacl.cpp
Review URL: https://codereview.chromium.org/17616003
|
|
This avoids baking into pexes an assumption that function pointers are
0 mod 2, which might not be the case in future sandboxing models.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3450
TEST=run_method_pointer_repr_test in NaCl + llvm-lit test
Review URL: https://codereview.chromium.org/17419005
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@183212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@183208 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r182645 | eugenis | 2013-05-24 07:28:03 -0700 (Fri, 24 May 2013) | 6 lines
Add -lrt to sanitizer link arguments.
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182944 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Was "Implement __declspec(selectany) under -fms-extensions ..."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182381 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181283 | rsmith | 2013-05-06 19:55:48 -0700 (Mon, 06 May 2013) | 6 lines
C++ status:
- fix paper links to point to isocpp.org, where most of the papers are already up
- update "SVN" features to "Clang 3.3" to distinguish them from features which we
complete after the branch
- document use of -std=c++1y to enable c++1y support
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181342 | rsmith | 2013-05-07 12:32:56 -0700 (Tue, 07 May 2013) | 4 lines
C++1y: Update __cplusplus to temporary value 201305L to allow detection of provisional C++1y support.
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181487 | fjahanian | 2013-05-08 16:38:56 -0700 (Wed, 08 May 2013) | 4 lines
put noisy "unknown command tag name" warning
under -Wdocumentation-unknown-command and off by default.
patch by Dmitri Gribenko.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r182266 | rnk | 2013-05-20 07:02:37 -0700 (Mon, 20 May 2013) | 13 lines
Implement __declspec(selectany) under -fms-extensions
selectany only applies to externally visible global variables. It has
the effect of making the data weak_odr.
The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce. MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D814
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r182072 | rsmith | 2013-05-16 19:19:35 -0700 (Thu, 16 May 2013) | 6 lines
PR15757: When we instantiate an inheriting constructor template, also
instantiate the inherited constructor template and mark that as the constructor
which the instantiated specialization is inheriting. This fixes a
crash-on-valid when trying to compute the exception specification of a
specialization of the inheriting constructor.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181465 | rsmith | 2013-05-08 13:32:14 -0700 (Wed, 08 May 2013) | 2 lines
Add missing triple to unit test.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182037 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181921 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181750 | rafael | 2013-05-13 17:44:24 -0700 (Mon, 13 May 2013) | 4 lines
Use atomic instructions on linux thumb v7.
This matches gcc's behaviour. The patch also explicitly parses the version so
that this keeps working when we add support for v8.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181920 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181728 | rafael | 2013-05-13 13:09:47 -0700 (Mon, 13 May 2013) | 6 lines
Use atomic instructions on ARM linux.
This is safe given how the pre-v6 atomic ops funcions in libgcc are
implemented.
This fixes pr15429.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181919 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181456 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181368 | rsmith | 2013-05-07 14:53:22 -0700 (Tue, 07 May 2013) | 3 lines
Don't crash in IRGen if a conditional with 'throw' in one of its branches is
used as a branch condition.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181401 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r181299 | djasper | 2013-05-07 02:25:29 -0700 (Tue, 07 May 2013) | 5 lines
Fix clang-format emacs integration in last line.
Emacs seems to have a line that is just past the last character of the
buffers content. This needs to be handled specially so that clang-format
is not called with an invalid -offset.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@181274 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181272 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deleted the next iterator.
This is an optimization. It is possible that by deleting the next
edge we will pattern match again at the current spot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181256 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181252 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
consumers which don't create a Parser. Pointed out by Tom Honermann.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
No functionality change. The existing tests for this pragma only verify
that we can preprocess it.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D751
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181246 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We can pass such an input-file-visiting ASTReaderListener to ASTReader::readASTFileControlBlock.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181238 91177308-0d34-0410-b5e6-96231b3b80d8
|
