Re: Time schedule?

Re: Time schedule?

[Richard Kenner]

    *** stor-layout.c.orig	Thu Mar 11 14:56:20 1999
    --- stor-layout.c	Mon Oct 25 00:32:45 1999
    ***************
    *** 65,70 ****
    --- 65,75 ----
      
      int immediate_size_expand;
  
    + /* Nonzero means that the size of a type may vary
    +    within one function context.  */
    + 
    + int size_volatile = 0;
    + 

I must say I don't much like this.  It adds "state", which is already
a tricky thing.  Is the intent here that *all* types have their sizes vary
or just *some*, depending on the setting of this switch?

If the former, I dislike it less, but would prefer something that's clearly
called at startup to set this.

If the latter, I'd prefer to see a flag in the tree.

We already have a number of different cases of handling of type sizes:
the top-level case, when it's done using a SAVE_EXPR (the present
case) and when it's determined from data within an object of the type
(for Ada discriminated records and unconstrained arrays).  I have no
problem with adding a fourth mechanism, but would prefer to see it
done in a more consistent manner.  GCC could also handle internally
the case of a variable sized top-level object, which is currently only
done by front ends (perhaps just Ada).

Re: Time schedule?

[Peter Gerwinski]

Richard Kenner wrote:
>     + /* Nonzero means that the size of a type may vary
>     +    within one function context.  */
>     + 
>     + int size_volatile = 0;
>     + 
> 
> I must say I don't much like this.

Nor do I.

> It adds "state", which is already
> a tricky thing.  Is the intent here that *all* types have their sizes vary
> or just *some*, depending on the setting of this switch?
> [...]
> If the latter, I'd prefer to see a flag in the tree.

It's the latter.  But there are already too few language
specific flags left ...

> [...] and when it's determined from data within an object of the type
> (for Ada discriminated records and unconstrained arrays).

That's exactly what is needed here.  How is this mechanism
intended to be used?  I did not find any documentation on this.

> GCC could also handle internally
> the case of a variable sized top-level object, which is currently only
> done by front ends (perhaps just Ada).

Pascal would be a second one.

    Peter

Re: Time schedule?

[Richard Kenner]

    *** stor-layout.c.orig	Thu Mar 11 14:56:20 1999
    --- stor-layout.c	Mon Oct 25 00:32:45 1999
    ***************
    *** 65,70 ****
    --- 65,75 ----
      
      int immediate_size_expand;
  
    + /* Nonzero means that the size of a type may vary
    +    within one function context.  */
    + 
    + int size_volatile = 0;
    + 

I must say I don't much like this.  It adds "state", which is already
a tricky thing.  Is the intent here that *all* types have their sizes vary
or just *some*, depending on the setting of this switch?

If the former, I dislike it less, but would prefer something that's clearly
called at startup to set this.

If the latter, I'd prefer to see a flag in the tree.

We already have a number of different cases of handling of type sizes:
the top-level case, when it's done using a SAVE_EXPR (the present
case) and when it's determined from data within an object of the type
(for Ada discriminated records and unconstrained arrays).  I have no
problem with adding a fourth mechanism, but would prefer to see it
done in a more consistent manner.  GCC could also handle internally
the case of a variable sized top-level object, which is currently only
done by front ends (perhaps just Ada).

Re: Time schedule?

[Peter Gerwinski]

Richard Kenner wrote:
>     + /* Nonzero means that the size of a type may vary
>     +    within one function context.  */
>     + 
>     + int size_volatile = 0;
>     + 
> 
> I must say I don't much like this.

Nor do I.

> It adds "state", which is already
> a tricky thing.  Is the intent here that *all* types have their sizes vary
> or just *some*, depending on the setting of this switch?
> [...]
> If the latter, I'd prefer to see a flag in the tree.

It's the latter.  But there are already too few language
specific flags left ...

> [...] and when it's determined from data within an object of the type
> (for Ada discriminated records and unconstrained arrays).

That's exactly what is needed here.  How is this mechanism
intended to be used?  I did not find any documentation on this.

> GCC could also handle internally
> the case of a variable sized top-level object, which is currently only
> done by front ends (perhaps just Ada).

Pascal would be a second one.

    Peter

Re: Time schedule?

[Peter Gerwinski]

Joe Buck wrote:
> 
> Chill and Pascal are the only set users, right?  It would be great if
> the front-end maintainers could agree on a common implementation.

Per already gave his okay for using the Pascal implementation in
the future which is more efficient.  However he told us that he
will not hack Chill to adapt it.

> Ideally, you and Per (or whoever
> takes over for him) could agree on endianness and word size of sets.

In fact I can adapt Pascal to use bytes instead of words within
a few seconds (which means a loss of efficiency).  Bit endianess
would be more work.  Giving up the alignment would cause even
more work and would be a clear step backwards.

BTW, as far as I can tell from what I have read from the Chill
run time library, that code is broken anyway and should be
fixed.  (See my recent postings on this topic.)

> Then this patch would go away.

It would only go away if I fully adapt Pascal to the current
Chill implementation of sets.  While this would be possible
I do not think that it should be done.

