EGCS 1.1.3?

EGCS 1.1.3?

[craig]

Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo this
week, and am trying to prioritize my activities for today before I leave,
and would like to have a heads-up if it's critical for me to submit
any patches (not yet written) for g77 for 1.1.3.

I'd rather put off work on these until after I return next Sunday,
1999-05-23, but if EGCS 1.1.3 is supposed to start "spinning" this
week, I'm willing to scramble on get them in by late tonight.

(The patches I have in mind would cause g77 to diagnose, as errors,
a few constructs we now know generate bad code, and for which EGCS 1.2
already has proper fixes, like INTEGER*8 array indexes.  Nothing major,
in terms of scope of changes, but important to help people avoid
getting bad code out of g77.)

        tq vm, (burley)

Re: EGCS 1.1.3?

[Jeffrey A Law]

  In message < 19990517143725.23227.qmail@deer >you write:
  > Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo this
  > week, and am trying to prioritize my activities for today before I leave,
  > and would like to have a heads-up if it's critical for me to submit
  > any patches (not yet written) for g77 for 1.1.3.
No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only patch
it would have anyway would be to fix the shared library problems HJ introduced.
Absolutely nothing else.

jeff

Re: EGCS 1.1.3?

[craig]

>No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only patch
>it would have anyway would be to fix the shared library problems HJ introduced.
>Absolutely nothing else.

Hmm, thought I saw a checkin to the egcs_1_1_branch sometime last week.

Anyway, it does seem to me as though egcs 1.2 will come out soon enough
to make little need for 1.1.3.  (But if there are substantial issues
that keep people from moving from 1.1.2 to 1.2 in a timely fashion,
that might result in pressure to provide a 1.1.3 if the bugs in 1.1.2
are considered bad enough.)

AFAIK, the bugs I know about in g77 in 1.1.2 aren't exactly the sort that
are resulting in bad code in ordinary development, so I wouldn't want
1.1.3 to be done just for g77.  If it *was* done, though, I'd feel better
if the g77 in 1.1.3 caught some problems it currently let through.

        tq vm, (burley)

Re: EGCS 1.1.3?

[Jeffrey A Law]

  In message <19990518034845.A52327@nuxi.com>you write:
  > >   > Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo th
  > is
  > ...
  > > No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only
  > > patch it would have anyway would be to fix the shared library problems
  > > HJ introduced.  Absolutely nothing else.
  > 
  > And if one wanted to have the equivant of the would-be 1.1.3, they would
  > apply this patch, right?
Or something similar.  There was an alternate proposal which involved moving
things around a little bit that *might* have been compatible with egcs-1.1.1
and still had the advantages of the patch that is causing the problems.

I'm planning to review that proposal since I want to fix this problem once
and for all in gcc-2.95.

jeff

EGCS 1.1.3?

[craig]

Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo this
week, and am trying to prioritize my activities for today before I leave,
and would like to have a heads-up if it's critical for me to submit
any patches (not yet written) for g77 for 1.1.3.

I'd rather put off work on these until after I return next Sunday,
1999-05-23, but if EGCS 1.1.3 is supposed to start "spinning" this
week, I'm willing to scramble on get them in by late tonight.

(The patches I have in mind would cause g77 to diagnose, as errors,
a few constructs we now know generate bad code, and for which EGCS 1.2
already has proper fixes, like INTEGER*8 array indexes.  Nothing major,
in terms of scope of changes, but important to help people avoid
getting bad code out of g77.)

        tq vm, (burley)

Re: EGCS 1.1.3?

[Jeffrey A Law]

  In message < 19990518034845.A52327@nuxi.com >you write:
  > >   > Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo th
  > is
  > ...
  > > No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only
  > > patch it would have anyway would be to fix the shared library problems
  > > HJ introduced.  Absolutely nothing else.
  > 
  > And if one wanted to have the equivant of the would-be 1.1.3, they would
  > apply this patch, right?
Or something similar.  There was an alternate proposal which involved moving
things around a little bit that *might* have been compatible with egcs-1.1.1
and still had the advantages of the patch that is causing the problems.

I'm planning to review that proposal since I want to fix this problem once
and for all in gcc-2.95.

jeff

Re: EGCS 1.1.3?

[Jeffrey A Law]

  In message < 19990517143725.23227.qmail@deer >you write:
  > Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo this
  > week, and am trying to prioritize my activities for today before I leave,
  > and would like to have a heads-up if it's critical for me to submit
  > any patches (not yet written) for g77 for 1.1.3.
No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only patch
it would have anyway would be to fix the shared library problems HJ introduced.
Absolutely nothing else.

jeff

Re: EGCS 1.1.3?

[craig]

>No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only patch
>it would have anyway would be to fix the shared library problems HJ introduced.
>Absolutely nothing else.

Hmm, thought I saw a checkin to the egcs_1_1_branch sometime last week.

Anyway, it does seem to me as though egcs 1.2 will come out soon enough
to make little need for 1.1.3.  (But if there are substantial issues
that keep people from moving from 1.1.2 to 1.2 in a timely fashion,
that might result in pressure to provide a 1.1.3 if the bugs in 1.1.2
are considered bad enough.)

AFAIK, the bugs I know about in g77 in 1.1.2 aren't exactly the sort that
are resulting in bad code in ordinary development, so I wouldn't want
1.1.3 to be done just for g77.  If it *was* done, though, I'd feel better
if the g77 in 1.1.3 caught some problems it currently let through.

        tq vm, (burley)

Re: EGCS 1.1.3?

[David O'Brien]

>   > Is EGCS 1.1.3 going to happen anytime soon?  I'm away at LinuxExpo this
...
> No.  Being sick totally killed any chance to do egcs-1.1.3.  THe only
> patch it would have anyway would be to fix the shared library problems
> HJ introduced.  Absolutely nothing else.

And if one wanted to have the equivant of the would-be 1.1.3, they would
apply this patch, right?

--- egcs-1.1.2/gcc/crtstuff.c	Sat Feb 27 13:54:23 1999
+++ egcs-1.1.1/gcc/crtstuff.c	Mon Jun  8 11:30:12 1998
@@ -56,45 +56,6 @@
 #include <stddef.h>
 #include "frame.h"
 
-/* This really belongs in gansidecl.h, but for the egcs-1.1.x branch, the
-   only code which uses weak attributes is in this file and this file does
-   not include gansidecl.h.  */
-#ifndef TARGET_ATTRIBUTE_WEAK
-# if SUPPORTS_WEAK
-#  define TARGET_ATTRIBUTE_WEAK       __attribute__ ((weak))
-# else
-#  define TARGET_ATTRIBUTE_WEAK
-# endif
-#endif
-
-/* We do not want to add the weak attribute to the declarations of these
-   routines in frame.h because that will cause the definition of these
-   symbols to be weak as well.
-
-   This exposes a core issue, how to handle creating weak references vs
-   how to create weak definitions.  Either we have to have the definition
-   of TARGET_WEAK_ATTRIBUTE be conditional in the shared header files or
-   have a second declaration if we want a function's references to be weak,
-   but not its definition.
-
-   Making TARGET_WEAK_ATTRIBUTE conditional seems like a good solution until
-   one thinks about scaling to larger problems -- ie, the condition under
-   which TARGET_WEAK_ATTRIBUTE is active will eventually get far too
-   complicated.
-
-   So, we take an approach similar to #pragma weak -- we have a second
-   declaration for functions that we want to have weak references.
-
-   Neither way is particularly good.  */
-   
-/* References to __register_frame_info and __deregister_frame_info should
-   be weak in this file if at all possible.  */
-extern void __register_frame_info (void *, struct object *)
-				  TARGET_ATTRIBUTE_WEAK;
-
-extern void *__deregister_frame_info (void *)
-				     TARGET_ATTRIBUTE_WEAK;
-
 /* Provide default definitions for the pseudo-ops used to switch to the
    .ctors and .dtors sections.
  
@@ -181,8 +142,7 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  if (__deregister_frame_info)
-    __deregister_frame_info (__EH_FRAME_BEGIN__);
+  __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
   completed = 1;
 }
@@ -210,8 +170,7 @@
 frame_dummy ()
 {
   static struct object object;
-  if (__register_frame_info)
-    __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -295,8 +254,7 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  if (__deregister_frame_info)
-    __deregister_frame_info (__EH_FRAME_BEGIN__);
+  __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -308,8 +266,7 @@
 __frame_dummy ()
 {
   static struct object object;
-  if (__register_frame_info)
-    __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif