--- Comment #6 from tbptbp at gmail dot com 2008-02-14 10:30 ---
Well, this was my best attempt so far at cornering that issue. I'm gonna wave a
dead chicken and try another attack vector. Sigh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34864
--- Comment #5 from rguenther at suse dot de 2008-02-14 10:14 ---
Subject: Re: array constants after inlining
and "staticification"
On Thu, 14 Feb 2008, tbptbp at gmail dot com wrote:
> --- Comment #4 from tbptbp at gmail dot com 2008-02-14 10:02 ---
> Hmm. If i correctly un
--- Comment #4 from tbptbp at gmail dot com 2008-02-14 10:02 ---
Hmm. If i correctly understand what you're saying, *cough*, ldexp should be
immune to this missed-folding-because-a-builtin-isn't-recognized-as-such; but
in the original code that lead to PR34774 there's nothing but ldexp,
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-14 09:13 ---
It's probably still the same issue - in initializers we only fold builtin
functions, where the std:: variants are not recognized as such (they are
wrapper functions around the builtin). So this gets folded only afte
--- Comment #2 from tbptbp at gmail dot com 2008-01-19 17:56 ---
Gah. Seems that i've managed to hit another issue than what i was after with my
simplistic testcase then, because in the original code there's no array
anywhere - but static definitions - and i get calls to ldexpf (at runti
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-19 12:04 ---
It is constant folded but not until after inlining.
A simplier example is:
static inline int f(int a)
{
return a+2;
}
int g(int a)
{
const int b[] = {f(1), f(2), f(3) };
return b[a];
}
int g1(int a)
{
const
