Compiling GCC with g++: a report

Compiling GCC with g++: a report

[Gabriel Dos Reis]

Hi,

  I spent the week-end trying to get GCC -- mainline -- compilable
(i.e. those compoenents written in C) with a C++ compiler (e.g. g++).

My summary is:  It is largely doable and it is within our reach at this
point of development.  More specifically, I successfully got all
files necessary to build a native GNU C compiler on an i686-pc-linux-gnu.
Attempt to get the GNU C++ compiler through the same massage is
underway (but I'm going to bed shortly ;-)).

I think this project is beneficial to GCC for several reasons:

  (1) for testing purposes, we can use a compiler with stricter type
      checking.

  (2) there have been lots of discussions about more static typing in
      the data structures, but so far we haven't made anything
      concrete.  Partly because, we need this sort of preliminary
      preparation of thee source tree.  We can have infinite debates
      about the merits of such approaches, but I think a way to know
      is to do actual experiments and we better start making that
      possible now.

  (3) It might open the door for more contributions and foster more
      free software based on GCC.

  (4) <insert your favorite reasons why you would like to see this happen>.


What I have learnt from this little experience.  Well, the source code
seems to have been carefully written to make sure that no lunatic
(e.g. the author of this writing) will succeed in feeding a C++
compiler with GCC :-)

The first resistance seems to come from the pervasive use of the implicit
conversion void* -> T*, mostly with storage allocating functions.
We've recently introduced C++ friendly macros in libiberty, but we
have yet to take advantage of them.  We should start now.
(I also noted a happy confusion about the calling convention of the
function [x]calloc(), but it is mostly harmless as everything "multiply
nicely" in the end and we don't get burned by strict alignment
issues).  We should generalize the notation for GGC allocators and
alloca(). 


The second resistance is the pervasive use of C++ keywords (e.g. new,
class, template, try, catch, ...).  The first three are quite
frequent in the middle-end.


Third, there is some "type-punning" with enums, int and unsigned int,
where the middle-end (mostly) relies on implicit conversion from int
to enums.  That is a bit annoying but could be avoided as most of the
time, we do have names for those integer constants.  For example, we
should be using EXPAND_NORMAL instead of 0, or VOIDmode, instead of
0, TV_TOTAL instead of 0, etc.  At this point, I should also note that
not implicit conversions between enums (c_tree_code <-> tree_code, or
rtx_code  <-> reg_note, etc.) is not supported in C++.  So, we should
probably arrange to make the relationship (mostly subsetting) between
more explicit, as opposed to throwing in casts.  Also, there are few
cases where we want to iterate over all the values of enumerations.
I've shamelessly used the following macros:

   #define NEXT(E)  ((__typeof__(E)) (E + 1))
   #define PREV(E)  ((__typeof__(E)) (E - 1))
   #define DECR(E)  (E = (__typeof__(E)) (E - 1))
   #define INCR(E)  (E = (__typeof__(E)) (E + 1))
   #define IOR(A,B) ((__typeof__(A)) (A | B))
   #define AND(A,B) ((__typeof__(A)) (A & B))
   #define XOR(A,B) ((__typeof__(A)) (A ^ B))

but I'm not suggesting that as real replacement; just reporting the
dirty tricks I did and I'm looking for better suggestions. 


Fourth, it appears that we're implicilty using C99's semantics of 
"extern inline" in our source -- when we have a pure C90 compiler that
does not understand "inline", we just #define inline to nothing so we
don't get into trouble.  With a C++ compiler, we're in trouble because
an inline function needs to be defined in every translation where it
is used.  So, I either move the affected functions to "static inline"
or just make then non-inline (cases are in hashtable.c and toplev.c).


Fifth, there is a slight difference between "const" in C and in C++.
In C++, a const variable implicitly has an internal linkage; so a
C++ compiler tends to optimize it out when its address is not taken
(so no storage is wasted).  This is an issue for the objects
automatically generated by the gengtype support machinery.  The are
supposed to have external linkage, so we need to explicitly say
"extern" in their definitions. 


Sixth, there is a real "mess" about name spaces.  It is true that
every C programmers knows the rule saying tags inhabit different name
space than variable of functions.  However, all the C coding standards
I've read so far usually suggest 

   typedef struct foo foo;

but *not*

   typedef struct foo *foo;

i.e. "bringing" the tag-name into normal name space to name the type
structure or enumeration is OK, but not naming a different type!  the
latter practice will be flagged by a C++ compiler.  I guess we may
need some discussion about the naming of structure (POSIX reserves
anything ending with "_t", so we might want to choose something so
that we don't run into problem.  However, I do not expect this issue
to dominate the discussion :-))


So, if various components maintainers (e.g. C and C++, middle-end,
ports, etc.)  are willing to help quickly reviewing patches we can
have this done for this week (assuming mainline is unslushed soon).
And, of course, everybody can help :-)

Thanks,


-- 
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
	Texas A&M University -- Department of Computer Science
	301, Bright Building -- College Station, TX 77843-3112

Re: Compiling GCC with g++: a report

[Ranjit Mathew]

Gabriel Dos Reis wrote:
> Hi,
> 
>   I spent the week-end trying to get GCC -- mainline -- compilable
> (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).

[...]

> 
> I think this project is beneficial to GCC for several reasons:

[...]
> 
>   (4) <insert your favorite reasons why you would like to see this happen>.

Tom Tromey's GCJX (gcjx_branch in CVS), the completely
rewritten Java front-end that is written in C++.

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

| Hi,
| 
|   I spent the week-end trying to get GCC -- mainline -- compilable
| (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
| 
| My summary is:  It is largely doable and it is within our reach at this
| point of development.  More specifically, I successfully got all
| files necessary to build a native GNU C compiler on an i686-pc-linux-gnu.
| Attempt to get the GNU C++ compiler through the same massage is
| underway (but I'm going to bed shortly ;-)).
| 
| I think this project is beneficial to GCC for several reasons:

I have received several inquiries as whether this is a project to have
GCC implemeted in C++.  

The answer is no.  

It is a project that will align us with our coding standard that codes
should live in the large intersection of C and C++.
Those not fluent in C++ should have to worry -- when/if they write
"good" codes in C :-).  Most certanly, patch reviewers will make
suggestions in case a patch falls outside. And since I brought the
issue, I volunteer to help fulfill that task.

-- Gaby

Re: Compiling GCC with g++: a report

[Tom Tromey]

>>>>> "Ranjit" == Ranjit Mathew <rmathew@gmail.com> writes:

>> (4) <insert your favorite reasons why you would like to see this happen>.

Ranjit> Tom Tromey's GCJX (gcjx_branch in CVS), the completely
Ranjit> rewritten Java front-end that is written in C++.

Plugging this into gcc has largely been fine, thanks to an earlier
round of patches in this area.

The biggest unsolved build issue is that it would be nice, when
bootstrapping native (build=host=target), to use the just-built g++
and libstdc++ for gcjx.  This involves some wacky build reordering
that I've been avoiding looking at.

Tom

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

[...]

| Attempt to get the GNU C++ compiler through the same massage is
| underway (but I'm going to bed shortly ;-)).

I can also report that I got the GNU C++ compiler through -- and apart
form uses of C++ keywords (template, namespace, class), it worked
out.  A note on type sfety issue though: lookup_name() is declared in
c-tree.h as

      extern tree lookup_name (tree);

and used in c-common.c:handle_cleanup_attribute() according to that
signature.  It is however declared and defined in cp/ as

      extern tree lookup_name (tree, int);

That was caught at link time (and dealt with).

-- Gaby

Re: Compiling GCC with g++: a report

[Joseph S. Myers]

On Tue, 24 May 2005, Gabriel Dos Reis wrote:

> I can also report that I got the GNU C++ compiler through -- and apart
> form uses of C++ keywords (template, namespace, class), it worked
> out.  A note on type sfety issue though: lookup_name() is declared in
> c-tree.h as
> 
>       extern tree lookup_name (tree);
> 
> and used in c-common.c:handle_cleanup_attribute() according to that
> signature.  It is however declared and defined in cp/ as
> 
>       extern tree lookup_name (tree, int);

We should try to stop c-common.c from including c-tree.h.  If it is 
genuinely common code it shouldn't be including c-tree.h which is a C 
front end header.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
> Hi,
> 
>   I spent the week-end trying to get GCC -- mainline -- compilable
> (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).

These results are very interesting.

As a general observation: A lot of the things you have found to be
problematic, are in fact preferred idioms for C code.  For instance,
no standard-C programmer would ever write an explicit cast on malloc's
return value.  I think that we are losing something, if only in
readability, if we restrict our code to the subset of C which is also
correct C++.  Now, if we were migrating to C++, that would be okay,
because we would (eventually) get all of the additional expressive power
of C++ in exchange.  However, if we're not migrating to C++, I'm opposed
to the inclusion of patches that restrict our C code to the subset which
is correct C++.  Furthermore, as I've said before, I support migrating
to C++ -- but only if the C++ ABI and libstdc++ soname are first
permanently frozen.  If we do not do that first, we risk being trapped
into a situation where we need specific versions of GCC to compile
specific newer versions of GCC, which would be a Bad Thing.

The C++ ABI seems to be stable at this point, but there is not yet
consensus that it will never again be changed.  The libstdc++ team is
currently developing yet another new, incompatible version, so I see no
hope for a permanent freeze of its soname in the near future.  Thus,
while you've discovered some interesting things by trying this, I don't
think C++ compatibility patches should be applied now.

Having said that, some comments on the problems you have found:

> Third, there is some "type-punning" with enums, int and unsigned int,
> where the middle-end (mostly) relies on implicit conversion from int
> to enums.  

Being allowed to do this is very important.  Some enumerated types are
to be treated as opaque outside a very narrow context; the only way to
do that in C is to have (a typedef of) unsigned int as the visible type,
and only declare the enumerated type in the context where it's allowed
to be used.  I want to see more use of this idiom, not less; for
example, 'enum machine_mode' ought to be a black box to almost the
entire compiler.  I'd be delighted to hear of a more C++-friendly way to
code this.  Naturally, where the constant is _not_ opaque outside of a
defined context, but is part of an interface (as your examples seemed to
be), not using it is just sloppy.

> Fourth, it appears that we're implicilty using C99's semantics of 
> "extern inline" in our source -- when we have a pure C90 compiler that
> does not understand "inline", we just #define inline to nothing so we
> don't get into trouble.  With a C++ compiler, we're in trouble because
> an inline function needs to be defined in every translation where it
> is used.  So, I either move the affected functions to "static inline"
> or just make then non-inline (cases are in hashtable.c and toplev.c).

Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike.  Patches to add 'static' to such functions (AND MAKING NO OTHER
CHANGES) are preapproved, post-slush.

> Fifth, there is a slight difference between "const" in C and in C++.
> In C++, a const variable implicitly has an internal linkage; so a
> C++ compiler tends to optimize it out when its address is not taken
> (so no storage is wasted).  This is an issue for the objects
> automatically generated by the gengtype support machinery.  The are
> supposed to have external linkage, so we need to explicitly say
> "extern" in their definitions. 

Presumably such constants are declared in some header file, with
external linkage.  It would be better to make that declaration visible
at the point of definition, rather than marking up the declarations with
'extern'.

> Sixth, there is a real "mess" about name spaces.  It is true that
> every C programmers knows the rule saying tags inhabit different name
> space than variable of functions.  However, all the C coding standards
> I've read so far usually suggest 
> 
>    typedef struct foo foo;
> 
> but *not*
> 
>    typedef struct foo *foo;
> 
> i.e. "bringing" the tag-name into normal name space to name the type
> structure or enumeration is OK, but not naming a different type!

Ugh.  Where do we do that?  I will suggest, when you find these, that
you tack "_s" on the end of the tag-name; that doesn't conflict with
POSIX, and should require fewer changes elsewhere in the code.

zw

Re: Compiling GCC with g++: a report

[Daniel Jacobowitz]

On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
> As a general observation: A lot of the things you have found to be
> problematic, are in fact preferred idioms for C code.  For instance,
> no standard-C programmer would ever write an explicit cast on malloc's
> return value.  I think that we are losing something, if only in
> readability, if we restrict our code to the subset of C which is also
> correct C++.  Now, if we were migrating to C++, that would be okay,
> because we would (eventually) get all of the additional expressive power
> of C++ in exchange.  However, if we're not migrating to C++, I'm opposed
> to the inclusion of patches that restrict our C code to the subset which
> is correct C++.  Furthermore, as I've said before, I support migrating
> to C++ -- but only if the C++ ABI and libstdc++ soname are first
> permanently frozen.  If we do not do that first, we risk being trapped
> into a situation where we need specific versions of GCC to compile
> specific newer versions of GCC, which would be a Bad Thing.

You keep saying this and I don't think it means what you think it
means...

Being stuck requiring a specific version of GCC to compile a specific
newer version of GCC would be a restriction on _source compatibility_
and has nothing to do with binary compatibility.  I don't see any way
that the libstdc++ soname, for instance, could matter to this at all.

If you do, then please be more precise about what problems you're
talking about.

> The C++ ABI seems to be stable at this point, but there is not yet
> consensus that it will never again be changed.  The libstdc++ team is
> currently developing yet another new, incompatible version, so I see no
> hope for a permanent freeze of its soname in the near future.  Thus,
> while you've discovered some interesting things by trying this, I don't
> think C++ compatibility patches should be applied now.

There is no such thing as an ABI that will never again be changed. 
Designing anything at all around that assumption is just asking to be
hurt.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Compiling GCC with g++: a report

[Andrew Pinski]

On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
> Use of bare 'inline' is just plain wrong in our source code; this has
> nothing to do with C++, no two C compilers implement bare 'inline'
> alike.  Patches to add 'static' to such functions (AND MAKING NO OTHER
> CHANGES) are preapproved, post-slush.
That will not work for the cases where the bare 'inline' are used
because they are external also in this case.  Now this is where C99 and
C++ differs at what a bare 'inline' means so I have no idea what to
do, except for removing the 'inline' in first place.

Thanks,
Andrew Pinski

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
| > Hi,
| > 
| >   I spent the week-end trying to get GCC -- mainline -- compilable
| > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
| 
| These results are very interesting.
| 
| As a general observation: A lot of the things you have found to be
| problematic, are in fact preferred idioms for C code.  For instance,
| no standard-C programmer would ever write an explicit cast on malloc's
| return value.  I think that we are losing something, if only in
| readability, if we restrict our code to the subset of C which is also
| correct C++. 

I think opinions are variable here a lot.  If for example, you take a
look at examples in The C Programming Language (all editions), you'll
find explicit casts on malloc's return value.  Yet, I would refrain
from calling Dennis Ritchie as a non standard-C programmer or his
book, TCPL2, not describing standard C.  Most of the C programmers
I've met have learnt from his book.  (Yes, I've also read some C
programmers comment that nobody should cast the return value of
malloc, but for large scale sofwtare, I have not seen their opinions
as dorminating). 

The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
and such.  It is not anything you'll find in the code directly.  So,
in fact we do not lose readability as you claim.

| Now, if we were migrating to C++, that would be okay,
| because we would (eventually) get all of the additional expressive power
| of C++ in exchange.  However, if we're not migrating to C++, I'm opposed
| to the inclusion of patches that restrict our C code to the subset which
| is correct C++.

The patches are aligning us to our coding standards.  I don't think it
is reasonable to throw roadblocks in the way, especially when they are
contrary to our current coding standards.  The claim that the cast
will obscure the code is unjustified as the use of the libiberty
macros relieve us of springling cast in the code.  See my previous
patches to libiberty and fixincludes.
I don't think your suggestion of moving to C++ is workable at this
point.  The patches of aligning us to the common subsets of C90 and
C++ is following the consensus we developed as our coding standards.

|  Furthermore, as I've said before, I support migrating
| to C++ -- but only if the C++ ABI and libstdc++ soname are first
| permanently frozen.  If we do not do that first, we risk being trapped
| into a situation where we need specific versions of GCC to compile
| specific newer versions of GCC, which would be a Bad Thing.

Throwing roadblocks in the way is not going to help the GCC project.
It is unreasonable to that at this time.

| The C++ ABI seems to be stable at this point, but there is not yet
| consensus that it will never again be changed.  The libstdc++ team is
| currently developing yet another new, incompatible version, so I see no
| hope for a permanent freeze of its soname in the near future.  Thus,
| while you've discovered some interesting things by trying this, I don't
| think C++ compatibility patches should be applied now.

The issue of moving to C++ is independent of our aligning ourselves to
our coding standards.  I don't beleive it is reasonable to block these
patches on the ground that we could conceive moving to C++ (which is a
controversial issue).  The decision to code at the intersection of C90
and C++ is a consensus we reached after repeated debates.

| Having said that, some comments on the problems you have found:
| 
| > Third, there is some "type-punning" with enums, int and unsigned int,
| > where the middle-end (mostly) relies on implicit conversion from int
| > to enums.  
| 
| Being allowed to do this is very important.  Some enumerated types are
| to be treated as opaque outside a very narrow context; the only way to
| do that in C is to have (a typedef of) unsigned int as the visible type,
| and only declare the enumerated type in the context where it's allowed
| to be used. 

I have looked at every of those uses -- since I went through editing
almost every file needed for compiling GNU C and GNU C++ compilers.
None of the cases appear important.  The only compelling cases are
when front-ends (eg.g C or C++) extend them (e.g. c_tree_code or
cplus_tree_code).  However, none of the current approach is necessary.
As, RTH pointed out in the past, front-ends should define those
enumerators as a whole by appropriately #include the file.  We can
arrange for that -- in fact I've tested variants of that in my
experiments.   No cast is neeeded when done properly.

| I want to see more use of this idiom, not less; for
| example, 'enum machine_mode' ought to be a black box to almost the
| entire compiler. 

Me too, but the way to make it a black box is not to cast it so
unsigned int back forth willy nilly -- that does not make it a black
box, on the contrary.  For example, we should be using EXPAND_NORMAL
instead of plain "0".

| I'd be delighted to hear of a more C++-friendly way to
| code this. 

See above.

| Naturally, where the constant is _not_ opaque outside of a
| defined context, but is part of an interface (as your examples seemed to
| be), not using it is just sloppy.
| 
| > Fourth, it appears that we're implicilty using C99's semantics of 
| > "extern inline" in our source -- when we have a pure C90 compiler that
| > does not understand "inline", we just #define inline to nothing so we
| > don't get into trouble.  With a C++ compiler, we're in trouble because
| > an inline function needs to be defined in every translation where it
| > is used.  So, I either move the affected functions to "static inline"
| > or just make then non-inline (cases are in hashtable.c and toplev.c).
| 
| Use of bare 'inline' is just plain wrong in our source code; this has
| nothing to do with C++, no two C compilers implement bare 'inline'
| alike.  

Well, the way I figureed it out was running the code source through a
C++ compiler.  I'm aware that inline is absent from C90 and that many
of the current compilers that claim to implement C99 have their own
opinions on the matter.  However, what I was reporting is  an *actual*
experiment, no a thought.  And it popped up only because I ran the
source code through g++.  Which, I think I should mention.

| Patches to add 'static' to such functions (AND MAKING NO OTHER
| CHANGES) are preapproved, post-slush.
| 
| > Fifth, there is a slight difference between "const" in C and in C++.
| > In C++, a const variable implicitly has an internal linkage; so a
| > C++ compiler tends to optimize it out when its address is not taken
| > (so no storage is wasted).  This is an issue for the objects
| > automatically generated by the gengtype support machinery.  The are
| > supposed to have external linkage, so we need to explicitly say
| > "extern" in their definitions. 
| 
| Presumably such constants are declared in some header file, with
| external linkage.  It would be better to make that declaration visible
| at the point of definition, rather than marking up the declarations with
| 'extern'.

I'm talking of the various gt_* objects created by the gengtype.
Please, do have a look at the actual contents of the file and re-read
what I wrote. 

| > Sixth, there is a real "mess" about name spaces.  It is true that
| > every C programmers knows the rule saying tags inhabit different name
| > space than variable of functions.  However, all the C coding standards
| > I've read so far usually suggest 
| > 
| >    typedef struct foo foo;
| > 
| > but *not*
| > 
| >    typedef struct foo *foo;
| > 
| > i.e. "bringing" the tag-name into normal name space to name the type
| > structure or enumeration is OK, but not naming a different type!
| 
| Ugh.  Where do we do that?

In our source code. :-)  To name one that come to mind,

    alias.c:96:typedef struct alias_set_entry *alias_set_entry;

