This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 11 Feb 2015 10:08:20 +0000
- Subject: [Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
- Auto-submitted: auto-generated
- References: <bug-61886-4 at http dot gcc dot gnu dot org/bugzilla/>
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 ;)