make update not updating clang svn?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

make update not updating clang svn?

George King
Hi list,

According to http://clang.llvm.org/get_started.html:

You can update your toplevel LLVM project and all (possibly unrelated) projects inside it with make update. This will run svn update on all subdirectories related to subversion.

However after following the check out instructions, I observed the following behavior:

gk ~/external/llvm > make update
svn  update /Users/gk/external/llvm
U    /Users/gk/external/llvm/test/CodeGen/X86/break-sse-dep.ll
... (more U ... lines)
Updated to revision 91929.

gk ~/external/llvm > cd tools/clang
gk ~/external/llvm/tools/clang > svn update
U    test/Lexer/char-escapes.c
... (many more U ... lines)
Updated to revision 91930.

gk ~/external/llvm/tools/clang > cd ../..
gk ~/external/llvm > svn update
At revision 91930.


'make update' did not appear to run 'svn update' for the tools/clang directory. Otherwise I would see "svn update /Users/gk/external/llvm/tools/clang" output, right? I realize that this looks a little ambiguous because of the revision numbers 91929 and 91930, but I don't think that's the issue; there were hundreds of files updated in the clang tree, which I doubt were committed in the interim between commands.

Does 'make update' work as advertised for others?

Thank you,

George
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: make update not updating clang svn?

Chris Lattner

On Dec 22, 2009, at 2:53 PM, George King wrote:

> Hi list,
>
> According to http://clang.llvm.org/get_started.html:
>
> You can update your toplevel LLVM project and all (possibly  
> unrelated) projects inside it with make update. This will run svn  
> update on all subdirectories related to subversion.

Someone on IRC was claiming that this was because tools/clang was in  
the svnignore of the llvm tree.  This doesn't make a lot of sense to  
me, but I don't know how to fix it.  If some else does, please go for  
it.

-Chris

>
> However after following the check out instructions, I observed the  
> following behavior:
>
> gk ~/external/llvm > make update
> svn  update /Users/gk/external/llvm
> U    /Users/gk/external/llvm/test/CodeGen/X86/break-sse-dep.ll
> ... (more U ... lines)
> Updated to revision 91929.
>
> gk ~/external/llvm > cd tools/clang
> gk ~/external/llvm/tools/clang > svn update
> U    test/Lexer/char-escapes.c
> ... (many more U ... lines)
> Updated to revision 91930.
>
> gk ~/external/llvm/tools/clang > cd ../..
> gk ~/external/llvm > svn update
> At revision 91930.
>
>
> 'make update' did not appear to run 'svn update' for the tools/clang  
> directory. Otherwise I would see "svn update /Users/gk/external/llvm/
> tools/clang" output, right? I realize that this looks a little  
> ambiguous because of the revision numbers 91929 and 91930, but I  
> don't think that's the issue; there were hundreds of files updated  
> in the clang tree, which I doubt were committed in the interim  
> between commands.
>
> Does 'make update' work as advertised for others?
>
> Thank you,
>
> George
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: make update not updating clang svn?

Filipe Cabecinhas
Hi

I didn't see tools/clang in svn ignore...

Sometime ago I tracked that problem down to svn info... But now I tried
to reproduce and make update worked... Weird.

Regards,

   Filipe


On 12/22/09 22:58, Chris Lattner wrote:

>
> On Dec 22, 2009, at 2:53 PM, George King wrote:
>
>> Hi list,
>>
>> According to http://clang.llvm.org/get_started.html:
>>
>> You can update your toplevel LLVM project and all (possibly
>> unrelated) projects inside it with make update. This will run svn
>> update on all subdirectories related to subversion.
>
> Someone on IRC was claiming that this was because tools/clang was in
> the svnignore of the llvm tree.  This doesn't make a lot of sense to
> me, but I don't know how to fix it.  If some else does, please go for
> it.
>
> -Chris
>
>>
>> However after following the check out instructions, I observed the
>> following behavior:
>>
>> gk ~/external/llvm>  make update
>> svn  update /Users/gk/external/llvm
>> U    /Users/gk/external/llvm/test/CodeGen/X86/break-sse-dep.ll
>> ... (more U ... lines)
>> Updated to revision 91929.
>>
>> gk ~/external/llvm>  cd tools/clang
>> gk ~/external/llvm/tools/clang>  svn update
>> U    test/Lexer/char-escapes.c
>> ... (many more U ... lines)
>> Updated to revision 91930.
>>
>> gk ~/external/llvm/tools/clang>  cd ../..
>> gk ~/external/llvm>  svn update
>> At revision 91930.
>>
>>
>> 'make update' did not appear to run 'svn update' for the tools/clang
>> directory. Otherwise I would see "svn update /Users/gk/external/llvm/
>> tools/clang" output, right? I realize that this looks a little
>> ambiguous because of the revision numbers 91929 and 91930, but I
>> don't think that's the issue; there were hundreds of files updated
>> in the clang tree, which I doubt were committed in the interim
>> between commands.
>>
>> Does 'make update' work as advertised for others?
>>
>> Thank you,
>>
>> George
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: make update not updating clang svn?

