[LLVMdev] [RFC] New function attributes for errno-setting functions

Hal Finkel hfinkel at anl.gov
Fri Sep 13 13:37:37 PDT 2013


----- Original Message -----
> On 9/13/2013 2:23 PM, Hal Finkel wrote:
> >
> > Maybe the easiest way would be to insert an intrinsic
> > @llvm.errno.read() whenever errno (as a source token) appears in
> > the source as an rvalue (and do some similar thing when it appears
> > as a lvalue). Thoughts?
> 
> I think the major problem is still with "errno" defined as a
> preprocessor macro, as it may not look like errno by the time the
> front-end sees it. 

That's why I said source token (I meant preprocessor token), but any such solution would not be robust to preprocessed source files, and that seems like a big problem.

> Perhaps some configuration test could preprocess
> something like "var = errno;" and check what's really getting stored
> in
> "var", but it may be unreliable (i.e. not detect all cases).
> 
> I thought a bit more about it and I think we will need to have this
> information to prevent similar problems as the one you mentioned in
> the
> first post.  For example:
> 
>    int fd = open(...);
>    int saved_errno = errno;
>    double s = sqrt(var);
>    if (fd == -1)
>      fprintf(stderr, "error: %d\n", saved_errno);
> 
> 
> With only the information about modifying errno, this code could be
> transformed to
> 
>    int fd = open(...);
>    double s = sqrt(var);
>    int saved_errno = errno;
>    if (fd == -1)
>      fprintf(stderr, "error: %d\n", saved_errno);
> 
> again producing the same situation.

No, I don't think so. If sqrt is not readnone or readonly, then it should potentially alias whatever the errno macro actually expands to (whether it is a global variable, and thread-local variable, a function call, or whatever).

 -Hal

> 
> 
> -K
> 
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list