From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10686 invoked by alias); 10 Apr 2014 13:42:08 -0000 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 Received: (qmail 10637 invoked by uid 48); 10 Apr 2014 13:42:03 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are "", in both warnings and dumps Date: Thu, 10 Apr 2014 13:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.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-SW-Source: 2014-04/txt/msg00736.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60761 --- Comment #16 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Martin Jambor from comment #15) > (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #13) > > It is not clear to me why you want to print at all. It is an > > internal detail. >=20 > ...just printing "" really provides fairly little value. If we > (hopefully from the next version on) manage to print details about > properties of the particular clone, it will become useful. I'm not entirely convinced by the arguments given above. Templated C++ code= in diagnostics is already convoluted enough to add stuff that is not even in t= he language and that users will have no idea about. Imagine (real G++ output): std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_Ch= arT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type& (*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT =3D= char, _Traits =3D std::char_traits, std::basic_ostream<_CharT, _Traits>::__ostream_type =3D std::basic_ostream] For developer/debug dumps, of course this doesn't apply, but this is not wh= at this bug is about. (In reply to Marc Glisse from comment #14) > Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone > specializing a=3D0. If the function contains a comparison a<=3Db, you mig= ht get > a warning because the comparison is always true. As a user, I would be qu= ite > confused... This used to happen with template instantiations and it was considered a bu= g. That is, the compiler should not give that kind of warning for generated co= de if the original code does not show the same issue. If the original code sho= ws the same issue, then we should give a warning for the original code.=20 In general, there are at least two kinds of warnings: those for which there= is a bug if we reach that code under certain conditions, and those for which t= he code looks suspicious but we cannot prove that there is a bug under any specific condition. Uninitialized warnings fall in the first category, wher= eas "comparison is always true/false" falls under the second one. The first kin= d of warnings would be improved by providing the exact conditions that may trigg= er the bug, whereas the second kind become noise if only triggered for specific conditions that are actually not present in the original code (like template specializations, macro expansion, and function cloning). For the first kind of bugs, if we explain the conditions better thanks to optimization, great, but saying: we warn because we created a clone of the function only leads to more questions: what is a clone? For the second kind, saying that we warn because we created a clone sounds more like an excuse t= han an actual analysis. ;-) >>From gcc-bugs-return-448717-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 10 14:01:09 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 25861 invoked by alias); 10 Apr 2014 14:01:09 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 25820 invoked by uid 48); 10 Apr 2014 14:01:04 -0000 From: "mpolacek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/60809] C99 struct initialiser with embedded self assignment Date: Thu, 10 Apr 2014 14:01: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.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mpolacek 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-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-04/txt/msg00737.txt.bz2 Content-length: 686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809 Marek Polacek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I see nothing surprising here; an assignment expression has the value of the left operand after the assignment. So we 1) set query2.ai_flags to AI_PASSIVE, 2) use this value to initialize .ai_protocol. I'm not sure a warning here makes sense: an assignment-expression is perfectly valid initializer.