public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Jeff Law <law@redhat.com>
Cc: David Malcolm <dmalcolm@redhat.com>,
	gcc-patches@gcc.gnu.org,	mliska@suse.cz
Subject: Re: [PATCH 2/4 v2] libcpp: Replace macro usage with C++ constructs)
Date: Sun, 10 May 2015 15:39:00 -0000	[thread overview]
Message-ID: <20150510153951.GE9659@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <554D2E65.4010802@redhat.com>

> On 05/05/2015 12:21 PM, David Malcolm wrote:
> >On Mon, 2015-05-04 at 13:15 -0600, Jeff Law wrote:
> >On 05/01/2015 06:56 PM, David Malcolm wrote:
> >>>
> >>>[I didn't mark the inline functions as "static"; should they be?]
> Just a follow-up on this.  I got burned by the ODR issues around
> implicit extern inlines earlier this week.  Basically I had two
> distinct implementations for an inline function with the same name.
> They obviously appeared in different "header files".
> 
> When optimizng, this was fine as they'd actually get inlined and all
> was good.  Things blew up when the optimizer was off.  We got two
> functions with the same name, but different implementations.  The
> linker blindly chose one for me, and in one context it was the wrong
> one.
> 
> This led to bootstrap comparison failures.
> 
> So, just be careful :-)

Martin actually tried using ICF to warn about such cases at LTO time (if the
two COMDAT function bodies does not seem to have same implementation, complain
about it). One showstopper here is that early inliner may divere easily (if you
provide inline implementation of called function in one unit), but perhaps we could
output warnings at least in cases we know that both optimization flags and
inline decisions match. (this can be checked during the compare by looking
at DECL_INITIAL block structure)

In GCC I would really love us to switch to non-static inline and just chase
out ODR violations if they exists (hopefully it is not that common). This
makes code reuse more explicit to IPA and hopefully will lead to smaller
binaries.

Honza

  reply	other threads:[~2015-05-10 15:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02  0:44 [PATCH 0/4] libcpp patches David Malcolm
2015-05-02  0:44 ` [PATCH 4/4] Replace line_map union with C++ class hierarchy David Malcolm
2015-05-04 20:45   ` Jeff Law
2015-05-04 21:34     ` David Malcolm
2015-05-14 15:20       ` Jeff Law
2015-05-02  0:44 ` [PATCH 3/4] libcpp/input.c: Add a way to visualize the linemaps David Malcolm
2015-05-04 19:20   ` Jeff Law
2015-05-13 14:05     ` David Malcolm
2015-05-02  0:44 ` [PATCH 2/4] libcpp: Replace macro usage with C++ constructs David Malcolm
2015-05-04 19:15   ` Jeff Law
2015-05-05 18:08     ` [PATCH 2/4 v2] libcpp: Replace macro usage with C++ constructs) David Malcolm
2015-05-05 18:08       ` [PATCH 2/4 v2: part 2] libcpp: Replace macro usage with C++ constructs David Malcolm
2015-05-08 21:47         ` Jeff Law
2015-07-08 14:50         ` Thomas Schwinge
2015-07-08 15:14           ` David Malcolm
2015-05-05 18:08       ` [PATCH 2/4 v2: part 1] Move linemap_assert higher up within the file David Malcolm
2015-05-08 21:35         ` Jeff Law
2015-05-05 18:08       ` [PATCH 5/4] libcpp: Eliminate most of the non-const/reference-returning inline fns David Malcolm
2015-05-08 21:49         ` Jeff Law
2015-05-08 21:45       ` [PATCH 2/4 v2] libcpp: Replace macro usage with C++ constructs) Jeff Law
2015-05-10 15:39         ` Jan Hubicka [this message]
2015-05-02  0:44 ` [PATCH 1/4] libcpp: Improvements to comments in line-map.h/c David Malcolm
2015-05-04 17:18   ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150510153951.GE9659@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).