As long as nobody is willing to adapt Chill to a new set format
I'd consider my current approach the most reasonable thing.
(BTW it's just a consequent continuation of what I already found
in `stor-layout.c' (int set_alignment).)

> > [#ifdef GPC ...]
> 
> From my point of view, the reason that it's wrong is that it's a
> fundamental violation of the architecture of gcc, which consists of
> a language-independent back end and language-dependent front ends.
> Also, #ifdefs are the enemy of maintainable code, you want to minimize
> the number of them.

Yes, of course.

> This kind of thing (#ifdef GPC) may be OK at an early stage of
> development, but once we're ready to integrate the new front end we need
> to get rid of it.  [...]

No problem - that's exactly how I understood Jeff. :)

> Please don't give up.  I think that once Pascal is integrated into the
> tree, development to fix the remaining problems will accelerate, because
> it will be much easier for more people to get and work on the code.

This is exactly the reason why I think that it is a good idea to
integrate GPC into GCC.

    Peter

Re: Time schedule?

[Joe Buck]

> Per already gave his okay for using the Pascal implementation in
> the future which is more efficient.  However he told us that he
> will not hack Chill to adapt it.

(I think Per said he was giving up on Chill work altogether).
So then we need to find a volunteer to munge Chill to work like Pascal?

> In fact I can adapt Pascal to use bytes instead of words within
> a few seconds (which means a loss of efficiency).  Bit endianess
> would be more work.  Giving up the alignment would cause even
> more work and would be a clear step backwards.

It would seem that a word-based implementation is better, so you probably
should stick with it.

Re: Time schedule?

[Peter Gerwinski]

Marc Lehmann wrote:
> How long do you
> think will it take to package gpc into a cvs-able form?

What's that - a cvs-able form - in contrast to the existing tarball
that contains a subdirectory `p' to the `gcc' directory?

> If all issues with
> the backend are clear and gpc works out of the box (more or less) including
> it into cvs _might_ be the way to go. There is no feature freeze yet.

Okay, so I will just go on and submit patches (concerning the set
code and one feature in `variable_size()' (file `stor-layout.c')
that will allow for compiling GPC with the GCC backend without
further patches.

The bug fix for ABS_EXPRs of complex numbers is another one of
these patches needed by GPC.  Shall I re-submit it?

(Of course I already submitted a copyright assignment for past
and future changes to GCC to the FSF.)

    Peter

-- 
http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422
keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

Re: Time schedule?

[Joe Buck]

peter@gerwinski.de writes:

>   >   * Sets.  I introduced new variables `set_word_size' and
>   >     `set_words_big_endian' and made `expr.c' and `store-layout.c'
>   >     use them.  With their default values, Chill sets are
>   >     constructed; the Pascal frontend overrides them to obtain
>   >     Pascal sets.

> Let's hold off this one and go after the size_volatile stuff (which I
> understand a little better since we've already discussed it in the past.

Chill and Pascal are the only set users, right?  It would be great if
the front-end maintainers could agree on a common implementation.
While your design doesn't seem *that* bad, it seems to mean that
Chill and Pascal can't interoperate (which in this particular case
isn't so bad: how many people will use Chill and Pascal and try to
pass a set from one to the other?).  Ideally, you and Per (or whoever
takes over for him) could agree on endianness and word size of sets.
Then this patch would go away.

>   > This has never been a problem.  All GPC-specific patches have
>   > always been surrounded by `#ifdef GPC ... #endif'.  This is done
>   > even now where the patches only affect frontends that explicitly
>   > override the default values of some global variables.

> But this is something we absolutely do not want to do.  This kind of stuff
> is absolutely wrong.  

Jeff, while of course I agree with you 100%, such statements, I think,
tend to intimidate new developers who don't have your experience, because
they look arbitrary.  I think it would be helpful to explain a bit
why something is wrong, especially for mistakes people tend to make
repeatedly.  Otherwise, for people who don't get it, you just look
stubborn and hard to work with.

From my point of view, the reason that it's wrong is that it's a
fundamental violation of the architecture of gcc, which consists of
a language-independent back end and language-dependent front ends.
Also, #ifdefs are the enemy of maintainable code, you want to minimize
the number of them.

This kind of thing (#ifdef GPC) may be OK at an early stage of
development, but once we're ready to integrate the new front end we need
to get rid of it.  In some cases, the back end needs something for the new
language that wasn't there before.  Then there needs to be agreement.

Please don't give up.  I think that once Pascal is integrated into the
tree, development to fix the remaining problems will accelerate, because
it will be much easier for more people to get and work on the code.

Re: Time schedule?

[Peter Gerwinski]

Marc Lehmann wrote:
> If gpc does not break the rest of the tree (including gpc does not require
> applying random patches to the backend), then I'd say it's in a form
> suitable to get included. [...]

There are only two sets of patches left:

  * Sets.  I introduced new variables `set_word_size' and
    `set_words_big_endian' and made `expr.c' and `store-layout.c'
    use them.  With their default values, Chill sets are
    constructed; the Pascal frontend overrides them to obtain
    Pascal sets.

    If there is any chance to get this patch into the main GCC
    source, I can submit it to an address of your choice once
    I finished all tests with this.

  * `size_volatile' types.  These are types whose size must be
    re-calculated each time a variable of that type is used, so
    `variable_size()' (in `store-layout.c') must not construct a
    SAVE_EXPR for it.  Our current patch introduces a global
    variable `size_volatile' to inform `variable_size()' about
    this.  Better ideas welcome.

Since the other patches I suggested so far have been rejected or
ignored, we have constructed workarounds in the frontend for all
of them, so they are not needed any more.  This includes the bug
fix for ABS_EXPR with complex operands (for which I still wonder
how the code could have ever been working for any language).

> So this means there are principal problems with gpc.

I admit that our list of known bugs is long, but we are only two
active GPC hackers and simply do not have the manpower to fix
the bugs quickly.  If this is a principal problem, then, well,
then I do not see any chance to get GPC integrated into GCC in
time for gcc-3.0 - or even after that.  :-(

> If (compiling) stability is a problem we could require a --enable-gpc at
> configure time to attempt to build it.

This has never been a problem.  All GPC-specific patches have
always been surrounded by `#ifdef GPC ... #endif'.  This is done
even now where the patches only affect frontends that explicitly
override the default values of some global variables.

> It appears to me that we have to evaluate gpc again in the near future..

As soon as I have finished all tests with the new set
code, I will release a new alpha GPC.  If it isn't hopeless
anyway, I can keep you informed when this happens.

Greetings,

    Peter

Re: Time schedule?

[Richard Kenner]

    I already studied this a long time ago but did not understand how to
    use it.  The explanations seem to have been improved since those
    times, but I still do not see a place where I can provide the actual
    expression.

You put the expression in a TYPE_SIZE, DECL_SIZE, DECL_FIELD_BITPOS,
TYPE_MIN_VALUE or TYPE_MAX_VALUE.

    Anyway, why isn't it done with the other tree nodes?  In Pascal we use
    just a normal TYPE_SIZE slot in the RECORD_TYPE, but this TYPE_SIZE
    does contain something non-constant that contains the value of the
    variable in question itself.  I do not see the place where the
    PLACEHOLDER_EXPR should be introduced.

Well, I don't know Pascal well and if you don't know Ada well, it's
sort of hard to communicate, but let me use an array example, which is
easier to understand without knowing the language.

Ada has arrays that contains both bounds and data.  The bounds are
both the lower and upper bounds.  So if you want to compute A(I), you
need to subtract the lower bound of A.  You get that by looking
A.BOUNDS.LB0.  So TYPE_MIN_VALUE of the the index type contains an
expression that is a function of a COMPONENT_REF whose operand first
operand is PLACEHOLDER_EXPR of the same type as A.

The record case works similarly: you can have a record where the
position of an object depends on the value of data in the field of the
record.  I don't see how you can express this in the tree without
these new codes because there's no way of saying "the current object
of type FOO": that's what PLACEHOLDER_EXPR is for.

Re: Time schedule?

[Per Bothner]

Joe Buck <jbuck@synopsys.COM> writes:

> (I think Per said he was giving up on Chill work altogether).
> So then we need to find a volunteer to munge Chill to work like Pascal?

Basically.  I haven't done any Chill work (except providing advice)
for years;  I can't myself working on it unless I get paid (quite
well) for it; though at this point, time is the real constraint.

I don't know if anyone at Cygnus is still working on Chill, though I
heard a rumour Chill support is still of interest at Cygnus (i.e. to
at least one Cygnus customer).  I believe David Brolley is the last
person to work on Chill.

I am of course always happy to proffer my advice and opinions ...

> > In fact I can adapt Pascal to use bytes instead of words within
> > a few seconds (which means a loss of efficiency).  Bit endianess
> > would be more work.  Giving up the alignment would cause even
> > more work and would be a clear step backwards.
> 
> It would seem that a word-based implementation is better, so you probably
> should stick with it.

Yes, but we somebody need to change or replace the Chill run-time
to match the compiler changes.  I mentioned my bitprims library;
(see http://www.bothner.com/~per/software/#bitprims );  another
option may be to modify the Pascal library.

One thing confusing is Chill's terminology.  Chill has:
(a) bitstrings.  These are like character strings, but each element
is a single bit (a boolean).  These are basically packed arrays,
indexed from 0 to (length-1).
(b) "powersets" correspond to Pascal "sets".  (Chill "sets" are
basically enumerated types.)  These are mappings from a dicrete
type (or sub-range) to boolean.  The lower index need not be 0.

Traditionally, GNU Chill have used the same low-level representation
(packed bitstrings) for both.  That should continue.

Ideally, someone needs to check that Chill support in Gdb doesn't
break either, though I don't think that needs to be a pre-requisite.
(I.e. I think we can fix the compiler and break Gdb;  if this
cuases problems fr oneone, they can either fix it, or pay someone
to fix it, or stick with old releases.)

There is also a question whether Cygnus's Chill customer still needs
(and is willing to pay for) binary compatibility with the old code; if
so, that needs to be maintained.  However, backwards compatibility
support need not be in the public Gcc codebase.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Time schedule?

[Richard Kenner]

    It's the latter.  But there are already too few language
    specific flags left ...

I meant a language *independent* flag.

    > [...] and when it's determined from data within an object of the type
    > (for Ada discriminated records and unconstrained arrays).

    That's exactly what is needed here.  How is this mechanism
    intended to be used?  I did not find any documentation on this.

See PLACEHOLDER_EXPR and WITH_RECORD_EXPR in tree.def.

Re: Time schedule?

[Jeffrey A Law]

  In message < 199910242217.PAA21197@atrus.synopsys.com >you write:
  > Jeff, while of course I agree with you 100%, such statements, I think,
  > tend to intimidate new developers who don't have your experience, because
  > they look arbitrary.  I think it would be helpful to explain a bit
  > why something is wrong, especially for mistakes people tend to make
  > repeatedly.  Otherwise, for people who don't get it, you just look
  > stubborn and hard to work with.
But this is something I've explained to Peter in the past.

jeff

Re: Time schedule?

[Marc Lehmann]

On Sun, Oct 17, 1999 at 10:05:37PM +0200, Peter Gerwinski <peter@gerwinski.de> wrote:
> we are thinking about our release schedule for GPC.  Since we
> are approaching full integration with GCC (i.e. compilation
> without a patch to the backend), we'd like to know a rough plan
> when the next version of gcc-2.x and/or gcc-3.x is going to be
> released.

At the moment we can't give you any time schedule, or any tentative dates,
as Jeff is not able to do the release work for the next release.

I don't think we will directly go to 3.0 (but who knows). How long do you
think will it take to package gpc into a cvs-able form? If all issues with
the backend are clear and gpc works out of the box (more or less) including
it into cvs _might_ be the way to go. There is no feature freeze yet.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Kaveh R. Ghazi]

 > From: Peter Gerwinski <peter@gerwinski.de>
 > 
 > This is exactly the reason why I think that it is a good idea to
 > integrate GPC into GCC.
 >     Peter

Does the Pascal front-end compile cleanly with -W -Wall?  How about
-Wstrict-prototypes -Wwrite-strings?

If these are something you can reasonably do, I would greatly
appreciate it.  I've worked hard to get the current sources as close
to this as possible.

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

Re: Time schedule?

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:

| What's the word on releasing with the (slowly but surely) developing
| libstdc++ library? I would think that integration with this would
| justify a full version release by itself considering the impact it
| will have on deployed C++ applications. I was hoping it would be part
| of the 3.0 release but I don't see libstdc++ being ready before third
| qtr 2000 given its current pace (note - this is not me whining or
| complaining, just an observation). Has any thought been put into goals
| for a 4.0 release?

Well, the sooner you help the sooner libstdc++-v3 got finished.


BTW, libstdc++-v3, as it is, randomly crashes the compiler.  The last
time I tried to build it the compiler got into infinite loop (try
CXXFLAGS='-fsquangle -fhonor-std -fnew-exceptions -O3 -fnew-abi').
Also, the library needs some support from the compiler, such as 

	http://www.cantrip.org/cheaders.html

-- Gaby

Re: Time schedule?

[Benjamin Scherrey]

What's the word on releasing with the (slowly but surely) developing
libstdc++ library? I would think that integration with this would
justify a full version release by itself considering the impact it
will have on deployed C++ applications. I was hoping it would be part
of the 3.0 release but I don't see libstdc++ being ready before third
qtr 2000 given its current pace (note - this is not me whining or
complaining, just an observation). Has any thought been put into goals
for a 4.0 release?

	regards,

		Ben Scherrey

Marc Lehmann wrote:
> At the moment we can't give you any time schedule, or any tentative dates,
> as Jeff is not able to do the release work for the next release.
> 
> I don't think we will directly go to 3.0 (but who knows). How long do you
> think will it take to package gpc into a cvs-able form? If all issues with
> the backend are clear and gpc works out of the box (more or less) including
> it into cvs _might_ be the way to go. There is no feature freeze yet.

Re: Time schedule?

[Joe Buck]

> FWIW - I cannot ethically release code under any GNU license that
> I have ever read.

Please, let's keep discussion of software licensing issues off of this
list.  Anyone wanting to debate licenses and ethics, please go to
gnu.misc.discuss.

Re: Time schedule?

[Peter Gerwinski]

Jeffrey A. Law wrote:
>   >   * `size_volatile' types.  These are types whose size must be
>   >     re-calculated each time a variable of that type is used, [...]
> Let's go for this one first.  I'll also dig out the old discussion from the
> archives to refresh my memory of the issues.

Okay.  The patch to `stor-layout.c' is relatively small; I am
appending it below.

>   > This has never been a problem.  All GPC-specific patches have
>   > always been surrounded by `#ifdef GPC ... #endif'.  This is done
>   > even now where the patches only affect frontends that explicitly
>   > override the default values of some global variables.
> But this is something we absolutely do not want to do.  This kind of stuff
> is absolutely wrong.  

Indeed.  As I said, the current patches require the frontend to
override the default values of some global variables to become
active, so they cannot affect the behaviour of the GCC backend
with other frontends.

    Peter

8< ---- `size_volatile' patch to `expr.c' ----------------------

*** stor-layout.c.orig	Thu Mar 11 14:56:20 1999
--- stor-layout.c	Mon Oct 25 00:32:45 1999
***************
*** 65,70 ****
--- 65,75 ----
  
  int immediate_size_expand;
  
+ /* Nonzero means that the size of a type may vary
+    within one function context.  */
+ 
+ int size_volatile = 0;
+ 
  tree
  get_pending_sizes ()
  {
***************
*** 102,108 ****
        || global_bindings_p () < 0 || contains_placeholder_p (size))
      return size;
  
!   size = save_expr (size);
  
    if (global_bindings_p ())
      {
--- 107,114 ----
        || global_bindings_p () < 0 || contains_placeholder_p (size))
      return size;
  
!   if (! size_volatile)
!     size = save_expr (size);
  
    if (global_bindings_p ())
      {
***************
*** 119,125 ****
         Also, we would like to pass const0_rtx here, but don't have it.  */
      expand_expr (size, expand_expr (integer_zero_node, NULL_PTR, VOIDmode, 0),
  		 VOIDmode, 0);
!   else
      pending_sizes = tree_cons (NULL_TREE, size, pending_sizes);
  
    return size;
--- 125,131 ----
         Also, we would like to pass const0_rtx here, but don't have it.  */
      expand_expr (size, expand_expr (integer_zero_node, NULL_PTR, VOIDmode, 0),
  		 VOIDmode, 0);
!   else if (! size_volatile)
      pending_sizes = tree_cons (NULL_TREE, size, pending_sizes);
  
    return size;

Re: Time schedule?

[Joe Buck]

> What's the word on releasing with the (slowly but surely) developing
> libstdc++ library?

The original idea was that it would be part of 3.0, with the hope that
we would then have a more or less final C++ ABI.

> I would think that integration with this would
> justify a full version release by itself considering the impact it
> will have on deployed C++ applications. I was hoping it would be part
> of the 3.0 release but I don't see libstdc++ being ready before third
> qtr 2000 given its current pace (note - this is not me whining or
> complaining, just an observation).

... which means that the next major gcc release will probably be 2.96.
There's no set schedule for 3.0, as there isn't a marketing department
in charge.

Re: Time schedule?

[David Starner]

On Mon, Oct 18, 1999 at 08:43:52PM -0500, Benjamin Scherrey wrote:
> What's the word on releasing with the (slowly but surely) developing
> libstdc++ library? I would think that integration with this would
> justify a full version release by itself considering the impact it
> will have on deployed C++ applications. 

Major version changes on GCC are reserved for massive changes.
OTOH, the libstdc++ 2 -> 3 change-over will probably have less 
effect on C++ applications than the libg++ -> libstdc++ change
over did, and that was 2.7 -> 2.8/egcs. 

At this point no one know what GCC 4.0 will look like, except that
it will probably be as far from GCC 3.0 as GCC 3.0 was from GCC 2.0.

David Starner - dstarner98@aasaa.ofe.org

Re: Time schedule?

[Peter Gerwinski]

Richard Kenner wrote:
>     It's the latter.  But there are already too few language
>     specific flags left ...
> 
> I meant a language *independent* flag.

No objections - as long as enough language *dependend* flags
remain. ;-)

>     That's exactly what is needed here.  How is this mechanism
>     intended to be used?  I did not find any documentation on this.
> 
> See PLACEHOLDER_EXPR and WITH_RECORD_EXPR in tree.def.

I already studied this a long time ago but did not understand
how to use it.  The explanations seem to have been improved
since those times, but I still do not see a place where I can
provide the actual expression.

Anyway, why isn't it done with the other tree nodes?  In Pascal
we use just a normal TYPE_SIZE slot in the RECORD_TYPE, but this
TYPE_SIZE does contain something non-constant that contains the
value of the variable in question itself.  I do not see the
place where the PLACEHOLDER_EXPR should be introduced.

    Peter

Re: Time schedule?

[Jeffrey A Law]

  In message < 199910190111.SAA23672@kankakee.wrs.com >you write:

  > I disagree.  I think we should include it in, now, regardless of the
  > state it is in.
I strongly disagree wrong with that attitude.

There is a significant difference between dropping in something that is
basically OK and just needs polishing around the edges and dropping in
something that needs major revamping before it's in the right neighborhood.

We do not know where the gpc code sits at the current time.  Last I looked
there were some major problems, particularly in how it interfaced into
expr.c and the debugging code that were totally unacceptable.  Worse yet,
nobody from the gpc camp even knew why the changes were needed (or even if
they were still needed).

I'm not trying to slam the gpc folks, but that's not a hunk of code we're
likely to accept unless it has been significantly improved.  I sincerely
hope it has because I want to see GCC incorporate gpc in the hope that it'll
have the same kind of positive effect incorporating g77 had.

  > Once it is in, people can contribute fixes for
  > whatever brokenness is left, if and as they care.  Without it in, out
  > of sight, out of mind.  (I'm assuming it at least doesn't break the
  > builds.)
I'm more than aware of the advantages that having code in the tree provides,
but the code has to meet a certain level of correctness before it will go in.
No ifs, ands or buts about it.  This is not "throw it over the wall and watch
developers scatter" development, nor is it "wait until it is 100% perfect"
development.  There's a point in-between that we're shooting for.

Dropping it in before it hits that level of correctness is just going to make
everyone life miserable, waiting too late would make gpc suffer.  Finding the
right time to contribute can be difficult, but it's really necessary for the
health of both projects.


jeff

Re: Time schedule?

[Marc Lehmann]

On Mon, Oct 18, 1999 at 08:06:42PM -0600, Jeffrey A Law <law@cygnus.com> wrote:
>   In message < 199910190111.SAA23672@kankakee.wrs.com >you write:
> 
>   > I disagree.  I think we should include it in, now, regardless of the
>   > state it is in.
> I strongly disagree wrong with that attitude.

I don't. While I agree that including something just because it exists is not
viable, the real question is wether gpc is in a form suitable for inclusion.

If gpc does not break the rest of the tree (including gpc does not require
applying random patches to the backend), then I'd say it's in a form
suitable to get included. (And since there is wide demand for it it is
also "economically useful").

> basically OK and just needs polishing around the edges and dropping in
> something that needs major revamping before it's in the right neighborhood.

So this means there are principal problems with gpc. In this case we really
need to clarify what these problems are, and what needs to be done on the gpc
side to fix it. We have been asked for this.

> We do not know where the gpc code sits at the current time.  Last I looked
> there were some major problems, particularly in how it interfaced into

Last time it also required patches to the backend. We were told that it does not
need these patches anymore, so what would inhibit us from including it in cvs
(and only there).

If (compiling) stability is a problem we could require a --enable-gpc at
configure time to attempt to build it.

> Dropping it in before it hits that level of correctness is just going to make
> everyone life miserable, waiting too late would make gpc suffer.  Finding the
> right time to contribute can be difficult, but it's really necessary for the
> health of both projects.

It appears to me that we have to evaluate gpc again in the near future..

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Marc Lehmann]

On Sun, Oct 24, 1999 at 01:54:41PM +0200, Peter Gerwinski <peter@gerwinski.de> wrote:
> > So this means there are principal problems with gpc.
> 
> I admit that our list of known bugs is long, but we are only two
> active GPC hackers and simply do not have the manpower to fix

No, "principal problems" means "it interacts badly with other frontends".
Wether gpc itself has bugs is of no concern, only wether this affects the
backend or the other frontends.

A "principal" problem would be if gpc required a patch that made the
backend incompatible to other frontends.

> This has never been a problem.  All GPC-specific patches have
> always been surrounded by `#ifdef GPC ... #endif'.  This is done

We either have these patches in the backend _always_ or we haven't. The
idea is that the patches that are still required for gpc can be
implemented in an frontend-independent way, i.e. the other frontends must
work with the patches installed (and not #ifdef'ed out).

Wether global flags to affect backend behaviour is the best way to
interface is another question.

> As soon as I have finished all tests with the new set
> code, I will release a new alpha GPC.  If it isn't hopeless
> anyway, I can keep you informed when this happens.

It certainly isn't hopeless! We need to apply (and possibly fix) the
patches required for gpc integration. This should have no effect on other
frontends.

Then we should evaluate the gpc frontend itself, add it into the cvs tree
and decide wether it is portable enough to be built by default (I think
so).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Benjamin Scherrey]

I figured I'd get at least one message like this which is why I tried
to make it clear that I wasn't complaining. FWIW - I cannot ethically
release code under any GNU license that I have ever read. I'd be happy
to help an open source non-GNU implementation of the C++ standard lib
that wasn't compiler specific and stressed platform independence. I
don't expect that to happen any time remotely soon and wish the
current team well with their efforts.

	regards,

		Ben Scherrey

Gabriel Dos_Reis wrote:
> 
> Benjamin Scherrey <scherrey@switchco.com> writes:
> 
> | What's the word on releasing with the (slowly but surely) developing
> | libstdc++ library? 
<snip>

> Well, the sooner you help the sooner libstdc++-v3 got finished.

Re: Time schedule?

[Marc Lehmann]

On Tue, Oct 19, 1999 at 12:27:37AM +0200, Peter Gerwinski <peter@gerwinski.de> wrote:
> Marc Lehmann wrote:
> > How long do you
> > think will it take to package gpc into a cvs-able form?
> 
> What's that - a cvs-able form - in contrast to the existing tarball
> that contains a subdirectory `p' to the `gcc' directory?

Difficult to define ;) It's a tarball that can be integrated into cvs
which contains the p subdir.

In addition:

- it should not break anything else (should, bugs or just bugs)
- it must have an active maintainer who cares for the bugs
  and the compiler bug reports (i.e. gcc-bugs).

If this is ok (it should) then I'd say we should include gnu pascal in
cvs, as soon as the remaining issues are resolved (see below).

However, wether gpc will be in the next release, or wether this happens
before the next release, is in the hands of the release manager ;)
Stability is most important, but I would very much like it to have it in
the 3.0 release.

> Okay, so I will just go on and submit patches (concerning the set
> code and one feature in `variable_size()' (file `stor-layout.c')
> that will allow for compiling GPC with the GCC backend without
> further patches.

Yes, thats the goal. First all incompatibilities between the back- and the
frontend have to be resolved (don't underestimate this, some people might
disagree on how to fix some things).

> The bug fix for ABS_EXPRs of complex numbers is another one of
> these patches needed by GPC.  Shall I re-submit it?

I think you submitted it recently enough.

> (Of course I already submitted a copyright assignment for past
> and future changes to GCC to the FSF.)

Good, one problem less ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Benjamin Scherrey]

I agree that, technically, libg++ -> libstdc++ had a higher impact on
deployed code than the new libstdc++ will. That said, I feel it
deserved its own version release as well but that was back when the
egcs split was still relatively young and not the standard release of
gcc. My biggest caveat, however, is that there simply wasn't as much
C++ code actually deployed then as there is now. The C++ user base
with g++ is probably an order of magnitude larger than it was then and
compliance to the ANSI spec is a major issue that the libstdc++
release will pretty much bring the most egregious variances under
wraps. So... the impact to the development community will be far
larger in this case. A point release will be very confusing to
developers who don't track the compiler's development closely. They're
used to seeing bug fixes and minor improvements for those kind of
things, not expecting to have to relink all deployed apps! Perhaps we
can call it GCC-2000? :-)

	regards,

		Ben Scherrey

