public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Hans-Peter Nilsson <hp@axis.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno
Date: Tue, 28 Feb 2023 21:25:34 -0500	[thread overview]
Message-ID: <9bc0171b3a54d691324cdaf202f5b1aae0829e7d.camel@redhat.com> (raw)
In-Reply-To: <20230301005937.632A42042E@pchp3.se.axis.com>

On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > From: David Malcolm <dmalcolm@redhat.com>
> > Date: Tue, 28 Feb 2023 14:12:47 -0500
> 
> > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote:
> > > Ok to commit?
> > > -- >8 --
> > > Investigating analyzer tesstsuite errors for cris-elf.  The same
> > > are
> > > seen for pru-elf according to posts to gcc-testresults@.
> > > 
> > > For glibc, errno is #defined as:
> > >  extern int *__errno_location (void) __THROW __attribute_const__;
> > >  # define errno (*__errno_location ())
> > > while for newlib in its default configuration, it's:
> > >  #define errno (*__errno())
> > >  extern int *__errno (void);
> > 
> > We're already handling ___errno (three underscores) for Solaris as
> > of
> > 7c9717fcb5cf94ce1e7ef5c903058adf9980ff28; does it fix the issue if
> > you 
> > add __errno (two underscores) to analyzer/kf.cc's 
> > register_known_functions in an analogous way to that commit?  (i.e.
> > wiring it up to kf_errno_location, "teaching" the analyzer that
> > that
> > function returns a pointer to the "errno region")
> 
> But...there's already "support" for two underscores since
> the commit you quote, so I guess not.  

Is there?  That commit adds support for:
  __error
but not for:
  __errno
unless there's something I'm missing.

> I strongly believe
> "the critical difference is that __attribute__
> ((__const__))" because I indeed proved it by adding it to
> the newlib definition.
> 
> I doubt these tests actually *pass* for OS X, because that
> one looks identical to the newlib definition as quoted in
> that commit (compare to the newlib one I pasted in the quote
> above).
> 
> It looks like that definition was added for good measure
> along with the Solaris definition (that has the
> attribute-const) but never tested.  Sorry, I don't have an
> OS X to test it myself and according to a popular search
> engine(...) nobody has posted gcc-testresults@ for anything
> "apple" since gcc-4.7 era. :(

The comments by Rainer in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807
suggests that it did fix stuff on Solaris and OS X.

Sorry if I'm missing something here, I'm not very familiar with newlib.

Dave

> 
> brgds, H-P
> 
> > 
> > Dave
> > 
> > > 
> > > The critical difference is that __attribute__ ((__const__)),
> > > where glibc says that the caller will see the same value on
> > > all calls (from the same context; read: same thread).  I'm
> > > not sure the absence of __attribute__ ((__const__)) for the
> > > newlib definition is deliberate, but I guess it can.
> > > Either way, without the "const" attribute, it can't be known
> > > that the same location will be returned the next time, so
> > > analyzer-tests that depend the value being known it should
> > > see UNKNOWN rather than TRUE, that's why the deliberate
> > > check for UNKNOWN rather than xfailing the test.
> > > 
> > > For isatty-1.c, it's the same problem, but here it'd be
> > > unweildy with the extra dg-lines, so better just skip it for
> > > newlib targets.
> > > 
> > > testsuite:
> > >         * gcc.dg/analyzer/call-summaries-errno.c: Expect UNKNOWN
> > >         for newlib after having set errno.
> > >         * gcc.dg/analyzer/errno-1.c: Ditto.
> > >         * gcc.dg/analyzer/isatty-1.c: Skip for newlib targets.
> > > ---
> > >  gcc/testsuite/gcc.dg/analyzer/call-summaries-errno.c | 3 ++-
> > >  gcc/testsuite/gcc.dg/analyzer/errno-1.c              | 3 ++-
> > >  gcc/testsuite/gcc.dg/analyzer/isatty-1.c             | 2 +-
> > >  3 files changed, 5 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/gcc/testsuite/gcc.dg/analyzer/call-summaries-errno.c
> > > b/gcc/testsuite/gcc.dg/analyzer/call-summaries-errno.c
> > > index e4333b30bb77..cf4d9f7141e4 100644
> > > --- a/gcc/testsuite/gcc.dg/analyzer/call-summaries-errno.c
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/call-summaries-errno.c
> > > @@ -13,5 +13,6 @@ void test_sets_errno (int y)
> > >    sets_errno (y);
> > >    sets_errno (y);
> > >  
> > > -  __analyzer_eval (errno == y); /* { dg-warning "TRUE" } */  
> > > +  __analyzer_eval (errno == y); /* { dg-warning "TRUE" "errno is
> > > at
> > > a constant location" { target { ! newlib } } } */
> > > +  /* { dg-warning "UNKNOWN" "errno is not known to be at a
> > > constant
> > > location" { target { newlib } } .-1 } */
> > >  }
> > > diff --git a/gcc/testsuite/gcc.dg/analyzer/errno-1.c
> > > b/gcc/testsuite/gcc.dg/analyzer/errno-1.c
> > > index 6b9d28c10799..af0cc3d52a36 100644
> > > --- a/gcc/testsuite/gcc.dg/analyzer/errno-1.c
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/errno-1.c
> > > @@ -17,7 +17,8 @@ void test_storing_to_errno (int val)
> > >  {
> > >    __analyzer_eval (errno == val); /* { dg-warning "UNKNOWN" } */
> > >    errno = val;
> > > -  __analyzer_eval (errno == val); /* { dg-warning "TRUE" } */
> > > +  __analyzer_eval (errno == val); /* { dg-warning "TRUE" "errno
> > > is
> > > at a constant location" { target { ! newlib } } } */
> > > +  /* { dg-warning "UNKNOWN" "errno is not known to be at a
> > > constant
> > > location" { target { newlib } } .-1 } */
> > >    external_fn ();
> > >    __analyzer_eval (errno == val); /* { dg-warning "UNKNOWN" }
> > > */  
> > >  }
> > > diff --git a/gcc/testsuite/gcc.dg/analyzer/isatty-1.c
> > > b/gcc/testsuite/gcc.dg/analyzer/isatty-1.c
> > > index 389d2cdf3f18..450a7d71990d 100644
> > > --- a/gcc/testsuite/gcc.dg/analyzer/isatty-1.c
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/isatty-1.c
> > > @@ -1,4 +1,4 @@
> > > -/* { dg-skip-if "" { powerpc*-*-aix* } } */
> > > +/* { dg-skip-if "" { powerpc*-*-aix* || newlib } } */
> > >  
> > >  #include <errno.h>
> > >  #include "analyzer-decls.h"
> > 
> 


  reply	other threads:[~2023-03-01  2:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 18:47 Hans-Peter Nilsson
2023-02-28 19:12 ` David Malcolm
2023-03-01  0:59   ` Hans-Peter Nilsson
2023-03-01  2:25     ` David Malcolm [this message]
2023-03-01  3:01       ` Hans-Peter Nilsson
2023-03-01 13:32         ` David Malcolm
2023-03-01 15:36           ` Hans-Peter Nilsson
2023-03-01 16:02             ` Hans-Peter Nilsson
2023-03-01 23:23               ` Bernhard Reutner-Fischer
2023-03-01 23:54                 ` Hans-Peter Nilsson
2023-03-02  0:37                   ` Bernhard Reutner-Fischer
2023-03-02  0:58                     ` Hans-Peter Nilsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9bc0171b3a54d691324cdaf202f5b1aae0829e7d.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hp@axis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).