Re: [PATCH] D37826: Refine generation of TBAA information in clang

[Daniel Berlin via cfe-commits]

(As i mentioned to hal offline, i'm too slammed to help here)

On Wed, Sep 27, 2017 at 8:47 AM, Ivan A. Kosarev via Phabricator <
revi...@reviews.llvm.org> wrote:

> kosarev added a comment.
>
> Colleagues, please let me know if I can do anything else to help with
> reviewing the patch. Thanks.
>
>
> https://reviews.llvm.org/D37826
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36836: [clang-tidy] Implement sonarsource-function-cognitive-complexity check

[Daniel Berlin via cfe-commits]

Yes, unfortnuately, i just have no time these days with my new role. Sorry.
I'm trying to keep up with reviews where i can, but i'm prioritizing those
that are absolutely blocked on me (and trying to hand those off).



On Tue, Nov 21, 2017 at 11:11 AM, Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri updated this revision to Diff 123827.
> lebedev.ri marked an inline comment as done.
> lebedev.ri retitled this revision from "[clang-tidy] Implement
> readability-function-cognitive-complexity check" to "[clang-tidy]
> Implement sonarsource-function-cognitive-complexity check".
> lebedev.ri added a subscriber: chandlerc.
> lebedev.ri added a comment.
>
> - Rebased
> - As advised by @aaron.ballman, moved into it's own directory/module.
> Please review that, i'm not entirely sure i have done that fully correctly.
>
> @chandlerc Hi!
> @aaron.ballman has suggested for me to try to talk to you about this.
> Is there some precedent for the licensing 'issue' at hand? Do you have any
> opinion?
> @dberlin did not react to the pings, so i'm not sure i personally can come
> up with anything better for `LICENSE.txt`
>
> If there are no further ideas, i'll try to contact sonarsource.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D36836
>
> Files:
>   LICENSE.TXT
>   clang-tidy/CMakeLists.txt
>   clang-tidy/plugin/CMakeLists.txt
>   clang-tidy/sonarsource/CMakeLists.txt
>   clang-tidy/sonarsource/FunctionCognitiveComplexityCheck.cpp
>   clang-tidy/sonarsource/FunctionCognitiveComplexityCheck.h
>   clang-tidy/sonarsource/LICENSE.TXT
>   clang-tidy/sonarsource/SONARSOURCETidyModule.cpp
>   clang-tidy/tool/CMakeLists.txt
>   clang-tidy/tool/ClangTidyMain.cpp
>   docs/ReleaseNotes.rst
>   docs/clang-tidy/checks/list.rst
>   docs/clang-tidy/checks/sonarsource-function-cognitive-complexity.rst
>   test/clang-tidy/sonarsource-function-cognitive-complexity.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Fri, Apr 21, 2017 at 4:03 AM, Hal Finkel via Phabricator <
revi...@reviews.llvm.org> wrote:

> hfinkel added a comment.
>
> In https://reviews.llvm.org/D32199#732737, @rsmith wrote:
>
> > In https://reviews.llvm.org/D32199#732189, @hfinkel wrote:
> >
> > > In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
> > >
> > > > 1. C's "effective type" rule allows writes to set the type pretty
> much unconditionally, unless the storage is for a variable with a declared
> type
> > >
> > >
> > > To come back to this point: We don't really implement these rules now,
> and it is not clear that we will. The problem here is that, if we take the
> specification literally, then we can't use our current TBAA at all. The
> problem is that if we have:
> > >
> > >   write x, !tbaa "int"
> > >   read x, !tbaa "int"
> > >   write x, !tbaa "float"
> > >
> > >
> > > TBAA will currently tell us that the "float" write aliases with
> neither the preceding read nor the preceding write.
> >
> >
> > Right, C's TBAA rules do not (in general) permit a store to be reordered
> before a memory operation of a different type, they only allow loads to be
> moved before stores. (Put another way, they do not tell you that pointers
> point to distinct memory locations, just that a stored value cannot be
> observed by a load of a different type.) You get the more general "distinct
> memory locations" result only for objects of a declared type.
> >
> > C++ is similar, except that (because object lifetimes do not currently
> begin magically due to a store) you /can/ reorder stores past a memory
> operation of a different type if you know no object's lifetime began in
> between. (But currently we do not record all lifetime events in IR, so we
> can't do that today. Also, we may be about to lose the property that you
> can statically determine a small number of places that might start an
> object lifetime.)
> >
> > > Also, a strict reading of C's access rules seems to rule out the
> premise underlying our struct-path TBAA entirely. So long as I'm accessing
> a value using a struct that has some member, including recursively, with
> that type, then it's fine. The matching of the relative offsets is a
> sufficient, but not necessary, condition for well-defined access. C++ has
> essentially the same language (and, thus, potentially the same problem).
> >
> > I agree this rule is garbage, but it's not as permissive as I think
> you're suggesting. The rule says that you can use an lvalue of struct type
> to access memory of struct field type. In C this happens during struct
> assignment, for instance. It does *not* permit using an lvalue of struct
> field type to access unrelated fields of the same struct. So C appears to
> allow this nonsense:
> >
> >   char *p = malloc(8);
> >   *(int*)p = 0;
> >   *(int*)(p + 4) = 0;
> >   struct S {int n; float f;} s = *(struct S*)p; // use lvalue of type
> `struct S` to access object of effective type `int`, to initialize a `float`
> >
> >
> > but not this nonsense:
> >
> >   float q = ((struct S*)p)->f; // ub, cannot use lvalue of type `float`
> to access object of effective type `int`
> >
> >
> > ... which just means that we can't make much use of TBAA when emitting
> struct copies in C.
> >
> > In C++, on the other hand, the rule is even more garbage, since there is
> no way to perform a memory access with a glvalue of class type. (The
> closest you get is that a defaulted union construction/assignment copies
> the object representation, but that's expressed in terms of copying a
> sequence of unsigned chars, and in any case those are member functions and
> so already require an object of the correct type to exist.) See
> wg21.link/cwg2051
>
>
> Our struct-path TBAA does the following:
>
>   struct X { int a, b; };
>   X x { 50, 100 };
>   X *o = (X*) (((int*) &x) + 1);
>
>   int a_is_b = o->a; // This is UB (or so we say)?
>

This is UB.
A good resource for this stuff is http://www.cl.cam.ac.uk/~pes20/cerberus/
which has a long document where they exlpore all of these and what various
compilers do, along with what the standard seems to say.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 12:16 PM, Hal Finkel  wrote:

>
> On 05/01/2017 12:49 PM, Daniel Berlin wrote:
>
>
>
> On Fri, Apr 21, 2017 at 4:03 AM, Hal Finkel via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> hfinkel added a comment.
>>
>> In https://reviews.llvm.org/D32199#732737, @rsmith wrote:
>>
>> > In https://reviews.llvm.org/D32199#732189, @hfinkel wrote:
>> >
>> > > In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
>> > >
>> > > > 1. C's "effective type" rule allows writes to set the type pretty
>> much unconditionally, unless the storage is for a variable with a declared
>> type
>> > >
>> > >
>> > > To come back to this point: We don't really implement these rules
>> now, and it is not clear that we will. The problem here is that, if we take
>> the specification literally, then we can't use our current TBAA at all. The
>> problem is that if we have:
>> > >
>> > >   write x, !tbaa "int"
>> > >   read x, !tbaa "int"
>> > >   write x, !tbaa "float"
>> > >
>> > >
>> > > TBAA will currently tell us that the "float" write aliases with
>> neither the preceding read nor the preceding write.
>> >
>> >
>> > Right, C's TBAA rules do not (in general) permit a store to be
>> reordered before a memory operation of a different type, they only allow
>> loads to be moved before stores. (Put another way, they do not tell you
>> that pointers point to distinct memory locations, just that a stored value
>> cannot be observed by a load of a different type.) You get the more general
>> "distinct memory locations" result only for objects of a declared type.
>> >
>> > C++ is similar, except that (because object lifetimes do not currently
>> begin magically due to a store) you /can/ reorder stores past a memory
>> operation of a different type if you know no object's lifetime began in
>> between. (But currently we do not record all lifetime events in IR, so we
>> can't do that today. Also, we may be about to lose the property that you
>> can statically determine a small number of places that might start an
>> object lifetime.)
>> >
>> > > Also, a strict reading of C's access rules seems to rule out the
>> premise underlying our struct-path TBAA entirely. So long as I'm accessing
>> a value using a struct that has some member, including recursively, with
>> that type, then it's fine. The matching of the relative offsets is a
>> sufficient, but not necessary, condition for well-defined access. C++ has
>> essentially the same language (and, thus, potentially the same problem).
>> >
>> > I agree this rule is garbage, but it's not as permissive as I think
>> you're suggesting. The rule says that you can use an lvalue of struct type
>> to access memory of struct field type. In C this happens during struct
>> assignment, for instance. It does *not* permit using an lvalue of struct
>> field type to access unrelated fields of the same struct. So C appears to
>> allow this nonsense:
>> >
>> >   char *p = malloc(8);
>> >   *(int*)p = 0;
>> >   *(int*)(p + 4) = 0;
>> >   struct S {int n; float f;} s = *(struct S*)p; // use lvalue of type
>> `struct S` to access object of effective type `int`, to initialize a `float`
>> >
>> >
>> > but not this nonsense:
>> >
>> >   float q = ((struct S*)p)->f; // ub, cannot use lvalue of type `float`
>> to access object of effective type `int`
>> >
>> >
>> > ... which just means that we can't make much use of TBAA when emitting
>> struct copies in C.
>> >
>> > In C++, on the other hand, the rule is even more garbage, since there
>> is no way to perform a memory access with a glvalue of class type. (The
>> closest you get is that a defaulted union construction/assignment copies
>> the object representation, but that's expressed in terms of copying a
>> sequence of unsigned chars, and in any case those are member functions and
>> so already require an object of the correct type to exist.) See
>> wg21.link/cwg2051
>>
>>
>> Our struct-path TBAA does the following:
>>
>>   struct X { int a, b; };
>>   X x { 50, 100 };
>>   X *o = (X*) (((int*) &x) + 1);
>>
>>   int a_is_b = o->a; // This is UB (or so we say)?
>>
>
> This is UB.
> A good resource for this stuff is http://www.cl.cam.ac.uk/~pes20/cerberus/
> which has a long document where they exlpore all of these and what various
> compilers do, along with what the standard seems to say.
>
>
> http://www.cl.cam.ac.uk/~pes20/cerberus/notes30-full.pdf is 172 pages,
> and so I may have missed it, but I don't see this case.
>

Let me find it for you. it may only be in one of the other versions.


> Also, I'd really like to see where the standard says this is UB. I don't
> see it.
>
>
So you believe that you can index into an object randomly by pointer
arithmetic and pull out a different field?

For starters, this is  illegal because you don't know where the padding
bytes are.
You cannot assume that X.a + 1 == X.b
"Implementation alignment requirements might cause two adjacent members not
to be allocated immediately after each other;"

See 9.2.14
___

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

>
>
>>
>>
> So you believe that you can index into an object randomly by pointer
> arithmetic and pull out a different field?
>
> For starters, this is  illegal because you don't know where the padding
> bytes are.
> You cannot assume that X.a + 1 == X.b
> "Implementation alignment requirements might cause two adjacent members
> not to be allocated immediately after each other;"
>
> See 9.2.14
>

IE at best you'd have to add

 &(struct X*(0))->b - &(struct X*(0))->a


I don't believe this is legal either.

Let me try to dredge up the long discussions we had about these cases on
the gcc mailing lists.
The conclusion was, i believe:

"if you want to go marching through an object as a char *, that's fine, if
you expect to be able to get at fields by playing pointer arithmetic games,
from other fields, that is not)
I feel like every couple years, a different compiler has the same aliasing
discussions :)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:

> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin  wrote:
>
>> So you believe that you can index into an object randomly by pointer
 arithmetic and pull out a different field?

>>>
>>> For starters, this is  illegal because you don't know where the padding
>>> bytes are.
>>> You cannot assume that X.a + 1 == X.b
>>> "Implementation alignment requirements might cause two adjacent members
>>> not to be allocated immediately after each other;"
>>>
>>> See 9.2.14
>>>
>>
>> IE at best you'd have to add
>>
>>  &(struct X*(0))->b - &(struct X*(0))->a
>>
>>
>> I don't believe this is legal either.
>>
>> Let me try to dredge up the long discussions we had about these cases on
>> the gcc mailing lists.
>> The conclusion was, i believe:
>>
>> "if you want to go marching through an object as a char *, that's fine,
>> if you expect to be able to get at fields by playing pointer arithmetic
>> games, from other fields, that is not)
>> I feel like every couple years, a different compiler has the same
>> aliasing discussions :)
>>
>
> With the caveat that, in practice, compilers have to support both:
>   a) "going up a level" by subtracting an offsetof, which is clearly
> officially intended and not otherwise supported,
>

AFAIK, Vtable accesses were supported by doing this, but pretty much
nothing else.



> and
>   b) treating a final or flexible array member, possibly at depth > 1, as
> contiguous with a trailing array, because this is an extremely common
> extension and artificial idiom.
>

Yes, anything at the end was treated as magically special.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin  wrote:

>
>
> On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:
>
>> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin 
>> wrote:
>>
>>> So you believe that you can index into an object randomly by pointer
> arithmetic and pull out a different field?
>

 For starters, this is  illegal because you don't know where the padding
 bytes are.
 You cannot assume that X.a + 1 == X.b
 "Implementation alignment requirements might cause two adjacent members
 not to be allocated immediately after each other;"

 See 9.2.14

>>>
>>> IE at best you'd have to add
>>>
>>>  &(struct X*(0))->b - &(struct X*(0))->a
>>>
>>>
>>> I don't believe this is legal either.
>>>
>>> Let me try to dredge up the long discussions we had about these cases on
>>> the gcc mailing lists.
>>> The conclusion was, i believe:
>>>
>>> "if you want to go marching through an object as a char *, that's fine,
>>> if you expect to be able to get at fields by playing pointer arithmetic
>>> games, from other fields, that is not)
>>> I feel like every couple years, a different compiler has the same
>>> aliasing discussions :)
>>>
>>
>> With the caveat that, in practice, compilers have to support both:
>>   a) "going up a level" by subtracting an offsetof, which is clearly
>> officially intended and not otherwise supported,
>>
>
> AFAIK, Vtable accesses were supported by doing this, but pretty much
> nothing else.
>

