RE: PATCH: DG/UX Intel port

["Eric Raskin" <ehr at listworks dot com>]

Jeffrey:

>   > > Removing flag_signed_bitfields from OPTIMIZATION_OPTIONS is
>   > > both good and bad.
>   > >
>   > > The problem (I suspect) is dgux's compilers had unsigned
>   > > bitfields and the
>   > > the in OPTIMIZATION_OPTIONS is trying to make gcc be
>   > > compatible.  We need to
>   > > find a clean way to fix this problem.
>   > >
>   >
>   > DG/UX doesn't have its own compilers.  The compiler
> distributed with the
>   > latest DG/UX version is gcc 2.7.2.  I don't think
> compiler compatibility is
>   > the issue.
> Well, if it's what the compiler (gcc or any other) was doing
> in the past, then
> that in effect gives us a compiler compaibility issue.  ie,
> if we take the
> change out, then code compiled with gcc-2.95 would be
> incompatible with code
> compiled by gcc-2.7.2.
>
> So, we need to find a way to continue to set the signedness
> of bitfields,
> but without using OPTIMIZATION_OPTIONS.  I believe I outlined
> a way to do that
> in my original reply.  Something along the lines of creating
> a new macro
> "DEFAULT_SIGNED_BITFIELDS" or something like that.  Then using that to
> initialize flag_signed_bitfields.
>

I put in this change as you suggested.  I now get a few test failures I
didn't have before:

FAIL: g++.bugs/900401_01.C  (test for errors, line 12)
FAIL: g++.bugs/900402_01.C bitified with function type (test for errors,
line 12)

900401_01.C creates an unsigned 4 byte array as a typedef, then defines a
bitfield of that type inside a struct.  The comments in the code say that
g++ aborts but Cfront 2.0 passes.  I don't see why g++ should fail.  Which
is correct?

900402_01.C is another where Cfront 2.0 allows it and g++ aborts.  This one
typedefs a function type, then declares a bit string of that type in a
struct.  This one seems really wrong -- what's a void f():32?  Now, my test
is failing, meaning that g++ accepts it as well.  Again, which is correct?

I checked the test reports -- no one reports these tests as failing.  I
guess this patch breaks something.  Which is better, backwards compatibility
on the DG platform, or cross-platform compatibility at the current release
level?  Maybe we should leave the bitfield stuff alone -- possible (unknown)
backwards compatibility be damned, full speed ahead! [Any DG people out
there to comment on this?]

> The way to handle this would be separate patches.  One to fix
> the bug, then
> after that is installed a separate patch for just fixing
> formatting issues.
>

I've submitted a separate patch to egcs-patches fixing the [cd]tors problem
on shared objects in the native compiler.  Only changed 1 brace -- mininum
change necessary.  I'll leave the formatting alone.

>   > Actually what I did is took the current _int_varargs.h
> from my DG/UX
>   > installation and used it to replace the one currently
> distributed.  The
>   > currently distributed version didn't work.  So, I didn't
> actually include
>   > any gratuitous whitespace changes on my own.  What should
> I do to make this
>   > better?
> OK.  This might be OK then.  It probably makes sense to go
> ahead and resend
> this patch separately too.

Re-submitted as a separate patch to egcs-patches today.

> For ChangeLogs:
>
>   1. Do not send the ChangeLog entry as a patch.  Send it as
> plaintext.
>
>      The reason we do not want ChangeLog patches is because
> they rarely
>      apply because the patch always references the top of the
> file which
>      is always changing.
>
>
>   2. The format of a ChangeLog entry is:
>
> <tab>* filename (procedure/macro that was changed): What changed.
>
>

understood.

Have a nice Memorial Day holiday!

	Eric Raskin