David Starner wrote:
> Major version changes on GCC are reserved for massive changes.
> OTOH, the libstdc++ 2 -> 3 change-over will probably have less
> effect on C++ applications than the libg++ -> libstdc++ change
> over did, and that was 2.7 -> 2.8/egcs.

Re: Time schedule?

[Jeffrey A Law]

  In message < 19991024135441.C230@esmeralda.gerwinski.de >you write:
  > There are only two sets of patches left:
Oh.  Good.  Sounds like you've made great progress.

  >   * Sets.  I introduced new variables `set_word_size' and
  >     `set_words_big_endian' and made `expr.c' and `store-layout.c'
  >     use them.  With their default values, Chill sets are
  >     constructed; the Pascal frontend overrides them to obtain
  >     Pascal sets.
  > 
  >     If there is any chance to get this patch into the main GCC
  >     source, I can submit it to an address of your choice once
  >     I finished all tests with this.
Let's hold off this one and go after the size_volatile stuff (which I
understand a little better since we've already discussed it in the past.


  >   * `size_volatile' types.  These are types whose size must be
  >     re-calculated each time a variable of that type is used, so
  >     `variable_size()' (in `store-layout.c') must not construct a
  >     SAVE_EXPR for it.  Our current patch introduces a global
  >     variable `size_volatile' to inform `variable_size()' about
  >     this.  Better ideas welcome.