I've also found that we have hash_table from libcpp as a typedef-name
and hash_table as global (static variable) in cselib.c.

| I will suggest, when you find these, that
| you tack "_s" on the end of the tag-name; 

That is what I did in my local tree. But I believe we need to
standardize on a coherent coding standards.  Which is why I brought up
the issue.

| that doesn't conflict with
| POSIX, and should require fewer changes elsewhere in the code.

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Daniel Jacobowitz <drow@false.org> writes:

| On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
| > As a general observation: A lot of the things you have found to be
| > problematic, are in fact preferred idioms for C code.  For instance,
| > no standard-C programmer would ever write an explicit cast on malloc's
| > return value.  I think that we are losing something, if only in
| > readability, if we restrict our code to the subset of C which is also
| > correct C++.  Now, if we were migrating to C++, that would be okay,
| > because we would (eventually) get all of the additional expressive power
| > of C++ in exchange.  However, if we're not migrating to C++, I'm opposed
| > to the inclusion of patches that restrict our C code to the subset which
| > is correct C++.  Furthermore, as I've said before, I support migrating
| > to C++ -- but only if the C++ ABI and libstdc++ soname are first
| > permanently frozen.  If we do not do that first, we risk being trapped
| > into a situation where we need specific versions of GCC to compile
| > specific newer versions of GCC, which would be a Bad Thing.
| 
| You keep saying this and I don't think it means what you think it
| means...

Furthermore, I do not believe doing that (at least, as I understand it
is any resonable.  At any case, it is completely indpendent of the
patches that align us to our coding standards.

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
| > Use of bare 'inline' is just plain wrong in our source code; this has
| > nothing to do with C++, no two C compilers implement bare 'inline'
| > alike.  Patches to add 'static' to such functions (AND MAKING NO OTHER
| > CHANGES) are preapproved, post-slush.
| That will not work for the cases where the bare 'inline' are used
| because they are external also in this case.  Now this is where C99 and
| C++ differs at what a bare 'inline' means so I have no idea what to
| do, except for removing the 'inline' in first place.

It suffices to make the function "static inline".  See our current
extensive usage.  That works for both C and C++.

-- Gaby

Re: Compiling GCC with g++: a report

[Mark Mitchell]

Zack Weinberg wrote:
> On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
> 
>>Hi,
>>
>>  I spent the week-end trying to get GCC -- mainline -- compilable
>>(i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
> 
> 
> These results are very interesting.
> 
> As a general observation: A lot of the things you have found to be
> problematic, are in fact preferred idioms for C code.  For instance,
> no standard-C programmer would ever write an explicit cast on malloc's
> return value.

I don't know that I agree; I used to write such casts on other projects. 
    I learned C and C++ at the same time, and did a fair amount of work 
with formal type systems, though, so I may not be representative.

> is correct C++.  Furthermore, as I've said before, I support migrating
> to C++ -- but only if the C++ ABI and libstdc++ soname are first
> permanently frozen.  If we do not do that first, we risk being trapped
> into a situation where we need specific versions of GCC to compile
> specific newer versions of GCC, which would be a Bad Thing.

Line Daniel, I'm confused by this.  I think we would need to be sure of 
source compatibility with a reasonably large set of compilers, so I'd 
say that it would be bad to depend on (say) a fix for a bug with 
templates that was fixed in the last release.  But, it's doable to 
specify a super-conservative subset of C++ that works with anything that 
vaguely smells like a C++ compiler.  I'd certainly say that the common 
subset of C and C++ is such a subset.

> Being allowed to do this is very important.  Some enumerated types are
> to be treated as opaque outside a very narrow context; the only way to
> do that in C is to have (a typedef of) unsigned int as the visible type,
> and only declare the enumerated type in the context where it's allowed
> to be used.

I agree with the goal of more hiding.

You can do this in C by using an incomplete structure type in most 
places, and then, in the files where you want the definition visible, 
defining the structure to have a single field of the enumerated type. 
That is a little messy, but it is C++-compatible.  (In fact, in ISO C++, 
without the additions presently in the WP, you can't do better; forward 
declarations of enums are still not allowed.)

(The other thing you can do is to depend on the fact that enums and 
unsigned ints have the same representation, which you can force in C++ 
by declaring extra enumeration constants of values like UINT_MAX, and 
then use explicit casts at places where you want to go back and forth. 
I think this is not as nice as the incomplete structure approach.)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Compiling GCC with g++: a report

[Zack Weinberg]

Daniel Jacobowitz <drow@false.org> writes:

> On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
>> Furthermore, as I've said before, I support migrating
>> to C++ -- but only if the C++ ABI and libstdc++ soname are first
>> permanently frozen.  If we do not do that first, we risk being trapped
>> into a situation where we need specific versions of GCC to compile
>> specific newer versions of GCC, which would be a Bad Thing.
>
> You keep saying this and I don't think it means what you think it
> means...
>
> Being stuck requiring a specific version of GCC to compile a specific
> newer version of GCC would be a restriction on _source compatibility_
> and has nothing to do with binary compatibility.  I don't see any way
> that the libstdc++ soname, for instance, could matter to this at all.
>
> If you do, then please be more precise about what problems you're
> talking about.

Um, yeah.  I completely botched that explanation.  My apologies.  I'm
concerned about four different scenarios which may arise when the
preexisting C++ compiler and runtime are ABI-incompatible with the C++
compiler and runtime being built; none are source compatibility
issues, as you point out, however two of them have just the same
effect from the user's point of view: imposing constraints on what
compiler can be used to build the compiler.

Scenario one: Suppose that both libcpp and gcc start using <vector>,
and that the initial compiler/runtime's implementation of <vector> is
binary incompatible with the implementation being built.  Libcpp is
currently built only with the initial compiler.  Bootstrap will fail
in stage 2, when we try to link libcpp modules expecting the older
<vector> against a library implementing the newer <vector> (or perhaps
the link will succeed but the resulting executable won't work).  This
scenario, at least theoretically, becomes a non-issue if we make
top-level bootstrap the only option before we start using C++ features
in GCC, but that hasn't happened yet.

Scenario two: Suppose that we have not found every last place where
LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to
ensure that the dynamic linker binds the stage 2 compiler to the
shared libstdc++ that it's expecting.  If there isn't a libstdc++.so
in /usr/lib, or if there is but it is not compatible with the one the
compiler wants, again bootstrap will fail.  Any time this scenario
comes up, it is attributable to a bug in the Makefiles, but you know
just how hard it can be to fix such bugs.  We've had similar problems
with the shared libgcc.

Scenario three: Suppose that libstdc++.so.7 (gcc-4.2) and
libstdc++.so.7 (gcc-4.3) are compatible in the same way that libc.so.6
(glibc-2.0) and libc.so.6 (glibc-2.1) are compatible: that is, if you
build a binary against the first, it'll run against the second, but
not vice versa.  Now, suppose that on some system gcc-4.2 is
/usr/bin/gcc, its libstdc++.so.7 is installed in /usr/lib, and we're
trying to use it to compile gcc-4.3, to be installed in /opt/gcc-4.3
or some other weird place that is not in the dynamic linker's default
search path.  Furthermore, scenarios one and two have been properly
avoided.  The bootstrap process will produce final compiler binaries
that have been linked against the 4.3 libstdc++.so.  If we include
RPATHs in those binaries, bootstrap will fail, because the library
isn't installed yet; if we don't, bootstrap and testing will succeed,
but the installed compiler will not run unless the user knows to set
LD_LIBRARY_PATH, which has its own problems.  DT_RUNPATH could
theoretically be used to make this work, but we can't count on
DT_RUNPATH.

If I were evil, I might point out that this is exactly the same
problem that various people were complaining about last week, of
depending on newer libraries than one expected to.

Scenario four: Suppose that we manage to avoid all the above
scenarios.  Suppose further that we think we have achieved binary
compatibility between different versions of libstdc++, but we are
wrong.  Then 'make install' is likely to overwrite the libstdc++.so on
the system with one that is, in fact, not compatible, and break
already-installed software.  This could, of course, happen even if we
don't start using C++ in GCC itself - I bring it up to caution us
against rushing into declaring libstdc++ ABI-frozen.  I'd want to see
at least two major releases with no libstdc++ soname bump and no
problems reported, before I had confidence we'd gotten it right.

I want to emphasize that I don't think any of these are unsolvable
problems.  I do think they are all real problems, and I think there
are going to be other problems I haven't listed above, and I want to
be sure we have considered the problems and have solutions in hand
before we take the plunge.

> There is no such thing as an ABI that will never again be changed.
> Designing anything at all around that assumption is just asking to
> be hurt.

C++ ABI stability (including libstdc++ interface) on a par with the C
ABI (including libc interface) would suffice.

zw

Re: Compiling GCC with g++: a report

[Mark Mitchell]

Zack Weinberg wrote:

> Um, yeah.  I completely botched that explanation.  My apologies.  I'm
> concerned about four different scenarios which may arise when the
> preexisting C++ compiler and runtime are ABI-incompatible with the C++
> compiler and runtime being built; none are source compatibility
> issues, as you point out, however two of them have just the same
> effect from the user's point of view: imposing constraints on what
> compiler can be used to build the compiler.

I agree that these are valid concerns.

Certainly, I can imagine us (CodeSourcery) considering shipping 
statically linked binaries for quite some time in order to avoid 
problems for customers, even though that would be less efficient.

Like you, I do think these problems are surmountable; but, also like 
you, I think it would take some time to get all the problems solved.  I 
don't really think, though, that this is immediately relevant; Gaby's 
trying to fix things that seem to me like they will actually make for 
better C code, and, right now at least, going to C++ isn't on the table. 
  I think you agree that most of the changes Gaby wants to make are for 
the better (with the possible exception of casting the return value of 
malloc, which will be hidden in a macro that's probably less error-prone 
that writing out the malloc calls directly) -- but you're concerned 
about the fact that doing this work now might make it too easy for us to 
switch to C++ without thinking about all the issues?

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Compiling GCC with g++: a report

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

[...]
> The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
> and such.  It is not anything you'll find in the code directly.  So,
> in fact we do not lose readability as you claim.

To be honest, I think XNEW* are less readable than bare xmalloc, and I
regret that I ever invented them.

> The patches of aligning us to the common subsets of C90 and C++ is
> following the consensus we developed as our coding standards.

I don't see that there is any such consensus.  I certainly consider
coding to the intersection of C90 and C++ acceptable only as a
stepping stone to coding in C++.  If we aren't going to do that, and
in short order, we have sacrificed the additional expressiveness of
C-that-is-not-C++ for no gain.

I was unclear in my previous message: it seems that you have found a
number of things, by your experiment, that are not just code outside
the intersection, but outright bugs.  The bugs should of course be
fixed.  Things that I consider outright bugs include: functions being
called with prototypes in scope that don't match their definitions;
use of numeric constants in interfaces when enumeration constants are
defined for those interfaces; 'typedef struct foo *foo'.

Things I consider correct coding, but outside the intersection of C90
and C++, include: not casting the return value of allocator functions;
not casting to void* when passing an arbitrary pointer to a function
that takes a void* parameter; unrestricted use of C++ keywords;
declaring structure fields with the same name as a structure tag in
scope.

> | I want to see more use of this idiom, not less; for
> | example, 'enum machine_mode' ought to be a black box to almost the
> | entire compiler. 
>
> Me too, but the way to make it a black box is not to cast it so
> unsigned int back forth willy nilly -- that does not make it a black
> box, on the contrary.  For example, we should be using EXPAND_NORMAL
> instead of plain "0".
>
> | I'd be delighted to hear of a more C++-friendly way to
> | code this. 
>
> See above.

This isn't an answer to the question I asked.  I asked for a more C++
friendly way to code *black box* use of enums, where (in C) one is
deliberately relying on the unchecked conversion to and from integral
types.

> I'm talking of the various gt_* objects created by the gengtype.
> Please, do have a look at the actual contents of the file and
> re-read what I wrote.

I haven't time; please post a reduced example and explain why my
suggestion won't work.

zw

Re: Compiling GCC with g++: a report

[Zack Weinberg]

Mark Mitchell <mark@codesourcery.com> writes:

[snip stuff addressed elsewhere]
> I agree with the goal of more hiding.
>
> You can do this in C by using an incomplete structure type in most
> places, and then, in the files where you want the definition visible,
> defining the structure to have a single field of the enumerated
> type. That is a little messy, but it is C++-compatible.  (In fact, in
> ISO C++, without the additions presently in the WP, you can't do
> better; forward declarations of enums are still not allowed.)

Doesn't work, at least not as a drop-in replacement; you can't pass an
incomplete structure by value.  We do do this in places where there's
a real structure that can be passed around by pointer...

zw

Re: Compiling GCC with g++: a report

[Mark Mitchell]

Zack Weinberg wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> [snip stuff addressed elsewhere]
> 
>>I agree with the goal of more hiding.
>>
>>You can do this in C by using an incomplete structure type in most
>>places, and then, in the files where you want the definition visible,
>>defining the structure to have a single field of the enumerated
>>type. That is a little messy, but it is C++-compatible.  (In fact, in
>>ISO C++, without the additions presently in the WP, you can't do
>>better; forward declarations of enums are still not allowed.)
> 
> 
> Doesn't work, at least not as a drop-in replacement; you can't pass an
> incomplete structure by value.  We do do this in places where there's
> a real structure that can be passed around by pointer...

Good point; yes, you would have to pass a pointer.  I guess you could 
create a singleton representative of each value in the enum, and pass 
them around, but I agree that's getting pretty ugly.  Of course, the 
problem with "unsigned int" is that it is a complete type, and people 
can accidentally pass in "7", even if there's no such enumeral.  You 
really want forward-declared enums, but you haven't got them; it may be 
you just lose. :-(

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Compiling GCC with g++: a report

[Mark Mitchell]

Zack Weinberg wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> 
> [...]
> 
>>The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
>>and such.  It is not anything you'll find in the code directly.  So,
>>in fact we do not lose readability as you claim.
> 
> 
> To be honest, I think XNEW* are less readable than bare xmalloc, and I
> regret that I ever invented them.

Too late. :-)

We have adopted them, and people have started using them.  Unlike you, I 
still think they're a good thing.  More importantly, I think it would be 
a mistake to reopen this issue; I don't think the difference is terribly 
important, but not having the debate seems like a win. :-)

> Things I consider correct coding, but outside the intersection of C90
> and C++, include: not casting the return value of allocator functions;

See above.

> not casting to void* when passing an arbitrary pointer to a function
> that takes a void* parameter

That's not necessary in C++ either; the C++ difference is that you must 
cast "void *" to "int *" to call a function accepting an "int *"; not 
the opposite.  Maybe that's what you meant?

> unrestricted use of C++ keywords;
 >
> declaring structure fields with the same name as a structure tag in
> scope.

I don't think we should be reverting patches that fall afoul of these 
last two, even if they break Gaby's build-with-a-C++-compiler builds. 
But, I would tend to accept patches from Gaby to fix such problems.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Compiling GCC with g++: a report

[Zack Weinberg]

Mark Mitchell <mark@codesourcery.com> writes:
...
> Like you, I do think these problems are surmountable; but, also like
> you, I think it would take some time to get all the problems solved.
> I don't really think, though, that this is immediately relevant;
> Gaby's trying to fix things that seem to me like they will actually
> make for better C code, and, right now at least, going to C++ isn't on
> the table. I think you agree that most of the changes Gaby wants to
> make are for the better (with the possible exception of casting the
> return value of malloc, which will be hidden in a macro that's
> probably less error-prone that writing out the malloc calls directly)
> -- but you're concerned about the fact that doing this work now might
> make it too easy for us to switch to C++ without thinking about all
> the issues?

Yes, that's what I'm trying to get at.  Secondarily, I don't want to
lose some of the expressive power of C-that-is-not-C++ if we're not
getting the expressive power of C++ in exchange -- for instance, I
really don't want to have to avoid the set of C++ keywords when coding
in C, or remember the semantic difference between C and C++ struct tags.

I'd change my tune if Gaby could demonstrate a place where the C++
compiler caught a user-visible bug that the C compiler missed.  That
would be worth the extra discipline.  All the bugs described so far,
however, have been things that, while formally incorrect, haven't
affected the visible behavior of the compiler.

(And I'd be less grumpy about coding to the intersection of C and C++
if someone coded up warnings for the C compiler to catch things
outside the intersection.)

zw

Re: Compiling GCC with g++: a report

[Mark Mitchell]

Zack Weinberg wrote:

> (And I'd be less grumpy about coding to the intersection of C and C++
> if someone coded up warnings for the C compiler to catch things
> outside the intersection.)

My feeling on this is that it's not fair to expect people to know C++, 
until and unless we switch to actually using C++.  I'd say just code how 
you always have, within our existing coding standards, and ignore the 
issue; let people who care fix it up after the fact, or comment on your 
patches when you post them.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| [...]
| > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
| > and such.  It is not anything you'll find in the code directly.  So,
| > in fact we do not lose readability as you claim.
| 
| To be honest, I think XNEW* are less readable than bare xmalloc, and I
| regret that I ever invented them.

Then, we would have just agree to disagree.  At least, with the
explicit call to malloc + explicit specification of sizeof, I've found
a number of wrong codes -- while replacing the existing xmalloc/xcallo
with XNEWVEC and friends (see previous patches and messages) in
libiberty, not counting  the happy confusion about xcalloc() in the
current GCC codes.  Those are bugs we do not have with the XNEWVEC and
friends.  Not only, we do get readable code, we also get right codes.

| > The patches of aligning us to the common subsets of C90 and C++ is
| > following the consensus we developed as our coding standards.
| 
| I don't see that there is any such consensus.  I certainly consider

   http://www.gnu.org/software/gcc/codingconventions.html

    Avoid the use of identifiers or idioms that would prevent code
    compiling with a C++ compiler. Identifiers such as new or class,
    that are reserved words in C++, should not be used as variables or
    field names. Explicit casts should be used to convert between
    void* and other pointer types.

Previous discussions reached this:

    http://gcc.gnu.org/ml/gcc/2004-07/msg00601.html


| coding to the intersection of C90 and C++ acceptable only as a
| stepping stone to coding in C++.

If converting GCC to C++ is your ultimate goal, then I don't think
you should block these patches.  They do not introduce C++, but also
they do provide a path to local experiments before we ever have any
huge fight about that.  I do not think converting GCC to C++ is on the
table or will happen any time soon -- see previous long discussions.
However, I do not believe it would help the GCC project to block any
patch that bring us in alignment to our own committment.  We can have
our cake and it.  I.e. we can have the source code in a form
compilable with a C++ compiler and test conjectures/experiments.

|  If we aren't going to do that, and
| in short order, we have sacrificed the additional expressiveness of
| C-that-is-not-C++ for no gain.

I don't think so.  These patches make it possible to compile the
source code with a C++ compiler.  We gain better checking by doing
that.  In particular, it makes it possible for people to test any
conjecture about the benefits of moving to C++, without actually
requiring it at the moment.  Those benefits largely offset the
inconvenient of using XNEWVEC (with all its benefits).  I was able to
find those problems because I could get the source code through a C++
compiler.  Making that possible to everyone, including those who do no
like to use C++ in GCC is a win for everybody.

| I was unclear in my previous message: it seems that you have found a
| number of things, by your experiment, that are not just code outside
| the intersection, but outright bugs.

Exactly.  I was able to find those because I spent the time to convert
the souorce to be compilable to C++.  I do not believe it makes to
require everybody to wste such time locally, whereas it could be done
one for all.

|  The bugs should of course be
| fixed.  Things that I consider outright bugs include: functions being
| called with prototypes in scope that don't match their definitions;
| use of numeric constants in interfaces when enumeration constants are
| defined for those interfaces; 'typedef struct foo *foo'.
| 
| Things I consider correct coding, but outside the intersection of C90
| and C++, include: not casting the return value of allocator functions;
| not casting to void* when passing an arbitrary pointer to a function
| that takes a void* parameter; unrestricted use of C++ keywords;
| declaring structure fields with the same name as a structure tag in
| scope.

These do not being us any benefits as far as checking is concerned.
The point of being able to do so and therefore prevent ourselves from
having freely avaliable tools to catch errors completely escape my
understanding. 

| > | I want to see more use of this idiom, not less; for
| > | example, 'enum machine_mode' ought to be a black box to almost the
| > | entire compiler. 
| >
| > Me too, but the way to make it a black box is not to cast it so
| > unsigned int back forth willy nilly -- that does not make it a black
| > box, on the contrary.  For example, we should be using EXPAND_NORMAL
| > instead of plain "0".
| >
| > | I'd be delighted to hear of a more C++-friendly way to
| > | code this. 
| >
| > See above.
| 
| This isn't an answer to the question I asked.  I asked for a more C++
| friendly way to code *black box* use of enums, where (in C) one is
| deliberately relying on the unchecked conversion to and from integral
| types.

The point was that an enum by itself is a black box.  There is no
foward declaration of enums.  There is no need here for an abstraction
for an abstraction. The named constants stand by themselves
are abstraction layer over the values they represent.

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Mark Mitchell <mark@codesourcery.com> writes:
| ...
| > Like you, I do think these problems are surmountable; but, also like
| > you, I think it would take some time to get all the problems solved.
| > I don't really think, though, that this is immediately relevant;
| > Gaby's trying to fix things that seem to me like they will actually
| > make for better C code, and, right now at least, going to C++ isn't on
| > the table. I think you agree that most of the changes Gaby wants to
| > make are for the better (with the possible exception of casting the
| > return value of malloc, which will be hidden in a macro that's
| > probably less error-prone that writing out the malloc calls directly)
| > -- but you're concerned about the fact that doing this work now might
| > make it too easy for us to switch to C++ without thinking about all
| > the issues?
| 
| Yes, that's what I'm trying to get at.  Secondarily, I don't want to
| lose some of the expressive power of C-that-is-not-C++ if we're not
| getting the expressive power of C++ in exchange -- for instance, I
| really don't want to have to avoid the set of C++ keywords when coding
| in C, or remember the semantic difference between C and C++ struct tags.

But we do not get any expressive power by using C++ keywords.  
Using C++ keywords just make it impossible to have better checking
provided by C++ compilers.  That is no gain.  It is a lost.
Furthermore, if you ever move to C++ as you wanted to do, you will
have to abondon those keywords anyway, so it does not represent any
essential to expressive power.  I find the insistance of using C++
keywords (while wishing for moving to C++) very inconsistent, if not
contrary to our coding conventions. 

| I'd change my tune if Gaby could demonstrate a place where the C++
| compiler caught a user-visible bug that the C compiler missed.  That
| would be worth the extra discipline.  All the bugs described so far,
| however, have been things that, while formally incorrect, haven't
| affected the visible behavior of the compiler.

That is an extreme statement.  First, I just complete the project this
afternoon.  Furthermore, the fact that a function was called with with
one argument, but its definition was poking at a second argument is a
bug whose effect is hard to trace down correcly.  But that was just
the first one I came across.  Furthermore, the benefits are not just
what bugs we can catch right now, but how we make it possible to build
free software based on GCC, and encourage more contributions.  I know
of a number of projects that are done with proprietary compilers, that
could have been done with GCC (and people are ready to move to GCC, I
know at a number of Codesourcery customers ;-)) if it were possible to
have GCC compilable with a C++ compiler.  Frankly, there does not seem
to be any benefit to obsctructing these patches that would align us
with our own coding conventions.

| (And I'd be less grumpy about coding to the intersection of C and C++
| if someone coded up warnings for the C compiler to catch things
| outside the intersection.)

Consider that to be a follow-up that I'm willing to do, if these
preliminary patches are in.  For sure, I do want to make sure that we
do not break things too easily.

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| > unrestricted use of C++ keywords;
|  >
| > declaring structure fields with the same name as a structure tag in
| > scope.
| 
| I don't think we should be reverting patches that fall afoul of these
| last two, even if they break Gaby's build-with-a-C++-compiler
| builds. But, I would tend to accept patches from Gaby to fix such
| problems.

I guess we had a preliminary discussion about this a while ago.  I
volunteered to maintain this compatibility issue.  At a first stage,
once the patches are in, I would like to adapt Geoff's regression
scirpt to run the build with a C++ compiler.  Next, I'm willing to
follow-up with patches that implement warnings about C/C++
compatibility but that would be a much more extensive project, so I
don't think it would be fair to require it for 4.1 or hold patches on
that.  They are improvements we can get by increments.

-- Gaby

Re: Compiling GCC with g++: a report

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument.  Also,
rearranging paragraphs a bit so as not to have to repeat myself]

