ATS and CLANG

[gmhwxi]

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 :(

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

> Please brace yourself for warning messages when using clang to bootstrap
> ATS2 :(

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. :)

[Raoul Duke]

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

[Barry Schwartz]

I said:
> > 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. :)

Raoul Duke <rao...@gmail.com> said:
> 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.

A Shepherd-boy, who watched a flock of sheep near a village, brought
out the villagers three or four times by crying out, "Wolf! Wolf!" and
when his neighbors came to help him, laughed at them for their
pains. The Wolf, however, did truly come at last. The Shepherd-boy,
now really alarmed, shouted in an agony of terror: "Pray, do come and
help me; the Wolf is killing the sheep"; but no one paid any heed to
his cries, nor rendered any assistance. The Wolf, having no cause of
fear, at his leisure lacerated or destroyed the whole flock.

There is no believing a liar, even when he speaks the truth.

[Raoul Duke]

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.

[Greg Fitzgerald]

> 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,
Greg

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

[gmhwxi]

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.

[Barry Schwartz]

Greg Fitzgerald <gar...@gmail.com> skribis:

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

I’m saying I don’t like Clang’s C compiler’s warnings; that it gives
so many about so many different things that it cheapens the very idea
of a warning. False positives have nothing to do with it. I am
entitled to an opinion. :)

It was also a roundabout way of saying I don’t think ATS should do
much about it, since there are better ways to spend one’s time than
‘fix’ problems that are not an actual problem.

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

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

You know how compilers like GCC suggest putting parens around = in a
predicate. My advice is DON’T DO THAT AT ALL. DON’T EVEN THINK ABOUT
IT! BURN YOUR COPY OF K&R that says to do that! But, anyway, imagine
my consternation when Clang warned me that there were unnecessary
parens around an == and to consider removing them! Ostensibly trying
to protect me from typing == when I meant =.

When the warning is that you used clarifying parentheses and ought to
remove them, and this is a default setting of a systemwide compiler,
and is just the latest example, I get testy. :)

[Greg Fitzgerald]

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,
Greg

> https://groups.google.com/d/msgid/ats-lang-users/aa0f0de6-3fdb-42b1-bafa-9e63b42305ee%40googlegroups.com.

[Hongwei Xi]

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?

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.

[Barry Schwartz]

Hongwei Xi <gmh...@gmail.com> skribis:

> I am using clang 3.0.
>
> However, I think this is really an issue of fundamental limitation.

To some degree it is an example of why I object to what I consider
excessive eagerness to give warnings. Eventually the warnings start to
snowball, when the warning is that I may have incorrectly written code
that was meant to silence another warning, that latter warning being
meant to help me correctly write bad code.

[Greg Fitzgerald]

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?

> I am using clang 3.0.

Well that's not fair. What's preventing you from upgrading to at least 3.4?

-Greg

[gmhwxi]

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!

 

[Greg Fitzgerald]

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

-Greg

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

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

> 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).

Yeah, even a function declared ‘pure’, where that means it always
returns the same thing and has no ‘observable’ side effects, may need
to be evaluated at least once. This shows up in my own code, where I
sometimes use gcc’s attribute(pure) for functions that are
one-time-initialized using atomic_ops.