Re: Wanted: ETA for working friendly template support in EGCS.

Re: Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

>You may think [working C++ support] is a necessity, but I don't.  I'm
>certainly not going to spend any time on it.

Why is that? A hell of a lot of C++ programs would dearly love to be able
to write real, serious C++ projects on DOS and in other COFF-limited
environments without having to buy a commercial compiler and then write
non-portable code.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Jeffrey A Law]

  In message < 3.0.6.32.19990202211508.0092cb00@pop.netaddress.com >you write:
  > >You may think [working C++ support] is a necessity, but I don't.  I'm
  > >certainly not going to spend any time on it.
  > 
  > Why is that? A hell of a lot of C++ programs would dearly love to be able
  > to write real, serious C++ projects on DOS and in other COFF-limited
  > environments without having to buy a commercial compiler and then write
  > non-portable code.
No, I was referring to DOS, COFF and similar ilk.

Working C++ is important to me.  Making it work for DOS is not important to me.



jeff

Re: Wanted: ETA for working friendly template support in EGCS.

[Jeffrey A Law]

  In message < 3.0.6.32.19990202211508.0092cb00@pop.netaddress.com >you write:
  > >You may think [working C++ support] is a necessity, but I don't.  I'm
  > >certainly not going to spend any time on it.
  > 
  > Why is that? A hell of a lot of C++ programs would dearly love to be able
  > to write real, serious C++ projects on DOS and in other COFF-limited
  > environments without having to buy a commercial compiler and then write
  > non-portable code.
No, I was referring to DOS, COFF and similar ilk.

Working C++ is important to me.  Making it work for DOS is not important to me.



jeff

Re: Wanted: ETA for working friendly template support in EGCS.

[Jason Merrill]

>>>>> DJ Delorie <dj@delorie.com> writes:

 > Jeffrey A Law wrote:
 >> Working C++ is important to me.  Making it work for DOS is not
 >> important to me.

 > Making it work in NT should be important, though, and both NT and DOS
 > use COFF format.  Fixing the problem for NT will fix it for DOS
 > as well (plus or minus porting the changes to djgpp).

But it does work in NT.  PE has .linkonce, which is roughly equivalent to
what we do on ELF.  Does DJGPP support .linkonce?

Jason

Re: Wanted: ETA for working friendly template support in EGCS.

[Mumit Khan]

On 3 Feb 1999, Jason Merrill wrote:

> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
> what we do on ELF.  Does DJGPP support .linkonce?

Nope.

Mark E is working on it, and I believe there is something usable already
in the binutils snapshots. I think he's yet to submit his egcs changes to
support .weak on coff however.

Mumit

Re: Wanted: ETA for working friendly template support in EGCS.

[Mark E.]

On 3 Feb 1999 16:39:15 +0100, you wrote:

>On 3 Feb 1999, Jason Merrill wrote:
>
>> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
>> what we do on ELF.  Does DJGPP support .linkonce?
>
>Nope.
>
>Mark E is working on it, and I believe there is something usable already
>in the binutils snapshots. I think he's yet to submit his egcs changes to
>support .weak on coff however.
>

Yep, I haven't submitted the change yet. I want to wait until the next
binutils release, since putting in the patch now would then require an egcs
snapshot user to have an development version of binutils. Should I go ahead
and submit a patch to 'turn on' weak symbol support for COFF or should I
hold off until the next binutils release?

Mark
-- 
Mark E.: snowball3@usa.net
http://members.xoom.com/snowball3/

Re: Wanted: ETA for working friendly template support in EGCS.

[Richard Henderson]

On Wed, Feb 03, 1999 at 10:12:38PM +0000, Mark E. wrote:
> Yep, I haven't submitted the change yet. I want to wait until the next
> binutils release, since putting in the patch now would then require an egcs
> snapshot user to have an development version of binutils. Should I go ahead
> and submit a patch to 'turn on' weak symbol support for COFF or should I
> hold off until the next binutils release?

Probably best is to use autoconf to detect assembler features.
There are a couple present already -- search for subsection.


r~

Re: Wanted: ETA for working friendly template support in EGCS.

[Richard Henderson]

On Wed, Feb 03, 1999 at 10:12:38PM +0000, Mark E. wrote:
> Yep, I haven't submitted the change yet. I want to wait until the next
> binutils release, since putting in the patch now would then require an egcs
> snapshot user to have an development version of binutils. Should I go ahead
> and submit a patch to 'turn on' weak symbol support for COFF or should I
> hold off until the next binutils release?

Probably best is to use autoconf to detect assembler features.
There are a couple present already -- search for subsection.


r~

Re: Wanted: ETA for working friendly template support in EGCS.

[Mark E.]

On 3 Feb 1999 16:39:15 +0100, you wrote:

>On 3 Feb 1999, Jason Merrill wrote:
>
>> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
>> what we do on ELF.  Does DJGPP support .linkonce?
>
>Nope.
>
>Mark E is working on it, and I believe there is something usable already
>in the binutils snapshots. I think he's yet to submit his egcs changes to
>support .weak on coff however.
>

Yep, I haven't submitted the change yet. I want to wait until the next
binutils release, since putting in the patch now would then require an egcs
snapshot user to have an development version of binutils. Should I go ahead
and submit a patch to 'turn on' weak symbol support for COFF or should I
hold off until the next binutils release?

Mark
-- 
Mark E.: snowball3@usa.net
http://members.xoom.com/snowball3/

Re: Wanted: ETA for working friendly template support in EGCS.

[Mumit Khan]

On 3 Feb 1999, Jason Merrill wrote:

> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
> what we do on ELF.  Does DJGPP support .linkonce?

Nope.

Mark E is working on it, and I believe there is something usable already
in the binutils snapshots. I think he's yet to submit his egcs changes to
support .weak on coff however.

Mumit

Re: Wanted: ETA for working friendly template support in EGCS.

[DJ Delorie]

> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
> what we do on ELF.  Does DJGPP support .linkonce?

DJGPP currently uses binutils 2.8.1 - was support in there?  Is it in
binutils-2.9.1?

Re: Wanted: ETA for working friendly template support in EGCS.

[Jason Merrill]

>>>>> DJ Delorie <dj@delorie.com> writes:

 >> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
 >> what we do on ELF.  Does DJGPP support .linkonce?

 > DJGPP currently uses binutils 2.8.1 - was support in there?  Is it in
 > binutils-2.9.1?

My understanding is that DJGPP uses straight COFF, not PE.  Certainly the
handling in the linker refers to "coff-go32", as opposed to "pei-i386" for
cygwin.  Not being a linker guy, I don't know how much work it would be to
merge the two, or to add COMDAT support to coff-go32.

Jason

Re: Wanted: ETA for working friendly template support in EGCS.

[DJ Delorie]

I guess I'll have to look at it.  Thanks.

> My understanding is that DJGPP uses straight COFF, not PE.  Certainly the
> handling in the linker refers to "coff-go32", as opposed to "pei-i386" for
> cygwin.  Not being a linker guy, I don't know how much work it would be to
> merge the two, or to add COMDAT support to coff-go32.

Re: Wanted: ETA for working friendly template support in EGCS.

[DJ Delorie]

I guess I'll have to look at it.  Thanks.

> My understanding is that DJGPP uses straight COFF, not PE.  Certainly the
> handling in the linker refers to "coff-go32", as opposed to "pei-i386" for
> cygwin.  Not being a linker guy, I don't know how much work it would be to
> merge the two, or to add COMDAT support to coff-go32.

Re: Wanted: ETA for working friendly template support in EGCS.

[Jason Merrill]

>>>>> DJ Delorie <dj@delorie.com> writes:

 >> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
 >> what we do on ELF.  Does DJGPP support .linkonce?

 > DJGPP currently uses binutils 2.8.1 - was support in there?  Is it in
 > binutils-2.9.1?

My understanding is that DJGPP uses straight COFF, not PE.  Certainly the
handling in the linker refers to "coff-go32", as opposed to "pei-i386" for
cygwin.  Not being a linker guy, I don't know how much work it would be to
merge the two, or to add COMDAT support to coff-go32.

Jason

Re: Wanted: ETA for working friendly template support in EGCS.

[DJ Delorie]

> But it does work in NT.  PE has .linkonce, which is roughly equivalent to
> what we do on ELF.  Does DJGPP support .linkonce?

DJGPP currently uses binutils 2.8.1 - was support in there?  Is it in
binutils-2.9.1?

Re: Wanted: ETA for working friendly template support in EGCS.

[Jason Merrill]

>>>>> DJ Delorie <dj@delorie.com> writes:

 > Jeffrey A Law wrote:
 >> Working C++ is important to me.  Making it work for DOS is not
 >> important to me.

 > Making it work in NT should be important, though, and both NT and DOS
 > use COFF format.  Fixing the problem for NT will fix it for DOS
 > as well (plus or minus porting the changes to djgpp).

But it does work in NT.  PE has .linkonce, which is roughly equivalent to
what we do on ELF.  Does DJGPP support .linkonce?

Jason

Re: Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

>You may think [working C++ support] is a necessity, but I don't.  I'm
>certainly not going to spend any time on it.

Why is that? A hell of a lot of C++ programs would dearly love to be able
to write real, serious C++ projects on DOS and in other COFF-limited
environments without having to buy a commercial compiler and then write
non-portable code.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Mark E.]

 
> > Should I go ahead and submit a patch to 'turn on' weak symbol
> > support for COFF?

Unfortunately, after looking over the gcc/config/, there doesn't seem to 
be a 'coff.h' type file which is included by all coff targets. Doesn't mean 
there isn't, it's just that I can find one.

The .weak directive in binutils for COFF is compatible with the one for 
ELF. Especially since the routine in gas that parses .weak for COFF 
was copied from the ELF version. So the macro in elfos.h can be 
reused with COFF targets:  

/* This is how we tell the assembler that a symbol is weak.  */  
#define ASM_WEAKEN_LABEL(FILE,NAME) \
  do { fputs ("\t.weak\t", FILE); assemble_name (FILE, NAME); \
       fputc ('\n', FILE); } while (0)

> 
> I think you should, brownie points if you can autoconf the feature and put
> it in now.  I thought people autoconf some as features (p2align maybe?).
> 

I'm sure detecting support for .weak is easy, but writing a working 
autoconf macro is beyond me at the moment.

Mark

--- 
Mark Elbrecht snowball3@usa.net
http://members.xoom.com/snowball3/

Re: Wanted: ETA for working friendly template support in EGCS.

[Mark E.]

 
> > Should I go ahead and submit a patch to 'turn on' weak symbol
> > support for COFF?

Unfortunately, after looking over the gcc/config/, there doesn't seem to 
be a 'coff.h' type file which is included by all coff targets. Doesn't mean 
there isn't, it's just that I can find one.

The .weak directive in binutils for COFF is compatible with the one for 
ELF. Especially since the routine in gas that parses .weak for COFF 
was copied from the ELF version. So the macro in elfos.h can be 
reused with COFF targets:  

/* This is how we tell the assembler that a symbol is weak.  */  
#define ASM_WEAKEN_LABEL(FILE,NAME) \
  do { fputs ("\t.weak\t", FILE); assemble_name (FILE, NAME); \
       fputc ('\n', FILE); } while (0)

> 
> I think you should, brownie points if you can autoconf the feature and put
> it in now.  I thought people autoconf some as features (p2align maybe?).
> 

I'm sure detecting support for .weak is easy, but writing a working 
autoconf macro is beyond me at the moment.

Mark

--- 
Mark Elbrecht snowball3@usa.net
http://members.xoom.com/snowball3/

Re: Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

[Aagh I keep forgetting that this listserv doesn't fix the reply-to,
 and then keep forgetting to change the address in the reply to
 "egcs@egcs.cygnus.com". Those of you receiving duplicate emails
 from  me, sorry.]

At 05:40 PM 2/2/99 -0700, you wrote:
>COFF is a turd, move as far away from it as possible.  Similarly for a.out.

I couldn't agree more but the DJGPP group assures that there are grave
technical problems with moving to another format. (I suggest ELF myself...)

IMHO it was a BIG mistake for them to become thoroughly wedded to a
specific image format.

But I can't go back in time and make them use elf from the outset, nor is
it within my ethical limits to physically locate DJ Delorie, stick a gun to
his head, and force him to port it to elf (which he would probably be
unable to do correctly under such stressful circumstances anyways) :-)

Also, other platforms seem to wed GCC to COFF as well and they need to be
considered as well as us minority Micro$uck DOS users :-)

Therefore, I think a COFF-based egcs that has
a) Working debug support (Current COFF GCCs all have problems
   linking object files with lots of debug info together) and
b) Working template support
is a necessity.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

[Aagh I keep forgetting that this listserv doesn't fix the reply-to,
 and then keep forgetting to change the address in the reply to
 "egcs@egcs.cygnus.com". Those of you receiving duplicate emails
 from  me, sorry.]

At 05:40 PM 2/2/99 -0700, you wrote:
>COFF is a turd, move as far away from it as possible.  Similarly for a.out.

I couldn't agree more but the DJGPP group assures that there are grave
technical problems with moving to another format. (I suggest ELF myself...)

IMHO it was a BIG mistake for them to become thoroughly wedded to a
specific image format.

But I can't go back in time and make them use elf from the outset, nor is
it within my ethical limits to physically locate DJ Delorie, stick a gun to
his head, and force him to port it to elf (which he would probably be
unable to do correctly under such stressful circumstances anyways) :-)

Also, other platforms seem to wed GCC to COFF as well and they need to be
considered as well as us minority Micro$uck DOS users :-)

Therefore, I think a COFF-based egcs that has
a) Working debug support (Current COFF GCCs all have problems
   linking object files with lots of debug info together) and
b) Working template support
is a necessity.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Mike Stump]

> Date: Tue, 02 Feb 1999 19:37:58 -0500
> To: egcs@egcs.cygnus.com
> From: Paul Derbyshire <pderbysh@usa.net>

> I'm repeatedly assured that when either
> a) an x86 GCC comes out that supports an image format more flexible
>    than the benighted COFF or
> b) a working, robust, reliable, and transparent hack to make template
>    instantiation work without missing and duplicate symbols is put
>    into a COFF-using GCC
> it will be an egcs and it will come from here.

> So, does anyone have an estimate on when such a thing will be available?

Have you tried -frepo on coff from an egcs snapshot or egcs and ELF?
What doesn't it do that you want?  It should be there today, and it
should just work.  We see some complaints with repo every now and
then, but if you don't hit them, then they should not impact you, and
as far as ELF goes, I offhand don't recall seeing any reports that
aren't fixed with it (though I don't memorize those types of reports,
so forgive me if I am not up-to-date on the state of the art in
linkonce).

Re: Wanted: ETA for working friendly template support in EGCS.

[Mike Stump]

> Date: Tue, 02 Feb 1999 19:37:58 -0500
> To: egcs@egcs.cygnus.com
> From: Paul Derbyshire <pderbysh@usa.net>

> I'm repeatedly assured that when either
> a) an x86 GCC comes out that supports an image format more flexible
>    than the benighted COFF or
> b) a working, robust, reliable, and transparent hack to make template
>    instantiation work without missing and duplicate symbols is put
>    into a COFF-using GCC
> it will be an egcs and it will come from here.

> So, does anyone have an estimate on when such a thing will be available?

Have you tried -frepo on coff from an egcs snapshot or egcs and ELF?
What doesn't it do that you want?  It should be there today, and it
should just work.  We see some complaints with repo every now and
then, but if you don't hit them, then they should not impact you, and
as far as ELF goes, I offhand don't recall seeing any reports that
aren't fixed with it (though I don't memorize those types of reports,
so forgive me if I am not up-to-date on the state of the art in
linkonce).

Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

I'm repeatedly assured that when either
a) an x86 GCC comes out that supports an image format more flexible
   than the benighted COFF or
b) a working, robust, reliable, and transparent hack to make template
   instantiation work without missing and duplicate symbols is put
   into a COFF-using GCC
it will be an egcs and it will come from here.

So, does anyone have an estimate on when such a thing will be available? (I
understand that only an estimate can reaonably be expected, not an exact
day, minute, and microsecond.)

NOTE: "Working, robust, reliable" means that if you write compliant
C++ it will link, and it will link correctly. I.e., if you use vecor<int>
in two translation units they will link, assuming you don't make any errors
of your own.
NOTE 2: "Transparent hack" means that users of GCC/egcs will not have to
goof around with some obscure post processing commands on their sources or
.o files/will not have to mess with special cases/will not have to do
anything nonportable in their template code, most especially not
#pragmas/will not need to know quantum mechanics, general relativity, or
rocket science.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Jeffrey A Law]

  In message < 3.0.6.32.19990202193758.007f1d80@pop.netaddress.com >you write:
  > I'm repeatedly assured that when either
  > a) an x86 GCC comes out that supports an image format more flexible
  >    than the benighted COFF or
Err, like ELF?  Like we do on linux & freebsd?

  > b) a working, robust, reliable, and transparent hack to make template
  >    instantiation work without missing and duplicate symbols is put
  >    into a COFF-using GCC
  > it will be an egcs and it will come from here.
Like we already have for ELF?

COFF is a turd, move as far away from it as possible.  Similarly for a.out.


jeff

Re: Wanted: ETA for working friendly template support in EGCS.

[J. Kean Johnston]

On Tue, Feb 02, 1999 at 05:40:15PM -0700, Jeffrey A Law wrote:
> 
>   In message < 3.0.6.32.19990202193758.007f1d80@pop.netaddress.com >you write:
>   > I'm repeatedly assured that when either
>   > a) an x86 GCC comes out that supports an image format more flexible
>   >    than the benighted COFF or
> Err, like ELF?  Like we do on linux & freebsd?
And OpenServer, and UnixWare, and Solaris X86. The choices are myriad.

Kean.

Re: Wanted: ETA for working friendly template support in EGCS.

[J. Kean Johnston]

On Tue, Feb 02, 1999 at 05:40:15PM -0700, Jeffrey A Law wrote:
> 
>   In message < 3.0.6.32.19990202193758.007f1d80@pop.netaddress.com >you write:
>   > I'm repeatedly assured that when either
>   > a) an x86 GCC comes out that supports an image format more flexible
>   >    than the benighted COFF or
> Err, like ELF?  Like we do on linux & freebsd?
And OpenServer, and UnixWare, and Solaris X86. The choices are myriad.

Kean.

Re: Wanted: ETA for working friendly template support in EGCS.

[Jeffrey A Law]

  In message < 3.0.6.32.19990202193758.007f1d80@pop.netaddress.com >you write:
  > I'm repeatedly assured that when either
  > a) an x86 GCC comes out that supports an image format more flexible
  >    than the benighted COFF or
Err, like ELF?  Like we do on linux & freebsd?

  > b) a working, robust, reliable, and transparent hack to make template
  >    instantiation work without missing and duplicate symbols is put
  >    into a COFF-using GCC
  > it will be an egcs and it will come from here.
Like we already have for ELF?

COFF is a turd, move as far away from it as possible.  Similarly for a.out.


jeff

Re: Wanted: ETA for working friendly template support in EGCS.

[Zack Weinberg]

On Tue, 02 Feb 1999 19:37:58 -0500, Paul Derbyshire wrote:
>I'm repeatedly assured that when either
>a) an x86 GCC comes out that supports an image format more flexible
>   than the benighted COFF or
>b) a working, robust, reliable, and transparent hack to make template
>   instantiation work without missing and duplicate symbols is put
>   into a COFF-using GCC
>it will be an egcs and it will come from here.
>
>So, does anyone have an estimate on when such a thing will be available? (I
>understand that only an estimate can reaonably be expected, not an exact
>day, minute, and microsecond.)

GCC (not just egcs) already supports x86 image formats other than COFF: a.out
(several variants), ELF, ROSE, etc.  If your operating system doesn't
support anything other than COFF, there are these things called `Linux' and
`FreeBSD' that you may be interested in.

In fact, on ELF systems, we do have better template instantiation.  It still
isn't perfect.  There are people working on it, but the best time estimate
is "eventually".  You could speed things up by contributing code, kibitzing
over other people's code, testing other people's code, describing in detail
why what we have is inadequate and what you would like it to do, etc. etc.

zw

Re: Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

At 07:52 PM 2/2/99 -0500, you wrote:
>GCC (not just egcs) already supports x86 image formats other than COFF: a.out
>(several variants)

Blows hard smelly rabbit chunks. Next...

>ELF

Gimme gimme... but DJGPP seems to be wedded to COFF

>If your operating system doesn't support anything other than COFF, there
are these things called `Linux' and
>`FreeBSD' that you may be interested in.

Yeah. I'm quite interested in "Linux", and therefore in "a very very large
slave EIDE drive", and therefore in "winning the lottery". :-)

The other alternative being "deleting half my hd stuff" and "making another
backup on Zip disks" prior to "getting and using partition magic" after
obtaining "a shitload of money to buy partition magic".
:-)

>You could speed things up by contributing code

With all the other stuff I have my hands full with? I couldn't begin to
even *understand* the code involved in this without spending years poring
over sources and obscure man files.

>kibitzing over other people's code

Same problems...

>testing other people's code

Give me a DJGPP-compatible DOS x86 binary for an experimental egcs with
fixed COFF template support and I'll be willing to see how many copies of
"vector<int>::_lenghts[]" the linker finds compiling some simple template
testing dummy code.

>describing in detail why what we have is inadequate

ANSI C++ template support is not complete. (Namespaces too still, last I
hear.) Indeed, C++ is thoroughly crippled because you can only use
vector<int> in one translation unit, and you can only use rope<char> in one
translation unit, and .........

>and what you would like it to do.

A very simple thing: working template linkage.

IOW, right now, any template with static functions or variables can't be
used in more than one translation unit, including nearly all of the STL; I
would like to have these template situations link just fine, without any of
these:
* Having to use nonportable #pragmas
* Having to postprocess the sources or .o files in any way before
  compiling/linking, manually or by invoking weird extra utility
  applets.
* Having to (God forbid!) limit the use of static-containing template
instances to one translation unit per instance.

IIRC, inline member functions or other inline functions in a header
included in multiple translation units, and using static member variables,
also trigger the bug.


Okay. Now you have me thinking about it, and I have some code for you. Just
pseudo code for two alternative hacks, which involve changes to ld and in
one case to cc1plus and cpp as well.


The simplest hack solution I can think of is not perfectly robust in that
it may cause the linker to miss real errors on rare occasions.
(Read below for a surefire but more complicated hack.)
It entails changing the line in the ld sources that, inside an if that
detected a duplicate symbol, prints an error message and aborts, to
something like this pseudo-code tries to express:

if (new_symbol is_in list_of_existing_symbols) {
  // log error "duplicate symbol"...  no, scratch that
  bool dserror=true;
  other_symbol = find_in_existing_symbols(new_symbol);
  if (new_symbol is_static) {
    if (new_symbol is_in_inline_func || new_symbol is_template_class_member) {
      dserror=false;
    }
  }
  if (dserror) { // Log error, etc.
}


This and a bit more like it will make the linker merge duplicate static
symbols in either a template class body or an inline function.
The rare real error it will thus overlook and which will cause some weird
runtime behavior that can hopefully be resolved by debugging will be far
outweighed by the benefit of fixed C++ support.

A more cumbersome but more robust alternative:

1. Make the preprocessor treat #includes in C++ source differently:
   a. While reprocessing the included file, compute a hash of the
  included file.
   b. Bracket the included header material in a pair of "compiler
      directives" that signal the start and end of a header file and
      include the hash.
   The directive can have the format #enter <hash> and #end. Since
   anything in the source in those locations using a # would have
   been already used by the preprocessor as a preprocessor directive
   the compiler will know that the #foo are directives and not
   normal code.
2. Make cc1plus manage the "compiler directives" by including the
   hash for the current #enter/#end block when mangling the names of
   static template symbols and static symbols inside inline
   functions. For example, the preprocessed code

#enter foohash
inline void foo1 (void) { static int foovar_1; }
#enter barhash
inline void foo2 (void) { static int foovar_2; }
#end
inline void foo3 (void) { static int foovar_3; }
#end

   will mean that if and when these are instantiated in that
   translation unit, foovar_1 and foovar_3 will be mangled with
   foohash and foovar_2 will be mangled with barhash. The hash
   must be a specific part of the mangled name, say a suffix, that
   can be peeled off to give the usual GCC C++ mangled name for the
   variable by, say, removing the second to final underscore and
   anything following it. It must also be detectable: the presence of
   the hash can be indicated by ending a symbol with an underscore
   and never ending an unhashmarked symbol with one. So an unhashed
   symbol might become _mangled and the same symbol hashed become
   _mangled_hash_ so the oroginal can be recovered by noting the
   trailing _, finding the previous _, and removing it and everything
   after to recover _mangled.

3. Then cc1plus must also check for duplicate symbol definitions in    
   the same translation unit and flag those.

4. Last, the linker goes through all the .o files and performs three
   special actions:
   i.   It checks for duplicate hashed symbol definitions and merges
        them. They are from the same header and they weren't in the
        same translation unit or cc1plus would have puked. So they
        are the same symbol defined in the same header in an inline
        or template and instantiated in multiple source files and
        should be merged.
   ii.  For every hashed symbol, removes the hash from the symbol
        name. 
   iii. Scans all symbols for duplicate definitions and reports
        errors in traditional fashion.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

At 07:52 PM 2/2/99 -0500, you wrote:
>GCC (not just egcs) already supports x86 image formats other than COFF: a.out
>(several variants)

Blows hard smelly rabbit chunks. Next...

>ELF

Gimme gimme... but DJGPP seems to be wedded to COFF

>If your operating system doesn't support anything other than COFF, there
are these things called `Linux' and
>`FreeBSD' that you may be interested in.

Yeah. I'm quite interested in "Linux", and therefore in "a very very large
slave EIDE drive", and therefore in "winning the lottery". :-)

The other alternative being "deleting half my hd stuff" and "making another
backup on Zip disks" prior to "getting and using partition magic" after
obtaining "a shitload of money to buy partition magic".
:-)

>You could speed things up by contributing code

With all the other stuff I have my hands full with? I couldn't begin to
even *understand* the code involved in this without spending years poring
over sources and obscure man files.

>kibitzing over other people's code

Same problems...

>testing other people's code

Give me a DJGPP-compatible DOS x86 binary for an experimental egcs with
fixed COFF template support and I'll be willing to see how many copies of
"vector<int>::_lenghts[]" the linker finds compiling some simple template
testing dummy code.

>describing in detail why what we have is inadequate

ANSI C++ template support is not complete. (Namespaces too still, last I
hear.) Indeed, C++ is thoroughly crippled because you can only use
vector<int> in one translation unit, and you can only use rope<char> in one
translation unit, and .........

>and what you would like it to do.

A very simple thing: working template linkage.

IOW, right now, any template with static functions or variables can't be
used in more than one translation unit, including nearly all of the STL; I
would like to have these template situations link just fine, without any of
these:
* Having to use nonportable #pragmas
* Having to postprocess the sources or .o files in any way before
  compiling/linking, manually or by invoking weird extra utility
  applets.
* Having to (God forbid!) limit the use of static-containing template
instances to one translation unit per instance.

IIRC, inline member functions or other inline functions in a header
included in multiple translation units, and using static member variables,
also trigger the bug.


Okay. Now you have me thinking about it, and I have some code for you. Just
pseudo code for two alternative hacks, which involve changes to ld and in
one case to cc1plus and cpp as well.


The simplest hack solution I can think of is not perfectly robust in that
it may cause the linker to miss real errors on rare occasions.
(Read below for a surefire but more complicated hack.)
It entails changing the line in the ld sources that, inside an if that
detected a duplicate symbol, prints an error message and aborts, to
something like this pseudo-code tries to express:

if (new_symbol is_in list_of_existing_symbols) {
  // log error "duplicate symbol"...  no, scratch that
  bool dserror=true;
  other_symbol = find_in_existing_symbols(new_symbol);
  if (new_symbol is_static) {
    if (new_symbol is_in_inline_func || new_symbol is_template_class_member) {
      dserror=false;
    }
  }
  if (dserror) { // Log error, etc.
}


This and a bit more like it will make the linker merge duplicate static
symbols in either a template class body or an inline function.
The rare real error it will thus overlook and which will cause some weird
runtime behavior that can hopefully be resolved by debugging will be far
outweighed by the benefit of fixed C++ support.

A more cumbersome but more robust alternative:

1. Make the preprocessor treat #includes in C++ source differently:
   a. While reprocessing the included file, compute a hash of the
  included file.
   b. Bracket the included header material in a pair of "compiler
      directives" that signal the start and end of a header file and
      include the hash.
   The directive can have the format #enter <hash> and #end. Since
   anything in the source in those locations using a # would have
   been already used by the preprocessor as a preprocessor directive
   the compiler will know that the #foo are directives and not
   normal code.
2. Make cc1plus manage the "compiler directives" by including the
   hash for the current #enter/#end block when mangling the names of
   static template symbols and static symbols inside inline
   functions. For example, the preprocessed code

#enter foohash
inline void foo1 (void) { static int foovar_1; }
#enter barhash
inline void foo2 (void) { static int foovar_2; }
#end
inline void foo3 (void) { static int foovar_3; }
#end

   will mean that if and when these are instantiated in that
   translation unit, foovar_1 and foovar_3 will be mangled with
   foohash and foovar_2 will be mangled with barhash. The hash
   must be a specific part of the mangled name, say a suffix, that
   can be peeled off to give the usual GCC C++ mangled name for the
   variable by, say, removing the second to final underscore and
   anything following it. It must also be detectable: the presence of
   the hash can be indicated by ending a symbol with an underscore
   and never ending an unhashmarked symbol with one. So an unhashed
   symbol might become _mangled and the same symbol hashed become
   _mangled_hash_ so the oroginal can be recovered by noting the
   trailing _, finding the previous _, and removing it and everything
   after to recover _mangled.

3. Then cc1plus must also check for duplicate symbol definitions in    
   the same translation unit and flag those.

4. Last, the linker goes through all the .o files and performs three
   special actions:
   i.   It checks for duplicate hashed symbol definitions and merges
        them. They are from the same header and they weren't in the
        same translation unit or cc1plus would have puked. So they
        are the same symbol defined in the same header in an inline
        or template and instantiated in multiple source files and
        should be merged.
   ii.  For every hashed symbol, removes the hash from the symbol
        name. 
   iii. Scans all symbols for duplicate definitions and reports
        errors in traditional fashion.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Wanted: ETA for working friendly template support in EGCS.

[Zack Weinberg]

On Tue, 02 Feb 1999 19:37:58 -0500, Paul Derbyshire wrote:
>I'm repeatedly assured that when either
>a) an x86 GCC comes out that supports an image format more flexible
>   than the benighted COFF or
>b) a working, robust, reliable, and transparent hack to make template
>   instantiation work without missing and duplicate symbols is put
>   into a COFF-using GCC
>it will be an egcs and it will come from here.
>
>So, does anyone have an estimate on when such a thing will be available? (I
>understand that only an estimate can reaonably be expected, not an exact
>day, minute, and microsecond.)

GCC (not just egcs) already supports x86 image formats other than COFF: a.out
(several variants), ELF, ROSE, etc.  If your operating system doesn't
support anything other than COFF, there are these things called `Linux' and
`FreeBSD' that you may be interested in.

In fact, on ELF systems, we do have better template instantiation.  It still
isn't perfect.  There are people working on it, but the best time estimate
is "eventually".  You could speed things up by contributing code, kibitzing
over other people's code, testing other people's code, describing in detail
why what we have is inadequate and what you would like it to do, etc. etc.

zw

Wanted: ETA for working friendly template support in EGCS.

[Paul Derbyshire]

I'm repeatedly assured that when either
a) an x86 GCC comes out that supports an image format more flexible
   than the benighted COFF or
b) a working, robust, reliable, and transparent hack to make template
   instantiation work without missing and duplicate symbols is put
   into a COFF-using GCC
it will be an egcs and it will come from here.

So, does anyone have an estimate on when such a thing will be available? (I
understand that only an estimate can reaonably be expected, not an exact
day, minute, and microsecond.)

NOTE: "Working, robust, reliable" means that if you write compliant
C++ it will link, and it will link correctly. I.e., if you use vecor<int>
in two translation units they will link, assuming you don't make any errors
of your own.
NOTE 2: "Transparent hack" means that users of GCC/egcs will not have to
goof around with some obscure post processing commands on their sources or
.o files/will not have to mess with special cases/will not have to do
anything nonportable in their template code, most especially not
#pragmas/will not need to know quantum mechanics, general relativity, or
rocket science.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|