Using clang to bootstrap ATS is significantly faster than gcc:
cd ${PATSHOME}/src/CBOOT
time make CC=clang >& /dev/null:
real 0m31.296s
user 0m25.702s
sys 0m4.124s
cd ${PATSHOME}/src/CBOOT
time make CC=gcc >& /dev/null:
real 0m40.822s
user 0m34.170s
sys 0m4.168s
The compiler (patsopt) generated by clang takes about the same time as the
one by gcc does.
Please brace yourself for warning messages when using clang to bootstrap
ATS2 
I am using clang 3.0.
However, I think this is really an issue of fundamental limitation.
Suppose that you replace
__strcmp_gc(“”, “-v”, 2);
with
__strcmp_gc(“”, “-v”, strlen(“-v”));
For instance, one may define strcmp as follows:
#define strcmp(s1, s2) __strcmp_gc(s1, s2, strlen(s2))
Clang must evaluate strlen(“-v”) to get 2. But what would be a good
criterion to
determine whether strlen(“-v”) should or should not be evaluated at
compile-time?On Thu, Dec 18, 2014 at 7:38 PM, Greg Fitzgerald gar...@gmail.com wrote:
What version of clang are you using? I was not able to reproduce the
warning you described. I’m using clang 3.5:No warning:
__strcmp_gc(“”, “”, 0);
__strcmp_gc(“”, “-v”, 2);Warning (as expected):
__strcmp_gc(“”, “”, 1);
__strcmp_gc(“”, “-v”, 3);Thanks,
GregOn Tue, Dec 16, 2014 at 6:59 PM, gmhwxi gmh...@gmail.com wrote:
I chased a couple of warnings issued by clang and realized that
they seem to be clear indication of the limitation of clang right now.
For instance, in the following declaration of foo, one may want to state
that n should be the size of the array A:extern void foo (char *A, size_t n);
But this information cannot be passed to clang (or I don’t know how to do
it).Here is a macro defined in /usr/include/x86_64-linux-gnu/bits/string2.h:
define __strcmp_gc(s1, s2, l2) \
(extension ({ __const unsigned char *__s1 =
(__const unsigned char *) (__const char *) (s1);
register int __result =
__s1[0] - ((__const unsigned char *)
(__const char *) (s2))[0];
if (l2 > 0 && __result == 0)
{
__result = (__s1[1]
- ((__const unsigned char *)
(__const char *) (s2))[1]);
if (l2 > 1 && __result == 0)
{
__result =
(__s1[2] - ((__const unsigned char *)
(__const char *) (s2))[2]);
if (l2 > 2 && __result == 0)
__result =
(__s1[3]
- ((__const unsigned char *)
(__const char *) (s2))[3]);
}
}
__result; }))If you do __strcmp_gc(s1, “-v”, 2), clang warns that s2[3] in the code
may
be out-of-bounds.
However, if you read the code carefully, you notice that s2[3] is never
reached if the length of s2 is less than or equal to 2.
My guess is that clang issues the warning because it does not know l2 in
__strcmp_gc(s1, s2, l2) is required to be the length
of s2.Chasing this kind of warnings is very time-consuming. Reward? Not so
sure.On Tuesday, December 16, 2014 8:58:56 PM UTC-5, Greg Fitzgerald wrote:
I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the samePlease don’t do that. You’re telling one open source compiler
community to ignore the [automated] advise of another. We’re all on
the same team here. If you feel strongly that a warning message
reported by clang is a false positive, please shoot me an email. I’d
be happy to open a discussion with the LLVM community on behalf of the
ATS community.Thanks,
GregOn Tue, Dec 16, 2014 at 4:17 PM, Barry Schwartz chem...@chemoelectric.org wrote:
gmhwxi gmh...@gmail.com skribis:
Please brace yourself for warning messages when using clang to
bootstrap
ATS2I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the same. I don’t want to legitimize that kind
of uncontrolled yelping as if by a barking dog.–
You received this message because you are subscribed to the Google
Groups “ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ats-lang...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visithttps://groups.google.com/d/msgid/ats-lang-users/20141217001727.GA16360%40crud
.–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/CAFLa5WM_MeCr-eP_-j-_Urd3B0pTrvuCPXLv7grWfAiMahKSjg%40mail.gmail.com
.
I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the same
Please don’t do that. You’re telling one open source compiler
community to ignore the [automated] advise of another. We’re all on
the same team here. If you feel strongly that a warning message
reported by clang is a false positive, please shoot me an email. I’d
be happy to open a discussion with the LLVM community on behalf of the
ATS community.
Thanks,
GregOn Tue, Dec 16, 2014 at 4:17 PM, Barry Schwartz chemoe...@chemoelectric.org wrote:
gmhwxi gmh...@gmail.com skribis:
Please brace yourself for warning messages when using clang to bootstrap
ATS2I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the same. I don’t want to legitimize that kind
of uncontrolled yelping as if by a barking dog.–
You received this message because you are subscribed to the Google Groups “ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/20141217001727.GA16360%40crud.
I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the same. I don’t want to legitimize that kind
of uncontrolled yelping as if by a barking dog.
oh, and here i was thinking almost the exact opposite. 
i’m tired
of getting somebody else’s project and trying to install it and seeing
a zillion warnings. it just seems like an indictment of SOMETHING,
SOMEWHERE.
yeah, i understand the deal with false positives in static checkers,
believe me. but i do not then think static checkers are inherently
evil. so i think if there is a problem it must lie in the ones we have
and use today vs. the ones we should be using, perhaps. is it the case
that the compilers you run your code through that spit out warnings
are really mostly wrong? in my experience there’s a lot of the
warnings that are valid, if not earth-shatteringly-dangerous if left
unfixed.
I chased a couple of warnings issued by clang and realized that
they seem to be clear indication of the limitation of clang right now.
For instance, in the following declaration of foo, one may want to state
that n should be the size of the array A:
extern void foo (char *A, size_t n);
But this information cannot be passed to clang (or I don’t know how to do
it).
Here is a macro defined in /usr/include/x86_64-linux-gnu/bits/string2.h:
(extension ({ __const unsigned char *__s1 =
(__const unsigned char *) (__const char *) (s1);
register int __result =
__s1[0] - ((__const unsigned char *)
(__const char *) (s2))[0];
if (l2 > 0 && __result == 0)
{
__result = (__s1[1]
- ((__const unsigned char *)
(__const char *) (s2))[1]);
if (l2 > 1 && __result == 0)
{
__result =
(__s1[2] - ((__const unsigned char *)
(__const char *) (s2))[2]);
if (l2 > 2 && __result == 0)
__result =
(__s1[3]
- ((__const unsigned char *)
(__const char *) (s2))[3]);
}
}
__result; }))
If you do __strcmp_gc(s1, “-v”, 2), clang warns that s2[3] in the code may
be out-of-bounds.
However, if you read the code carefully, you notice that s2[3] is never
reached if the length of s2 is less than or equal to 2.
My guess is that clang issues the warning because it does not know l2 in
__strcmp_gc(s1, s2, l2) is required to be the length
of s2.
Chasing this kind of warnings is very time-consuming. Reward? Not so sure.On Tuesday, December 16, 2014 8:58:56 PM UTC-5, Greg Fitzgerald wrote:
I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the samePlease don’t do that. You’re telling one open source compiler
community to ignore the [automated] advise of another. We’re all on
the same team here. If you feel strongly that a warning message
reported by clang is a false positive, please shoot me an email. I’d
be happy to open a discussion with the LLVM community on behalf of the
ATS community.Thanks,
GregOn Tue, Dec 16, 2014 at 4:17 PM, Barry Schwartz <chem...@chemoelectric.org <javascript:>> wrote:
gmhwxi <gmh...@gmail.com <javascript:>> skribis:
Please brace yourself for warning messages when using clang to
bootstrap
ATS2I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the same. I don’t want to legitimize that kind
of uncontrolled yelping as if by a barking dog.–
You received this message because you are subscribed to the Google
Groups “ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ats-lang...@googlegroups.com <javascript:>.
To post to this group, send email to ats-l...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/20141217001727.GA16360%40crud.
Clang must evaluate strlen(“-v”) to get 2. But what would be a good criterion to
determine whether strlen(“-v”) should or should not be evaluated at compile-time?
I’ve always assumed what could be evaluated at compile-time should be
evaluated at compile-time. no?
I am using clang 3.0.
Well that’s not fair. What’s preventing you from upgrading to at least 3.4?
-Greg
Clang must evaluate strlen(“-v”) to get 2. But what would be a good
criterion to
determine whether strlen(“-v”) should or should not be evaluated at
compile-time?I’ve always assumed what could be evaluated at compile-time should be
evaluated at compile-time. no?
However, to determine what could be evaluated at compile-time is
non-trivial at all.
For instance, functions may be nonterminating or they may create effects.
This is
a big issue in the context of typechecking dependent types (in a language
like Idris).
I am using clang 3.0.
Well that’s not fair. What’s preventing you from upgrading to at least
3.4?
I went ahead to try clang 3.2, clang 3.4 and clang 3.5.
It is pretty clear to me that clang is becoming less eager to report
“warnings”.
For clang 3.2 reported tons of stuff like this:
WARNING: While resolving call to function ‘v1aldec_tr_102’ arguments were
dropped!
WARNING: While resolving call to function ‘f_71’ arguments were dropped!
WARNING: While resolving call to function ‘f_41’ arguments were dropped!
WARNING: While resolving call to function
‘_2home_2hwxi_2research_2Postiats_2git_2src_2pats_trans2_2esats__d1ecl_tr’
arguments were dropped!
WARNING: While resolving call to function ‘f_4’ arguments were dropped!
WARNING: While resolving call to function ‘s1rtdef_tr_20’ arguments were
dropped!
WARNING: While resolving call to function ‘s1tacst_tr_22’ arguments were
dropped!
WARNING: While resolving call to function ‘__ats_fun_33’ arguments were
dropped!
WARNING: While resolving call to function ‘f2_35’ arguments were dropped!
WARNING: While resolving call to function ‘f1_34’ arguments were dropped!
WARNING: While resolving call to function ‘m1acarg_tr_91’ arguments were
dropped!
WARNING: While resolving call to function ‘f_93’ arguments were dropped!
WARNING: While resolving call to function ‘f_92’ arguments were dropped!
WARNING: While resolving call to function ‘trans2_env_add_m2acarg_88’
arguments were dropped!
WARNING: While resolving call to function ‘__ats_fun_104’ arguments were
dropped!
WARNING: While resolving call to function ‘v1ardec_tr_108’ arguments were
dropped!
WARNING: While resolving call to function ‘f_110’ arguments were dropped!
WARNING: While resolving call to function ‘prv1ardec_tr_114’ arguments were
dropped!
WARNING: While resolving call to function ‘f_116’ arguments were dropped!
WARNING: While resolving call to function
‘_2home_2hwxi_2research_2Postiats_2git_2src_2pats_trans2_2esats__d1ecl_tr’
arguments were dropped!
WARNING: While resolving call to function ‘f_93’ arguments were dropped!
WARNING: While resolving call to function ‘f_92’ arguments were dropped!
WARNING: While resolving call to function ‘f1_34’ arguments were dropped!
Obviously (to me), no arguments were ever dropped in these calls for
otherwise my code would have definitely crashed.
Now I think clang (3.5) is very similar to gcc in terms of the eagerness to
report warnings.
In general, the warnings issued on manually written code are quite helpful.
Those issued on code generated by the
ATS compiler are somewhat an annoyance. Anyways, I jumped through all kinds
of hoops in the past two days to
make sure that the C code generated from ATS2 source can now be cleanly
compiled by clang 3.5.
Cheers!
Anyways, I jumped through all kinds of hoops in the past two days to make
sure that the C code generated from ATS2 source can now be cleanly
compiled by clang 3.5.
Thanks for doing that! Now that you’re up to the latest clang, it
would be interesting to compile and run your test suite with “-g
-fsanitize=address” and/or “-fsanitize=undefined” to see if there are
any memory violations or undefined behavior hiding in the generated
code. If there is, it would be impressive to see the patches you make
to the ATS2 user code to eliminate the whole class of errors.
-GregOn Fri, Dec 19, 2014 at 3:52 PM, gmhwxi gmh...@gmail.com wrote:
On Friday, December 19, 2014 1:36:14 AM UTC-5, Greg Fitzgerald wrote:
On Thu, Dec 18, 2014 at 5:30 PM, Hongwei Xi gmh...@gmail.com wrote:
Clang must evaluate strlen(“-v”) to get 2. But what would be a good
criterion to
determine whether strlen(“-v”) should or should not be evaluated at
compile-time?I’ve always assumed what could be evaluated at compile-time should be
evaluated at compile-time. no?However, to determine what could be evaluated at compile-time is non-trivial
at all.
For instance, functions may be nonterminating or they may create effects.
This is
a big issue in the context of typechecking dependent types (in a language
like Idris).I am using clang 3.0.
Well that’s not fair. What’s preventing you from upgrading to at least
3.4?I went ahead to try clang 3.2, clang 3.4 and clang 3.5.
It is pretty clear to me that clang is becoming less eager to report
“warnings”.
For clang 3.2 reported tons of stuff like this:WARNING: While resolving call to function ‘v1aldec_tr_102’ arguments were
dropped!
WARNING: While resolving call to function ‘f_71’ arguments were dropped!
WARNING: While resolving call to function ‘f_41’ arguments were dropped!
WARNING: While resolving call to function
‘_2home_2hwxi_2research_2Postiats_2git_2src_2pats_trans2_2esats__d1ecl_tr’
arguments were dropped!
WARNING: While resolving call to function ‘f_4’ arguments were dropped!
WARNING: While resolving call to function ‘s1rtdef_tr_20’ arguments were
dropped!
WARNING: While resolving call to function ‘s1tacst_tr_22’ arguments were
dropped!
WARNING: While resolving call to function ‘__ats_fun_33’ arguments were
dropped!
WARNING: While resolving call to function ‘f2_35’ arguments were dropped!
WARNING: While resolving call to function ‘f1_34’ arguments were dropped!
WARNING: While resolving call to function ‘m1acarg_tr_91’ arguments were
dropped!
WARNING: While resolving call to function ‘f_93’ arguments were dropped!
WARNING: While resolving call to function ‘f_92’ arguments were dropped!
WARNING: While resolving call to function ‘trans2_env_add_m2acarg_88’
arguments were dropped!
WARNING: While resolving call to function ‘__ats_fun_104’ arguments were
dropped!
WARNING: While resolving call to function ‘v1ardec_tr_108’ arguments were
dropped!
WARNING: While resolving call to function ‘f_110’ arguments were dropped!
WARNING: While resolving call to function ‘prv1ardec_tr_114’ arguments were
dropped!
WARNING: While resolving call to function ‘f_116’ arguments were dropped!
WARNING: While resolving call to function
‘_2home_2hwxi_2research_2Postiats_2git_2src_2pats_trans2_2esats__d1ecl_tr’
arguments were dropped!
WARNING: While resolving call to function ‘f_93’ arguments were dropped!
WARNING: While resolving call to function ‘f_92’ arguments were dropped!
WARNING: While resolving call to function ‘f1_34’ arguments were dropped!Obviously (to me), no arguments were ever dropped in these calls for
otherwise my code would have definitely crashed.Now I think clang (3.5) is very similar to gcc in terms of the eagerness to
report warnings.In general, the warnings issued on manually written code are quite helpful.
Those issued on code generated by the
ATS compiler are somewhat an annoyance. Anyways, I jumped through all kinds
of hoops in the past two days to
make sure that the C code generated from ATS2 source can now be cleanly
compiled by clang 3.5.Cheers!
–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/daa729b1-1a60-44e6-8eed-b053a1a6b412%40googlegroups.com.
What version of clang are you using? I was not able to reproduce the
warning you described. I’m using clang 3.5:
No warning:
__strcmp_gc(“”, “”, 0);
__strcmp_gc(“”, “-v”, 2);
Warning (as expected):
__strcmp_gc(“”, “”, 1);
__strcmp_gc(“”, “-v”, 3);
Thanks,
GregOn Tue, Dec 16, 2014 at 6:59 PM, gmhwxi gmh...@gmail.com wrote:
I chased a couple of warnings issued by clang and realized that
they seem to be clear indication of the limitation of clang right now.
For instance, in the following declaration of foo, one may want to state
that n should be the size of the array A:extern void foo (char *A, size_t n);
But this information cannot be passed to clang (or I don’t know how to do
it).Here is a macro defined in /usr/include/x86_64-linux-gnu/bits/string2.h:
define __strcmp_gc(s1, s2, l2) \
(extension ({ __const unsigned char *__s1 =
(__const unsigned char *) (__const char *) (s1);
register int __result =
__s1[0] - ((__const unsigned char *)
(__const char *) (s2))[0];
if (l2 > 0 && __result == 0)
{
__result = (__s1[1]
- ((__const unsigned char *)
(__const char *) (s2))[1]);
if (l2 > 1 && __result == 0)
{
__result =
(__s1[2] - ((__const unsigned char *)
(__const char *) (s2))[2]);
if (l2 > 2 && __result == 0)
__result =
(__s1[3]
- ((__const unsigned char *)
(__const char *) (s2))[3]);
}
}
__result; }))If you do __strcmp_gc(s1, “-v”, 2), clang warns that s2[3] in the code may
be out-of-bounds.
However, if you read the code carefully, you notice that s2[3] is never
reached if the length of s2 is less than or equal to 2.
My guess is that clang issues the warning because it does not know l2 in
__strcmp_gc(s1, s2, l2) is required to be the length
of s2.Chasing this kind of warnings is very time-consuming. Reward? Not so sure.
On Tuesday, December 16, 2014 8:58:56 PM UTC-5, Greg Fitzgerald wrote:
I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the samePlease don’t do that. You’re telling one open source compiler
community to ignore the [automated] advise of another. We’re all on
the same team here. If you feel strongly that a warning message
reported by clang is a false positive, please shoot me an email. I’d
be happy to open a discussion with the LLVM community on behalf of the
ATS community.Thanks,
GregOn Tue, Dec 16, 2014 at 4:17 PM, Barry Schwartz chem...@chemoelectric.org wrote:
gmhwxi gmh...@gmail.com skribis:
Please brace yourself for warning messages when using clang to
bootstrap
ATS2I have long since learned to ignore warnings from clang’s C compiler
and suggest others do the same. I don’t want to legitimize that kind
of uncontrolled yelping as if by a barking dog.–
You received this message because you are subscribed to the Google
Groups “ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ats-lang...@googlegroups.com.
To post to this group, send email to ats-l...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/20141217001727.GA16360%40crud.–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/aa0f0de6-3fdb-42b1-bafa-9e63b42305ee%40googlegroups.com.
