From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B79FD3858401; Tue, 9 Nov 2021 00:01:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B79FD3858401 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure Date: Tue, 09 Nov 2021 00:01:13 +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: 12.0 X-Bugzilla-Keywords: build, diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 00:01:13 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103121 --- Comment #14 from Andrew Macleod --- As near as I can tell, you are calling debug_ranger () to see what ranger c= ould produce. That routine creates a new ranger and populates it, dumps out the results, kills the ranger and returns. When I put a breakpoint in the code: 2181 tree tlen =3D build_int_cst (size_type_node, len); (gdb) c Continuing. Breakpoint 1, strlen_pass::maybe_warn_overflow (this=3D0x7fffffffcec0, stmt=3D0x7fffe9f63910, call_lhs=3Dtrue, len=3D0x7fffe9f4ed50, si=3D0x0, plu= s_one=3Dfalse, rawmem=3Dfalse) at /gcc/master/gcc/gcc/tree-ssa-strlen.c:1998 1998 if (!len || warning_suppressed_p (stmt, OPT_Wstringop_overflow_)) (gdb) p print_gimple_stmt (stderr, stmt, 0 ,0) *grp_name_25 =3D 0; $8 =3D void (gdb) enable 2 (gdb) c Continuing. Breakpoint 2, vr_values::range_of_expr (this=3D0x7fffffffcee0, r=3D..., expr=3D0x7fffe9f5d0d8, stmt=3D0x7fffe9f5b240) at /gcc/master/gcc/gcc/vr-values.c:182 182 if (!gimple_range_ssa_p (expr)) (gdb) p print_generic_expr (stderr, expr, 0) _2$9 =3D void (gdb) p print_gimple_stmt (stderr, stmt, 0, 0) grp_name_25 =3D __builtin_alloca (_2); $10 =3D void So yes, you are asking for the range of _2 at that statement.... but note t= he traceback shows you are invoking: Breakpoint 2, vr_values::range_of_expr Which means you aren't using ranger... that callback is into vr_values... w= hich is the old EVRP engine. Have you called enable_ranger() to turn it on for your pass? You should be seeing gimple-ranger::range_of_expr() in that traceback. That also explains why when I range --param=3Dranger-debug=3Dtrace I wasn't= seeing any calls in your listing. Looking deeper, the place where this is called from in get_size_range: if (!query) query =3D get_range_query (cfun); if (integral) { value_range vr; query->range_of_expr (vr, exp, stmt); p get_range_query (cfun) $11 =3D (range_query *) 0x40d9a80 So if you didn't have a range query, it would have picked up global ranges.= .=20 Looking down the call chain: #0 vr_values::range_of_expr (this=3D0x7fffffffcee0, r=3D..., expr=3D0x7fff= e9f5d0d8, stmt=3D0x7fffe9f5b240) at /gcc/master/gcc/gcc/vr-values.c:182 #1 0x000000000163c58c in get_size_range (query=3D0x7fffffffcee0, exp=3D0x7fffe9f5d0d8, stmt=3D0x7fffe9f5b240, range=3D0x7fffffffb840, flags= =3D3) at /gcc/master/gcc/gcc/pointer-query.cc:320 #2 0x000000000163d724 in gimple_call_alloc_size (stmt=3D0x7fffe9f5b240, rng1=3D0x7fffffffbb20, qry=3D0x7fffffffcee0) at /gcc/master/gcc/gcc/pointer-query.cc:506 #3 0x0000000001643501 in compute_objsize_r (ptr=3D0x7fffe9f5d870, stmt=3D0x7fffe9f5b240, ostype=3D1, pref=3D0x7fffffffc7f0, snlim=3D..., qry=3D0x7fffffffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:1970 #4 0x000000000164224c in handle_mem_ref (mref=3D0x7fffe9f6d230, stmt=3D0x7fffe9f63910, ostype=3D1, pref=3D0x7fffffffc7f0, snlim=3D..., qry=3D0x7fffffffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:1702 #5 0x0000000001642d63 in compute_objsize_r (ptr=3D0x7fffe9f6d230, stmt=3D0x7fffe9f63910, ostype=3D1, pref=3D0x7fffffffc7f0, snlim=3D..., qry=3D0x7fffffffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:1865 #6 0x00000000016441a9 in compute_objsize (ptr=3D0x7fffe9f6d230, stmt=3D0x7fffe9f63910, ostype=3D1, pref=3D0x7fffffffc7f0, ptr_qry=3D0x7ffff= fffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:2154 #7 0x0000000001a71634 in strlen_pass::maybe_warn_overflow (this=3D0x7fffffffcec0, stmt=3D0x7fffe9f63910, call_lhs=3Dtrue, len=3D0x7ff= fe9f4ed50, si=3D0x0, plus_one=3Dfalse, rawmem=3Dfalse) at /gcc/master/gcc/gcc/tree-ssa-strlen.c:2038 I see you are passing this range_query down the call chain from the maybe_warn_overflow. I am not sure where you picked up a vr-values range query... but if you had simply called enable_ranger() at the start of the pass, and let cfun->get_range_query() get the query object in get_size_rang= e(), I would expect you to see rangers results. As it is, I don't know what you= are looking at, nor where it came from.=