George King
>>> 'make update' did not appear to run 'svn update' for the tools/clang
>>> directory.

> Sometime ago I tracked that problem down to svn info... But now I tried to reproduce and make update worked... Weird.

I took a look at the llvm Makefile.  Here is the relevant part:

SVN = svn
SVN-UPDATE-OPTIONS =
AWK = awk
SUB-SVN-DIRS = $(AWK) '/\?\ \ \ \ \ \ / {print $$2}'   \
                | LC_ALL=C xargs $(SVN) info 2>/dev/null \
                | $(AWK) '/Path:\ / {print $$2}'

update:
        $(SVN) $(SVN-UPDATE-OPTIONS) update $(LLVM_SRC_ROOT)
        @ $(SVN) status $(LLVM_SRC_ROOT) | $(SUB-SVN-DIRS) | xargs $(SVN) $(SVN-UPDATE-OPTIONS) update


My understanding of this pipeline is as follows:
  run 'svn status' on llvm
  for every line that matches something in awk,
  run 'svn info'
  pull out the path value with awk
  run 'svn update' on that
 
When I run 'svn status' I get no output, so the rest of the chain does nothing. This explains why it works for the clang developers most of the time: any time you make a local change, then the clang directory gets picked up.

This all seems a bit complicated for the task at hand. The least confusing solution is to just list the sub repositories; how many sub repositories are there? considering that clang is mentioned explicitly in other parts of the makefile, this seems reasonable. Pasted below is a diff to Makefile.

Otherwise, I think the initial 'svn status' should be changed to something along the lines of:

 find $(LLVM_SRC_ROOT) -type d  -maxdepth 2 ! -regex '.*/\...*'

The regex at the end excludes hidden directories like .svn. I tried svn ls -R, and it was painfully slow. Unfortunately, find does not completely work either. The following bit yields duplicate paths, and then bombs out on the Debug/lib directory:
find . -type d -maxdepth 2 ! -regex '.*/\..*' | xargs svn info

Hope this helps,

george


Index: Makefile
===================================================================
--- Makefile (revision 92033)
+++ Makefile (working copy)
@@ -207,14 +207,10 @@
 
 SVN = svn
 SVN-UPDATE-OPTIONS =
-AWK = awk
-SUB-SVN-DIRS = $(AWK) '/\?\ \ \ \ \ \ / {print $$2}'   \
- | LC_ALL=C xargs $(SVN) info 2>/dev/null \
- | $(AWK) '/Path:\ / {print $$2}'
 
 update:
  $(SVN) $(SVN-UPDATE-OPTIONS) update $(LLVM_SRC_ROOT)
- @ $(SVN) status $(LLVM_SRC_ROOT) | $(SUB-SVN-DIRS) | xargs $(SVN) $(SVN-UPDATE-OPTIONS) update
+ $(SVN) $(SVN-UPDATE-OPTIONS) update $(LLVM_SRC_ROOT)/tools/clang
 
 happiness: update all check unittests
 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Pointers to Overloaded C Functions

George King
In reply to this post by Filipe Cabecinhas
I am experimenting with clang's overloaded C functions, and I can't figure out how to get a pointer to an overloaded function.

test program:

#define OL __attribute__((overloadable))

void OL a(int x) { printf("i: %d\n", x); }
void OL a(float x) { printf("f: %f\n", x); }

int main(int argc, char** argv)
{
    a(1);
    a(1.0f);
   
    void(*a_i_ptr)(int) = a;
    void(*a_f_ptr)(float) = a;
   
    return 0;
}


compiler output:

> clang test_ol.c
test_ol.c:25:11: error: incompatible type initializing '<overloaded function type>', expected
      'void (*)(int)'
    void(*a_i_ptr)(int) = a;
          ^               ~
test_ol.c:26:11: error: incompatible type initializing '<overloaded function type>', expected
      'void (*)(float)'
    void(*a_f_ptr)(float) = a;
          ^                 ~
2 diagnostics generated.


If I change the name of one of the functions, then it compiles; clang appears well aware of the syntactic ambiguity. Is there a more specific syntax to specify which function I'm  referring to?

Something like "void(*a_i_ptr)(int) = a(int);" makes sense to me, but I imagine that it's a stretch as far as extending the language goes.

Thanks,