> with the explicit call to malloc + explicit specification of sizeof,
> I've found a number of wrong codes -- while replacing the existing
> xmalloc/xcallo with XNEWVEC and friends (see previous patches and
> messages) in libiberty, not counting the happy confusion about
> xcalloc() in the current GCC codes.  Those are bugs we do not have
> with the XNEWVEC and friends.  Not only, we do get readable code, we
> also get right codes.
...
> I don't think so.  These patches make it possible to compile the
> source code with a C++ compiler.  We gain better checking by doing
> that. 

Have you found any places where the bugs you found could have resulted
in user-visible incorrect behavior (of any kind)?

If you have, I will drop all of my objections.

> If converting GCC to C++ is your ultimate goal, then I don't think
> you should block these patches.  They do not introduce C++, but also
> they do provide a path to local experiments before we ever have any
> huge fight about that.

To be clear, my ultimate goal is neither to introduce C++ nor to block
it.  My goal is to make sure that *if* a transition to C++ happens, it
happens with great care and attention to detail.  Part of this is not
doing anything that makes it seem easier to convert to C++ than it
actually is.  See my earlier response to Mark.

Now, if there's a benefit to your patches other than making that
hypothetical transition easier - like finding actual user-visible bugs -
then I don't have a problem with them.

> | This isn't an answer to the question I asked.  I asked for a more C++
> | friendly way to code *black box* use of enums, where (in C) one is
> | deliberately relying on the unchecked conversion to and from integral
> | types.
>
> The point was that an enum by itself is a black box.  There is no
> foward declaration of enums.  There is no need here for an abstraction
> for an abstraction.

So you don't see any value whatsoever to having (for instance) the
individual constants of 'enum machine_mode' be inaccessible in most of
GCC?  'cos I sure do.

zw

Re: Compiling GCC with g++: a report

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> But we do not get any expressive power by using C++ keywords.  

Readability, readability, readability.

(for instance, 'class' vs. 'klass' - I can read decimal orders of
magnitude faster if all the English words in what I'm reading are
correctly spelled)

> That is an extreme statement.

*shrug* That's what would make it worthwhile to me.

> Furthermore, the benefits are not just what bugs we can catch right
> now, but how we make it possible to build free software based on
> GCC, and encourage more contributions.

The YAGNI principle applies, in my opinion.

> | (And I'd be less grumpy about coding to the intersection of C and
> | C++ if someone coded up warnings for the C compiler to catch
> | things outside the intersection.)
>
> Consider that to be a follow-up that I'm willing to do, if these
> preliminary patches are in.

Thank you, I appreciate that.

zw

Re: Compiling GCC with g++: a report

[Florian Weimer]

* Gabriel Dos Reis:

> The first resistance seems to come from the pervasive use of the implicit
> conversion void* -> T*, mostly with storage allocating functions.

This can be worked around on the C++ side, see the example code below.
It's a kludge, but it's not too bad IMHO.

class xmalloc_result;
xmalloc_result xmalloc (size_t);

class xmalloc_result
{
  friend xmalloc_result xmalloc (size_t);
  const size_t size_;

  xmalloc_result (size_t size)
    : size_ (size)
  {
  }

  xmalloc_result operator= (const xmalloc_result&);
  // not implemented

public:
  template <typename T> operator T* () const
  {
    return static_cast<T*> (malloc(size_));
  }
};

inline xmalloc_result
xmalloc (size_t size)
{
  return xmalloc_result (size);
}

char *
foo (void)
{
  return xmalloc (1);
}

void
bar (int **result)
{
  *result = xmalloc (sizeof (int));
}

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| [dropping most of the message - if I haven't responded, assume I don't
| agree but I also don't care enough to continue the argument.  Also,
| rearranging paragraphs a bit so as not to have to repeat myself]
| 
| > with the explicit call to malloc + explicit specification of sizeof,
| > I've found a number of wrong codes -- while replacing the existing
| > xmalloc/xcallo with XNEWVEC and friends (see previous patches and
| > messages) in libiberty, not counting the happy confusion about
| > xcalloc() in the current GCC codes.  Those are bugs we do not have
| > with the XNEWVEC and friends.  Not only, we do get readable code, we
| > also get right codes.
| ...
| > I don't think so.  These patches make it possible to compile the
| > source code with a C++ compiler.  We gain better checking by doing
| > that. 
| 
| Have you found any places where the bugs you found could have resulted
| in user-visible incorrect behavior (of any kind)?

As I said, I ran a preliminary experiment to estimate how difficult
the task would be to have the existing source respect our own coding
conventions:

  http://www.gnu.org/software/gcc/codingconventions.html

   Avoid the use of identifiers or idioms that would prevent code
   compiling with a C++ compiler. Identifiers such as new or class,
   that are reserved words in C++, should not be used as variables or
   field names. Explicit casts should be used to convert between void*
   and other pointer types.


The mere fact of doing that and catch the errors I mentioned earlier,
was quite positive.  Of course, I do not doubt that we would find more
bugs (and if we do not find any, then we do get another level of
confidence in the code), but this is something that happens quicker
and go through extensive coverage when it is possible for more people
to do.  I do believe that the fact that the compiler is relying on
a second inexisting argument to do name lookup is a user visible bug
(not mentioning stack corruption), but we do get better and existing
checking by making the change avaialble to a wider number of people.

The benefits are not just the immediate bugs I find.

| If you have, I will drop all of my objections.
| 
| > If converting GCC to C++ is your ultimate goal, then I don't think
| > you should block these patches.  They do not introduce C++, but also
| > they do provide a path to local experiments before we ever have any
| > huge fight about that.
| 
| To be clear, my ultimate goal is neither to introduce C++ nor to block
| it.  My goal is to make sure that *if* a transition to C++ happens, it
| happens with great care and attention to detail.  Part of this is not
| doing anything that makes it seem easier to convert to C++ than it
| actually is.  See my earlier response to Mark.

I understand that, but none of the patches is in line of unthinking,
that makes any hypothetical move to C++ (nor non-move move-to)
difficult.

  (1) if we move to C++, we have to avoid the keywords (which are
      already prohibited by our current coding conventions)
  (2) if we move to C++, we have to avoid the implicit convertion
       void* -> T* (which is already prohibited by our coding
       conventions) 
  (3) if we don't move to C++, we still follow our coding conventions.

  (4) if we don't move to C++, we still can use additional testing
      provided by a C++ compiler.

| > | This isn't an answer to the question I asked.  I asked for a more C++
| > | friendly way to code *black box* use of enums, where (in C) one is
| > | deliberately relying on the unchecked conversion to and from integral
| > | types.
| >
| > The point was that an enum by itself is a black box.  There is no
| > foward declaration of enums.  There is no need here for an abstraction
| > for an abstraction.
| 
| So you don't see any value whatsoever to having (for instance) the
| individual constants of 'enum machine_mode' be inaccessible in most of
| GCC?  'cos I sure do.


What I'm saying is that when you have a name like EXPAND_NORMAL, you
do not need to know the value it represents.  Just that it names a
constant.  If you want to introduce a new name for that name, people
would still have to use that name, therefore the question is exactly
what  do you gain in this specific case by introducing a second name
(which does not hide more than the first name) over the existing
practice where people use numerical values, that you do not gai by
introducing just a single layer (enumeration)?

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > But we do not get any expressive power by using C++ keywords.  
| 
| Readability, readability, readability.
| 
| (for instance, 'class' vs. 'klass'

When replacing "class" with a new identifier, "klass" it not the only
choice.  Therefore, it does not appear that you have exhibited any
loss of readability.  You have just suggested a worst choise, but it
is not the only one we have.

[...]

| > | (And I'd be less grumpy about coding to the intersection of C and
| > | C++ if someone coded up warnings for the C compiler to catch
| > | things outside the intersection.)
| >
| > Consider that to be a follow-up that I'm willing to do, if these
| > preliminary patches are in.
| 
| Thank you, I appreciate that.

So, were do we stand?  

Notice again that none of the changes are outside our existing coding
conventions. 

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Florian Weimer <fw@deneb.enyo.de> writes:

| * Gabriel Dos Reis:
| 
| > The first resistance seems to come from the pervasive use of the implicit
| > conversion void* -> T*, mostly with storage allocating functions.
| 
| This can be worked around on the C++ side, see the example code below.
| It's a kludge, but it's not too bad IMHO.


Yes.  However, if we were to use C++ in the source code, I know of a
few numbers of ways to make the exsting code far better :-)  
However, the idea is to have the *C* source code through a C++
compiler -- for a number of reasons, for starter using C++ in 
GCC is not on the table.

(And the implicit conversion is still unable to catch the various
wrong codes I repported earlier and the confusion about xcalloc).

-- Gaby

Re: Compiling GCC with g++: a report

[Kai Henningsen]

mark@codesourcery.com (Mark Mitchell)  wrote on 23.05.05 in <4292C8C9.9040400@codesourcery.com>:

> Zack Weinberg wrote:
> > Mark Mitchell <mark@codesourcery.com> writes:
> >
> > [snip stuff addressed elsewhere]
> >
> >>I agree with the goal of more hiding.
> >>
> >>You can do this in C by using an incomplete structure type in most
> >>places, and then, in the files where you want the definition visible,
> >>defining the structure to have a single field of the enumerated
> >>type. That is a little messy, but it is C++-compatible.  (In fact, in
> >>ISO C++, without the additions presently in the WP, you can't do
> >>better; forward declarations of enums are still not allowed.)
> >
> >
> > Doesn't work, at least not as a drop-in replacement; you can't pass an
> > incomplete structure by value.  We do do this in places where there's
> > a real structure that can be passed around by pointer...
>
> Good point; yes, you would have to pass a pointer.  I guess you could
> create a singleton representative of each value in the enum, and pass
> them around, but I agree that's getting pretty ugly.  Of course, the
> problem with "unsigned int" is that it is a complete type, and people
> can accidentally pass in "7", even if there's no such enumeral.  You
> really want forward-declared enums, but you haven't got them; it may be
> you just lose. :-(

What I've done, in a similar situation, was to declare a complete  
structure encapsulating the value - this at least makes sure you need to  
acknowledge the structure whenever you access the value. Plus, I've added  
inline functions for accessing the value, so those places don't need to  
know the structure details either.

This makes it fairly type safe, and you can grep for all kinds of uses  
(including people who naughtily access the structure contents directly).

MfG Kai

Re: Compiling GCC with g++: a report

[Paolo Bonzini]

 > This scenario, at least theoretically, becomes a non-issue if we make
> top-level bootstrap the only option before we start using C++ features
> in GCC, but that hasn't happened yet.

It will happen soon after the end of the slush.  The last preliminary 
patch has already been posted, then all one has to do is to flip the 
default.

In the meanwhile, the CFT is open since last September :-)  Last time I 
ran a toplevel bootstrap was a couple of weeks ago.

Paolo

Re: Compiling GCC with g++: a report

[Daniel Jacobowitz]

[Rearranging]

> I want to emphasize that I don't think any of these are unsolvable
> problems.  I do think they are all real problems, and I think there
> are going to be other problems I haven't listed above, and I want to
> be sure we have considered the problems and have solutions in hand
> before we take the plunge.

On the other hand, I've spent time thinking about all of these already.
For instance, let me point one thing out that you mention a couple of
times but don't give enough attention to:

> just how hard it can be to fix such bugs.  We've had similar problems
> with the shared libgcc.

We've fixed a lot of these problems already; I will be brave and say
that we have fixed most of them.

On Mon, May 23, 2005 at 11:04:14PM -0700, Zack Weinberg wrote:
> Scenario one: Suppose that both libcpp and gcc start using <vector>,
> and that the initial compiler/runtime's implementation of <vector> is
> binary incompatible with the implementation being built.  Libcpp is
> currently built only with the initial compiler.  Bootstrap will fail
> in stage 2, when we try to link libcpp modules expecting the older
> <vector> against a library implementing the newer <vector> (or perhaps
> the link will succeed but the resulting executable won't work).  This
> scenario, at least theoretically, becomes a non-issue if we make
> top-level bootstrap the only option before we start using C++ features
> in GCC, but that hasn't happened yet.

As Paolo wrote, it will soon.  This isn't the only thing it'll fix. 
For instance it would let us use bool in those interfaces again,
without breaking Darwin.

> Scenario two: Suppose that we have not found every last place where
> LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to
> ensure that the dynamic linker binds the stage 2 compiler to the
> shared libstdc++ that it's expecting.  If there isn't a libstdc++.so
> in /usr/lib, or if there is but it is not compatible with the one the
> compiler wants, again bootstrap will fail.  Any time this scenario
> comes up, it is attributable to a bug in the Makefiles, but you know
> just how hard it can be to fix such bugs.  We've had similar problems
> with the shared libgcc.

With top level bootstrap this is trivial to get right.  The top level
should set the library path appropriately for the stage.

> Scenario three: Suppose that libstdc++.so.7 (gcc-4.2) and
> libstdc++.so.7 (gcc-4.3) are compatible in the same way that libc.so.6
> (glibc-2.0) and libc.so.6 (glibc-2.1) are compatible: that is, if you
> build a binary against the first, it'll run against the second, but
> not vice versa.  Now, suppose that on some system gcc-4.2 is
> /usr/bin/gcc, its libstdc++.so.7 is installed in /usr/lib, and we're
> trying to use it to compile gcc-4.3, to be installed in /opt/gcc-4.3
> or some other weird place that is not in the dynamic linker's default
> search path.  Furthermore, scenarios one and two have been properly
> avoided.  The bootstrap process will produce final compiler binaries
> that have been linked against the 4.3 libstdc++.so.  If we include
> RPATHs in those binaries, bootstrap will fail, because the library
> isn't installed yet; if we don't, bootstrap and testing will succeed,
> but the installed compiler will not run unless the user knows to set
> LD_LIBRARY_PATH, which has its own problems.  DT_RUNPATH could
> theoretically be used to make this work, but we can't count on
> DT_RUNPATH.

You do realize that libgcc is "compatible" in the same way as glibc,
right?  If you do this and don't copy the hypothetical gcc 4.3
libgcc_s.so.1 into your system library directory, C++ stands a decent
chance of not working.  Not a new problem.

I don't know why you think that the DT_RPATH would cause the build to
fail.  A DT_RPATH pointing at a non-existant directory is harmless and
LD_LIBRARY_PATH will still be used.  It's only if you had an old copy
in $prefix that DT_RPATH would bite you.  And there are plenty of other
ways around this - for instance, a shell script named xgcc in the build
tree which LD_PRELOADs the correct copy using a full path.

> Scenario four: Suppose that we manage to avoid all the above
> scenarios.  Suppose further that we think we have achieved binary
> compatibility between different versions of libstdc++, but we are
> wrong.  Then 'make install' is likely to overwrite the libstdc++.so on
> the system with one that is, in fact, not compatible, and break
> already-installed software.  This could, of course, happen even if we
> don't start using C++ in GCC itself - I bring it up to caution us
> against rushing into declaring libstdc++ ABI-frozen.  I'd want to see
> at least two major releases with no libstdc++ soname bump and no
> problems reported, before I had confidence we'd gotten it right.

You mean, like GCC 3.4 and GCC 4.0?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Compiling GCC with g++: a report

[Paul Koning]

>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

 Gabriel> http://www.gnu.org/software/gcc/codingconventions.html

 Gabriel> Avoid the use of identifiers or idioms that would prevent
 Gabriel> code compiling with a C++ compiler. Identifiers such as new
 Gabriel> or class, that are reserved words in C++, should not be used
 Gabriel> as variables or field names. Explicit casts should be used
 Gabriel> to convert between void* and other pointer types.

I hope that doesn't require (void *) casts for pointer arguments
passed to the likes of memcpy...

 Gabriel> If converting GCC to C++ is your ultimate goal, then I don't
 Gabriel> think you should block these patches.  They do not introduce
 Gabriel> C++, but also they do provide a path to local experiments
 Gabriel> before we ever have any huge fight about that.  I do not
 Gabriel> think converting GCC to C++ is on the table or will happen
 Gabriel> any time soon -- see previous long discussions.  However, I
 Gabriel> do not believe it would help the GCC project to block any
 Gabriel> patch that bring us in alignment to our own committment.  We
 Gabriel> can have our cake and it.  I.e. we can have the source code
 Gabriel> in a form compilable with a C++ compiler and test
 Gabriel> conjectures/experiments.

I think that's a good argument.

I also find the argument of better type checking persuasive, whether
or not it has yet caught a user-visible bug.

    paul

Re: Compiling GCC with g++: a report

[Andreas Schwab]

Paul Koning <pkoning@equallogic.com> writes:

>>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
>  Gabriel> http://www.gnu.org/software/gcc/codingconventions.html
>
>  Gabriel> Avoid the use of identifiers or idioms that would prevent
>  Gabriel> code compiling with a C++ compiler. Identifiers such as new
>  Gabriel> or class, that are reserved words in C++, should not be used
>  Gabriel> as variables or field names. Explicit casts should be used
>  Gabriel> to convert between void* and other pointer types.
>
> I hope that doesn't require (void *) casts for pointer arguments
> passed to the likes of memcpy...

Only the (void*) -> (any*) direction requires a cast in C++, the other
direction is still converted implicitly.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Paul Koning <pkoning@equallogic.com> writes:

| >>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
|  Gabriel> http://www.gnu.org/software/gcc/codingconventions.html
| 
|  Gabriel> Avoid the use of identifiers or idioms that would prevent
|  Gabriel> code compiling with a C++ compiler. Identifiers such as new
|  Gabriel> or class, that are reserved words in C++, should not be used
|  Gabriel> as variables or field names. Explicit casts should be used
|  Gabriel> to convert between void* and other pointer types.
| 
| I hope that doesn't require (void *) casts for pointer arguments
| passed to the likes of memcpy...

It doesn't.  The implicit conversion T* -> void* is OK.

(I think that if written properly, we will barely have to see casts
explicit in the codes.)

-- Gaby

Re: Compiling GCC with g++: a report

[Diego Novillo]

On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:

> So, if various components maintainers (e.g. C and C++, middle-end,
> ports, etc.)  are willing to help quickly reviewing patches we can
> have this done for this week (assuming mainline is unslushed soon).
> And, of course, everybody can help :-)
> 
If the final goal is to allow GCC components to be implemented in
C++, then I am all in favour of this project.  I'm pretty sick of
all this monkeying around we do with macros to make up for the
lack of abstraction.