Let's go for this one first.  I'll also dig out the old discussion from the
archives to refresh my memory of the issues.


  > This has never been a problem.  All GPC-specific patches have
  > always been surrounded by `#ifdef GPC ... #endif'.  This is done
  > even now where the patches only affect frontends that explicitly
  > override the default values of some global variables.
But this is something we absolutely do not want to do.  This kind of stuff
is absolutely wrong.  

jeff

Re: Time schedule?

[Mike Stump]

> Date: Tue, 19 Oct 1999 02:17:49 +0200
> From: Marc Lehmann <pcg@opengroup.org>
> To: gcc@gcc.gnu.org

> If this is ok (it should) then I'd say we should include gnu pascal in
> cvs, as soon as the remaining issues are resolved (see below).

I disagree.  I think we should include it in, now, regardless of the
state it is in.  Once it is in, people can contribute fixes for
whatever brokenness is left, if and as they care.  Without it in, out
of sight, out of mind.  (I'm assuming it at least doesn't break the
builds.)

Time schedule?

[Peter Gerwinski]

Hello,

we are thinking about our release schedule for GPC.  Since we
are approaching full integration with GCC (i.e. compilation
without a patch to the backend), we'd like to know a rough plan
when the next version of gcc-2.x and/or gcc-3.x is going to be
released.

Thanks,

    Peter

-- 
http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422
keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

Re: Time schedule?

[Kaveh R. Ghazi]

 > From: Peter Gerwinski <peter@gerwinski.de>
 > 
 > This is exactly the reason why I think that it is a good idea to
 > integrate GPC into GCC.
 >     Peter

Does the Pascal front-end compile cleanly with -W -Wall?  How about
-Wstrict-prototypes -Wwrite-strings?

If these are something you can reasonably do, I would greatly
appreciate it.  I've worked hard to get the current sources as close
to this as possible.

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

Re: Time schedule?

[Per Bothner]

Joe Buck <jbuck@synopsys.COM> writes:

> (I think Per said he was giving up on Chill work altogether).
> So then we need to find a volunteer to munge Chill to work like Pascal?

Basically.  I haven't done any Chill work (except providing advice)
for years;  I can't myself working on it unless I get paid (quite
well) for it; though at this point, time is the real constraint.

I don't know if anyone at Cygnus is still working on Chill, though I
heard a rumour Chill support is still of interest at Cygnus (i.e. to
at least one Cygnus customer).  I believe David Brolley is the last
person to work on Chill.

I am of course always happy to proffer my advice and opinions ...

> > In fact I can adapt Pascal to use bytes instead of words within
> > a few seconds (which means a loss of efficiency).  Bit endianess
> > would be more work.  Giving up the alignment would cause even
> > more work and would be a clear step backwards.
> 
> It would seem that a word-based implementation is better, so you probably
> should stick with it.

Yes, but we somebody need to change or replace the Chill run-time
to match the compiler changes.  I mentioned my bitprims library;
(see http://www.bothner.com/~per/software/#bitprims );  another
option may be to modify the Pascal library.

One thing confusing is Chill's terminology.  Chill has:
(a) bitstrings.  These are like character strings, but each element
is a single bit (a boolean).  These are basically packed arrays,
indexed from 0 to (length-1).
(b) "powersets" correspond to Pascal "sets".  (Chill "sets" are
basically enumerated types.)  These are mappings from a dicrete
type (or sub-range) to boolean.  The lower index need not be 0.

Traditionally, GNU Chill have used the same low-level representation
(packed bitstrings) for both.  That should continue.

Ideally, someone needs to check that Chill support in Gdb doesn't
break either, though I don't think that needs to be a pre-requisite.
(I.e. I think we can fix the compiler and break Gdb;  if this
cuases problems fr oneone, they can either fix it, or pay someone
to fix it, or stick with old releases.)

There is also a question whether Cygnus's Chill customer still needs
(and is willing to pay for) binary compatibility with the old code; if
so, that needs to be maintained.  However, backwards compatibility
support need not be in the public Gcc codebase.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Time schedule?

[Jeffrey A Law]

  In message < 199910242217.PAA21197@atrus.synopsys.com >you write:
  > Jeff, while of course I agree with you 100%, such statements, I think,
  > tend to intimidate new developers who don't have your experience, because
  > they look arbitrary.  I think it would be helpful to explain a bit
  > why something is wrong, especially for mistakes people tend to make
  > repeatedly.  Otherwise, for people who don't get it, you just look
  > stubborn and hard to work with.
But this is something I've explained to Peter in the past.

jeff

Re: Time schedule?

[Richard Kenner]

    I already studied this a long time ago but did not understand how to
    use it.  The explanations seem to have been improved since those
    times, but I still do not see a place where I can provide the actual
    expression.

You put the expression in a TYPE_SIZE, DECL_SIZE, DECL_FIELD_BITPOS,
TYPE_MIN_VALUE or TYPE_MAX_VALUE.

    Anyway, why isn't it done with the other tree nodes?  In Pascal we use
    just a normal TYPE_SIZE slot in the RECORD_TYPE, but this TYPE_SIZE
    does contain something non-constant that contains the value of the
    variable in question itself.  I do not see the place where the
    PLACEHOLDER_EXPR should be introduced.

Well, I don't know Pascal well and if you don't know Ada well, it's
sort of hard to communicate, but let me use an array example, which is
easier to understand without knowing the language.

Ada has arrays that contains both bounds and data.  The bounds are
both the lower and upper bounds.  So if you want to compute A(I), you
need to subtract the lower bound of A.  You get that by looking
A.BOUNDS.LB0.  So TYPE_MIN_VALUE of the the index type contains an
expression that is a function of a COMPONENT_REF whose operand first
operand is PLACEHOLDER_EXPR of the same type as A.

The record case works similarly: you can have a record where the
position of an object depends on the value of data in the field of the
record.  I don't see how you can express this in the tree without
these new codes because there's no way of saying "the current object
of type FOO": that's what PLACEHOLDER_EXPR is for.

Re: Time schedule?

[Marc Lehmann]

On Sun, Oct 24, 1999 at 01:54:41PM +0200, Peter Gerwinski <peter@gerwinski.de> wrote:
> > So this means there are principal problems with gpc.
> 
> I admit that our list of known bugs is long, but we are only two
> active GPC hackers and simply do not have the manpower to fix

No, "principal problems" means "it interacts badly with other frontends".
Wether gpc itself has bugs is of no concern, only wether this affects the
backend or the other frontends.

A "principal" problem would be if gpc required a patch that made the
backend incompatible to other frontends.

> This has never been a problem.  All GPC-specific patches have
> always been surrounded by `#ifdef GPC ... #endif'.  This is done

