Re: RFA: how to handle union wait portably?

Re: RFA: how to handle union wait portably?

[Michael Sokolov]

Kaveh R. Ghazi <ghazi@caip.rutgers.edu> wrote:

> Kaveh
> ----^

I know, that was a typo.

> I'd phrase it differently. 4.3BSD's sys/wait.h is never
> POSIX-compliant, even technically speaking.

Well, not so fast. What's the definition of <sys/wait.h> being POSIX-compliant?
That when it is #included, WIFEXITED and WIFSIGNALED can be applied to an int
producing a correctly working program, right? This holds when compiled with
PCC.

> How about unconditionally doing #undef HAVE_SYS_WAIT_H in the relevant
> bsd specific config file?  (Do so with lots of explanitory comments.)
> I believe the host config file gets included after auto-host.h.

OK, I'll consider doing that.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

Re: RFA: how to handle union wait portably?

[Michael Sokolov]

Per Bothner <per@bothner.com> wrote:

> It seems to me that when you switch compilers you should re-run
> configure.  So arguably it is a bug in 'make bootstap' if it doesn't
> do that.

Well, this is definitely for more big-time GCC folks, not for me little 4.3BSD
user. :-)

> Another possible solution:  Add fix-includes changes so that
> WIFEXITED etc cast their arguments to (union wait*).

I don't think it's that simple. The argument to these macros needs to be a
union wait, not a union wait *. While you can easily cast from an int * to a
union wait *, I don't think you can cast from an int to a union wait. Applying
a & to the argument won't work either, I think. If in POSIX these macros take a
simple int, they don't require a lvalue, do they? So I don't see how this
approach can be used.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

Re: RFA: how to handle union wait portably?

[Richard Henderson]

On Fri, Dec 29, 2000 at 09:38:01PM -0800, Michael Sokolov wrote:
> How would it know that it ought not be able to compile something that
> compiles and works 100% correctly? By ESP?

By writing code that should return an error from the 
compiler but doesn't.

> Would you mind using more respectful terminology? PCC is not broken...

Yes it is.  Forget ISO C, the language definition I know as K&R
doesn't allow nonsense like applying structure member tags to
non-structures.  Or for that matter, applying structure member
tags to structures that do not contain that member, which IIRC
is another PCC bug.

And please leave off with the advocacy.  It's tiring.


r~

Re: RFA: how to handle union wait portably?

[Per Bothner]

msokolov@ivan.Harhan.ORG (Michael Sokolov) writes:

> The upshot of all this is that everything works correctly except when doing a
> 3-stage GCC bootstrap with make bootstrap using the native cc as the starting
> compiler. I don't see how the GCC source could be changed to avoid this
> problem.

It seems to me that when you switch compilers you should re-run
configure.  So arguably it is a bug in 'make bootstap' if it doesn't
do that.

Another possible solution:  Add fix-includes changes so that
WIFEXITED etc cast their arguments to (union wait*).

One might argue that both fixes should be done.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: RFA: how to handle union wait portably?

[Michael Sokolov]

Richard Henderson <rth@redhat.com> wrote:

> You could also modify the sys/wait test to fail if we can compile
> something we ought not be able to do.

How would it know that it ought not be able to compile something that compiles
and works 100% correctly? By ESP?

> I.e.  detect PCC brokenness.  