Diego.

Re: Compiling GCC with g++: a report

[Richard Guenther]

On 5/24/05, Diego Novillo <dnovillo@redhat.com> wrote:
> On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
> 
> > So, if various components maintainers (e.g. C and C++, middle-end,
> > ports, etc.)  are willing to help quickly reviewing patches we can
> > have this done for this week (assuming mainline is unslushed soon).
> > And, of course, everybody can help :-)
> >
> If the final goal is to allow GCC components to be implemented in
> C++, then I am all in favour of this project.  I'm pretty sick of
> all this monkeying around we do with macros to make up for the
> lack of abstraction.

It's also a good test to see how/whether the different trees the C++ frontend
presents to the middle-end impact our ability to optimize gcc itself.  There
are quite some subtle differences out there asking to be "fixed", regardless
if we go to adopt C++ for writing gcc or not.

Richard.

Re: Compiling GCC with g++: a report

[Joe Buck]

On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote:
> Paul Koning <pkoning@equallogic.com> writes:
> > I hope that doesn't require (void *) casts for pointer arguments
> > passed to the likes of memcpy...
> 
> Only the (void*) -> (any*) direction requires a cast in C++, the other
> direction is still converted implicitly.

In my view, the decision by the C standards committees to allow the
omission of the cast in the reverse direction was a bad mistake (and I
wrote my first C program in 1981, if I recall correctly).
While, in

    int * int_p = malloc(num_integers * sizeof(int));

the operation is safe, this is only because the void* returned by malloc
is different from the void* obtained by, say,

    double d_var;
    void * p;
    ...
    p = &d_var;

since one is safe to assign to an int* and the other is not.  We really
have two different types here; one represents the top of a lattice and
the other represents the bottom.  It would have been nice if there
were a type "aligned_pointer_t" to represent the kind of object returned
by malloc.

For this reason, I always cast the result of malloc to the proper type;
it just feels wrong otherwise.

Re: Compiling GCC with g++: a report

[Dale Johannesen]

On May 24, 2005, at 9:43 AM, Joe Buck wrote:
> On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote:
>> Paul Koning <pkoning@equallogic.com> writes:
>>> I hope that doesn't require (void *) casts for pointer arguments
>>> passed to the likes of memcpy...
>>
>> Only the (void*) -> (any*) direction requires a cast in C++, the other
>> direction is still converted implicitly.
>
> For this reason, I always cast the result of malloc to the proper type;
> it just feels wrong otherwise.

Yes, if the cast looks odd to you, you probably don't go back far 
enough.
I've certainly used compilers that warned when you didn't have a cast 
there.

Re: Compiling GCC with g++: a report

[Kevin Handy]

Gabriel Dos Reis wrote:

>Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
>
>[...]
>
>| Attempt to get the GNU C++ compiler through the same massage is
>| underway (but I'm going to bed shortly ;-)).
>
>I can also report that I got the GNU C++ compiler through -- and apart
>form uses of C++ keywords (template, namespace, class), it worked
>out.  A note on type sfety issue though: lookup_name() is declared in
>c-tree.h as
>
>      extern tree lookup_name (tree);
>
>and used in c-common.c:handle_cleanup_attribute() according to that
>signature.  It is however declared and defined in cp/ as
>
>      extern tree lookup_name (tree, int);
>
>That was caught at link time (and dealt with).
>
>-- Gaby
>  
>
Would it be possible to add a diagnostic to GCC to warn when C++
keywords are being used as identifiers? Maybe also add any
objective C keywords too.

This seems like it would be useful to someone writing library
functions that could, at some later time, be imported (cut and paste)
into code for the other languages, as well as for code being converted
from C to C++.

Re: Compiling GCC with g++: a report

[Kevin Handy]

Diego Novillo wrote:

>On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
>
>  
>
>>So, if various components maintainers (e.g. C and C++, middle-end,
>>ports, etc.)  are willing to help quickly reviewing patches we can
>>have this done for this week (assuming mainline is unslushed soon).
>>And, of course, everybody can help :-)
>>
>>    
>>
>If the final goal is to allow GCC components to be implemented in
>C++, then I am all in favour of this project.  I'm pretty sick of
>all this monkeying around we do with macros to make up for the
>lack of abstraction.
>
>
>Diego.
>
>  
>
It might be interesting, sometime in the future, to fork a version
of GCC into a C++ version, just to see what can be done with it.

It might make it easier for someone to write their own front/back
end by using existing classes to fill out most of the standard stuff,
and to build up trees using classes, etc.

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | So you don't see any value whatsoever to having (for instance) the
> | individual constants of 'enum machine_mode' be inaccessible in most of
> | GCC?  'cos I sure do.
>
> What I'm saying is that when you have a name like EXPAND_NORMAL, you
> do not need to know the value it represents.  Just that it names a
> constant.

We appear to be still talking about two different cases.  I am talking
about the case where, in C++, you might declare something like

class machine_mode
{
  enum {
    VOIDmode, SImode, // ...
  } value;

 // accessors, whatever ...
};

and then pass around 'machine_mode' objects.  Does this help?

zw

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Tue, 2005-05-24 at 09:41 -0400, Daniel Jacobowitz wrote:
> We've fixed a lot of these problems already; I will be brave and say
> that we have fixed most of them.

I'm glad you're optimistic about it.  It's good to have someone
balancing out pessimistic people like me. :)

> > This scenario, at least theoretically, becomes a non-issue if we make
> > top-level bootstrap the only option before we start using C++ features
> > in GCC, but that hasn't happened yet.
> 
> As Paolo wrote, it will soon.  This isn't the only thing it'll fix. 
> For instance it would let us use bool in those interfaces again,
> without breaking Darwin.

Actually it won't.  We could only use a real 'bool' if we switched to
C++.   Short of that, we can't count on bool being a real bool, so we
have to #define it to unsigned char everywhere so that no one
accidentally writes code that relies on bool having Boolean semantics.

You might think we could get away with it in stage 2, but that's
actually a recipe for comparison failures.

(I'm pleasantly surprised to report that HP's C++ compiler *doesn't*
have the bool/_Bool bugs that their C compiler does.)

> > Scenario two: Suppose that we have not found every last place where
> > LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to
> > ensure that the dynamic linker binds the stage 2 compiler to the
> > shared libstdc++ that it's expecting.
> 
> With top level bootstrap this is trivial to get right.  The top level
> should set the library path appropriately for the stage.

Um, there have been plenty of cases in the past where the top level set
something correctly and the subdirectory makefiles overrode it with an
incorrect setting.

> You do realize that libgcc is "compatible" in the same way as glibc,
> right?  If you do this and don't copy the hypothetical gcc 4.3
> libgcc_s.so.1 into your system library directory, C++ stands a decent
> chance of not working.  Not a new problem.

No, not a new problem.  In a lot of ways, C++ use in GCC would inflict
on us the same problems we've been inflicting on our users since before
3.0.  ;-/

> I don't know why you think that the DT_RPATH would cause the build to
> fail.  A DT_RPATH pointing at a non-existant directory is harmless and
> LD_LIBRARY_PATH will still be used.  It's only if you had an old copy
> in $prefix that DT_RPATH would bite you.  And there are plenty of other
> ways around this - for instance, a shell script named xgcc in the build
> tree which LD_PRELOADs the correct copy using a full path.

I had misremembered what DT_RPATH did if the directory didn't exist; my
bad.

In private mail someone suggested $ORIGIN to me as a possible solution.
I really don't mean to be giving the impression that these are
intractable problems; I just don't want them considered non-problems.

> > I'd want to see at least two major releases with no libstdc++ soname
> > bump and no problems reported, before I had confidence we'd gotten
> > it right.
> 
> You mean, like GCC 3.4 and GCC 4.0?

If GCC 4.1 comes out without anyone having reported 3.4/4.0
incompatibilities, and continues to provide libstdc++.so.6, then yes,
that would be like what I mean.  However, the active development on the
libstdc++.so.7 branch means that we haven't even started the clock
running on this criterion yet.

zw

Re: Compiling GCC with g++: a report

[Daniel Jacobowitz]

On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote:
> Um, there have been plenty of cases in the past where the top level set
> something correctly and the subdirectory makefiles overrode it with an
> incorrect setting.

Ah, but once we have a globally correct setting in the top level we can
brutally eliminate settings further down.  This does require toplevel
bootstrap.

> In private mail someone suggested $ORIGIN to me as a possible solution.
> I really don't mean to be giving the impression that these are
> intractable problems; I just don't want them considered non-problems.

$ORIGIN is nifty; but do you know how portable it is?  I've got no
clue.

> > > I'd want to see at least two major releases with no libstdc++ soname
> > > bump and no problems reported, before I had confidence we'd gotten
> > > it right.
> > 
> > You mean, like GCC 3.4 and GCC 4.0?
> 
> If GCC 4.1 comes out without anyone having reported 3.4/4.0
> incompatibilities, and continues to provide libstdc++.so.6, then yes,
> that would be like what I mean.  However, the active development on the
> libstdc++.so.7 branch means that we haven't even started the clock
> running on this criterion yet.

That would be three major releases unless you're counting differently
than I am.  My point was that we did preserve the soname between 3.4
and 4.0, and no one's reported trouble because of that yet - and I have
fairly high confidence that no one will.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Compiling GCC with g++: a report

[Richard Henderson]

On Tue, May 24, 2005 at 07:17:22PM -0400, Daniel Jacobowitz wrote:
> $ORIGIN is nifty; but do you know how portable it is?  I've got no
> clue.

Solaris and Linux only, afaik.


r~

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Tue, 2005-05-24 at 19:17 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote:
> > Um, there have been plenty of cases in the past where the top level set
> > something correctly and the subdirectory makefiles overrode it with an
> > incorrect setting.
> 
> Ah, but once we have a globally correct setting in the top level we can
> brutally eliminate settings further down.  This does require toplevel
> bootstrap.

Can, yeah, but how long will it take to get done?  It's two years later
and we're still ripping 2.13isms out of gcc/configure.ac at a painfully
slow rate.

> $ORIGIN is nifty; but do you know how portable it is?  I've got no
> clue.

Linux and Solaris, is all I know.  Note that the solution needn't be the
same on all platforms.

> > If GCC 4.1 comes out without anyone having reported 3.4/4.0
> > incompatibilities, and continues to provide libstdc++.so.6, then yes,
> > that would be like what I mean.  However, the active development on the
> > libstdc++.so.7 branch means that we haven't even started the clock
> > running on this criterion yet.
> 
> That would be three major releases unless you're counting differently
> than I am.  My point was that we did preserve the soname between 3.4
> and 4.0, and no one's reported trouble because of that yet - and I have
> fairly high confidence that no one will.

I'm counting two full development cycles since the initial release with
the frozen ABI.  Or, perhaps it will make more sense if I describe it as
one full development cycle since the release of the second compiler that
implements the frozen ABI.  This is to give people time to find and
report problems, which they are more likely to do when it involves
comparing two official releases than when it involves comparing a
released version to the development trunk.  4.0 has only been out for
what, a month now?  And people are being skittish about adopting it
because of all the optimizer changes.

zw

Re: Compiling GCC with g++: a report

[Paolo Carlini]

Hi,

>..........................  However, the active development on the
>libstdc++.so.7 branch means that we haven't even started the clock
>running on this criterion yet.
>  
>
Maybe a clarification is in order: actually, the name
libstdcxx_so_7-branch is somewhat misleading, right now. Indeed, it's
absolutely true that a lot of active development is going on in that
branch (consider the nice changes contributed by Chris Jefferson, for
instance, and more will come), but not necessarily all those changes
actually break to ABI. In a nutshell, we are using that branch for new,
experimental features/optimizations that *may* break the ABI. For
instance, in my understanding at least, if we decide somehow in the
future to ship a different implementation of basic_string, that will
break the ABI. Probably this is not the case for many changes to the
containers, *very* little of which is present in the built *.a and *.so.
Really, during the next months we want to re-evaluate the various
subsets of changes for possible merge to 4.1 or, anyway,
not-ABI-breaking branches.

I'm not sure what the above may imply for your ongoing discussion, tough...

Paolo.

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
| > | So you don't see any value whatsoever to having (for instance) the
| > | individual constants of 'enum machine_mode' be inaccessible in most of
| > | GCC?  'cos I sure do.
| >
| > What I'm saying is that when you have a name like EXPAND_NORMAL, you
| > do not need to know the value it represents.  Just that it names a
| > constant.
| 
| We appear to be still talking about two different cases.  I am talking
| about the case where, in C++, you might declare something like
| 
| class machine_mode
| {
|   enum {
|     VOIDmode, SImode, // ...
|   } value;
| 
|  // accessors, whatever ...
| };
| 
| and then pass around 'machine_mode' objects.  Does this help?

Nothing in what I said or is proposing prevents that scenario, if you
decided to go there (despite pessimizations on x86 targets).  To pass
machine_mode around, you need it to be declared.  That same condition
holds it it were an enum.  Currently, what you want to do is not
directly possible, because functions are using numeric values
directly, therefore breaking the abstraction barrier.  What I'm
proposing is to use the *names* (instead of the values).  If and when
you convert machine_mode to a class, then you still need a way to
refer to those values, and the named constants could be silently
changed to const class machine_mode objects, that won't change
anything to the rest of the code.  That is a value of named constant
abstraction I was talking  about.  You get the abstraction for free,
with the changes I'm proposing.

-- Gaby

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Wed, 2005-05-25 at 01:45 +0200, Paolo Carlini wrote:
> >..........................  However, the active development on the
> >libstdc++.so.7 branch means that we haven't even started the clock
> >running on this criterion yet.
>
> Maybe a clarification is in order: actually, the name
> libstdcxx_so_7-branch is somewhat misleading, right now. Indeed, it's
> absolutely true that a lot of active development is going on in that
> branch (consider the nice changes contributed by Chris Jefferson, for
> instance, and more will come), but not necessarily all those changes
> actually break to ABI. 

Thanks for the clarification.  I did not know this.

> I'm not sure what the above may imply for your ongoing discussion, tough...

Well, if I were running the show, the 'clock' would only start running
when it was consensus among the libstdc++ developers that the soname
would not be bumped again - that henceforth libstdc++ was committed to
binary compatibility as good as glibc's.  Or better, if y'all can manage
it.  It doesn't sound like we're there yet, to me.

zw

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
> 
> | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | > | So you don't see any value whatsoever to having (for instance) the
> | > | individual constants of 'enum machine_mode' be inaccessible in most of
> | > | GCC?  'cos I sure do.
> | >
> | > What I'm saying is that when you have a name like EXPAND_NORMAL, you
> | > do not need to know the value it represents.  Just that it names a
> | > constant.
> | 
> | We appear to be still talking about two different cases.  I am talking
> | about the case where, in C++, you might declare something like
> | 
> | class machine_mode
> | {
> |   enum {
> |     VOIDmode, SImode, // ...
> |   } value;
> | 
> |  // accessors, whatever ...
> | };
> | 
> | and then pass around 'machine_mode' objects.  Does this help?
> 
> Nothing in what I said or is proposing prevents that scenario, if you
> decided to go there (despite pessimizations on x86 targets). 

This is still not an answer to the question I originally asked - do you
see any way IN C to write code which has the relevant property of the
class above (that is, that the FOOmode constants are not accessible
except to authorized code) and which does not rely on free conversion
between enumeration constants and integral types?

zw

Re: Compiling GCC with g++: a report

[Daniel Jacobowitz]

On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> Well, if I were running the show, the 'clock' would only start running
> when it was consensus among the libstdc++ developers that the soname
> would not be bumped again - that henceforth libstdc++ was committed to
> binary compatibility as good as glibc's.  Or better, if y'all can manage
> it.  It doesn't sound like we're there yet, to me.

If that's why you were confused by my response, I was not suggesting
freezing the ABI.  I think it's an awful idea.  You specifically
objected to shipping two versions using the same SONAME in case we
installed the new one and it turned out to be incompatible - which
we've done.

I still haven't seen a valid objection to bumping the SONAME whenever
necessary.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Compiling GCC with g++: a report

[Russ Allbery]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> Zack Weinberg <zack@codesourcery.com> writes:

> | (And I'd be less grumpy about coding to the intersection of C and C++
> | if someone coded up warnings for the C compiler to catch things
> | outside the intersection.)

> Consider that to be a follow-up that I'm willing to do, if these
> preliminary patches are in.  For sure, I do want to make sure that we
> do not break things too easily.

Even apart from this project and this discussion, this would be awesome to
have, and I would be deeply grateful if you or someone else would
implement this.  Various people have requested over the years that some of
the packages I maintain compile cleanly with a C++ compiler, and while I
can test such compiles with special effort, being able to integrate the
warnings about it into my normal make warnings build would be incredibly
useful.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > Well, if I were running the show, the 'clock' would only start running
> > when it was consensus among the libstdc++ developers that the soname
> > would not be bumped again - that henceforth libstdc++ was committed to
> > binary compatibility as good as glibc's.  Or better, if y'all can manage
> > it.  It doesn't sound like we're there yet, to me.
> 
> If that's why you were confused by my response, I was not suggesting
> freezing the ABI.  I think it's an awful idea.  

Why?  To be honest, I keep harping on this mostly because I think it
should happen.  All the C++-in-GCC noise is a digression.  

You know how much work it is for the distributors every time we bump the
libstdc++ soname.  Why wouldn't we want to stop inflicting that pain on
them?

zw

Re: Compiling GCC with g++: a report

[DJ Delorie]

> This is still not an answer to the question I originally asked - do you
> see any way IN C to write code which has the relevant property of the
> class above (that is, that the FOOmode constants are not accessible
> except to authorized code) and which does not rely on free conversion
> between enumeration constants and integral types?

enum {
  TVQ_BAR_GRILL = (DATESTAMP % 10),
  TVQ_NEXT2,
  TVQ_NEXT3,
  TVQ_NEXT4
} TheValQuux;

It's evil, but it will keep programmers from hard-coding integer
constants anywhere.  The "constants" will need to be different every
day.

"Authorized code" can always offset by (DATESTAMP%10) if the intrinsic
values of the enums are important to it.

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote:
> > This is still not an answer to the question I originally asked - do you
> > see any way IN C to write code which has the relevant property of the
> > class above (that is, that the FOOmode constants are not accessible
> > except to authorized code) and which does not rely on free conversion
> > between enumeration constants and integral types?
> 
> enum {
>   TVQ_BAR_GRILL = (DATESTAMP % 10),
>   TVQ_NEXT2,
>   TVQ_NEXT3,
>   TVQ_NEXT4
> } TheValQuux;
> 
> It's evil, but it will keep programmers from hard-coding integer
> constants anywhere.  The "constants" will need to be different every
> day.

This doesn't do what I want at all.  The goal is to make the *symbolic
enumeration constants* inaccessible to most code.

Think about how machine_mode values are used.  Almost the entire
compiler is supposed to treat them as opaque things.  You get them from
e.g. int_mode_for_size; you may iterate over a class with
GET_MODE_WIDER_MODE; you stash them in RTL and you pass them to
predicates.  Appearances of "SImode" in the machine-independent compiler
are usually bugs.  This is a major contributing factor to the brokenness
of ports that don't set BITS_PER_UNIT==8.

The goal is to make "SImode" and its friends inaccessible in the
machine-independent compiler, so that that category of bugs cannot
arise.

zw

Re: Compiling GCC with g++: a report

[Ian Lance Taylor]

Zack Weinberg <zack@codesourcery.com> writes:

> Think about how machine_mode values are used.  Almost the entire
> compiler is supposed to treat them as opaque things.  You get them from
> e.g. int_mode_for_size; you may iterate over a class with
> GET_MODE_WIDER_MODE; you stash them in RTL and you pass them to
> predicates.  Appearances of "SImode" in the machine-independent compiler
> are usually bugs.  This is a major contributing factor to the brokenness
> of ports that don't set BITS_PER_UNIT==8.

Well, do you want a nice clean solution, like using a C++ class, or do
you want a hideous hacked up solution that works for C?

mv machmode.h real-machmode.h
cat <<EOF machmode.h
#include "real-machmode.h"
#define SImode diediedie
#define HImode diediedie
...
EOF
find config -name '*.[ch]' -print | while read f; do
  sed -e 's/"machmode.h"/"real-machmode.h"/' < $f > $f.new
  mv $f.new $f
done

Ian

Re: Compiling GCC with g++: a report

[Paolo Carlini]

Zack Weinberg wrote:

>Why?  To be honest, I keep harping on this mostly because I think it
>should happen.  All the C++-in-GCC noise is a digression.  
>  
>
I was wondering: is it too late to organize a Panel at GCCSummit?
Otherwise we can meet anyway more informally and discuss all those
issues anyway. In my opinion, during the last years too often the
various points of view remained implicit: it's probably in order a
little bit of planning based on clear, open discussion and, hopefully,
consensus.

Paolo.

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
| > Zack Weinberg <zack@codesourcery.com> writes:
| > 
| > | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
| > | > | So you don't see any value whatsoever to having (for instance) the
| > | > | individual constants of 'enum machine_mode' be inaccessible in most of
| > | > | GCC?  'cos I sure do.
| > | >
| > | > What I'm saying is that when you have a name like EXPAND_NORMAL, you
| > | > do not need to know the value it represents.  Just that it names a
| > | > constant.
| > | 
| > | We appear to be still talking about two different cases.  I am talking
| > | about the case where, in C++, you might declare something like
| > | 
| > | class machine_mode
| > | {
| > |   enum {
| > |     VOIDmode, SImode, // ...
| > |   } value;
| > | 
| > |  // accessors, whatever ...
| > | };
| > | 
| > | and then pass around 'machine_mode' objects.  Does this help?
| > 
| > Nothing in what I said or is proposing prevents that scenario, if you
| > decided to go there (despite pessimizations on x86 targets). 
| 
| This is still not an answer to the question I originally asked - do you

Oh this is getting silly, as I suggested the answer at the beginning
and repeated it over and over.

| see any way IN C to write code which has the relevant property of the
| class above (that is, that the FOOmode constants are not accessible
| except to authorized code) and which does not rely on free conversion
| between enumeration constants and integral types?

Yes.

  (1) Use the names.  What you want to prevent is the direct fidling
      with the bits, not the name.  Names are the messengers, not the
      message.  Don't shoot them.  So, no mocking around with type
      conversion unsigned int <-> enums.  When and if you move to
      class, codes using FOOmode will still work correctly.

   (2) When and if you switch to this:

        class machine_mode
        {
          enum value_t {
           VOIDmode, SImode, // ...
          } value;

         // accessors, whatever ...
        };

      You replace the global named constants with named constant objects

        extern const machine_mode FOOmode;

      This will not conflict with the other (enumeration values)
      FOOmode in machine_mode, because a class in C++ (unlike C)
      defines a scope, therefore shields them from the outside.  And
      people using FOOmode won't see any difference (except those
      breaking the abstraction barrier, but then you catch them).
      Furthermore, because you have access checking (brought to you for
      free) you do catch anyone who try to mock directly with the values.

So, using the named constants do make it easy for you if you move to
C++.  And if you decide not to go to C++, you still get better code.

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Russ Allbery <rra@stanford.edu> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > Zack Weinberg <zack@codesourcery.com> writes:
| 
| > | (And I'd be less grumpy about coding to the intersection of C and C++
| > | if someone coded up warnings for the C compiler to catch things
| > | outside the intersection.)
| 
| > Consider that to be a follow-up that I'm willing to do, if these
| > preliminary patches are in.  For sure, I do want to make sure that we
| > do not break things too easily.
| 
| Even apart from this project and this discussion, this would be awesome to
| have, and I would be deeply grateful if you or someone else would
| implement this.

I'm implementing this.  However, Zack has decided to gratuituously to
stand in the way, contrary to our coding conventions. 
You would need to alk to him, or the Steering Committ need to talk to him.

-- Gaby

Re: Compiling GCC with g++: a report

[DJ Delorie]

> This doesn't do what I want at all.  The goal is to make the *symbolic
> enumeration constants* inaccessible to most code.

Oh.

enum {
 THE_VAL_QUUX_ENUMS
} TheValQuux;

If not defined, you get one enum, THE_VAL_QUUX_ENUMS.  The "authority"
can define it to a list of enums, so it gets expanded.  Now, if we can
figure out a solution to the "enums are the smallest integral type
they fit in" problem, we'd be all set.  This might work with a suitable
terminator on the real list:

enum {
 THE_VAL_QUUX_ENUMS = 32767;
} TheValQuux;

The private header would have something like:

#define THE_VAL_QUUX_ENUMS \
	TVQ_FOO1, \
	TVQ_FOO2, \
	TVQ_FOO3, \
	TVQ_NUM_ENTRIES, \
	TVQ_INT_MAX

If it's OK to have the enums in a header, provided you can't *use* them...

enum {
#ifdef TVQ_AUTHORITATIVE_ENUMS
 TVQ_FOO1,
 TVQ_FOO2,
 TVQ_FOO3,
 TVQ_NUM_ENTRIES,
#endif
 TVQ_INT_SIZER = 32767;
} TheValQuux;

This won't stop a suitably enthusiastic programmer from getting to
them anyway, but that's always the case.

Or...

#ifndef TVG_ENUM
#define TVG_ENUM(X) DONT_USE_ME_TVG_##x
#endif
enum {
  TVG_ENUM(FOO1),
  TVG_ENUM(FOO2),
  TVG_ENUM(FOO3),
} TheValQuux;

With the "authority" suitably defining TVG_ENUM.

Of course, these are all just hacks to hide the enumerations.

Re: Compiling GCC with g++: a report

[Zack Weinberg]

On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote:
> > This doesn't do what I want at all.  The goal is to make the *symbolic
> > enumeration constants* inaccessible to most code.
> 
...
> If it's OK to have the enums in a header, provided you can't *use* them...
> 
> enum {
> #ifdef TVQ_AUTHORITATIVE_ENUMS
>  TVQ_FOO1,
>  TVQ_FOO2,
>  TVQ_FOO3,
>  TVQ_NUM_ENTRIES,
> #endif
>  TVQ_INT_SIZER = 32767;
> } TheValQuux;
> 
> This won't stop a suitably enthusiastic programmer from getting to
> them anyway, but that's always the case.

Ooh, I like this one for enum machine_mode.  The relevant header
(machmode.def) is already machine-generated, so it would be a fairly
small change.  And doesn't in any way interfere with Gabriel's cleanups
to use the enumeration type instead of 'int', which is good.

Be a hell of a lot of breakage to sort through, though.  Unless we've
got a volunteer with a whole lot of time, I don't think this is
happening for 4.1.  Oh well.

zw

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote:
| > > This is still not an answer to the question I originally asked - do you
| > > see any way IN C to write code which has the relevant property of the
| > > class above (that is, that the FOOmode constants are not accessible
| > > except to authorized code) and which does not rely on free conversion
| > > between enumeration constants and integral types?
| > 
| > enum {
| >   TVQ_BAR_GRILL = (DATESTAMP % 10),
| >   TVQ_NEXT2,
| >   TVQ_NEXT3,
| >   TVQ_NEXT4
| > } TheValQuux;
| > 
| > It's evil, but it will keep programmers from hard-coding integer
| > constants anywhere.  The "constants" will need to be different every
| > day.
| 
| This doesn't do what I want at all.  The goal is to make the *symbolic
| enumeration constants* inaccessible to most code.

But, you wrong in that goal.  The goal should not be to prevent access
to the names, but to prevent access to the values behind the names.  
You are looking at the wrong thing.

| Think about how machine_mode values are used.
                               ^^^^^^

That is the key.  *Values*.  You want to make sure the invariants for
the values are kept consistent.  Not, that the names that designate
the values are inaccessible.

| Almost the entire
| compiler is supposed to treat them as opaque things.

Yes, and the names do provide that abstraction layer.  Furthermore, if
you remove the current type mocking unsigned int <-> int <-> enums,
you do make a step further toward making sure that people treats the
machine_mode values as opaque.

|  You get them from
| e.g. int_mode_for_size; you may iterate over a class with
| GET_MODE_WIDER_MODE; you stash them in RTL and you pass them to
| predicates.  Appearances of "SImode" in the machine-independent compiler
| are usually bugs.

That is wrong.  If you remove the names and provide interface where
people use integers and type casts, you promote more opportunities for
bugs.  That is not what you want.  You want something different.  You
want better control.  The need for iterating over the modes is real.
So what you do is provide an interface for that.  In the earlier
message, I even said I used macros NEXT(), PREV().

|  This is a major contributing factor to the brokenness
| of ports that don't set BITS_PER_UNIT==8.
| 
| The goal is to make "SImode" and its friends inaccessible in the

No, the goal is to make the *values* inaccessible, not the names.

| machine-independent compiler, so that that category of bugs cannot
| arise.

-- Gaby

Re: Compiling GCC with g++: a report

[DJ Delorie]

>    (2) When and if you switch to this:
> 
>         class machine_mode
>         {
>           enum value_t {
>            VOIDmode, SImode, // ...
>           } value;
> 
>          // accessors, whatever ...
>         };

I think what Mark wants is to migrate to this:

	class machine_mode_desc
	{
	  unsigned char bits;
	  unsigned char is_signed:1;
	  unsigned char partial_bits;
	  unsigned char vector_width;
	  char *name;
	  // accessors, whatever
	};
	class machine_mode
	{
	  machine_mode_desc *mode_data;
	  // various constructors
	}

And the target can do this in tm.c:

	class machine_mode SImode ("SI", 32);
	class machine_mode V4QImode ("V4QI", 8, 0, 8, 4);

Then, the MI parts can obtain a mode with certain characteristics,
enumerate available modes, and get info about a given mode, but don't
have a compile-time identifier for a "well-known named" mode.

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

DJ Delorie <dj@redhat.com> writes:


[...]

| If it's OK to have the enums in a header, provided you can't *use* them...
| 
| enum {
| #ifdef TVQ_AUTHORITATIVE_ENUMS
|  TVQ_FOO1,
|  TVQ_FOO2,
|  TVQ_FOO3,
|  TVQ_NUM_ENTRIES,
| #endif
|  TVQ_INT_SIZER = 32767;
| } TheValQuux;
| 
| This won't stop a suitably enthusiastic programmer from getting to
| them anyway, but that's always the case.

Furthermore, that does not stop an enthusiastic programmer from
feeding the interface functions with the wrong values if he is
supposed to convert between integers and enums.  That is a far more
important problem that trying to prevent using the names.  If you
provide the names, then you have control over what they mean and there
is no incitation to cast things, therefore there is more chance to get
things right and less chance to get the horrible bugs one would like
to prevent by making the names inaccessible.  The names are not the
problem.  

| Or...
| 
| #ifndef TVG_ENUM
| #define TVG_ENUM(X) DONT_USE_ME_TVG_##x
| #endif
| enum {
|   TVG_ENUM(FOO1),
|   TVG_ENUM(FOO2),
|   TVG_ENUM(FOO3),
| } TheValQuux;
| 
| With the "authority" suitably defining TVG_ENUM.
| 
| Of course, these are all just hacks to hide the enumerations.

-- Gaby

Re: Compiling GCC with g++: a report

[DJ Delorie]

> No, the goal is to make the *values* inaccessible, not the names.

No, *I* want gcc to stop doing *&$@ like this:

  stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);

It should use GET_MODE(stack_parm) in case the target has multiple
pointer sizes.

And YES I have a port with multiple pointer sizes, and YES the
customer wanted both sizes supported in a single compilation unit and
NO I couldn't get gcc to do it, because Pmode was hardcoded in a LOT
of inappropriate places.

Oh, and sometimes gcc randomly uses pointer_mode instead of Pmode.  I
haven't a clue why there's a difference, or how badly gcc would break
if pointer_mode and Pmode were different.  Ok, I lied, I *do* know how
badly it breaks if they differ; I did try that at one point.

Here's another [quickly found, possibly inappropriate] one:

  void
  initialize_sizetypes (bool signed_p)
  {
    tree t = make_node (INTEGER_TYPE);
  
    TYPE_MODE (t) = SImode;

size_t is 16 bits on that platform, but SImode is 32 bits.  Is
hard-coding SImode the right thing to do?

Re: Compiling GCC with g++: a report

[DJ Delorie]

> Furthermore, that does not stop an enthusiastic programmer from
> feeding the interface functions with the wrong values

If you seed the first enum from DATESTAMP, and properly range check,
you can find these cases pretty quickly and abort.

  TVQ_SEED = (DATESTAMP%10) * 1000,
  TVQ_FOO1,
  ...

> if he is supposed to convert between integers and enums.

I can't imagine any situation where the programmer is *supposed* to
feed integers where enums are expected, in the cases where we're
trying to hide the names (like machine_mode).

I think the problem you're trying to solve is enumerations that, for
example, define an ABI to hardware or something, where they *must*
have specific values.  Still, you can use the DATESTAMP trick, and
offset it in the authoritative functions to get the needed integer
values.

enum {
  TVQ_SEED = (DATESTAMP%10) * 1000,
  TVQ_NOP,
  TVQ_READ,
  TVQ_WRITE
} tvq_dma_command;

int tvq_dma (tvq_dma_command cmd)
{
  *port = (int)cmd - ((int)TVQ_SEED+1);
}

If you really must stop people from using integers found in ABI
manuals, list the enums in reverse order.  You can still use math to
find the right integers, but you can't use TVQ_NOP+2 to mean "the chip
expects a 2".

Worse, use a random order and a private lookup table ;-)

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote:
| > > This doesn't do what I want at all.  The goal is to make the *symbolic
| > > enumeration constants* inaccessible to most code.
| > 
| ...
| > If it's OK to have the enums in a header, provided you can't *use* them...
| > 
| > enum {
| > #ifdef TVQ_AUTHORITATIVE_ENUMS
| >  TVQ_FOO1,
| >  TVQ_FOO2,
| >  TVQ_FOO3,
| >  TVQ_NUM_ENTRIES,
| > #endif
| >  TVQ_INT_SIZER = 32767;
| > } TheValQuux;
| > 
| > This won't stop a suitably enthusiastic programmer from getting to
| > them anyway, but that's always the case.
| 
| Ooh, I like this one for enum machine_mode.  The relevant header
| (machmode.def) is already machine-generated, so it would be a fairly
| small change.  And doesn't in any way interfere with Gabriel's cleanups
| to use the enumeration type instead of 'int', which is good.

I want to say a public thank to DJ and Mark for building the bridge
between Zack and me.

-- Gaby

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

DJ Delorie <dj@redhat.com> writes:

| > No, the goal is to make the *values* inaccessible, not the names.
| 
| No, *I* want gcc to stop doing *&$@ like this:
| 
|   stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);
| 
| It should use GET_MODE(stack_parm) in case the target has multiple
| pointer sizes.

Ah, that I have no problem with and I completelty agree with.

The cases I've found in my conversion was when codes use plain
"0" instead of VOIDmode or whatever machine_mode is appropriate.
That use of plain 0 breaks compilation with a C++ compiler. 

Now, once we have the appropriate XXXmode in place, they would be
easier to grep for :-)

Thanks,

-- Gaby

Re: Compiling GCC with g++: a report

[Daniel Jacobowitz]

On Tue, May 24, 2005 at 05:32:27PM -0700, Zack Weinberg wrote:
> On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> > On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > > Well, if I were running the show, the 'clock' would only start running
> > > when it was consensus among the libstdc++ developers that the soname
> > > would not be bumped again - that henceforth libstdc++ was committed to
> > > binary compatibility as good as glibc's.  Or better, if y'all can manage
> > > it.  It doesn't sound like we're there yet, to me.
> > 
> > If that's why you were confused by my response, I was not suggesting
> > freezing the ABI.  I think it's an awful idea.  
> 
> Why?  To be honest, I keep harping on this mostly because I think it
> should happen.  All the C++-in-GCC noise is a digression.  
> 
> You know how much work it is for the distributors every time we bump the
> libstdc++ soname.  Why wouldn't we want to stop inflicting that pain on
> them?

I know exactly how much work it is for Debian.  I wouldn't mind slowing
down.  I wouldn't mind using symbol versioning to solve the problem, if
I honestly thought that were feasible (which I don't, for a C++
implementation library).  But the fact of the matter is, the distros
know how to deal with this once in a while.  I think that it's more
important that we continue to improve the library, for now.

In a couple years I'll probably think differently.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

DJ Delorie <dj@redhat.com> writes:

| >    (2) When and if you switch to this:
| > 
| >         class machine_mode
| >         {
| >           enum value_t {
| >            VOIDmode, SImode, // ...
| >           } value;
| > 
| >          // accessors, whatever ...
| >         };
| 
| I think what Mark wants is to migrate to this:
| 
| 	class machine_mode_desc
| 	{
| 	  unsigned char bits;
| 	  unsigned char is_signed:1;
| 	  unsigned char partial_bits;
| 	  unsigned char vector_width;
| 	  char *name;
| 	  // accessors, whatever
| 	};
| 	class machine_mode
| 	{
| 	  machine_mode_desc *mode_data;
| 	  // various constructors
| 	}
| 
| And the target can do this in tm.c:
| 
| 	class machine_mode SImode ("SI", 32);
| 	class machine_mode V4QImode ("V4QI", 8, 0, 8, 4);
| 
| Then, the MI parts can obtain a mode with certain characteristics,
| enumerate available modes, and get info about a given mode, but don't
| have a compile-time identifier for a "well-known named" mode.

I like it.

However, that is orthogonal to changing the plain numeric value "0" to
the named constant with current machinery, don't you believe?

-- Gaby

Re: Compiling GCC with g++: a report

[DJ Delorie]

> The cases I've found in my conversion was when codes use plain
> "0" instead of VOIDmode or whatever machine_mode is appropriate.
> That use of plain 0 breaks compilation with a C++ compiler. 

If the #include isn't portable enough, just hard code a 42.  We'd need
suitable changes for insn-modes.c et al (null mode_names should stop
some of them!), but this was just to give you the idea ;-)

Index: genmodes.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/genmodes.c,v
retrieving revision 1.15
diff -p -U3 -r1.15 genmodes.c
--- genmodes.c	15 Oct 2004 14:47:07 -0000	1.15
+++ genmodes.c	25 May 2005 02:02:14 -0000
@@ -24,6 +24,10 @@ Software Foundation, 59 Temple Place - S
 #include "errors.h"
 #include "hashtab.h"
 
+static int some_random_number =
+#include "DATESTAMP"
+;
+
 /* enum mode_class is normally defined by machmode.h but we can't
    include that header here.  */
 #include "mode-classes.def"
@@ -780,6 +784,8 @@ emit_insn_modes_h (void)
 \n\
 enum machine_mode\n{");
 
+  printf("  MIN_MACHINE_MODE = %d,\n", some_random_number % 10 + 5);
+
   for (c = 0; c < MAX_MODE_CLASS; c++)
     for (m = modes[c]; m; m = m->next)
       {

Re: Compiling GCC with g++: a report

[Kaveh R. Ghazi]

 >  > unrestricted use of C++ keywords; declaring structure fields with
 >  > the same name as a structure tag in scope.
 > 
 > I don't think we should be reverting patches that fall afoul of these
 > last two, even if they break Gaby's build-with-a-C++-compiler
 > builds. But, I would tend to accept patches from Gaby to fix such
 > problems.

This reminds me of the last time we were coding to two C-family
variants, named K&R vs ISO.  I had improved -Wtraditional to the point
where it caught most problems, and we had macros (PARAMS, etc) to
cover most other cases.

Now we have e.g. XNEW* and all we need is a new -W* flag to catch
things like using C++ keywords and it should be fairly automatic to
keep incompatibilities out of the sources.  IMHO Gaby should volunteer
to write the new -W flag, it'll be easier for him than fixing breakage
after the fact.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

DJ Delorie <dj@redhat.com> writes:

| > The cases I've found in my conversion was when codes use plain
| > "0" instead of VOIDmode or whatever machine_mode is appropriate.
| > That use of plain 0 breaks compilation with a C++ compiler. 
| 
| If the #include isn't portable enough, just hard code a 42.  We'd need
| suitable changes for insn-modes.c et al (null mode_names should stop
| some of them!), but this was just to give you the idea ;-)

I'll get back to that later, when I'm done with the syntactical part :-)

-- Gaby

Re: Compiling GCC with g++: a report

[DJ Delorie]

> Now we have e.g. XNEW* and all we need is a new -W* flag to catch
> things like using C++ keywords and it should be fairly automatic to
> keep incompatibilities out of the sources.

Why not this?

#ifndef __cplusplus
#pragma GCC poison class template new . . .
#endif

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

DJ Delorie <dj@redhat.com> writes:

| > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
| > things like using C++ keywords and it should be fairly automatic to
| > keep incompatibilities out of the sources.
| 
| Why not this?
| 
| #ifndef __cplusplus
| #pragma GCC poison class template new . . .
| #endif

I like it for GCC source code.  It would be nice to have  for libiberty.h
when everything is converted :-)

There was a suggestion from a different person that they might want
to check similar things that for their projects, so there might be some
usefulness to a -W switch...

-- Gaby

Re: Compiling GCC with g++: a report

[Jason Merrill]

On Mon, 23 May 2005 23:25:13 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

> Good point; yes, you would have to pass a pointer.  I guess you could
> create a singleton representative of each value in the enum, and pass
> them around, but I agree that's getting pretty ugly.  Of course, the
> problem with "unsigned int" is that it is a complete type, and people can
> accidentally pass in "7", even if there's no such enumeral.  You really
> want forward-declared enums, but you haven't got them; it may be you just
> lose. :-(

You don't have foward-declared enums because you don't know how large they
need to be.

If what you want is an opaque enum, such that other files treat it as an
integer and only certain files know the enumerators, then declare your
variables to some typedef of an integer.  People could accidentally pass in
"7" anyway in C.  You either get the opacity or the type checking (when
compiled as C++), but not both.

Jason

Re: Compiling GCC with g++: a report

[Bernardo Innocenti]

Kevin Handy wrote:

>> That was caught at link time (and dealt with).
>>  
>>
> Would it be possible to add a diagnostic to GCC to warn when C++
> keywords are being used as identifiers? Maybe also add any
> objective C keywords too.
> 
> This seems like it would be useful to someone writing library
> functions that could, at some later time, be imported (cut and paste)
> into code for the other languages, as well as for code being converted
> from C to C++.

I'd like such a switch too.  Until it's done, we could just
poison C++ keywords in system.h.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: Compiling GCC with g++: a report

[Christoph Hellwig]

On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > I'm not sure what the above may imply for your ongoing discussion, tough...
> 
> Well, if I were running the show, the 'clock' would only start running
> when it was consensus among the libstdc++ developers that the soname
> would not be bumped again - that henceforth libstdc++ was committed to
> binary compatibility as good as glibc's.  Or better, if y'all can manage
> it.  It doesn't sound like we're there yet, to me.

Why can't libstdc++ use symbol versioning?  glibc has maintained the soname
and binary comptiblity despite changing fundamental types like FILE

libstdc++ soname and versioning (was: Re: Compiling GCC...)

[Paolo Carlini]

Daniel Jacobowitz wrote:

>>Why?  To be honest, I keep harping on this mostly because I think it
>>should happen.  All the C++-in-GCC noise is a digression.  
>>
>>You know how much work it is for the distributors every time we bump the
>>libstdc++ soname.  Why wouldn't we want to stop inflicting that pain on
>>them?
>>    
>>
>I know exactly how much work it is for Debian.  I wouldn't mind slowing
>down.  I wouldn't mind using symbol versioning to solve the problem, if
>I honestly thought that were feasible (which I don't, for a C++
>implementation library).  But the fact of the matter is, the distros
>know how to deal with this once in a while.  I think that it's more
>important that we continue to improve the library, for now.
>
>In a couple years I'll probably think differently.
>
I agree on both accounts.

In practice, we have got an handful of bugs unfixable within the current
ABI (mostly already fixed in v7) and a major QoI issue (ref-counted
string vs MT) which certainly we don't want in anything "definitive" (x).

Paolo.

(x) What "definitive" really means in such contexts is an interesting
semantic issue: *for sure* will end with C++0x ;)

Re: Compiling GCC with g++: a report

[Florian Weimer]

* Christoph Hellwig:

> Why can't libstdc++ use symbol versioning?

Via stack allocation, templates and inline functions, the internal
representation of libstdc++ data structures is exported.  All of its
users would have to be versioned, too, and you'd need bridging code
between the ABIs (e.g. to pass a std::string from a v6 library to a v7
library).

Re: Compiling GCC with g++: a report

[Kaveh R. Ghazi]

 > > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
 > > things like using C++ keywords and it should be fairly automatic to
 > > keep incompatibilities out of the sources.
 > 
 > Why not this?
 > 
 > #ifndef __cplusplus
 > #pragma GCC poison class template new . . .
 > #endif

That's limited.  A new -W flag could catch not only this, but also
other problems like naked void* -> FOO* conversions.  E.g. IIRC, the
-Wtraditional flag eventually caught over a dozen different problems.
Over time this new warning flag for c/c++ intersection could be
similarly refined.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: libstdc++ soname and versioning (was: Re: Compiling GCC...)

[Theodore Papadopoulo]

On Wed, 2005-05-25 at 10:37 +0200, Paolo Carlini wrote:
> >>Why?  To be honest, I keep harping on this mostly because I think it
> >>should happen.  All the C++-in-GCC noise is a digression.  
> [.....]
> In practice, we have got an handful of bugs unfixable within the
> current
> ABI (mostly already fixed in v7) and a major QoI issue (ref-counted
> string vs MT) which certainly we don't want in anything
> "definitive" (x).

The real problem I think is not really casting an ABI in stone, but
merely to have "some stability" over time. Maybe the only thing that is
missing is a "commitment" of the C++ library ABI stable over a few (two,
three ?) major gcc releases as there is one for the core compiler (and
remember it took several releases to achieve it)...

I agree that fixing the ABI for good is probably several years away, but
user expectation of keeping some stability is also reasonable...
I also believe making "some committment" (note that I clearly avoid to
state which one and I really understand that already people try to make
as little breakage as possible) helps to achieve the goal. So pushing up
for a stable ABI is also a good thing.

All that being said, I do not know why this C++ transition should be
blocked by libstdc++ ABI stability. Given the history the GCC project
and the amount of work (and the expected benefits) that would arise just
from converting to a simple subset of C++ (class,some simple inheritance
and maybe simple templates and no library stuff), I would argue that a
lot of benefit could be gained already just with core C++ (ie without
the library).

And this limits the ABI breakage problem to libsupc++ for which (as I as
I know) the problem is much simpler (at least it seems feasible to my
unexperienced observer)....

Obviously, using the C++ library could bring some more benefits, but
this seems clearly a second stage which could be done once the stdc++
library will freeze its ABI.

SO THE QUESTION IS: is libsupc++ is a state for which its ABI can be
freezed easily (I have not followed the topic closely enought to really
know, but it really seems to me that the answer is yes).

That being said, and to go back to the topic of freezing the libstdc++
ABI, maybe part of this work can be done immediately in the sense that
if there are parts of the library (eg list or vector) that are simple
enough and in a good state, then maybe it is possible to freeze those
(eventually providing a library in two pieces one stable and one
unstable), without freezing the whole ABI. Then immediately this part of
the standard C++ library becomes usable per Zack's request...

But obviously this C++ transition is plain science fiction for now...
Still science fiction sometimes brings useful ideas so it needs to be
considered. And actually, some science fiction creeps out of books much
faster than expected, so I'm still hoping....

Re: libstdc++ soname and versioning

[Paolo Carlini]

Theodore Papadopoulo wrote:

>The real problem I think is not really casting an ABI in stone, but
>merely to have "some stability" over time. Maybe the only thing that is
>missing is a "commitment" of the C++ library ABI stable over a few (two,
>three ?) major gcc releases as there is one for the core compiler (and
>remember it took several releases to achieve it)...
>  
>
Just a quick comment: this is *already* happening, no doubts. We have v6
since 3.4.0...

Paolo.

Re: libstdc++ soname and versioning (was: Re: Compiling GCC...)

[Gabriel Dos Reis]

On Wed, 25 May 2005, Theodore Papadopoulo wrote:

| All that being said, I do not know why this C++ transition should be
| blocked by libstdc++ ABI stability. Given the history the GCC project
| and the amount of work (and the expected benefits) that would arise just
| from converting to a simple subset of C++ (class,some simple inheritance
| and maybe simple templates and no library stuff), I would argue that a
| lot of benefit could be gained already just with core C++ (ie without
| the library).

The project I'm proposing is not to move to C++. Just to move to the
intersection of C and C++, which is what we had agreed on in previous
discussions.  Someone needs to implement those decisions, that is what
I'm trying to do (of course, anyone who can help is welcome).

Then, whether GCC should actually use C++, simple overloading, super
inheritance and hyper though template hackery is completely separate
issue. We may have those discussions but if we're not actually in any
way to be able to test the conjectures, then the whole discussion is
pointless.

The benefits to move to that intersection are obvious.

When the time comes to actually introduce C++ in GCC, we could have
the discussion of what to freeze.  As you may or may not have noticed,
libstdc++ people are trying hard to keep the ABI stable.  It also has
its own downsides -- there are bugs that we cannot fix and they are
known and implemented improvements we cannot benefit from.

-- Gaby

Re: libstdc++ soname and versioning

[Theodore Papadopoulo]

On Wed, 2005-05-25 at 14:48 +0200, Paolo Carlini wrote:
> Just a quick comment: this is *already* happening, no doubts. We have
> v6 since 3.4.0...

I know (well almost).... Apologies if my mail was suggesting the
opposite. As you might have noticed, I tried to avoid to make too strong
statements as I really know that there is some effort but have not
followed exactly to what extent this goes. Thank's for clarifying this.

If I said almost above is because, as far as I remember, Fedora Core 3,
shipped with a 3.4 compiler and a preview 4.0 one that has uses the 3.4
library. Of course that does not necessarily means that ABI has changed
but it surely somewhat confused me.

On that topic, my point was more to say "give some warranty/promise".

I know that all of you are working carefully to avoid ABI changes as
much as possible, but as far as I know there is no statement like "The C
++ library will be kept stable till release X.Y". Pick the X and Y you
are confortable with, and of course, if there is a huge problem then the
promise will be broken. As far as I remember, this happened at least
once with core C++ ABI with gcc-3.1, but overall after a very few wrong
promises, the ABI is "effectively" frozen (actually there is still a
pending core compiler ABI change pending)....

Re: libstdc++ soname and versioning (was: Re: Compiling GCC...)

[Theodore Papadopoulo]

On Wed, 2005-05-25 at 08:29 -0500, Gabriel Dos Reis wrote:
> The project I'm proposing is not to move to C++. Just to move to the
> intersection of C and C++, which is what we had agreed on in previous
> discussions.  Someone needs to implement those decisions, that is what
> I'm trying to do (of course, anyone who can help is welcome).

I know that, I was trying to find a compromise with respect to Zack's
comment on freezing the C++ library ABI and of the potential future
benefits.

Now, if you need some help, and can set some focussed goals (to someone
who does not know gcc internals so well), I can try. I think the work
you do is a very useful step.

> Then, whether GCC should actually use C++, simple overloading, super
> inheritance and hyper though template hackery is completely separate
> issue. We may have those discussions but if we're not actually in any
> way to be able to test the conjectures, then the whole discussion is
> pointless.

Again, my mail was more an answer to the point 2) of Zack's idea: that
1) your work would be useful only if there is some transition to C++ and
2) thus a stable C++ library was need.

I agree with all the comments you made that what you do is useful even
if 1) is not a route that will be followed (at the very least, it opens
the possibility). My remark was only concerning the point 2) that do not
seem to me a necessary consequence of 1). I waited for someone else to
make the comment, and to my surprise the discussion focussed of the need
to freeze libstdc++, thus my posting.

> When the time comes to actually introduce C++ in GCC, we could have
> the discussion of what to freeze.  As you may or may not have noticed,
> libstdc++ people are trying hard to keep the ABI stable.  It also has
> its own downsides -- there are bugs that we cannot fix and they are
> known and implemented improvements we cannot benefit from.

Again I know that (at least to some extent). Again, all my apologies if
my mail was hinting the opposite.

Re: libstdc++ soname and versioning

[Gabriel Dos Reis]

On Wed, 25 May 2005, Theodore Papadopoulo wrote:

| On that topic, my point was more to say "give some warranty/promise".

There is no point in making a promise when one does not have enough
data to keep it.  That does not mean, we don't want; just that it is
hard work.  And we have been carefully trying to make things as simple
as possible, at the expense of not fixing known bugs and not implementing
known improvements.

| I know that all of you are working carefully to avoid ABI changes as
| much as possible, but as far as I know there is no statement like "The C
| ++ library will be kept stable till release X.Y". Pick the X and Y you
| are confortable with, and of course, if there is a huge problem then the
| promise will be broken. As far as I remember, this happened at least
| once with core C++ ABI with gcc-3.1,

And I also distinctly remember the psychodrama that followed when
we discovered bugs we needed to fix, leading to premature gcc-3.2.x.

| but overall after a very few wrong promises,

"very few" is an euphemism when you investigate the impact ihey had.
What value woul dthe promise will have if they are wrong.

That is not saying that it is not desirable to have a stable ABI, you
can grant people working on listdc++ that they do know its value.
However, I think extreme care should be exercised when people are
pushing hard for hard statements and promises about ABI stability.
That should not be underestimated or handwaved.

-- Gaby

Re: libstdc++ soname and versioning

[Paolo Carlini]

Theodore Papadopoulo wrote:

>..........................(actually there is still a
>pending core compiler ABI change pending)....
>
Indeed, I think you are right: I clearly remember Mark saying: let's
synchronize any possible library ABI  change with a core compiler
change. In my understanding, we will end up doing one further iteration
within, say, 1-2 years. Seems to me a good compromise, considering,
again 3.4.0 ->

Paolo.

Re: Compiling GCC with g++: a report

[Jason Merrill]

On Tue, 24 May 2005 17:32:27 -0700, Zack Weinberg <zack@codesourcery.com> wrote:

> On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:

>> If that's why you were confused by my response, I was not suggesting
>> freezing the ABI.  I think it's an awful idea.  
>
> Why?  To be honest, I keep harping on this mostly because I think it
> should happen.  All the C++-in-GCC noise is a digression.  

The problem is that for a library that uses inlines and templates
extensively, the implementation is the interface, and so a change of
implementation frequently results in an ABI change.  So we can't freeze the
library ABI until we're willing to commit to the implementation.  C++ is
much less friendly to separate compilation than C, at least if you use
templates.

Jason

hidden enum constants (Was: Compiling GCC with g++: a report)

[Giovanni Bajo]

Zack Weinberg <zack@codesourcery.com> wrote:

>>> This doesn't do what I want at all.  The goal is to make the *symbolic
>>> enumeration constants* inaccessible to most code.
>>
> ...
>> If it's OK to have the enums in a header, provided you can't *use*
them...
>>
>> enum {
>> #ifdef TVQ_AUTHORITATIVE_ENUMS
>>  TVQ_FOO1,
>>  TVQ_FOO2,
>>  TVQ_FOO3,
>>  TVQ_NUM_ENTRIES,
>> #endif
>>  TVQ_INT_SIZER = 32767;
>> } TheValQuux;
>>
>> This won't stop a suitably enthusiastic programmer from getting to
>> them anyway, but that's always the case.
>
> Ooh, I like this one for enum machine_mode.

I think this is an ODR failure for C++ and I suspect program-at-a-time would
flag it with an error. So even this solution to hide enum constants (a
legitimate design request) does not appear to be C++ compatible to me.
-- 
Giovanni Bajo

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

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

|  > > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
|  > > things like using C++ keywords and it should be fairly automatic to
|  > > keep incompatibilities out of the sources.
|  > 
|  > Why not this?
|  > 
|  > #ifndef __cplusplus
|  > #pragma GCC poison class template new . . .
|  > #endif
| 
| That's limited.  A new -W flag could catch not only this, but also
| other problems like naked void* -> FOO* conversions.  E.g. IIRC, the
| -Wtraditional flag eventually caught over a dozen different problems.
| Over time this new warning flag for c/c++ intersection could be
| similarly refined.

This is now

     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759

-- Gaby

Re: Compiling GCC with g++: a report

[Marcin Dalecki]

On 2005-05-23, at 08:15, Gabriel Dos Reis wrote:
>
>
> Sixth, there is a real "mess" about name spaces.  It is true that
> every C programmers knows the rule saying tags inhabit different name
> space than variable of functions.  However, all the C coding standards
> I've read so far usually suggest
>
>    typedef struct foo foo;
>
> but *not*
>
>    typedef struct foo *foo;
>
> i.e. "bringing" the tag-name into normal name space to name the type
> structure or enumeration is OK, but not naming a different type!  the
> latter practice will be flagged by a C++ compiler.  I guess we may
> need some discussion about the naming of structure (POSIX reserves
> anything ending with "_t", so we might want to choose something so
> that we don't run into problem.  However, I do not expect this issue
> to dominate the discussion :-))
>

In 80% of the cases you are talking about the GCC source code already
follows the semi-convention of appending _s to the parent type.

Re: Compiling GCC with g++: a report

[Marcin Dalecki]

On 2005-05-24, at 09:09, Zack Weinberg wrote:

> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> [dropping most of the message - if I haven't responded, assume I don't
> agree but I also don't care enough to continue the argument.  Also,
> rearranging paragraphs a bit so as not to have to repeat myself]
>
>
>> with the explicit call to malloc + explicit specification of sizeof,
>> I've found a number of wrong codes -- while replacing the existing
>> xmalloc/xcallo with XNEWVEC and friends (see previous patches and
>> messages) in libiberty, not counting the happy confusion about
>> xcalloc() in the current GCC codes.  Those are bugs we do not have
>> with the XNEWVEC and friends.  Not only, we do get readable code, we
>> also get right codes.
>>
> ...
>
>> I don't think so.  These patches make it possible to compile the
>> source code with a C++ compiler.  We gain better checking by doing
>> that.
>>
>
> Have you found any places where the bugs you found could have resulted
> in user-visible incorrect behavior (of any kind)?
>
> If you have, I will drop all of my objections.

You could look at the linkage issues for darwin I have found several  
months
ago. They where *real*.

Re: Compiling GCC with g++: a report

[Marcin Dalecki]

On 2005-05-25, at 08:06, Christoph Hellwig wrote:

