Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <[EMAIL PROTECTED]> writes:

| Mark Mitchell <[EMAIL PROTECTED]> 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: GCC and Floating-Point

[Uros Bizjak]

Hello!

> I'm writing an extensive article about floating-point programming on
> Linux, including a focus on GCC's compilers. This is an outgrowth of
> many debates about topics like -ffast-math and -mfpmath=sse|387, and I
> hope it will prove enlightening for myself and others.

  I would like to point out that for applications that crunch data from real
world (no infinites or nans, where precision is not critical) such as various
simulations, -ffast-math is something that can speed up application a lot.

Regarding i387, -ffast-math does following:

- because NaNs and infinets are not present, fp compares are simplified, as
there is no need for bypases and secondary compares (due to C0 C2 and C3 bits of
FP status word) and cmove instruction can be used in all cases.

- simple builtin functions (sqrt, sin and cos, etc) can be used with hardware
implemented fsqrt, fsin and fcos insn instead of calling library functions.
These can handle arguments up to (something)*2^63, so it is quite enough for
normal apps. This way, a call overhead (saving all FP registers, overhead of
call insn itself) is eliminated, and as an added bonus, sin and cos of the same
argument are combined as fsincos insn.

- not-so-simple (I won't use the word complex here :)) builtin functions (exp,
asin, etc) are expanded on RTL level and CSE is used to eliminate duplicate
calculations.

- floor and ceil functions are implemented as builtin functions and further 
simplified to direct conversion, for example:
(int)floor(double) -> __builtin_lfloor(double).
__builtin_lfloor (and similar builtins) can be implemented directly in i387
using fist(p) insn with appropriate rounding control bits set in control word.

- in addition to this target specific effects, various (otherwise unsafe)
transformations are enabled on middle-level when -ffast-math is used.

  Due to outdated i386 ABI, where all FP parameters are passed on stack, SSE
code does not show all its power when used. When math library function is
called, SSE regs are pushed on stack and called math library function (that is
currently implemented again with i387 insns) pulls these values from stack to
x87 registers. In contrast, x86_64 ABI specifies that FP values are passed in
SSE registers, so they avoid costly SSE reg->stack moves. Until i386 ABI
(together with supporting math functions) is changed to something similar to
x86_64, use of -mfpmath=sse won't show all its power. Another fact is, that x87
intrinsics are currently disabled for -mfpmath=sse, because it was shown that
SSE math libraries (with SSE ABI) are faster for x86_64. Somehow annoying fact
is, that intrinsics are disabled also for i386, where we are still waiting for
ABI to change ;) [Please note that use of SSE intrinsic functions does not rely
on -mfpmath=... settings].

  So, for real-world applications, using i387 with -ffast-math could be
substantially faster than using SSE code. However, the problem lies in math
library headers. These define a lot of inlined asm functions in mathinline.h
header (included when math.h is used). These functions interfear with gcc's
builtins, so -D__NO_MATH_INLINES is needed to fix this problem. The situation is
even worse when SSE code is used. Asm inlines from mathinline.h are implemented
using i387 instructions, so these instructions force parameters to move from SSE
registers to x87 regs (via stack) and the result to move back to SSE reg the
same way. This can be seen when sin(a + 1.0) is compiled with math.h header
included. With -mfpmath=sse, SSE->mem->FP reg moves are needed to satisfy
constraints of inlined sin() code.

  Because SSE->x87 moves are costly, -mfpmath=sse,387 produces unoptimal code.
This option in fact confuses register allocator, and wrong register set is
choosen sometimes. As there is no separate resources for SSE and x87
instructions, the use of -mfpmath=sse,387 is a bit questionable. However, with
-mfpmath=sse, x87 registers could be used for temporary storage in MEM->MEM
moves, they can even do conversions from (double)<->(float) on the fly...

  As an example for this writing, try to benchmark povray with the combination
of following parameters:

-ffast-math
-mpfmath=sse, -mfpmath=387 (and perhaps -mfpmath=387,sse)
-D__NO_MATH_INLINES (this depends on the version of your libc)