Would you mind using more respectful terminology? PCC is not broken, it just
deliberately chooses to implement a different version of the language (one
compatible with its predecessor, Ritchie's original compiler) than the one you
have deliberately chosen to implement (ISO C).

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

Re: RFA: how to handle union wait portably?

[Richard Henderson]

On Fri, Dec 29, 2000 at 05:45:23PM -0500, Kaveh R. Ghazi wrote:
> How about unconditionally doing #undef HAVE_SYS_WAIT_H in the relevant
> bsd specific config file?  (Do so with lots of explanitory comments.)
> I believe the host config file gets included after auto-host.h.

You could also modify the sys/wait test to fail if we can compile
something we ought not be able to do.  I.e.  detect PCC brokenness.  


r~

Re: RFA: how to handle union wait portably?

[Kaveh R. Ghazi]

 > From: msokolov@ivan.Harhan.ORG (Michael Sokolov) 
 > 
 > Kaven, you've hit the nail right on the head! "sys/wait.h that is

Glad to have been of help. :-)  BTW, its:
Kaveh
----^

 > POSIX.1 compatible" means that you can apply WIFEXITED and WIFSIGNALED
 > to an int, right? If so, the autoconf test is correct, but... it is
 > negative when the compiler is GCC but positive when the compiler is
 > PCC! 4.3BSD's <sys/wait.h> defines WIFEXITED and WIFSIGNALED macros
 > that apply the dot operator to their argument. This causes
 > <sys/wait.h> to be not POSIX-compliant assuming an ISO C compiler that
 > doesn't allow applying the dot operator to an int. However, PCC does
 > allow applying the dot operator to an int, so when the compiler is
 > PCC, 4.3BSD's <sys/wait.h> technically *is* POSIX-compliant!

I'd phrase it differently. 4.3BSD's sys/wait.h is never
POSIX-compliant, even technically speaking.  PCC is non-compliant,
period.


 > The upshot of all this is that everything works correctly except when
 > doing a 3-stage GCC bootstrap with make bootstrap using the native cc
 > as the starting compiler. I don't see how the GCC source could be
 > changed to avoid this problem.

How about unconditionally doing #undef HAVE_SYS_WAIT_H in the relevant
bsd specific config file?  (Do so with lots of explanitory comments.)
I believe the host config file gets included after auto-host.h.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: RFA: how to handle union wait portably?

[Michael Sokolov]

Kaveh R. Ghazi <ghazi@caip.rutgers.edu> wrote:

> Hmm, you say you have conflicts with sys/wait.h.  But IIRC the test
> for sys/wait.h not only checks whether the file exists, but also
> whether it is POSIX compatible.  BSD's is not, so you shouldn't see it
> get included during bootstrap.  I think that is the cause of your
> problems, what does cofigure say for this test?
>
> "checking for sys/wait.h that is POSIX.1 compatible... ???"
>
> If it says "yes", does forcing it to "no" fix your problem,
> and can you figure out why it erroneously says "yes"?

Kaven, you've hit the nail right on the head! "sys/wait.h that is POSIX.1
compatible" means that you can apply WIFEXITED and WIFSIGNALED to an int,
right? If so, the autoconf test is correct, but... it is negative when the
compiler is GCC but positive when the compiler is PCC! 4.3BSD's <sys/wait.h>
defines WIFEXITED and WIFSIGNALED macros that apply the dot operator to their
argument. This causes <sys/wait.h> to be not POSIX-compliant assuming an ISO C
compiler that doesn't allow applying the dot operator to an int. However, PCC
does allow applying the dot operator to an int, so when the compiler is PCC,
4.3BSD's <sys/wait.h> technically *is* POSIX-compliant!

The upshot of all this is that everything works correctly except when doing a
3-stage GCC bootstrap with make bootstrap using the native cc as the starting
compiler. I don't see how the GCC source could be changed to avoid this
problem.

The easiest solution for me personally would be to simply not use make
bootstrap (which I never liked anyway). I will still test my patches for
bootstrapability as required, but I'll do it by installing the intermediate
stages and doing a new fresh configure and make for the next stage.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

Re: RFA: how to handle union wait portably?

