On Mon, 8 Dec 2014, Joseph Myers wrote:
On Mon, 8 Dec 2014, Richard Biener wrote:
The alternative is to decide used in the middle-end at one point,
for example at the end of all_lowering_passes where hopefully
we have constant folded and removed dead code enough. We can also
compute
On Thu, 4 Dec 2014, Joseph Myers wrote:
On Thu, 4 Dec 2014, Richard Biener wrote:
OTOH this also means the user cannot provide a conforming
implementation on his own and get that used by GCC without editing
system headers or including a header with -isystem or similar
tricks.
Well -
On Mon, Dec 08, 2014 at 01:24:12PM +0100, Richard Biener wrote:
I'm not pushing this further for stage3, but for stage1 I'd like
to eventually address this by splitting up builtin_info_type's
'implicit_p' into a flags array providing implicit_p, declared_p,
used_p and maybe
On Mon, 8 Dec 2014, Jakub Jelinek wrote:
On Mon, Dec 08, 2014 at 01:24:12PM +0100, Richard Biener wrote:
I'm not pushing this further for stage3, but for stage1 I'd like
to eventually address this by splitting up builtin_info_type's
'implicit_p' into a flags array providing implicit_p,
On Mon, Dec 08, 2014 at 01:54:21PM +0100, Richard Biener wrote:
On Mon, 8 Dec 2014, Jakub Jelinek wrote:
On Mon, Dec 08, 2014 at 01:24:12PM +0100, Richard Biener wrote:
I'm not pushing this further for stage3, but for stage1 I'd like
to eventually address this by splitting up
On Mon, 8 Dec 2014, Richard Biener wrote:
I'm not pushing this further for stage3, but for stage1 I'd like
to eventually address this by splitting up builtin_info_type's
'implicit_p' into a flags array providing implicit_p, declared_p,
used_p and maybe declared_in_system_header_p. Would you
On Mon, 8 Dec 2014, Richard Biener wrote:
The alternative is to decide used in the middle-end at one point,
for example at the end of all_lowering_passes where hopefully
we have constant folded and removed dead code enough. We can also
compute an overall uses libm flag to fix the testcase I
Currently even when I prototype
double exp10 (double);
this function is not available to optimizers for code generation if
they just check for builtin_decl_implicit (BUILT_IN_EXP10).
Curiously though the function is identified as BUILT_IN_EXP10 when
used though, thus the middle-end assumes it
On Thu, 4 Dec 2014, Richard Biener wrote:
Currently even when I prototype
double exp10 (double);
this function is not available to optimizers for code generation if
they just check for builtin_decl_implicit (BUILT_IN_EXP10).
Curiously though the function is identified as BUILT_IN_EXP10
OK.
Jason
On Thu, 4 Dec 2014, Richard Biener wrote:
Currently even when I prototype
double exp10 (double);
this function is not available to optimizers for code generation if
they just check for builtin_decl_implicit (BUILT_IN_EXP10).
Curiously though the function is identified as BUILT_IN_EXP10
On Thu, 4 Dec 2014, Joseph Myers wrote:
On Thu, 4 Dec 2014, Richard Biener wrote:
Currently even when I prototype
double exp10 (double);
this function is not available to optimizers for code generation if
they just check for builtin_decl_implicit (BUILT_IN_EXP10).
Curiously
On Thu, 4 Dec 2014, Richard Biener wrote:
So what does this all mean in practice for optimization passes?
I don't know what it means in terms of how to fix the various existing
problems - it's simply how I think a fixed compiler should behave.
When b) does not apply then the given stpcpy
On Thu, 4 Dec 2014, Joseph Myers wrote:
On Thu, 4 Dec 2014, Richard Biener wrote:
So what does this all mean in practice for optimization passes?
I don't know what it means in terms of how to fix the various existing
problems - it's simply how I think a fixed compiler should behave.
On Thu, 4 Dec 2014, Richard Biener wrote:
OTOH this also means the user cannot provide a conforming
implementation on his own and get that used by GCC without editing
system headers or including a header with -isystem or similar
tricks.
Well - you could have a pragma / attribute for that
15 matches
Mail list logo
