Re: interpreting "make -k check"

Re: interpreting "make -k check"

[Mike Stump]

> Date: Thu, 8 Jul 1999 15:47:29 -0400
> From: Art Werschulz <agw@dsm.fordham.edu>

> When I do "make -k check", I get some unexpected failures, e.g.,

> 		=== gcc Summary ===

> # of expected passes		7484
> # of unexpected failures	14
> # of expected failures		7
> # of unsupported tests		18

> How concerned should I be about these unexpected failures?

Compare with other alpha results.  The 14 is the number you want to
compare.  My guess is that this is near to what it usually is.

> Is it reasonably safe to install the compiler?

14, yes, I'd say so.

> (If you like, I can make the results of "make -k check" available to
> you via the web.)

The normal way to make the results available to us is to:

#!/bin/sh
( cd $HOME/net/egcs && $HOME/net/egcs/contrib/egcs_update -A -d; )
nice make -j3 MAKE='make -j3' clean; nice make -j3 MAKE='make -j3' bootstrap && { nice make -k check; $HOME/net/egcs/contrib/test_summary | sh -x
}
>From ian@tharas.com Thu Jul 08 17:01:00 1999
From: Ian Nixon <ian@tharas.com>
To: egcs-bugs@egcs.cygnus.com
Subject: problem with g++ & -O optimization
Date: Thu, 08 Jul 1999 17:01:00 -0000
Message-id: <37853BAE.33071723@tharas.com>
X-SW-Source: 1999-07/msg00325.html
Content-length: 904

  Hi folks,
    I see the following problem when using:

gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

on sparc-sun-solaris2.6

With the following code:

#include <stdio.h>

struct Base {
  virtual void action () = 0;

  void DoIt () {
        action ();
  } 
};

void func ()
{
  struct Derived : public Base {
        void action () { printf ("Hello Mum\n"); }
  };

  Derived d;

  d.DoIt ();
}

main ()
{
  func ();
}

// --- End Code

  this is OK:

g++ main.cc -o main

  but this is not:

g++ main.cc -o main -O
Undefined                       first referenced
 symbol                             in file
action__Q210func__Fv.0_7Derived.4   /var/tmp/ccv0pGG1.o
ld: fatal: Symbol referencing errors. No output written to main
collect2: ld returned 1 exit status

  Has anyone seen this before? Moving the "Derived" struct out of the
function makes the problem go away.

  Thanks
    Ian.
>From house@usq.edu.au Thu Jul 08 18:38:00 1999
From: Ron House <house@usq.edu.au>
To: egcs-bugs@egcs.cygnus.com
Subject: [Fwd: egcs internal error]
Date: Thu, 08 Jul 1999 18:38:00 -0000
Message-id: <3785524B.6ACB5AB1@usq.edu.au>
X-SW-Source: 1999-07/msg00326.html
Content-length: 111

-- 
Ron House            house@usq.edu.au

The evils of each age always seem self-evidently right at the time.
>From craig@jcb-sc.com Thu Jul 08 19:13:00 1999
From: craig@jcb-sc.com
To: martin.kahlert@provi.de
Cc: craig@jcb-sc.com
Subject: Re: Showstopper in g77 in prerelease on Linux-Alpha
Date: Thu, 08 Jul 1999 19:13:00 -0000
Message-id: <19990709015119.16258.qmail@deer>
References: <199907082138.XAA00190@keksy.linux.provi.de>
X-SW-Source: 1999-07/msg00327.html
Content-length: 4317

>This is clearly a show stopper for me, since my program relies heavily on NINT.

Are you by any chance using Redhat Linux 6.0, or something equivalent?

Reason I ask is, there have already been reports that the libm.a routine
that implements NINT is broken.

Enclosed is some earlier email that you might find pertinent.

If it doesn't apply, and you still believe g77 (or gcc) itself is
at fault, definitely let us know ASAP!

        tq vm, (burley)