> On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
>
>>> I'm not sure what the above may imply for your ongoing  
>>> discussion, tough...
>>>
>>
>> Well, if I were running the show, the 'clock' would only start  
>> running
>> when it was consensus among the libstdc++ developers that the soname
>> would not be bumped again - that henceforth libstdc++ was  
>> committed to
>> binary compatibility as good as glibc's.  Or better, if y'all can  
>> manage
>> it.  It doesn't sound like we're there yet, to me.
>>
>
> Why can't libstdc++ use symbol versioning?  glibc has maintained  
> the soname
> and binary comptiblity despite changing fundamental types like FILE

Please stop spreading rumors:

1. libgcc changes with compiler release. glibc is loving libgcc. ergo:
    glibc has not maintained the soname and binary compatibility.

2. The whole linker tricks glibc plays to accomplish this
    are not portable and not applicable to C++ code.

3. Threads are the death to glibc backward compatibility.

Re: Compiling GCC with g++: a report

[Marcin Dalecki]

On 2005-05-24, at 18:06, Diego Novillo wrote:

> On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
>
>
>> So, if various components maintainers (e.g. C and C++, middle-end,
>> ports, etc.)  are willing to help quickly reviewing patches we can
>> have this done for this week (assuming mainline is unslushed soon).
>> And, of course, everybody can help :-)
>>
>>
> If the final goal is to allow GCC components to be implemented in
> C++, then I am all in favour of this project.  I'm pretty sick of
> all this monkeying around we do with macros to make up for the
> lack of abstraction.

Amen. GCC cries and woes through struct tree for polymorphism.

Re: Compiling GCC with g++: a report

[Marcin Dalecki]

On 2005-05-24, at 06:00, Andrew Pinski wrote:

>
> On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
>
>> Use of bare 'inline' is just plain wrong in our source code; this has
>> nothing to do with C++, no two C compilers implement bare 'inline'
>> alike.  Patches to add 'static' to such functions (AND MAKING NO  
>> OTHER
>> CHANGES) are preapproved, post-slush.
>>
> That will not work for the cases where the bare 'inline' are used
> because they are external also in this case.  Now this is where C99  
> and
> C++ differs at what a bare 'inline' means so I have no idea what to
> do, except for removing the 'inline' in first place.

This actually applies only to two function from libiberty:

  /* Return the current size of given hash table. */
-inline size_t
-htab_size (htab)
-     htab_t htab;
+size_t
+htab_size (htab_t htab)
{
    return htab->size;
}
/* Return the current number of elements in given hash table. */
-inline size_t
-htab_elements (htab)
-     htab_t htab;
+size_t
+htab_elements (htab_t htab)
{
    return htab->n_elements - htab->n_deleted;
}

It could be resolved easy be moving those "macro wrappers" in to a  
header
and making the static inline there. Actually this could improve the  
GCC code
overall a bit.

Re: Compiling GCC with g++: a report

[DJ Delorie]

>   which is defined to correspond to some physical mode

Close.  Defined to correspond to one or more physical modes.

> - Huh?, can you provide a single example of where a char type would
>   be mapped by the target to two different target specified modes?

i386 can hold a char in %al (QImode) or %bx (HImode) or %esi (SImode).
It can also be stored in st0 (TFmode).  I can't imagine why a target
port would want to *force* a char into a wider register on the i386,
but I don't want to assume it won't happen either.  Imagine, for
example, a port with 9 bit chars, with an __attribute__ to get an 8
bit char when different overflow semantics are required.

But I can easily imagine a chip (8086) where "int *" can be one of two
different sizes (16 or 32 bits).

>   mapped to into an indexed subreg of a wider target specified mode, the

See also WORD_REGISTER_OPERATIONS.

> - fully agree, no physical mode name (such as SImode) as may be defined
>   by the target should ever be referred to by the MI portion of the

Note that using integer_mode is equally wrong, if you don't check to
see if it's the proper size for the application.  long_integer_mode or
short_integer_mode might be more appropriate.  Copying modes from one
of the operands is faster.

Consider adding two scalars of modes A and B.  Maybe the target has an
addAB3 insn (some do!).  If not, see if it has {zero|sign})_extendAB2
(or BA depending on bits-per-mode) and addB3.  If not, for
(bits=bits(B)+1; bits<MAX_MODE_BITS; bits++) see if it has
addMODE(bits)3.

Note that this kind of thing happens a lot with multiply and divide
insns, which reminds me, I need to submit a patch to take out an
assumption that the "next wider" mode happens to be the "twice wider"
mode.  Doesn't work with partial int modes defined.

> - sorry, I was just attempting to respond given my best guess as to your
>   intent when you introduced BI mode into the discussion by with the above
>   to:
> 
> >>>>   target_unit_mode // presumably the target's smallest addressable datum.

On some chips, the smallest addressable datum is a bit, not a byte.
Given how often gcc makes invalid assumptions about bytes and words,
it was worth noting.

>   modes (i.e. function pointers may be defined to map to WILMA mode, where
>   label pointers may be defined to map to BARNEY mode physical target
>   pointer modes).

Sigh, more assumptions.  Don't group all functions into the same
pointer size either.  Consider the i386 "near" vs "far" attributes;
you need different sized pointers for EACH FUNCTION AND VARIABLE
depending on whether it's near or far.

> - fully agreed, my mistake in making the same incorrect assumption which
>   GCC seems to do on occasion, as alignment should likely be an attribute
>   of every target defined logical type -> physical mode mapping definition.

Worse.  Some chips have both aligned and unaligned addressing modes
for each physical data type.  Unaligned modes are normally slower, so
you'd want to tag those variables or pointers which may be unaligned,
and use a different type of pointer (although perhaps the same size)
for those, than the default.

> - given that the target may only "decide" based on the uniqueness of the
>   contextual of the pointer's use visible to it,

It knows what the pointer points to, too.  "pointer to int" may be
different than "pointer to __attribute__((far)) int".

>   rather than leaving it up to chance that they may be discrimated

i386 near vs far again.  Borland has supported that since the late
1980's, gcc still doesn't support it.

> - but only needs to associate a logical type mode with a target defined
>   physical mode when attempting to match the the target's instruction
>   rtl definitions defined in terms of physical modes SI, DI, WILMA, etc.),
>   it would seem?

My point was that MI and target both have the same information
available for doing this conversion.  There's no advantage to trying
to force the MI to do it somehow.

> - yes, as would always need to be done if the language's new data-type
>   precision or representation is target dependant, as most language
>   data-types are?

There are more language types than hard types, for example floating
point types might be simulated in software.  The target shouldn't need
to know about new types if they fit (somehow) into existing modes.

> - fully agree, which is why the MI need only deal with *language* type/modes
>   and rely on the target to define their mapping to *target* types/modes.

But the target should *not* know about language types, aside from a
few key bits like "bits per int" etc.

> >> - sorry, I don't see; as the program code, and internal tree representation
> >>   of that code (as you've noted below), identifies all nodes as having one
> >>   of N  canonical types (bool, char, short, int, *, [], etc.) not an
> >>   arbitrary type,
> > 
> > *Except* when you consider __attribute__ which can modify *anything*
> > in gcc.  This is how we get vector variables, interrupt functions,
> > etc.
> 
> - unless I misunderstand, I suspect you're mixing a few orthogonal issues:
> 
>   - the last first, a vector is just another canonical type, no different
>     than bool, char, etc. and needs it's target specific attributes
>     described by the target, and correspondingly mapped to some target
>     defined named physical mode which the target's rtl is described using.

Vectors can be simulated in software for ports that don't support
them.  Ports that *do* support them need to map them to existing
(nonstandard so far) vector operations.

>   - interrupt, no-return, etc. attributes aren't types per-se, but rather
>     semantic modifiers which GCC has provided as a convenience to both
>     programmers, and the middle-end architecture to enable the incremental
>     specification of semantics in a canonical way by language front-ends,
>     to enable the development of a language neutral middle end?

Except that "pointer to function" and "pointer to interrupt function"
must be different types, because *calling* those two types of
functions often requires a different set of opcodes.  "pointer to int"
and "pointer to unaligned int" must be different so the right
addressing modes (or simulations) can be used.

Consider this C++:

void foo (void __attribute__((far) *);
void foo (void __attribute__((near)) *);

int j;

foo(&j);

Which function is called?  How can it choose if it doesn't know how to
differentiate types that differ only in attributes?

>     be used to introduce "new" types, but only if that "new" type is defined
>     as being physically equivalent to an existing supported type/mode known
>     already to both the MI and the target portions of the compiler, as

No.  The MI shouldn't need to know about machine modes that are used
by the target only to support attribute-tagged types.  Essentially,
the target causes MI to create a new type (much like "typedef" does in
C) that the target happens to have insns for.

>     otherwise neither the MI or target portions of the compiler understands
>     it relationship/conversion to/from other types,

Why should the MI know how to convert between types in a given class?
That's what the extendMN2 insn patterns are for.

> > No, you're missing a lot of variability here.
> 
> - like? (observing that it may be easily augmented as desired/required)

near vs far comes to mind.  Vectors, complex, alignment, signalling,
volatile, etc.  Two variables of C type "char" might be assigned
different machine modes based on something MI doesn't know about.
What about CPUs with multiple [different] integer units?  You'd want
distinct scalar modes so the programmer can assign variables to
specific integer units, perhaps.  Example: a fast FPU vs an
IEEE-accurate FPU.

> >>   if (TYPE_MODE(...) == char_mode) ...
> > 
> > I'd rather see
> > 
> >     if (TYPE_MODE(...) == TYPE_MODE(...))
> > 
> > or
> >     if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE)
> 
> - out of curiosity, why?

If the MI is calling a function and passing three arguments, why
should it care if the type is "char" ?  If it's offsetting a pointer
to access a structure field, who cares if the pointer is Pmode?  What
about DSPs that have 32 bit chars, but can access 8 bit bytes?

Either deal with language types, or deal with machine modes.  Don't
mix them unless you're lowering to RTL, and only when absolutely
needed.  That's where the lookup functions get used.  But there's a
big difference between "give me a mode that is this type" and "give me
a mode that I can put this variable in".  The first makes unneeded
assumptions, the second doesn't.

Re: Compiling GCC with g++: a report

[Paul Schlie]

> From: DJ Delorie <dj@redhat.com>
>> - ok, and how does it know that it needs a 32-bit unsigned scalar?
> 
> tm.h: #define INT_TYPE_SIZE 32
> 
> Combined with "unsigned int foo;" in the user's source file.
> 
> The MI doesn't need to know that this fits in a QImode.

- agreed, all it needs to know is that a int_mode operand/operator is
  required, which is defined to correspond to some physical mode given
  some name by the target.

>>   the world is it desirable to go go in a big circle to identify
>>   which mode corresponds to a type as defined by the target, rather
>>   than simply having the target define it directly?)
> 
> Because on many targets, small scalars can be held in larger
> registers, and large scalars (or complex or vector types) can be held
> in groups of small registers.  There isn't a strict mapping between C
> types and hardware modes.  Plus, the target might provide attributes
> that alter the mode (think "__attribute__((mode(FRED)))").

- Huh?, can you provide a single example of where a char type would
  be mapped by the target to two different target specified modes?

  (as it seems that although multiple char's may be specified as being
  mapped to into an indexed subreg of a wider target specified mode, the
  middle end is responsible for identifying how and how many and smaller
  datum, may be packed into a vector, as defined by the target's
  specification of it's vector_mode, if supported at all, not the target.)

>>   correspondingly "well known named" types (such as bool, char, int,
> 
> In this case, the "well known named" things are front-end types, like
> "int" and "short", not back-end types, like PSImode or V4QImode.

- fully agree, which is why the MI need/should never need to identify
  the target physical mode (given some name by the target), which
  corresponds to the canonical type mode name like int_mode as used by
  the MI until target rtl templates need to be matched.

> A simple example of this type of problem is when MI uses "SImode" for
> integers, on a target with 16-bit integers.  SImode is wrong.  Any
> time you have "well known" types coming from the *target* you're
> setting yourself up for this type of thing.

- fully agree, no physical mode name (such as SImode) as may be defined
  by the target should ever be referred to by the MI portion of the
  compiler until target specific templates which use the target defined
  physical mode names need to be matched.

>>> BImode in most cases, not really useful that way.
>> 
>> - maybe we are using different terminology, as there would seem to
>> be no reason that a target couldn't define that a bool was a 16-bit
>> wide datum
> 
> I didn't say anything about bools.  See?  You're making the same wrong
> assumptions GCC makes.  "bool" should be a well-known name.  BImode
> shouldn't.  My chip has an addressing mode that addresses individual
> bits, has nothing to do with the "bool" type.

- sorry, I was just attempting to respond given my best guess as to your
  intent when you introduced BI mode into the discussion by with the above
  to:

>>>>   target_unit_mode // presumably the target's smallest addressable datum.

  (presuming that you meant that BI mode as presumed to the narrowest width
   physical mode, which I mistakenly presumed you associated with bool, but
   agree that the MI portion of the compiler should never presume anything
   about any particular target named machine physical mode.)

>>   (in essence, there needs to be a mechanism by which a target may
>>   define the it's address resolution, and alignment requirements,
>>   independently
> 
> The chip I'm working on has three addressing modes, with two different
> resolutions and alignments.  Your assumption - that there is one
> address resolution - already breaks my chip.

- fully agree, the MI portion of the compiler should make no assumptions
  about the equality of pointer modes as may be necessary to be distinct
  for a particular target, but do presume that all stack pointer, function
  pointer, label pointer, readonly_data pointer, heap pointer, etc.
  references utilize a common target defined mode, which may all be mapped
  to the same target physical pointer mode, or different physical pointer
  modes (i.e. function pointers may be defined to map to WILMA mode, where
  label pointers may be defined to map to BARNEY mode physical target
  pointer modes).
  
>>>>   target_word_mode // presumably the target's largest addressable datum.
>>> 
>>> BLKmode in all cases.  Also not useful.
>> 
>> - I hope not, as block mode operands seem to be used for moving data
>> with finer granularity than the target's word-width when
>> initializing char
> 
> You said largest addressable, not largest alignment.  More
> assumptions.  On some chips, for example, "words" may be unaligned,
> but "floats" must be aligned.  Your "well known name" is already
> wrong.

- fully agreed, my mistake in making the same incorrect assumption which
  GCC seems to do on occasion, as alignment should likely be an attribute
  of every target defined logical type -> physical mode mapping definition.

>> - no?, I presume that "target_word_mode" would merely describe
>> (mentioned above), an aspect of the physical target's natural memory
>> access granularity,
> 
> You're assuming the target has ONE "natural" access granularity.  Just
> the dichotomy between scalars and reals breaks that.
> 
> My chip has four "natural" accessing granularities.  Which would I
> choose?  (yes, I was stumped for UNITS_PER_WORD because it was used
> for many things, and I needed different things it was used for to work
> with different sized data).
> 
> Heck, the i386 has five natural modes (QI, HI, SI/SF, DI/DF TF).  Pick
> one.

- fully agreed, as above.

>> - understood, although it would seem much easier if the MI portion simply
>>   identified the type of pointer it required based upon the context of the
>>   access which it inherently knows (which the target may map to whatever
> 
> "inherently" is misleading.  The MI has two feasible options - assume
> all pointers are the same, or let the target decide.  There is no
> usable middle ground.

- given that the target may only "decide" based on the uniqueness of the
  contextual of the pointer's use visible to it, it depends on the MI
  differentiating such uses. Which seems simpler for the MI to do explicitly
  by named canonical pointer modes (such as function_pointer, label_pointer,
  rodata_pointer, etc.) rather than leaving it up to chance that they may
  be discrimated as may be required by the target; which the target may
  define to map to the same or different physical modes as required by the
  target, it would seem?

>>   mode it desires), rather than the target having to try to figure
>>   out based upon the more limited tree/rtx context visible to it?)
> 
> The tree/decl/rtx is all the MI has too.

- but only needs to associate a logical type mode with a target defined
  physical mode when attempting to match the the target's instruction
  rtl definitions defined in terms of physical modes SI, DI, WILMA, etc.),
  it would seem?

>> - understood, although hardly believe that it's a problem to require that
>>   a target define the logical->physical mapping required for for the 20
>>   or so logically distinct type variations that the MI portion is and
>>   should be aware of (rather than subject the mapping to any mishandling)
> 
> Ok, next time a new language front and is added with new data types,
> you get to update all the target backends.

- yes, as would always need to be done if the language's new data-type
  precision or representation is target dependant, as most language
  data-types are?

>> - I do believe were just using somewhat different terminology, as the MI
>>   portion of the compiler does and must deal with "well known named" typed
>>   operations and operands.
> 
> Does?  Yes.  Must?  No, outside of the *language* types (not the
> *target* types).

- fully agree, which is why the MI need only deal with *language* type/modes
  and rely on the target to define their mapping to *target* types/modes.

>> - sorry, I don't see; as the program code, and internal tree representation
>>   of that code (as you've noted below), identifies all nodes as having one
>>   of N  canonical types (bool, char, short, int, *, [], etc.) not an
>>   arbitrary type,
> 
> *Except* when you consider __attribute__ which can modify *anything*
> in gcc.  This is how we get vector variables, interrupt functions,
> etc.

- unless I misunderstand, I suspect you're mixing a few orthogonal issues:

  - the last first, a vector is just another canonical type, no different
    than bool, char, etc. and needs it's target specific attributes
    described by the target, and correspondingly mapped to some target
    defined named physical mode which the target's rtl is described using.

  - interrupt, no-return, etc. attributes aren't types per-se, but rather
    semantic modifiers which GCC has provided as a convenience to both
    programmers, and the middle-end architecture to enable the incremental
    specification of semantics in a canonical way by language front-ends,
    to enable the development of a language neutral middle end?

  - the use of GCC's __attribute__ extension directly in user code, seems
    to simply extend this capability to the programmer. And seemingly may
    be used to introduce "new" types, but only if that "new" type is defined
    as being physically equivalent to an existing supported type/mode known
    already to both the MI and the target portions of the compiler, as
    otherwise neither the MI or target portions of the compiler understands
    it relationship/conversion to/from other types, or it's corresponding
    target specific physical mode to use to represent the type, or
    operations it would seem?

>> - why bother if:  TYPE_MODE :: *target_type_mode, i.e:
>> 
>>   typedef struct {
>>     char* name;
>>     char* mode:
>>     char  size:
>>     enum  attribute {is_signed, is_unsigned, is_floating, is_void};
>>   } target_type_mode;
>>
>>   enum type_mode {
>>     bool_mode = &(target_type_mode){"bool", "QI", 10, is_unsinged},
>>     char_mode = &(target_type_mode){"char", "QI", 10, is_unsigned},
>>     uint_mode = &(target_type_mode){"uint", "HI", 17, is_unsigned},
>>     ...}
>
> No, you're missing a lot of variability here.

- like? (observing that it may be easily augmented as desired/required)

>>   if (TYPE_MODE(...) == char_mode) ...
> 
> I'd rather see
> 
>     if (TYPE_MODE(...) == TYPE_MODE(...))
> 
> or
>     if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE)

- out of curiosity, why?

(but suspect you simply like flexibility of another level of abstraction)

Re: Compiling GCC with g++: a report

[DJ Delorie]

> - ok, and how does it know that it needs a 32-bit unsigned scalar?

tm.h: #define INT_TYPE_SIZE 32

Combined with "unsigned int foo;" in the user's source file.

The MI doesn't need to know that this fits in a QImode.

>   the world is it desirable to go go in a big circle to identify
>   which mode corresponds to a type as defined by the target, rather
>   than simply having the target define it directly?)

Because on many targets, small scalars can be held in larger
registers, and large scalars (or complex or vector types) can be held
in groups of small registers.  There isn't a strict mapping between C
types and hardware modes.  Plus, the target might provide attributes
that alter the mode (think "__attribute__((mode(FRED)))").

