[Bug fortran/54687] Use gcc option machinery for gfortran

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #5)
> > Is there still something missing?
> Note that the options machinery has ways to encode String->Enum options, so
> things like gfc_handle_coarray_option and the handling of OPT_finit_real_
> are redundant (and others).

Pending patch (awaiting ME review):
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01377.html


> Also, my intuition tells me that any explicit handling of optimization
> options that does not use the common machinery such as:
>   if (gfc_option.flag_protect_parens == -1)
>   if (gfc_option.flag_stack_arrays == -1)

Those should be fine as they are completely handled in the FE: The
protect_parens translates into PAREN_EXPR and stack_arrays is also a choice
done by the FE.


> In the future, it would be ideal to have separate option structs for
> FE-specific options, such that not all FEs have to see all options from all
> other FEs. Although moving options from gfc_option_t to the globally
> generated option struct may seem a step backward in that respect, it is
> actually a step forward, since those separated structs should be generated
> directly from the *.opt files.

I concur. I think it also would be useful to support combined options like
Fortran's -ffpe-trap= and -fcheck= or common's -fsanitize=.
>From gcc-bugs-return-470937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 22:40:32 2014
Return-Path: <gcc-bugs-return-470937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 439 invoked by alias); 16 Dec 2014 22:40:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 376 invoked by uid 48); 16 Dec 2014 22:40:25 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/54687] Use gcc option machinery for gfortran
Date: Tue, 16 Dec 2014 22:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-54687-4-s01MSy9CGf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54687-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54687-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg01944.txt.bz2
Content-length: 517

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #8)
> I concur. I think it also would be useful to support combined options like
> Fortran's -ffpe-trap= and -fcheck= or common's -fsanitize=.

Total agreement! 

In my wildest dreams most of invoke.texi would be auto-generated from the opt
files.

Please could you open PRs for such missing features of the common machinery?
>From gcc-bugs-return-470938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 22:57:24 2014
Return-Path: <gcc-bugs-return-470938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16899 invoked by alias); 16 Dec 2014 22:57:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16831 invoked by uid 48); 16 Dec 2014 22:57:18 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64334] New: Common .opt handling: Support flags which take a list of values (-fopt=a,b,c ...)
Date: Tue, 16 Dec 2014 22:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cc blocked
Message-ID: <bug-64334-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg01945.txt.bz2
Content-length: 1102

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

            Bug ID: 64334
           Summary: Common .opt handling: Support flags which take a list
                    of values (-fopt=a,b,c ...)
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: manu at gcc dot gnu.org
            Blocks: 54687

Split off from PR54687.

There are some options which take a list of values – and applies bitwise OR to
the choice.

Example:
  fsanitize=
which takes "address" (SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS),
"kernel-address" (SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS), "thread"
(SANITIZE_THREAD) etc. as argument.

Similarly, in Fortran: -ffpe-trap and -ffpe-summary which take "invalid",
"denormal" etc. or -fcheck= with "all", "bounds", ...

It would be useful it one could extend the current Enum scheme to support this.
>From gcc-bugs-return-470939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 23:04:58 2014
Return-Path: <gcc-bugs-return-470939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23665 invoked by alias); 16 Dec 2014 23:04:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23606 invoked by uid 48); 16 Dec 2014 23:04:53 -0000
From: "tavianator at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work
Date: Tue, 16 Dec 2014 23:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tavianator at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64308-4-cN0JDWcOGN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64308-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64308-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg01946.txt.bz2
Content-length: 961

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd308

--- Comment #3 from Tavian Barnes <tavianator at gmail dot com> ---
@Richard Biener: Yes the range for _16 could be [0, 4294967294].  Why can't VRP
can't assume division by zero doesn't occur?  If it can then it could say
anything mod [a, b] fits in [0, b - 1].

That's a reasonable improvement by itself but it's not enough to optimize this
PR, because to use divl for (ret * b % m), you need (ret * b / m) to fit in [0,
4294967295] as well.  And to know that that, as Marc Glisse suggests, you'd
need symbolic ranges.

@Marc Glisse: Is there currently no support at all for symbolic ranges?  If you
can infer that b < m is an invariant then that's all you need.  Formally it's
something like this:

If x, y, and z are 32-bit unsigned integers, and x <= z || y <= z, then

    (uint64_t)x * (uint64_t)y % z

can be computed with mull and divl because x * y / z is always <= max(x, y)
which fits in 32 bits.