Uros.

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Mark Mitchell <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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  operator T* () const
  {
return static_cast (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 <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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]

[EMAIL PROTECTED] (Mark Mitchell)  wrote on 23.05.05 in <[EMAIL PROTECTED]>:

> Zack Weinberg wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> 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: [rfc] mainline slush

[Richard Earnshaw]

On Mon, 2005-05-23 at 17:36, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote:

> > However, in the mean-time I'm stuck.  I can't build my world anymore, so
> > I can't test the compiler
> I understand.  But realize that I'm trying to ultimately save you time
> in the long run -- in the mean time you can pretty easily hack around
> these problems.
> 
> > Maybe we should start a timer on this one.
> I would recommend against.  Every one of these missing calls to compute
> the status bits properly is a latent bug waiting to be exposed.  I'd
> much rather bite the bullet and get them fixed now.  The fact that it's
> affecting a lot of people keep the coals hot on my feet :-)

It's probably too late to do anything about this one this time around,
but isn't this why we have branches?  The whole point of having branch
developments is so that potentially destabilizing chanes (such as
adding/changing major interfaces) can be done without causing this level
of disruption to other developers.

R.

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: i387 control word register definition is missing

[Michael Meissner]

On Mon, May 23, 2005 at 10:25:26AM +0200, Uros Bizjak wrote:
> Hello!
> 
> It looks that i387 control word register definition is missing from register
> definitions for i386 processor. Inside i386.h, we have:
> 
> #define FIXED_REGISTERS   \
> /*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/\
> {  0, 0, 0, 0, 0, 0, 0, 1, 0,  0,  0,  0,  0,  0,  0,  0, \
> /*arg,flags,fpsr,dir,frame*/  \
> 1,1,   1,  1,1,   \
> /*xmm0,xmm1,xmm2,xmm3,xmm4,xmm5,xmm6,xmm7*/   \
>  0,   0,   0,   0,   0,   0,   0,   0,\
> /*mmx0,mmx1,mmx2,mmx3,mmx4,mmx5,mmx6,mmx7*/   \
>  0,   0,   0,   0,   0,   0,   0,   0,\
> /*  r8,  r9, r10, r11, r12, r13, r14, r15*/   \
>  2,   2,   2,   2,   2,   2,   2,   2,\
> /*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/ \
>  2,   2,2,2,2,2,2,2}
> 
> However, there should be another register defined, i387 control word register,
> 'fpcr' (Please look at chapter 11.2.1.2 and 11.2.1.3 in
> http://webster.cs.ucr.edu/AoA/Windows/HTML/RealArithmetic.html). There are two
> instructions in i386.md that actually use fpcr:

Well you really want both the fpcr and the mxcsr registers, since the fpcr
only controls the x87 and the mxcsr controls the xmm registers.  Note, in
adding these registers, you are going to have to go through all of the floating
point patterns to add (use:HI FPCR_REG) and (use:SI MXCSR_REG) to each and
every pattern so that the optimizer can be told not to move a floating point
operation past the setting of the control word.  Then you need to make sure
nothing got broken by adding these USE instructions.  It is certainly doable,
but it is not a simple fix.  I suspect there is then more information needed to
be able to move redudant mode switching operations out of a loop.  If you are
going to tackle it, be sure to have your paperwork in place so that your code
changes can be used.

-- 
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org

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 ,
> and that the initial compiler/runtime's implementation of  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
>  against a library implementing the newer  (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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> writes:

>> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> writes:

| > "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [rfc] mainline slush

[Jeffrey A Law]

On Mon, 2005-05-23 at 11:43 -0700, Mark Mitchell wrote:

> Fair enough.  Would you mind reporting back later today, then?  One 
> possibility is to do the changes that fix our primary languages (C, C++, 
> and Java, since it's easy) and deal with Fortran later.  If we can get 
> the mainline bootstrapping and passing regression tests on primary 
> platforms, but leaving Fortran broken, that might be worthwhile.
I went ahead and checked in the non-controversial stuff that affected
our optimizers.  There's still a few more patches to come, at that
point I'll return to the Fortran front-end.  Ultimately I couldn't
justify holding things up further given that I had patches to get
people working again.

Jeff

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.

Profile-based inliner status?

[Daniel Kegel]

Any news on when profile-based inlining will be merged?

http://gcc.gnu.org/ml/gcc/2005-05/msg00224.html and
http://gcc.gnu.org/wiki/CFG%20Transparent%20Inlining,%20Profile-Guided%20Inlining
have all the official news, but they just say it's not in yet.

I have an app that might benefit from this particular optimization,
and am looking forward to benchmarking it.

Re: Profile-based inliner status?

[Paolo Carlini]

Daniel Kegel wrote:

> Any news on when profile-based inlining will be merged?

Very soon, I would guess:

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02304.html

Paolo.

Uninitialized stack gaps and conservative garbage collection

[Camm Maguire]

Greetings!  GCL is a lisp system that compiles to native object code
via the intermediary of gcc.  It uses a conservative garbage
collection algorithm, which means that it walks the C stack to find
likely objects in use by automatic variables, and holds on to these.
This works quite well in practice.

For very large systems, the likelihood of holding onto objects which
should be collected increases.  In looking into this, it has come to
my attention that regardless of how carefully the C programmer
initializes variables on the stack, gcc will quite commonly allocate
extra space inaccessbile via any C variable.  These 'stack gaps' can
wind up permanently preventing a large portion of user memory from
ever being collected with this algorithm.

Ideally, I'd like to be able to have each C function carefully
initialize a contiguous stack to minimize or eliminate this problem.
Even better would be a gcc switch which would simply zero out each
stack frame at the beginning of each function, though this could be
expensive in terms of performance.  Advice is most appreciated.  I'd
most like the solution to be portable.  I know about
-mpreferred-stack-boundary, but I am unsure if its absense on other
architectures means there is no stack padding there anyway.

Here is my ridiculous kludge which nevertheless works at least here:

void wipe_stack(VOL void *) __attribute__ ((noinline));
void
wipe_stack(VOL void *l) {

#if CSTACK_DIRECTION == -1
   if (l>(void *)&l) bzero((void *)&l,l-(void *)&l);
#else
  l+=sizeof(l);
  if ((void *)&l>l) bzero(l,(void *)&l-l);
#endif

}

object fLfuncall(object fun,...) { 

  va_list ap;
  object *new;
  int i,n = VFUN_NARGS-1;

  if (n>=65) FEerror("arg limit exceeded",0);
  new=ZALLOCA(n*sizeof(*new));

  /* There are 3 unused words on top of esp before and after the
  alloca, as well as extra esp allocation in the alloca itself, even
  though the alloca call is padded to 16 bytes.  So let's wipe the
  crud from the stack... */

  wipe_stack(&n);
  ...

}

