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 ;)