and to be clear, i mean given:

struct a
{
int a;
 struct b bstruct;
};

given a pointer to bstruct, subtracting sizeof(int)  is not going to give
you a pointer to a struct a.

It was allowed to work for vtable accesses.

everyone else got told to turn off strict aliasing if you wanted it to
work, and they did.

But again, i'll go thread spleunking
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 3:58 PM, John McCall  wrote:

> On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin  wrote:
>
>> On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin 
>> wrote:
>>
>>> On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:
>>>
 On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin 
 wrote:

> So you believe that you can index into an object randomly by pointer
>>> arithmetic and pull out a different field?
>>>
>>
>> For starters, this is  illegal because you don't know where the
>> padding bytes are.
>> You cannot assume that X.a + 1 == X.b
>> "Implementation alignment requirements might cause two adjacent
>> members not to be allocated immediately after each other;"
>>
>> See 9.2.14
>>
>
> IE at best you'd have to add
>
>  &(struct X*(0))->b - &(struct X*(0))->a
>
>
> I don't believe this is legal either.
>
> Let me try to dredge up the long discussions we had about these cases
> on the gcc mailing lists.
> The conclusion was, i believe:
>
> "if you want to go marching through an object as a char *, that's
> fine, if you expect to be able to get at fields by playing pointer
> arithmetic games, from other fields, that is not)
> I feel like every couple years, a different compiler has the same
> aliasing discussions :)
>

 With the caveat that, in practice, compilers have to support both:
   a) "going up a level" by subtracting an offsetof, which is clearly
 officially intended and not otherwise supported,

>>>
>>> AFAIK, Vtable accesses were supported by doing this, but pretty much
>>> nothing else.
>>>
>>
>> and to be clear, i mean given:
>>
>> struct a
>> {
>> int a;
>>  struct b bstruct;
>> };
>>
>> given a pointer to bstruct, subtracting sizeof(int)  is not going to give
>> you a pointer to a struct a.
>>
>
> If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure
> should (if you're doing the pointer arithmetic on an appropriate type, of
> course).
>
>



> It was allowed to work for vtable accesses.
>>
>
> I would like to once again remind you that random mailing list
> conversations you happened to be in but can't even remember from some
> completely unnamed
>

It's not unnamed, it's either gcc@, gcc-patches@ or gcc bugzilla.
I can even give you approximate dates if you like.

I don't believe calling "the other major compiler's mailing list", which
treaded exactly this topic, is "a random mailing list conversation", or "an
unnamed source" or a "different context".


> and possibly different context are neither authoritative nor binding on us
> now. :)
>
> John, while i appreciate the smiley, this is kind of rude.
Without a good reason to be different, we should follow the paths other
compilers have taken and users have become used to. Both in what we allow,
and what we disallow.
So if the plan here is go off and do something that is going to be
completely different than what users expect from their compilers, that
doesn't make a lot of sense to me.
Otherwise, if you really don't want me to tell you what they've done, and
try to explain why, okay, fine, then i'll bow out of these discussion and
leave y'all to do whatever.

Just don't expect me to okay patches to llvm that implement the current
kind of hacks we currently have.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13446: [PATCH] Add checker discouraging definition of variadic function definitions in C++

