This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886

--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 11 Feb 2015, Richard Biener wrote:

> On Wed, 11 Feb 2015, hubicka at ucw dot cz wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
> > 
> > --- Comment #31 from Jan Hubicka <hubicka at ucw dot cz> ---
> > > So, do we really want to go without this fixed again, for GCC 5?  Honza?  After
> > > all this is an underlying wrong-code issue!  (wrong function is picked as
> > > prevailing)
> > 
> > Well, I have only two hands and do not see reasonably simple solution. Will
> > look into it
> > again.  How this cause wrong code?
> 
> Hmm, maybe it can't (the "aliases" map to the same symbol).  But at least
> if I produce another decl with say, attribute(regparm), and that gets
> picked even though I didn't call it then it would be wrong-code
> (of course that decl is technically invalid as the symbol it refers to
> has different calling conventions).

Like

extern void fooreg (int i) __attribute__((regparm)) __asm__ ("bar");
extern void foo (int i) __asm__ ("bar");

void forward (int i, int reg)
{
  if (reg)
    fooreg (i);
  else
    foo (i);
}

and use it like LD_PRELOAD=libwithregparm.so ./test --regparm.

Poor-mans ifuncs ;)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]