* [Bug c/65445] Improve [-W...] display for -Wformat
2015-03-17 8:27 [Bug c/65445] New: Improve [-W...] display for -Wformat burnus at gcc dot gnu.org
2015-03-17 8:32 ` [Bug c/65445] " mpolacek at gcc dot gnu.org
@ 2015-03-17 16:26 ` manu at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: manu at gcc dot gnu.org @ 2015-03-17 16:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65445
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
There is a trivial fix, which is to use the appropriate OPT_Wx flag when
calling warning().
However, Joseph and I think that if the warning was enabled via a group option,
then it would be better to print both, such as:
[-Wformat=,-Wformat-contains-null]
This should be feasible now that options relationships are encoded in the *.opt
files. One would need to build in the opt*.awk scripts a static data-structure
that given OPT_Wx gives a list of OPT_Wy options that enable it. Something
like:
static int opts_enable_opt_table [] = {
...
2, OPT_Wall, OPT_Wc++-compat, /* OPT_Wenum_compare */
1, OPT_Wformat, /* OPT_Wformat_contains_nul */
...
};
static int opts_enable_opt_index [] = {
...
/* OPT_Wenum_compare */ 50,
/* OPT_Wformat_contains_nul */ 53,
/* OPT_Wall */ -1,
....
};
such that opts_enable_opt_table[opts_enable_opt_index[OPT_Wformat_contains_nul]
+ 1] == OPT_Wformat
Then add a function that given an OPT_Wx, returns which OPT_Wy options that
enable it are enabled at this moment. Then, use this function when printing the
warning in diagnostics.c.
>From gcc-bugs-return-480562-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 17 16:48:56 2015
Return-Path: <gcc-bugs-return-480562-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 33721 invoked by alias); 17 Mar 2015 16:48:56 -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 33673 invoked by uid 48); 17 Mar 2015 16:48:52 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65448] Allow for cascade includes in error messages
Date: Tue, 17 Mar 2015 16:48: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.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-65448-4-HmroO4ROT0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65448-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: 2015-03/txt/msg01706.txt.bz2
Content-length: 1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2015-03-17
CC| |manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Michal Malecki from comment #0)
> Most tools that use these error reports simply skip the first three lines,
> as they do not look like "standard compiler error format". It would be nice
> to have at least an option to change the format into something like this:
Which tools? Shouldn't those tools be fixed instead?
Perhaps this would have been a better way to do it (although I would prefer the
notes after the error, and it could just not say "note:", to be consistent with
what we do for template instantiations), if we could start over again, but now
GCC has always behaved like this, if we change it, it may break other tools.
>From gcc-bugs-return-480563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 17 17:18:53 2015
Return-Path: <gcc-bugs-return-480563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10541 invoked by alias); 17 Mar 2015 17:18:53 -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 10496 invoked by uid 48); 17 Mar 2015 17:18:49 -0000
From: "aoliva at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
Date: Tue, 17 Mar 2015 17:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aoliva at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-64164-4-3AWsFxyQgP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64164-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64164-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: 2015-03/txt/msg01707.txt.bz2
Content-length: 1551
https://gcc.gnu.org/bugzilla/show_bug.cgi?idd164
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org
--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
The problem starts in the first copyrename pass. We refrain from coalescing
variables if neither has a usable root. This causes us to fail to coalesce
partitions that we would coalesce if only we tried them in a different order
(i.e., P1 and P2 fail but either one coalesces with P3, and then the other
would coalesce with that union). This is exactly what happens in AO_myload
with -DOPT: partitions _3 and _6 won't coalesce, and then result_4 and _6
coalesce, which would enable _3 to coalesce too. This in turn brings
additional rootless variables into stm_load, which again fail to coalesce
because we try them first (_36 and _4 fails, and l_11 and _36 passes, so that
with _4 would work). Without -DOPT, we succeed in coalescing result (there are
fewer SSA names), and when that is inlined, it gets there with a root symbol,
so that coalescing of _36 and result_4 succeeds. In both cases, we coalesce
l_11 with result_36, and it is precisely because _4 remains separate that we
end up introducing copies in new blocks when going out of SSA into RTL.
Coalescing SSA names even when neither has a root removes the optimization
differences for this testcase.
^ permalink raw reply [flat|nested] 3+ messages in thread