From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9582 invoked by alias); 25 Jan 2013 11:43:53 -0000 Received: (qmail 7855 invoked by uid 48); 25 Jan 2013 11:43:37 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts Date: Fri, 25 Jan 2013 11:43: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-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: manu 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-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg02357.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56094 --- Comment #13 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez 2013-01-25 11:43:37 UTC --- (In reply to comment #12) > Created attachment 29272 [details] > gcc48-pr56094.patch >=20 > input_location is used heavily in the gimplifier, gimplify_expr sets it f= rom > the expression being currently gimplified (if it has any), and for tempor= aries > and their initializers that are created while gimplifying that stmt it is > intentional to use the location of that expression. You are explaining how it works right now. What I am asking is how we want = it to work, that is, why the gimplifier needs to care about input_location and cannot use *always* the location of the expression being gimplified (or some sub-expression) or UNKNOWN_LOCATION for things that are compiler generated. Moreover, if gimplifying occurs after parsing is completed, why do we need = to use input_location as a communication device between parts of the gimplifie= r, why not just use some gimplifier-specific state or pass down specific locations. > I've bootstrapped/regtested this patch on i686-linux (no ada) so far, the= lex.c > hunk is to avoid ICEs when e.g. tree-parloops.c calls the make_type langh= ook > (but there are other callers of that) with input_location of UNKNOWN_LOCA= TION. > I was surprised there weren't regressions, given that input_location is u= sed > implicitly e.g. by all error/warning calls, unless they supply their own > location. Does the diagnostic machinery assert that input_location !=3D UNKNOWN_LOCAT= ION? I think not. I seem to remember that we sometimes generate: warning:0:0: something but I am not sure if this happens for warning_at(UNKNOWN_LOCATION).