llvm dev - Sep 2013 - [LLVMdev] [RFC] New function attributes for errno-setting functions

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

On 9/13/2013 3:37 PM, Hal Finkel wrote:
>
> 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).
I'm not sure about this. How about this:

extern int BLAH;
#define errno BLAH

Then we have

   int fd = open(...);
   int saved_errno = BLAH;
   double s = sqrt(var);

If "sqrt" is "write-only-errno", how would we know that BLAH
should be
aliased with sqrt?  We don't to alias it with every global variable 
(that's what this proposal is trying to address).  We'd need a way to 
associate BLAH with errno, or else we're in the same place as we are now.

-K


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

----- Original Message -----
> On 9/13/2013 3:37 PM, Hal Finkel wrote:
> >
> > 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).
> 
> I'm not sure about this. How about this:
> 
> extern int BLAH;
> #define errno BLAH
> 
> Then we have
> 
>    int fd = open(...);
>    int saved_errno = BLAH;
>    double s = sqrt(var);
> 
> If "sqrt" is "write-only-errno", how would we know that
BLAH should
> be
> aliased with sqrt?  We don't to alias it with every global variable
> (that's what this proposal is trying to address).  We'd need a way
to
> associate BLAH with errno, or else we're in the same place as we are
> now.
No, this is exactly what we do. It needs to be pessimistic in this sense.
"write-only-errno" only helps to prove things about potential alising
with pointers that we *know* can't be errno (like local stack allocations).
Any global might be errno, so that can't count.

 -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