George


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pointers to Overloaded C Functions

Eli Friedman
On Mon, Jan 4, 2010 at 9:53 AM, George King <[hidden email]> wrote:

> I am experimenting with clang's overloaded C functions, and I can't figure out how to get a pointer to an overloaded function.
>
> test program:
>
> #define OL __attribute__((overloadable))
>
> void OL a(int x) { printf("i: %d\n", x); }
> void OL a(float x) { printf("f: %f\n", x); }
>
> int main(int argc, char** argv)
> {
>    a(1);
>    a(1.0f);
>
>    void(*a_i_ptr)(int) = a;
>    void(*a_f_ptr)(float) = a;
>
>    return 0;
> }
>
>
> compiler output:
>
>> clang test_ol.c
> test_ol.c:25:11: error: incompatible type initializing '<overloaded function type>', expected
>      'void (*)(int)'
>    void(*a_i_ptr)(int) = a;
>          ^               ~
> test_ol.c:26:11: error: incompatible type initializing '<overloaded function type>', expected
>      'void (*)(float)'
>    void(*a_f_ptr)(float) = a;
>          ^                 ~
> 2 diagnostics generated.
>
>
> If I change the name of one of the functions, then it compiles; clang appears well aware of the syntactic ambiguity. Is there a more specific syntax to specify which function I'm  referring to?
>
> Something like "void(*a_i_ptr)(int) = a(int);" makes sense to me, but I imagine that it's a stretch as far as extending the language goes.

Umm, interesting... I think it's just some missing logic in the code
for assignments in C.  I don't think anyone considered that someone
might write code like that.  You have the syntax right; the given code
works properly if clang is in C++ mode.

-Eli

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pointers to Overloaded C Functions

Douglas Gregor

On Jan 4, 2010, at 10:13 AM, Eli Friedman wrote:

> On Mon, Jan 4, 2010 at 9:53 AM, George King <[hidden email]>  
> wrote:
>> I am experimenting with clang's overloaded C functions, and I can't  
>> figure out how to get a pointer to an overloaded function.
>>
>> test program:
>>
>> #define OL __attribute__((overloadable))
>>
>> void OL a(int x) { printf("i: %d\n", x); }
>> void OL a(float x) { printf("f: %f\n", x); }
>>
>> int main(int argc, char** argv)
>> {
>>    a(1);
>>    a(1.0f);
>>
>>    void(*a_i_ptr)(int) = a;
>>    void(*a_f_ptr)(float) = a;
>>
>>    return 0;
>> }
>>
>>
>> compiler output:
>>
>>> clang test_ol.c
>> test_ol.c:25:11: error: incompatible type initializing '<overloaded  
>> function type>', expected
>>      'void (*)(int)'
>>    void(*a_i_ptr)(int) = a;
>>          ^               ~
>> test_ol.c:26:11: error: incompatible type initializing '<overloaded  
>> function type>', expected
>>      'void (*)(float)'
>>    void(*a_f_ptr)(float) = a;
>>          ^                 ~
>> 2 diagnostics generated.
>>
>>
>> If I change the name of one of the functions, then it compiles;  
>> clang appears well aware of the syntactic ambiguity. Is there a  
>> more specific syntax to specify which function I'm  referring to?
>>
>> Something like "void(*a_i_ptr)(int) = a(int);" makes sense to me,  
>> but I imagine that it's a stretch as far as extending the language  
>> goes.
>
> Umm, interesting... I think it's just some missing logic in the code
> for assignments in C.  I don't think anyone considered that someone
> might write code like that.

I don't know if we even want to support that kind of code... the  
"overloadable" attribute is narrowly defined to help support certain  
weird C99-isms (*cough* tgmath.h *cough*). We don't really want to  
encourage widespread use, since it is likely to never be portable.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pointers to Overloaded C Functions

George King
>>> I am experimenting with clang's overloaded C functions, and I can't figure out how to get a pointer to an overloaded function.

>> Umm, interesting... I think it's just some missing logic in the code for assignments in C.  I don't think anyone considered that someone might write code like that.
>
> I don't know if we even want to support that kind of code... the "overloadable" attribute is narrowly defined to help support certain weird C99-isms (*cough* tgmath.h *cough*). We don't really want to encourage widespread use, since it is likely to never be portable.

Thanks for your replies, and sorry for taking so long to respond. If it is valid to take the address of an overloaded function in C++, then it seems reasonable to expect that one could do so with the overload feature in C too. I understand that this is not a portable feature, but that is no reason not fully implement it (in the sense of completeness relative to C++). I certainly don't expect this to be a priority for anyone; nevertheless, it seems weird to me that you could write functions but not be able to get their addresses due to syntactic limitations.

