Author: James Y Knight
Date: 2022-05-22T10:22:13-04:00
New Revision: 69c0af3de224131cca844debd12872d4d1686800
URL:
https://github.com/llvm/llvm-project/commit/69c0af3de224131cca844debd12872d4d1686800
DIFF:
https://github.com/llvm/llvm-project/commit/69c0af3de224131cca844debd12872d4d1686800
jyknight wrote:
Can reduce further to:
```
template
concept h = requires(T i) { [] {}(i); };
template struct k;
template struct k {
struct n;
};
using o = k::n;
```
But, is `requires(T i) { [] {}(i); };` actually valid? I think that _should_
fail the requirement, since you cannot call tha
jyknight wrote:
+1 on the high-level plan. Switching from a linear offset to a
{local-module-index, offset-within-module} pair sounds great!
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
jyknight wrote:
Thanks for reviving the change!
I'm definitely in favor of this, but since it adds no new functionality (only
better usability), the value proposition is significantly lessened (IMO, to the
point where it may not be be worthwhile to do) if it gets implemented ONLY in
clang. S
@@ -1760,6 +1760,50 @@ references can be used instead of numeric references.
return -1;
}
+Hard Register Operands for ASM Constraints
+==
+
+Clang supports the ability to specify specific hardware registers in inline
+assembly co
@@ -770,6 +770,18 @@ bool TargetInfo::validateOutputConstraint(ConstraintInfo
&Info) const {
case 'E':
case 'F':
break; // Pass them.
+case '{': {
jyknight wrote:
It's unclear to me whether this uses the same register parsing logic as the
jyknight wrote:
> So, alternatively...we could just go with the simplest solution, and use
> "ieee" as the default even under -ffast-math.
This is feeling like the best option to me, at this point. Easily
implementable, and doesn't seem to make things significantly worse than they
are today,
jyknight wrote:
@RKSimon: I'm not sure if you intended your comment to be a blocker; I was
about to press the merge button when you commented (and would still wish to
now).
https://github.com/llvm/llvm-project/pull/74275
___
cfe-commits mailing list
jyknight wrote:
> > > > So, alternatively...we could just go with the simplest solution, and
> > > > use "ieee" as the default even under -ffast-math.
> >
> >
> > +1. **There hasn't been a performance reason to use FTZ/DAZ since ~2011.**
> > Maybe there's still a power benefit? But in that ca
jyknight wrote:
I'm proposing a simple change we can make _now_, in order to unblock this PR
which at least gets rid of crtfastmath for shared libraries! I don't think this
needs to be the end of the story; additional, more large-scale changes can be
made afterwards...
> Are youe suggesting t
jyknight wrote:
> I don't see why the current denormal-fp-math setting behavior is a blocking
> issue for this change
Because this PR as-is causes us to start parsing the "-shared" flag for
compilation actions in order to determine which denormal-fp-math setting to
use. Users should not pass
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/81173
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight approved this pull request.
Sorry for the delay. This looks good to me now!
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
jyknight wrote:
Is there a valid use for having "EHCleanup" that _doesn't_ handle branches
across it? That is, do we _ever_ need a cleanup to be called only for an
exception thrown, and not otherwise leaving the scope? I'm just wondering if we
can simplify things conceptually here and remove a
jyknight wrote:
What config is this bot using? Is it "-target sparc-solaris -mcpu=v9" (that is:
32-bit sparc, but with v9 cpu available)?
I see that SparcV9TargetInfo sets MaxAtomicInlineWidth to 64 unconditionally.
But, the message `warning: large atomic operation may incur significant
perfo
jyknight wrote:
> Don't know but everything passed now!
Well, I'm not an expert on the objc codegen...but unless you, or someone else,
can explain that my concern is invalid, I think this change cannot be made.
https://github.com/llvm/llvm-project/pull/79191
___
jyknight wrote:
Underaligned atomic operations are expanded to an appropriate `__atomic_*`
libcall via mostly target-independent code in AtomicExpandPass
(https://github.com/llvm/llvm-project/blob/7ecfb66c77ad77dabbb705cbb1f3b17a3d1391a4/llvm/lib/CodeGen/AtomicExpandPass.cpp#L210)
and never hi
jyknight wrote:
I think there is a bit of a problematic interaction with getDenormalModeForType
[here](https://github.com/llvm/llvm-project/blob/7a94acb2da5b20d12f13f3c5f4eb0f3f46e78e73/clang/lib/Driver/ToolChains/Linux.cpp#L838C8-L838C37).
"-shared" is (should be) a flag used only for linking,
jyknight wrote:
> It is not always safe to run preserve-sign code under IEEE settings
I can see that this is used in a bunch of optimization/constant-folding passes,
but I don't have a feel for what the actual impact is:
1. Which value allows generating the "fastest" math code -- disregarding
jyknight wrote:
> You'll get different results depending on whether the input is implicitly
> flushed in fcmp vs. not in the is.fpclass
This sounds intuitively like the sort of semantics-breaking optimization which
is expected from `-ffast-math`. If the only issues are things like getting a
s
jyknight wrote:
This is incorrect: X86 does not support unaligned atomics.
However, LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary). So the ObjC code's
`hasUnalignedAtomics` could be removed, and let the backend deal with i
jyknight wrote:
Does this cause an ABI incompatibility? E.g. if we have a case where an
existing object calls copyStruct on a given object (which presumably has its
own internal mutex), and a newly compiled object file calls `__atomic_load` on
the same object, implemented with its own internal
jyknight wrote:
My suggestion on #69994 had been to stop implying
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` from
`_LIBCPP_ENABLE_CXX20_REMOVED_FEATURES` in LLVM 18 at the same time as
deprecating it. Did you intend to _not_ do that, or was it just missed?
https://github.com/llvm/llvm-p
jyknight wrote:
Ah, I see that now. SGTM, thanks for the clarification!
https://github.com/llvm/llvm-project/pull/77692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
There's two sets of atomic functions:
`__atomic_*` are provided by libatomic, and might use locking, or not.
`__sync_*` should always be lock-free. These are only used on certain
architectures where it's guaranteed that the operation _can_ be implemented
lock-free, but it's desi
jyknight wrote:
Yes, that's an acceptable/correct solution in that circumstance. Given we
already have a forced-atomics option, IMO it probably makes sense to still
require users to specify that explicitly, rather than effectively defaulting it
to on with Zaamo.
However, I must say, I cannot
jyknight wrote:
BTW, please don't rebase/amend commits and force-push, it makes a it extremely
difficult to review the changes since the previous review -- especially if the
new changes are commingled with a rebase.
Much better to simply push new commits on top of your existing branch. And if
jyknight wrote:
I think we can check whether it's been overridden more easily using an asm
alias like this (when libc++ is built under -fno-exceptions):
```
#include
#include
__attribute__((weak)) void* operator new(std::size_t size) {
void* mem = malloc(size);
if (!mem) abort();
return
Author: James Y Knight
Date: 2021-01-27T16:46:51-05:00
New Revision: 9c7aeaebb3ac1b94200b59b111742cb6b8f090c2
URL:
https://github.com/llvm/llvm-project/commit/9c7aeaebb3ac1b94200b59b111742cb6b8f090c2
DIFF:
https://github.com/llvm/llvm-project/commit/9c7aeaebb3ac1b94200b59b111742cb6b8f090c2
Author: James Y Knight
Date: 2021-01-27T16:46:52-05:00
New Revision: 8ca33605ff0cfc536f5c6710fb5f6378bf11959a
URL:
https://github.com/llvm/llvm-project/commit/8ca33605ff0cfc536f5c6710fb5f6378bf11959a
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-01-27T16:46:52-05:00
New Revision: a7246ba02a8923f316419a62d836dbe1c0b437bd
URL:
https://github.com/llvm/llvm-project/commit/a7246ba02a8923f316419a62d836dbe1c0b437bd
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-01-27T16:46:51-05:00
New Revision: 9c7aeaebb3ac1b94200b59b111742cb6b8f090c2
URL:
https://github.com/llvm/llvm-project/commit/9c7aeaebb3ac1b94200b59b111742cb6b8f090c2
DIFF:
https://github.com/llvm/llvm-project/commit/9c7aeaebb3ac1b94200b59b111742cb6b8f090c2
Author: James Y Knight
Date: 2021-01-27T16:46:52-05:00
New Revision: 8ca33605ff0cfc536f5c6710fb5f6378bf11959a
URL:
https://github.com/llvm/llvm-project/commit/8ca33605ff0cfc536f5c6710fb5f6378bf11959a
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-01-27T16:46:52-05:00
New Revision: a7246ba02a8923f316419a62d836dbe1c0b437bd
URL:
https://github.com/llvm/llvm-project/commit/a7246ba02a8923f316419a62d836dbe1c0b437bd
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-01-31T18:43:00-05:00
New Revision: 8f670d5b6d8f39bf9bf1d142dacef3afaed6d70b
URL:
https://github.com/llvm/llvm-project/commit/8f670d5b6d8f39bf9bf1d142dacef3afaed6d70b
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-01-31T19:56:26-05:00
New Revision: 20b1c1300c8f00d85e1292158f865c1bd0d1e12c
URL:
https://github.com/llvm/llvm-project/commit/20b1c1300c8f00d85e1292158f865c1bd0d1e12c
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-02-22T17:55:25-05:00
New Revision: fe2dcd89acfd9301a230e38e9030734553baa8dc
URL:
https://github.com/llvm/llvm-project/commit/fe2dcd89acfd9301a230e38e9030734553baa8dc
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-02-22T18:47:15-05:00
New Revision: e8617f2f1870022b7dd076bf43c7aaee30831197
URL:
https://github.com/llvm/llvm-project/commit/e8617f2f1870022b7dd076bf43c7aaee30831197
DIFF:
https://github.com/llvm/llvm-project/commit/e8617f2f1870022b7dd076bf43c7aaee30831197
Author: James Y Knight
Date: 2021-11-09T16:59:45-05:00
New Revision: 50082e1882ae7fe101e563c5e18a27e0804d517b
URL:
https://github.com/llvm/llvm-project/commit/50082e1882ae7fe101e563c5e18a27e0804d517b
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2021-11-10T17:40:16-05:00
New Revision: fddc4e41164e2fd152605362639eb3255cc75212
URL:
https://github.com/llvm/llvm-project/commit/fddc4e41164e2fd152605362639eb3255cc75212
DIFF:
https://github.com/llvm/llvm-project/commit/fddc4e41164e2fd152605362639eb3255cc75212
Author: James Y Knight
Date: 2021-02-25T18:29:42-05:00
New Revision: 24539f1ef2471d07bd87f833cb0288fc0f251f4b
URL:
https://github.com/llvm/llvm-project/commit/24539f1ef2471d07bd87f833cb0288fc0f251f4b
DIFF:
https://github.com/llvm/llvm-project/commit
Author: James Y Knight
Date: 2023-01-31T09:57:23-05:00
New Revision: ab0116e2f05c6156c4bc3d35986de1e98cc27016
URL:
https://github.com/llvm/llvm-project/commit/ab0116e2f05c6156c4bc3d35986de1e98cc27016
DIFF:
https://github.com/llvm/llvm-project/commit/ab0116e2f05c6156c4bc3d35986de1e98cc27016
Author: James Y Knight
Date: 2022-06-22T09:55:05-04:00
New Revision: 17e27025287b96026a4351e1d73931bb0c76dac2
URL:
https://github.com/llvm/llvm-project/commit/17e27025287b96026a4351e1d73931bb0c76dac2
DIFF:
https://github.com/llvm/llvm-project/commit/17e27025287b96026a4351e1d73931bb0c76dac2
Author: James Y Knight
Date: 2022-05-25T14:20:11-04:00
New Revision: 997b072e10d2be09c0e1a5bf4d6b92e2da3b8cc6
URL:
https://github.com/llvm/llvm-project/commit/997b072e10d2be09c0e1a5bf4d6b92e2da3b8cc6
DIFF:
https://github.com/llvm/llvm-project/commit/997b072e10d2be09c0e1a5bf4d6b92e2da3b8cc6
https://github.com/jyknight approved this pull request.
Ok. We should change the default to a non zero value to match gcc, too, but
that can be a follow-up.
https://github.com/llvm/llvm-project/pull/66839
___
cfe-commits mailing list
cfe-commits@lists
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/3] [libcxx] Allow string to use SSO in constant evaluat
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/3] [libcxx] Allow string to use SSO in constant evaluat
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/4] [libcxx] Allow string to use SSO in constant evaluat
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/4] [libcxx] Allow string to use SSO in constant evaluat
@@ -1969,7 +1955,8 @@ private:
allocator_type __a = __str.__alloc();
auto __allocation = std::__allocate_at_least(__a,
__str.__get_long_cap());
__begin_lifetime(__allocation.ptr, __allocation.count);
-
@@ -1746,26 +1747,8 @@ private:
#endif // _LIBCPP_STD_VER >= 20
}
-_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 void __default_init() {
-__r_.first() = __rep();
-if (__libcpp_is_constant_evaluated()) {
-size_type __sz = __recommend(0)
@@ -880,7 +880,7 @@ public:
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string()
_NOEXCEPT_(is_nothrow_default_constructible::value)
: __r_(__default_init_tag(), __default_init_tag()) {
-__default_init();
+__r_.first() = __rep();
@@ -1969,7 +1955,8 @@ private:
allocator_type __a = __str.__alloc();
auto __allocation = std::__allocate_at_least(__a,
__str.__get_long_cap());
__begin_lifetime(__allocation.ptr, __allocation.count);
-
@@ -1746,26 +1747,8 @@ private:
#endif // _LIBCPP_STD_VER >= 20
}
-_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 void __default_init() {
-__r_.first() = __rep();
-if (__libcpp_is_constant_evaluated()) {
-size_type __sz = __recommend(0)
jyknight wrote:
I don't think I will be able to work on that the discussed Clang diagnostics
anytime soon. Unless someone else is volunteering to implement it, that may not
be implemented at all.
So, I'd like to hear explicit consensus is that folks are generally OK to
submit this _without_ s
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/5] [libcxx] Allow string to use SSO in constant evaluat
@@ -0,0 +1,22 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
@@ -0,0 +1,22 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/66576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/66576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/6] [libcxx] Allow string to use SSO in constant evaluat
jyknight wrote:
Looks like the debug/hardened/safe mode tests are failing
libcxx/std/utilities/template.bitset/bitset.members/to_string.pass.cpp because
the constant evaluations for
```
static_assert(test_to_string<64>());
static_assert(test_to_string<65>());
```
now both hit the constant e
jyknight wrote:
> This pull request implements the entirety of the now-accepted N3017 -
> Preprocessor Embed.
Amazing! I had started to think about looking into getting this implemented
recently, so it's really nice to see an implementation uploaded now!
> I have no intention of following up
I'm not clear as to what you're saying is broken.
On MS platforms, long is 32-bit, so either way this function takes a 32bit
value, right? And, Microsoft's docs say this function takes a long.
On Wed, Feb 26, 2020, 5:09 PM Michael Spencer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> I
or in clang?
On Mon, Nov 25, 2019, 7:07 PM Aaron Ballman wrote:
> On Mon, Nov 25, 2019 at 5:59 PM James Y Knight
> wrote:
> >
> > Isn't this unnecessarily annoying to users? You have the same syntax to
> use the attributes, and the attributes are expected to be compatibl
On Fri, Feb 28, 2020 at 10:05 AM Aaron Ballman
wrote:
> On Thu, Feb 27, 2020 at 6:04 PM James Y Knight
> wrote:
> >
> > That all makes sense -- especially the bits about the dates needing to
> be different.
> >
> > But, even with all that, I'm no
On Fri, Feb 28, 2020 at 11:42 AM Arthur O'Dwyer
wrote:
> On Fri, Feb 28, 2020 at 11:23 AM James Y Knight via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Fri, Feb 28, 2020 at 10:05 AM Aaron Ballman
>> wrote:
>>
>>> On Thu, Fe
Author: James Y Knight
Date: 2019-11-04T16:26:53-05:00
New Revision: d11a9018b773c0359934a7989d886b02468112e4
URL:
https://github.com/llvm/llvm-project/commit/d11a9018b773c0359934a7989d886b02468112e4
DIFF:
https://github.com/llvm/llvm-project/commit/d11a9018b773c0359934a7989d886b02468112e4
Isn't this unnecessarily annoying to users? You have the same syntax to use
the attributes, and the attributes are expected to be compatible when named
the same way, but you can't use the same #if conditional to check for
availability, when writing a header intended to work in both modes?
On Mon,
Author: James Y Knight
Date: 2019-12-04T15:12:17-05:00
New Revision: 90fce46fa6c9ccec86f642be0a75da2d0a5b11c1
URL:
https://github.com/llvm/llvm-project/commit/90fce46fa6c9ccec86f642be0a75da2d0a5b11c1
DIFF:
https://github.com/llvm/llvm-project/commit/90fce46fa6c9ccec86f642be0a75da2d0a5b11c1
Author: jyknight
Date: Fri Jan 13 13:22:26 2017
New Revision: 291946
URL: http://llvm.org/viewvc/llvm-project?rev=291946&view=rev
Log:
[libc++abi] Add a silent terminate handler to libcxxabi.
The current std::terminate_handler pulls in some string code, some I/O
code, and more. Since it is automa
nemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> FWIW, doesn't this just need a may_alias attribute on the definition?
> On Wed, Jul 5, 2017 at 2:39 PM James Y Knight via Phabricator via
> cfe-commits wrote:
>
>> jyknight added a comment.
>>
>> Ping. I don
Author: jyknight
Date: Wed Jul 19 14:48:49 2017
New Revision: 308528
URL: http://llvm.org/viewvc/llvm-project?rev=308528&view=rev
Log:
Rework libcxx strerror_r handling.
The set of #ifdefs used to handle the two incompatible variants of
strerror_r were not complete (they didn't handle newlib appr
Author: jyknight
Date: Thu May 4 16:31:17 2017
New Revision: 302195
URL: http://llvm.org/viewvc/llvm-project?rev=302195&view=rev
Log:
Fix whitespace before token-paste of an argument.
The whitespace should come from the argument name in the macro
expansion, rather than from the token passed to t
Author: jyknight
Date: Wed May 10 16:48:13 2017
New Revision: 302738
URL: http://llvm.org/viewvc/llvm-project?rev=302738&view=rev
Log:
[Myriad] Pass -Xclang and -mllvm flags to moviCompile
Patch by Walter Lee.
Differential Revision: https://reviews.llvm.org/D33020
Modified:
cfe/trunk/lib/Dr
Author: jyknight
Date: Fri May 12 11:01:23 2017
New Revision: 302913
URL: http://llvm.org/viewvc/llvm-project?rev=302913&view=rev
Log:
[SPARC] Support 'f' and 'e' inline asm constraints.
Patch by Patrick Boettcher.
Differential Revision: https://reviews.llvm.org/D29117
Added:
cfe/trunk/test
This breaks code which is using module headers, and then does like this:
extern "C" {
#include
}
because:
> In file included from include/c++/v1/stdint.h:102:
> include/c++/v1/__config:912:35: error: declaration of
> '__libcpp_library_version' has a different language linkage
> _LIBCPP_FUNC_VIS
jyknight added inline comments.
Comment at: lib/Driver/ToolChains.cpp:3929
@@ +3928,3 @@
+: Generic_GCC(D, Triple, Args) {
+ // If a target of 'sparc-myriad-elf' is specified to clang, it wants to use
+ // 'sparc-myriad--elf' (note the unknown OS) as the canonical triple.
--
jyknight accepted this revision.
jyknight added a comment.
This revision is now accepted and ready to land.
Other than minor comments, lgtm.
Comment at: lib/Driver/ToolChains.cpp:3937
@@ +3936,3 @@
+ default:
+llvm_unreachable("Unsupported architecture");
+ case llvm::Trip
Author: jyknight
Date: Tue Sep 29 17:28:44 2015
New Revision: 248836
URL: http://llvm.org/viewvc/llvm-project?rev=248836&view=rev
Log:
Move functions declared in ExprObjC.h into ExprObjC.cpp.
r51703 back in 2008 split out all the ObjC Expr subclasses from Expr.h
to a new ExprObjC.h file, but fail
Author: jyknight
Date: Wed Sep 30 09:04:23 2015
New Revision: 248905
URL: http://llvm.org/viewvc/llvm-project?rev=248905&view=rev
Log:
Fix FunctionParmPackExpr::Create() to take a ParmVarDecl* array.
FunctionParmPackExpr actually stores an array of ParmVarDecl* (and
accessors return that). But, t
jyknight added a comment.
This certainly seems a big improvement.
However, I don't think that you actually fixed specifying both
-gline-tables-only and a Dwarf version, because that requires actually handling
multiple options from g_group, instead of just the last one. E.g. "-gdwarf-2
-g1" sho
Sorry for the miscommunication, I thought you were going to commit it
already. LGTM.
On Wed, Aug 12, 2015 at 6:37 AM, Brad Smith wrote:
> On 06/05/2015 08:30 PM, Brad Smith wrote:
>
>> On 06/05/15 01:33, James Y Knight wrote:
>>
>>> Thanks. Openbsd doesn't seem
Author: jyknight
Date: Fri Aug 14 22:45:25 2015
New Revision: 245154
URL: http://llvm.org/viewvc/llvm-project?rev=245154&view=rev
Log:
Tiny cleanup: move some Triple variables up to the top of the
function, and remove a duplicate var.
Modified:
cfe/trunk/lib/Driver/Tools.cpp
Modified: cfe/tr
jyknight added inline comments.
Comment at: lib/Driver/Tools.cpp:2928
@@ +2927,3 @@
+/// Parses the various -fpic/-fPIC/-fpie/-fPIE arguments. Then,
+/// smooshes them together with platform defaults, to decide with
+/// whether this compile should be using PIC mode or not. Retur
jyknight updated this revision to Diff 32216.
jyknight added a comment.
Updated for review comments
http://reviews.llvm.org/D11845
Files:
include/clang/Driver/CC1Options.td
lib/Driver/Tools.cpp
test/Driver/integrated-as.s
Index: test/Driver/integrated-as.s
===
jyknight added a comment.
Joerg said LGTM on #llvm; going ahead with commit.
http://reviews.llvm.org/D11845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL245447: Properly pass through the PIC mode to the integrated
assembler when (authored by jyknight).
Changed prior to commit:
http://reviews.llvm.org/D11845?vs=32216&id=32552#toc
Repository:
rL LLVM
Author: jyknight
Date: Wed Aug 19 10:12:02 2015
New Revision: 245447
URL: http://llvm.org/viewvc/llvm-project?rev=245447&view=rev
Log:
Properly pass through the PIC mode to the integrated assembler when
doing assembly-only, and unify the Driver's PIC argument parsing.
On a few architectures, pars
jyknight created this revision.
jyknight added a reviewer: joerg.
jyknight added subscribers: rnk, jevinskie, tberghammer, danalbert, srhines,
cfe-commits.
For some reason, clang had been treating a command like:
clang -static -fPIC foo.c
as if it should be compiled without the PIC relocation mo
Author: jyknight
Date: Thu Aug 20 23:14:55 2015
New Revision: 245667
URL: http://llvm.org/viewvc/llvm-project?rev=245667&view=rev
Log:
Stop treating -static as overriding -fPIC: they are distinct.
For some reason, clang had been treating a command like:
clang -static -fPIC foo.c
as if it should
jyknight created this revision.
jyknight added a reviewer: majnemer.
jyknight added a subscriber: cfe-commits.
This is important in the case that the LLVM-inferred llvm-struct
alignment is not the same as the clang-known C-struct alignment.
http://reviews.llvm.org/D12243
Files:
lib/CodeGen/CGC
Author: jyknight
Date: Fri Aug 21 13:19:06 2015
New Revision: 245719
URL: http://llvm.org/viewvc/llvm-project?rev=245719&view=rev
Log:
Properly provide alignment of 'byval' arguments down to llvm.
This is important in the case that the LLVM-inferred llvm-struct
alignment is not the same as the cl
This revision was automatically updated to reflect the committed changes.
Closed by commit rL245719: Properly provide alignment of 'byval' arguments down
to llvm. (authored by jyknight).
Changed prior to commit:
http://reviews.llvm.org/D12243?vs=32839&id=32847#toc
Repository:
rL LLVM
http:/
jyknight closed this revision.
jyknight added a comment.
D'oh, I copy/pasted the wrong review link when submitting this. It was
submitted as http://reviews.llvm.org/rL245667.
http://reviews.llvm.org/D12164
___
cfe-commits mailing list
cfe-commits@l
jyknight added inline comments.
Comment at: lib/Driver/ToolChains.cpp:3936
@@ -3914,9 +3935,3 @@
-SHAVEToolChain::SHAVEToolChain(const Driver &D, const llvm::Triple &Triple,
- const ArgList &Args)
-: Generic_GCC(D, Triple, Args) {}
-
-SHAVEToolC
jyknight created this revision.
jyknight added a reviewer: dougk.
jyknight added a subscriber: cfe-commits.
Herald added a subscriber: jyknight.
Also move the addLibStdCXXIncludePaths helper function from Linux to
Generic_GCC.
http://reviews.llvm.org/D13813
Files:
lib/Driver/ToolChains.cpp
l
Author: jyknight
Date: Fri Oct 16 13:46:26 2015
New Revision: 250536
URL: http://llvm.org/viewvc/llvm-project?rev=250536&view=rev
Log:
Teach MyriadToolchain how to find its C++ header paths.
Also move the addLibStdCXXIncludePaths helper function from Linux to
Generic_GCC.
Added:
cfe/trunk/te
jyknight added inline comments.
/cfe/trunk/lib/CodeGen/CGAtomic.cpp:941-943 Looks like GCC's behavior does
actually follow that spec.
I'm not sure why the library exposes these entry-points when you're not
supposed to use them. Oop. Sorry that I failed to notice that.
Users:
jyknight (Author
jyknight created this revision.
jyknight added a reviewer: rsmith.
jyknight added subscribers: majnemer, compnerd, cfe-commits, tstellarAMD.
In r244063, I had caused these builtins to call the same-named library
functions, __atomic_*_fetch_SIZE. However, this was incorrect: while
those functions a
101 - 200 of 886 matches
Mail list logo
