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
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
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
'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
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
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
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
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
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
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 
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