[Bug fortran/44054] New: Handle -Werror, -Werror=, -fdiagnostics-show-option

[Bug fortran/44054] New: Handle -Werror, -Werror=, -fdiagnostics-show-option

[burnus at gcc dot gnu dot org]

The middle end now supports besides -Werror also -Werror=list, where
-Werror=<foo> implies -W<foo>. Additionally, the middle end also annotates via
-fdiagnostics-show-option (enabled by default) the messages with the
warning-flag name in parentheses:

-Wuninitialized  (or, e.g.: -Wall)
  foo.c:4:2: warning: 'j' is used uninitialized in this function
[-Wuninitialized]
-Wuninitialized -fno-diagnostics-show-option:
  foo.c:4:2: warning: 'j' is used uninitialized in this function
-Werror=uninitialized (or, e.g.: -Werror -Wall)
  foo.c:4:2: error: 'j' is used uninitialized in this function
[-Werror=uninitialized]


Expected:

a) -Werror  caues gfortran to print "Error" rather than "Warning"; currently it
only changes the exit status code (and the total error count)

b) -f(no-)diagnostics-show-option is supported by printing the flag in
parenthesis after the warning

c) -Werror=<list> is supported.


-- 
           Summary: Handle -Werror, -Werror=, -fdiagnostics-show-option
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2010-05-10 10:30 -------
-Werror= was added 2006 (
http://gcc.gnu.org/viewcvs?view=revision&revision=109907 ) and the
-fdiagnostics-show-option already exists since 2005
(http://gcc.gnu.org/viewcvs?view=revision&revision=99169 ) - though it has only
be enabled very recently, cf.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00910.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[dfranke at gcc dot gnu dot org]

------- Comment #2 from dfranke at gcc dot gnu dot org  2010-05-10 16:58 -------
This probably superseeds (accompanies?) PR31601.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2010-05-10 17:16 -------
(In reply to comment #2)
> This probably superseeds (accompanies?) PR31601.

Not really. This is about warnings - the other is about errors due to -std=.
For warnings, the purpose is to help fine-tuning the warnings - while for
errors (-std=, -f(no-)range-check) the idea is to point the user to an option,
which allows him/her to still compile the program. 

(Sometimes one is simply not aware that a certain option exists - and
especially non-Fortran programmers tend to compile legacy Fortran programs. But
even I tend to forget about. e.g., -std=legacy or -fdollar-ok.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2010-05-15 00:44 -------
It would be so nice if there was a single diagnostics library that all FEs
could use and help to enhance. Something configurable, flexible and powerful
like LLVM's diagnostics library. Then Fortran could configure the library to
get a consistent output. Maybe pooling resources we could get caret
diagnostics, ranges, xml output, color, fix-it hints, spell-checker and a few
other features that LLVM already has.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-15 00:44:07
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 32622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32622&action=edit
proof of concept

The attached patch is a proof of concept. It gives the following output:

/home/manuel/test1/test-gfc-warning.f03:11:0:
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4)
at (1) [-Wconversion]
   arr = (/ INTEGER(KIND=4) :: HUGE(0_8) /) ! { dg-warning "conversion from" }
 ^

This warning is controllable by -Wno-conversion, -Werror=conversion and the
#pragma GCC diagnostic. Also the diagnostic is in color (unfortunately it does
not show it here).

Contrary to what I said above, I think it is actually easier for Fortran to use
the common pretty printer rather than fake their own. It will also remove quite
a bit of duplicated code from the Fortran FE. The transition can be done in the
following steps (I chose the wrong warning to start with):

1. Warnings that don't use %L (so initially you don't have to deal with locus)
2. Warnings that use %C
3. Warnings that use one %L
4. Warnings that use two %L


If there is one or more willing Fortran developers that wants to tackle this
for the next release, I think the four steps are feasible within one release.
To fully match the current Fortran diagnostics, the common diagnostics
machinery needs the following features:

a. Make the printing of the caret line more customizable. For the C/C++ FE it
will be moved to the diagnostic_finalizer, whereas for Fortran it will go in
the diagnostic_starter, so it can be printed before the actual text.
b. A way to customize the caret symbol so Fortran can print '1' instead of '^'.
c. Pass down offsets relative to current location. This is anyway necessary for
printing more precise diagnostics for format strings, so it is a matter to add
an offset field to the diagnostic_info structure.
d. A way to print two locations in the caret line.

And that is all as far as I can see.

If a Fortran developer volunteers to tackle the Fortran bits, I will be happy
to implement the common diagnostics bits. From the above a) and b) are trivial.
c) is also trivial but requires writing a bit more of code. d) is a bit more
convoluted but it should work fine.

The Fortran transition can be incremental, that is, if Fortran disables colors
and -fdiagnostics-show-option by default, then the converted diagnostics will
be indistinguishable from the unconverted ones (except that -Wno-*, -Werror=
and the #pragmas will only work for the converted ones).
>From gcc-bugs-return-449195-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 16 20:05:59 2014
Return-Path: <gcc-bugs-return-449195-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25156 invoked by alias); 16 Apr 2014 20:05:59 -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 25123 invoked by uid 48); 16 Apr 2014 20:05:56 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60852] [4.8/4.9/4.10 Regression] boost::has_complement of enum class does not compile
Date: Wed, 16 Apr 2014 20:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: paolo.carlini at oracle dot com
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60852-4-Wum9UClui7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60852-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60852-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-04/txt/msg01215.txt.bz2
Content-length: 287

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`852

--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
Did someone file a corresponding PR for clang? It is useful for them, but also
for gcc because it gives them a chance to give a different interpretation of
the standard.