[Kaveh R. Ghazi]

 > From: msokolov at ivan dot Harhan dot ORG (Michael Sokolov) 
 > 
 > In three places where it lauches and waits for child processes (gcc,
 > collect2, and protoize) GCC makes the implicit assumption that the
 > status variable filled in by wait is an int. It always uses an int
 > variable, passes an int * to wait (indirectly via pwait in libiberty),
 > and then applies the W* macros to this int. In system.h where the W*
 > macros are provided for systems that lack them again they are written
 > with the assumption that they need to deal with an int.
 > 
 > This breaks on 4.3BSD, where the process status is a union wait
 > instead of an int, although it has the same size and bit layout as it
 > does on other systems where it's an int. I.e., at the machine level
 > it's exactly the same 32-bit integer with the exact same layout, but
 > the 4.3BSD docs encourage programmers to declare it as union wait and
 > access its fields as union members, rather than declare it as an int
 > and shift and mask it. 4.3BSD's <sys/wait.h> defines union wait and
 > defines WIFEXITED and WIFSIGNALED macros that expect a union wait. It
 > does not define WEXITSTATUS or WTERMSIG because those aren't necessary
 > with a union wait, you just use .w_retcode and .w_termsig instead.
 > 
 > GCC breaks when compiled with itself (like in bootstrap stage 2)
 > because it declares this variable as an int, but uses the WIFEXITED
 > and WIFSIGNALED macros from 4.3BSD's <sys/wait.h>, which expect their
 > argument to be a union wait and apply the dot operator to it, at which
 > GCC instantly squeaks. (I haven't noticed this problem previously when
 > compiling GCC with PCC because PCC, and I know the ISO C folks here
 > will be horrified by this, allows you to apply the dot operator to
 > something that is not a struct or union. It issues a warning, but
 > doesn't abort compilation and produces correct code.) GCC has had this
 > problem since at least 2.8.1 (the earliest I checked) through the
 > current 2.97.
 > 
 > Alexandre (or other portability gurus here), would you happen to have
 > any insight on how to solve this problem in a portable way that
 > doesn't break other systems and would be acceptable for a patch for
 > the current GCC? TIA.

Hmm, you say you have conflicts with sys/wait.h.  But IIRC the test
for sys/wait.h not only checks whether the file exists, but also
whether it is POSIX compatible.  BSD's is not, so you shouldn't see it
get included during bootstrap.  I think that is the cause of your
problems, what does cofigure say for this test?

"checking for sys/wait.h that is POSIX.1 compatible... ???"

If it says "yes", does forcing it to "no" fix your problem,
and can you figure out why it erroneously says "yes"?

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

RFA: how to handle union wait portably?

[Michael Sokolov]

Alexandre, I guess this one is for you as the maintainer of the build/
portability machinery.

In three places where it lauches and waits for child processes (gcc, collect2,
and protoize) GCC makes the implicit assumption that the status variable filled
in by wait is an int. It always uses an int variable, passes an int * to wait
(indirectly via pwait in libiberty), and then applies the W* macros to this
int. In system.h where the W* macros are provided for systems that lack them
again they are written with the assumption that they need to deal with an int.

This breaks on 4.3BSD, where the process status is a union wait instead of an
int, although it has the same size and bit layout as it does on other systems
where it's an int. I.e., at the machine level it's exactly the same 32-bit
integer with the exact same layout, but the 4.3BSD docs encourage programmers
to declare it as union wait and access its fields as union members, rather than
declare it as an int and shift and mask it. 4.3BSD's <sys/wait.h> defines union
wait and defines WIFEXITED and WIFSIGNALED macros that expect a union wait. It
does not define WEXITSTATUS or WTERMSIG because those aren't necessary with a
union wait, you just use .w_retcode and .w_termsig instead.

GCC breaks when compiled with itself (like in bootstrap stage 2) because it
declares this variable as an int, but uses the WIFEXITED and WIFSIGNALED macros
from 4.3BSD's <sys/wait.h>, which expect their argument to be a union wait and
apply the dot operator to it, at which GCC instantly squeaks. (I haven't
noticed this problem previously when compiling GCC with PCC because PCC, and I
know the ISO C folks here will be horrified by this, allows you to apply the
dot operator to something that is not a struct or union. It issues a warning,
but doesn't abort compilation and produces correct code.) GCC has had this
problem since at least 2.8.1 (the earliest I checked) through the current 2.97.

Alexandre (or other portability gurus here), would you happen to have any
insight on how to solve this problem in a portable way that doesn't break other
systems and would be acceptable for a patch for the current GCC? TIA.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)