>X-Coding-System: undecided-unix
>Mail-from: From craig@jcb-sc.com Mon Jun 07 23:42:04 1999
>Return-Path: <craig@jcb-sc.com>
>Delivered-To: craig@localhost
>Received: (qmail 10522 invoked from network); 7 Jun 1999 23:42:04 -0000
>Received: from localhost (root@127.0.0.1)
>  by localhost with SMTP; 7 Jun 1999 23:42:04 -0000
>Received: from world.std.com
>	by fetchmail-4.5.8 POP3
>	for <craig/localhost> (single-drop); Mon, 07 Jun 1999 19:42:04 EDT
>Received: from mescaline.gnu.org by world.std.com (TheWorld/Spike-2.0)
>	id AA08030; Mon, 7 Jun 1999 14:28:23 -0400
>Received: from tug.org (IDENT:root@tug.org [158.121.106.10])
>	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id OAA12898
>	for <fortran@gnu.org>; Mon, 7 Jun 1999 14:28:16 -0400
>From: niles@fan745.gsfc.nasa.gov
>Received: from wheelo.gsfc.nasa.gov (wheelo.gsfc.nasa.gov [128.183.50.20])
>	by tug.org (8.9.1/8.9.1) with ESMTP id XAA04435
>	for <fortran@gnu.org>; Sun, 6 Jun 1999 23:38:48 -0400
>Received: from fan745.gsfc.nasa.gov (root@fan745.gsfc.nasa.gov [128.183.146.42])
>	by wheelo.gsfc.nasa.gov (8.8.8/8.8.8) with ESMTP id XAA25217
>	for <fortran@gnu.org>; Sun, 6 Jun 1999 23:36:18 -0400 (EDT)
>Received: from fan745.gsfc.nasa.gov (IDENT:niles@localhost [127.0.0.1])
>	by fan745.gsfc.nasa.gov (8.9.3/8.8.7) with ESMTP id XAA09547
>	for <fortran@gnu.org>; Sun, 6 Jun 1999 23:37:23 -0400
>Message-Id: <199906070337.XAA09547@fan745.gsfc.nasa.gov>
>To: fortran@gnu.org
>Subject: Re: Scary problems in g77 for RedHat 6.0. (glibc-2.1) 
>Date: Sun, 06 Jun 1999 23:37:23 -0400
>X-UIDL: 9c1e40c572e3b306464f703461764cd5
>
>
>Check out this program:
>
>#include <stdio.h>
>#include <math.h>
>
>int
>main()
>{
>  printf("%f\n",floor(0.1));
>  return 0;
>}
>
>---------------
>
>It will result in 36028797018963968.000000 on Alpha RedHat Linux 6.0
>using glibc-2.1 at least on my 21064.  This may result in g77 bug
>reports concerning the INT() function, just so you know.
>
>	Thanks,	
>	Rick Niles.


>From: niles@fan745.gsfc.nasa.gov
>To: fortran@gnu.org
>Cc: niles@fan745.gsfc.nasa.gov
>Subject: problem with DNINT() on Linux/Alpha.
>Date: Sun, 06 Jun 1999 16:39:35 -0400
>X-UIDL: 6aa9208d7bda8b6182a095dfd37016b7
>
>
>This is probably the short bug report ever. :)
>
>----
>      WRITE(*,*) DNINT(0.0D0)
>      STOP
>      END
>----
>
>Result on Linux/i386: " 0."  (and every other computer!)
>Result on Linux/alpha: " 3.6028797E+16"
>
>It seems to work fine if I change it to the generic NINT().  Probably
>a name pollution problem in the new C library, but it seems bad. no?
>
>	Thanks,
>	Rick Niles.

[This last was private email, but I'm pretty confident Rick wouldn't
mind my publishing it!]


>From: niles@fan745.gsfc.nasa.gov
>To: craig@jcb-sc.com
>Subject: Re: problem with DNINT() on Linux/Alpha. 
>In-Reply-To: Your message of "08 Jun 1999 00:52:33 -0000."
>             <19990608005233.11029.qmail@deer> 
>Date: Mon, 07 Jun 1999 23:10:02 -0400
>X-UIDL: afdb0636b5b84851c2dbbbf701737719
>
>
>> >It seems to work fine if I change it to the generic NINT().  Probably
>> >a name pollution problem in the new C library, but it seems bad. no?
>> 
>> I've lost track -- did this turn out to be due to the -lf2c bug
>> as well?
>
>No. Sorry about the crazy number of bug reports...
>
>This was due to a bug in the floor() function in the glibc libm
>shipped with RedHat-6.0 for Alpha.  I reported it earlier but it's
>basically that floor() is really broken and reports all crazy values.
>Thus, the FORTRAN INT() family which relies on it is broken on this
>setup too.  I was wondering if anyone had a fix to the libm or perhaps
>just the <bits/mathinline.h> file.  This could also be 21064
>specific. (i.e. it may work OK on a 21164 or greater machine.)  I did
>a fresh install of the complete RedHat 6.0, so I don't think it's a
>configuration problem.
>
>	      Thanks,
>	      Rick Niles.
>From wilson@cygnus.com Thu Jul 08 19:19:00 1999
From: Jim Wilson <wilson@cygnus.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: egcs-bugs@egcs.cygnus.com, law@cygnus.com, wilson@cygnus.com
Subject: Re: gcc-2.95 19990627 irix6 bootstrap fails with "-O3 -funroll-all-loops" 
Date: Thu, 08 Jul 1999 19:19:00 -0000
Message-id: <199907090219.TAA06017@rtl.cygnus.com>
References: <199907020212.WAA05700@caip.rutgers.edu>
X-SW-Source: 1999-07/msg00328.html
Content-length: 1912

I got a bootstrap with this patch.  I'm not particularly happy with it though.
I tried to fix the problem in unroll.c to reduce the impact of the patch, but
after all the trouble I had, I think it would be simpler to add code to
delete_insn to check for NOTE_INSN_DELETED_LABEL and then not delete it.

Thu Jul  8 19:15:51 1999  Jim Wilson  <wilson@cygnus.com>

	* unroll.c (unroll_loops): Don't delete named CODE_LABEL or
	NOTE_INSN_DELETED_LABEL note.

Index: unroll.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/unroll.c,v
retrieving revision 1.57
diff -p -r1.57 unroll.c
*** unroll.c	1999/05/05 15:47:48	1.57
--- unroll.c	1999/07/09 02:15:36
*************** unroll_loop (loop_end, insn_count, loop_
*** 1262,1268 ****
    insn = NEXT_INSN (copy_start);
    while (insn != safety_label)
      {
!       if (insn != start_label)
  	insn = delete_insn (insn);
        else
  	insn = NEXT_INSN (insn);
--- 1262,1279 ----
    insn = NEXT_INSN (copy_start);
    while (insn != safety_label)
      {
!       /* ??? Don't delete named code labels.  They will be deleted when the
! 	 jump that references them is deleted.  Otherwise, we end up deleting
! 	 them twice, which causes them to completely disappear instead of turn
! 	 into NOTE_INSN_DELETED_LABEL notes.  This in turn causes aborts in
! 	 dwarfout.c/dwarf2out.c.  We could perhaps fix the dwarf*out.c files
! 	 to handle deleted labels instead.  Or perhaps fix DECL_RTL of the
! 	 associated LABEL_DECL to point to one of the new label instances.  */
!       /* ??? Likewise, we can't delete a NOTE_INSN_DELETED_LABEL note.  */
!       if (insn != start_label
! 	  && ! (GET_CODE (insn) == CODE_LABEL && LABEL_NAME (insn))
! 	  && ! (GET_CODE (insn) == NOTE
! 		&& NOTE_LINE_NUMBER (insn) == NOTE_INSN_DELETED_LABEL))
  	insn = delete_insn (insn);
        else
  	insn = NEXT_INSN (insn);
>From hchang-tky@umin.ac.jp Thu Jul 08 20:58:00 1999
From: <hchang-tky@umin.ac.jp>
To: egcs-bugs@egcs.cygnus.com
Subject: bug?
Date: Thu, 08 Jul 1999 20:58:00 -0000
Message-id: <199907091712.NAA01134@hckb-13.c.u-tokyo.ac.jp>
X-SW-Source: 1999-07/msg00329.html
Content-length: 557

When I compile and run the following program,
I get an unexpected result.
It prints
> -1 0
instead of
> 0 1

If I change N to 7, it works fine.
Am I missing something?

-------------------------------------------

#include <stdio.h>

#define N 8

typedef struct {
  int base;
  int form[N];
} frame;

int main()
{
  frame frame_stack[10], frames[10], *fp;
  int i;

  frame_stack[0].base = 0;
  frame_stack[1].base = 1;
  fp = frames;
  for(i=0;i<2;++i){
    *fp++ = frame_stack[i];
  }
  
  printf("%d %d\n", frames[0].base, frames[1].base);
  return 0;
}
>From law@cygnus.com Thu Jul 08 22:07:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: hchang-tky@umin.ac.jp
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: bug? 
Date: Thu, 08 Jul 1999 22:07:00 -0000
Message-id: <4250.931496494@upchuck.cygnus.com>
References: <199907091712.NAA01134@hckb-13.c.u-tokyo.ac.jp>
X-SW-Source: 1999-07/msg00330.html
Content-length: 1075

  In message < 199907091712.NAA01134@hckb-13.c.u-tokyo.ac.jp >you write:
  > 
  > When I compile and run the following program,
  > I get an unexpected result.
  > It prints
  > > -1 0
  > instead of
  > > 0 1
  > 
  > If I change N to 7, it works fine.
  > Am I missing something?
  > 
  > -------------------------------------------
  > 
  > #include <stdio.h>
  > 
  > #define N 8
  > 
  > typedef struct {
  >   int base;
  >   int form[N];
  > } frame;
  > 
  > int main()
  > {
  >   frame frame_stack[10], frames[10], *fp;
  >   int i;
  > 
  >   frame_stack[0].base = 0;
  >   frame_stack[1].base = 1;
  >   fp = frames;
  >   for(i=0;i<2;++i){
  >     *fp++ = frame_stack[i];
  >   }
  >   
  >   printf("%d %d\n", frames[0].base, frames[1].base);
  >   return 0;
Unfortunately you did not file a complete bug report.  You didn't mention
what configuration shows this problem.  You did not mention what version of 
egcs you were using, nor did you mention what compile flags you used.

Please see the FAQ for help in filing a complete bug report.

jeff
  > }
  > 

interpreting "make -k check"

[Art Werschulz]

Hi.

I've built egcs-1.1.2 on a Compaq (nee Digital) AlphaServer1000,
running Digital Unix 4.0E.

When I do "make -k check", I get some unexpected failures, e.g.,

		=== gcc Summary ===

# of expected passes		7484
# of unexpected failures	14
# of expected failures		7
# of unsupported tests		18

How concerned should I be about these unexpected failures?  Is it
reasonably safe to install the compiler?

(If you like, I can make the results of "make -k check" available to
you via the web.)

Thanks.


-- 
Art Werschulz (8-{)}   "Metaphors be with you."  -- bumper sticker
GCS/M (GAT): d? -p+ c++ l u+(-) e--- m* s n+ h f g+ w+ t++ r- y? 
Net: agw@dsm.fordham.edu <a href=" http://www.dsm.fordham.edu/~agw/ ">WWW</a>
Phone:   Fordham U. (212) 636-6325, Columbia U. (212) 939-7061