From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C47EC3944438; Thu, 26 Mar 2020 08:42:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C47EC3944438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585212161; bh=eogZLYX244oQQKx1UCgUC20hYg9nlK+IcXdPriunkJY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RKH4Iotrx3wdgp43lKbbpJQXIcjgL6Hiqusng+zYMCTO9H6adW0a7bCLS9SeMCG+o wAsl0KTU6ujGdvQx8v7E0/rqOQeLZLDqqHjNkxNUnWYq7kdvxDs9kfmHuq9L7HaIgC B6P3+4Vpwul9yzBCQFNGpyH3+vDBoiMakNlc229E= From: "romain.geissler at amadeus dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2 Date: Thu, 26 Mar 2020 08:42:41 +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: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: romain.geissler at amadeus 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: --- 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: Thu, 26 Mar 2020 08:42:41 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94335 --- Comment #4 from Romain Geissler --- Thanks Richard. Indeed, beyond the false positive described in this bug, our whole code that implement "relative pointer" is I think quite hacky and not very compiler friendly (around alignment, aliasing rule, pointer arithmetic). We should review and update it a lot. Actually a similar class exists in Boost.Interprocess under the name "offset_ptr", and they did write this in their header: https://github.com/boostorg/interprocess/blob/develop/include/boost/interpr= ocess/offset_ptr.hpp //Note: using the address of a local variable to point to another address //is not standard conforming and this can be optimized-away by the compiler. //Non-inlining is a method to remain illegal but correct //Undef BOOST_INTERPROCESS_OFFSET_PTR_INLINE_XXX if your compiler can inline //this code without breaking the library any time they need to deal with pointer to offset conversion, or vice-versa= . I happens that we also suffer from similar problems and had to put attribute "noinline" "randomly" in places to "fix" (actually workaround our poor understanding of how the compiler works) problems we are seeing with the behavior of this library when compiled with optimizations. We should obviou= sly review greatly in depths what we are doing which seems wrong in many places. PS Martin: I am ok to leave unresolved, just I think the wording of the err= or should be somehow updated so that the fact that it's only a possibility for= not a certainty, other of your warnings around string management do print the r= ange of value that gcc found out is possible, and that helps in understanding and fixing/silencing the warnings.=