We either have these patches in the backend _always_ or we haven't. The
idea is that the patches that are still required for gpc can be
implemented in an frontend-independent way, i.e. the other frontends must
work with the patches installed (and not #ifdef'ed out).

Wether global flags to affect backend behaviour is the best way to
interface is another question.

> As soon as I have finished all tests with the new set
> code, I will release a new alpha GPC.  If it isn't hopeless
> anyway, I can keep you informed when this happens.

It certainly isn't hopeless! We need to apply (and possibly fix) the
patches required for gpc integration. This should have no effect on other
frontends.

Then we should evaluate the gpc frontend itself, add it into the cvs tree
and decide wether it is portable enough to be built by default (I think
so).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Peter Gerwinski]

Richard Kenner wrote:
>     It's the latter.  But there are already too few language
>     specific flags left ...
> 
> I meant a language *independent* flag.

No objections - as long as enough language *dependend* flags
remain. ;-)

>     That's exactly what is needed here.  How is this mechanism
>     intended to be used?  I did not find any documentation on this.
> 
> See PLACEHOLDER_EXPR and WITH_RECORD_EXPR in tree.def.

I already studied this a long time ago but did not understand
how to use it.  The explanations seem to have been improved
since those times, but I still do not see a place where I can
provide the actual expression.

Anyway, why isn't it done with the other tree nodes?  In Pascal
we use just a normal TYPE_SIZE slot in the RECORD_TYPE, but this
TYPE_SIZE does contain something non-constant that contains the
value of the variable in question itself.  I do not see the
place where the PLACEHOLDER_EXPR should be introduced.

    Peter

