Re: basic-improvements merge status

Re: basic-improvements merge status

[David Edelsohn]

	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
recursing.

#ifndef HAVE_SINF
float
sinf(float x)
{
  return (float) sin(x);
}
#endif

is being compiled as

	bl sinf

In other words, recursing and calling itself.  This even appears in the
stubs.c.00.rtl dump:

(insn 11 10 12 0 (set (reg:SF 33 f1)
        (reg/v:SF 119)) -1 (nil)
    (insn_list:REG_LIBCALL 13 (nil)))

(call_insn/u 12 11 13 0 (parallel [
            (set (reg:SF 33 f1)
                (call (mem:SI (symbol_ref:SI ("sinf[DS]")) [0 S4 A8])
                    (const_int 32 [0x20])))
            (use (const_int 0 [0x0]))
            (clobber (scratch:SI))
        ]) -1 (nil)
    (expr_list:REG_EH_REGION (const_int -1 [0xffffffffffffffff])
        (nil))
    (expr_list (use (mem:BLK (scratch) [0 A8]))
        (expr_list (use (reg:SF 33 f1))
            (nil))))

(insn 13 12 14 0 (set (reg:SF 121)
        (reg:SF 33 f1)) -1 (nil)
    (insn_list:REG_RETVAL 11 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scra
tch) [0 A8]))
                (expr_list (symbol_ref:SI ("sinf[DS]"))
                    (expr_list (reg/v:SF 119)
                        (nil))))
            (nil))))

Any idea what change in GCC 3.4BIB is causing GCC to "optimize"

	(float) sin(x)

as

	sinf(x)?

Thanks, David

Re: basic-improvements merge status

[Zack Weinberg]

David Edelsohn <dje@watson.ibm.com> writes:

> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
>
> 	(float) sin(x)
>
> as
>
> 	sinf(x)?

I remember such an optimization being implemented but I can't find the
change log entry for it.  My recollection is that it was Jan Hubicka
who coded it.  Jan?

zw

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> David Edelsohn <dje@watson.ibm.com> writes:
>> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
>> 
>> (float) sin(x)
>> 
>> as
>> 
>> sinf(x)?

Zack> I remember such an optimization being implemented but I can't find the
Zack> change log entry for it.  My recollection is that it was Jan Hubicka
Zack> who coded it.  Jan?

	Yes, it appears to be due to the builtins.def changes by Jan which
assumes that all of those functions natively are available on every
target.  One cannot make that assumption.  Testing for the existence of
those functions on the target is not easy.

	In most cases, the transformation will result in a linker error on
systems which do not provide the function, but libstdc++-v3 graciously
provides the symbols, creating a recursion in those definitions.

David

Re: basic-improvements merge status

[Jan Hubicka]

> >>>>> Zack Weinberg writes:
> 
> Zack> David Edelsohn <dje@watson.ibm.com> writes:
> >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
> >> 
> >> (float) sin(x)
> >> 
> >> as
> >> 
> >> sinf(x)?
> 
> Zack> I remember such an optimization being implemented but I can't find the
> Zack> change log entry for it.  My recollection is that it was Jan Hubicka
> Zack> who coded it.  Jan?
> 
> 	Yes, it appears to be due to the builtins.def changes by Jan which
> assumes that all of those functions natively are available on every
> target.  One cannot make that assumption.  Testing for the existence of
> those functions on the target is not easy.

I noticed that already and there is patch waiting for that.  So hope it
will get reviewed soon.
I am not quite sure how to deal with this (whether we can autoconfigure
on whether runtime does have them or not).  At the moment I do the
transformation only when -std=c99 or gnu99 is specified when the
transformation is valid as the standard requires these functions.

Honza
> 
> 	In most cases, the transformation will result in a linker error on
> systems which do not provide the function, but libstdc++-v3 graciously
> provides the symbols, creating a recursion in those definitions.
> 
> David

Re: basic-improvements merge status

[Jan Hubicka]

> 	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
> AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
> recursing.
> 
> #ifndef HAVE_SINF
> float
> sinf(float x)
> {
>   return (float) sin(x);
> }
> #endif
> 
> is being compiled as

I think we can deal with -fno-builtin-fsin to avoid gcc from being
active on optimizing this.
The name sinf is reserved by C90 standard, so this is not valid C.

Honza

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Jan Hubicka writes:

>> #ifndef HAVE_SINF
>> float
>> sinf(float x)
>> {
>> return (float) sin(x);
>> }
>> #endif
>> 
>> is being compiled as

Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
Jan> active on optimizing this.
Jan> The name sinf is reserved by C90 standard, so this is not valid C.

	Maybe libstdc++-v3/libmath/stubs.c should be compiled with
-fno-builtins.  It only tries to define sinf if sinf was not found by
configure.

David

Re: basic-improvements merge status

[Jan Hubicka]

> >>>>> Jan Hubicka writes:
> 
> >> #ifndef HAVE_SINF
> >> float
> >> sinf(float x)
> >> {
> >> return (float) sin(x);
> >> }
> >> #endif
> >> 
> >> is being compiled as
> 
> Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
> Jan> active on optimizing this.
> Jan> The name sinf is reserved by C90 standard, so this is not valid C.
> 
> 	Maybe libstdc++-v3/libmath/stubs.c should be compiled with
> -fno-builtins.  It only tries to define sinf if sinf was not found by
> configure.
Yes, I will try to make patch.

Honza
> 
> David

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Jan Hubicka writes:

>> #ifndef HAVE_SINF
>> float
>> sinf(float x)
>> {
>> return (float) sin(x);
>> }
>> #endif
>> 
>> is being compiled as

Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
Jan> active on optimizing this.
Jan> The name sinf is reserved by C90 standard, so this is not valid C.

float
foo (float x)
{
  return (float) sin(x);
}

always should be valid without the user having to specify -fno-builtin, as
your change requires on systems without sinf().  stubs.c could be compiled
with -fno-builtin, but that's just covering up the incorrect assumption in
the transformation.

David

Re: basic-improvements merge status

[Jan Hubicka]

> >>>>> Jan Hubicka writes:
> 
> >> #ifndef HAVE_SINF
> >> float
> >> sinf(float x)
> >> {
> >> return (float) sin(x);
> >> }
> >> #endif
> >> 
> >> is being compiled as
> 
> Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
> Jan> active on optimizing this.
> Jan> The name sinf is reserved by C90 standard, so this is not valid C.
> 
> float
> foo (float x)
> {
>   return (float) sin(x);
> }
> 
> always should be valid without the user having to specify -fno-builtin, as
> your change requires on systems without sinf().  stubs.c could be compiled

As I've mentined I am handling this with the other patch that disables
the transfomration for C90 until we decide how to detect such systems.
On C99 and C++ it is always valid as runtime is required to have it (and
thats why libstdc++ does it).  I hope Richard will have time to take a
look on these patches soon.

I am not configure expert, but can I detect the runtime library
properties in it?  (when we are building without glibc, we need to
rebuild anyway at least on Linux bootstrap, so this should be possible)
Other way would be to use target macro.  Something like
TARGET_C99_RUNTIME.  Ideal would be to push these functions into libgcc,
but I am not quite sure how this can be done (ie so they will be
overwriten by runtime).
What sounds sane?

Honza

> with -fno-builtin, but that's just covering up the incorrect assumption in
> the transformation.
> 
> David

Re: basic-improvements merge status

[Neil Booth]

Jan Hubicka wrote:-

> > 
> > 	Yes, it appears to be due to the builtins.def changes by Jan which
> > assumes that all of those functions natively are available on every
> > target.  One cannot make that assumption.  Testing for the existence of
> > those functions on the target is not easy.
> 
> I noticed that already and there is patch waiting for that.  So hope it
> will get reviewed soon.
> I am not quite sure how to deal with this (whether we can autoconfigure
> on whether runtime does have them or not).  At the moment I do the
> transformation only when -std=c99 or gnu99 is specified when the
> transformation is valid as the standard requires these functions.

But those switches are statements about what features the compiler
should accept, and compiler semantics.  They say nothing about the
library conformance of the target to C99, IMO.

Neil.

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Jan Hubicka writes:

Jan> As I've mentined I am handling this with the other patch that disables
Jan> the transfomration for C90 until we decide how to detect such systems.
Jan> On C99 and C++ it is always valid as runtime is required to have it (and
Jan> thats why libstdc++ does it).  I hope Richard will have time to take a
Jan> look on these patches soon.

	Would you please include a pointer to the patch?  I have been
browsing your patches and cannot find one that fixes this problem.

David

Re: basic-improvements merge status

[Jan Hubicka]

> >>>>> Jan Hubicka writes:
> 
> Jan> As I've mentined I am handling this with the other patch that disables
> Jan> the transfomration for C90 until we decide how to detect such systems.
> Jan> On C99 and C++ it is always valid as runtime is required to have it (and
> Jan> thats why libstdc++ does it).  I hope Richard will have time to take a
> Jan> look on these patches soon.
> 
> 	Would you please include a pointer to the patch?  I have been
> browsing your patches and cannot find one that fixes this problem.
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00619.html
honza
> 
> David

[libstdc++] Re: basic-improvements merge status

[Jan Hubicka]

> >>>>> Jan Hubicka writes:
> 
> Jan> As I've mentined I am handling this with the other patch that disables
> Jan> the transfomration for C90 until we decide how to detect such systems.
> Jan> On C99 and C++ it is always valid as runtime is required to have it (and
> Jan> thats why libstdc++ does it).  I hope Richard will have time to take a
> Jan> look on these patches soon.
> 
> 	Would you please include a pointer to the patch?  I have been
> browsing your patches and cannot find one that fixes this problem.
Hi,
and this should fix the builtins overwriting problem.
Even if we manage gcc to not do the transformation under certain
configurations, still this is more safe to do.

Honza

Mon Dec 16 23:53:16 CET 2002  Jan Hubicka  <jh@suse.cz>
	* Makefile.am (AM_CFLAGS): New.
Index: Makefile.am
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/libmath/Makefile.am,v
retrieving revision 1.20
diff -c -3 -p -r1.20 Makefile.am
*** Makefile.am	12 Sep 2002 23:27:30 -0000	1.20
--- Makefile.am	16 Dec 2002 22:53:03 -0000
*************** libmath_la_DEPENDENCIES = $(libmath_la_L
*** 34,39 ****
--- 34,43 ----
  
  libmath_la_SOURCES = stubs.c
  
+ # Avoid GCC transfroming (float)sin(float) into sinf causing infinite
+ # recursion.
+ AM_CFLAGS = -fno-builtins
+ 
  # Use common includes from acinclude.m4/GLIBCPP_EXPORT_INCLUDES
  TOPLEVEL_INCLUDES = @TOPLEVEL_INCLUDES@
  

Re: basic-improvements merge status

[Jan Hubicka]

> Jan Hubicka wrote:-
> 
> > > 
> > > 	Yes, it appears to be due to the builtins.def changes by Jan which
> > > assumes that all of those functions natively are available on every
> > > target.  One cannot make that assumption.  Testing for the existence of
> > > those functions on the target is not easy.
> > 
> > I noticed that already and there is patch waiting for that.  So hope it
> > will get reviewed soon.
> > I am not quite sure how to deal with this (whether we can autoconfigure
> > on whether runtime does have them or not).  At the moment I do the
> > transformation only when -std=c99 or gnu99 is specified when the
> > transformation is valid as the standard requires these functions.
> 
> But those switches are statements about what features the compiler
> should accept, and compiler semantics.  They say nothing about the
> library conformance of the target to C99, IMO.
The patch is more about adding infrastructure to specify about builtin
whether compiler can produce it implicitly than about the actual
decision.  I expected the thread open when I sent the patch, so perhaps
it happent now.
I see that doing this transformation is different from the other
decision we make based on language switch and would be happy about the
better alternative.

It is clear that in C99 environment this transformation is valid.
To my surprise it is important one.  In C90 compliant program there is
no other way to write such code and even after that people are still
using it, so the tranformation matches about houndred times in SPEC2000
and even more times in real world 3d programs, like Mesa, Crystal Space
and similar often in internal loops.
I would definitly like to see this enabled by default on Linux, that is
not the case if we conditionalize it by C99.

Honza
> 
> Neil.

Re: basic-improvements merge status

[Dale Johannesen]

On Monday, December 16, 2002, at 02:44  PM, Jan Hubicka wrote:
> On C99 and C++ it is always valid as runtime is required to have it 
> (and
> thats why libstdc++ does it).

According to the C99 standard, this is right, but GCC does not control 
the
runtime libraries.  What should the behavior of -std=c99 be, when 
generating code
for a target with non-C99-conformant libraries?

Re: basic-improvements merge status

[Benjamin Kosnik]

Your patch to libmath/Makefile.am is fine, but your ChangeLog entry
should say libmath/Makefile.am, not Makefile.am.

>I am not configure expert, but can I detect the runtime library
>properties in it?  (when we are building without glibc, we need to
>rebuild anyway at least on Linux bootstrap, so this should be possible)
>Other way would be to use target macro.  Something like
>TARGET_C99_RUNTIME.  Ideal would be to push these functions into libgcc,
>but I am not quite sure how this can be done (ie so they will be
>overwriten by runtime).
>What sounds sane?

See:

GLIBCPPP_USE_C99. This is on by default for gnu/linux.

Keep in mind that tests for C99, and decisions on what to enable or
partially enable WRT C99 support in the C++ runtime is a continuing area
of controversy, especially with respect to wide character support.

-benjamin

Re: basic-improvements merge status

[Andrew Pinski]

This is the same problem on Darwin but it shows up sooner and in the 
build of libmath.

Thanks,
Andrew Pinski

On Monday, Dec 16, 2002, at 14:38 US/Pacific, David Edelsohn wrote:

>>>>>> Jan Hubicka writes:
>
>>> #ifndef HAVE_SINF
>>> float
>>> sinf(float x)
>>> {
>>> return (float) sin(x);
>>> }
>>> #endif
>>>
>>> is being compiled as
>
> Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
> Jan> active on optimizing this.
> Jan> The name sinf is reserved by C90 standard, so this is not valid C.
>
> float
> foo (float x)
> {
>   return (float) sin(x);
> }
>
> always should be valid without the user having to specify 
> -fno-builtin, as
> your change requires on systems without sinf().  stubs.c could be 
> compiled
> with -fno-builtin, but that's just covering up the incorrect 
> assumption in
> the transformation.
>
> David
>

Re: basic-improvements merge status

[Jan Hubicka]

> Your patch to libmath/Makefile.am is fine, but your ChangeLog entry
> should say libmath/Makefile.am, not Makefile.am.
> 
> >I am not configure expert, but can I detect the runtime library
> >properties in it?  (when we are building without glibc, we need to
> >rebuild anyway at least on Linux bootstrap, so this should be possible)
> >Other way would be to use target macro.  Something like
> >TARGET_C99_RUNTIME.  Ideal would be to push these functions into libgcc,
> >but I am not quite sure how this can be done (ie so they will be
> >overwriten by runtime).
> >What sounds sane?
> 
> See:
> 
> GLIBCPPP_USE_C99. This is on by default for gnu/linux.

Uh yes, I need something like that available in gcc itself and not
locked to GLIBC only...

> 
> Keep in mind that tests for C99, and decisions on what to enable or
> partially enable WRT C99 support in the C++ runtime is a continuing area
> of controversy, especially with respect to wide character support.

In case we do have sinf and friends always defined by C++ runtime, this
is not problem as the names are reserved anyway.  I guess.

Honza
> 
> -benjamin

Re: basic-improvements merge status

[Jan Hubicka]

> 
> On Monday, December 16, 2002, at 02:44  PM, Jan Hubicka wrote:
> >On C99 and C++ it is always valid as runtime is required to have it 
> >(and
> >thats why libstdc++ does it).
> 
> According to the C99 standard, this is right, but GCC does not control 
> the
> runtime libraries.  What should the behavior of -std=c99 be, when 
> generating code
> for a target with non-C99-conformant libraries?

I don't know.  It is interesting combination at least (like C without
runtime).
It would be best to push these into libgcc when runtime does not
overwrite these.  Is that doable?  

Honza

Re: basic-improvements merge status

[Mark Mitchell]

--On Monday, December 16, 2002 11:18:28 PM +0100 Jan Hubicka <jh@suse.cz> 
wrote:

> I noticed that already and there is patch waiting for that.  So hope it
> will get reviewed soon.

Where is the patch?  I will review it for you.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Mark Mitchell]

--On Monday, December 16, 2002 11:50:51 PM +0100 Jan Hubicka <jh@suse.cz> 
wrote:

>> >>>>> Jan Hubicka writes:
>>
>> Jan> As I've mentined I am handling this with the other patch that
>> disables Jan> the transfomration for C90 until we decide how to detect
>> such systems. Jan> On C99 and C++ it is always valid as runtime is
>> required to have it (and Jan> thats why libstdc++ does it).  I hope
>> Richard will have time to take a Jan> look on these patches soon.
>>
>> 	Would you please include a pointer to the patch?  I have been
>> browsing your patches and cannot find one that fixes this problem.
> http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00619.html

I agree with Neil -- this isn't the right fix.  As he says, the C99
switch indicates that the source is C99 source; we should't make any
assumptions about the target library based on that.

Please revert, or at least disable, your change until we can figure out
how to do the configury bits.  (One possibility is explicitly flags in
the tm.h file.)

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Dale Johannesen]

On Monday, December 16, 2002, at 03:56  PM, Jan Hubicka wrote:

>>
>> On Monday, December 16, 2002, at 02:44  PM, Jan Hubicka wrote:
>>> On C99 and C++ it is always valid as runtime is required to have it
>>> (and
>>> thats why libstdc++ does it).
>>
>> According to the C99 standard, this is right, but GCC does not control
>> the
>> runtime libraries.  What should the behavior of -std=c99 be, when
>> generating code
>> for a target with non-C99-conformant libraries?
>
> I don't know.  It is interesting combination at least (like C without
> runtime).

"C without runtime" is known as "freestanding" in the standard, and
is actually well defined.  Is this something we want to support though?

Re: basic-improvements merge status

[Fergus Henderson]

On 16-Dec-2002, Dale Johannesen <dalej@apple.com> wrote:
> 
> On Monday, December 16, 2002, at 03:56  PM, Jan Hubicka wrote:
> 
> >>
> >> On Monday, December 16, 2002, at 02:44  PM, Jan Hubicka wrote:
> >>> On C99 and C++ it is always valid as runtime is required to have it
> >>> (and
> >>> thats why libstdc++ does it).
> >>
> >> According to the C99 standard, this is right, but GCC does not control
> >> the
> >> runtime libraries.  What should the behavior of -std=c99 be, when
> >> generating code
> >> for a target with non-C99-conformant libraries?
> >
> > I don't know.  It is interesting combination at least (like C without
> > runtime).
> 
> "C without runtime" is known as "freestanding" in the standard, and
> is actually well defined.  Is this something we want to support though?

