Re:

Re:

[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.

 

 

 

Re:

[LIU Hao]

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

Re:

[Jonathan Wakely]

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.

Re:

[Zebediah Beck]

[-- 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
>
>
>

Re:

[David Edelsohn]

[-- 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

Re:

[David Edelsohn]

On Sun, May 22, 2022 at 5:21 PM Skrab Skrab via Gcc <gcc@gcc.gnu.org> wrote:
>
> How can i contribute to gcc.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

Re:

[Aaron Gyes]

Sent from my MacBook Air

Re:

[Lawrence Gutsin]

You are tired of overweight? Don�t worry!..  
http://www.vive-la-sante.com/com.page.php?ovPage=80o3

Re:

[nicole8509]

It�s a brill site where you can buy everything you want!.  
http://theplugnpray.net/best2011.php?ohpage=56m4

Re: re:

[Mike Stump]

On Jun 18, 2008, at 6:58 AM, Jack Howarth wrote:
> someone has proposed a patch to allow static linkage of libgfortran
> into fortran programs on darwin. One of the Darwin maintainers
> should review this since it touches the gcc/config/x-darwin
> file. FYI.
>
> http://gcc.gnu.org/ml/gcc/2008-06/msg00362.html

Looks fine to me.

Re:

[Selina Ewing]

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!

Re:

[Daniel Berlin]

On Mon, 2005-08-01 at 22:36 +0800, Chunjiang Li wrote:
> 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
> 

See df.h/df.c

Re:

[ИнфоПространство]

[-- 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

Re:

[Aalokrai Porwal]

Hi Guys,

I don't any feedback but I am having problem sending to gcc@gcc.gnu.org. Is 
there a trick to send email? I signed up for the mailing list today. Any 
suggestion would be helpful.

Best regards,
~Aalok

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Re:

[Joe Buck]

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.

Re:

[Geoffrey Keating]

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...

Re: Re:

[Jeffrey A Law]

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.

Re:

[Mark Mitchell]

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

Re:

[Bryce McKinlay]

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

Re:

[Лада Власовна]

Âíèìàíèå àêöèÿ!
Çàêàæèòå äî 20 äekaáðÿ Å-ìàil paccûëêy è noëy÷è áîíóñ(paccûëêy ïî icq)....
 
agee@3432.cjb.net 





\0

Re:

[Елена Климентьевна]

Âíèìàíèå!
Òîëüêî äî 1 äåêàáðÿ 2OO4 ãîäà âû ñìîæåòå çàêàçàòü Å-Mail paccûëêó(ïëàòíî) è ïîëó÷èòü paccûëêó ïî icq(áåñïëàòíî)....
 
annotate@e881.cjb.net 





\0

Re: Re:

[Richard Henderson]

On Fri, Sep 24, 2004 at 07:36:24PM -0700, Dale Johannesen wrote:
> Thanks, I was looking at tree-ssa.texi:

It is indeed out of date.

> The version in
> tree-gimple.c doesn't seem to allow ADDR_EXPR, but clearly it has to:

Indeed, there is a bug here.  We should have 

   call-arg-list: TREE_LIST
                        members -> lhs | CONST

> I propose to put a single copy of it one place or the other
> (I'd prefer the texi file), with a pointer to the master copy
> in the other place.  Comments?

Putting the master copy in the documentation does sound best.


r~

Re: Re:

[Daniel Berlin]

On Fri, 2004-09-24 at 19:36 -0700, Dale Johannesen wrote:
> On Sep 24, 2004, at 6:24 PM, Devang Patel wrote:
> > On Sep 24, 2004, at 5:58 PM, Dale Johannesen wrote:
> >> I'm tracking down a crash I'm getting locally.  It's not clear yet 
> >> this is connected,
> >> but I see a tree of this form in the Gimple and SSA dumps:
> >>
> >>   *pTmp4<D6472> = __NAGf90_dcdivdc (*pTmp2<D6470>, *pTmp3<D6471>);
> >>
> >> The Gimple doc does not allow a pointer deref in a function argument.
> >> Is is supposed to?
> >
> > It says CALL_EXPR arguments are valid LHS. So it allows. I am reading 
> > comment at the beginning of tree-gimple.c
> 
> Thanks, I was looking at tree-ssa.texi:
> 
> call-stmt: CALL_EXPR
>    op0 -> _DECL | '&' _DECL
>    op1 -> arglist
> arglist:
>    NULL_TREE
>    | TREE_LIST
>        op0 -> val
>        op1 -> arglist
> val : _DECL | CONST
> 
> There seem to be a number of differences.   Apparently the 
> tree-ssa.texi version is older, as it's
> closer (but not identical) to the summit paper, but some nits have 
> crept in.   The version in
> tree-gimple.c doesn't seem to allow ADDR_EXPR, but clearly it has to:
> 
>   __NAGf90_write (6, &FMT_129<D6540>, -1, 0B, 0, 0);
> 

Actually, it *doesn't* allow random ADDR_EXPR.
We consider min_invariant things to be CONST.
That's why you see &<something> in the arglist, becuase it's invariant.

Random ADDR_EXPR's are *NOT* allowed in the call argument list, nor
should they be.

-- 

Re: Re:

[Dale Johannesen]

On Sep 24, 2004, at 6:24 PM, Devang Patel wrote:
> On Sep 24, 2004, at 5:58 PM, Dale Johannesen wrote:
>> I'm tracking down a crash I'm getting locally.  It's not clear yet 
>> this is connected,
>> but I see a tree of this form in the Gimple and SSA dumps:
>>
>>   *pTmp4<D6472> = __NAGf90_dcdivdc (*pTmp2<D6470>, *pTmp3<D6471>);
>>
>> The Gimple doc does not allow a pointer deref in a function argument.
>> Is is supposed to?
>
> It says CALL_EXPR arguments are valid LHS. So it allows. I am reading 
> comment at the beginning of tree-gimple.c

Thanks, I was looking at tree-ssa.texi:

call-stmt: CALL_EXPR
   op0 -> _DECL | '&' _DECL
   op1 -> arglist
arglist:
   NULL_TREE
   | TREE_LIST
       op0 -> val
       op1 -> arglist
val : _DECL | CONST

There seem to be a number of differences.   Apparently the 
tree-ssa.texi version is older, as it's
closer (but not identical) to the summit paper, but some nits have 
crept in.   The version in
tree-gimple.c doesn't seem to allow ADDR_EXPR, but clearly it has to:

  __NAGf90_write (6, &FMT_129<D6540>, -1, 0B, 0, 0);

IMO it is highly desirable for future development to have a clean 
definition.  I expect not everyone
shares MO, so I'll volunteer to clean this up, but I'll need help 
determining what it should say.  I propose to
put a single copy of it one place or the other (I'd prefer the texi 
file), with a pointer to the master copy
in the other place.  Comments?

Re: Re:

[Andrew MacLeod]

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

Re:

[Nathan Sidwell]

   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

Re:

[Daniel Berlin]

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.

Re:

[Josep Maria]

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

Re:

[Josep Maria]

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

Re:

[ZMSECTT-2]

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

Re:

[Richard Kenner]

    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.

Re:

[Jeffrey A Law]

  >         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 (bu2
  > 1)
  > *** Error code 1 (bu21)
  > 
  > 
  > 
  > How to fixed this problem??
Build with gnu-make.

jeff

Re:

[Jeffrey A Law]

  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

Re:

[Jeffrey A Law]

  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

Re:

[Jochen Kuepper]

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
-----------------------------------------------------------------------

Re:

[Jeffrey A Law]

  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

Re:

[Jeffrey A Law]

  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

Re:

[Jeffrey A Law]

  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