* Re: basic-improvements merge status @ 2002-12-16 13:52 David Edelsohn 2002-12-16 13:57 ` Zack Weinberg 2002-12-16 14:29 ` Jan Hubicka 0 siblings, 2 replies; 67+ messages in thread From: David Edelsohn @ 2002-12-16 13:52 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 13:52 basic-improvements merge status David Edelsohn @ 2002-12-16 13:57 ` Zack Weinberg 2002-12-16 14:23 ` David Edelsohn 2002-12-16 14:29 ` Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Zack Weinberg @ 2002-12-16 13:57 UTC (permalink / raw) To: David Edelsohn, Jan Hubicka; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 13:57 ` Zack Weinberg @ 2002-12-16 14:23 ` David Edelsohn 2002-12-16 14:27 ` Jan Hubicka 2002-12-17 0:47 ` Gabriel Dos Reis 0 siblings, 2 replies; 67+ messages in thread From: David Edelsohn @ 2002-12-16 14:23 UTC (permalink / raw) To: Zack Weinberg, Jan Hubicka; +Cc: gcc, libstdc++ >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:23 ` David Edelsohn @ 2002-12-16 14:27 ` Jan Hubicka 2002-12-16 14:47 ` Neil Booth 2002-12-16 17:01 ` Mark Mitchell 2002-12-17 0:47 ` Gabriel Dos Reis 1 sibling, 2 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 14:27 UTC (permalink / raw) To: David Edelsohn; +Cc: Zack Weinberg, Jan Hubicka, gcc, libstdc++ > >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:27 ` Jan Hubicka @ 2002-12-16 14:47 ` Neil Booth 2002-12-16 15:10 ` Jan Hubicka 2002-12-16 21:32 ` Joseph S. Myers 2002-12-16 17:01 ` Mark Mitchell 1 sibling, 2 replies; 67+ messages in thread From: Neil Booth @ 2002-12-16 14:47 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:47 ` Neil Booth @ 2002-12-16 15:10 ` Jan Hubicka 2002-12-17 0:50 ` Gabriel Dos Reis 2002-12-16 21:32 ` Joseph S. Myers 1 sibling, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 15:10 UTC (permalink / raw) To: Neil Booth; +Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++ > 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 15:10 ` Jan Hubicka @ 2002-12-17 0:50 ` Gabriel Dos Reis 2002-12-17 15:54 ` Richard Henderson 0 siblings, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 0:50 UTC (permalink / raw) To: Jan Hubicka; +Cc: Neil Booth, David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:50 ` Gabriel Dos Reis @ 2002-12-17 15:54 ` Richard Henderson 2002-12-17 16:14 ` Gabriel Dos Reis 2002-12-17 16:19 ` Matt Austern 0 siblings, 2 replies; 67+ messages in thread From: Richard Henderson @ 2002-12-17 15:54 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jan Hubicka, Neil Booth, David Edelsohn, Zack Weinberg, gcc, libstdc++ 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~ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 15:54 ` Richard Henderson @ 2002-12-17 16:14 ` Gabriel Dos Reis 2002-12-18 5:29 ` Jan Hubicka 2002-12-17 16:19 ` Matt Austern 1 sibling, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 16:14 UTC (permalink / raw) To: Richard Henderson Cc: Jan Hubicka, Neil Booth, David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 16:14 ` Gabriel Dos Reis @ 2002-12-18 5:29 ` Jan Hubicka 0 siblings, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-18 5:29 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Richard Henderson, Jan Hubicka, Neil Booth, David Edelsohn, Zack Weinberg, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 15:54 ` Richard Henderson 2002-12-17 16:14 ` Gabriel Dos Reis @ 2002-12-17 16:19 ` Matt Austern 2002-12-17 16:31 ` Phil Edwards 1 sibling, 1 reply; 67+ messages in thread From: Matt Austern @ 2002-12-17 16:19 UTC (permalink / raw) To: Richard Henderson Cc: Gabriel Dos Reis, Jan Hubicka, Neil Booth, David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 16:19 ` Matt Austern @ 2002-12-17 16:31 ` Phil Edwards 0 siblings, 0 replies; 67+ messages in thread From: Phil Edwards @ 2002-12-17 16:31 UTC (permalink / raw) To: Matt Austern; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:47 ` Neil Booth 2002-12-16 15:10 ` Jan Hubicka @ 2002-12-16 21:32 ` Joseph S. Myers 1 sibling, 0 replies; 67+ messages in thread From: Joseph S. Myers @ 2002-12-16 21:32 UTC (permalink / raw) To: Neil Booth; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:27 ` Jan Hubicka 2002-12-16 14:47 ` Neil Booth @ 2002-12-16 17:01 ` Mark Mitchell 1 sibling, 0 replies; 67+ messages in thread From: Mark Mitchell @ 2002-12-16 17:01 UTC (permalink / raw) To: Jan Hubicka, David Edelsohn; +Cc: Zack Weinberg, gcc, libstdc++ --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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:23 ` David Edelsohn 2002-12-16 14:27 ` Jan Hubicka @ 2002-12-17 0:47 ` Gabriel Dos Reis 2002-12-17 0:54 ` Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 0:47 UTC (permalink / raw) To: David Edelsohn; +Cc: Zack Weinberg, Jan Hubicka, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:47 ` Gabriel Dos Reis @ 2002-12-17 0:54 ` Jan Hubicka 2002-12-17 1:19 ` Gabriel Dos Reis 0 siblings, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 0:54 UTC (permalink / raw) To: Gabriel Dos Reis Cc: David Edelsohn, Zack Weinberg, Jan Hubicka, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:54 ` Jan Hubicka @ 2002-12-17 1:19 ` Gabriel Dos Reis 0 siblings, 0 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 1:19 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 13:52 basic-improvements merge status David Edelsohn 2002-12-16 13:57 ` Zack Weinberg @ 2002-12-16 14:29 ` Jan Hubicka 2002-12-16 14:29 ` David Edelsohn ` (2 more replies) 1 sibling, 3 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 14:29 UTC (permalink / raw) To: David Edelsohn; +Cc: Zack Weinberg, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:29 ` Jan Hubicka @ 2002-12-16 14:29 ` David Edelsohn 2002-12-16 14:35 ` Jan Hubicka 2002-12-17 0:55 ` Gabriel Dos Reis 2002-12-16 14:44 ` David Edelsohn 2002-12-17 0:53 ` Gabriel Dos Reis 2 siblings, 2 replies; 67+ messages in thread From: David Edelsohn @ 2002-12-16 14:29 UTC (permalink / raw) To: Jan Hubicka; +Cc: Zack Weinberg, gcc, libstdc++ >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:29 ` David Edelsohn @ 2002-12-16 14:35 ` Jan Hubicka 2002-12-17 0:55 ` Gabriel Dos Reis 1 sibling, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 14:35 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, Zack Weinberg, gcc, libstdc++ > >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:29 ` David Edelsohn 2002-12-16 14:35 ` Jan Hubicka @ 2002-12-17 0:55 ` Gabriel Dos Reis 2002-12-17 0:58 ` Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 0:55 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:55 ` Gabriel Dos Reis @ 2002-12-17 0:58 ` Jan Hubicka 2002-12-17 1:53 ` Gabriel Dos Reis 0 siblings, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 0:58 UTC (permalink / raw) To: Gabriel Dos Reis Cc: David Edelsohn, Jan Hubicka, Zack Weinberg, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:58 ` Jan Hubicka @ 2002-12-17 1:53 ` Gabriel Dos Reis 2002-12-17 4:16 ` Jan Hubicka 0 siblings, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 1:53 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 1:53 ` Gabriel Dos Reis @ 2002-12-17 4:16 ` Jan Hubicka 2002-12-17 4:29 ` Fergus Henderson 2002-12-17 8:39 ` Gabriel Dos Reis 0 siblings, 2 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 4:16 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 4:16 ` Jan Hubicka @ 2002-12-17 4:29 ` Fergus Henderson 2002-12-17 8:39 ` Gabriel Dos Reis 1 sibling, 0 replies; 67+ messages in thread From: Fergus Henderson @ 2002-12-17 4:29 UTC (permalink / raw) To: Jan Hubicka Cc: Gabriel Dos Reis, David Edelsohn, Zack Weinberg, gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 4:16 ` Jan Hubicka 2002-12-17 4:29 ` Fergus Henderson @ 2002-12-17 8:39 ` Gabriel Dos Reis 2002-12-17 13:58 ` Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 8:39 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 8:39 ` Gabriel Dos Reis @ 2002-12-17 13:58 ` Jan Hubicka 0 siblings, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 13:58 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:29 ` Jan Hubicka 2002-12-16 14:29 ` David Edelsohn @ 2002-12-16 14:44 ` David Edelsohn 2002-12-16 14:45 ` Jan Hubicka 2002-12-16 15:56 ` Andrew Pinski 2002-12-17 0:53 ` Gabriel Dos Reis 2 siblings, 2 replies; 67+ messages in thread From: David Edelsohn @ 2002-12-16 14:44 UTC (permalink / raw) To: Jan Hubicka; +Cc: Zack Weinberg, gcc, libstdc++ >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:44 ` David Edelsohn @ 2002-12-16 14:45 ` Jan Hubicka 2002-12-16 14:52 ` David Edelsohn ` (2 more replies) 2002-12-16 15:56 ` Andrew Pinski 1 sibling, 3 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 14:45 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, Zack Weinberg, gcc, libstdc++, rth > >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:45 ` Jan Hubicka @ 2002-12-16 14:52 ` David Edelsohn 2002-12-16 14:54 ` Jan Hubicka 2002-12-16 15:05 ` [libstdc++] " Jan Hubicka 2002-12-16 15:40 ` Dale Johannesen 2002-12-16 15:55 ` Benjamin Kosnik 2 siblings, 2 replies; 67+ messages in thread From: David Edelsohn @ 2002-12-16 14:52 UTC (permalink / raw) To: Jan Hubicka; +Cc: Zack Weinberg, gcc, libstdc++, Richard Henderson >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:52 ` David Edelsohn @ 2002-12-16 14:54 ` Jan Hubicka 2002-12-16 17:05 ` Mark Mitchell 2002-12-16 15:05 ` [libstdc++] " Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 14:54 UTC (permalink / raw) To: David Edelsohn Cc: Jan Hubicka, Zack Weinberg, gcc, libstdc++, Richard Henderson > >>>>> 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:54 ` Jan Hubicka @ 2002-12-16 17:05 ` Mark Mitchell 2002-12-17 0:44 ` Jan Hubicka 2002-12-17 1:16 ` Gabriel Dos Reis 0 siblings, 2 replies; 67+ messages in thread From: Mark Mitchell @ 2002-12-16 17:05 UTC (permalink / raw) To: Jan Hubicka, David Edelsohn Cc: Zack Weinberg, gcc, libstdc++, Richard Henderson --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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 17:05 ` Mark Mitchell @ 2002-12-17 0:44 ` Jan Hubicka 2002-12-17 0:46 ` Mark Mitchell 2002-12-17 1:16 ` Gabriel Dos Reis 1 sibling, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 0:44 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > > > --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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:44 ` Jan Hubicka @ 2002-12-17 0:46 ` Mark Mitchell 2002-12-17 0:51 ` Jan Hubicka ` (3 more replies) 0 siblings, 4 replies; 67+ messages in thread From: Mark Mitchell @ 2002-12-17 0:46 UTC (permalink / raw) To: Jan Hubicka Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:46 ` Mark Mitchell @ 2002-12-17 0:51 ` Jan Hubicka 2002-12-17 4:10 ` Joseph S. Myers 2002-12-17 9:43 ` Mark Mitchell 2002-12-17 0:54 ` basic-improvements merge status Jan Hubicka ` (2 subsequent siblings) 3 siblings, 2 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 0:51 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > >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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:51 ` Jan Hubicka @ 2002-12-17 4:10 ` Joseph S. Myers 2002-12-17 7:06 ` Gabriel Dos Reis 2002-12-17 9:43 ` Mark Mitchell 1 sibling, 1 reply; 67+ messages in thread From: Joseph S. Myers @ 2002-12-17 4:10 UTC (permalink / raw) To: Jan Hubicka; +Cc: Mark Mitchell, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 4:10 ` Joseph S. Myers @ 2002-12-17 7:06 ` Gabriel Dos Reis 2002-12-17 11:42 ` Joseph S. Myers 0 siblings, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 7:06 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Jan Hubicka, Mark Mitchell, gcc, libstdc++ "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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 7:06 ` Gabriel Dos Reis @ 2002-12-17 11:42 ` Joseph S. Myers 0 siblings, 0 replies; 67+ messages in thread From: Joseph S. Myers @ 2002-12-17 11:42 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:51 ` Jan Hubicka 2002-12-17 4:10 ` Joseph S. Myers @ 2002-12-17 9:43 ` Mark Mitchell 2002-12-17 14:06 ` Jan Hubicka 2002-12-17 14:36 ` Implicit generation of runtime calls Jan Hubicka 1 sibling, 2 replies; 67+ messages in thread From: Mark Mitchell @ 2002-12-17 9:43 UTC (permalink / raw) To: Jan Hubicka Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson --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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 9:43 ` Mark Mitchell @ 2002-12-17 14:06 ` Jan Hubicka 2002-12-17 14:18 ` Gabriel Dos Reis 2002-12-17 14:36 ` Implicit generation of runtime calls Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 14:06 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > > > --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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 14:06 ` Jan Hubicka @ 2002-12-17 14:18 ` Gabriel Dos Reis 0 siblings, 0 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 14:18 UTC (permalink / raw) To: Jan Hubicka Cc: Mark Mitchell, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Implicit generation of runtime calls 2002-12-17 9:43 ` Mark Mitchell 2002-12-17 14:06 ` Jan Hubicka @ 2002-12-17 14:36 ` Jan Hubicka 2002-12-17 14:51 ` Jan Hubicka 1 sibling, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 14:36 UTC (permalink / raw) To: Mark Mitchell, gcc-patches Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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" } ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Implicit generation of runtime calls 2002-12-17 14:36 ` Implicit generation of runtime calls Jan Hubicka @ 2002-12-17 14:51 ` Jan Hubicka 0 siblings, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 14:51 UTC (permalink / raw) To: Jan Hubicka Cc: Mark Mitchell, gcc-patches, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:46 ` Mark Mitchell 2002-12-17 0:51 ` Jan Hubicka @ 2002-12-17 0:54 ` Jan Hubicka 2002-12-17 3:24 ` Gabriel Dos Reis 2002-12-17 1:51 ` basic-improvements merge status Gabriel Dos Reis 2002-12-17 21:21 ` Alexandre Oliva 3 siblings, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 0:54 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > >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)) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:54 ` basic-improvements merge status Jan Hubicka @ 2002-12-17 3:24 ` Gabriel Dos Reis 2002-12-17 4:28 ` Hot to configure sinf? Jan Hubicka 0 siblings, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 3:24 UTC (permalink / raw) To: Jan Hubicka Cc: Mark Mitchell, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson Jan Hubicka <jh@suse.cz> writes: | > The simplest approach would be something like TARGET_MEM_FUNCTIONS. | I've applied the attached patch. Thanks! -- Gaby ^ permalink raw reply [flat|nested] 67+ messages in thread
* Hot to configure sinf? 2002-12-17 3:24 ` Gabriel Dos Reis @ 2002-12-17 4:28 ` Jan Hubicka 2002-12-17 8:24 ` Gabriel Dos Reis 0 siblings, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 4:28 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jan Hubicka, Mark Mitchell, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Hot to configure sinf? 2002-12-17 4:28 ` Hot to configure sinf? Jan Hubicka @ 2002-12-17 8:24 ` Gabriel Dos Reis 0 siblings, 0 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 8:24 UTC (permalink / raw) To: Jan Hubicka Cc: Mark Mitchell, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:46 ` Mark Mitchell 2002-12-17 0:51 ` Jan Hubicka 2002-12-17 0:54 ` basic-improvements merge status Jan Hubicka @ 2002-12-17 1:51 ` Gabriel Dos Reis 2002-12-17 21:31 ` Alexandre Oliva 2002-12-17 21:21 ` Alexandre Oliva 3 siblings, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 1:51 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 1:51 ` basic-improvements merge status Gabriel Dos Reis @ 2002-12-17 21:31 ` Alexandre Oliva 0 siblings, 0 replies; 67+ messages in thread From: Alexandre Oliva @ 2002-12-17 21:31 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Mark Mitchell, Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:46 ` Mark Mitchell ` (2 preceding siblings ...) 2002-12-17 1:51 ` basic-improvements merge status Gabriel Dos Reis @ 2002-12-17 21:21 ` Alexandre Oliva 2002-12-18 5:44 ` Jan Hubicka 3 siblings, 1 reply; 67+ messages in thread From: Alexandre Oliva @ 2002-12-17 21:21 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 21:21 ` Alexandre Oliva @ 2002-12-18 5:44 ` Jan Hubicka 0 siblings, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-18 5:44 UTC (permalink / raw) To: Alexandre Oliva Cc: Mark Mitchell, Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 17:05 ` Mark Mitchell 2002-12-17 0:44 ` Jan Hubicka @ 2002-12-17 1:16 ` Gabriel Dos Reis 1 sibling, 0 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 1:16 UTC (permalink / raw) To: Mark Mitchell Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, Richard Henderson 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [libstdc++] Re: basic-improvements merge status 2002-12-16 14:52 ` David Edelsohn 2002-12-16 14:54 ` Jan Hubicka @ 2002-12-16 15:05 ` Jan Hubicka 1 sibling, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 15:05 UTC (permalink / raw) To: David Edelsohn Cc: Jan Hubicka, Zack Weinberg, gcc, libstdc++, Richard Henderson > >>>>> 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@ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:45 ` Jan Hubicka 2002-12-16 14:52 ` David Edelsohn @ 2002-12-16 15:40 ` Dale Johannesen 2002-12-16 16:16 ` Jan Hubicka 2002-12-16 15:55 ` Benjamin Kosnik 2 siblings, 1 reply; 67+ messages in thread From: Dale Johannesen @ 2002-12-16 15:40 UTC (permalink / raw) To: Jan Hubicka Cc: Dale Johannesen, David Edelsohn, Zack Weinberg, gcc, libstdc++, rth 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? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 15:40 ` Dale Johannesen @ 2002-12-16 16:16 ` Jan Hubicka 2002-12-16 17:12 ` Dale Johannesen 2002-12-17 1:14 ` Gabriel Dos Reis 0 siblings, 2 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 16:16 UTC (permalink / raw) To: Dale Johannesen Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, rth > > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 16:16 ` Jan Hubicka @ 2002-12-16 17:12 ` Dale Johannesen 2002-12-16 19:16 ` Fergus Henderson 2002-12-17 1:14 ` Gabriel Dos Reis 1 sibling, 1 reply; 67+ messages in thread From: Dale Johannesen @ 2002-12-16 17:12 UTC (permalink / raw) To: Jan Hubicka Cc: Dale Johannesen, David Edelsohn, Zack Weinberg, gcc, libstdc++, rth 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? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 17:12 ` Dale Johannesen @ 2002-12-16 19:16 ` Fergus Henderson 0 siblings, 0 replies; 67+ messages in thread From: Fergus Henderson @ 2002-12-16 19:16 UTC (permalink / raw) To: Dale Johannesen Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++, rth 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 16:16 ` Jan Hubicka 2002-12-16 17:12 ` Dale Johannesen @ 2002-12-17 1:14 ` Gabriel Dos Reis 2002-12-17 3:48 ` Joseph S. Myers 1 sibling, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 1:14 UTC (permalink / raw) To: Jan Hubicka Cc: Dale Johannesen, David Edelsohn, Zack Weinberg, gcc, libstdc++, rth 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 1:14 ` Gabriel Dos Reis @ 2002-12-17 3:48 ` Joseph S. Myers 0 siblings, 0 replies; 67+ messages in thread From: Joseph S. Myers @ 2002-12-17 3:48 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:45 ` Jan Hubicka 2002-12-16 14:52 ` David Edelsohn 2002-12-16 15:40 ` Dale Johannesen @ 2002-12-16 15:55 ` Benjamin Kosnik 2002-12-16 16:10 ` Jan Hubicka 2 siblings, 1 reply; 67+ messages in thread From: Benjamin Kosnik @ 2002-12-16 15:55 UTC (permalink / raw) To: Jan Hubicka; +Cc: dje, jh, zack, gcc, libstdc++, rth 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 15:55 ` Benjamin Kosnik @ 2002-12-16 16:10 ` Jan Hubicka 0 siblings, 0 replies; 67+ messages in thread From: Jan Hubicka @ 2002-12-16 16:10 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: Jan Hubicka, dje, zack, gcc, libstdc++, rth > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:44 ` David Edelsohn 2002-12-16 14:45 ` Jan Hubicka @ 2002-12-16 15:56 ` Andrew Pinski 1 sibling, 0 replies; 67+ messages in thread From: Andrew Pinski @ 2002-12-16 15:56 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, Zack Weinberg, gcc, libstdc++ 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 > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-16 14:29 ` Jan Hubicka 2002-12-16 14:29 ` David Edelsohn 2002-12-16 14:44 ` David Edelsohn @ 2002-12-17 0:53 ` Gabriel Dos Reis 2002-12-17 0:56 ` Jan Hubicka 2002-12-17 2:12 ` Gabriel Dos Reis 2 siblings, 2 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 0:53 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:53 ` Gabriel Dos Reis @ 2002-12-17 0:56 ` Jan Hubicka 2002-12-17 1:22 ` Gabriel Dos Reis 2002-12-17 2:12 ` Gabriel Dos Reis 1 sibling, 1 reply; 67+ messages in thread From: Jan Hubicka @ 2002-12-17 0:56 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jan Hubicka, David Edelsohn, Zack Weinberg, gcc, libstdc++ > 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:56 ` Jan Hubicka @ 2002-12-17 1:22 ` Gabriel Dos Reis 2002-12-17 3:20 ` Gabriel Dos Reis 0 siblings, 1 reply; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 1:22 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 1:22 ` Gabriel Dos Reis @ 2002-12-17 3:20 ` Gabriel Dos Reis 0 siblings, 0 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 3:20 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: basic-improvements merge status 2002-12-17 0:53 ` Gabriel Dos Reis 2002-12-17 0:56 ` Jan Hubicka @ 2002-12-17 2:12 ` Gabriel Dos Reis 1 sibling, 0 replies; 67+ messages in thread From: Gabriel Dos Reis @ 2002-12-17 2:12 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, Zack Weinberg, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2002-12-18 9:41 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-16 13:52 basic-improvements merge status David Edelsohn 2002-12-16 13:57 ` Zack Weinberg 2002-12-16 14:23 ` David Edelsohn 2002-12-16 14:27 ` Jan Hubicka 2002-12-16 14:47 ` Neil Booth 2002-12-16 15:10 ` Jan Hubicka 2002-12-17 0:50 ` Gabriel Dos Reis 2002-12-17 15:54 ` Richard Henderson 2002-12-17 16:14 ` Gabriel Dos Reis 2002-12-18 5:29 ` Jan Hubicka 2002-12-17 16:19 ` Matt Austern 2002-12-17 16:31 ` Phil Edwards 2002-12-16 21:32 ` Joseph S. Myers 2002-12-16 17:01 ` Mark Mitchell 2002-12-17 0:47 ` Gabriel Dos Reis 2002-12-17 0:54 ` Jan Hubicka 2002-12-17 1:19 ` Gabriel Dos Reis 2002-12-16 14:29 ` Jan Hubicka 2002-12-16 14:29 ` David Edelsohn 2002-12-16 14:35 ` Jan Hubicka 2002-12-17 0:55 ` Gabriel Dos Reis 2002-12-17 0:58 ` Jan Hubicka 2002-12-17 1:53 ` Gabriel Dos Reis 2002-12-17 4:16 ` Jan Hubicka 2002-12-17 4:29 ` Fergus Henderson 2002-12-17 8:39 ` Gabriel Dos Reis 2002-12-17 13:58 ` Jan Hubicka 2002-12-16 14:44 ` David Edelsohn 2002-12-16 14:45 ` Jan Hubicka 2002-12-16 14:52 ` David Edelsohn 2002-12-16 14:54 ` Jan Hubicka 2002-12-16 17:05 ` Mark Mitchell 2002-12-17 0:44 ` Jan Hubicka 2002-12-17 0:46 ` Mark Mitchell 2002-12-17 0:51 ` Jan Hubicka 2002-12-17 4:10 ` Joseph S. Myers 2002-12-17 7:06 ` Gabriel Dos Reis 2002-12-17 11:42 ` Joseph S. Myers 2002-12-17 9:43 ` Mark Mitchell 2002-12-17 14:06 ` Jan Hubicka 2002-12-17 14:18 ` Gabriel Dos Reis 2002-12-17 14:36 ` Implicit generation of runtime calls Jan Hubicka 2002-12-17 14:51 ` Jan Hubicka 2002-12-17 0:54 ` basic-improvements merge status Jan Hubicka 2002-12-17 3:24 ` Gabriel Dos Reis 2002-12-17 4:28 ` Hot to configure sinf? Jan Hubicka 2002-12-17 8:24 ` Gabriel Dos Reis 2002-12-17 1:51 ` basic-improvements merge status Gabriel Dos Reis 2002-12-17 21:31 ` Alexandre Oliva 2002-12-17 21:21 ` Alexandre Oliva 2002-12-18 5:44 ` Jan Hubicka 2002-12-17 1:16 ` Gabriel Dos Reis 2002-12-16 15:05 ` [libstdc++] " Jan Hubicka 2002-12-16 15:40 ` Dale Johannesen 2002-12-16 16:16 ` Jan Hubicka 2002-12-16 17:12 ` Dale Johannesen 2002-12-16 19:16 ` Fergus Henderson 2002-12-17 1:14 ` Gabriel Dos Reis 2002-12-17 3:48 ` Joseph S. Myers 2002-12-16 15:55 ` Benjamin Kosnik 2002-12-16 16:10 ` Jan Hubicka 2002-12-16 15:56 ` Andrew Pinski 2002-12-17 0:53 ` Gabriel Dos Reis 2002-12-17 0:56 ` Jan Hubicka 2002-12-17 1:22 ` Gabriel Dos Reis 2002-12-17 3:20 ` Gabriel Dos Reis 2002-12-17 2:12 ` Gabriel Dos Reis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).