basic-improvements merge status

basic-improvements merge status

[Zack Weinberg]

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

Still unresolved problems reported to me are:

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

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

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

Thoughts?

zw

Re: basic-improvements merge status

[Mark Mitchell]

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

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

So, do the merge.

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

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

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

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

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

Thanks,

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

Re: basic-improvements merge status

[Zack Weinberg]

Mark Mitchell <mark@codesourcery.com> writes:

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

Thanks for the vote of confidence ...

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

zw

Re: basic-improvements merge status

[Mark Mitchell]

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

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

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

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

Then, I would do something like:

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

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

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

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

Re: basic-improvements merge status

[Tom Lord]

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


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

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

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

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

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

    larch whats-missing ...

output into an `xargs' of 

    larch replay ...

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

    larch whats-missing --summary

and apply `larch replay' to those.

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

:-)


-t

Re: basic-improvements merge status

[DJ Delorie]

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

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

I wish CVS could do this.

Re: basic-improvements merge status

[Jason R Thorpe]

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

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

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

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

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

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

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

Re: basic-improvements merge status

[Jan Hubicka]

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

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

Honza
> 
> zw

Re: basic-improvements merge status

[Geoff Keating]

Zack Weinberg <zack@codesourcery.com> writes:

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

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

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

RE: basic-improvements merge status

[Robert McNulty Junior]

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


Zack Weinberg <zack@codesourcery.com> writes:

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

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

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


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

Re: basic-improvements merge status

[Mark Mitchell]

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

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

I'm unhappy that you're unhappy.

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

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

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

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

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

Re: basic-improvements merge status

[David Edelsohn]

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

	No new c-torture fails.

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

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

David

Re: basic-improvements merge status

[David Edelsohn]

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

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

is being compiled as

	bl sinf

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

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

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

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

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

	(float) sin(x)

as

	sinf(x)?

Thanks, David

Re: basic-improvements merge status

[Zack Weinberg]

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

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

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

zw

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Zack Weinberg writes:

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

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

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

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

David

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

Re: basic-improvements merge status

[Neil Booth]

Jan Hubicka wrote:-

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

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

Neil.

Re: basic-improvements merge status

[Jan Hubicka]

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

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

Honza
> 
> Neil.

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

[...]

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

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

-- Gaby

Re: basic-improvements merge status

[Richard Henderson]

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

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

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

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


r~

Re: basic-improvements merge status

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

[...]

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

I never claimed that the current behaviour is correct.

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Matt Austern]

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

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

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

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

			--Matt

Re: basic-improvements merge status

[Phil Edwards]

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

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


Phil

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

Re: basic-improvements merge status

[Joseph S. Myers]

On Mon, 16 Dec 2002, Neil Booth wrote:

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

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

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

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

Re: basic-improvements merge status

[Mark Mitchell]

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

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

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

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

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

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

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

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

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

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

Which function is not valid C? 

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

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

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

Honza

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Jan Hubicka writes:

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

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

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

David

Re: basic-improvements merge status

[Jan Hubicka]

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

Honza
> 
> David

Re: basic-improvements merge status

[Gabriel Dos Reis]

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

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

This is papering over broken assumptions made by the transformation.

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

-fno-builtin-sin does the trick.

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

| -fno-builtin-sin does the trick.

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

Re: basic-improvements merge status

[Fergus Henderson]

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

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Jan Hubicka writes:

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

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

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

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

David

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

Honza

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

Re: basic-improvements merge status

[David Edelsohn]

>>>>> Jan Hubicka writes:

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

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

David

Re: basic-improvements merge status

[Jan Hubicka]

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

Re: basic-improvements merge status

[Mark Mitchell]

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

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

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

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

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

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

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

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

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

Re: basic-improvements merge status

[Mark Mitchell]

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

Thanks; that's fine.

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

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

The simplest approach would be something like TARGET_MEM_FUNCTIONS.

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

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

Re: basic-improvements merge status

[Joseph S. Myers]

On Tue, 17 Dec 2002, Jan Hubicka wrote:

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

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

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

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

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

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

-- Gaby

Re: basic-improvements merge status

[Joseph S. Myers]

On 17 Dec 2002, Gabriel Dos Reis wrote:

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

There are the separate questions of:

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

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

Re: basic-improvements merge status

[Mark Mitchell]

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

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

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

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

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

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

Thanks!

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

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

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

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

-- Gaby

Re: basic-improvements merge status

[Alexandre Oliva]

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

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

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

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

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

Re: basic-improvements merge status

[Alexandre Oliva]

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

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

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

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

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

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

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

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

100% agreed.

-- Gaby

Re: basic-improvements merge status

[Dale Johannesen]

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

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

Re: basic-improvements merge status

[Jan Hubicka]

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

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

Honza

Re: basic-improvements merge status

[Dale Johannesen]

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

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

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

Re: basic-improvements merge status

[Fergus Henderson]

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

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

-- Gaby

Re: basic-improvements merge status

[Joseph S. Myers]

On 17 Dec 2002, Gabriel Dos Reis wrote:

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

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

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

Re: basic-improvements merge status

[Benjamin Kosnik]

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

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

See:

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

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

-benjamin

Re: basic-improvements merge status

[Jan Hubicka]

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

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

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

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

Honza
> 
> -benjamin

Re: basic-improvements merge status

[Andrew Pinski]

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

Thanks,
Andrew Pinski

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

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

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

-- Gaby

Re: basic-improvements merge status

[Jan Hubicka]

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

Honza
> 
> -- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

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

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

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

-- Gaby

Re: basic-improvements merge status

[Gabriel Dos Reis]

Jan Hubicka <jh@suse.cz> writes:

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

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

-- Gaby

Re: basic-improvements merge status

[Geoff Keating]

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

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

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

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

Re: basic-improvements merge status

[Zack Weinberg]

Geoff Keating <geoffk@geoffk.org> writes:

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

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

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

#include "rtl.h"

Have you got a sticky tag or something?

zw

Re: basic-improvements merge status

[Geoff Keating]

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

I did.  I wonder how that happened?

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

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