Take care,

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [rfc] mainline slush

[Mark Mitchell]

Richard Earnshaw wrote:


It's probably too late to do anything about this one this time around,
but isn't this why we have branches?  The whole point of having branch
developments is so that potentially destabilizing chanes (such as
adding/changing major interfaces) can be done without causing this level
of disruption to other developers.


I agree.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

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: PATCH RFA: Use years for ChangeLog names

[Ian Lance Taylor]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Sun, 6 Mar 2005, Ian Lance Taylor wrote:
> 
> > look at the ChangeLog for the appropriate year.  This is also how some
> > other GNU programs organize their ChangeLog files, including libhava
> > and libstdc++-v3.
> 
> Not consistently, however.  libjava/ChangeLog-1999 has entries from 1998, 
> libjava/ChangeLog-2001 has entries from 2000, libstdc++-v3/ChangeLog-2000 
> has entries from 1998 and 1999.  Perhaps a followup patch could also fix 
> those?

For the record, this is now done.

Ian

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 <[EMAIL PROTECTED]> 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 03:03 +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <[EMAIL PROTECTED]> 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

[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

[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 <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) 

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

[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

[Ian Lance Taylor]

Zack Weinberg <[EMAIL PROTECTED]> 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 < $f.new
  mv $f.new $f
done

Ian

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Zack Weinberg <[EMAIL PROTECTED]> writes:

| On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
| > Zack Weinberg <[EMAIL PROTECTED]> 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

gcc-3.4-20050524 is now available

[gccadmin]

Snapshot gcc-3.4-20050524 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050524/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050524 

You'll find:

gcc-3.4-20050524.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20050524.tar.bz2 C front end and core compiler

gcc-ada-3.4-20050524.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20050524.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20050524.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20050524.tar.bz2 Java front end and runtime

gcc-objc-3.4-20050524.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20050524.tar.bz2The GCC testsuite

Diffs from 3.4-20050520 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

Russ Allbery <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| > Zack Weinberg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 -  1.15
+++ genmodes.c  25 May 2005 02:02:14 -
@@ -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  [EMAIL PROTECTED]

Re: Compiling GCC with g++: a report

[Gabriel Dos Reis]

DJ Delorie <[EMAIL PROTECTED]> 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

[Paul Schlie]

> Gabriel Dos Reis 
>| J Delorie  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);
  ...

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

[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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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

[Paul Schlie]

> From: DJ Delorie <[EMAIL PROTECTED]>
>> 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

[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