Re: Time schedule?

[Richard Kenner]

    It's the latter.  But there are already too few language
    specific flags left ...

I meant a language *independent* flag.

    > [...] and when it's determined from data within an object of the type
    > (for Ada discriminated records and unconstrained arrays).

    That's exactly what is needed here.  How is this mechanism
    intended to be used?  I did not find any documentation on this.

See PLACEHOLDER_EXPR and WITH_RECORD_EXPR in tree.def.

Re: Time schedule?

[Joe Buck]

> Per already gave his okay for using the Pascal implementation in
> the future which is more efficient.  However he told us that he
> will not hack Chill to adapt it.

(I think Per said he was giving up on Chill work altogether).
So then we need to find a volunteer to munge Chill to work like Pascal?

> In fact I can adapt Pascal to use bytes instead of words within
> a few seconds (which means a loss of efficiency).  Bit endianess
> would be more work.  Giving up the alignment would cause even
> more work and would be a clear step backwards.

It would seem that a word-based implementation is better, so you probably
should stick with it.

Re: Time schedule?

[Peter Gerwinski]

Joe Buck wrote:
> 
> Chill and Pascal are the only set users, right?  It would be great if
> the front-end maintainers could agree on a common implementation.

Per already gave his okay for using the Pascal implementation in
the future which is more efficient.  However he told us that he
will not hack Chill to adapt it.

> Ideally, you and Per (or whoever
> takes over for him) could agree on endianness and word size of sets.

In fact I can adapt Pascal to use bytes instead of words within
a few seconds (which means a loss of efficiency).  Bit endianess
would be more work.  Giving up the alignment would cause even
more work and would be a clear step backwards.

BTW, as far as I can tell from what I have read from the Chill
run time library, that code is broken anyway and should be
fixed.  (See my recent postings on this topic.)

> Then this patch would go away.

It would only go away if I fully adapt Pascal to the current
Chill implementation of sets.  While this would be possible
I do not think that it should be done.

As long as nobody is willing to adapt Chill to a new set format
I'd consider my current approach the most reasonable thing.
(BTW it's just a consequent continuation of what I already found
in `stor-layout.c' (int set_alignment).)

> > [#ifdef GPC ...]
> 
> From my point of view, the reason that it's wrong is that it's a
> fundamental violation of the architecture of gcc, which consists of
> a language-independent back end and language-dependent front ends.
> Also, #ifdefs are the enemy of maintainable code, you want to minimize
> the number of them.

Yes, of course.

> This kind of thing (#ifdef GPC) may be OK at an early stage of
> development, but once we're ready to integrate the new front end we need
> to get rid of it.  [...]

No problem - that's exactly how I understood Jeff. :)

> Please don't give up.  I think that once Pascal is integrated into the
> tree, development to fix the remaining problems will accelerate, because
> it will be much easier for more people to get and work on the code.

This is exactly the reason why I think that it is a good idea to
integrate GPC into GCC.

    Peter

Re: Time schedule?

[Peter Gerwinski]

Jeffrey A. Law wrote:
>   >   * `size_volatile' types.  These are types whose size must be
>   >     re-calculated each time a variable of that type is used, [...]
> Let's go for this one first.  I'll also dig out the old discussion from the
> archives to refresh my memory of the issues.

Okay.  The patch to `stor-layout.c' is relatively small; I am
appending it below.

>   > This has never been a problem.  All GPC-specific patches have
>   > always been surrounded by `#ifdef GPC ... #endif'.  This is done
>   > even now where the patches only affect frontends that explicitly
>   > override the default values of some global variables.
> But this is something we absolutely do not want to do.  This kind of stuff
> is absolutely wrong.  

Indeed.  As I said, the current patches require the frontend to
override the default values of some global variables to become
active, so they cannot affect the behaviour of the GCC backend
with other frontends.

    Peter

8< ---- `size_volatile' patch to `expr.c' ----------------------

*** stor-layout.c.orig	Thu Mar 11 14:56:20 1999
--- stor-layout.c	Mon Oct 25 00:32:45 1999
***************
*** 65,70 ****
--- 65,75 ----
  
  int immediate_size_expand;
  
+ /* Nonzero means that the size of a type may vary
+    within one function context.  */
+ 
+ int size_volatile = 0;
+ 
  tree
  get_pending_sizes ()
  {
***************
*** 102,108 ****
        || global_bindings_p () < 0 || contains_placeholder_p (size))
      return size;
  
!   size = save_expr (size);
  
    if (global_bindings_p ())
      {
--- 107,114 ----
        || global_bindings_p () < 0 || contains_placeholder_p (size))
      return size;
  
!   if (! size_volatile)
!     size = save_expr (size);
  
    if (global_bindings_p ())
      {
***************
*** 119,125 ****
         Also, we would like to pass const0_rtx here, but don't have it.  */
      expand_expr (size, expand_expr (integer_zero_node, NULL_PTR, VOIDmode, 0),
  		 VOIDmode, 0);
!   else
      pending_sizes = tree_cons (NULL_TREE, size, pending_sizes);
  
    return size;
--- 125,131 ----
         Also, we would like to pass const0_rtx here, but don't have it.  */
      expand_expr (size, expand_expr (integer_zero_node, NULL_PTR, VOIDmode, 0),
  		 VOIDmode, 0);
!   else if (! size_volatile)
      pending_sizes = tree_cons (NULL_TREE, size, pending_sizes);
  
    return size;

Re: Time schedule?

[Joe Buck]

peter@gerwinski.de writes:

>   >   * Sets.  I introduced new variables `set_word_size' and
>   >     `set_words_big_endian' and made `expr.c' and `store-layout.c'
>   >     use them.  With their default values, Chill sets are
>   >     constructed; the Pascal frontend overrides them to obtain
>   >     Pascal sets.

> Let's hold off this one and go after the size_volatile stuff (which I
> understand a little better since we've already discussed it in the past.

Chill and Pascal are the only set users, right?  It would be great if
the front-end maintainers could agree on a common implementation.
While your design doesn't seem *that* bad, it seems to mean that
Chill and Pascal can't interoperate (which in this particular case
isn't so bad: how many people will use Chill and Pascal and try to
pass a set from one to the other?).  Ideally, you and Per (or whoever
takes over for him) could agree on endianness and word size of sets.
Then this patch would go away.

>   > This has never been a problem.  All GPC-specific patches have
>   > always been surrounded by `#ifdef GPC ... #endif'.  This is done
>   > even now where the patches only affect frontends that explicitly
>   > override the default values of some global variables.

> But this is something we absolutely do not want to do.  This kind of stuff
> is absolutely wrong.  

Jeff, while of course I agree with you 100%, such statements, I think,
tend to intimidate new developers who don't have your experience, because
they look arbitrary.  I think it would be helpful to explain a bit
why something is wrong, especially for mistakes people tend to make
repeatedly.  Otherwise, for people who don't get it, you just look
stubborn and hard to work with.

From my point of view, the reason that it's wrong is that it's a
fundamental violation of the architecture of gcc, which consists of
a language-independent back end and language-dependent front ends.
Also, #ifdefs are the enemy of maintainable code, you want to minimize
the number of them.

This kind of thing (#ifdef GPC) may be OK at an early stage of
development, but once we're ready to integrate the new front end we need
to get rid of it.  In some cases, the back end needs something for the new
language that wasn't there before.  Then there needs to be agreement.

Please don't give up.  I think that once Pascal is integrated into the
tree, development to fix the remaining problems will accelerate, because
it will be much easier for more people to get and work on the code.

Re: Time schedule?

[Jeffrey A Law]

  In message < 19991024135441.C230@esmeralda.gerwinski.de >you write:
  > There are only two sets of patches left:
Oh.  Good.  Sounds like you've made great progress.

  >   * Sets.  I introduced new variables `set_word_size' and
  >     `set_words_big_endian' and made `expr.c' and `store-layout.c'
  >     use them.  With their default values, Chill sets are
  >     constructed; the Pascal frontend overrides them to obtain
  >     Pascal sets.
  > 
  >     If there is any chance to get this patch into the main GCC
  >     source, I can submit it to an address of your choice once
  >     I finished all tests with this.
Let's hold off this one and go after the size_volatile stuff (which I
understand a little better since we've already discussed it in the past.


  >   * `size_volatile' types.  These are types whose size must be
  >     re-calculated each time a variable of that type is used, so
  >     `variable_size()' (in `store-layout.c') must not construct a
  >     SAVE_EXPR for it.  Our current patch introduces a global
  >     variable `size_volatile' to inform `variable_size()' about
  >     this.  Better ideas welcome.
Let's go for this one first.  I'll also dig out the old discussion from the
archives to refresh my memory of the issues.


  > This has never been a problem.  All GPC-specific patches have
  > always been surrounded by `#ifdef GPC ... #endif'.  This is done
  > even now where the patches only affect frontends that explicitly
  > override the default values of some global variables.
But this is something we absolutely do not want to do.  This kind of stuff
is absolutely wrong.  

jeff

Re: Time schedule?

[Peter Gerwinski]

Marc Lehmann wrote:
> If gpc does not break the rest of the tree (including gpc does not require
> applying random patches to the backend), then I'd say it's in a form
> suitable to get included. [...]

There are only two sets of patches left:

  * Sets.  I introduced new variables `set_word_size' and
    `set_words_big_endian' and made `expr.c' and `store-layout.c'
    use them.  With their default values, Chill sets are
    constructed; the Pascal frontend overrides them to obtain
    Pascal sets.

    If there is any chance to get this patch into the main GCC
    source, I can submit it to an address of your choice once
    I finished all tests with this.

  * `size_volatile' types.  These are types whose size must be
    re-calculated each time a variable of that type is used, so
    `variable_size()' (in `store-layout.c') must not construct a
    SAVE_EXPR for it.  Our current patch introduces a global
    variable `size_volatile' to inform `variable_size()' about
    this.  Better ideas welcome.

Since the other patches I suggested so far have been rejected or
ignored, we have constructed workarounds in the frontend for all
of them, so they are not needed any more.  This includes the bug
fix for ABS_EXPR with complex operands (for which I still wonder
how the code could have ever been working for any language).

> So this means there are principal problems with gpc.

I admit that our list of known bugs is long, but we are only two
active GPC hackers and simply do not have the manpower to fix
the bugs quickly.  If this is a principal problem, then, well,
then I do not see any chance to get GPC integrated into GCC in
time for gcc-3.0 - or even after that.  :-(

> If (compiling) stability is a problem we could require a --enable-gpc at
> configure time to attempt to build it.

This has never been a problem.  All GPC-specific patches have
always been surrounded by `#ifdef GPC ... #endif'.  This is done
even now where the patches only affect frontends that explicitly
override the default values of some global variables.

> It appears to me that we have to evaluate gpc again in the near future..

As soon as I have finished all tests with the new set
code, I will release a new alpha GPC.  If it isn't hopeless
anyway, I can keep you informed when this happens.

Greetings,

    Peter

Re: Time schedule?

[Marc Lehmann]

On Mon, Oct 18, 1999 at 08:06:42PM -0600, Jeffrey A Law <law@cygnus.com> wrote:
>   In message < 199910190111.SAA23672@kankakee.wrs.com >you write:
> 
>   > I disagree.  I think we should include it in, now, regardless of the
>   > state it is in.
> I strongly disagree wrong with that attitude.

I don't. While I agree that including something just because it exists is not
viable, the real question is wether gpc is in a form suitable for inclusion.

If gpc does not break the rest of the tree (including gpc does not require
applying random patches to the backend), then I'd say it's in a form
suitable to get included. (And since there is wide demand for it it is
also "economically useful").

> basically OK and just needs polishing around the edges and dropping in
> something that needs major revamping before it's in the right neighborhood.

So this means there are principal problems with gpc. In this case we really
need to clarify what these problems are, and what needs to be done on the gpc
side to fix it. We have been asked for this.

> We do not know where the gpc code sits at the current time.  Last I looked
> there were some major problems, particularly in how it interfaced into

Last time it also required patches to the backend. We were told that it does not
need these patches anymore, so what would inhibit us from including it in cvs
(and only there).

If (compiling) stability is a problem we could require a --enable-gpc at
configure time to attempt to build it.

> Dropping it in before it hits that level of correctness is just going to make
> everyone life miserable, waiting too late would make gpc suffer.  Finding the
> right time to contribute can be difficult, but it's really necessary for the
> health of both projects.

It appears to me that we have to evaluate gpc again in the near future..

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Joe Buck]

> FWIW - I cannot ethically release code under any GNU license that
> I have ever read.

Please, let's keep discussion of software licensing issues off of this
list.  Anyone wanting to debate licenses and ethics, please go to
gnu.misc.discuss.

Re: Time schedule?

[Benjamin Scherrey]

I figured I'd get at least one message like this which is why I tried
to make it clear that I wasn't complaining. FWIW - I cannot ethically
release code under any GNU license that I have ever read. I'd be happy
to help an open source non-GNU implementation of the C++ standard lib
that wasn't compiler specific and stressed platform independence. I
don't expect that to happen any time remotely soon and wish the
current team well with their efforts.

	regards,

		Ben Scherrey

Gabriel Dos_Reis wrote:
> 
> Benjamin Scherrey <scherrey@switchco.com> writes:
> 
> | What's the word on releasing with the (slowly but surely) developing
> | libstdc++ library? 
<snip>

> Well, the sooner you help the sooner libstdc++-v3 got finished.

Re: Time schedule?

[Benjamin Scherrey]

I agree that, technically, libg++ -> libstdc++ had a higher impact on
deployed code than the new libstdc++ will. That said, I feel it
deserved its own version release as well but that was back when the
egcs split was still relatively young and not the standard release of
gcc. My biggest caveat, however, is that there simply wasn't as much
C++ code actually deployed then as there is now. The C++ user base
with g++ is probably an order of magnitude larger than it was then and
compliance to the ANSI spec is a major issue that the libstdc++
release will pretty much bring the most egregious variances under
wraps. So... the impact to the development community will be far
larger in this case. A point release will be very confusing to
developers who don't track the compiler's development closely. They're
used to seeing bug fixes and minor improvements for those kind of
things, not expecting to have to relink all deployed apps! Perhaps we
can call it GCC-2000? :-)

	regards,

		Ben Scherrey

David Starner wrote:
> Major version changes on GCC are reserved for massive changes.
> OTOH, the libstdc++ 2 -> 3 change-over will probably have less
> effect on C++ applications than the libg++ -> libstdc++ change
> over did, and that was 2.7 -> 2.8/egcs.

Re: Time schedule?

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:

| What's the word on releasing with the (slowly but surely) developing
| libstdc++ library? I would think that integration with this would
| justify a full version release by itself considering the impact it
| will have on deployed C++ applications. I was hoping it would be part
| of the 3.0 release but I don't see libstdc++ being ready before third
| qtr 2000 given its current pace (note - this is not me whining or
| complaining, just an observation). Has any thought been put into goals
| for a 4.0 release?

Well, the sooner you help the sooner libstdc++-v3 got finished.


BTW, libstdc++-v3, as it is, randomly crashes the compiler.  The last
time I tried to build it the compiler got into infinite loop (try
CXXFLAGS='-fsquangle -fhonor-std -fnew-exceptions -O3 -fnew-abi').
Also, the library needs some support from the compiler, such as 

	http://www.cantrip.org/cheaders.html

-- Gaby

Re: Time schedule?

[Jeffrey A Law]

  In message < 199910190111.SAA23672@kankakee.wrs.com >you write:

  > I disagree.  I think we should include it in, now, regardless of the
  > state it is in.
I strongly disagree wrong with that attitude.

There is a significant difference between dropping in something that is
basically OK and just needs polishing around the edges and dropping in
something that needs major revamping before it's in the right neighborhood.

We do not know where the gpc code sits at the current time.  Last I looked
there were some major problems, particularly in how it interfaced into
expr.c and the debugging code that were totally unacceptable.  Worse yet,
nobody from the gpc camp even knew why the changes were needed (or even if
they were still needed).

I'm not trying to slam the gpc folks, but that's not a hunk of code we're
likely to accept unless it has been significantly improved.  I sincerely
hope it has because I want to see GCC incorporate gpc in the hope that it'll
have the same kind of positive effect incorporating g77 had.

  > Once it is in, people can contribute fixes for
  > whatever brokenness is left, if and as they care.  Without it in, out
  > of sight, out of mind.  (I'm assuming it at least doesn't break the
  > builds.)
I'm more than aware of the advantages that having code in the tree provides,
but the code has to meet a certain level of correctness before it will go in.
No ifs, ands or buts about it.  This is not "throw it over the wall and watch
developers scatter" development, nor is it "wait until it is 100% perfect"
development.  There's a point in-between that we're shooting for.

Dropping it in before it hits that level of correctness is just going to make
everyone life miserable, waiting too late would make gpc suffer.  Finding the
right time to contribute can be difficult, but it's really necessary for the
health of both projects.


jeff

Re: Time schedule?

[Mike Stump]

> Date: Tue, 19 Oct 1999 02:17:49 +0200
> From: Marc Lehmann <pcg@opengroup.org>
> To: gcc@gcc.gnu.org

> If this is ok (it should) then I'd say we should include gnu pascal in
> cvs, as soon as the remaining issues are resolved (see below).

I disagree.  I think we should include it in, now, regardless of the
state it is in.  Once it is in, people can contribute fixes for
whatever brokenness is left, if and as they care.  Without it in, out
of sight, out of mind.  (I'm assuming it at least doesn't break the
builds.)

Re: Time schedule?

[David Starner]

On Mon, Oct 18, 1999 at 08:43:52PM -0500, Benjamin Scherrey wrote:
> What's the word on releasing with the (slowly but surely) developing
> libstdc++ library? I would think that integration with this would
> justify a full version release by itself considering the impact it
> will have on deployed C++ applications. 

Major version changes on GCC are reserved for massive changes.
OTOH, the libstdc++ 2 -> 3 change-over will probably have less 
effect on C++ applications than the libg++ -> libstdc++ change
over did, and that was 2.7 -> 2.8/egcs. 

At this point no one know what GCC 4.0 will look like, except that
it will probably be as far from GCC 3.0 as GCC 3.0 was from GCC 2.0.

David Starner - dstarner98@aasaa.ofe.org

Re: Time schedule?

[Joe Buck]

> What's the word on releasing with the (slowly but surely) developing
> libstdc++ library?

The original idea was that it would be part of 3.0, with the hope that
we would then have a more or less final C++ ABI.

> I would think that integration with this would
> justify a full version release by itself considering the impact it
> will have on deployed C++ applications. I was hoping it would be part
> of the 3.0 release but I don't see libstdc++ being ready before third
> qtr 2000 given its current pace (note - this is not me whining or
> complaining, just an observation).

... which means that the next major gcc release will probably be 2.96.
There's no set schedule for 3.0, as there isn't a marketing department
in charge.

Re: Time schedule?

[Benjamin Scherrey]

What's the word on releasing with the (slowly but surely) developing
libstdc++ library? I would think that integration with this would
justify a full version release by itself considering the impact it
will have on deployed C++ applications. I was hoping it would be part
of the 3.0 release but I don't see libstdc++ being ready before third
qtr 2000 given its current pace (note - this is not me whining or
complaining, just an observation). Has any thought been put into goals
for a 4.0 release?

	regards,

		Ben Scherrey

Marc Lehmann wrote:
> At the moment we can't give you any time schedule, or any tentative dates,
> as Jeff is not able to do the release work for the next release.
> 
> I don't think we will directly go to 3.0 (but who knows). How long do you
> think will it take to package gpc into a cvs-able form? If all issues with
> the backend are clear and gpc works out of the box (more or less) including
> it into cvs _might_ be the way to go. There is no feature freeze yet.

Re: Time schedule?

[Marc Lehmann]

On Tue, Oct 19, 1999 at 12:27:37AM +0200, Peter Gerwinski <peter@gerwinski.de> wrote:
> Marc Lehmann wrote:
> > How long do you
> > think will it take to package gpc into a cvs-able form?
> 
> What's that - a cvs-able form - in contrast to the existing tarball
> that contains a subdirectory `p' to the `gcc' directory?

Difficult to define ;) It's a tarball that can be integrated into cvs
which contains the p subdir.

In addition:

- it should not break anything else (should, bugs or just bugs)
- it must have an active maintainer who cares for the bugs
  and the compiler bug reports (i.e. gcc-bugs).

If this is ok (it should) then I'd say we should include gnu pascal in
cvs, as soon as the remaining issues are resolved (see below).

However, wether gpc will be in the next release, or wether this happens
before the next release, is in the hands of the release manager ;)
Stability is most important, but I would very much like it to have it in
the 3.0 release.

> Okay, so I will just go on and submit patches (concerning the set
> code and one feature in `variable_size()' (file `stor-layout.c')
> that will allow for compiling GPC with the GCC backend without
> further patches.

Yes, thats the goal. First all incompatibilities between the back- and the
frontend have to be resolved (don't underestimate this, some people might
disagree on how to fix some things).

> The bug fix for ABS_EXPRs of complex numbers is another one of
> these patches needed by GPC.  Shall I re-submit it?

I think you submitted it recently enough.

> (Of course I already submitted a copyright assignment for past
> and future changes to GCC to the FSF.)

Good, one problem less ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: Time schedule?

[Peter Gerwinski]

Marc Lehmann wrote:
> How long do you
> think will it take to package gpc into a cvs-able form?

What's that - a cvs-able form - in contrast to the existing tarball
that contains a subdirectory `p' to the `gcc' directory?

> If all issues with
> the backend are clear and gpc works out of the box (more or less) including
> it into cvs _might_ be the way to go. There is no feature freeze yet.

Okay, so I will just go on and submit patches (concerning the set
code and one feature in `variable_size()' (file `stor-layout.c')
that will allow for compiling GPC with the GCC backend without
further patches.

The bug fix for ABS_EXPRs of complex numbers is another one of
these patches needed by GPC.  Shall I re-submit it?

(Of course I already submitted a copyright assignment for past
and future changes to GCC to the FSF.)

    Peter

-- 
http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422
keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

Re: Time schedule?

[Marc Lehmann]

On Sun, Oct 17, 1999 at 10:05:37PM +0200, Peter Gerwinski <peter@gerwinski.de> wrote:
> we are thinking about our release schedule for GPC.  Since we
> are approaching full integration with GCC (i.e. compilation
> without a patch to the backend), we'd like to know a rough plan
> when the next version of gcc-2.x and/or gcc-3.x is going to be
> released.

At the moment we can't give you any time schedule, or any tentative dates,
as Jeff is not able to do the release work for the next release.

I don't think we will directly go to 3.0 (but who knows). How long do you
think will it take to package gpc into a cvs-able form? If all issues with
the backend are clear and gpc works out of the box (more or less) including
it into cvs _might_ be the way to go. There is no feature freeze yet.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Time schedule?

[Peter Gerwinski]

Hello,

we are thinking about our release schedule for GPC.  Since we
are approaching full integration with GCC (i.e. compilation
without a patch to the backend), we'd like to know a rough plan
when the next version of gcc-2.x and/or gcc-3.x is going to be
released.

Thanks,

    Peter

-- 
http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422
keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net