This is, at the moment, an academic inquiry on my part, but for the record I do think that overloaded functions are a great extension, and people like me (mac developers) do have the luxury of writing single platform code. My primary interest in overloads is that they can simplify generated C code, which I use as a simpler alternative to C++ templates.

Thank again,

George
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pointers to Overloaded C Functions

Daniel Dunbar
In reply to this post by Douglas Gregor
On Mon, Jan 4, 2010 at 10:15 AM, Douglas Gregor <[hidden email]> wrote:

>
> On Jan 4, 2010, at 10:13 AM, Eli Friedman wrote:
>
>> On Mon, Jan 4, 2010 at 9:53 AM, George King <[hidden email]>
>> wrote:
>>> I am experimenting with clang's overloaded C functions, and I can't
>>> figure out how to get a pointer to an overloaded function.
>>>
>>> test program:
>>>
>>> #define OL __attribute__((overloadable))
>>>
>>> void OL a(int x) { printf("i: %d\n", x); }
>>> void OL a(float x) { printf("f: %f\n", x); }
>>>
>>> int main(int argc, char** argv)
>>> {
>>>    a(1);
>>>    a(1.0f);
>>>
>>>    void(*a_i_ptr)(int) = a;
>>>    void(*a_f_ptr)(float) = a;
>>>
>>>    return 0;
>>> }
>>>
>>>
>>> compiler output:
>>>
>>>> clang test_ol.c
>>> test_ol.c:25:11: error: incompatible type initializing '<overloaded
>>> function type>', expected
>>>      'void (*)(int)'
>>>    void(*a_i_ptr)(int) = a;
>>>          ^               ~
>>> test_ol.c:26:11: error: incompatible type initializing '<overloaded
>>> function type>', expected
>>>      'void (*)(float)'
>>>    void(*a_f_ptr)(float) = a;
>>>          ^                 ~
>>> 2 diagnostics generated.
>>>
>>>
>>> If I change the name of one of the functions, then it compiles;
>>> clang appears well aware of the syntactic ambiguity. Is there a
>>> more specific syntax to specify which function I'm  referring to?
>>>
>>> Something like "void(*a_i_ptr)(int) = a(int);" makes sense to me,
>>> but I imagine that it's a stretch as far as extending the language
>>> goes.
>>
>> Umm, interesting... I think it's just some missing logic in the code
>> for assignments in C.  I don't think anyone considered that someone
>> might write code like that.
>
> I don't know if we even want to support that kind of code... the
> "overloadable" attribute is narrowly defined to help support certain
> weird C99-isms (*cough* tgmath.h *cough*). We don't really want to
> encourage widespread use, since it is likely to never be portable.

If we really don't want to encourage use, we should find a way to
disable (or at least warn) on the attribute outside of clang specific
headers. Otherwise, it will almost inevitably become a compiler
feature.

It would be nice to do the same thing for at least some __builtin...s,
actually, so that any use outside of clang's private headers triggered
a warning.

 - Daniel

>        - Doug
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pointers to Overloaded C Functions

George King
> If we really don't want to encourage use, we should find a way to
> disable (or at least warn) on the attribute outside of clang specific
> headers. Otherwise, it will almost inevitably become a compiler
> feature.

if you really want to discourage use, take it off the website :)

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pointers to Overloaded C Functions

Douglas Gregor
In reply to this post by George King

On Jan 11, 2010, at 9:59 PM, George King <[hidden email]> wrote:

>>>> I am experimenting with clang's overloaded C functions, and I  
>>>> can't figure out how to get a pointer to an overloaded function.
>
>>> Umm, interesting... I think it's just some missing logic in the  
>>> code for assignments in C.  I don't think anyone considered that  
>>> someone might write code like that.
>>
>> I don't know if we even want to support that kind of code... the  
>> "overloadable" attribute is narrowly defined to help support  
>> certain weird C99-isms (*cough* tgmath.h *cough*). We don't really  
>> want to encourage widespread use, since it is likely to never be  
>> portable.
>
> Thanks for your replies, and sorry for taking so long to respond. If  
> it is valid to take the address of an overloaded function in C++,  
> then it seems reasonable to expect that one could do so with the  
> overload feature in C too. I understand that this is not a portable  
> feature, but that is no reason not fully implement it (in the sense  
> of completeness relative to C++).

Well, it's a reason not to fully implement it because a better  
implementation encourages more use.

> I certainly don't expect this to be a priority for anyone;  
> nevertheless, it seems weird to me that you could write functions  
> but not be able to get their addresses due to syntactic limitations.

I would not oppose patches that make overloadable functions more  
useful in C. But you won't see me jumping to implement them, either.

   - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev