Re:

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.

(no subject)

[Nani Rodrigue]

[-- Attachment #1: Type: text/plain, Size: 88 bytes --]

Good morning

Can I get the last version of an application of gcc for Windows ?

Thanks

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:

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

(no subject)

[Zebediah Beck]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

I would like that contribute technical documentation to the community

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:

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

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

 

 

 

(no subject)

[Skrab Skrab]

How can i contribute to gcc.

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

(no subject)

[nayeemislam031702]

Sent from my Samsung Galaxy smartphone.

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!

(no subject)

[Chunjiang Li]

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.

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:

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

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

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

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

Âíèìàíèå àêöèÿ!
Çàêàæèòå äî 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:

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

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

[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: Problem with operand handling

[Richard Kenner]

    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;

}

Re: Problem with operand handling

[Diego Novillo]

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.

Re: Problem with operand handling

[Andrew MacLeod]

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

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

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

No Subject

[Yuan Xie]

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

          

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

No Subject

[Ken Faiczak]

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

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:

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

No Subject

[Jochen Kuepper]

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

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

No Subject

[Thomas Weise]

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)

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

(no subject)

[Eliot Dresselhaus]

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.

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