[Daniel Berlin via cfe-commits]

dberlin added a subscriber: dberlin.


Comment at: docs/clang-tidy/checks/cert-variadic-function-def.rst:13
@@ +12,2 @@
+`DCL50-CPP. Do not define a C-style variadic function
+`_.

I'm sure this is oversight on CERT's part, but their website actually has terms 
of use (click the terms of use at the bottom of the page) that says this can't 
be copied/reused, and here you are, copying it.
It explicit says: "
Use of the Service. You may only display the content of the Service for your 
own personal use (i.e., non-commercial use) and may not otherwise copy, 
reproduce, alter, modify, create derivative works, or publicly display any 
content. "

Before this is accepted, someone should email cert and say "hey, uh, yeah, this 
seems bad", and get them to okay you doing this.
I'm sure they'll go and fix this.



http://reviews.llvm.org/D13446



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13446: [PATCH] Add checker discouraging definition of variadic function definitions in C++

[Daniel Berlin via cfe-commits]

Apologies, I will try to take a look today

On Tue, Nov 3, 2015, 10:05 AM Aaron Ballman  wrote:

> On Tue, Nov 3, 2015 at 7:19 AM, Alexander Kornienko 
> wrote:
> > On Fri, Oct 9, 2015 at 12:13 PM, Aaron Ballman 
> > wrote:
> >>
> >> On Fri, Oct 9, 2015 at 3:09 PM, Daniel Berlin 
> wrote:
> >> > dberlin added a subscriber: dberlin.
> >> >
> >> > 
> >> > Comment at: docs/clang-tidy/checks/cert-variadic-function-def.rst:13
> >> > @@ +12,2 @@
> >> > +`DCL50-CPP. Do not define a C-style variadic function
> >> >
> >> > +<
> https://www.securecoding.cert.org/confluence/display/cplusplus/DCL50-CPP.+Do+not+define+a+C-style+variadic+function
> >`_.
> >> > 
> >> > I'm sure this is oversight on CERT's part, but their website actually
> >> > has terms of use (click the terms of use at the bottom of the page)
> that
> >> > says this can't be copied/reused, and here you are, copying it.
> >> > It explicit says: "
> >> > Use of the Service. You may only display the content of the Service
> for
> >> > your own personal use (i.e., non-commercial use) and may not
> otherwise copy,
> >> > reproduce, alter, modify, create derivative works, or publicly
> display any
> >> > content. "
> >> >
> >> > Before this is accepted, someone should email cert and say "hey, uh,
> >> > yeah, this seems bad", and get them to okay you doing this.
> >> > I'm sure they'll go and fix this.
> >>
> >> That's an excellent point, I will bring it up internally (I work for
> >> CERT) and report back.
> >
> >
> > Any news here?
>
> Yes; I have heard back from CERT's legal team, and they have a
> document that I have sent (off-list) to Daniel for review. If it seems
> like it would resolve his concerns, then I think the next step will be
> to bring it to the LLVM foundation more formally to see how they would
> like to handle it.
>
> ~Aaron
>
> >
> >>
> >>
> >> ~Aaron
> >>
> >> >
> >> >
> >> >
> >> > http://reviews.llvm.org/D13446
> >> >
> >> >
> >> >
> >
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Daniel Berlin via cfe-commits]

On Mon, Jul 25, 2016 at 1:03 PM, Vlad Dovlekaev via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:

> vladisld added a comment.
>
> In https://reviews.llvm.org/D22463#494828, @jlebar wrote:
>
> > I think the general feeling is that most of us (myself included) would
> rather not learn a new tool if there's a simpler >alternative, such as a
> vanilla git workflow.
>
>
> Generally you're right, however learning how to use git-repo is much
> simpler than managing the intricacies of git sub-modules (and Google's
> experience with Android is a clear example of it).


Just to make some points, as a guy who watched repo being designed in the
office next to me:
Sub modules were completely and totally unusable for Google at that point,
and something was needed sooner.
There is no good reason for android to change now, so they don't.

Note that repo does not solve the issue of cross-repo atomic commits in any
way, shape, or form, and in fact, this is the biggest complaint ;)

In fact, the gerrit team (same people who produce repo) uses submodules for
pseudo-atomic cross-repo commits.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15087: [PATCH] Add CERT license clarification

[Daniel Berlin via cfe-commits]

dberlin added a comment.

The license  looks fine to me


http://reviews.llvm.org/D15087



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits