* Re:
@ 2002-10-18 16:20 Josep Maria
2002-10-18 16:22 ` Re: Josep Maria
0 siblings, 1 reply; 38+ messages in thread
From: Josep Maria @ 2002-10-18 16:20 UTC (permalink / raw)
To: gcc
[-- Attachment #1.1: Type: text/plain, Size: 2108 bytes --]
Untitled Document
Problemas de seguridad de Outlook Express: sale otro parche.
La vulnerabilidad encontrada es bastante seria y permite a los hackers o bien bloquear el funcionamiento del programa, o lo que es peor, ejecutar un código cualquiera en la máquina..
Casio CW-100: nueva impresora térmica para discos CD/DVD.
¿Será la frecuencia funcional recomendada del NV30 igual a 400 MHz?
Sistema acústico SP 53 de 5.1 canales de ABIT: especificaciones y precios.
Los paleontólogos por primera vez obtienen una momia de un dinosaurio en condiciones óptimas.
El cadaver momificado del dinosaurio, que estuvo enterrado debajo de la tierra durante 77 millones de años, fue encontrado al norte del estado de Montana, nos cuenta Nationalgeografic.com. El hallazgo lo llamaron Leonardo en honor a un graffiti pintado cerca (Leonard Webb and Geneva Jordan, 1917). Leonardo es un dinosaurio ...
A los pobladores de Alaska les aterroriza un pterodáctilo gigante.
El tratamiento genético contra la calvicie hará que el pelo brille con colores amarillo, verde, azul o rojo.
La estación espacial sigue en obras.
Mecano Lego: estructuras en cuatro dimensiones.
Hay gente que afirma ser constructores profesionales de mecano. Estas afirmaciones afectan sobre todo los famoso mecanos Lego. Asimismo, un hombre llamado Andrew Lipson afirma ser el professional nerd. De su arte vamos a hablar hoy...
Clonacion humana es imposible, pero inevitable.
Hoy en dia, cuando ya se sabe que ir y hacer un ejercito de clones - casihumanos idénticos - es imposible, la situación de la clonación humana es precaria. No podemos esperar nada sensacional, pero...
www.xtio.com
[-- Attachment #1.2: Type: text/html, Size: 12416 bytes --]
[-- Attachment #2: zero.gif --]
[-- Type: image/gif, Size: 43 bytes --]
[-- Attachment #3: enov.gif --]
[-- Type: image/gif, Size: 1120 bytes --]
[-- Attachment #4: xnov.gif --]
[-- Type: image/gif, Size: 1181 bytes --]
[-- Attachment #5: 3605.jpg --]
[-- Type: image/jpeg, Size: 3131 bytes --]
[-- Attachment #6: verccompl4.gif --]
[-- Type: image/gif, Size: 857 bytes --]
[-- Attachment #7: ball.gif --]
[-- Type: image/gif, Size: 145 bytes --]
[-- Attachment #8: 3589.jpg --]
[-- Type: image/jpeg, Size: 2082 bytes --]
[-- Attachment #9: clocas.gif --]
[-- Type: image/gif, Size: 388 bytes --]
[-- Attachment #10: cienciad.gif --]
[-- Type: image/gif, Size: 445 bytes --]
[-- Attachment #11: 3386.jpg --]
[-- Type: image/jpeg, Size: 4118 bytes --]
[-- Attachment #12: 3316.jpg --]
[-- Type: image/jpeg, Size: 2631 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2002-10-18 16:20 Josep Maria
@ 2002-10-18 16:22 ` Josep Maria
0 siblings, 0 replies; 38+ messages in thread
From: Josep Maria @ 2002-10-18 16:22 UTC (permalink / raw)
To: gcc
[-- Attachment #1.1: Type: text/plain, Size: 2108 bytes --]
Untitled Document
Problemas de seguridad de Outlook Express: sale otro parche.
La vulnerabilidad encontrada es bastante seria y permite a los hackers o bien bloquear el funcionamiento del programa, o lo que es peor, ejecutar un código cualquiera en la máquina..
Casio CW-100: nueva impresora térmica para discos CD/DVD.
¿Será la frecuencia funcional recomendada del NV30 igual a 400 MHz?
Sistema acústico SP 53 de 5.1 canales de ABIT: especificaciones y precios.
Los paleontólogos por primera vez obtienen una momia de un dinosaurio en condiciones óptimas.
El cadaver momificado del dinosaurio, que estuvo enterrado debajo de la tierra durante 77 millones de años, fue encontrado al norte del estado de Montana, nos cuenta Nationalgeografic.com. El hallazgo lo llamaron Leonardo en honor a un graffiti pintado cerca (Leonard Webb and Geneva Jordan, 1917). Leonardo es un dinosaurio ...
A los pobladores de Alaska les aterroriza un pterodáctilo gigante.
El tratamiento genético contra la calvicie hará que el pelo brille con colores amarillo, verde, azul o rojo.
La estación espacial sigue en obras.
Mecano Lego: estructuras en cuatro dimensiones.
Hay gente que afirma ser constructores profesionales de mecano. Estas afirmaciones afectan sobre todo los famoso mecanos Lego. Asimismo, un hombre llamado Andrew Lipson afirma ser el professional nerd. De su arte vamos a hablar hoy...
Clonacion humana es imposible, pero inevitable.
Hoy en dia, cuando ya se sabe que ir y hacer un ejercito de clones - casihumanos idénticos - es imposible, la situación de la clonación humana es precaria. No podemos esperar nada sensacional, pero...
www.xtio.com
[-- Attachment #1.2: Type: text/html, Size: 12416 bytes --]
[-- Attachment #2: zero.gif --]
[-- Type: image/gif, Size: 43 bytes --]
[-- Attachment #3: enov.gif --]
[-- Type: image/gif, Size: 1120 bytes --]
[-- Attachment #4: xnov.gif --]
[-- Type: image/gif, Size: 1181 bytes --]
[-- Attachment #5: 3605.jpg --]
[-- Type: image/jpeg, Size: 3131 bytes --]
[-- Attachment #6: verccompl4.gif --]
[-- Type: image/gif, Size: 857 bytes --]
[-- Attachment #7: ball.gif --]
[-- Type: image/gif, Size: 145 bytes --]
[-- Attachment #8: 3589.jpg --]
[-- Type: image/jpeg, Size: 2082 bytes --]
[-- Attachment #9: clocas.gif --]
[-- Type: image/gif, Size: 388 bytes --]
[-- Attachment #10: cienciad.gif --]
[-- Type: image/gif, Size: 445 bytes --]
[-- Attachment #11: 3386.jpg --]
[-- Type: image/jpeg, Size: 4118 bytes --]
[-- Attachment #12: 3316.jpg --]
[-- Type: image/jpeg, Size: 2631 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* (no subject)
@ 2024-01-05 9:57 Nani Rodrigue
2024-01-05 10:34 ` Jonathan Wakely
0 siblings, 1 reply; 38+ messages in thread
From: Nani Rodrigue @ 2024-01-05 9:57 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 88 bytes --]
Good morning
Can I get the last version of an application of gcc for Windows ?
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2024-01-05 9:57 Nani Rodrigue
@ 2024-01-05 10:34 ` Jonathan Wakely
2024-01-05 10:58 ` Re: LIU Hao
0 siblings, 1 reply; 38+ messages in thread
From: Jonathan Wakely @ 2024-01-05 10:34 UTC (permalink / raw)
To: Nani Rodrigue; +Cc: gcc
On Fri, 5 Jan 2024 at 10:33, Nani Rodrigue via Gcc <gcc@gcc.gnu.org> wrote:
>
> Good morning
>
> Can I get the last version of an application of gcc for Windows ?
Not from here, no. See https://gcc.gnu.org/install/binaries.html
There are also the https://nuwen.net/mingw.html and
https://jmeubank.github.io/tdm-gcc/download/ projects, but they both
use outdated versions of GCC at the moment.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2024-01-05 10:34 ` Jonathan Wakely
@ 2024-01-05 10:58 ` LIU Hao
0 siblings, 0 replies; 38+ messages in thread
From: LIU Hao @ 2024-01-05 10:58 UTC (permalink / raw)
To: Jonathan Wakely, Nani Rodrigue; +Cc: gcc
[-- Attachment #1.1: Type: text/plain, Size: 409 bytes --]
在 2024/1/5 18:34, Jonathan Wakely via Gcc 写道:
> There are also the https://nuwen.net/mingw.html and
> https://jmeubank.github.io/tdm-gcc/download/ projects, but they both
> use outdated versions of GCC at the moment.
Wrong mailing list; but anyway, for bleeding-edge updates, with other well managed packages, we
generally recommend https://www.msys2.org/.
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* (no subject)
@ 2023-11-18 21:22 Zebediah Beck
2023-11-18 23:52 ` David Edelsohn
0 siblings, 1 reply; 38+ messages in thread
From: Zebediah Beck @ 2023-11-18 21:22 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 70 bytes --]
I would like that contribute technical documentation to the community
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2023-11-18 21:22 Zebediah Beck
@ 2023-11-18 23:52 ` David Edelsohn
2023-11-18 23:57 ` Re: Zebediah Beck
0 siblings, 1 reply; 38+ messages in thread
From: David Edelsohn @ 2023-11-18 23:52 UTC (permalink / raw)
To: Zebediah Beck; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
On Sat, Nov 18, 2023 at 4:23 PM Zebediah Beck via Gcc <gcc@gcc.gnu.org>
wrote:
> I would like that contribute technical documentation to the community.
>
Hi, Zebediah
Thanks for your interest in GCC. Welcome!
Improvements to the GCC technical documentation would be a wonderful
contribution.
We also would be happy to try to sponsor you and other documentation
writers through the Google Season of Docs program.
Thanks, David
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2023-11-18 23:52 ` David Edelsohn
@ 2023-11-18 23:57 ` Zebediah Beck
0 siblings, 0 replies; 38+ messages in thread
From: Zebediah Beck @ 2023-11-18 23:57 UTC (permalink / raw)
To: David Edelsohn; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
Thank you for your response. Wonderful opportunity it would be to work with
such an awesome community of dedicated people! I have admired the GCC
team's work on the Gnu toolkit for a long time.
On Sun, 19 Nov 2023, 01:52 David Edelsohn, <dje.gcc@gmail.com> wrote:
> On Sat, Nov 18, 2023 at 4:23 PM Zebediah Beck via Gcc <gcc@gcc.gnu.org>
> wrote:
>
>> I would like that contribute technical documentation to the community.
>>
>
> Hi, Zebediah
>
> Thanks for your interest in GCC. Welcome!
>
> Improvements to the GCC technical documentation would be a wonderful
> contribution.
>
> We also would be happy to try to sponsor you and other documentation
> writers through the Google Season of Docs program.
>
> Thanks, David
>
>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2023-01-13 5:41 father.dominic
0 siblings, 0 replies; 38+ messages in thread
From: father.dominic @ 2023-01-13 5:41 UTC (permalink / raw)
To: father.dominic
Hello
I'm obliged to inform you that a monetary donation of $800,000.00 USD has
been awarded to you. Contact stef@stefaniekoren.com for more information.
Regards.
^ permalink raw reply [flat|nested] 38+ messages in thread
* (no subject)
@ 2022-05-22 21:20 Skrab Skrab
2022-05-22 22:12 ` David Edelsohn
0 siblings, 1 reply; 38+ messages in thread
From: Skrab Skrab @ 2022-05-22 21:20 UTC (permalink / raw)
To: gcc
How can i contribute to gcc.
^ permalink raw reply [flat|nested] 38+ messages in thread
* (no subject)
@ 2021-06-12 23:32 nayeemislam031702
2021-06-12 23:35 ` Aaron Gyes
0 siblings, 1 reply; 38+ messages in thread
From: nayeemislam031702 @ 2021-06-12 23:32 UTC (permalink / raw)
To: gcc; +Cc: nayeemislam031702
Sent from my Samsung Galaxy smartphone.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2011-09-23 22:54 Lawrence Gutsin
0 siblings, 0 replies; 38+ messages in thread
From: Lawrence Gutsin @ 2011-09-23 22:54 UTC (permalink / raw)
To: gaoxiwu, gaoyifei1216, gaoyongli214, gaoyuanxsb, gcc, gcc209
You are tired of overweight? Don�t worry!..
http://www.vive-la-sante.com/com.page.php?ovPage=80o3
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2011-06-29 15:42 nicole8509
0 siblings, 0 replies; 38+ messages in thread
From: nicole8509 @ 2011-06-29 15:42 UTC (permalink / raw)
To: gaotian303, gcc, gdc_zp, gdszlyw, gee28, ggjgx
It�s a brill site where you can buy everything you want!.
http://theplugnpray.net/best2011.php?ohpage=56m4
^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <20080618135807.GA15427@bromo.msbb.uc.edu>]
* Re:
@ 2008-01-10 16:29 Selina Ewing
0 siblings, 0 replies; 38+ messages in thread
From: Selina Ewing @ 2008-01-10 16:29 UTC (permalink / raw)
To: gcc
Life can be a different thing for you now!
Why wait?!WE now happy to introduce to you a tatally different option to acquire your qualification online!Whatever your specialization is now obtaining your diploma degree becomes a reality.
Lot's of people worldwide appreciated this unique opportunity of getting bachelorÂs, PHÂs, and MasterÂs through the net.
And plus you now able to reach your aim almoust instantly.The missing brick is right there! Call us 1 206 888-2083 for 24/7. You can proudly grasp your diploma within days!
^ permalink raw reply [flat|nested] 38+ messages in thread
* (no subject)
@ 2005-08-01 14:18 Chunjiang Li
2005-08-01 14:37 ` Daniel Berlin
0 siblings, 1 reply; 38+ messages in thread
From: Chunjiang Li @ 2005-08-01 14:18 UTC (permalink / raw)
To: gcc
Hi, all:
Also the problem about Pseudo register usage.
I want to know the Pseudo registers used (def and ref) in a basic block.
How can I get these result using the APIs presented in GCC?
Need help. Urgently
Chunjiang Li
Creative Compiler Research Group,
National University of Defense Technology, China.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2005-07-15 21:22 ИнфоПространство
0 siblings, 0 replies; 38+ messages in thread
From: ИнфоПространство @ 2005-07-15 21:22 UTC (permalink / raw)
To: gcc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original, Size: 2486 bytes --]
=- ÊÎÐÏÎÐÀÒÈÂÍÛÅ ÌÅÐÎÏÐÈßÒÈß -=
=- ÍÀ ÎÑÒÎÆÅÍÊÅ ÍÀ 2000 êâ.ì -=
êîíôåðåíöèè, ñåìèíàðû, ñîáðàíèÿ
âûñòàâêè, ïðåçåíòàöèè, ïðàçäíèêè
áàíêåòû, ôóðøåòû
1. Ôóíêöèîíàëüíàÿ ïðèíàäëåæíîñòü: Öåíòð ïðåäíàçíà÷åí äëÿ ïðîâåäåíèÿ âûñòàâîê, êîíôåðåíöèé, ñåìèíàðîâ, ïðåçåíòàöèé, ïîêàçîâ è ïðàçäíè÷íûõ ìåðîïðèÿòèé.
2. Ìåñòîíàõîæäåíèå: Èñòîðè÷åñêèé öåíòð, 300 ìåòðîâ îò Õðàìà Õðèñòà Ñïàñèòåëÿ, ì.Êðîïîòêèíñêàÿ, ìèêð-í Îñòîæåíêà, 50 ìåòðîâ îò Ïðå÷èñòåíñêîé íàá.
3. Òåõíè÷åñêèå õàðàêòåðèñòèêè: Îáùàÿ ïëîùàäü öåíòðà 2000 êâ.ì, óíèâåðñàëüíûé çàë-òðàíñôîðìåð ñ äèàïàçîíîì ïëîùàäåé îò 20 äî 1500 êâ.ì, 2 VIP-çàëà, Êàôå-ïèööåðèÿ-êîíäèòåðñêàÿ.
4. Îñîáåííîñòè:
- Ñïåöèàëüíûå âûñòàâî÷íûå ñòåíäû äî ïîòîëêà ñ ðàçëè÷íîé öâåòîâîé è ôóíêöèîíàëüíîé ãàììîé.
- Âîçìîæíîñòü ýêñïîíèðîâàíèÿ àâòîìîáèëåé.
- Âñòðîåííîå â ïîòîëîê âûñòàâî÷íîå îñâåùåíèå.
- Øèðîêèé âûáîð ìåáåëè.
- 2 ñöåíû
- 2 âõîäà: öåíòðàëüíûé è òåõíè÷åñêèé.
- Âûñîêîêà÷åñòâåííîå êîâðîâîå ïîêðûòèå
- Ïðîôåññèîíàëüíîå çâóêîóñèëèòåëüíîå îáîðóäîâàíèå.
Êîíôåðåíö-ïàêåò îò 36 ó.å. Âíóòð. êóðñ êîìïàíèè: 1 ó.å.=30 ðóá.
Äèðåêòîð ïî ðàçâèòèþ áèçíåñà è îðãàíèçàöèè êîðïîðàòèâíûõ ìåðîïðèÿòèé:
Ñàâðàñîâà Íàòàëüÿ òåë.: 290-0621, 290-7241, 290-00-66; ô.: 290-0649
-------------------------------------------
Ìåæäóíàðîäíûé
èíôîðìàöèîííî-
âûñòàâî÷íûé öåíòð
=- ÈíôîÏðîñòðàíñòâî -=
1-é Çà÷àòüåâñêèé ïåð.,4
òåë. (095) 290~72~41
ôàêñ (095) 202~9~245
\0
^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <m3d5q5b0pw.fsf@localhost.localdomain>]
* Re:
[not found] <m3d5q5b0pw.fsf@localhost.localdomain>
@ 2005-06-29 18:48 ` Bryce McKinlay
2005-06-29 20:40 ` Re: Mark Mitchell
0 siblings, 1 reply; 38+ messages in thread
From: Bryce McKinlay @ 2005-06-29 18:48 UTC (permalink / raw)
To: tromey; +Cc: Java Patch List, gcc, Mark Mitchell
Tom Tromey wrote:
>I'm checking this in on the trunk. If I remember I'll put it on the
>4.0 branch once it reopens (there are a fair number of patches pending
>for it ... I hope it reopens soon).
>
>
Mark,
The extended freeze of the 4.0 branch is making things difficult for
libgcj because we have a large backlog of runtime patches which we are
unable to apply at this time. The longer the freeze continues, the more
difficult it becomes for us to keep track of what needs applying and
increases the chances that something will be forgotten, resulting in
problems and wasted time further down the line.
Could we get an exemption from the freeze rules for low-risk, runtime
only libgcj fixes as determined by the libgcj maintainers?
Alternatively, could we rethink our release policy to ensure that the
duration of freezes is minimized in the future? I do think that a hard
freeze in the days leading up to a release is useful and important, but
keeping it in place for weeks just because a couple of bugs remain
unfixed doesn't seem helpful.
Thanks
Bryce
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2005-06-29 18:48 ` Re: Bryce McKinlay
@ 2005-06-29 20:40 ` Mark Mitchell
2005-06-29 21:54 ` Re: Jeffrey A Law
2005-06-29 21:57 ` Re: Geoffrey Keating
0 siblings, 2 replies; 38+ messages in thread
From: Mark Mitchell @ 2005-06-29 20:40 UTC (permalink / raw)
To: Bryce McKinlay; +Cc: tromey, Java Patch List, gcc
Bryce McKinlay wrote:
>
> Mark,
> Could we get an exemption from the freeze rules for low-risk, runtime
> only libgcj fixes as determined by the libgcj maintainers?
I don't think we want to do that.
First, we're close to a release. We've been waiting on one fix since
Friday, and Jeff Law has promised to fix it today.
Second, the whole point of freezes is to ensure stability. We're going
to RC3 on this release because we've found bad problems in RC1 and RC2.
If a change were to be checked in, for whatever reason, happens to
break something, then we need an RC4, and everybody loses.
> Alternatively, could we rethink our release policy to ensure that the
> duration of freezes is minimized in the future? I do think that a hard
> freeze in the days leading up to a release is useful and important, but
> keeping it in place for weeks just because a couple of bugs remain
> unfixed doesn't seem helpful.
Obviously, I'd like to have a shorter freeze period. This is the
longest pre-release freeze I can remember since I've been running
releases. That reflects the fact that a lot of critical problems were
uncovered in 4.0.0, including some during the 4.0.1 release process.
The way to get a shorter freeze period is to have fewer bugs and to fix
them more quickly. I think that this release is somewhat exceptional in
that after we released 4.0.0, a lot of people started using a lot of new
technology, and, unsurprisingly, there are more bugs in 4.0.0 than in
the average release.
Please hang in there.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Re:
2005-06-29 20:40 ` Re: Mark Mitchell
@ 2005-06-29 21:54 ` Jeffrey A Law
2005-06-29 23:17 ` Re: Joe Buck
2005-06-29 21:57 ` Re: Geoffrey Keating
1 sibling, 1 reply; 38+ messages in thread
From: Jeffrey A Law @ 2005-06-29 21:54 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Bryce McKinlay, tromey, Java Patch List, gcc
On Wed, 2005-06-29 at 13:39 -0700, Mark Mitchell wrote:
> First, we're close to a release. We've been waiting on one fix since
> Friday, and Jeff Law has promised to fix it today.
The fix is written, I'm just waiting on test results. Someone mucked
up the hpux11 target description (*) which caused libstdc++ to fail to
build and I had to re-bootstrap after working around that bit of
lameness.
I'd be surprised if I had results tonight. More likely early tomorrow
assuming the machines keep running (I killed one in Raleigh yesterday
to go along with the one in my basement...)
Jeff
(*) The hpux11 target description assumes that the linker shipped with
hpux11 supports +init as an option. Well, that may work OK for some
versions of hpux11, but it certainly doesn't work for hpux11.00 with
the 990903 version of the linker. Grrr.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Re:
2005-06-29 21:54 ` Re: Jeffrey A Law
@ 2005-06-29 23:17 ` Joe Buck
0 siblings, 0 replies; 38+ messages in thread
From: Joe Buck @ 2005-06-29 23:17 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: Mark Mitchell, Bryce McKinlay, tromey, Java Patch List, gcc
On Wed, Jun 29, 2005 at 03:53:18PM -0600, Jeffrey A Law wrote:
> (*) The hpux11 target description assumes that the linker shipped with
> hpux11 supports +init as an option. Well, that may work OK for some
> versions of hpux11, but it certainly doesn't work for hpux11.00 with
> the 990903 version of the linker. Grrr.
I have an hpux11.0 box available, and could run tests of your patch
if you like.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2005-06-29 20:40 ` Re: Mark Mitchell
2005-06-29 21:54 ` Re: Jeffrey A Law
@ 2005-06-29 21:57 ` Geoffrey Keating
2005-06-29 23:43 ` Re: Aalokrai Porwal
1 sibling, 1 reply; 38+ messages in thread
From: Geoffrey Keating @ 2005-06-29 21:57 UTC (permalink / raw)
To: Mark Mitchell; +Cc: tromey, Java Patch List, gcc
Mark Mitchell <mark@codesourcery.com> writes:
> Bryce McKinlay wrote:
>
> > Mark,
>
> > Could we get an exemption from the freeze rules for low-risk,
> > runtime only libgcj fixes as determined by the libgcj maintainers?
>
> I don't think we want to do that.
>
> First, we're close to a release. We've been waiting on one fix since
> Friday, and Jeff Law has promised to fix it today.
>
> Second, the whole point of freezes is to ensure stability. We're
> going to RC3 on this release because we've found bad problems in RC1
> and RC2. If a change were to be checked in, for whatever reason,
> happens to break something, then we need an RC4, and everybody loses.
This kind of conflict is solved in version control systems by the use
of branches...
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2004-12-11 3:30 Лада Власовна
0 siblings, 0 replies; 38+ messages in thread
From: Лада Власовна @ 2004-12-11 3:30 UTC (permalink / raw)
To: gcc
Г‚Гèìà ГГЁГҐ à êöèÿ!
Çà êà æèòå äî 20 Г¤ekaáðÿ Г…-ìà il paccûëêy ГЁ noГ«yГ·ГЁ ГЎГ®ГГіГ±(paccûëêy ГЇГ® icq)....
agee@3432.cjb.net
\0
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2004-11-29 5:11 Елена Климентьевна
0 siblings, 0 replies; 38+ messages in thread
From: Елена Климентьевна @ 2004-11-29 5:11 UTC (permalink / raw)
To: gcc
Г‚Гèìà ГГЁГҐ!
Òîëüêî äî 1 äåêà áðÿ 2OO4 ãîäà âû ñìîæåòå çà êà çà òü Г…-Mail paccûëêó(ïëà òГГ®) ГЁ ïîëó÷èòü paccûëêó ГЇГ® icq(áåñïëà òГГ®)....
annotate@e881.cjb.net
\0
^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <044DA5B8-0E8E-11D9-80A2-000A95D7CD40@apple.com>]
* Re: Problem with operand handling
@ 2004-09-07 13:59 Richard Kenner
2004-09-07 14:41 ` Diego Novillo
0 siblings, 1 reply; 38+ messages in thread
From: Richard Kenner @ 2004-09-07 13:59 UTC (permalink / raw)
To: amacleod; +Cc: gcc
what is 'decorator_traceback'?
I've got to run and will be back on this afternoon, but I'll put
the .t18.ssa file below. It's small enough.
Did you call mark_call_clobbered() on decorator_traceback? If so, why
if it passes all the tests in is_gimple_reg.. ie, its not volatile,
its address is not taken, and its not global...
A quick GDB session shows that it is called for that variable, from
add_may_alias.
;; Function GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (gnat__exception_traces__decorator_wrapper)
GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
{
system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
typedef system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615 gnat__exception_traces__decorator_wrapper__Tdecorator_tracebackS[T.5];
typedef <unnamed type> struct <unnamed type>;
typedef gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___XDL_1 gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___XDL_1;
natural___XDLU_0__2147483647 gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___U;
struct string___XUP T.11;
system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[(long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->LB0 .. (long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->UB0] * decorator_traceback.10;
struct ada__exceptions__traceback__tracebacks_array___XUB T.9;
struct ada__exceptions__traceback__tracebacks_array___XUP T.8;
struct string___XUP (*gnat__exception_traces__traceback_decorator) (struct ada__exceptions__traceback__tracebacks_array___XUP) gnat__exception_traces__current_decorator.7;
struct string___XUP T.6;
long int T.5;
bit_size_type T.4;
bit_size_type T.3;
long int T.2;
long int T.1;
integer len.0;
<bb 0>:
gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___U_2 = len_1;
len.0_3 = (integer) len_1;
len.0_4 = (integer) len_1;
T.1_5 = (long int) len.0_4;
T.2_6 = MAX_EXPR <T.1_5, 0>;
len.0_7 = (integer) len_1;
T.1_8 = (long int) len.0_7;
T.2_9 = MAX_EXPR <T.1_8, 0>;
T.3_10 = (bit_size_type) T.2_9;
T.4_11 = T.3_10 * 64;
len.0_12 = (integer) len_1;
T.1_13 = (long int) len.0_12;
T.2_14 = MAX_EXPR <T.1_13, 0>;
T.5_15 = T.2_14 * 8;
decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
gnat__exception_traces__current_decorator.7_19 = gnat__exception_traces__current_decorator;
len.0_20 = (integer) len_1;
T.9.LB0 = 1;
T.9.UB0 = len.0_20;
decorator_traceback.10_24 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[(long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->LB0 .. (long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->UB0] *) decorator_traceback_17;
T.8.P_ARRAY = decorator_traceback.10_24;
T.8.P_BOUNDS = &T.9;
T.11 = gnat__exception_traces__current_decorator.7_19 (T.8);
T.6 = T.11;
return T.6;
}
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Problem with operand handling
2004-09-07 13:59 Problem with operand handling Richard Kenner
@ 2004-09-07 14:41 ` Diego Novillo
2004-09-07 14:51 ` Andrew MacLeod
0 siblings, 1 reply; 38+ messages in thread
From: Diego Novillo @ 2004-09-07 14:41 UTC (permalink / raw)
To: Richard Kenner; +Cc: Andrew Macleod, gcc
On Tue, 2004-09-07 at 10:02, Richard Kenner wrote:
> GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
> {
> system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
>
What does this declaration mean? Is decorator_traceback
> decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
>
According to this, decorator_traceback is a GIMPLE register. It seems
to be a pointer of some kind? I can't parse the original declaration.
You'll have to figure out why we first think that decorator_traceback is
a gimple reg, and then we think otherwise.
This may help. Put this test in add_may_alias:
if (is_gimple_reg (var) || is_gimple_reg (alias))
abort ();
Diego.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Problem with operand handling
2004-09-07 14:41 ` Diego Novillo
@ 2004-09-07 14:51 ` Andrew MacLeod
2004-09-07 15:46 ` Nathan Sidwell
0 siblings, 1 reply; 38+ messages in thread
From: Andrew MacLeod @ 2004-09-07 14:51 UTC (permalink / raw)
To: Diego Novillo; +Cc: Richard Kenner, gcc mailing list
On Tue, 2004-09-07 at 10:41, Diego Novillo wrote:
> On Tue, 2004-09-07 at 10:02, Richard Kenner wrote:
>
> > GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
> > {
> > system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
> >
> What does this declaration mean? Is decorator_traceback
>
> > decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
> >
> According to this, decorator_traceback is a GIMPLE register. It seems
> to be a pointer of some kind? I can't parse the original declaration.
> You'll have to figure out why we first think that decorator_traceback is
> a gimple reg, and then we think otherwise.
>
> This may help. Put this test in add_may_alias:
>
> if (is_gimple_reg (var) || is_gimple_reg (alias))
> abort ();
>
This should probably be added permanently under ENABLE_CHECKING....
Andrew
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
2004-09-07 14:51 ` Andrew MacLeod
@ 2004-09-07 15:46 ` Nathan Sidwell
2004-09-07 15:55 ` Re: Andrew MacLeod
0 siblings, 1 reply; 38+ messages in thread
From: Nathan Sidwell @ 2004-09-07 15:46 UTC (permalink / raw)
Cc: Diego Novillo, Richard Kenner, gcc mailing list
wrote:
> On Tue, 2004-09-07 at 10:41, Diego Novillo wrote:
>
>>On Tue, 2004-09-07 at 10:02, Richard Kenner wrote:
>>
>>
>>>GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
>>>{
>>> system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
>>>
>>
>>What does this declaration mean? Is decorator_traceback
>>
>>
>>> decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
>>>
>>
>>According to this, decorator_traceback is a GIMPLE register. It seems
>>to be a pointer of some kind? I can't parse the original declaration.
>>You'll have to figure out why we first think that decorator_traceback is
>>a gimple reg, and then we think otherwise.
>>
>>This may help. Put this test in add_may_alias:
>>
>>if (is_gimple_reg (var) || is_gimple_reg (alias))
>> abort ();
>>
>
>
> This should probably be added permanently under ENABLE_CHECKING....
spelt
gcc_assert (!is_gimple_reg (var) && !is_gimple_reg (alias));
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Re:
2004-09-07 15:46 ` Nathan Sidwell
@ 2004-09-07 15:55 ` Andrew MacLeod
0 siblings, 0 replies; 38+ messages in thread
From: Andrew MacLeod @ 2004-09-07 15:55 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Diego Novillo, Richard Kenner, gcc mailing list
On Tue, 2004-09-07 at 11:45, Nathan Sidwell wrote:
> >>if (is_gimple_reg (var) || is_gimple_reg (alias))
> >> abort ();
> >>
> >
> >
> > This should probably be added permanently under ENABLE_CHECKING....
> spelt
> gcc_assert (!is_gimple_reg (var) && !is_gimple_reg (alias));
of course :-)
Its so hard to remember to change to modern ways :-)
Andrew
^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <200305221636.h4MGaLDA010075@mururoa.inria.fr>]
* Re:
[not found] <200305221636.h4MGaLDA010075@mururoa.inria.fr>
@ 2003-05-22 16:45 ` Daniel Berlin
0 siblings, 0 replies; 38+ messages in thread
From: Daniel Berlin @ 2003-05-22 16:45 UTC (permalink / raw)
To: Theodore Papadopoulo; +Cc: gcc
On Thursday, May 22, 2003, at 12:36 PM, Theodore Papadopoulo wrote:
>
> Here is a message I got trying to use bugzilla. Basically, I requested
> a change of password and then played with the back and forward keys of
> my browser.
>
Just as a note to everyone, the below type of error (anything about
permission denied, or Template->process failing twice) means it's
recompiling the templates.
This happens whenever i commit a change to the bugzilla code by CVS
(automagically, through the the magic of cvs commit hooks).
Recompiling the templates takes 5-10 seconds, so i don't bother
mentioning it.
As things settle, the number of times i change code will go down to the
point where i can set a maintenance window of some sort (maybe once a
week), and just do these things then.
Till then, if you get an error like the below, wait a minute and try
again.
Sorry for the inconvenience.
> The message:
>
> Bugzilla has suffered an internal error. Please save this page and
> send it to dberlin@gcc.gnu.org with details of what you were doing at
> the time this message appeared.
>
> URL: http://gcc.gnu.org/bugzilla/query.cgi?GoAheadAndLogIn=1
>
> Template->process() failed twice.
> First error: mkdir data/template/en/default/account: Permission denied
> at
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Template/
> Provider.pm line 844
> Second error: file error - cache failed to write code-error.html.tmpl:
> Error in tempfile() using data/template/en/default/global/XXXXXXXXXX:
> Parent directory (data/template/en/default/global/) is not writable at
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Template/
> Document.pm line 280
>
>
> Bugzilla seems much nicer than gnats, thank's for the work you did...
>
> Theo.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2002-09-04 22:16 ZMSECTT-2
0 siblings, 0 replies; 38+ messages in thread
From: ZMSECTT-2 @ 2002-09-04 22:16 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
------------------ Virus Warning Message (on mailcal)
Found virus WORM_BADTRANS.B in file fun.MP3.pif
The file is deleted.
---------------------------------------------------------
[-- Attachment #2.1: Type: text/html, Size: 114 bytes --]
[-- Attachment #3: Type: text/plain, Size: 177 bytes --]
------------------ Virus Warning Message (on mailcal)
fun.MP3.pif is removed from here because it contains a virus.
---------------------------------------------------------
[-- Attachment #4: Type: text/plain, Size: 1 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 2001-12-10 19:14 Richard Kenner
0 siblings, 0 replies; 38+ messages in thread
From: Richard Kenner @ 2001-12-10 19:14 UTC (permalink / raw)
To: dalej; +Cc: gcc
The improved memory aliasing stuff is interesting, but I see the
following case still isn't done optimally. The store to u.i[0]
is loop invariant, and is not so recognized. Is there enough
info there now to figure this out, do you think?
union {double d; int i[2]; } u;
float s=0.0;
while (count--)
{
u.i[0] = 0x4330;
u.i[1] = *i++;
s += u.d;
}
Perhaps, but it will be hard. What you'd need in this case is a tree
corresponding to were the variable case "ends" and an offset to there.
The first of those isn't hard, the second is trickier.
^ permalink raw reply [flat|nested] 38+ messages in thread
* No Subject
@ 1998-04-08 2:13 Yuan Xie
1998-04-08 15:08 ` Jeffrey A Law
0 siblings, 1 reply; 38+ messages in thread
From: Yuan Xie @ 1998-04-08 2:13 UTC (permalink / raw)
To: egcs
Dear sir,
can you give me some help?
Well, when I install egcs-1.0.1,
1. type "src-dir/configure"
it is ok and response ready for make native compiler for
mips-sgi-irix5.3
2. then I use "make bootstrap"
the error is:
make bootstrap
test -z "" || \
gcc -c -g -O2 -I. -I/u/yuanxie/egcs/libiberty/../include argv.c -o
pic/argv.o
gcc -c -g -O2 -I. -I/u/yuanxie/egcs/libiberty/../include argv.c gcc:
argv.c: No such file or directory gcc: No input files *** Error code 1 (bu21)
*** Error code 1 (bu21)
How to fixed this problem??
Thanks!
sincerely
Yuan
|||||
~~~ ~~~
@ @
=================------.ooou--U--uooo.----==========================
Mail Address: Office: E-Quad B-219
Yuan Xie Tel: (609)-497-9251 (h)
406B, Butler Ave. (609)-258-1354 (o)
Butler Apartment Email: yuanxie@princeton.edu
Princeton, NJ 08540 Homepage: www.ee.princeton.edu/~yuanxie/
=====================================================================
^ permalink raw reply [flat|nested] 38+ messages in thread
* No Subject
@ 1998-03-27 15:18 Ken Faiczak
1998-03-31 0:46 ` Jeffrey A Law
0 siblings, 1 reply; 38+ messages in thread
From: Ken Faiczak @ 1998-03-27 15:18 UTC (permalink / raw)
To: 'egcs'
I'd like to get exceptions working in vxWorks on a MIPS platform.
The code is being generated, it throws the exception but then the thread
is terminated since no frames are found. How do I register the frames?
I'm simply downloading a relocatable file to the target and running it, so
it is not linked with and crt files that would normally do this. The crt
normally looks like it does __register_frame_info(__EH_FRAME_BEGIN__,
&object).
I can't seem to get the symbol __EH_FRAME_BEGIN__ defined? Though
there are multiple __FRAME_BEGIN__ defined and __EXCEPTION_TABLE__.
Anybody have pointers on where to go from here.
I don't want to use the sjlj-exceptions due to performance overhead. I'm
also
not worried about MT-safe at this point, one thing at a time.
____________________________________________________________
Ken Faiczak Pixel Scientific Incorporated
ken@pixsci.com 180 Columbia St. West
(519) 884-4196 x2234 Waterloo Ontario, Canada
fax:(519) 884-5949 N2L 3L3
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
1998-03-27 15:18 No Subject Ken Faiczak
@ 1998-03-31 0:46 ` Jeffrey A Law
0 siblings, 0 replies; 38+ messages in thread
From: Jeffrey A Law @ 1998-03-31 0:46 UTC (permalink / raw)
To: Ken Faiczak; +Cc: 'egcs'
In message < 3521B963898BD111AA6A006008A845160707BC@SERVER >you write:
> The code is being generated, it throws the exception but then the thread
> is terminated since no frames are found. How do I register the frames?
On ELF systems it's done by placing calls to __register_frame_info
in the .init section. See crtstuff.c in the gcc directory.
jeff
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
@ 1998-02-10 3:34 Jochen Kuepper
1998-02-10 10:30 ` Re: Jeffrey A Law
0 siblings, 1 reply; 38+ messages in thread
From: Jochen Kuepper @ 1998-02-10 3:34 UTC (permalink / raw)
To: law; +Cc: egcs
Jeffrey A Law <law@hurl.cygnus.com> wrote:
:>
:> In message < 9802091815.AA16287@bacchus.pc1.uni-duesseldorf.de >you write:
:> >
:> > Since there are so many patches going around, will there be a release
:> > egcs-1.0.2 any time soon.
:> I suspect it'll happen before mid-March. Exactly when between now and
:> then is hard to predict at this point.
Sounds good !
:> > Is there an archive of patches to egcs-1.0.1 (separated from the
:> > snapshot patches) anywhere ?
:> ? Not sure what you're really asking.
:>
:> Are you trying to figure out how to update from 1.0.1 to 1.0.2?
No, but following the mailing lists, there are coming in bug reports and patches
for fixes/enhancements of egcs-1.0.1 and of the current egcs snapshots/cvs tree
mixed altogether.
I was thinking it would be nice to have an archive of patches that can be
apllied to the last egcs-release, separated from all the patches that can only
be applied to the snapshots.
I know that for you development guys the snapshots are more important to move
forward, but shouldn't we make the releases as 'bugfree' as possible.
So if there is knowledge from the snapshot tree, that can go into the release
tree easily, why not give the user a possibility to patch his release instead
of waiting for the next release.
Or is all this even possible by just checking out the release tree from the
cvs-sources regularly ?
Thanks for the good work,
Jochen
-----------------------------------------------------------------------
Jochen K"upper
Heinrich-Heine-Universit"at D"usseldorf jochen@uni-duesseldorf.de
Institut f"ur Physikalische Chemie I
Universit"atsstr. 1, Geb 26.43 Raum 02.29 phone ++49-211-8113681
40225 D"usseldorf fax ++49-211-8115195
Germany http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
1998-02-10 3:34 Re: Jochen Kuepper
@ 1998-02-10 10:30 ` Jeffrey A Law
0 siblings, 0 replies; 38+ messages in thread
From: Jeffrey A Law @ 1998-02-10 10:30 UTC (permalink / raw)
To: Jochen Kuepper; +Cc: egcs
In message < 9802101122.AA29122@bacchus.pc1.uni-duesseldorf.de >you write:
> No, but following the mailing lists, there are coming in bug reports and
> patches for fixes/enhancements of egcs-1.0.1 and of the current egcs
> snapshots/cvs tree mixed altogether.
Yup.
> I was thinking it would be nice to have an archive of patches that can be
> apllied to the last egcs-release, separated from all the patches that can
> only be applied to the snapshots.
Ah yes. Did you read the initial message about 1.0.2? It had this line:
Right now these are only available on the cvs server; I'll bundle
them up for ftp after I take care of a few more critical fixes.
Which to be more explicit means we'll be providing (via ftp) patches folks
can use to turn 1.0.1 into pre-release versions of 1.0.2. This is also how
we handle the 1.0.1 release (look in the snapshots/1.0.1-prerelease dir).
> I know that for you development guys the snapshots are more important to
> move forward, but shouldn't we make the releases as 'bugfree' as possible.
It's a nice goal, but at some point you have to say "critical fixes only",
else we'd have to pull in most of the development tree, which unstabilizes
things...
That's why we don't try to fix every bug in minor releases... It is a tough
decision to make, but necessary.
> Or is all this even possible by just checking out the release tree from the
> cvs-sources regularly ?
Yes -- if you update your release tree via cvs you'll get whatever patches
we've applied to to the release tree. That's precisely why we install the
changes in the release branch -- so folks can get them them at any time.
jeff
^ permalink raw reply [flat|nested] 38+ messages in thread
* No Subject
@ 1998-02-09 14:46 Jochen Kuepper
1998-02-09 15:37 ` Jeffrey A Law
0 siblings, 1 reply; 38+ messages in thread
From: Jochen Kuepper @ 1998-02-09 14:46 UTC (permalink / raw)
To: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
Since there are so many patches going around, will there be a release
egcs-1.0.2 any time soon. Is there an archive of patches to egcs-1.0.1
(separated from the snapshot patches) anywhere ?
Jochen
-----------------------------------------------------------------------
Jochen Küpper
Heinrich-Heine-Universität Düsseldorf jochen@uni-duesseldorf.de
Institut für Physikalische Chemie I
Universitätsstrasse 1, Geb 26.43.02.19 phone ++49-211-8113681
40225 Düsseldorf fax ++49-211-8115195
Germany http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
1998-02-09 14:46 No Subject Jochen Kuepper
@ 1998-02-09 15:37 ` Jeffrey A Law
0 siblings, 0 replies; 38+ messages in thread
From: Jeffrey A Law @ 1998-02-09 15:37 UTC (permalink / raw)
To: Jochen Kuepper; +Cc: egcs
In message < 9802091815.AA16287@bacchus.pc1.uni-duesseldorf.de >you write:
>
> Since there are so many patches going around, will there be a release
> egcs-1.0.2 any time soon.
I suspect it'll happen before mid-March. Exactly when between now and
then is hard to predict at this point.
> Is there an archive of patches to egcs-1.0.1 (separated from the
> snapshot patches) anywhere ?
? Not sure what you're really asking.
Are you trying to figure out how to update from 1.0.1 to 1.0.2?
jeff
^ permalink raw reply [flat|nested] 38+ messages in thread
* No Subject
@ 1997-12-05 13:11 Thomas Weise
1997-12-06 9:23 ` Jeffrey A Law
0 siblings, 1 reply; 38+ messages in thread
From: Thomas Weise @ 1997-12-05 13:11 UTC (permalink / raw)
To: egcs
Here are my gcc/g++ results "configure; make bootstrap"
and below full results "configure --enable-shared; make bootstrap".
Is --enable-shared g++ known to fail on this target?
tom@zaphod.wh9.tu-dresden.de
S.u.S.E. Linux 4.4.1 (kernel 2.0.29) + libc-5.4.39 + binutils-2.8.1.0.15
Test Run By tom on Thu Dec 4 00:22:35 1997
Native configuration is i486-pc-linux-gnulibc1
=== gcc Summary ===
# of expected passes 4883
# of expected failures 5
# of unsupported tests 7
/home/tom/egcs-1.0/gcc/xgcc version egcs-2.90.21 971202 (egcs-1.00 release)
Test Run By tom on Thu Dec 4 01:03:23 1997
Native configuration is i486-pc-linux-gnulibc1
=== g++ Summary ===
# of expected passes 3400
# of unexpected successes 3
# of expected failures 80
# of untested testcases 6
/home/tom/egcs-1.0/gcc/testsuite/../xgcc version egcs-2.90.21 971202 (egcs-1.00 release)
Test Run By tom on Fri Dec 5 17:26:31 1997
Native configuration is i486-pc-linux-gnulibc1
=== libio tests ===
=== libio Summary ===
# of expected passes 40
Test Run By tom on Fri Dec 5 17:29:30 1997
Native configuration is i486-pc-linux-gnulibc1
=== libstdc++ tests ===
=== libstdc++ Summary ===
# of expected passes 30
Test Run By tom on Fri Dec 5 17:32:28 1997
Native configuration is i486-pc-linux-gnulibc1
=== gcc tests ===
=== gcc Summary ===
# of expected passes 4883
# of expected failures 5
# of unsupported tests 7
/home/tom/egcs-1.0/gcc/xgcc version egcs-2.90.21 971202 (egcs-1.00 release)
Test Run By tom on Fri Dec 5 18:19:59 1997
Native configuration is i486-pc-linux-gnulibc1
=== g++ tests ===
FAIL: g++.bob/delete1.C Execution test
FAIL: g++.bob/packed1.C Execution test
FAIL: g++.bob/template4.C Execution test
FAIL: g++.brendan/code-gen1.C Execution test
FAIL: g++.brendan/code-gen2.C Execution test
FAIL: g++.brendan/code-gen3.C Execution test
FAIL: g++.brendan/code-gen4.C Execution test
FAIL: g++.brendan/code-gen5.C Execution test
FAIL: g++.brendan/code-gen6.C Execution test
FAIL: g++.brendan/copy1.C Execution test
FAIL: g++.brendan/copy2.C Execution test
FAIL: g++.brendan/copy3.C Execution test
FAIL: g++.brendan/copy4.C Execution test
FAIL: g++.brendan/copy5.C Execution test
FAIL: g++.brendan/copy6.C Execution test
FAIL: g++.brendan/copy7.C Execution test
FAIL: g++.brendan/copy8.C Execution test
FAIL: g++.brendan/copy9.C Execution test
FAIL: g++.brendan/ctors1.C Execution test
FAIL: g++.brendan/ctors2.C Execution test
FAIL: g++.brendan/delete2.C Execution test
FAIL: g++.brendan/dtors1.C Execution test
FAIL: g++.brendan/dtors2.C Execution test
FAIL: g++.brendan/dtors3.C Execution test
FAIL: g++.brendan/groff1.C Execution test
FAIL: g++.brendan/init3.C Execution test
FAIL: g++.brendan/misc12.C Execution test
FAIL: g++.brendan/misc7.C Execution test
FAIL: g++.brendan/nest21.C Execution test
FAIL: g++.brendan/new2.C Execution test
FAIL: g++.brendan/new3.C Execution test
FAIL: g++.brendan/operators5.C Execution test
FAIL: g++.brendan/overload2.C Execution test
FAIL: g++.brendan/overload7.C Execution test
FAIL: g++.brendan/ptolemy2.C Execution test
FAIL: g++.brendan/redecl2.C Execution test
FAIL: g++.brendan/reference1.C Execution test
FAIL: g++.brendan/sizeof5.C Execution test
FAIL: g++.brendan/template22.C Execution test
FAIL: g++.brendan/template24.C Execution test
FAIL: g++.brendan/template3.C Execution test
FAIL: g++.brendan/template9.C Execution test
FAIL: g++.brendan/vtables1.C Execution test
FAIL: g++.bugs/891230_01.C Execution test
FAIL: g++.bugs/900107_01.C Execution test
FAIL: g++.bugs/900207_03.C Execution test
FAIL: g++.bugs/900208_02.C Execution test
FAIL: g++.bugs/900212_03.C Execution test
FAIL: g++.bugs/900220_01.C Execution test
FAIL: g++.bugs/900220_02.C Execution test
FAIL: g++.bugs/900220_03.C Execution test
FAIL: g++.bugs/900227_01.C Execution test
FAIL: g++.bugs/900321_02.C Execution test
FAIL: g++.bugs/900321_04.C Execution test
FAIL: g++.bugs/900321_05.C Execution test
FAIL: g++.bugs/900324_03.C Execution test
FAIL: g++.bugs/900324_06.C Execution test
FAIL: g++.bugs/900331_02.C Execution test
FAIL: g++.bugs/900331_03.C Execution test
FAIL: g++.bugs/900331_04.C Execution test
FAIL: g++.bugs/900406_02.C (syntax) Execution test
FAIL: g++.bugs/900407_02.C Execution test
FAIL: g++.bugs/900511_01.C Execution test
FAIL: g++.bugs/900519_04.C Execution test
FAIL: g++.bugs/900519_08.C Execution test
FAIL: g++.bugs/900520_02.C Execution test
FAIL: g++.bugs/900520_04.C Execution test
FAIL: g++.bugs/900520_05.C Execution test
FAIL: g++.bugs/900520_06.C Execution test
FAIL: g++.eh/pdel1.C Execution test
FAIL: g++.eh/pdel2.C Execution test
FAIL: g++.eh/rethrow1.C Execution test
FAIL: g++.eh/rethrow2.C Execution test
FAIL: g++.eh/rethrow3.C Execution test
FAIL: g++.eh/spec1.C Execution test
FAIL: g++.eh/spec2.C Execution test
FAIL: g++.eh/spec4.C Execution test
FAIL: g++.ext/constructor.C Execution test
FAIL: g++.ext/default.C Execution test
FAIL: g++.ext/null1.C Execution test
FAIL: g++.gb/sig01.C Execution test
FAIL: g++.gb/sig02.C Execution test
FAIL: g++.gb/sig03.C Execution test
FAIL: g++.gb/sig04.C Execution test
FAIL: g++.gb/sig05.C Execution test
FAIL: g++.gb/sig06.C Execution test
FAIL: g++.gb/sig07.C Execution test
FAIL: g++.gb/sig08.C Execution test
FAIL: g++.gb/sig09.C Execution test
FAIL: g++.gb/sig10.C Execution test
FAIL: g++.gb/sig11.C Execution test
FAIL: g++.gb/sig12.C Execution test
FAIL: g++.gb/sig13.C Execution test
FAIL: g++.gb/sig14.C Execution test
FAIL: g++.gb/sig15.C Execution test
FAIL: g++.gb/sig16.C Execution test
FAIL: g++.gb/sig17.C Execution test
FAIL: g++.gb/sig18.C Execution test
FAIL: g++.gb/sig19.C Execution test
FAIL: g++.gb/sig20.C Execution test
FAIL: g++.gb/sig21.C Execution test
FAIL: g++.gb/sig22.C Execution test
FAIL: g++.gb/sig23.C Execution test
FAIL: g++.gb/sig24.C Execution test
FAIL: g++.gb/sig25.C Execution test
FAIL: g++.gb/sig26.C Execution test
FAIL: g++.gb/sig27.C Execution test
FAIL: g++.gb/sig28.C Execution test
FAIL: g++.gb/sig29.C Execution test
FAIL: g++.gb/sig30.C Execution test
FAIL: g++.gb/sig31.C Execution test
FAIL: g++.jason/2371.C Execution test
FAIL: g++.jason/aggregate.C Execution test
FAIL: g++.jason/anon.C Execution test
FAIL: g++.jason/bool2.C Execution test
FAIL: g++.jason/bool4.C Execution test
FAIL: g++.jason/bool5.C Execution test
FAIL: g++.jason/byval.C Execution test
FAIL: g++.jason/cleanup.C Execution test
FAIL: g++.jason/cond2.C Execution test
FAIL: g++.jason/const.C Execution test
FAIL: g++.jason/const2.C Execution test
FAIL: g++.jason/const3.C Execution test
FAIL: g++.jason/conversion6.C Execution test
FAIL: g++.jason/conversion7.C Execution test
FAIL: g++.jason/conversion8.C Execution test
FAIL: g++.jason/conversion9.C Execution test
FAIL: g++.jason/ctor1.C Execution test
FAIL: g++.jason/dcast2.C Execution test
FAIL: g++.jason/dcast3.C Execution test
FAIL: g++.jason/defctor.C Execution test
XPASS: g++.jason/destruct3.C - (test for bogus messages, line 38)
FAIL: g++.jason/dtor2.C Execution test
FAIL: g++.jason/dtor5.C Execution test
FAIL: g++.jason/enum5.C Execution test
FAIL: g++.jason/enum6.C Execution test
FAIL: g++.jason/enum8.C Execution test
FAIL: g++.jason/friend.C Execution test
FAIL: g++.jason/groff1.C Execution test
FAIL: g++.jason/init2.C Execution test
FAIL: g++.jason/init3.C Execution test
FAIL: g++.jason/inline.C Execution test
FAIL: g++.jason/lex1.C Execution test
FAIL: g++.jason/lvalue4.C Execution test
FAIL: g++.jason/mangle3.C Execution test
FAIL: g++.jason/mi.C Execution test
FAIL: g++.jason/mutable1.C Execution test
FAIL: g++.jason/net2.C Execution test
FAIL: g++.jason/new.C Execution test
FAIL: g++.jason/new2.C Execution test
FAIL: g++.jason/new3.C Execution test
FAIL: g++.jason/new4.C Execution test
FAIL: g++.jason/new5.C Execution test
FAIL: g++.jason/offset2.C Execution test
FAIL: g++.jason/opeq.C Execution test
FAIL: g++.jason/optimize2.C Execution test
FAIL: g++.jason/overload11.C Execution test
FAIL: g++.jason/overload12.C Execution test
FAIL: g++.jason/overload13.C Execution test
FAIL: g++.jason/overload19.C Execution test
FAIL: g++.jason/overload27.C Execution test
FAIL: g++.jason/parse10.C Execution test
FAIL: g++.jason/parse12.C Execution test
FAIL: g++.jason/parse9.C Execution test
FAIL: g++.jason/pmem2.C Execution test
FAIL: g++.jason/pmem3.C Execution test
FAIL: g++.jason/pmf7.C Execution test
FAIL: g++.jason/pmf8.C Execution test
FAIL: g++.jason/ref10.C Execution test
FAIL: g++.jason/ref11.C Execution test
FAIL: g++.jason/ref12.C Execution test
FAIL: g++.jason/ref7.C Execution test
FAIL: g++.jason/ref8.C Execution test
FAIL: g++.jason/ref9.C Execution test
FAIL: g++.jason/return.C Execution test
FAIL: g++.jason/return2.C Execution test
FAIL: g++.jason/return3.C Execution test
FAIL: g++.jason/rvalue1.C Execution test
FAIL: g++.jason/rvalue2.C Execution test
FAIL: g++.jason/scoping17.C Execution test
FAIL: g++.jason/static1.C Execution test
FAIL: g++.jason/synth5.C Execution test
FAIL: g++.jason/synth7.C Execution test
FAIL: g++.jason/template11.C Execution test
FAIL: g++.jason/template13.C Execution test
FAIL: g++.jason/template14.C Execution test
FAIL: g++.jason/template15.C Execution test
FAIL: g++.jason/template16.C Execution test
FAIL: g++.jason/template19.C Execution test
FAIL: g++.jason/template20.C Execution test
FAIL: g++.jason/template24.C Execution test
FAIL: g++.jason/template25.C Execution test
FAIL: g++.jason/template26.C Execution test
FAIL: g++.jason/template27.C Execution test
FAIL: g++.jason/template28.C Execution test
FAIL: g++.jason/template3.C Execution test
FAIL: g++.jason/template31.C Execution test
FAIL: g++.jason/template34.C Execution test
FAIL: g++.jason/template36.C Execution test
FAIL: g++.jason/template37.C Execution test
FAIL: g++.jason/template38.C Execution test
FAIL: g++.jason/template40.C Execution test
FAIL: g++.jason/template41.C Execution test
FAIL: g++.jason/template42.C Execution test
FAIL: g++.jason/template43.C Execution test
FAIL: g++.jason/template6.C - failed temp resolution Execution test
FAIL: g++.jason/temporary.C Execution test
FAIL: g++.jason/temporary3.C Execution test
FAIL: g++.jason/temporary4.C Execution test
FAIL: g++.jason/temporary5.C Execution test
FAIL: g++.jason/temporary7.C Execution test
FAIL: g++.jason/temporary8.C Execution test
FAIL: g++.jason/thunk1.C Execution test
FAIL: g++.jason/thunk2.C Execution test
FAIL: g++.jason/thunk3.C Execution test
FAIL: g++.jason/typedef2.C Execution test
FAIL: g++.jason/typeid1.C Execution test
FAIL: g++.jason/typeid2.C Execution test
FAIL: g++.jason/vecdel.C Execution test
FAIL: g++.jason/virtual2.C Execution test
FAIL: g++.jason/warning5.C Execution test
FAIL: g++.law/arg7.C Execution test
FAIL: g++.law/arg8.C Execution test
FAIL: g++.law/arm13.C Execution test
FAIL: g++.law/arm15.C Execution test
FAIL: g++.law/arm4.C Execution test
FAIL: g++.law/arm5.C Execution test
FAIL: g++.law/arm7.C Execution test
FAIL: g++.law/array1.C Execution test
FAIL: g++.law/bit-fields2.C Execution test
FAIL: g++.law/builtin1.C Execution test
FAIL: g++.law/code-gen1.C Execution test
FAIL: g++.law/code-gen2.C Execution test
FAIL: g++.law/code-gen4.C Execution test
FAIL: g++.law/code-gen5.C Execution test
FAIL: g++.law/copy1.C Execution test
FAIL: g++.law/ctors12.C Execution test
FAIL: g++.law/ctors15.C Execution test
FAIL: g++.law/ctors16.C Execution test
FAIL: g++.law/ctors2.C Execution test
FAIL: g++.law/ctors4.C Execution test
FAIL: g++.law/ctors8.C Execution test
FAIL: g++.law/cvt12.C Execution test
FAIL: g++.law/cvt2.C Execution test
FAIL: g++.law/cvt4.C Execution test
FAIL: g++.law/cvt7.C Execution test
FAIL: g++.law/dtors2.C Execution test
FAIL: g++.law/dtors3.C Execution test
FAIL: g++.law/dtors4.C Execution test
FAIL: g++.law/dtors5.C Execution test
FAIL: g++.law/enum9.C Execution test
FAIL: g++.law/global-init1.C Execution test
FAIL: g++.law/init11.C Execution test
FAIL: g++.law/init13.C Execution test
FAIL: g++.law/init14.C Execution test
FAIL: g++.law/init9.C Execution test
FAIL: g++.law/inline4.C Execution test
FAIL: g++.law/operators1.C Execution test
FAIL: g++.law/operators15.C Execution test
FAIL: g++.law/operators16.C Execution test
FAIL: g++.law/operators23.C Execution test
FAIL: g++.law/operators27.C Execution test
FAIL: g++.law/operators7.C Execution test
FAIL: g++.law/operators8.C Execution test
FAIL: g++.law/profile1.C Execution test
FAIL: g++.law/refs1.C Execution test
FAIL: g++.law/refs4.C Execution test
FAIL: g++.law/scope2.C Execution test
FAIL: g++.law/template2.C Execution test
FAIL: g++.law/temps2.C Execution test
FAIL: g++.law/temps3.C Execution test
FAIL: g++.law/temps4.C Execution test
FAIL: g++.law/temps5.C Execution test
FAIL: g++.law/temps6.C Execution test
FAIL: g++.law/virtual2.C Execution test
FAIL: g++.law/virtual3.C Execution test
FAIL: g++.law/virtual4.C Execution test
FAIL: g++.law/vtable3.C Execution test
FAIL: g++.mike/align1.C Execution test
FAIL: g++.mike/align2.C Execution test
FAIL: g++.mike/asm2.C Execution test
FAIL: g++.mike/bool2.C Execution test
FAIL: g++.mike/conv1.C Execution test
FAIL: g++.mike/dyncast3.C Execution test
FAIL: g++.mike/dyncast5.C Execution test
FAIL: g++.mike/dyncast7.C Execution test
FAIL: g++.mike/dyncast8.C Execution test
FAIL: g++.mike/dyncast9.C Execution test
FAIL: g++.mike/eh10.C Execution test
FAIL: g++.mike/eh12.C Execution test
FAIL: g++.mike/eh13.C Execution test
FAIL: g++.mike/eh14.C Execution test
FAIL: g++.mike/eh16.C Execution test
FAIL: g++.mike/eh17.C Execution test
FAIL: g++.mike/eh18.C Execution test
FAIL: g++.mike/eh2.C Execution test
FAIL: g++.mike/eh21.C Execution test
FAIL: g++.mike/eh23.C Execution test
FAIL: g++.mike/eh24.C Execution test
FAIL: g++.mike/eh25.C Execution test
FAIL: g++.mike/eh26.C Execution test
FAIL: g++.mike/eh27.C Execution test
FAIL: g++.mike/eh28.C Execution test
FAIL: g++.mike/eh29.C Execution test
FAIL: g++.mike/eh3.C Execution test
FAIL: g++.mike/eh31.C Execution test
FAIL: g++.mike/eh33.C Execution test
FAIL: g++.mike/eh34.C Execution test
FAIL: g++.mike/eh35.C Execution test
FAIL: g++.mike/eh36.C Execution test
FAIL: g++.mike/eh37.C Execution test
FAIL: g++.mike/eh38.C Execution test
FAIL: g++.mike/eh39.C Execution test
FAIL: g++.mike/eh40.C Execution test
FAIL: g++.mike/eh41.C Execution test
FAIL: g++.mike/eh42.C Execution test
FAIL: g++.mike/eh44.C Execution test
FAIL: g++.mike/eh45.C Execution test
FAIL: g++.mike/eh47.C Execution test
FAIL: g++.mike/eh48.C Execution test
FAIL: g++.mike/eh49.C Execution test
FAIL: g++.mike/eh5.C Execution test
FAIL: g++.mike/eh50.C Execution test
FAIL: g++.mike/eh51.C Execution test
FAIL: g++.mike/eh52.C Execution test
FAIL: g++.mike/eh53.C Execution test
FAIL: g++.mike/eh55.C Execution test
FAIL: g++.mike/eh56.C Execution test
FAIL: g++.mike/eh6.C Execution test
FAIL: g++.mike/eh7.C Execution test
FAIL: g++.mike/eh8.C Execution test
FAIL: g++.mike/eh9.C Execution test
FAIL: g++.mike/hog1.C Execution test
FAIL: g++.mike/init1.C Execution test
FAIL: g++.mike/leak1.C Execution test
FAIL: g++.mike/mangle3.C Execution test
FAIL: g++.mike/mi1.C Execution test
FAIL: g++.mike/mi2.C Execution test
FAIL: g++.mike/misc1.C Execution test
FAIL: g++.mike/misc13.C Execution test
FAIL: g++.mike/misc14.C Execution test
FAIL: g++.mike/net15.C Execution test
FAIL: g++.mike/net16.C Execution test
FAIL: g++.mike/net17.C Execution test
FAIL: g++.mike/net21.C Execution test
FAIL: g++.mike/net26.C Execution test
FAIL: g++.mike/net34.C Execution test
FAIL: g++.mike/net35.C Execution test
FAIL: g++.mike/net37.C Execution test
FAIL: g++.mike/net38.C Execution test
FAIL: g++.mike/net39.C Execution test
FAIL: g++.mike/net40.C Execution test
FAIL: g++.mike/net41.C Execution test
FAIL: g++.mike/net46.C Execution test
FAIL: g++.mike/offset1.C Execution test
FAIL: g++.mike/opr-as1.C Execution test
FAIL: g++.mike/p10148.C Execution test
FAIL: g++.mike/p10769a.C Execution test
FAIL: g++.mike/p10849a.C Execution test
FAIL: g++.mike/p11144.C Execution test
FAIL: g++.mike/p11667.C Execution test
FAIL: g++.mike/p12306.C Execution test
FAIL: g++.mike/p12306a.C Execution test
FAIL: g++.mike/p1248.C Execution test
FAIL: g++.mike/p1567.C Execution test
FAIL: g++.mike/p1862.C Execution test
FAIL: g++.mike/p2394.C Execution test
FAIL: g++.mike/p2736.C Execution test
FAIL: g++.mike/p2846.C Execution test
FAIL: g++.mike/p2846a.C Execution test
FAIL: g++.mike/p2846b.C Execution test
FAIL: g++.mike/p2960.C Execution test
FAIL: g++.mike/p3041.C Execution test
FAIL: g++.mike/p3060d.C Execution test
FAIL: g++.mike/p3068.C Execution test
FAIL: g++.mike/p3139.C Execution test
FAIL: g++.mike/p3570.C Execution test
FAIL: g++.mike/p3579.C Execution test
FAIL: g++.mike/p3708.C Execution test
FAIL: g++.mike/p3708a.C Execution test
FAIL: g++.mike/p3708b.C Execution test
FAIL: g++.mike/p4068.C Execution test
FAIL: g++.mike/p4104.C Execution test
FAIL: g++.mike/p4246.C Execution test
FAIL: g++.mike/p4511.C Execution test
FAIL: g++.mike/p4623.C Execution test
FAIL: g++.mike/p4667.C Execution test
FAIL: g++.mike/p4736a.C Execution test
FAIL: g++.mike/p4736b.C Execution test
FAIL: g++.mike/p4736c.C Execution test
FAIL: g++.mike/p5469.C Execution test
FAIL: g++.mike/p5469a.C Execution test
FAIL: g++.mike/p5571.C Execution test
FAIL: g++.mike/p5611.C Execution test
FAIL: g++.mike/p5673.C Execution test
FAIL: g++.mike/p5718.C Execution test
FAIL: g++.mike/p5840.C Execution test
FAIL: g++.mike/p5958.C Execution test
FAIL: g++.mike/p6004.C Execution test
FAIL: g++.mike/p6311.C Execution test
FAIL: g++.mike/p646.C Execution test
FAIL: g++.mike/p658.C Execution test
FAIL: g++.mike/p6610a.C Execution test
FAIL: g++.mike/p6610b.C Execution test
FAIL: g++.mike/p6611.C Execution test
FAIL: g++.mike/p6927.C Execution test
FAIL: g++.mike/p7180.C Execution test
FAIL: g++.mike/p7325.C Execution test
FAIL: g++.mike/p755.C Execution test
FAIL: g++.mike/p755a.C Execution test
FAIL: g++.mike/p7651.C Execution test
FAIL: g++.mike/p783.C Execution test
FAIL: g++.mike/p783a.C Execution test
FAIL: g++.mike/p783b.C Execution test
FAIL: g++.mike/p786.C Execution test
FAIL: g++.mike/p7865.C Execution test
FAIL: g++.mike/p789.C Execution test
FAIL: g++.mike/p789a.C Execution test
FAIL: g++.mike/p7912.C Execution test
FAIL: g++.mike/p8018.C Execution test
FAIL: g++.mike/p8155.C Execution test
FAIL: g++.mike/p8483.C Execution test
FAIL: g++.mike/p8804.C Execution test
FAIL: g++.mike/p9206.C Execution test
FAIL: g++.mike/p9706.C Execution test
FAIL: g++.mike/p9732a.C Execution test
FAIL: g++.mike/p9732b.C Execution test
FAIL: g++.mike/pmf1.C Execution test
FAIL: g++.mike/pmf2.C Execution test
FAIL: g++.mike/pmf5.C Execution test
FAIL: g++.mike/pmf7.C Execution test
FAIL: g++.mike/pmf8.C Execution test
FAIL: g++.mike/pmf9.C Execution test
FAIL: g++.mike/pt1.C - Execution test
FAIL: g++.mike/pt2.C Execution test
FAIL: g++.mike/ref1.C Execution test
FAIL: g++.mike/rtti2.C Execution test
FAIL: g++.mike/rtti3.C Execution test
FAIL: g++.mike/temp.C Execution test
FAIL: g++.mike/thunk2.C Execution test
FAIL: g++.mike/thunk3.C Execution test
FAIL: g++.mike/virt2.C Execution test
FAIL: g++.mike/virt4.C Execution test
FAIL: g++.mike/virt5.C Execution test
FAIL: g++.niklas/t140.C Execution test
FAIL: g++.other/rtti1.C Execution test
FAIL: g++.other/rtti2.C Execution test
FAIL: g++.other/rtti3.C Execution test
FAIL: g++.other/rtti4.C Execution test
FAIL: g++.other/rttid2.C Execution test
FAIL: g++.other/rttid3.C Execution test
FAIL: g++.other/rttid4.C Execution test
FAIL: g++.pt/eichin01a.C Execution test
FAIL: g++.pt/eichin01b.C Execution test
FAIL: g++.pt/t16.C Execution test
FAIL: g++.pt/t39.C Execution test
FAIL: g++.pt/t42.C - this should work Execution test
FAIL: g++.pt/tiemann2.C Execution test
=== g++ Summary ===
# of expected passes 2943
# of unexpected failures 457
# of unexpected successes 1
# of expected failures 82
# of untested testcases 6
/home/tom/egcs-1.0/gcc/testsuite/../xgcc version egcs-2.90.21 971202 (egcs-1.00 release)
Test Run By tom on Fri Dec 5 18:56:11 1997
Native configuration is i486-pc-linux-gnulibc1
=== g77 tests ===
FAIL: g77.f-torture/execute/dnrm2.f execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops
FAIL: g77.f-torture/execute/dnrm2.f execution, -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops
=== g77 Summary ===
# of expected passes 130
# of unexpected failures 2
/home/tom/egcs-1.0/gcc/g77 version egcs-2.90.21 971202 (egcs-1.00 release)
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
1997-12-05 13:11 No Subject Thomas Weise
@ 1997-12-06 9:23 ` Jeffrey A Law
0 siblings, 0 replies; 38+ messages in thread
From: Jeffrey A Law @ 1997-12-06 9:23 UTC (permalink / raw)
To: Thomas Weise; +Cc: egcs
In message < 199712051820.TAA09304@zaphod.wh9.tu-dresden.de >you write:
> Here are my gcc/g++ results "configure; make bootstrap"
> and below full results "configure --enable-shared; make bootstrap".
> Is --enable-shared g++ known to fail on this target?
The g++ failures are due to a bug in the testing harness; it's not
arranging for the test programs to find the freshly built shared C++
libs, instead they pick up whatever shared versions of the C++ libs
it can find in the standard locations on your system.
We really need someone to fix this correctly; the right way to do this
is to have the _testing framework_ pass args to the linker so that tests
have a path to the shared libraries they reference.
jeff
^ permalink raw reply [flat|nested] 38+ messages in thread
* (no subject)
@ 1997-08-26 21:22 Eliot Dresselhaus
1997-10-17 23:35 ` Jeffrey A Law
0 siblings, 1 reply; 38+ messages in thread
From: Eliot Dresselhaus @ 1997-08-26 21:22 UTC (permalink / raw)
To: egcs
Here is a patch which makes Haifa the default scheduler for alpha-*-* targets and
changes insn timings to reflect this.
This seems generate much better floating point code than the old scheduler and
seems to bootstrap.
I'd appreciate any feedback on these diffs from alpha hackers. Thanks.
Fri Aug 22 17:36:47 1997 Eliot Dresselhaus <eliot@sirius.com>
* configure.in (alpha* targets): default to Haifa scheduler.
* alpha.md (function units): Use real clock counts for Haifa scheduler.
* alpha.c (alpha_adjust_cost): Likewise.
* alpha.h (ISSUE_RATE): Define.
*** configure.in.old Fri Aug 22 14:18:14 1997
--- configure.in Fri Aug 22 14:26:26 1997
***************
*** 264,269 ****
--- 264,272 ----
use_collect2=yes
;;
alpha*-*-linux-gnuecoff*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
tm_file="${tm_file} alpha/linux.h"
xm_file="${xm_file} alpha/xm-linux.h"
target_cpu_default="MASK_GAS"
***************
*** 273,278 ****
--- 276,284 ----
gas=yes gnu_ld=yes
;;
alpha*-*-linux-gnu*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
tm_file="${tm_file} alpha/linux.h alpha/elf.h"
xm_file="${xm_file} alpha/xm-linux.h"
target_cpu_default="MASK_GAS"
***************
*** 287,292 ****
--- 293,301 ----
fi
;;
alpha*-dec-osf[[456789]]*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
if [[ x$stabs = xyes ]]
then
tm_file="${tm_file} dbx.h"
***************
*** 305,310 ****
--- 314,322 ----
esac
;;
alpha*-dec-osf[[23]]*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
tm_file="${tm_file} alpha/osf2or3.h"
if [[ x$stabs = xyes ]]
then
***************
*** 317,322 ****
--- 329,337 ----
use_collect2=yes
;;
alpha*-dec-osf1.2)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
tm_file="${tm_file} alpha/osf12.h"
if [[ x$stabs = xyes ]]
then
***************
*** 329,334 ****
--- 344,352 ----
use_collect2=yes
;;
alpha*-*-osf*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
if [[ x$stabs = xyes ]]
then
tm_file="${tm_file} dbx.h"
***************
*** 340,345 ****
--- 358,366 ----
use_collect2=yes
;;
alpha*-*-winnt3*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
tm_file="${tm_file} alpha/win-nt.h"
target_cpu_default=MASK_WINDOWS_NT
xm_file="${xm_file} config/winnt/xm-winnt.h alpha/xm-winnt.h"
***************
*** 357,362 ****
--- 378,386 ----
fi
;;
alpha*-dec-vms*)
+ if [[ x$enable_haifa != xno ]]; then
+ enable_haifa=yes
+ fi
tm_file=alpha/vms.h
xm_file="${xm_file} alpha/xm-vms.h"
tmake_file=alpha/t-vms
*** config/alpha/alpha.c.old Sun Aug 17 13:42:19 1997
--- config/alpha/alpha.c Fri Aug 22 14:22:24 1997
***************
*** 1198,1208 ****
case TYPE_IMULL:
case TYPE_IMULQ:
/* In these cases, we save one cycle. */
! return cost - 2;
default:
/* In all other cases, we save two cycles. */
! return MAX (0, cost - 4);
}
/* Another case that needs adjustment is an arithmetic or logical
--- 1198,1208 ----
case TYPE_IMULL:
case TYPE_IMULQ:
/* In these cases, we save one cycle. */
! return cost - 1;
default:
/* In all other cases, we save two cycles. */
! return MAX (0, cost - 2);
}
/* Another case that needs adjustment is an arithmetic or logical
***************
*** 1220,1226 ****
return cost;
default:
! return 2;
}
/* The final case is when a compare feeds into an integer branch. The cost
--- 1220,1226 ----
return cost;
default:
! return 1;
}
/* The final case is when a compare feeds into an integer branch. The cost
***************
*** 1230,1236 ****
&& get_attr_type (dep_insn) == TYPE_ICMP
&& recog_memoized (insn) >= 0
&& get_attr_type (insn) == TYPE_IBR)
! return 2;
/* Otherwise, return the default cost. */
--- 1230,1236 ----
&& get_attr_type (dep_insn) == TYPE_ICMP
&& recog_memoized (insn) >= 0
&& get_attr_type (insn) == TYPE_IBR)
! return 1;
/* Otherwise, return the default cost. */
*** config/alpha/alpha.h.old Sun Aug 17 13:41:13 1997
--- config/alpha/alpha.h Fri Aug 22 14:39:37 1997
***************
*** 1594,1599 ****
--- 1594,1602 ----
our own exit function. */
#define HAVE_ATEXIT
+ /* The ev4 are dual issue; ev5 cpus are quad issue. */
+ #define ISSUE_RATE (alpha_cpu == PROCESSOR_EV4 ? 2 : 4)
+
/* Compute the cost of computing a constant rtl expression RTX
whose rtx-code is CODE. The body of this macro is a portion
of a switch statement. If the code is computed here,
*** config/alpha/alpha.md.old Sun Aug 17 13:40:59 1997
--- config/alpha/alpha.md Fri Aug 22 15:07:59 1997
***************
*** 45,66 ****
;; BBOX, used for branches, EBOX, used for integer operations, and FBOX,
;; used for FP operations.
;;
- ;; We assume that we have been successful in getting double issues and
- ;; hence multiply all costs by two insns per cycle. The minimum time in
- ;; a function unit is 2 cycle, which will tend to produce the double
- ;; issues.
;; Memory delivers its result in three cycles.
(define_function_unit "ev4_abox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "ld,st"))
! 6 2)
;; Branches have no delay cost, but do tie up the unit for two cycles.
(define_function_unit "ev4_bbox" 1 1
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "ibr,fbr,jsr"))
! 4 4)
;; Arithmetic insns are normally have their results available after two
;; cycles. There are a number of exceptions. They are encoded in
--- 45,62 ----
;; BBOX, used for branches, EBOX, used for integer operations, and FBOX,
;; used for FP operations.
;;
;; Memory delivers its result in three cycles.
(define_function_unit "ev4_abox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "ld,st"))
! 3 1)
;; Branches have no delay cost, but do tie up the unit for two cycles.
(define_function_unit "ev4_bbox" 1 1
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "ibr,fbr,jsr"))
! 2 2)
;; Arithmetic insns are normally have their results available after two
;; cycles. There are a number of exceptions. They are encoded in
***************
*** 69,75 ****
(define_function_unit "ev4_ebox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "iadd,ilog,ldsym,shift,cmov,icmp"))
! 4 2)
;; These really don't take up the integer pipeline, but they do occupy
;; IBOX1; we approximate here.
--- 65,71 ----
(define_function_unit "ev4_ebox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "iadd,ilog,ldsym,shift,cmov,icmp"))
! 2 1)
;; These really don't take up the integer pipeline, but they do occupy
;; IBOX1; we approximate here.
***************
*** 77,211 ****
(define_function_unit "ev4_ebox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imull"))
! 42 2)
(define_function_unit "ev4_ebox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imulq"))
! 46 2)
(define_function_unit "ev4_imult" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imull"))
! 42 38)
(define_function_unit "ev4_imult" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imulq"))
! 46 42)
(define_function_unit "ev4_fbox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fadd,fmul,fcpys"))
! 12 2)
(define_function_unit "ev4_fbox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivs"))
! 68 0)
(define_function_unit "ev4_fbox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivt"))
! 126 0)
(define_function_unit "ev4_divider" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivs"))
! 68 60)
(define_function_unit "ev4_divider" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivt"))
! 126 118)
\f
! ;; EV5 scheduling. EV5 can issue 4 insns per clock.
! ;; Multiply all costs by 4.
;; EV5 has two integer units.
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "iadd,ilog,icmp,ldsym"))
! 4 4)
;; Memory takes at least 2 clocks.
;; Conditional moves always take 2 ticks.
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "ld,cmov"))
! 8 4)
;; Loads can dual issue. Store cannot; nor can loads + stores.
;; Model this with a mythical load/store unit.
(define_function_unit "ev5_ldst" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "ld"))
! 8 4 [(eq_attr "type" "st")])
(define_function_unit "ev5_ldst" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "st"))
! 4 4)
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imull"))
! 32 4)
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imulq"))
! 48 4)
;; Multiplies also use the integer multiplier.
(define_function_unit "ev5_imult" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imull"))
! 16 8)
(define_function_unit "ev5_imult" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imulq"))
! 48 32)
;; There is only 1 shifter/zapper.
(define_function_unit "ev5_shift" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "shift"))
! 4 4)
;; We pretend EV5 has symmetrical 2 fpus,
;; even though cpys is the only insn that can issue on either unit.
(define_function_unit "ev5_fpu" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fadd,fmul,fcpys"))
! 16 4)
;; Multiplies (resp. adds) also use the fmul (resp. fadd) units.
(define_function_unit "ev5_fpmul" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fmul"))
! 16 4)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fadd"))
! 16 4)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fbr"))
! 4 4)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fdivs"))
! 60 4)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fdivt"))
! 88 4)
\f
;; First define the arithmetic insns. Note that the 32-bit forms also
;; sign-extend.
--- 73,206 ----
(define_function_unit "ev4_ebox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imull"))
! 21 1)
(define_function_unit "ev4_ebox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imulq"))
! 23 1)
(define_function_unit "ev4_imult" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imull"))
! 21 19)
(define_function_unit "ev4_imult" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "imulq"))
! 23 21)
(define_function_unit "ev4_fbox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fadd,fmul,fcpys"))
! 6 1)
(define_function_unit "ev4_fbox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivs"))
! 34 0)
(define_function_unit "ev4_fbox" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivt"))
! 63 0)
(define_function_unit "ev4_divider" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivs"))
! 34 30)
(define_function_unit "ev4_divider" 1 0
(and (eq_attr "cpu" "ev4")
(eq_attr "type" "fdivt"))
! 64 59)
\f
! ;; EV5 scheduling.
;; EV5 has two integer units.
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "iadd,ilog,icmp,ldsym"))
! 1 1)
;; Memory takes at least 2 clocks.
;; Conditional moves always take 2 ticks.
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "ld,cmov"))
! 2 1)
;; Loads can dual issue. Store cannot; nor can loads + stores.
;; Model this with a mythical load/store unit.
(define_function_unit "ev5_ldst" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "ld"))
! 2 1 [(eq_attr "type" "st")])
(define_function_unit "ev5_ldst" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "st"))
! 2 2)
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imull"))
! 8 1)
(define_function_unit "ev5_ebox" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imulq"))
! 12 1)
;; Multiplies also use the integer multiplier.
(define_function_unit "ev5_imult" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imull"))
! 8 4)
(define_function_unit "ev5_imult" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "imulq"))
! 12 8)
;; There is only 1 shifter/zapper.
(define_function_unit "ev5_shift" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "shift"))
! 1 1)
;; We pretend EV5 has symmetrical 2 fpus,
;; even though cpys is the only insn that can issue on either unit.
(define_function_unit "ev5_fpu" 2 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fadd,fmul,fcpys"))
! 4 1)
;; Multiplies (resp. adds) also use the fmul (resp. fadd) units.
(define_function_unit "ev5_fpmul" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fmul"))
! 4 1)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fadd"))
! 4 1)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fbr"))
! 1 1)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fdivs"))
! 15 1)
(define_function_unit "ev5_fpadd" 1 0
(and (eq_attr "cpu" "ev5")
(eq_attr "type" "fdivt"))
! 22 1)
\f
;; First define the arithmetic insns. Note that the 32-bit forms also
;; sign-extend.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re:
1997-08-26 21:22 (no subject) Eliot Dresselhaus
@ 1997-10-17 23:35 ` Jeffrey A Law
0 siblings, 0 replies; 38+ messages in thread
From: Jeffrey A Law @ 1997-10-17 23:35 UTC (permalink / raw)
To: Eliot Dresselhaus; +Cc: egcs
In message <199708262120.OAA26639@wally.edc.com>you write:
> Here is a patch which makes Haifa the default scheduler for
> alpha-*-* targets and changes insn timings to reflect this.
>
> This seems generate much better floating point code than the
> old scheduler and seems to bootstrap.
>
> I'd appreciate any feedback on these diffs from alpha hackers. Thanks.
Richard Henderson installed changes into the last snapshot which
should be roughly equivalent, maybe even a little better.
Note we haven't made haifa the default scheduler for the alpha
though. I'll leave that decision to Richard and the other
Alpha about when to make the switch.
jeff
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2024-01-05 10:58 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-18 16:20 Josep Maria
2002-10-18 16:22 ` Re: Josep Maria
-- strict thread matches above, loose matches on Subject: below --
2024-01-05 9:57 Nani Rodrigue
2024-01-05 10:34 ` Jonathan Wakely
2024-01-05 10:58 ` Re: LIU Hao
2023-11-18 21:22 Zebediah Beck
2023-11-18 23:52 ` David Edelsohn
2023-11-18 23:57 ` Re: Zebediah Beck
2023-01-13 5:41 Re: father.dominic
2022-05-22 21:20 Skrab Skrab
2022-05-22 22:12 ` David Edelsohn
2021-06-12 23:32 nayeemislam031702
2021-06-12 23:35 ` Aaron Gyes
2011-09-23 22:54 Re: Lawrence Gutsin
2011-06-29 15:42 Re: nicole8509
[not found] <20080618135807.GA15427@bromo.msbb.uc.edu>
2008-06-18 18:02 ` Mike Stump
2008-01-10 16:29 Selina Ewing
2005-08-01 14:18 Chunjiang Li
2005-08-01 14:37 ` Daniel Berlin
2005-07-15 21:22 Re: ИнфоПространство
[not found] <m3d5q5b0pw.fsf@localhost.localdomain>
2005-06-29 18:48 ` Re: Bryce McKinlay
2005-06-29 20:40 ` Re: Mark Mitchell
2005-06-29 21:54 ` Re: Jeffrey A Law
2005-06-29 23:17 ` Re: Joe Buck
2005-06-29 21:57 ` Re: Geoffrey Keating
2005-06-29 23:43 ` Re: Aalokrai Porwal
2004-12-11 3:30 Re: Лада Власовна
2004-11-29 5:11 Re: Елена Климентьевна
[not found] <044DA5B8-0E8E-11D9-80A2-000A95D7CD40@apple.com>
[not found] ` <9D4EDFF8-0E91-11D9-AC54-000393A91CAA@apple.com>
2004-09-25 10:54 ` Re: Dale Johannesen
2004-09-25 11:14 ` Re: Daniel Berlin
2004-09-25 11:31 ` Re: Richard Henderson
2004-09-07 13:59 Problem with operand handling Richard Kenner
2004-09-07 14:41 ` Diego Novillo
2004-09-07 14:51 ` Andrew MacLeod
2004-09-07 15:46 ` Nathan Sidwell
2004-09-07 15:55 ` Re: Andrew MacLeod
[not found] <200305221636.h4MGaLDA010075@mururoa.inria.fr>
2003-05-22 16:45 ` Re: Daniel Berlin
2002-09-04 22:16 Re: ZMSECTT-2
2001-12-10 19:14 Re: Richard Kenner
1998-04-08 2:13 No Subject Yuan Xie
1998-04-08 15:08 ` Jeffrey A Law
1998-03-27 15:18 No Subject Ken Faiczak
1998-03-31 0:46 ` Jeffrey A Law
1998-02-10 3:34 Re: Jochen Kuepper
1998-02-10 10:30 ` Re: Jeffrey A Law
1998-02-09 14:46 No Subject Jochen Kuepper
1998-02-09 15:37 ` Jeffrey A Law
1997-12-05 13:11 No Subject Thomas Weise
1997-12-06 9:23 ` Jeffrey A Law
1997-08-26 21:22 (no subject) Eliot Dresselhaus
1997-10-17 23:35 ` Jeffrey A Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).