Yes -- but only if the `-ffreestanding' option is specified.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: basic-improvements merge status

[Joseph S. Myers]

On Mon, 16 Dec 2002, Neil Booth wrote:

> But those switches are statements about what features the compiler
> should accept, and compiler semantics.  They say nothing about the
> library conformance of the target to C99, IMO.

-std=c89 says (unless -ffreestanding is used) that library function names
reserved in C90 may be presumed to have their C90 semantics, and built-in
functions may be optimised on that basis (while it also disables various
built-in functions that aren't in C90 but are accepted in gnu89 mode).  
-std=c99 says (unless -ffreestanding is used) the same thing for C99.  
Such presumptions may be avoided by -ffreestanding.  Note that the 
standards specify that the reserved function names are always reserved for 
functions with external linkage, irrespective of whether any headers are 
included (except for a special case in C94, where some new wide character 
function names are only reserved if certain headers are included somewhere 
in the program; this special case was removed in C99).

Of course it's still sensible to avoid generating calls to functions known
not to be present on the target, if calls to those functions weren't
present in the source code, just as we use TARGET_MEM_FUNCTIONS to know
whether to generate calls to the C90 mem* functions.  (Though in that case
I think that we should put the mem* functions in libgcc for targets
without them in libc and then generate calls to them unconditionally;  
this would need replacing TARGET_MEM_FUNCTIONS by a mechanism for
specifying, for the old targets without the functions that haven't had
support for them removed, which functions should be added to libgcc.  
Much the same mechanism could be used for sinf etc., though the benefits
are less and we don't have the information readily to hand in the target
headers to work out which systems need sinf defined.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: basic-improvements merge status

[Jan Hubicka]

> 
> 
> --On Monday, December 16, 2002 11:50:51 PM +0100 Jan Hubicka <jh@suse.cz> 
> wrote:
> 
> >>>>>>> Jan Hubicka writes:
> >>
> >>Jan> As I've mentined I am handling this with the other patch that
> >>disables Jan> the transfomration for C90 until we decide how to detect
> >>such systems. Jan> On C99 and C++ it is always valid as runtime is
> >>required to have it (and Jan> thats why libstdc++ does it).  I hope
> >>Richard will have time to take a Jan> look on these patches soon.
> >>
> >>	Would you please include a pointer to the patch?  I have been
> >>browsing your patches and cannot find one that fixes this problem.
> >http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00619.html
> 
> I agree with Neil -- this isn't the right fix.  As he says, the C99
> switch indicates that the source is C99 source; we should't make any
> assumptions about the target library based on that.

As I've mentioned, I was moslty interested in adding the extra bits to
allow/disallow implicit function call construction and hoped that we
will figure out the proper way to configure it on the way.
> 
> Please revert, or at least disable, your change until we can figure out

OK, I will disable the transfromation for the moment.
The change does more than just the this trick so I don't want to revert
it as a whole.

> how to do the configury bits.  (One possibility is explicitly flags in
> the tm.h file.)

WHat do you think is the correct way to handle it?

Honza
> 
> --
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Mark Mitchell]

> OK, I will disable the transfromation for the moment.

Thanks; that's fine.

>> how to do the configury bits.  (One possibility is explicitly flags in
>> the tm.h file.)
>
> What do you think is the correct way to handle it?

I'm not sure; I'm not a configury expert.  For a native build, I'd think
we could use autoconf; for a cross-build, that's a little tougher -- but
I'd think we could still do it.

The simplest approach would be something like TARGET_MEM_FUNCTIONS.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Gabriel Dos Reis]

David Edelsohn <dje@watson.ibm.com> writes:

| >>>>> Zack Weinberg writes:
| 
| Zack> David Edelsohn <dje@watson.ibm.com> writes:
| >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
| >> 
| >> (float) sin(x)
| >> 
| >> as
| >> 
| >> sinf(x)?
| 
| Zack> I remember such an optimization being implemented but I can't find the
| Zack> change log entry for it.  My recollection is that it was Jan Hubicka
| Zack> who coded it.  Jan?
| 
| 	Yes, it appears to be due to the builtins.def changes by Jan which
| assumes that all of those functions natively are available on every
| target.  One cannot make that assumption.  Testing for the existence of
| those functions on the target is not easy.

I think this is a case where GCC's logic in apply transformations just
breaks down.

| 	In most cases, the transformation will result in a linker error on
| systems which do not provide the function, but libstdc++-v3 graciously
| provides the symbols, creating a recursion in those definitions.

I don't think libstdc++-v3 is at fault here.  I think it is the
middle-end. That is, if as a programmer, I do know that the target is
lacking sinf() and consciously I did write "(float) sin(x)", then I
find it a diservice that GCC calls a sinf().  Really.

I see values for the mentioned transformation.  But bindly applying it
is a -not- a service.

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

[...]

| It is clear that in C99 environment this transformation is valid.

Well, it is precisely the *compiler's job* to provide that
environment.  Since it doesn't, because there no library support with
it), it is *wrong* to assume it is operating in C99 mode.  This is
just the usual bootstrap problem.

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> >OK, I will disable the transfromation for the moment.
> 
> Thanks; that's fine.
> 
> >>how to do the configury bits.  (One possibility is explicitly flags in
> >>the tm.h file.)
> >
> >What do you think is the correct way to handle it?
> 
> I'm not sure; I'm not a configury expert.  For a native build, I'd think
> we could use autoconf; for a cross-build, that's a little tougher -- but
> I'd think we could still do it.
> 
> The simplest approach would be something like TARGET_MEM_FUNCTIONS.

OK, I will create updated patch with TARGET_C99_FUNCTIONS macro and set
it via linux.h file.  Does this sound sane?
In next iteration we may add autoconf bits for this, but I would like to
hear opinion from someone more familiar with it than I do first.

Honza
> 
> -- 
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > 	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
| > AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
| > recursing.
| > 
| > #ifndef HAVE_SINF
| > float
| > sinf(float x)
| > {
| >   return (float) sin(x);
| > }
| > #endif
| > 
| > is being compiled as
| 
| I think we can deal with -fno-builtin-fsin to avoid gcc from being
| active on optimizing this.
| The name sinf is reserved by C90 standard, so this is not valid C.

This is part of the *compiler runtime support* so it does make sense
de define the sinf() function.

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> David Edelsohn <dje@watson.ibm.com> writes:
> 
> | >>>>> Zack Weinberg writes:
> | 
> | Zack> David Edelsohn <dje@watson.ibm.com> writes:
> | >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
> | >> 
> | >> (float) sin(x)
> | >> 
> | >> as
> | >> 
> | >> sinf(x)?
> | 
> | Zack> I remember such an optimization being implemented but I can't find the
> | Zack> change log entry for it.  My recollection is that it was Jan Hubicka
> | Zack> who coded it.  Jan?
> | 
> | 	Yes, it appears to be due to the builtins.def changes by Jan which
> | assumes that all of those functions natively are available on every
> | target.  One cannot make that assumption.  Testing for the existence of
> | those functions on the target is not easy.
> 
> I think this is a case where GCC's logic in apply transformations just
> breaks down.
> 
> | 	In most cases, the transformation will result in a linker error on
> | systems which do not provide the function, but libstdc++-v3 graciously
> | provides the symbols, creating a recursion in those definitions.
> 
> I don't think libstdc++-v3 is at fault here.  I think it is the
> middle-end. That is, if as a programmer, I do know that the target is
> lacking sinf() and consciously I did write "(float) sin(x)", then I
> find it a diservice that GCC calls a sinf().  Really.

Yes, I see that.
But it is really not different from reusing memset() call for totally
different purpose.  You function is not valid C so it should use
-fdisable-builtins.
> 
> I see values for the mentioned transformation.  But bindly applying it
> is a -not- a service.
In what conditions do you think we should apply that?

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> >OK, I will disable the transfromation for the moment.
> 
> Thanks; that's fine.
> 
> >>how to do the configury bits.  (One possibility is explicitly flags in
> >>the tm.h file.)
> >
> >What do you think is the correct way to handle it?
> 
> I'm not sure; I'm not a configury expert.  For a native build, I'd think
> we could use autoconf; for a cross-build, that's a little tougher -- but
> I'd think we could still do it.
> 
> The simplest approach would be something like TARGET_MEM_FUNCTIONS.
I've applied the attached patch.  It should solve the bootstrap problems
we are having right now and will prepare updated patch afternoon.
I have to leave for now so hope everything is OK.
THanks!

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 1.16126
diff -c -3 -p -r1.16126 ChangeLog
*** ChangeLog	17 Dec 2002 07:49:23 -0000	1.16126
--- ChangeLog	17 Dec 2002 08:50:06 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ Tue Dec 17 09:47:57 CET 2002  Jan Hubicka  <jh@suse.cz>
+ 
+ 	* convert.c (convert_to_real): Disable function transformation for
+ 	now.
+ 
  2002-12-16  Geoffrey Keating  <geoffk@apple.com>
  
  	* gcc.c (handle_braces): Allow '@' as a switch name.
Index: convert.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/convert.c,v
retrieving revision 1.20
diff -c -3 -p -r1.20 convert.c
*** convert.c	16 Dec 2002 18:19:13 -0000	1.20
--- convert.c	17 Dec 2002 08:50:07 -0000
*************** convert_to_real (type, expr)
*** 110,115 ****
--- 110,118 ----
    enum built_in_function fcode = builtin_mathfn_code (expr);
    tree itype = TREE_TYPE (expr);
  
+   /* Disable until we figure out how to decide whether the functions are
+      present in runtime.  */
+ #if 0
    /* Convert (float)sqrt((double)x) where x is float into sqrtf(x) */
    if ((fcode == BUILT_IN_SQRT
         || fcode == BUILT_IN_SQRTL
*************** convert_to_real (type, expr)
*** 196,201 ****
--- 199,205 ----
  	    }
  	}
      }
+ #endif
  
    /* Propagate the cast into the operation.  */
    if (itype != type && FLOAT_TYPE_P (type))

Re: basic-improvements merge status

[Gabriel Dos Reis]

David Edelsohn <dje@watson.ibm.com> writes:

| >>>>> Jan Hubicka writes:
| 
| >> #ifndef HAVE_SINF
| >> float
| >> sinf(float x)
| >> {
| >> return (float) sin(x);
| >> }
| >> #endif
| >> 
| >> is being compiled as
| 
| Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
| Jan> active on optimizing this.
| Jan> The name sinf is reserved by C90 standard, so this is not valid C.
| 
| 	Maybe libstdc++-v3/libmath/stubs.c should be compiled with
| -fno-builtins.

This is papering over broken assumptions made by the transformation.

Moreover, not all functions are missing at the same time.  So
-fno-builtin will be overly pessimistic an assumption.  There ought to
be a way to tell the compiler which library function not to optimize.

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> Jan Hubicka <jh@suse.cz> writes:
> 
> | > 	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
> | > AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
> | > recursing.
> | > 
> | > #ifndef HAVE_SINF
> | > float
> | > sinf(float x)
> | > {
> | >   return (float) sin(x);
> | > }
> | > #endif
> | > 
> | > is being compiled as
> | 
> | I think we can deal with -fno-builtin-fsin to avoid gcc from being
> | active on optimizing this.
> | The name sinf is reserved by C90 standard, so this is not valid C.
> 
> This is part of the *compiler runtime support* so it does make sense
> de define the sinf() function.
Yes, but what is wrong with compiling runtime with -fno-builtins to
avoid GCC from assuming that the reserved functions are used in usual
ways?

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> David Edelsohn <dje@watson.ibm.com> writes:
> 
> | >>>>> Jan Hubicka writes:
> | 
> | >> #ifndef HAVE_SINF
> | >> float
> | >> sinf(float x)
> | >> {
> | >> return (float) sin(x);
> | >> }
> | >> #endif
> | >> 
> | >> is being compiled as
> | 
> | Jan> I think we can deal with -fno-builtin-fsin to avoid gcc from being
> | Jan> active on optimizing this.
> | Jan> The name sinf is reserved by C90 standard, so this is not valid C.
> | 
> | 	Maybe libstdc++-v3/libmath/stubs.c should be compiled with
> | -fno-builtins.
> 
> This is papering over broken assumptions made by the transformation.
> 
> Moreover, not all functions are missing at the same time.  So
> -fno-builtin will be overly pessimistic an assumption.  There ought to
> be a way to tell the compiler which library function not to optimize.

-fno-builtin-sin does the trick.

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > 
| > On Monday, December 16, 2002, at 02:44  PM, Jan Hubicka wrote:
| > >On C99 and C++ it is always valid as runtime is required to have it 
| > >(and
| > >thats why libstdc++ does it).
| > 
| > According to the C99 standard, this is right, but GCC does not control 
| > the
| > runtime libraries.  What should the behavior of -std=c99 be, when 
| > generating code
| > for a target with non-C99-conformant libraries?
| 
| I don't know.  It is interesting combination at least (like C without
| runtime).
| It would be best to push these into libgcc when runtime does not
| overwrite these.  Is that doable?  

Does that mean that GCC will also provide a C library?

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| --On Monday, December 16, 2002 11:50:51 PM +0100 Jan Hubicka
| <jh@suse.cz> wrote:
| 
| >> >>>>> Jan Hubicka writes:
| >>
| >> Jan> As I've mentined I am handling this with the other patch that
| >> disables Jan> the transfomration for C90 until we decide how to detect
| >> such systems. Jan> On C99 and C++ it is always valid as runtime is
| >> required to have it (and Jan> thats why libstdc++ does it).  I hope
| >> Richard will have time to take a Jan> look on these patches soon.
| >>
| >> 	Would you please include a pointer to the patch?  I have been
| >> browsing your patches and cannot find one that fixes this problem.
| > http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00619.html
| 
| I agree with Neil -- this isn't the right fix.  As he says, the C99
| switch indicates that the source is C99 source; we should't make any
| assumptions about the target library based on that.
| 
| Please revert, or at least disable, your change until we can figure out
| how to do the configury bits.  (One possibility is explicitly flags in
| the tm.h file.)

100% agreed.

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > David Edelsohn <dje@watson.ibm.com> writes:
| > 
| > | >>>>> Zack Weinberg writes:
| > | 
| > | Zack> David Edelsohn <dje@watson.ibm.com> writes:
| > | >> Any idea what change in GCC 3.4BIB is causing GCC to "optimize"
| > | >> 
| > | >> (float) sin(x)
| > | >> 
| > | >> as
| > | >> 
| > | >> sinf(x)?
| > | 
| > | Zack> I remember such an optimization being implemented but I can't find the
| > | Zack> change log entry for it.  My recollection is that it was Jan Hubicka
| > | Zack> who coded it.  Jan?
| > | 
| > | 	Yes, it appears to be due to the builtins.def changes by Jan which
| > | assumes that all of those functions natively are available on every
| > | target.  One cannot make that assumption.  Testing for the existence of
| > | those functions on the target is not easy.
| > 
| > I think this is a case where GCC's logic in apply transformations just
| > breaks down.
| > 
| > | 	In most cases, the transformation will result in a linker error on
| > | systems which do not provide the function, but libstdc++-v3 graciously
| > | provides the symbols, creating a recursion in those definitions.
| > 
| > I don't think libstdc++-v3 is at fault here.  I think it is the
| > middle-end. That is, if as a programmer, I do know that the target is
| > lacking sinf() and consciously I did write "(float) sin(x)", then I
| > find it a diservice that GCC calls a sinf().  Really.
| 
| Yes, I see that.
| But it is really not different from reusing memset() call for totally
| different purpose.  You function is not valid C so it should use
| -fdisable-builtins.

Which function is not valid C? 

Please, do remember that libtdc++-v3 is part of the compiler runtime
support, so your argument that it is not valid is pointless.

| > I see values for the mentioned transformation.  But bindly applying it
| > is a -not- a service.
| In what conditions do you think we should apply that?

There ought to be a switch to tell the compiler which functions not to
use its transformations.

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > Jan Hubicka <jh@suse.cz> writes:
| > 
| > | > 	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
| > | > AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
| > | > recursing.
| > | > 
| > | > #ifndef HAVE_SINF
| > | > float
| > | > sinf(float x)
| > | > {
| > | >   return (float) sin(x);
| > | > }
| > | > #endif
| > | > 
| > | > is being compiled as
| > | 
| > | I think we can deal with -fno-builtin-fsin to avoid gcc from being
| > | active on optimizing this.
| > | The name sinf is reserved by C90 standard, so this is not valid C.
| > 
| > This is part of the *compiler runtime support* so it does make sense
| > de define the sinf() function.
| Yes, but what is wrong with compiling runtime with -fno-builtins to
| avoid GCC from assuming that the reserved functions are used in usual
| ways?

That is just papering over broken assumptions made by the tranformation.

I rather see the transformation applied only when there are confidence
that the result of the transformation will also run on the target. 

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > OK, I will disable the transfromation for the moment.
| 
| Thanks; that's fine.
| 
| >> how to do the configury bits.  (One possibility is explicitly flags in
| >> the tm.h file.)
| >
| > What do you think is the correct way to handle it?
| 
| I'm not sure; I'm not a configury expert.  For a native build, I'd think
| we could use autoconf; for a cross-build, that's a little tougher -- but
| I'd think we could still do it.

Yes, I think we should be able (using Autoconf) to produce a swicth
like after usual tests.

   --without-library-functions='sinf,cosf, blah blah'

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| -fno-builtin-sin does the trick.

The issue isn't about the lack of built-in sin.  It is about lack of
support (either hardwired or in library) for sin{, f,l}.

That is, when applying the transformation, the compiler should know
about which functions it may freely use without producing a bogus
result. 

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > 	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
| > AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
| > recursing.
| > 
| > #ifndef HAVE_SINF
| > float
| > sinf(float x)
| > {
| >   return (float) sin(x);
| > }
| > #endif
| > 
| > is being compiled as
| 
| I think we can deal with -fno-builtin-fsin to avoid gcc from being
| active on optimizing this.
| The name sinf is reserved by C90 standard, so this is not valid C.

This is part of the *compiler runtime support* so it does make sense
de define the sinf() function.

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > Jan Hubicka <jh@suse.cz> writes:
| > 
| > | > 	The GCC 3.4BIB libstdc++-v3 failure of 26_numerics/c_math.cc on
| > | > AIX is occurring because libstdc++-v3/libmath/stubs.c functions are
| > | > recursing.
| > | > 
| > | > #ifndef HAVE_SINF
| > | > float
| > | > sinf(float x)
| > | > {
| > | >   return (float) sin(x);
| > | > }
| > | > #endif
| > | > 
| > | > is being compiled as
| > | 
| > | I think we can deal with -fno-builtin-fsin to avoid gcc from being
| > | active on optimizing this.
| > | The name sinf is reserved by C90 standard, so this is not valid C.
| > 
| > This is part of the *compiler runtime support* so it does make sense
| > de define the sinf() function.
| Yes, but what is wrong with compiling runtime with -fno-builtins to
| avoid GCC from assuming that the reserved functions are used in usual
| ways?

That is just papering over broken assumptions made by the tranformation.

I rather see the transformation applied only when there are confidence
that the result of the transformation will also run on the target. 

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > The simplest approach would be something like TARGET_MEM_FUNCTIONS.
| I've applied the attached patch.

Thanks!

-- Gaby

Re: basic-improvements merge status

[Joseph S. Myers]

On 17 Dec 2002, Gabriel Dos Reis wrote:

> | I don't know.  It is interesting combination at least (like C without
> | runtime).
> | It would be best to push these into libgcc when runtime does not
> | overwrite these.  Is that doable?  
> 
> Does that mean that GCC will also provide a C library?

No, rather that it would fix deficiencies in the C library just like
fixincludes presently fixes some deficiencies in the headers (including
making sure that certain headers do exist on the target).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: basic-improvements merge status

[Joseph S. Myers]

On Tue, 17 Dec 2002, Jan Hubicka wrote:

> > The simplest approach would be something like TARGET_MEM_FUNCTIONS.
> 
> OK, I will create updated patch with TARGET_C99_FUNCTIONS macro and set
> it via linux.h file.  Does this sound sane?

(a) The macro should be defined so that the normal sense (no definition in 
the .h file) is that the C99 functions _are_ available, as this will be 
usual in future.  TARGET_MEM_FUNCTIONS is the wrong way round; using the 
standard functions should be the default.

(b) If the approach of replacing missing functions in libgcc is followed 
(which can also get rid of TARGET_MEM_FUNCTIONS) then it might be more 
appropriate to use a list in config.gcc of missing C library functions 
that need to go in libgcc.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: basic-improvements merge status

[Jan Hubicka]

> Jan Hubicka <jh@suse.cz> writes:
> 
> | -fno-builtin-sin does the trick.
> 
> The issue isn't about the lack of built-in sin.  It is about lack of
> support (either hardwired or in library) for sin{, f,l}.

libstdc++ does provide these.  All we need is to move them into libgcc
and use -fno-builtin-sin to compile file in question.
What do you see wrong about using the -fno-builtin to compile runtime
support that must be done in a way breaking C90 standard?

Honza
> 
> That is, when applying the transformation, the compiler should know
> about which functions it may freely use without producing a bogus
> result. 
> 
> -- Gaby

Hot to configure sinf?

[Jan Hubicka]

Hi,
We've discussed several possible sollutions.  So far we have

1) Follow scheme of TARGET_MEM_FUNCTIONS and define it in linux.h and
friends
2) Same as 1) but default to 1 and override it for broken targets
3) Same as 1) but use autoconf to determine presence of builtins for
noncrosscompiler builds
4) Push missing functions into libgcc with config.gcc having list of
missing functions  (that would remove the libstdc++ issues too)
(I see possible problem here for configurations with multiple runtimes,
like cygwin/mingw)

What sounds most plausible?
4) looks most robust, but the optimization is pointless when sin/cos and
friends are avialbale only via libgcc hiding the cast... So I tend to
imply to 1)-3).  I will implement TARGET_C99_MATH_FUNCTIONS patch and we
can discuss futher steps.

Honza

Re: basic-improvements merge status

[Fergus Henderson]

On 17-Dec-2002, Jan Hubicka <jh@suse.cz> wrote:
> > Jan Hubicka <jh@suse.cz> writes:
> > 
> > | -fno-builtin-sin does the trick.
> > 
> > The issue isn't about the lack of built-in sin.  It is about lack of
> > support (either hardwired or in library) for sin{, f,l}.
> 
> libstdc++ does provide these.  All we need is to move them into libgcc
> and use -fno-builtin-sin to compile file in question.
> What do you see wrong about using the -fno-builtin to compile runtime
> support that must be done in a way breaking C90 standard?

Another option would be to build the files in question with -ffreestanding
(and to make sure the optimization is disabled if -ffreestanding is used --
if it is not, that is a bug).  That makes sense to me: those files are
part of the implementation of the C library, so GCC can't assume that
there is a C library already when compiling those files.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: basic-improvements merge status

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| (b) If the approach of replacing missing functions in libgcc is followed 
| (which can also get rid of TARGET_MEM_FUNCTIONS) then it might be more 
| appropriate to use a list in config.gcc of missing C library functions 
| that need to go in libgcc.

I would favor an approach where the list of missing C functions can be
specified by the user at any time -- not just at configure time.

-- Gaby

Re: Hot to configure sinf?

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

[...]

| 3) Same as 1) but use autoconf to determine presence of builtins for
| noncrosscompiler builds
| 4) Push missing functions into libgcc with config.gcc having list of
| missing functions  (that would remove the libstdc++ issues too)
| (I see possible problem here for configurations with multiple runtimes,
| like cygwin/mingw)
| 
| What sounds most plausible?

I'm leaning toward 3) since it is clearly C/C++ specific and much
flexible. 

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > Jan Hubicka <jh@suse.cz> writes:
| > 
| > | -fno-builtin-sin does the trick.
| > 
| > The issue isn't about the lack of built-in sin.  It is about lack of
| > support (either hardwired or in library) for sin{, f,l}.
| 
| libstdc++ does provide these.  All we need is to move them into libgcc
| and use -fno-builtin-sin to compile file in question.
| What do you see wrong about using the -fno-builtin to compile runtime
| support that must be done in a way breaking C90 standard?

My grip about -fno-builtin is that it operates (at least that is my
understanding) in a yes/no mode whereas in practice we need something
that can understand gray variation.  That is, the builtins are not all
missing at the same time; we should be able to make the compiler
understand that. 

-- Gaby

Re: basic-improvements merge status

[Mark Mitchell]

--On Tuesday, December 17, 2002 09:46:35 AM +0100 Jan Hubicka <jh@suse.cz> 
wrote:

> OK, I will create updated patch with TARGET_C99_FUNCTIONS macro and set
> it via linux.h file.  Does this sound sane?

It sounds OK to me, but it sounds like some people (for example, Gaby)
think we can do better via autoconf.  It we can do it with autoconf,
that's better, I guess.

Would you explore that alternative?  If that doesn't look doable, then,
yes, TARGET_C99_FUNCTIONS sounds good.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Joseph S. Myers]

On 17 Dec 2002, Gabriel Dos Reis wrote:

> I would favor an approach where the list of missing C functions can be
> specified by the user at any time -- not just at configure time.

There are the separate questions of:

* Which C functions are available to generate calls to (runtime with some
compile time default).
* Which C functions should be replaced in libgcc (as sinf etc. are
presently replaced in libstdc++) (compile time).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: basic-improvements merge status

[Jan Hubicka]

> Jan Hubicka <jh@suse.cz> writes:
> 
> | > Jan Hubicka <jh@suse.cz> writes:
> | > 
> | > | -fno-builtin-sin does the trick.
> | > 
> | > The issue isn't about the lack of built-in sin.  It is about lack of
> | > support (either hardwired or in library) for sin{, f,l}.
> | 
> | libstdc++ does provide these.  All we need is to move them into libgcc
> | and use -fno-builtin-sin to compile file in question.
> | What do you see wrong about using the -fno-builtin to compile runtime
> | support that must be done in a way breaking C90 standard?
> 
> My grip about -fno-builtin is that it operates (at least that is my
> understanding) in a yes/no mode whereas in practice we need something
> that can understand gray variation.  That is, the builtins are not all
> missing at the same time; we should be able to make the compiler
> understand that. 
We do have -fno-builtin-FUNCTION for exactly that.

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> 
> 
> --On Tuesday, December 17, 2002 09:46:35 AM +0100 Jan Hubicka <jh@suse.cz> 
> wrote:
> 
> >OK, I will create updated patch with TARGET_C99_FUNCTIONS macro and set
> >it via linux.h file.  Does this sound sane?
> 
> It sounds OK to me, but it sounds like some people (for example, Gaby)
> think we can do better via autoconf.  It we can do it with autoconf,
> that's better, I guess.
What I don't like about autoconf is that we can't do that completely
reliably - we can't do that when cross compiling or when there are
multiple possible runtime, like in mingw.

I will send the TARGET_* as soon as I finish testing and lets discuss
futher improvement on top of that.  OK?

Honza
> 
> Would you explore that alternative?  If that doesn't look doable, then,
> yes, TARGET_C99_FUNCTIONS sounds good.
> 
> -- 
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| > 
| > 
| > --On Tuesday, December 17, 2002 09:46:35 AM +0100 Jan Hubicka <jh@suse.cz> 
| > wrote:
| > 
| > >OK, I will create updated patch with TARGET_C99_FUNCTIONS macro and set
| > >it via linux.h file.  Does this sound sane?
| > 
| > It sounds OK to me, but it sounds like some people (for example, Gaby)
| > think we can do better via autoconf.  It we can do it with autoconf,
| > that's better, I guess.
| What I don't like about autoconf is that we can't do that completely
| reliably - we can't do that when cross compiling or when there are
| multiple possible runtime, like in mingw.

When cross-compiling, it is to be expected that the person doing the
build will provide the list of assumed missing functions.  It is no
different from the usual constraints when cross-compiling.

-- Gaby

Implicit generation of runtime calls

[Jan Hubicka]

Hi,
this patch adds the infrastructure to determine whether the function call can
be produced implicitly or not.  I am doing that by new array of declarations
implicit_built_in_decls that has entry nonzero just for those builtins that are
safe.
In future we may want to modify the declarations so the builtin expansion can
behave differently for implicit calls as they do already for __builtin_XXX calls
and XXX calls.

DEF_BUILTIN now allows to declare whehter the function is available and I've
categorized the functions according to C99 and C90 standards.
I also added the TARGET_C99_FUNCTIONS defined to 1 by default and function
to get the declaration in proper mode so conversions can be done easilly.

Thats it.  In the next step I would like to re-enable the transformation as
next step once this part is polished.  I would also like to turn
TARGET_MEM_FUNCTIONS into this scheme.  I intended to do this in one step but
the patch is getting bigger than I would like it to be already.

I will happily add -fno-c99-builtins switch to configure and manage it to
control TARGET_C99_FUNCTIONS if someone will make me believe that this is good.
I think this is static knowledge about the particular port and the problems
with autoconfiguration being different in different contexts, so it will
bring us problems in reproducing failures reported in cross envorinment
and so on.

I also don't think it makes sense to allow controlling each function
individually.  We already support about 10-20 such functions and the number of
them will increase.  I don't think runtimes are crazy enought to commonly
support just arbitary subset of these, so this would just anoy.  We can invent
1-2 new categories (perhaps there can be category for runtimes deifning sinf
but not sinl or cabs if such exists)

Bootstrapped/regtested mainline.
OK?

Honza

	* builtins.c (DEF_BUILTIN): Accept 10 arguments.
	(implicit_built_in_decls): New global array.
	(mathfn_built_in): New global function.
	(fold_trunc_transparent_mathfn): New static function
	(expand_builtin_strstr, expand_bultin_strchr,
	expand_builtin_strpbrk, expand_builtin_strcpy,
	expand_builtin_strncpy, expand_bultin_strcmp,
	expand_bultin_strncat, expand_builtin_fputs): Use
	implicint_built_in_decls.
	(fold_builtin): Fold floor/trunc/round/ceil/nearbyint.
	* builtins.def: Fix comments.
	(DEF_GCC_BUILTIN, DEF_FALLBACK_BUILTIN, DEF_EXT_FALLBACK_BUILTIN,
	DEF_LIB_BUILTIN, DEF_LIB_ALWAYS_BUILTIN, DEF_EXT_LIB_BUILTIN,
	DEF_C99_BULTIN, DEF_FRONT_END_LIB_BUILTIN,
	DEF_EXT_FRONT_END_LIB_BUILTIN): Pass implicit as needed.
	(DEF_C99_C90RES_BULTIN): New.
	(*f, *l builtins): Update.
	* c-common.c (DEF_BUILTIN): Initialize implicit array.
	(c_expand_builtin_printf, c_expand_builtin_fprintf): Update.
	* convert.c (strip_float_extensions): New global function.
	* tree.h (DEF_BUILTIN): Accept 10 arguments.
	(implicit_built_in_decls, mathfn_built_in, strip_float_extension):
	Declare.
	* java/builtins.c (define_builtin): Handle implicit.
	(DEF_BUILTIN): Update.
	* tm.texi (TARGET_C99_FUNCTIONS): Document.
	* defaults.h (TARGET_C99_FUNCTIONS): Default to 0.

Index: builtins.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/builtins.c,v
retrieving revision 1.166
diff -c -3 -p -r1.166 builtins.c
*** builtins.c	16 Dec 2002 18:18:59 -0000	1.166
--- builtins.c	17 Dec 2002 22:02:45 -0000
*************** Software Foundation, 59 Temple Place - S
*** 64,70 ****
  const char *const built_in_class_names[4]
    = {"NOT_BUILT_IN", "BUILT_IN_FRONTEND", "BUILT_IN_MD", "BUILT_IN_NORMAL"};
  
! #define DEF_BUILTIN(X, N, C, T, LT, B, F, NA, AT) STRINGX(X),
  const char *const built_in_names[(int) END_BUILTINS] =
  {
  #include "builtins.def"
--- 64,70 ----
  const char *const built_in_class_names[4]
    = {"NOT_BUILT_IN", "BUILT_IN_FRONTEND", "BUILT_IN_MD", "BUILT_IN_NORMAL"};
  
! #define DEF_BUILTIN(X, N, C, T, LT, B, F, NA, AT, IM) STRINGX(X),
  const char *const built_in_names[(int) END_BUILTINS] =
  {
  #include "builtins.def"
*************** const char *const built_in_names[(int) E
*** 74,79 ****
--- 74,83 ----
  /* Setup an array of _DECL trees, make sure each element is
     initialized to NULL_TREE.  */
  tree built_in_decls[(int) END_BUILTINS];
+ /* Declarations used when constructing the builtin implicitly in the compiler.
+    It may be NULL_TREE when this is invalid (for instance runtime is not
+    required to implement the function call in all cases.  */
+ tree implicit_built_in_decls[(int) END_BUILTINS];
  
  static int get_pointer_alignment	PARAMS ((tree, unsigned int));
  static tree c_strlen			PARAMS ((tree));
*************** static tree fold_builtin_classify_type	P
*** 153,158 ****
--- 157,163 ----
  static tree fold_builtin_inf		PARAMS ((tree, int));
  static tree fold_builtin_nan		PARAMS ((tree, tree, int));
  static int validate_arglist		PARAMS ((tree, ...));
+ static tree fold_trunc_transparent_mathfn PARAMS ((tree));
  
  /* Return the alignment in bits of EXP, a pointer valued expression.
     But don't return more than MAX_ALIGN no matter what.
*************** expand_builtin_constant_p (exp)
*** 1469,1474 ****
--- 1474,1643 ----
    return tmp;
  }
  
+ /* Return mathematic function equivalent to FN but operating directly on TYPE,
+    if available.  */
+ tree
+ mathfn_built_in (type, fn)
+      tree type;
+      enum built_in_function fn;
+ {
+   enum built_in_function fcode = NOT_BUILT_IN;
+   if (TYPE_MODE (type) == TYPE_MODE (double_type_node))
+     switch (fn)
+       {
+       case BUILT_IN_SQRT:
+       case BUILT_IN_SQRTF:
+       case BUILT_IN_SQRTL:
+ 	fcode = BUILT_IN_SQRT;
+ 	break;
+       case BUILT_IN_SIN:
+       case BUILT_IN_SINF:
+       case BUILT_IN_SINL:
+ 	fcode = BUILT_IN_SIN;
+ 	break;
+       case BUILT_IN_COS:
+       case BUILT_IN_COSF:
+       case BUILT_IN_COSL:
+ 	fcode = BUILT_IN_COS;
+ 	break;
+       case BUILT_IN_EXP:
+       case BUILT_IN_EXPF:
+       case BUILT_IN_EXPL:
+ 	fcode = BUILT_IN_EXP;
+ 	break;
+       case BUILT_IN_FLOOR:
+       case BUILT_IN_FLOORF:
+       case BUILT_IN_FLOORL:
+ 	fcode = BUILT_IN_FLOOR;
+ 	break;
+       case BUILT_IN_CEIL:
+       case BUILT_IN_CEILF:
+       case BUILT_IN_CEILL:
+ 	fcode = BUILT_IN_CEIL;
+ 	break;
+       case BUILT_IN_TRUNC:
+       case BUILT_IN_TRUNCF:
+       case BUILT_IN_TRUNCL:
+ 	fcode = BUILT_IN_TRUNC;
+ 	break;
+       case BUILT_IN_ROUND:
+       case BUILT_IN_ROUNDF:
+       case BUILT_IN_ROUNDL:
+ 	fcode = BUILT_IN_ROUND;
+ 	break;
+       case BUILT_IN_NEARBYINT:
+       case BUILT_IN_NEARBYINTF:
+       case BUILT_IN_NEARBYINTL:
+ 	fcode = BUILT_IN_NEARBYINT;
+ 	break;
+       default:
+ 	abort ();
+       }
+   else if (TYPE_MODE (type) == TYPE_MODE (float_type_node))
+     switch (fn)
+       {
+       case BUILT_IN_SQRT:
+       case BUILT_IN_SQRTF:
+       case BUILT_IN_SQRTL:
+ 	fcode = BUILT_IN_SQRTF;
+ 	break;
+       case BUILT_IN_SIN:
+       case BUILT_IN_SINF:
+       case BUILT_IN_SINL:
+ 	fcode = BUILT_IN_SINF;
+ 	break;
+       case BUILT_IN_COS:
+       case BUILT_IN_COSF:
+       case BUILT_IN_COSL:
+ 	fcode = BUILT_IN_COSF;
+ 	break;
+       case BUILT_IN_EXP:
+       case BUILT_IN_EXPF:
+       case BUILT_IN_EXPL:
+ 	fcode = BUILT_IN_EXPF;
+ 	break;
+       case BUILT_IN_FLOOR:
+       case BUILT_IN_FLOORF:
+       case BUILT_IN_FLOORL:
+ 	fcode = BUILT_IN_FLOORF;
+ 	break;
+       case BUILT_IN_CEIL:
+       case BUILT_IN_CEILF:
+       case BUILT_IN_CEILL:
+ 	fcode = BUILT_IN_CEILF;
+ 	break;
+       case BUILT_IN_TRUNC:
+       case BUILT_IN_TRUNCF:
+       case BUILT_IN_TRUNCL:
+ 	fcode = BUILT_IN_TRUNCF;
+ 	break;
+       case BUILT_IN_ROUND:
+       case BUILT_IN_ROUNDF:
+       case BUILT_IN_ROUNDL:
+ 	fcode = BUILT_IN_ROUNDF;
+ 	break;
+       case BUILT_IN_NEARBYINT:
+       case BUILT_IN_NEARBYINTF:
+       case BUILT_IN_NEARBYINTL:
+ 	fcode = BUILT_IN_NEARBYINTF;
+ 	break;
+       default:
+ 	abort ();
+       }
+   else if (TYPE_MODE (type) == TYPE_MODE (long_double_type_node))
+     switch (fn)
+       {
+       case BUILT_IN_SQRT:
+       case BUILT_IN_SQRTF:
+       case BUILT_IN_SQRTL:
+ 	fcode = BUILT_IN_SQRTL;
+ 	break;
+       case BUILT_IN_SIN:
+       case BUILT_IN_SINF:
+       case BUILT_IN_SINL:
+ 	fcode = BUILT_IN_SINL;
+ 	break;
+       case BUILT_IN_COS:
+       case BUILT_IN_COSF:
+       case BUILT_IN_COSL:
+ 	fcode = BUILT_IN_COSL;
+ 	break;
+       case BUILT_IN_EXP:
+       case BUILT_IN_EXPF:
+       case BUILT_IN_EXPL:
+ 	fcode = BUILT_IN_EXPL;
+ 	break;
+       case BUILT_IN_FLOOR:
+       case BUILT_IN_FLOORF:
+       case BUILT_IN_FLOORL:
+ 	fcode = BUILT_IN_FLOORL;
+ 	break;
+       case BUILT_IN_CEIL:
+       case BUILT_IN_CEILF:
+       case BUILT_IN_CEILL:
+ 	fcode = BUILT_IN_CEILL;
+ 	break;
+       case BUILT_IN_TRUNC:
+       case BUILT_IN_TRUNCF:
+       case BUILT_IN_TRUNCL:
+ 	fcode = BUILT_IN_TRUNCL;
+ 	break;
+       case BUILT_IN_ROUND:
+       case BUILT_IN_ROUNDF:
+       case BUILT_IN_ROUNDL:
+ 	fcode = BUILT_IN_ROUNDL;
+ 	break;
+       case BUILT_IN_NEARBYINT:
+       case BUILT_IN_NEARBYINTF:
+       case BUILT_IN_NEARBYINTL:
+ 	fcode = BUILT_IN_NEARBYINTL;
+ 	break;
+       default:
+ 	abort ();
+       }
+   return implicit_built_in_decls[fcode];
+ }
+ 
  /* Expand a call to one of the builtin math functions (sin, cos, or sqrt).
     Return 0 if a normal call should be emitted rather than expanding the
     function in-line.  EXP is the expression that is a call to the builtin
*************** expand_builtin_strstr (arglist, target, 
*** 1756,1762 ****
        if (p2[1] != '\0')
  	return 0;
  
!       fn = built_in_decls[BUILT_IN_STRCHR];
        if (!fn)
  	return 0;
  
--- 1925,1931 ----
        if (p2[1] != '\0')
  	return 0;
  
!       fn = implicit_built_in_decls[BUILT_IN_STRCHR];
        if (!fn)
  	return 0;
  
*************** expand_builtin_strrchr (arglist, target,
*** 1860,1866 ****
        if (! integer_zerop (s2))
  	return 0;
  
!       fn = built_in_decls[BUILT_IN_STRCHR];
        if (!fn)
  	return 0;
  
--- 2029,2035 ----
        if (! integer_zerop (s2))
  	return 0;
  
!       fn = implicit_built_in_decls[BUILT_IN_STRCHR];
        if (!fn)
  	return 0;
  
*************** expand_builtin_strpbrk (arglist, target,
*** 1918,1924 ****
        if (p2[1] != '\0')
  	return 0;  /* Really call strpbrk.  */
  
!       fn = built_in_decls[BUILT_IN_STRCHR];
        if (!fn)
  	return 0;
  
--- 2087,2093 ----
        if (p2[1] != '\0')
  	return 0;  /* Really call strpbrk.  */
  
!       fn = implicit_built_in_decls[BUILT_IN_STRCHR];
        if (!fn)
  	return 0;
  
*************** expand_builtin_strcpy (exp, target, mode
*** 2057,2063 ****
    if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
      return 0;
  
!   fn = built_in_decls[BUILT_IN_MEMCPY];
    if (!fn)
      return 0;
  
--- 2226,2232 ----
    if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
      return 0;
  
!   fn = implicit_built_in_decls[BUILT_IN_MEMCPY];
    if (!fn)
      return 0;
  
*************** expand_builtin_strncpy (arglist, target,
*** 2159,2165 ****
  	}
  
        /* OK transform into builtin memcpy.  */
!       fn = built_in_decls[BUILT_IN_MEMCPY];
        if (!fn)
  	return 0;
        return expand_expr (build_function_call_expr (fn, arglist),
--- 2328,2334 ----
  	}
  
        /* OK transform into builtin memcpy.  */
!       fn = implicit_built_in_decls[BUILT_IN_MEMCPY];
        if (!fn)
  	return 0;
        return expand_expr (build_function_call_expr (fn, arglist),
*************** expand_builtin_strcmp (exp, target, mode
*** 2575,2581 ****
    if (TREE_SIDE_EFFECTS (len))
      return 0;
  
!   fn = built_in_decls[BUILT_IN_MEMCMP];
    if (!fn)
      return 0;
  
--- 2744,2750 ----
    if (TREE_SIDE_EFFECTS (len))
      return 0;
  
!   fn = implicit_built_in_decls[BUILT_IN_MEMCMP];
    if (!fn)
      return 0;
  
*************** expand_builtin_strncmp (exp, target, mod
*** 2669,2675 ****
    if (!len)
      return 0;
  
!   fn = built_in_decls[BUILT_IN_MEMCMP];
    if (!fn)
      return 0;
  
--- 2838,2844 ----
    if (!len)
      return 0;
  
!   fn = implicit_built_in_decls[BUILT_IN_MEMCMP];
    if (!fn)
      return 0;
  
*************** expand_builtin_strncat (arglist, target,
*** 2750,2756 ****
  	{
  	  tree newarglist
  	    = tree_cons (NULL_TREE, dst, build_tree_list (NULL_TREE, src));
! 	  tree fn = built_in_decls[BUILT_IN_STRCAT];
  
  	  /* If the replacement _DECL isn't initialized, don't do the
  	     transformation.  */
--- 2919,2925 ----
  	{
  	  tree newarglist
  	    = tree_cons (NULL_TREE, dst, build_tree_list (NULL_TREE, src));
! 	  tree fn = implicit_built_in_decls[BUILT_IN_STRCAT];
  
  	  /* If the replacement _DECL isn't initialized, don't do the
  	     transformation.  */
*************** expand_builtin_strcspn (arglist, target,
*** 2838,2844 ****
        if (p2 && *p2 == '\0')
  	{
  	  tree newarglist = build_tree_list (NULL_TREE, s1),
! 	    fn = built_in_decls[BUILT_IN_STRLEN];
  
  	  /* If the replacement _DECL isn't initialized, don't do the
  	     transformation.  */
--- 3007,3013 ----
        if (p2 && *p2 == '\0')
  	{
  	  tree newarglist = build_tree_list (NULL_TREE, s1),
! 	    fn = implicit_built_in_decls[BUILT_IN_STRLEN];
  
  	  /* If the replacement _DECL isn't initialized, don't do the
  	     transformation.  */
*************** expand_builtin_fputs (arglist, ignore, u
*** 3445,3454 ****
       int unlocked;
  {
    tree len, fn;
!   tree fn_fputc = unlocked ? built_in_decls[BUILT_IN_FPUTC_UNLOCKED]
!     : built_in_decls[BUILT_IN_FPUTC];
!   tree fn_fwrite = unlocked ? built_in_decls[BUILT_IN_FWRITE_UNLOCKED]
!     : built_in_decls[BUILT_IN_FWRITE];
  
    /* If the return value is used, or the replacement _DECL isn't
       initialized, don't do the transformation.  */
--- 3614,3623 ----
       int unlocked;
  {
    tree len, fn;
!   tree fn_fputc = unlocked ? implicit_built_in_decls[BUILT_IN_FPUTC_UNLOCKED]
!     : implicit_built_in_decls[BUILT_IN_FPUTC];
!   tree fn_fwrite = unlocked ? implicit_built_in_decls[BUILT_IN_FWRITE_UNLOCKED]
!     : implicit_built_in_decls[BUILT_IN_FWRITE];
  
    /* If the return value is used, or the replacement _DECL isn't
       initialized, don't do the transformation.  */
Index: builtins.def
===================================================================
RCS file: /cvs/gcc/gcc/gcc/builtins.def,v
retrieving revision 1.40
diff -c -3 -p -r1.40 builtins.def
*** builtins.def	16 Dec 2002 18:19:00 -0000	1.40
--- builtins.def	17 Dec 2002 22:02:46 -0000
*************** Software Foundation, 59 Temple Place - S
*** 22,28 ****
  /* Before including this file, you should define a macro:
  
       DEF_BUILTIN (ENUM, NAME, CLASS, TYPE, LIBTYPE, BOTH_P,
!                   FALLBACK_P, NONANSI_P, ATTRS)
  
     This macro will be called once for each builtin function.  The
     ENUM will be of type `enum built_in_function', and will indicate
--- 22,28 ----
  /* Before including this file, you should define a macro:
  
       DEF_BUILTIN (ENUM, NAME, CLASS, TYPE, LIBTYPE, BOTH_P,
!                   FALLBACK_P, NONANSI_P, ATTRS, IMPLICIT)
  
     This macro will be called once for each builtin function.  The
     ENUM will be of type `enum built_in_function', and will indicate
*************** Software Foundation, 59 Temple Place - S
*** 53,59 ****
     exist when compiling in ANSI conformant mode.
  
     ATTRs is an attribute list as defined in builtin-attrs.def that
!    describes the attributes of this builtin function.  */
     
  /* A GCC builtin (like __builtin_saveregs) is provided by the
     compiler, but does not correspond to a function in the standard
--- 53,65 ----
     exist when compiling in ANSI conformant mode.
  
     ATTRs is an attribute list as defined in builtin-attrs.def that
!    describes the attributes of this builtin function.  
! 
!    IMPLICIT specifies condition when the builtin can be produced by
!    compiler.  For instance C90 reserves floorf function, but does not
!    define it's meaning.  When user uses floorf we may assume that the
!    floorf has the meaning we expect, but we can't produce floorf by
!    simplifing floor((double)float) since runtime don't need to implement it.  */
     
  /* A GCC builtin (like __builtin_saveregs) is provided by the
     compiler, but does not correspond to a function in the standard
*************** Software Foundation, 59 Temple Place - S
*** 61,67 ****
  #undef DEF_GCC_BUILTIN
  #define DEF_GCC_BUILTIN(ENUM, NAME, TYPE, ATTRS)		\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, BT_LAST,	\
!                false, false, false, ATTRS)
  
  
  /* A fallback builtin is a builtin (like __builtin_puts) that falls
--- 67,73 ----
  #undef DEF_GCC_BUILTIN
  #define DEF_GCC_BUILTIN(ENUM, NAME, TYPE, ATTRS)		\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, BT_LAST,	\
!                false, false, false, ATTRS, true)
  
  
  /* A fallback builtin is a builtin (like __builtin_puts) that falls
*************** Software Foundation, 59 Temple Place - S
*** 71,77 ****
  #undef DEF_FALLBACK_BUILTIN				
  #define DEF_FALLBACK_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
! 	       false, true, false, ATTRS)
  
  /* Like DEF_FALLBACK_BUILTIN, except that the function is not one that
     is specified by ANSI/ISO C.  So, when we're being fully conformant
--- 77,83 ----
  #undef DEF_FALLBACK_BUILTIN				
  #define DEF_FALLBACK_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
! 	       false, true, false, ATTRS, true)
  
  /* Like DEF_FALLBACK_BUILTIN, except that the function is not one that
     is specified by ANSI/ISO C.  So, when we're being fully conformant
*************** Software Foundation, 59 Temple Place - S
*** 80,86 ****
  #undef DEF_EXT_FALLBACK_BUILTIN
  #define DEF_EXT_FALLBACK_BUILTIN(ENUM, NAME, TYPE)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
! 	       false, true, true, ATTR_NOTHROW_LIST)
  
  /* A library builtin (like __builtin_strchr) is a builtin equivalent
     of an ANSI/ISO standard library function.  In addition to the
--- 86,92 ----
  #undef DEF_EXT_FALLBACK_BUILTIN
  #define DEF_EXT_FALLBACK_BUILTIN(ENUM, NAME, TYPE)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
! 	       false, true, true, ATTR_NOTHROW_LIST, true)
  
  /* A library builtin (like __builtin_strchr) is a builtin equivalent
     of an ANSI/ISO standard library function.  In addition to the
*************** Software Foundation, 59 Temple Place - S
*** 91,104 ****
  #undef DEF_LIB_BUILTIN					
  #define DEF_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
! 	       true, true, false, ATTRS)
  
  /* Like DEF_LIB_BUILTIN, except that a call to the builtin should
     never fall back to the library version.  */
  #undef DEF_LIB_ALWAYS_BUILTIN				
  #define DEF_LIB_ALWAYS_BUILTIN(ENUM, NAME, TYPE)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!     	       true, false, true, ATTR_CONST_NOTHROW_LIST)
  
  /* Like DEF_LIB_BUILTIN, except that the function is not one that is
     specified by ANSI/ISO C.  So, when we're being fully conformant we
--- 97,110 ----
  #undef DEF_LIB_BUILTIN					
  #define DEF_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
! 	       true, true, false, ATTRS, true)
  
  /* Like DEF_LIB_BUILTIN, except that a call to the builtin should
     never fall back to the library version.  */
  #undef DEF_LIB_ALWAYS_BUILTIN				
  #define DEF_LIB_ALWAYS_BUILTIN(ENUM, NAME, TYPE)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!     	       true, false, true, ATTR_CONST_NOTHROW_LIST, true)
  
  /* Like DEF_LIB_BUILTIN, except that the function is not one that is
     specified by ANSI/ISO C.  So, when we're being fully conformant we
*************** Software Foundation, 59 Temple Place - S
*** 107,127 ****
  #undef DEF_EXT_LIB_BUILTIN				
  #define DEF_EXT_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!    	       true, true, true, ATTRS)
  
  /* Like DEF_LIB_BUILTIN, except that the function is only a part of
     the standard in C99 or above.  */
  #undef DEF_C99_BUILTIN					
  #define DEF_C99_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!    	       true, true, !flag_isoc99, ATTRS)
  
  /* Like DEF_LIB_BUILTIN, except that the function is expanded in the
     front-end.  */
  #undef DEF_FRONT_END_LIB_BUILTIN			
  #define DEF_FRONT_END_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_FRONTEND, TYPE, TYPE,	\
! 	       true, true, false, ATTRS)
  
  /* Like DEF_FRONT_END_LIB_BUILTIN, except that the function is not one
     that is specified by ANSI/ISO C.  So, when we're being fully
--- 113,141 ----
  #undef DEF_EXT_LIB_BUILTIN				
  #define DEF_EXT_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!    	       true, true, true, ATTRS, false)
  
  /* Like DEF_LIB_BUILTIN, except that the function is only a part of
     the standard in C99 or above.  */
  #undef DEF_C99_BUILTIN					
  #define DEF_C99_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!    	       true, true, !flag_isoc99, ATTRS, TARGET_C99_FUNCTIONS)
! 
! /* Builtin that is specified by C99 and C90 reserve the name for future use.
!    We can still recognize the builtin in C90 mode but we can't produce it
!    implicitly.  */
! #undef DEF_C99_C90RES_BUILTIN					
! #define DEF_C99_C90RES_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
!   DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE,	\
!    	       true, true, !flag_isoc99, ATTRS, TARGET_C99_FUNCTIONS)
  
  /* Like DEF_LIB_BUILTIN, except that the function is expanded in the
     front-end.  */
  #undef DEF_FRONT_END_LIB_BUILTIN			
  #define DEF_FRONT_END_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_FRONTEND, TYPE, TYPE,	\
! 	       true, true, false, ATTRS, true)
  
  /* Like DEF_FRONT_END_LIB_BUILTIN, except that the function is not one
     that is specified by ANSI/ISO C.  So, when we're being fully
*************** Software Foundation, 59 Temple Place - S
*** 130,142 ****
  #undef DEF_EXT_FRONT_END_LIB_BUILTIN			
  #define DEF_EXT_FRONT_END_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_FRONTEND, TYPE, TYPE,	\
! 	       true, true, true, ATTRS)
  
  /* A built-in that is not currently used.  */
  #undef DEF_UNUSED_BUILTIN					
  #define DEF_UNUSED_BUILTIN(X)					\
    DEF_BUILTIN (X, (const char *) NULL, NOT_BUILT_IN, BT_LAST,	\
! 	       BT_LAST, false, false, false, ATTR_NOTHROW_LIST)
  
  /* If SMALL_STACK is defined, then `alloca' is only defined in its
     `__builtin' form.  */
--- 144,156 ----
  #undef DEF_EXT_FRONT_END_LIB_BUILTIN			
  #define DEF_EXT_FRONT_END_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)	\
    DEF_BUILTIN (ENUM, NAME, BUILT_IN_FRONTEND, TYPE, TYPE,	\
! 	       true, true, true, ATTRS, true)
  
  /* A built-in that is not currently used.  */
  #undef DEF_UNUSED_BUILTIN					
  #define DEF_UNUSED_BUILTIN(X)					\
    DEF_BUILTIN (X, (const char *) NULL, NOT_BUILT_IN, BT_LAST,	\
! 	       BT_LAST, false, false, false, ATTR_NOTHROW_LIST, false)
  
  /* If SMALL_STACK is defined, then `alloca' is only defined in its
     `__builtin' form.  */
*************** DEF_LIB_BUILTIN(BUILT_IN_FLOOR,
*** 173,199 ****
                  "__builtin_floor",
                  BT_FN_DOUBLE_DOUBLE,
  		ATTR_CONST_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_FLOORF,
!                 "__builtin_floorf",
!                 BT_FN_FLOAT_FLOAT,
! 		ATTR_CONST_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_FLOORL,
!                 "__builtin_floorl",
!                 BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		ATTR_CONST_NOTHROW_LIST)
  
  DEF_LIB_BUILTIN(BUILT_IN_CEIL,
                  "__builtin_ceil",
                  BT_FN_DOUBLE_DOUBLE,
  		ATTR_CONST_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_CEILF,
!                 "__builtin_ceilf",
!                 BT_FN_FLOAT_FLOAT,
! 		ATTR_CONST_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_CEILL,
! 		"__builtin_ceill",
! 		BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		ATTR_CONST_NOTHROW_LIST)
  
  DEF_C99_BUILTIN(BUILT_IN_ROUND,
  		"__builtin_round",
--- 187,213 ----
                  "__builtin_floor",
                  BT_FN_DOUBLE_DOUBLE,
  		ATTR_CONST_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_FLOORF,
! 		       "__builtin_floorf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       ATTR_CONST_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_FLOORL,
! 		       "__builtin_floorl",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       ATTR_CONST_NOTHROW_LIST)
  
  DEF_LIB_BUILTIN(BUILT_IN_CEIL,
                  "__builtin_ceil",
                  BT_FN_DOUBLE_DOUBLE,
  		ATTR_CONST_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_CEILF,
! 		       "__builtin_ceilf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       ATTR_CONST_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_CEILL,
! 		       "__builtin_ceill",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       ATTR_CONST_NOTHROW_LIST)
  
  DEF_C99_BUILTIN(BUILT_IN_ROUND,
  		"__builtin_round",
*************** DEF_BUILTIN (BUILT_IN_BZERO,
*** 295,308 ****
  	     BT_FN_VOID_PTR_SIZE, 
  	     BT_FN_VOID_VAR,
  	     true, true, true,
! 	     ATTR_NOTHROW_LIST)
  DEF_BUILTIN (BUILT_IN_BCMP,
  	     "__builtin_bcmp",
  	     BUILT_IN_NORMAL,
  	     BT_FN_INT_CONST_PTR_CONST_PTR_SIZE,
  	     BT_FN_INT_VAR,
  	     true, true, true,
! 	     ATTR_PURE_NOTHROW_LIST)
  
  DEF_EXT_LIB_BUILTIN(BUILT_IN_FFS,
  		    "__builtin_ffs",
--- 309,322 ----
  	     BT_FN_VOID_PTR_SIZE, 
  	     BT_FN_VOID_VAR,
  	     true, true, true,
! 	     ATTR_NOTHROW_LIST, false)
  DEF_BUILTIN (BUILT_IN_BCMP,
  	     "__builtin_bcmp",
  	     BUILT_IN_NORMAL,
  	     BT_FN_INT_CONST_PTR_CONST_PTR_SIZE,
  	     BT_FN_INT_VAR,
  	     true, true, true,
! 	     ATTR_PURE_NOTHROW_LIST, false)
  
  DEF_EXT_LIB_BUILTIN(BUILT_IN_FFS,
  		    "__builtin_ffs",
*************** DEF_LIB_BUILTIN(BUILT_IN_LOG,
*** 414,481 ****
  				: (flag_unsafe_math_optimizations
  				   ? ATTR_CONST_NOTHROW_LIST
  				   : ATTR_PURE_NOTHROW_LIST))
! DEF_LIB_BUILTIN(BUILT_IN_SQRTF,
! 		"__builtin_sqrtf",
! 		BT_FN_FLOAT_FLOAT,
! 		flag_errno_math ? ATTR_NOTHROW_LIST
! 				: (flag_unsafe_math_optimizations
! 				   ? ATTR_CONST_NOTHROW_LIST
! 				   : ATTR_PURE_NOTHROW_LIST))
! DEF_LIB_BUILTIN(BUILT_IN_SINF,
! 		"__builtin_sinf",
! 		BT_FN_FLOAT_FLOAT,
! 		flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 					       : ATTR_PURE_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_COSF,
! 		"__builtin_cosf",
! 		BT_FN_FLOAT_FLOAT,
! 		flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 					       : ATTR_PURE_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_EXPF,
! 		"__builtin_expf",
! 		BT_FN_FLOAT_FLOAT,
! 		flag_errno_math ? ATTR_NOTHROW_LIST
! 				: (flag_unsafe_math_optimizations
! 				   ? ATTR_CONST_NOTHROW_LIST
! 				   : ATTR_PURE_NOTHROW_LIST))
! DEF_LIB_BUILTIN(BUILT_IN_LOGF,
! 		"__builtin_logf",
! 		BT_FN_FLOAT_FLOAT,
! 		flag_errno_math ? ATTR_NOTHROW_LIST
! 				: (flag_unsafe_math_optimizations
! 				   ? ATTR_CONST_NOTHROW_LIST
! 				   : ATTR_PURE_NOTHROW_LIST))
! DEF_LIB_BUILTIN(BUILT_IN_SQRTL,
! 		"__builtin_sqrtl",
! 		BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		flag_errno_math ? ATTR_NOTHROW_LIST
! 				: (flag_unsafe_math_optimizations
! 				   ? ATTR_CONST_NOTHROW_LIST
! 				   : ATTR_PURE_NOTHROW_LIST))
! DEF_LIB_BUILTIN(BUILT_IN_SINL,
! 		"__builtin_sinl",
! 		BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 					       : ATTR_PURE_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_COSL,
! 		"__builtin_cosl",
! 		BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 					       : ATTR_PURE_NOTHROW_LIST)
! DEF_LIB_BUILTIN(BUILT_IN_EXPL,
! 		"__builtin_expl",
! 		BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		flag_errno_math ? ATTR_NOTHROW_LIST
! 				: (flag_unsafe_math_optimizations
! 				   ? ATTR_CONST_NOTHROW_LIST
! 				   : ATTR_PURE_NOTHROW_LIST))
! DEF_LIB_BUILTIN(BUILT_IN_LOGL,
! 		"__builtin_logl",
! 		BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		flag_errno_math ? ATTR_NOTHROW_LIST
! 				: (flag_unsafe_math_optimizations
! 				   ? ATTR_CONST_NOTHROW_LIST
! 				   : ATTR_PURE_NOTHROW_LIST))
  
  DEF_GCC_BUILTIN(BUILT_IN_INF,
  		"__builtin_inf",
--- 428,495 ----
  				: (flag_unsafe_math_optimizations
  				   ? ATTR_CONST_NOTHROW_LIST
  				   : ATTR_PURE_NOTHROW_LIST))
! DEF_C99_C90RES_BUILTIN(BUILT_IN_SQRTF,
! 		       "__builtin_sqrtf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       flag_errno_math ? ATTR_NOTHROW_LIST
! 				       : (flag_unsafe_math_optimizations
! 					  ? ATTR_CONST_NOTHROW_LIST
! 					  : ATTR_PURE_NOTHROW_LIST))
! DEF_C99_C90RES_BUILTIN(BUILT_IN_SINF,
! 		       "__builtin_sinf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 						      : ATTR_PURE_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_COSF,
! 		       "__builtin_cosf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 						      : ATTR_PURE_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_EXPF,
! 		       "__builtin_expf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       flag_errno_math ? ATTR_NOTHROW_LIST
! 				       : (flag_unsafe_math_optimizations
! 					  ? ATTR_CONST_NOTHROW_LIST
! 					  : ATTR_PURE_NOTHROW_LIST))
! DEF_C99_C90RES_BUILTIN(BUILT_IN_LOGF,
! 		       "__builtin_logf",
! 		       BT_FN_FLOAT_FLOAT,
! 		       flag_errno_math ? ATTR_NOTHROW_LIST
! 				       : (flag_unsafe_math_optimizations
! 					  ? ATTR_CONST_NOTHROW_LIST
! 					  : ATTR_PURE_NOTHROW_LIST))
! DEF_C99_C90RES_BUILTIN(BUILT_IN_SQRTL,
! 		       "__builtin_sqrtl",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       flag_errno_math ? ATTR_NOTHROW_LIST
! 				       : (flag_unsafe_math_optimizations
! 					  ? ATTR_CONST_NOTHROW_LIST
! 					  : ATTR_PURE_NOTHROW_LIST))
! DEF_C99_C90RES_BUILTIN(BUILT_IN_SINL,
! 		       "__builtin_sinl",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 						      : ATTR_PURE_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_COSL,
! 		       "__builtin_cosl",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       flag_unsafe_math_optimizations ? ATTR_CONST_NOTHROW_LIST
! 						      : ATTR_PURE_NOTHROW_LIST)
! DEF_C99_C90RES_BUILTIN(BUILT_IN_EXPL,
! 		       "__builtin_expl",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       flag_errno_math ? ATTR_NOTHROW_LIST
! 				       : (flag_unsafe_math_optimizations
! 					  ? ATTR_CONST_NOTHROW_LIST
! 					  : ATTR_PURE_NOTHROW_LIST))
! DEF_C99_C90RES_BUILTIN(BUILT_IN_LOGL,
! 		       "__builtin_logl",
! 		       BT_FN_LONG_DOUBLE_LONG_DOUBLE,
! 		       flag_errno_math ? ATTR_NOTHROW_LIST
! 				       : (flag_unsafe_math_optimizations
! 					  ? ATTR_CONST_NOTHROW_LIST
! 					  : ATTR_PURE_NOTHROW_LIST))
  
  DEF_GCC_BUILTIN(BUILT_IN_INF,
  		"__builtin_inf",
*************** DEF_BUILTIN (BUILT_IN_FPUTS,
*** 616,622 ****
  	     BUILT_IN_NORMAL,
  	     BT_FN_INT_CONST_STRING_PTR,
  	     BT_FN_INT_VAR,
! 	     true, true, false, ATTR_NOTHROW_LIST)
  DEF_FALLBACK_BUILTIN(BUILT_IN_FWRITE,
  		     "__builtin_fwrite",
  		     BT_FN_SIZE_CONST_PTR_SIZE_SIZE_PTR,
--- 630,636 ----
  	     BUILT_IN_NORMAL,
  	     BT_FN_INT_CONST_STRING_PTR,
  	     BT_FN_INT_VAR,
! 	     true, true, false, ATTR_NOTHROW_LIST, true)
  DEF_FALLBACK_BUILTIN(BUILT_IN_FWRITE,
  		     "__builtin_fwrite",
  		     BT_FN_SIZE_CONST_PTR_SIZE_SIZE_PTR,
*************** DEF_BUILTIN (BUILT_IN_FPUTS_UNLOCKED,
*** 650,656 ****
  	     BUILT_IN_NORMAL,
  	     BT_FN_INT_CONST_STRING_PTR,
  	     BT_FN_INT_VAR,
! 	     true, true, true, ATTR_NOTHROW_LIST)
  DEF_EXT_FALLBACK_BUILTIN(BUILT_IN_FWRITE_UNLOCKED,
  			 "__builtin_fwrite_unlocked",
  			 BT_FN_SIZE_CONST_PTR_SIZE_SIZE_PTR)
--- 664,670 ----
  	     BUILT_IN_NORMAL,
  	     BT_FN_INT_CONST_STRING_PTR,
  	     BT_FN_INT_VAR,
! 	     true, true, true, ATTR_NOTHROW_LIST, true)
  DEF_EXT_FALLBACK_BUILTIN(BUILT_IN_FWRITE_UNLOCKED,
  			 "__builtin_fwrite_unlocked",
  			 BT_FN_SIZE_CONST_PTR_SIZE_SIZE_PTR)
*************** DEF_BUILTIN (BUILT_IN_ABORT,
*** 755,761 ****
  	     BT_FN_VOID,
  	     BT_FN_VOID,
  	     1, 0, 0,
! 	     ATTR_NORETURN_NOTHROW_LIST)
  
  DEF_BUILTIN (BUILT_IN_EXIT,
  	     "__builtin_exit",
--- 769,775 ----
  	     BT_FN_VOID,
  	     BT_FN_VOID,
  	     1, 0, 0,
! 	     ATTR_NORETURN_NOTHROW_LIST, true)
  
  DEF_BUILTIN (BUILT_IN_EXIT,
  	     "__builtin_exit",
*************** DEF_BUILTIN (BUILT_IN_EXIT,
*** 763,769 ****
  	     BT_FN_VOID_INT,
  	     BT_FN_VOID_INT,
  	     1, 0, 0,
! 	     ATTR_NORETURN_NOTHROW_LIST)
  
  DEF_BUILTIN (BUILT_IN__EXIT,
  	     "__builtin__exit",
--- 777,783 ----
  	     BT_FN_VOID_INT,
  	     BT_FN_VOID_INT,
  	     1, 0, 0,
! 	     ATTR_NORETURN_NOTHROW_LIST, true)
  
  DEF_BUILTIN (BUILT_IN__EXIT,
  	     "__builtin__exit",
*************** DEF_BUILTIN (BUILT_IN__EXIT,
*** 771,777 ****
  	     BT_FN_VOID_INT,
  	     BT_FN_VOID_INT,
  	     1, 0, 1,
! 	     ATTR_NORETURN_NOTHROW_LIST)
  
  DEF_BUILTIN (BUILT_IN__EXIT2,
  	     "__builtin__Exit",
--- 785,791 ----
  	     BT_FN_VOID_INT,
  	     BT_FN_VOID_INT,
  	     1, 0, 1,
! 	     ATTR_NORETURN_NOTHROW_LIST, false)
  
  DEF_BUILTIN (BUILT_IN__EXIT2,
  	     "__builtin__Exit",
*************** DEF_BUILTIN (BUILT_IN__EXIT2,
*** 779,783 ****
  	     BT_FN_VOID_INT,
  	     BT_FN_VOID_INT,
  	     1, 0, !flag_isoc99,
! 	     ATTR_NORETURN_NOTHROW_LIST)
  
--- 793,797 ----
  	     BT_FN_VOID_INT,
  	     BT_FN_VOID_INT,
  	     1, 0, !flag_isoc99,
! 	     ATTR_NORETURN_NOTHROW_LIST, false)
  
Index: c-common.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.394
diff -c -3 -p -r1.394 c-common.c
*** c-common.c	16 Dec 2002 18:19:00 -0000	1.394
--- c-common.c	17 Dec 2002 22:02:49 -0000
*************** c_common_nodes_and_builtins ()
*** 3534,3540 ****
      c_init_attributes ();
  
  #define DEF_BUILTIN(ENUM, NAME, CLASS, TYPE, LIBTYPE,			\
! 		    BOTH_P, FALLBACK_P, NONANSI_P, ATTRS)		\
    if (NAME)								\
      {									\
        tree decl;							\
--- 3534,3540 ----
      c_init_attributes ();
  
  #define DEF_BUILTIN(ENUM, NAME, CLASS, TYPE, LIBTYPE,			\
! 		    BOTH_P, FALLBACK_P, NONANSI_P, ATTRS, IMPLICIT)	\
    if (NAME)								\
      {									\
        tree decl;							\
*************** c_common_nodes_and_builtins ()
*** 3561,3566 ****
--- 3561,3568 ----
  				   built_in_attributes[(int) ATTRS]);	\
  									\
        built_in_decls[(int) ENUM] = decl;				\
+       if (IMPLICIT)							\
+         implicit_built_in_decls[(int) ENUM] = decl;			\
      }									
  #include "builtins.def"
  #undef DEF_BUILTIN
*************** c_expand_builtin_printf (arglist, target
*** 4492,4500 ****
       int unlocked;
  {
    tree fn_putchar = unlocked ?
!     built_in_decls[BUILT_IN_PUTCHAR_UNLOCKED] : built_in_decls[BUILT_IN_PUTCHAR];
    tree fn_puts = unlocked ?
!     built_in_decls[BUILT_IN_PUTS_UNLOCKED] : built_in_decls[BUILT_IN_PUTS];
    tree fn, format_arg, stripped_string;
  
    /* If the return value is used, or the replacement _DECL isn't
--- 4494,4502 ----
       int unlocked;
  {
    tree fn_putchar = unlocked ?
!     implicit_built_in_decls[BUILT_IN_PUTCHAR_UNLOCKED] : implicit_built_in_decls[BUILT_IN_PUTCHAR];
    tree fn_puts = unlocked ?
!     implicit_built_in_decls[BUILT_IN_PUTS_UNLOCKED] : implicit_built_in_decls[BUILT_IN_PUTS];
    tree fn, format_arg, stripped_string;
  
    /* If the return value is used, or the replacement _DECL isn't
*************** c_expand_builtin_fprintf (arglist, targe
*** 4596,4604 ****
       int unlocked;
  {
    tree fn_fputc = unlocked ?
!     built_in_decls[BUILT_IN_FPUTC_UNLOCKED] : built_in_decls[BUILT_IN_FPUTC];
    tree fn_fputs = unlocked ?
!     built_in_decls[BUILT_IN_FPUTS_UNLOCKED] : built_in_decls[BUILT_IN_FPUTS];
    tree fn, format_arg, stripped_string;
  
    /* If the return value is used, or the replacement _DECL isn't
--- 4598,4606 ----
       int unlocked;
  {
    tree fn_fputc = unlocked ?
!     implicit_built_in_decls[BUILT_IN_FPUTC_UNLOCKED] : implicit_built_in_decls[BUILT_IN_FPUTC];
    tree fn_fputs = unlocked ?
!     implicit_built_in_decls[BUILT_IN_FPUTS_UNLOCKED] : implicit_built_in_decls[BUILT_IN_FPUTS];
    tree fn, format_arg, stripped_string;
  
    /* If the return value is used, or the replacement _DECL isn't
Index: defaults.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/defaults.h,v
retrieving revision 1.98
diff -c -3 -p -r1.98 defaults.h
*** defaults.h	16 Dec 2002 18:19:20 -0000	1.98
--- defaults.h	17 Dec 2002 22:02:49 -0000
*************** You Lose!  You must define PREFERRED_DEB
*** 613,616 ****
--- 613,622 ----
  #define EXTRA_ADDRESS_CONSTRAINT(C) 0
  #endif
  
+ /* Determine whether math functions specified by C99 standard, like
+    sinf/sinl are present in the runtime library.  */
+ #ifndef TARGET_C99_FUNCTIONS
+ #define TARGET_C99_FUNCTIONS 1
+ #endif
+ 
  #endif  /* ! GCC_DEFAULTS_H */
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.368
diff -c -3 -p -r1.368 tree.h
*** tree.h	16 Dec 2002 18:20:01 -0000	1.368
--- tree.h	17 Dec 2002 22:02:52 -0000
*************** extern const char *const built_in_class_
*** 84,90 ****
  /* Codes that identify the various built in functions
     so that expand_call can identify them quickly.  */
  
! #define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT) ENUM,
  enum built_in_function
  {
  #include "builtins.def"
--- 84,90 ----
  /* Codes that identify the various built in functions
     so that expand_call can identify them quickly.  */
  
! #define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM) ENUM,
  enum built_in_function
  {
  #include "builtins.def"
*************** extern const char *const built_in_names[
*** 99,104 ****
--- 99,105 ----
  
  /* An array of _DECL trees for the above.  */
  extern tree built_in_decls[(int) END_BUILTINS];
+ extern tree implicit_built_in_decls[(int) END_BUILTINS];
  \f
  /* The definition of tree nodes fills the next several pages.  */
  
*************** extern tree invert_truthvalue	PARAMS ((t
*** 2928,2933 ****
--- 2929,2936 ----
  extern tree fold_builtin				PARAMS ((tree));
  extern enum built_in_function builtin_mathfn_code	PARAMS ((tree));
  extern tree build_function_call_expr			PARAMS ((tree, tree));
+ extern tree mathfn_built_in				PARAMS ((tree, enum built_in_function fn));
+ extern tree strip_float_extensions			PARAMS ((tree));
  
  /* In alias.c */
  extern void record_component_aliases		PARAMS ((tree));
Index: doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.183
diff -c -3 -p -r1.183 tm.texi
*** doc/tm.texi	16 Dec 2002 18:22:25 -0000	1.183
--- doc/tm.texi	17 Dec 2002 22:03:06 -0000
*************** Define this macro if GCC should generate
*** 4732,4737 ****
--- 4732,4746 ----
  (and System V) library functions @code{memcpy}, @code{memmove} and
  @code{memset} rather than the BSD functions @code{bcopy} and @code{bzero}.
  
+ @findex TARGET_C99_FUNCTIONS
+ @cindex C99 math functions, implicit usage
+ @item TARGET_C99_FUNCTIONS
+ When this macro is nonzero, GCC will implicitly optimize @code{sin} calls into
+ @code{sinf} and similary for other functions defined by C99 standard.  The
+ default is nonzero that should be proper value for most modern systems, however
+ number of existing systems lacks support for these functions in the runtime so
+ they needs this macro to be redefined to @code{0}.
+ 
  @findex LIBGCC_NEEDS_DOUBLE
  @item LIBGCC_NEEDS_DOUBLE
  Define this macro if @code{float} arguments cannot be passed to library
Index: java/builtins.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/builtins.c,v
retrieving revision 1.11
diff -c -3 -p -r1.11 builtins.c
*** java/builtins.c	16 Dec 2002 18:22:31 -0000	1.11
--- java/builtins.c	17 Dec 2002 22:03:06 -0000
*************** static tree build_function_call_expr PAR
*** 72,78 ****
  static void define_builtin PARAMS ((enum built_in_function,
  				    const char *,
  				    enum built_in_class,
! 				    tree, int));
  static tree define_builtin_type PARAMS ((int, int, int, int, int));
  
  \f
--- 72,78 ----
  static void define_builtin PARAMS ((enum built_in_function,
  				    const char *,
  				    enum built_in_class,
! 				    tree, int, int));
  static tree define_builtin_type PARAMS ((int, int, int, int, int));
  
  \f
*************** sqrt_builtin (method_return_type, method
*** 193,204 ****
  
  /* Define a single builtin.  */
  static void
! define_builtin (val, name, class, type, fallback_p)
       enum built_in_function val;
       const char *name;
       enum built_in_class class;
       tree type;
       int fallback_p;
  {
    tree decl;
  
--- 193,205 ----
  
  /* Define a single builtin.  */
  static void
! define_builtin (val, name, class, type, fallback_p, implicit)
       enum built_in_function val;
       const char *name;
       enum built_in_class class;
       tree type;
       int fallback_p;
+      int implicit;
  {
    tree decl;
  
*************** define_builtin (val, name, class, type, 
*** 218,223 ****
--- 219,226 ----
    DECL_BUILT_IN_CLASS (decl) = class;
    DECL_FUNCTION_CODE (decl) = val;
    built_in_decls[val] = decl;
+   if (implicit)
+     implicit_built_in_decls[val] = decl;
  }
  
  /* Compute the type for a builtin.  */
*************** initialize_builtins ()
*** 316,323 ****
  #include "builtin-types.def"
  
  #define DEF_BUILTIN(ENUM, NAME, CLASS, TYPE, LIBTYPE, BOTH_P, \
!                     FALLBACK_P, NONANSI_P, ATTRS) \
!   define_builtin (ENUM, NAME, CLASS, builtin_types[TYPE], FALLBACK_P);
  #include "builtins.def"
  }
  
--- 319,326 ----
  #include "builtin-types.def"
  
  #define DEF_BUILTIN(ENUM, NAME, CLASS, TYPE, LIBTYPE, BOTH_P, \
!                     FALLBACK_P, NONANSI_P, ATTRS, IMPLICIT) \
!   define_builtin (ENUM, NAME, CLASS, builtin_types[TYPE], FALLBACK_P, IMPLICIT);
  #include "builtins.def"
  }
  

Re: Implicit generation of runtime calls

[Jan Hubicka]

> 
> Hi,
> this patch adds the infrastructure to determine whether the function call can
> be produced implicitly or not.  I am doing that by new array of declarations
> implicit_built_in_decls that has entry nonzero just for those builtins that are
> safe.
> In future we may want to modify the declarations so the builtin expansion can
> behave differently for implicit calls as they do already for __builtin_XXX calls
> and XXX calls.
> 
> DEF_BUILTIN now allows to declare whehter the function is available and I've
> categorized the functions according to C99 and C90 standards.
> I also added the TARGET_C99_FUNCTIONS defined to 1 by default and function
> to get the declaration in proper mode so conversions can be done easilly.
> 
> Thats it.  In the next step I would like to re-enable the transformation as
> next step once this part is polished.  I would also like to turn
> TARGET_MEM_FUNCTIONS into this scheme.  I intended to do this in one step but
> the patch is getting bigger than I would like it to be already.
> 
> I will happily add -fno-c99-builtins switch to configure and manage it to
> control TARGET_C99_FUNCTIONS if someone will make me believe that this is good.
> I think this is static knowledge about the particular port and the problems
> with autoconfiguration being different in different contexts, so it will
> bring us problems in reproducing failures reported in cross envorinment
> and so on.
> 
> I also don't think it makes sense to allow controlling each function
> individually.  We already support about 10-20 such functions and the number of
> them will increase.  I don't think runtimes are crazy enought to commonly
> support just arbitary subset of these, so this would just anoy.  We can invent
> 1-2 new categories (perhaps there can be category for runtimes deifning sinf
> but not sinl or cabs if such exists)
> 
> Bootstrapped/regtested mainline.

I also tested that it disables/enables the transformation as needed :)
In the followup I will add testcase to the testsuite so ports where
default is wrong will get caught and re-enable the transformation 

Honza

Re: basic-improvements merge status

[Richard Henderson]

On Tue, Dec 17, 2002 at 09:40:01AM +0100, Gabriel Dos Reis wrote:
> Well, it is precisely the *compiler's job* to provide that
> environment.

No, it's the *toolchain*'s job.  By that I mean libc included.
We should not get into the business of filling in the holes in
the c runtime.

> Since it doesn't, because there no library support with
> it), it is *wrong* to assume it is operating in C99 mode.

On the other hand, if you don't have a c99-compliant library,
I wonder if you should be using -std=c99 at all.


r~

Re: basic-improvements merge status

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

[...]

| > Since it doesn't, because there no library support with
| > it), it is *wrong* to assume it is operating in C99 mode.
| 
| On the other hand, if you don't have a c99-compliant library,
| I wonder if you should be using -std=c99 at all.

No body was using -std=c99 when building libstdc++-v3.

-- Gaby

Re: basic-improvements merge status

[Matt Austern]

On Tuesday, December 17, 2002, at 03:39  PM, Richard Henderson wrote:

> On the other hand, if you don't have a c99-compliant library,
> I wonder if you should be using -std=c99 at all.

Should this be something we probe for during the
configure step?  Unless you're building a cross
compiler, we can test to see if real C99 compliance
is possible.

(And then the next question: is a hybrid, with the
C99 core language and the C90 library, interesting?
If so, what should we call it?)

			--Matt

Re: basic-improvements merge status

[Phil Edwards]

On Tue, Dec 17, 2002 at 03:47:31PM -0800, Matt Austern wrote:
> On Tuesday, December 17, 2002, at 03:39  PM, Richard Henderson wrote:
> 
> > On the other hand, if you don't have a c99-compliant library,
> > I wonder if you should be using -std=c99 at all.
> 
> Should this be something we probe for during the
> configure step?  Unless you're building a cross
> compiler, we can test to see if real C99 compliance
> is possible.

v3 is trying to do this now, to the limited extent of "C99 library features
that can be useful in a C++98 library".  An opportunity for code reuse!


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: basic-improvements merge status

[Alexandre Oliva]

On Dec 17, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

>> OK, I will disable the transfromation for the moment.
> Thanks; that's fine.

>>> how to do the configury bits.  (One possibility is explicitly flags in
>>> the tm.h file.)
>> 
>> What do you think is the correct way to handle it?

> I'm not sure; I'm not a configury expert.  For a native build, I'd think
> we could use autoconf; for a cross-build, that's a little tougher -- but
> I'd think we could still do it.

There's nothing we can do, really.  The compiler is often built before
the C library, so it can't detect properties in it.  It has to know in
advance what transformations it can or cannot do.  I can't see
anything much different from, say, some settings in gcc/config that
enable or disable some of the functions, along with perhaps some
consistency check that detects functions that are present but whose
transformations are disabled, or those that are missing but enabled.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: basic-improvements merge status

[Alexandre Oliva]

On Dec 17, 2002, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Yes, I think we should be able (using Autoconf) to produce a swicth
> like after usual tests.

>    --without-library-functions='sinf,cosf, blah blah'

--without doesn't take arguments, only --with does.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: basic-improvements merge status

[Jan Hubicka]

> Richard Henderson <rth@redhat.com> writes:
> 
> [...]
> 
> | > Since it doesn't, because there no library support with
> | > it), it is *wrong* to assume it is operating in C99 mode.
> | 
> | On the other hand, if you don't have a c99-compliant library,
> | I wonder if you should be using -std=c99 at all.
> 
> No body was using -std=c99 when building libstdc++-v3.

I never claimed that the current behaviour is correct.

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

> On Dec 17, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> >> OK, I will disable the transfromation for the moment.
> > Thanks; that's fine.
> 
> >>> how to do the configury bits.  (One possibility is explicitly flags in
> >>> the tm.h file.)
> >> 
> >> What do you think is the correct way to handle it?
> 
> > I'm not sure; I'm not a configury expert.  For a native build, I'd think
> > we could use autoconf; for a cross-build, that's a little tougher -- but
> > I'd think we could still do it.
> 
> There's nothing we can do, really.  The compiler is often built before
> the C library, so it can't detect properties in it.  It has to know in
> advance what transformations it can or cannot do.  I can't see
> anything much different from, say, some settings in gcc/config that
> enable or disable some of the functions, along with perhaps some
> consistency check that detects functions that are present but whose
> transformations are disabled, or those that are missing but enabled.

I've added config/* macros.  I think I can easilly write testcae that
won't link when the conversion is incorrectly enabled, but I am not
quite sure I can do something when it is incorrectly disabled.
But since enabled is the default, I guess this is enought.  Thanks!

Honza
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist                Professional serial bug killer

Re: basic-improvements merge status

[Geoff Keating]

> Cc: gcc@gcc.gnu.org
> From: Zack Weinberg <zack@codesourcery.com>
> Date: Mon, 16 Dec 2002 17:43:24 -0800
> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)
> X-OriginalArrivalTime: 17 Dec 2002 01:43:25.0303 (UTC) FILETIME=[B09F1870:01C2A56D]
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > That line has a 'GTY(())' on it, which is causing the parse error:
> > somehow GTY is not being defined.
> 
> That should be impossible; coretypes.h unconditionally defines GTY,
> and cse.c includes coretypes.h before rtl.h:
> 
> #include "config.h"
> /* stdio.h must precede rtl.h for FFS.  */
> #include "system.h"
> #include "coretypes.h"
> #include "tm.h"
> 
> #include "rtl.h"
> 
> Have you got a sticky tag or something?

I did.  I wonder how that happened?

Anyway, now the build tries to invoke genmultilib twice
simultaneously, which it didn't before, and this fails when the first
instance deletes the temporary 'tmpmultilib' and 'tmpmultilib2'
scripts before the second has finished using them.  Patch to follow.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: basic-improvements merge status

[Zack Weinberg]

Geoff Keating <geoffk@geoffk.org> writes:

> That line has a 'GTY(())' on it, which is causing the parse error:
> somehow GTY is not being defined.

That should be impossible; coretypes.h unconditionally defines GTY,
and cse.c includes coretypes.h before rtl.h:

#include "config.h"
/* stdio.h must precede rtl.h for FFS.  */
#include "system.h"
#include "coretypes.h"
#include "tm.h"

#include "rtl.h"

Have you got a sticky tag or something?

zw

Re: basic-improvements merge status

[Geoff Keating]

I can't build powerpc-eabisim on mainline now either:

gcc -no-cpp-precomp -c   -g -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common  -DHAVE_CONFIG_H    -I. -I. -I/Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc -I/Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/. -I/Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/config -I/Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/../include /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/cse.c -o cse.o
In file included from /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/cse.c:26:
/Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/rtl.h:97: parse error before '(' token
[hundreds of other errors]

That line has a 'GTY(())' on it, which is causing the parse error:
somehow GTY is not being defined.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: basic-improvements merge status

[Mark Mitchell]

--On Monday, December 16, 2002 12:44:10 PM -0800 Geoff Keating 
<geoffk@geoffk.org> wrote:

> Zack Weinberg <zack@codesourcery.com> writes:
>
>> It is not clear to me that any purpose is served by holding off the
>> merge to trunk until all these issues get resolved.  We could instead
>> do the merge now and fix the problems on the mainline; this would let
>> people move forward with other work.
>
> I don't know what 'people' are helped by having the mainline
> unbuildable and untestable.  I'm very unhappy about the way this
> merge was handled.

I'm unhappy that you're unhappy.

I'm very unhappy about the fact that we had regressions on BIB; that
wasn't supposed to happen.

Other people were unhappy that we didn't merge sooner.

Let's fix the problems.  I'm happy to help with the Darwin issues, if
we can get to the point that someone with a cross-compiler (i.e., me),
can see what's happenning.

To be clear: the only patches that should be going to mainline now are
patches to fix the bootstrap issues resulting form the BIB merge.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

RE: basic-improvements merge status

[Robert McNulty Junior]

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
Geoff Keating
Sent: Monday, December 16, 2002 2:44 PM
To: Zack Weinberg
Cc: gcc@gcc.gnu.org
Subject: Re: basic-improvements merge status


Zack Weinberg <zack@codesourcery.com> writes:

> It is not clear to me that any purpose is served by holding off the
> merge to trunk until all these issues get resolved.  We could instead
> do the merge now and fix the problems on the mainline; this would let
> people move forward with other work.

I don't know what 'people' are helped by having the mainline
unbuildable and untestable.  I'm very unhappy about the way this
merge was handled.

--
- Geoffrey Keating <geoffk@geoffk.org>


HI.
I'm testing main trunk now.
Looks good so far.
All It was was the branch improvements being brought into the main trunk.
It's on Stage 3 (make that actually Stage Two) and still compiling.
I started compiling about an hour ago.
Robert

Re: basic-improvements merge status

[Geoff Keating]

Zack Weinberg <zack@codesourcery.com> writes:

> It is not clear to me that any purpose is served by holding off the
> merge to trunk until all these issues get resolved.  We could instead
> do the merge now and fix the problems on the mainline; this would let
> people move forward with other work.

I don't know what 'people' are helped by having the mainline
unbuildable and untestable.  I'm very unhappy about the way this
merge was handled.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: basic-improvements merge status

[DJ Delorie]

> (In the alternate universe where gcc is managed with `arch') use:
> 
>     larch star-merge gcc--basic-improvements gcc--mainline gcc-wd

At a previous job we implemented a branch system that was external to
the core source control system.  One of the good things it did was to
"reroot" a branch - i.e. move the branch point.  The merge process
required the branch to be rerooted at the head of the trunk first,
then merged back to the trunk.

I wish CVS could do this.

Re: basic-improvements merge status

[David Edelsohn]

	3.4BIB is looking okay on AIX (which does not build libjava):

	No new c-torture fails.

	c++-torture is failing for g++.dg/opt/vtgc1.C

	libstdc++ is failing for 26_numerics/c_math.cc execution test

David

Re: basic-improvements merge status

[Jason R Thorpe]

On Mon, Dec 16, 2002 at 12:11:44AM -0800, Zack Weinberg wrote:

 > ... but I just discovered that I don't know how.  "cvs update -j
 > gcc-3_4-basic-improvements-branch" tries to merge all of the merges
 > from the trunk to the branch BACK into the trunk, causing a ton of
 > spurious conflicts.  What's the right way to do this?  (I'm seriously
 > considering "diff -ruN 3.3/ 3.4b/ | (cd top-of-trunk/ && patch -p1 -E"!)

I think you want to use the tag indicating the version of the trunk at
the last merge with the branch tag, like so:

    -j version_of_trunk_at_least_merge -j gcc-3_4-basic-improvements-branch

(sorry, I don't have that tag handy, because the system with my GCC
source tree is powered off at the moment :-)

...because what you want to merge is "all of the differences between the
trunk(at that time) and the branch".

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: basic-improvements merge status

[Tom Lord]

       > ... but I just discovered that I don't know how.  "cvs update
       > -j gcc-3_4-basic-improvements-branch" tries to merge all of
       > the merges from the trunk to the branch BACK into the trunk,
       > causing a ton of spurious conflicts.  What's the right way to
       > do this?  (I'm seriously considering "diff -ruN 3.3/ 3.4b/ |
       > (cd top-of-trunk/ && patch -p1 -E"!)
       
       I think that *is* the right way, roughly.


(In the alternate universe where gcc is managed with `arch') use:

    larch star-merge gcc--basic-improvements gcc--mainline gcc-wd

That assumes that you want to start with basic-improvements and apply
the changes from mainline, which means that any real conflicts in
mainline will be kicked out to .rej files.   If you'd rather have the
truly conflicting basic-improvements changes in .rej files, use:

    larch star-merge gcc--mainline gcc--basic-improvements gcc-wd

If you've been cherry-picking those earlier merges, pipe 

    larch whats-missing ...

output into an `xargs' of 

    larch replay ...

If you now want to cherry pick rather than do a full merge, edit the
revision ids of the changes you want out of the output of:

    larch whats-missing --summary

and apply `larch replay' to those.

Finally, if you want to do this merge in such a way the individual
changesets from basic-improvements appear as individual changesets
(i.e., clean single-purpose changes) on mainline, then use one of the
replay techniques -- but commit between each call to replay.  That
will be a boon to people who have forks of mainline who themselves
cherry-pick from mainline changes.  Your `diff' technique, and the
other `larch' techniques listed here, will smoosh together lots of
changes in a single commit -- forcing cherry-pickers to look to the
branches to get the clean changesets.

:-)


-t

Re: basic-improvements merge status

[Jan Hubicka]

> 
> Since my last posting on the subject, the Makefile and 32x64 issues
> have been resolved and patches checked in.  I have also read through
> the entire diff between 3.3 branchpoint and 3.4bib top of branch, to
> make sure that no patches have gotten lost.  (It's possible that I
> missed something.)
> 
> Still unresolved problems reported to me are:
> 
> - hppa weak symbols problem
> - hppa g++ testsuite failures apparently to do with structure return
> - darwin stubs problem
> - darwin bootstrap failure
> - irix6.5 bootstrap failure
> - cygwin bootstrap failure
> 
> I do not have access to the systems involved, or enough knowledge of
> them to fix the problems even if I did.  I need help from people who
> have both these things.
> 
> It is not clear to me that any purpose is served by holding off the
> merge to trunk until all these issues get resolved.  We could instead
> do the merge now and fix the problems on the mainline; this would let
> people move forward with other work.  It would probably be a good idea
> in that case to hold off on further branch merges and other massively
> destabilizing patches until these issues do get resolved.
> 
> Thoughts?
I perfectly aggree.  All these are mostly configuration problems and can
be fixed once merge is done.  It looks like branch bootstrap en enought
different CPUs when configured properly giving enought evidence that it
is not broken by design.  Merging and reopening mainline will let other
work to be integrated...

Also you may check http://www.suse.de/~aj/SPEC for benchmarks from last
week.  Fortunately there seems to be no important regressions relative
to mainline and some important speedups.

Honza
> 
> zw

Re: basic-improvements merge status

[Mark Mitchell]

--On Monday, December 16, 2002 12:11:44 AM -0800 Zack Weinberg 
<zack@codesourcery.com> wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
>>> It is not clear to me that any purpose is served by holding off the
>>> merge to trunk until all these issues get resolved.  We could instead
>>> do the merge now and fix the problems on the mainline; this would let
>>> people move forward with other work.  It would probably be a good idea
>>> in that case to hold off on further branch merges and other massively
>>> destabilizing patches until these issues do get resolved.
>>
>> I agree.  These are really problems that should have been detected
>> and fixed on BIB, but they slipped through.  Nobody's fault, just
>> how it is.
>>
>> So, do the merge.
>
> Thanks for the vote of confidence ...
>
> ... but I just discovered that I don't know how.  "cvs update -j
> gcc-3_4-basic-improvements-branch" tries to merge all of the merges
> from the trunk to the branch BACK into the trunk, causing a ton of
> spurious conflicts.  What's the right way to do this?  (I'm seriously
> considering "diff -ruN 3.3/ 3.4b/ | (cd top-of-trunk/ && patch -p1 -E"!)

I think that *is* the right way, roughly.

Let's suppose you just merged the mainline to BIB, so that there's nothing
on mainline that's not on BIB.

Then, I would do something like:

  cvs diff -r BIB -r HEAD | patch -p0

to suck the changes to BIB back into the HEAD.  And then run around
removing files (if any) that were removed on BIB, but not on HEAD,
which is equivalent to what you said.

After all, what you're trying to do is just rename BIB to be mainline,
basically.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: basic-improvements merge status

[Zack Weinberg]

Mark Mitchell <mark@codesourcery.com> writes:

>> It is not clear to me that any purpose is served by holding off the
>> merge to trunk until all these issues get resolved.  We could instead
>> do the merge now and fix the problems on the mainline; this would let
>> people move forward with other work.  It would probably be a good idea
>> in that case to hold off on further branch merges and other massively
>> destabilizing patches until these issues do get resolved.
>
> I agree.  These are really problems that should have been detected
> and fixed on BIB, but they slipped through.  Nobody's fault, just
> how it is.
>
> So, do the merge.

Thanks for the vote of confidence ...

... but I just discovered that I don't know how.  "cvs update -j
gcc-3_4-basic-improvements-branch" tries to merge all of the merges
from the trunk to the branch BACK into the trunk, causing a ton of
spurious conflicts.  What's the right way to do this?  (I'm seriously
considering "diff -ruN 3.3/ 3.4b/ | (cd top-of-trunk/ && patch -p1 -E"!)

zw

Re: basic-improvements merge status

[Mark Mitchell]

> It is not clear to me that any purpose is served by holding off the
> merge to trunk until all these issues get resolved.  We could instead
> do the merge now and fix the problems on the mainline; this would let
> people move forward with other work.  It would probably be a good idea
> in that case to hold off on further branch merges and other massively
> destabilizing patches until these issues do get resolved.

I agree.  These are really problems that should have been detected
and fixed on BIB, but they slipped through.  Nobody's fault, just
how it is.

So, do the merge.

Then, let's leave the mainline frozen except for fixes to those problems.

The best way to make sure that we don't miss these things, especially
since many of them are bootstrap failures, is to fix them *right now*.

Are there PRs for these problems?  If not, please make them, and mark
them as high-priority bugs.

None is likely to be particularly problematic; people with those kinds of
systems can probably figure out what caused the problem quickly, and
then we can figure out how to fix them.

Yes, these are regressions on the mainline, and yes our 48-hour rule says
we would have to revert everything, but I think it's pretty clear that
we're better served by going ahead with the merge and then fixing the
problems.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

basic-improvements merge status

[Zack Weinberg]

Since my last posting on the subject, the Makefile and 32x64 issues
have been resolved and patches checked in.  I have also read through
the entire diff between 3.3 branchpoint and 3.4bib top of branch, to
make sure that no patches have gotten lost.  (It's possible that I
missed something.)

Still unresolved problems reported to me are:

- hppa weak symbols problem
- hppa g++ testsuite failures apparently to do with structure return
- darwin stubs problem
- darwin bootstrap failure
- irix6.5 bootstrap failure
- cygwin bootstrap failure

I do not have access to the systems involved, or enough knowledge of
them to fix the problems even if I did.  I need help from people who
have both these things.

It is not clear to me that any purpose is served by holding off the
merge to trunk until all these issues get resolved.  We could instead
do the merge now and fix the problems on the mainline; this would let
people move forward with other work.  It would probably be a good idea
in that case to hold off on further branch merges and other massively
destabilizing patches until these issues do get resolved.

Thoughts?

zw