public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
Date: Tue, 03 Nov 2020 07:18:30 +0000	[thread overview]
Message-ID: <bug-97320-4-Egdy6g9auz@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97320-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org
             Status|RESOLVED                    |NEW
         Resolution|DUPLICATE                   |---
           Severity|normal                      |enhancement
         Depends on|                            |90302

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
It's not an exact duplicate of PR 94978; that bug is about
a false positive without -Wdo-subscript, whereas this one is
about a false positive with -Wdo-subscript.

The reason why this is rather difficult to resolve is one
of translation phases.

In the gfortran front end, we create a syntax tree from the
Fortran source code.  On the basis of that syntax tree (where
we still know a lot about the langauge) we issue that warning.

The next step is conversion to an intermediate language, which
gets handed to the main part of gcc for further processing
(known as the "middle end").

It is the middle which is does most of the optimizations, and
which has the tools to do so.  In this particular instance, we
would need "range propagation" (where the compiler can infer the
range of variables from previous statements).  We don't do that
in the front end, because a) it would be a major piece of work, and
b) it would duplicate a lot of what the middle end already does.

The most elegant solution would be support from the middle and
back end to put in a pseudo statement, like a __bulitin_warning
"function".

Code like

    integer :: a(12)
    do i=1,10
       a(i-1) = 1

could then be annotated like

   do i=1,10
     if (0 < lbound(a)) call __builtin_warning ("index out of bounds")
     if (9 > ubound(a)) call __builtin_warning ("index out of bounds")
     a(i-1) = 1

and if the compiler could not prove that these statements get removed
by dead code elimination, it would issue the warning in the final phase of
translation.

This would pretty much eliminate false positives, and would be
far superior than what we currently do.

Unfortunately, this is a part of a compiler with which I am almost
totally unfamiliar, so I cannot help there. Some preliminary work
has been done (see PR 90302), but I don't know how far it has
progressed in the meantime.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302
[Bug 90302] Implement __builtin_warning

      parent reply	other threads:[~2020-11-03  7:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 13:17 [Bug fortran/97320] New: " trnka at scm dot com
2020-10-07 13:31 ` [Bug fortran/97320] " dominiq at lps dot ens.fr
2020-11-02 15:56 ` Jacques.Lebourlot at obspm dot fr
2020-11-02 17:03 ` kargl at gcc dot gnu.org
2020-11-02 17:09 ` Jacques.Lebourlot at obspm dot fr
2020-11-02 20:11 ` anlauf at gcc dot gnu.org
2020-11-03  7:18 ` tkoenig at gcc dot gnu.org [this message]

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=bug-97320-4-Egdy6g9auz@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).