>   correspondingly "well known named" types (such as bool, char, int,

In this case, the "well known named" things are front-end types, like
"int" and "short", not back-end types, like PSImode or V4QImode.

A simple example of this type of problem is when MI uses "SImode" for
integers, on a target with 16-bit integers.  SImode is wrong.  Any
time you have "well known" types coming from the *target* you're
setting yourself up for this type of thing.

> > BImode in most cases, not really useful that way.
> 
> - maybe we are using different terminology, as there would seem to
> be no reason that a target couldn't define that a bool was a 16-bit
> wide datum

I didn't say anything about bools.  See?  You're making the same wrong
assumptions GCC makes.  "bool" should be a well-known name.  BImode
shouldn't.  My chip has an addressing mode that addresses individual
bits, has nothing to do with the "bool" type.

>   (in essence, there needs to be a mechanism by which a target may
>   define the it's address resolution, and alignment requirements,
>   independently

The chip I'm working on has three addressing modes, with two different
resolutions and alignments.  Your assumption - that there is one
address resolution - already breaks my chip.

> >>   target_word_mode // presumably the target's largest addressable datum.
> > 
> > BLKmode in all cases.  Also not useful.
> 
> - I hope not, as block mode operands seem to be used for moving data
> with finer granularity than the target's word-width when
> initializing char

You said largest addressable, not largest alignment.  More
assumptions.  On some chips, for example, "words" may be unaligned,
but "floats" must be aligned.  Your "well known name" is already
wrong.

> - no?, I presume that "target_word_mode" would merely describe
> (mentioned above), an aspect of the physical target's natural memory
> access granularity,

You're assuming the target has ONE "natural" access granularity.  Just
the dichotomy between scalars and reals breaks that.

My chip has four "natural" accessing granularities.  Which would I
choose?  (yes, I was stumped for UNITS_PER_WORD because it was used
for many things, and I needed different things it was used for to work
with different sized data).

Heck, the i386 has five natural modes (QI, HI, SI/SF, DI/DF TF).  Pick
one.

> - understood, although it would seem much easier if the MI portion simply
>   identified the type of pointer it required based upon the context of the
>   access which it inherently knows (which the target may map to whatever

"inherently" is misleading.  The MI has two feasible options - assume
all pointers are the same, or let the target decide.  There is no
usable middle ground.

>   mode it desires), rather than the target having to try to figure
>   out based upon the more limited tree/rtx context visible to it?)

The tree/decl/rtx is all the MI has too.

> - understood, although hardly believe that it's a problem to require that
>   a target define the logical->physical mapping required for for the 20
>   or so logically distinct type variations that the MI portion is and
>   should be aware of (rather than subject the mapping to any mishandling)

Ok, next time a new language front and is added with new data types,
you get to update all the target backends.

> - I do believe were just using somewhat different terminology, as the MI
>   portion of the compiler does and must deal with "well known named" typed
>   operations and operands.

Does?  Yes.  Must?  No, outside of the *language* types (not the
*target* types).

> - sorry, I don't see; as the program code, and internal tree representation
>   of that code (as you've noted below), identifies all nodes as having one
>   of N  canonical types (bool, char, short, int, *, [], etc.) not an
>   arbitrary type,

*Except* when you consider __attribute__ which can modify *anything*
in gcc.  This is how we get vector variables, interrupt functions,
etc.

> - why bother if:  TYPE_MODE :: *target_type_mode, i.e:
> 
>   typedef struct {
>     char* name;
>     char* mode:
>     char  size:
>     enum  attribute {is_signed, is_unsigned, is_floating, is_void};
>   } target_type_mode;

No, you're missing a lot of variability here.

>   if (TYPE_MODE(...) == char_mode) ...

I'd rather see

    if (TYPE_MODE(...) == TYPE_MODE(...))

or
    if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE)

Re: Compiling GCC with g++: a report

[Paul Schlie]

> From: DJ Delorie <dj@redhat.com>
> 
>>   where then the target may declare class machine_mode
>>   target_int_mode ("HI", 16),
> 
> This is where we disagree.  The *target* shouldn't map types to modes.
> The *MI* should map types to modes. The target just creates the modes
> it supports and describes them. The MI looks them up by description
> (NOT NAME).  If the MI needs a 32 bit unsigned scalar, it does
> lookup_mode(32, M_SCALAR, M_UNSIGNED) and uses whatever gets returned.

- ok, and how does it know that it needs a 32-bit unsigned scalar?
  Answer: because it wants to know what mode it needs to specify for
  for an operation on a particular type which has those characteristics
  as defined by the targets definition of an int for example. (so why in
  the world is it desirable to go go in a big circle to identify which
  mode corresponds to a type as defined by the target, rather than simply
  having the target define it directly?)

> The fact that you're still trying to assign a "well known name" to a
> given type/mode/whatever means you haven't gotten away from the (to
> me) fundamental problem, that MI chooses modes according to what
> they're *for* instead of according to what they *are*.

- unless I misunderstand (which I admittedly may), the MI portion of
  the code is and should be based on manipulating data structures which
  correspond to user programs which are digested down to a canonical
  representation of "well known named" operators with operands of
  correspondingly "well known named" types (such as bool, char, int,
  float); who's sizes are defined by the target. So it would seem to
  stand to reason that the MI portion of GCC does and should restrict
  itself to well known "type" modes, which are defined to be mapped to
  physical modes as defined by the target? please see below)

>>   target_unit_mode // presumably the target's smallest addressable datum.
> 
> BImode in most cases, not really useful that way.

- maybe we are using different terminology, as there would seem to be no
  reason that a target couldn't define that a bool was a 16-bit wide datum
  while being able to address memory with a 4-bit wide granularity.
  (in essence, there needs to be a mechanism by which a target may define
   the it's address resolution, and alignment requirements, independently
   of it's specified type sizes, if not this way, then some other)

>>   target_word_mode // presumably the target's largest addressable datum.
> 
> BLKmode in all cases.  Also not useful.

- I hope not, as block mode operands seem to be used for moving data with
  finer granularity than the target's word-width when initializing char
  array and/or struct members (which need not be aligned to the width of
  of the target's widest naturally addressable datum, but it's smallest?)

>>   as there seems no valid reason for the target neutral portion of the
>>   compiler to ever refer to XXmode under any circumstance?
> 
> Ah, but in your case it *is* aware, it just calls it
> "target_word_mode" instead of "SImode" with all the same problems with
> assumptions.

- no?, I presume that "target_word_mode" would merely describe (mentioned
  above), an aspect of the physical target's natural memory access
  granularity, without having any presumed relationship to any particular
  separately defined target "type" mode such as it's target_int_mode for
  example.

>>   where correspondingly the MI portions of GCC utilizes the appropriate
>>   pointer mode as a function of the type of access being performed,
> 
> In my case, the target has to check the attributes of the
> function/data to decide what kind of pointer to use.  Again, "MI
> assuming" that all function pointers are the same is WRONG.

- understood, although it would seem much easier if the MI portion simply
  identified the type of pointer it required based upon the context of the
  access which it inherently knows (which the target may map to whatever
  mode it desires), rather than the target having to try to figure out based
  upon the more limited tree/rtx context visible to it?) thereby also
  exposing more potential opportunities for MI optimization to the middle
  end it would seem?

>> - understood, although I honestly don't believe there are that many, and
>>   it eliminates any possible confusion, and a host of other #defines.
> 
> My current port supports maybe 4-5 hard modes.  There are 19
> machine_modes defined.  That's about 4x as many as I really need to
> define, and that doesn't even include synthetic vector modes and such.

- understood, although hardly believe that it's a problem to require that
  a target define the logical->physical mapping required for for the 20
  or so logically distinct type variations that the MI portion is and
  should be aware of (rather than subject the mapping to any mishandling)

>> - as you've noted, all the information GCC MI portion needs to "do the
>>   right thing" already exists scattered in various target definitions,
>>   but it hasn't prevented mode assumptions from being made, and XXmodes
>>   being hard-coded into the MI sources on occasion; which is the only
>>   reason that I thought that by forcing target_TYPE_mode's to be the
>>   only thing available, GCC would indirectly be forced to always to the
>>   "right thing"?
> 
> The less available the better, true.  But target_*_modes don't need to
> be available either.  If you use a query/lookup API, MI can assume
> there are a *lot* of machine modes (one for each variable, one for
> each function, one for each C data type, etc), and let the target map
> them to available modes.

- I do believe were just using somewhat different terminology, as the MI
  portion of the compiler does and must deal with "well known named" typed
  operations and operands.

> targetm.modes.set_mode_for_decl(decl);
> 
> See?  This allows for a custom mode just for the given decl (it might
> be a 17 bit ternary value in a DSP), doesn't make assumptions about
> available machine modes, and MI can provide a naive default hook for
> targets that do "the usual thing".

- sorry, I don't see; as the program code, and internal tree representation
  of that code (as you've noted below), identifies all nodes as having one
  of N  canonical types (bool, char, short, int, *, [], etc.) not an
  arbitrary type, (where these canonical types need only be mapped to
  target supported/named/defined modes upon code generation, it would seem?)

> if (!TYPE_MODE (TREE_TYPE (decl)))
>  TYPE_MODE (TREE_TYPE (decl)) = find_mode_for_type (TREE_TYPE (decl));
> DECL_MODE (decl) = TYPE_MODE (TREE_TYPE (decl));

- why bother if:  TYPE_MODE :: *target_type_mode, i.e:

  typedef struct {
    char* name;
    char* mode:
    char  size:
    enum  attribute {is_signed, is_unsigned, is_floating, is_void};
  } target_type_mode;

  where the target defines:

  enum type_mode {
       bool_mode = &(target_type_mode){"bool", "QI", 10, is_unsinged},
       char_mode = &(target_type_mode){"char", "QI", 10, is_unsigned},
       uint_mode = &(target_type_mode){"uint", "HI", 17, is_unsigned},
       ...}

  thereby the MI portion need only do stuff like:
  
  if (TYPE_MODE(...) == char_mode) ...

  -or-
 
  if(TYPE_MODE(...)->size < word_mode->.size) ...

  where when required for target template mapping, mode names may be
  extracted via. TYPE_MODE(...)->mode, thereby the MI remains fully
  abstracted, and never needs to be aware or manipulate physical modes
  as named and utilized by the target it would seem?

> or something like that.  Caching is OK if you cache it the right way
> (with a type, not in a global "this is a pointer" variable).

(but recognize we're likely looking a things from different perspectives)

Re: Compiling GCC with g++: a report

[Richard Kenner]

    And YES I have a port with multiple pointer sizes, and YES the
    customer wanted both sizes supported in a single compilation unit 

This is actually not that uncommon.

    Oh, and sometimes gcc randomly uses pointer_mode instead of Pmode.  I
    haven't a clue why there's a difference, or how badly gcc would break
    if pointer_mode and Pmode were different.  Ok, I lied, I *do* know how
    badly it breaks if they differ; I did try that at one point.

There have been a number of ports where these differ.  Though undoubtably
there are bugs in this support, it does basically work.

Re: Compiling GCC with g++: a report

[DJ Delorie]

>   where then the target may declare class machine_mode
>   target_int_mode ("HI", 16),

This is where we disagree.  The *target* shouldn't map types to modes.
The *MI* should map types to modes.  The target just creates the modes
it supports and describes them.  The MI looks them up by description
(NOT NAME).  If the MI needs a 32 bit unsigned scalar, it does
lookup_mode(32, M_SCALAR, M_UNSIGNED) and uses whatever gets returned.

The fact that you're still trying to assign a "well known name" to a
given type/mode/whatever means you haven't gotten away from the (to
me) fundamental problem, that MI chooses modes according to what
they're *for* instead of according to what they *are*.

>   target_unit_mode // presumably the target's smallest addressable datum.

BImode in most cases, not really useful that way.

>   target_word_mode // presumably the target's largest addressable datum.

BLKmode in all cases.  Also not useful.

>   as there seems no valid reason for the target neutral portion of the
>   compiler to ever refer to XXmode under any circumstance?

Ah, but in your case it *is* aware, it just calls it
"target_word_mode" instead of "SImode" with all the same problems with
assumptions.

>   where correspondingly the MI portions of GCC utilizes the appropriate
>   pointer mode as a function of the type of access being performed,

In my case, the target has to check the attributes of the
function/data to decide what kind of pointer to use.  Again, "MI
assuming" that all function pointers are the same is WRONG.

> - understood, although I honestly don't believe there are that many, and
>   it eliminates any possible confusion, and a host of other #defines.

My current port supports maybe 4-5 hard modes.  There are 19
machine_modes defined.  That's about 4x as many as I really need to
define, and that doesn't even include synthetic vector modes and such.

> - as you've noted, all the information GCC MI portion needs to "do the
>   right thing" already exists scattered in various target definitions,
>   but it hasn't prevented mode assumptions from being made, and XXmodes
>   being hard-coded into the MI sources on occasion; which is the only
>   reason that I thought that by forcing target_TYPE_mode's to be the
>   only thing available, GCC would indirectly be forced to always to the
>   "right thing"?

The less available the better, true.  But target_*_modes don't need to
be available either.  If you use a query/lookup API, MI can assume
there are a *lot* of machine modes (one for each variable, one for
each function, one for each C data type, etc), and let the target map
them to available modes.

	targetm.modes.set_mode_for_decl(decl);

See?  This allows for a custom mode just for the given decl (it might
be a 17 bit ternary value in a DSP), doesn't make assumptions about
available machine modes, and MI can provide a naive default hook for
targets that do "the usual thing".

	if (!TYPE_MODE (TREE_TYPE (decl)))
	  TYPE_MODE (TREE_TYPE (decl)) = find_mode_for_type (TREE_TYPE (decl));
	DECL_MODE (decl) = TYPE_MODE (TREE_TYPE (decl));

or something like that.  Caching is OK if you cache it the right way
(with a type, not in a global "this is a pointer" variable).

Re: Compiling GCC with g++: a report

[Paul Schlie]

> From: DJ Delorie <dj@redhat.com>
>> Might it be more desirable for the compiler's code to only refer to
>> target "type" modes as opposed to "size" modes?
> 
> Not always, see my mail about Pmode.  The problem isn't just how gcc
> refers to machine words, but that gcc assumes their usage is context
> independent or inflexible.  For example, assuming int_mode is the same
> size as your general registers (esp when the target interface has a
> way of asking how big hard regs actually are).

- ?? which was why it seemed to make sense to have the target neutral
  sources refer to "type" modes, i.e. target_int_mode, where then the
  target may declare class machine_mode target_int_mode ("HI", 16),
  to map it in a target specific way to whatever "size" mode it chooses?

  and correspondingly architectural type modes could define more generic
  non-type specific characteristics?

  target_unit_mode // presumably the target's smallest addressable datum.
  target_word_mode // presumably the target's largest addressable datum.

  as there seems no valid reason for the target neutral portion of the
  compiler to ever refer to XXmode under any circumstance?

>> Thereby avoiding the temptation to incorrectly assume that any
>> particular "size" mode, like SImode corresponds to the targets int
>> or int* mode for example?
> 
> I'd like to call my modes "FREDmode" and "WILMAmode" and the MI parts
> shouldn't care at all.

- understood, I think, therefore would expect the target to define
  something like:

  class machine_mode target_code_ptr_mode ("FRED", 24);
  class machine_mode target_rodata_prt_mode ("DINO", 24);
  class machine_mode target_rwdata_ptr_mode ("BARNEY", 16);
  class machine_mode target_stack_ptr_mode ("WILMA", 16);

  where correspondingly the MI portions of GCC utilizes the appropriate
  pointer mode as a function of the type of access being performed,
  where each may mapped as defined by the target to the same or distinct
  modes of it's choosing (where I believe the above four cover the four
  distinct type of semantic accesses GCC seems to need to deal with?)

> patterns.  If they need an "unsigned int" mode, they should ask the
> target what "unsigned int" means (bits), and find a mode that matches
> that description.  I'd like the MI to ask the target "I need to
> multiply these types/modes together, what modes should I promote them
> to, and what mode will the result be?"

- or as above, just where target specific machine_mode instance data is
  defined directly for each target data/pointer/architecture "type" mode?

> I don't want to have to define a huge list of "mode types" when MI can
> figure most of them out from a few BITS_PER_ defines, or from context.

- understood, although I honestly don't believe there are that many, and
  it eliminates any possible confusion, and a host of other #defines.

>> Thereby the compiler's code should only refer to "type" modes:
> 
> Don't type trees already have a machine_mode field?
> I.e. TYPE_MODE(integer_type) ?  I know decls do.
> 
> The target already has a set of bits-per-type settings, we can look up
> modes by size that way and assign them to tree TYPE nodes as needed.
> 
> The target would need a new set of hooks for things like "mode for
> address of foo" or "mode of stack pointer" or "best mode for hard reg".
> 
> The rest of gcc should avoid looking up modes in general, so it's ok
> for a lookup_integer_mode_by_bits() call to be expensive.  Instead,
> the mode should be deduced (or copied) from the available operands.
> Perhaps a fast mode_wider_expanded() lookup for expanding multiplies.

- as you've noted, all the information GCC MI portion needs to "do the
  right thing" already exists scattered in various target definitions,
  but it hasn't prevented mode assumptions from being made, and XXmodes
  being hard-coded into the MI sources on occasion; which is the only
  reason that I thought that by forcing target_TYPE_mode's to be the
  only thing available, GCC would indirectly be forced to always to the
  "right thing"?

Re: Compiling GCC with g++: a report

[DJ Delorie]

> Might it be more desirable for the compiler's code to only refer to
> target "type" modes as opposed to "size" modes?

Not always, see my mail about Pmode.  The problem isn't just how gcc
refers to machine words, but that gcc assumes their usage is context
independent or inflexible.  For example, assuming int_mode is the same
size as your general registers (esp when the target interface has a
way of asking how big hard regs actually are).

> Thereby avoiding the temptation to incorrectly assume that any
> particular "size" mode, like SImode corresponds to the targets int
> or int* mode for example?

I'd like to call my modes "FREDmode" and "WILMAmode" and the MI parts
shouldn't care at all.  Yes, I want to define addfredwilma3 MD
patterns.  If they need an "unsigned int" mode, they should ask the
target what "unsigned int" means (bits), and find a mode that matches
that description.  I'd like the MI to ask the target "I need to
multiply these types/modes together, what modes should I promote them
to, and what mode will the result be?"

I don't want to have to define a huge list of "mode types" when MI can
figure most of them out from a few BITS_PER_ defines, or from context.

> Thereby the compiler's code should only refer to "type" modes:

Don't type trees already have a machine_mode field?
I.e. TYPE_MODE(integer_type) ?  I know decls do.

The target already has a set of bits-per-type settings, we can look up
modes by size that way and assign them to tree TYPE nodes as needed.

The target would need a new set of hooks for things like "mode for
address of foo" or "mode of stack pointer" or "best mode for hard reg".

The rest of gcc should avoid looking up modes in general, so it's ok
for a lookup_integer_mode_by_bits() call to be expensive.  Instead,
the mode should be deduced (or copied) from the available operands.
Perhaps a fast mode_wider_expanded() lookup for expanding multiplies.

Re: Compiling GCC with g++: a report

[Paul Schlie]

> Gabriel Dos Reis <gdr at integrable-solutions dot net>
>| J Delorie <dj at redhat dot com> writes:
>| And the target can do this in tm.c:
>| 
>|       class machine_mode SImode ("SI", 32);
>|       class machine_mode V4QImode ("V4QI", 8, 0, 8, 4);
>| 
>| Then, the MI parts can obtain a mode with certain characteristics,
>| enumerate available modes, and get info about a given mode, but don't
>| have a compile-time identifier for a "well-known named" mode.
>
> I like it.
>
> However, that is orthogonal to changing the plain numeric value "0" to
> the named constant with current machinery, don't you believe?

Might it be more desirable for the compiler's code to only refer to target
"type" modes as opposed to "size" modes? Thereby avoiding the temptation to
incorrectly assume that any particular "size" mode, like SImode corresponds
to the targets int or int* mode for example?

Thereby the compiler's code should only refer to "type" modes:

  target_unit_mode:
  target_word_mode:
  target_vect_mode:

  target_char_mode;
  target_short_mode;
  target_int_mode;
  target_ptr_mode;
  target_long_mode:
  target_long_long_mode
  ...

Where then the target then defines their corresponding "size" modes:

  class machine_mode target_unit_mode ("QI", 8);
  class machine_mode target_word_mode ("HI", 16);
  class machine_mode target_vect_mode ("SI", 32);

  class machine_mode target_char_mode ("QI", 8);
  class machine_mode target_short_mode ("HI",16);
  class machine_mode target_int_mode ("HI", 32);
  class machine_mode target_ptr_mode ("HI", 16);
  class machine_mode target_long_mode ("SI", 32);
  class machine_mode target_long_long_mode ("SI", 32);
  ...