* [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
2014-11-18 23:01 [Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function eggert at gnu dot org
@ 2014-11-19 15:16 ` manu at gcc dot gnu.org
2021-03-31 16:15 ` msebor at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2014-11-19 15:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-11-19
CC| |manu at gcc dot gnu.org
Blocks| |24639
Summary|-Wmaybe-uninitialized |wrong location for
|pragma mishandled in |-Wmaybe-uninitialized in
|inlined function |inlined function
Ever confirmed|0 |1
Known to fail| |4.9.2, 5.0
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Confirmed also in GCC 5.0.
The problem is the location info that is available in the middle-end and how
this is transformed when inlining and renaming/propagating copies. To be able
to silence this, the warning should be given at the location of 'return *p'.
We have the correct location in 028t.esra:
;; basic block 4, loop depth 0, count 0, freq 10000, maybe hot
;; prev block 3, next block 5, flags: (NEW, REACHABLE)
;; pred: 2 (FALSE_VALUE,EXECUTABLE)
;; starting at line 7
[test.c:7:10] _9 = v$4_14(D);
_13 = _9;
[test.c:17:27] iftmp.0_10 = _9;
;; succ: 5 (FALLTHRU,EXECUTABLE)
but the middle-end loses it after 030t.fre1:
;; basic block 5, loop depth 0, count 0, freq 0, maybe hot
;; prev block 4, next block 1, flags: (NEW, REACHABLE)
;; pred: 3 (FALLTHRU,EXECUTABLE)
;; 4 (FALLTHRU,EXECUTABLE)
;; starting at line -1, discriminator 4
# iftmp.0_1 = PHI <[test.c:17:27] iftmp.0_8(3), [test.c:17:27] v$4_14(D)(4)>
As a side note, I wonder if %K could be used here to get an "inline-from"
backtrace like we do in other diagnostics.
>From gcc-bugs-return-467515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 19 15:23:38 2014
Return-Path: <gcc-bugs-return-467515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22080 invoked by alias); 19 Nov 2014 15:23:38 -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 22030 invoked by uid 48); 19 Nov 2014 15:23:34 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/36312] should refuse to overwrite input file with output file
Date: Wed, 19 Nov 2014 15:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: 4.1.2
X-Bugzilla-Keywords: diagnostic, patch
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
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-36312-4-oj3m4jNZDQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36312-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36312-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-11/txt/msg01987.txt.bz2
Content-length: 760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312
--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to carlos from comment #15)
> It would be sufficient if /dev/null were special cased in some way for Linux
> configurations.
There is a pre-approved patch here
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837#c12) that I'm testing.
Unfortunately, there seems to be a problem with the machine in the compile farm
that I use for gcc development, and I'm not able to finish a
bootstrap®ression test. I always get:
couldn't create output pipe for command: too many open files
even for a pristine copy of GCC. This didn't happen a few days ago. I didn't
have time yet to investigate what is wrong.
>From gcc-bugs-return-467516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 19 15:24:11 2014
Return-Path: <gcc-bugs-return-467516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22846 invoked by alias); 19 Nov 2014 15:24:10 -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 22811 invoked by uid 48); 19 Nov 2014 15:24:07 -0000
From: "tbsaunde at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0
Date: Wed, 19 Nov 2014 15:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.6.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tbsaunde at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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 cc resolution
Message-ID: <bug-50687-4-W5O1RrT2XM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50687-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50687-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-11/txt/msg01988.txt.bz2
Content-length: 565
https://gcc.gnu.org/bugzilla/show_bug.cgi?idP687
tbsaunde at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |tbsaunde at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #5 from tbsaunde at gcc dot gnu.org ---
both 4.6 and 4.7 are unmaintained at this point, and this seems like reasonable
behavior anyway.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
2014-11-18 23:01 [Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function eggert at gnu dot org
2014-11-19 15:16 ` [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized " manu at gcc dot gnu.org
@ 2021-03-31 16:15 ` msebor at gcc dot gnu.org
2021-03-31 17:56 ` manu at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-03-31 16:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
Last reconfirmed|2014-11-19 00:00:00 |2021-3-31
Known to fail|4.9.2, 5.0 |10.2.0, 11.0, 4.9.4, 5.5.0,
| |6.4.0, 7.2.0, 8.3.0, 9.1.0
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirmed with GCC 11 with mostly the same observations as in comment #1.
As for using %K, I mostly agree. I actually have %G in my tree, but my goal is
to get rid of both and replace them with a new warning function like so:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
and replace calls to warning() and warning_at() in the middle end with those to
the new function. This makes it possible to control warnings at any point in
the lining stack and resolves bug like pr98871.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
2014-11-18 23:01 [Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function eggert at gnu dot org
2014-11-19 15:16 ` [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized " manu at gcc dot gnu.org
2021-03-31 16:15 ` msebor at gcc dot gnu.org
@ 2021-03-31 17:56 ` manu at gcc dot gnu.org
2021-03-31 20:36 ` egallager at gcc dot gnu.org
2021-04-15 16:49 ` msebor at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2021-03-31 17:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943
--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #3)
> As for using %K, I mostly agree. I actually have %G in my tree, but my goal
> is to get rid of both and replace them with a new warning function like so:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
> and replace calls to warning() and warning_at() in the middle end with those
> to the new function. This makes it possible to control warnings at any
> point in the lining stack and resolves bug like pr98871.
That is great. It may be worth CCing David Malcolm, since he is the diagnostics
maintainer. A couple of comments:
* #include "tree.h" in diagnostic.c is not great. Ideally, diagnostic.c should
be independent of trees so that other front-ends can use it without having to
use tree. We went through a lot of work to make the core diagnostics
independent of any FE or Middle-end and only depend on line-map and options
handling. The original plan is to move it to its own library/module, but I
guess there has been little progress in the modular GCC.
* There is a tree-diagnostic.c. Everything that depends on tree.h should be
moved there. (again, if there was a modular GCC, this would be obvious but
alas...)
* Although it is more work, I think Richard and other middle-end reviewers
would be more motivated to accept this if it removed completely
percent_K_format. That is, rather than add yet-another-way, completely replaces
the old %K with something better.
* I don't contribute to GCC anymore, but rather than doing:
diag_inlining_context dic (exp);
warning (dic, opt, "%qD specified size %E may exceed maximum object size %E",
func, bndrng[0], maxobjsize);
I'd prefer:
warning_at_inlined_context(exp, opt, "%qD specified size %E may exceed maximum
object size %E", func, bndrng[0], maxobjsize);
This way, I don't need to know about class diag_inlining_context nor about
another variable (dic). I just need to know about an alternative warning
function and the magic is hidden from me. This function can live in
tree-diagnostic.c which contains the tree-specific functions for diagnostics.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
2014-11-18 23:01 [Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function eggert at gnu dot org
` (2 preceding siblings ...)
2021-03-31 17:56 ` manu at gcc dot gnu.org
@ 2021-03-31 20:36 ` egallager at gcc dot gnu.org
2021-04-15 16:49 ` msebor at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-03-31 20:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org,
| |egallager at gcc dot gnu.org
--- Comment #5 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Martin Sebor from comment #3)
> > As for using %K, I mostly agree. I actually have %G in my tree, but my goal
> > is to get rid of both and replace them with a new warning function like so:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
> > and replace calls to warning() and warning_at() in the middle end with those
> > to the new function. This makes it possible to control warnings at any
> > point in the lining stack and resolves bug like pr98871.
>
> That is great. It may be worth CCing David Malcolm, since he is the
> diagnostics maintainer.
OK, done
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
2014-11-18 23:01 [Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function eggert at gnu dot org
` (3 preceding siblings ...)
2021-03-31 20:36 ` egallager at gcc dot gnu.org
@ 2021-04-15 16:49 ` msebor at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-04-15 16:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=81962 |
CC| |janus at gcc dot gnu.org
--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 81962 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 6+ messages in thread