This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Fw: Don't build libgcj on irix6.5 - still doesn't work


Would one of you mind addressing this issue?

I suggest applying David's patch until someone has a chance to get
libgcj working on IRIX.

However, I don't want to do so if there is something else in the
works.  Would one of you care to either apply the patch, or to reply
to his message?

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com



gcc-patches Digest 16 Mar 2001 02:14:27 -0000 Issue 1594

Topics (messages 31234 through 31263):

Silence warning in hashtab.c
	31234 by: Michael Meissner <meissner@cygnus.com>

PATCH: if -fpic then don't consider PIC_OFFSET_TABLE_REGNUM updates dead
	31235 by: Alexandre Oliva <aoliva@redhat.com>
	31236 by: Richard Henderson <rth@redhat.com>

PATCH: cgi-bin/gnatsweb.pl
	31237 by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
	31239 by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>

[v3] tests_flags.in tweak
	31238 by: Benjamin Kosnik <bkoz@redhat.com>

Hopeful patch for configure breakage
	31240 by: "Zack Weinberg" <zackw@Stanford.EDU>
	31248 by: John Wehle <john@feith.com>
	31252 by: "Zack Weinberg" <zackw@Stanford.EDU>
	31253 by: John Wehle <john@feith.com>
	31256 by: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
	31257 by: "Zack Weinberg" <zackw@Stanford.EDU>
	31258 by: "Zack Weinberg" <zackw@Stanford.EDU>
	31262 by: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
	31263 by: "Zack Weinberg" <zackw@Stanford.EDU>

PATCH: Parallel build fix.
	31241 by: Brad Lucier <lucier@math.purdue.edu>

Fix memory leak in cp-demangle.c
	31242 by: Jim Blandy <jimb@zwingli.cygnus.com>

Don't build libgcj on irix6.5 - still doesn't work
	31243 by: "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com>

[PATCH] Prevent g++ testsuite crahing on cygwin
	31244 by: "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com>

unreviewed DJGPP bootstrap fix
	31245 by: "Mark E." <snowball3@bigfoot.com>

Patch to fix i960 objc runtime build
	31246 by: John Wehle <john@feith.com>

#pragma interface (was Re: ia64 c++ abi exception handling)
	31247 by: Jason Merrill <jason@redhat.com>
	31254 by: Geoff Keating <geoffk@geoffk.org>

eliminate warning in i386.md
	31249 by: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

fix arguments to ix86_expand_compare
	31250 by: Matt Kraai <kraai@alumni.carnegiemellon.edu>

x86_64 merger part 15 - new extra constraints
	31251 by: Matt Kraai <kraai@alumni.carnegiemellon.edu>

dwarf2 offsets vs program addresses
	31255 by: Richard Henderson <rth@redhat.com>

PATCH: Lazy DECL_RTL
	31259 by: Rod Stewart <stewart@dystopia.lab43.org>
	31260 by: Mark Mitchell <mark@codesourcery.com>

GCC 3.0 Request
	31261 by: Geoff Keating <geoffk@geoffk.org>

Administrivia:

To subscribe to the digest, e-mail:
	gcc-patches-digest-subscribe@gcc.gnu.org

To unsubscribe from the digest, e-mail:
	gcc-patches-digest-unsubscribe@gcc.gnu.org

To post to the list, e-mail:
	gcc-patches@gcc.gnu.org


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


On Thu, Mar 15, 2001 at 08:56:18PM +0000, Graham Stott wrote:
> Micheal
> 
> Michael Meissner wrote:
> 
> > !                                       /* 4294967291L */
> > !     ((unsigned long) 2147483647) + ((unsigned long) 2147483642),
> 
> 2147483647 + 2147483642 != 4294967291
> 
> Shouldn't that be 2147483644

Right you are, good catch.  I've fixed it.  Thanks.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482



On Mar 15, 2001, Richard Henderson <rth@redhat.com> wrote:

> On Thu, Mar 15, 2001 at 02:18:38AM -0800, Toshi Morita wrote:
>> If -fpic is specified, then updates to the PIC_OFFSET_TABLE_REGNUM
>> should never be considered dead.

> After reload, all uses of the pic register should be visible.  If not,
> something's wrong elsewhere.  Quite possibly in the port, since this
> is an area where we have been traditionally sloppy.

Actually, I've taken a lot of care to avoid emitting the PIC reg load
when it's not necessary, and flagging it as necessary whenever it
actually is.  However, there still are cases in which some
optimizations remove the only active use of the PIC reg, and then flow
complains.

At some point, I had a patch that would mark the PIC reg load as
MAYBE_DEAD, but someone advised against it, and, after some further
improvements, I hadn't met the problem any more.  But it used to be
just a warning.  Only recently did it become a hard error, so it may
have gone unnoticed.  I still think marking it as MAYBE_DEAD is the
right way to fix the problem.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



On Thu, Mar 15, 2001 at 07:29:58PM -0300, Alexandre Oliva wrote:
> I still think marking it as MAYBE_DEAD is the right way to fix the problem.

Certainly better than hacking flow.  If Toshi has come up
with a case in which the last GOT reference is removed by
flow2, then do go ahead and use MAYBE_DEAD.


r~



Simplify the GCC-specific hacks a bit.

Installed.

Gerald

Index: gnatsweb.pl
===================================================================
RCS file: /cvs/gcc/wwwdocs/cgi-bin/gnatsweb.pl,v
retrieving revision 1.26
diff -u -3 -p -r1.26 gnatsweb.pl
--- gnatsweb.pl	2001/03/13 22:25:44	1.26
+++ gnatsweb.pl	2001/03/15 22:42:07
@@ -2399,19 +2399,21 @@ sub initialize

   @severity = ("all", "critical", "serious", "non-critical");
   @priority = ("all", "high", "medium", "low");
-  @confidential = ("all", "no");
+  @confidential = ("all", "no", "yes");

   # @fields - param names of columns displayable in query results
   # @deffields - default displayed columns
   @deffields = ("category", "state", "responsible", "synopsis");
-  #GCC-LOCAL begin.
-  @deffields = ("category", "state", "class", "responsible", "synopsis");
-  #GCC-LOCAL end.
   @fields = ("category", "confidential", "state", "class",
              "severity", "priority",
              "release", "quarter", "responsible", "submitter_id", "originator",
              "arrival_date", "date_required",
              "last_modified", "closed_date", "synopsis");
+
+  #GCC-LOCAL begin.
+  @confidential = ("all", "no");
+  @deffields = ("category", "state", "class", "responsible", "synopsis");
+  #GCC-LOCAL end.

   # @fieldnames - fields appear in the standard order, defined by pr.h
   @fieldnames = (




I moved over the following patch from the gnats/gnatsweb cvs tree:

  2001-03-11  Tommi Virtanen  <tv@debian.org>

        * gnatsweb.pl (decode_attachment): Editing bugs with attached files
        used to bomb out trying to chomp a constant string.

as "Import the change for revision 2.25 from gnatsweb CVS".

Tom, I believe you'll want that one, too.

Gerald

Index: gnatsweb.pl
===================================================================
RCS file: /cvs/gcc/wwwdocs/cgi-bin/gnatsweb.pl,v
retrieving revision 1.27
diff -u -3 -p -r1.27 gnatsweb.pl
--- gnatsweb.pl	2001/03/15 22:47:07	1.27
+++ gnatsweb.pl	2001/03/15 22:50:11
@@ -489,14 +489,15 @@ sub decode_attachment
   my ($envelope, $body) = split(/\n\n/, $att);
   return $hash_ref unless ($envelope && $body);

-  # Got the idea from this from the perldoc for split.
-  # The extra map step is the only way I could think of to strip
-  # the trailing newlines from the hash values.
+  # Split mbox-like headers into (header, value) pairs, with a leading
+  # "From_" line swallowed into USELESS_LEADING_ENTRY. Junk the leading
+  # entry. Chomp all values.
   warn "decode_attachment: envelope=>$envelope<=\n" if $debug;
-  #%$hash_ref = (USELESS_LEADING_ENTRY => split /^(\S*?):\s*/m, $envelope);
-  %$hash_ref = (map {chomp; $_;}
-               (USELESS_LEADING_ENTRY => split /^(\S*?):\s*/m, $envelope));
-  delete($$hash_ref{USELESS_LEADING_ENTRY});
+  %$hash_ref = (USELESS_LEADING_ENTRY => split /^(\S*?):\s*/m, $envelope);
+  delete($hash_ref->{USELESS_LEADING_ENTRY});
+  for (keys %$hash_ref) {
+    chomp $hash_ref->{$_};
+  }

   # Keep the original_attachment intact.
   $$hash_ref{'original_attachment'} = $att;





Removes 3 spurious static fails. Two remaining.

2001-03-15  Benjamin Kosnik  <bkoz@redhat.com>

	* tests_flags.in (CXXFLAGS): Link libstdc++ before libsupc++.

Index: tests_flags.in
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/tests_flags.in,v
retrieving revision 1.12
diff -c -p -r1.12 tests_flags.in
*** tests_flags.in	2001/02/23 07:12:03	1.12
--- tests_flags.in	2001/03/15 22:49:15
*************** CXXFLAGS="-ggdb3 -DDEBUG_ASSERT @SECTION
*** 144,150 ****
  # LIBS == any extra needed -l switches, etc (may need more libs, lose lose)
  case ${query} in
      --built-library)
!     LIBS="${LIB_PATH}/../libsupc++/libsupc++.la ${LIB_PATH}/libstdc++.la
  	    -no-install -rpath ${GCC_LIB_PATH}"
      case @target_os@ in
          *cygwin*)  LIBS="${LIBS} -nodefaultlibs -lgcc -lcygwin -luser32
--- 144,150 ----
  # LIBS == any extra needed -l switches, etc (may need more libs, lose lose)
  case ${query} in
      --built-library)
!     LIBS="${LIB_PATH}/libstdc++.la ${LIB_PATH}/../libsupc++/libsupc++.la 
  	    -no-install -rpath ${GCC_LIB_PATH}"
      case @target_os@ in
          *cygwin*)  LIBS="${LIBS} -nodefaultlibs -lgcc -lcygwin -luser32
*************** case ${query} in
*** 153,160 ****
      esac
      ;;
      --installed-library)
!     LIBS="-L${LIB_PATH} ${LIB_PATH}/libstdc++.la -no-install
! 	    -rpath ${LIB_PATH}"
      ;;
  esac
  
--- 153,160 ----
      esac
      ;;
      --installed-library)
!     LIBS="-L${LIB_PATH} ${LIB_PATH}/libstdc++.la 
!            -no-install -rpath ${LIB_PATH}"
      ;;
  esac
  



On Thu, Mar 15, 2001 at 11:23:26AM +0100, Lars Brinkhoff wrote:
> "Zack Weinberg" <zackw@stanford.edu> writes:
> > It should also make the float format detector understand the ARM
> > better, and the message printed by the endian detector a tad less
> > stilted.
> 
> On my armv4l-unknown-linux-gnu, configure now says:
> checking floating point format... IEEE (big-endian)

Cool.  What did it set HOST_FLOAT_FORMAT, HOST_WORDS_BIG_ENDIAN, and
HOST_FLOAT_WORDS_BIG_ENDIAN to in auto-host.h?

zw



Using (ef)grep on binary data is asking for trouble.

>From the Solaris man page for egrep:

  NOTES
    /usr/xpg4/bin/egrep
       The   /usr/xpg4/bin/egrep    utility   is    identical    to
       /usr/xpg4/bin/grep   -E (see grep(1)). Portable applications
       should use /usr/xpg4/bin/grep  -E.

>From the Solaris man page for grep:

  NOTES
    /usr/xpg4/bin/grep
       The results are unspecified if  input  files  contain  lines
       longer  than LINE_MAX bytes or contain binary data. LINE_MAX
       is defined in /usr/include/limits.h.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------




On Thu, Mar 15, 2001 at 07:31:42PM -0500, John Wehle wrote:
> Using (ef)grep on binary data is asking for trouble.

Yes, but does it cause trouble in practice?  The alternatives we have
are (a) back out the patch (something I would prefer to avoid, but it
may be necessary), (b) figure out a way to compile and run a program
on the build machine (which can be done, but would be a pain).

Or - it just occurred to me - we could run the object file through
od(1).  Does anyone know how portable that is?  How 'bout with the -c
switch?  (-t x1 is definitely not portable enough, alas.)

zw



> Or - it just occurred to me - we could run the object file through
> od(1).  Does anyone know how portable that is?  How 'bout with the -c
> switch?  (-t x1 is definitely not portable enough, alas.)

You'll probably need to massage the output because of the line breaks.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------





 > Yes, but does it cause trouble in practice?  The alternatives we have
 > are (a) back out the patch (something I would prefer to avoid, but it
 > may be necessary), (b) figure out a way to compile and run a program
 > on the build machine (which can be done, but would be a pain).
 > zw

Why aren't we using the `strings' program?  Is it not ubiquitous?

Here's a gross but possibly portable strategy.  YMMV.

Compile two files, one contains:

struct possibility {
  char prefix[8];
  double candidate;
  char postfix[8];
};

the other contains:

struct possibility {
  char prefix[8];
  char expected[8];
  char postfix[8];
};

Then loop in the shell over each float-number/expected-string pair.
Initialize the struct in file 1 with the float number and the struct
in file 2 with the expected string of chars and compile both files
with -c.

Then do a tail +16c on the two files and pass them to cmp (like we do
in "make compare".)  If the two object files match (minus the first 16
chars) then you've found the floating point format.  (This is assuming
that the float/string wasn't stored in the first 16 characters, not
sure if that torpedoes my suggestion.)

I'd much prefer you used the `strings' program though. :-)

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions



On Thu, Mar 15, 2001 at 07:52:32PM -0500, John Wehle wrote:
> > Or - it just occurred to me - we could run the object file through
> > od(1).  Does anyone know how portable that is?  How 'bout with the -c
> > switch?  (-t x1 is definitely not portable enough, alas.)
> 
> You'll probably need to massage the output because of the line breaks.

Hah, a simple matter of programming.

zw



On Thu, Mar 15, 2001 at 08:23:54PM -0500, Kaveh R. Ghazi wrote:
> 
>  > Yes, but does it cause trouble in practice?  The alternatives we have
>  > are (a) back out the patch (something I would prefer to avoid, but it
>  > may be necessary), (b) figure out a way to compile and run a program
>  > on the build machine (which can be done, but would be a pain).
>  > zw
> 
> Why aren't we using the `strings' program?  Is it not ubiquitous?

Without -a it cannot be counted upon to print out the strings we want,
and -a is not ubiquitous.

Also, there is a chance that we'll get an unprintable character in the
middle of the pattern that should have matched.  This will definitely
happen to the PDP-10 port, and could happen to the EBCDIC hosts in the
presence of last-hex-digit rounding, which is known to happen already.

I'm going to look into using od to convert the object file into
something we can grep safely.

zw



    > Using (ef)grep on binary data is asking for trouble.

    Yes, but does it cause trouble in practice?  

Yes, e.g., on Alpha/Tru64.

    The alternatives we have are (a) back out the patch (something I would
    prefer to avoid, but it may be necessary), (b) figure out a way to
    compile and run a program on the build machine (which can be done, but
    would be a pain).

What's wrong with using "strings"?



On Thu, Mar 15, 2001 at 09:05:30PM -0500, Richard Kenner wrote:
> 
> What's wrong with using "strings"?

See what I said to Kaveh.

zw



hash.c include config.h.

	* Makefile.in: Make hash.o depend on CONFIG_H.

===================================================================
RCS file: RCS/Makefile.in,v
retrieving revision 1.1
diff -p -r1.1 Makefile.in
*** Makefile.in	2001/03/15 22:40:23	1.1
--- Makefile.in	2001/03/15 22:40:39
*************** collect2.o : collect2.c $(CONFIG_H) syst
*** 1215,1221 ****
  	-c $(srcdir)/collect2.c
  
  tlink.o: tlink.c $(DEMANGLE_H) hash.h $(CONFIG_H) system.h collect2.h intl.h
! hash.o: hash.c hash.h system.h toplev.h
  	$(CC) -c $(ALL_CFLAGS) -DGENERATOR_FILE $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
  
  vfprintf.o: $(srcdir)/../libiberty/vfprintf.c $(GCONFIG_H) system.h
--- 1215,1221 ----
  	-c $(srcdir)/collect2.c
  
  tlink.o: tlink.c $(DEMANGLE_H) hash.h $(CONFIG_H) system.h collect2.h intl.h
! hash.o: hash.c hash.h system.h toplev.h $(CONFIG_H)
  	$(CC) -c $(ALL_CFLAGS) -DGENERATOR_FILE $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
  
  vfprintf.o: $(srcdir)/../libiberty/vfprintf.c $(GCONFIG_H) system.h




Perhaps there's some strange sharing going on that makes this the
wrong thing to do, but I didn't notice any.

2001-03-15  Jim Blandy  <jimb@redhat.com>

	* cp-demangle.c (string_list_delete): Don't forget to free the
	actual contents of the string.

Index: libiberty/cp-demangle.c
===================================================================
RCS file: /cvs/src/src/libiberty/cp-demangle.c,v
retrieving revision 1.8
diff -c -c -3 -p -r1.8 cp-demangle.c
*** libiberty/cp-demangle.c	2001/02/02 18:58:39	1.8
--- libiberty/cp-demangle.c	2001/03/15 23:09:50
*************** string_list_delete (node)
*** 415,420 ****
--- 415,421 ----
    while (node != NULL)
      {
        string_list_t next = node->next;
+       free (node->string.s);
        free (node);
        node = next;
      }



libgcj doesn't build on irix6.5.  It has been re-enabled ont he mainline.
This disables it again.

Please apply if OK.

2001-01-16  David Billinghurst (David.Billinghurst@riotinto.com)

	* configure.in:  Do not build libgcj on irix6

Index: configure.in
===================================================================
RCS file: /cvs/gcc/egcs/configure.in,v
retrieving revision 1.95
diff -u -r1.95 configure.in
--- configure.in        2001/03/10 00:20:21     1.95
+++ configure.in        2001/03/15 23:19:24
@@ -873,7 +873,7 @@
   mips*-*-irix6*)
     # The GNU assembler does not support IRIX 6.
     # emacs is emacs 18, which does not work on Irix 5 (emacs19 does work)
-    noconfigdirs="$noconfigdirs gas gprof emacs target-libgloss"
+    noconfigdirs="$noconfigdirs gas gprof emacs target-libgloss ${libgcj}"
     ;;
   mips*-dec-bsd*)
     noconfigdirs="$noconfigdirs gprof target-libgloss ${libgcj}"



The g++ testsuite fails on cygwin.  The root cause is a bug in
old-dejagnu.exp, where it attempts to delete any output generated when the
test case is executed, in addition to deleting the executable.  See
http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00453.html.

With this patch, the g++ testsuite works on NT4/cygwin.  Bootstrapped 3.0
branch on cygwin and irix6.5

2001-03-15  David Billinghurst  (David.Billinghurst@riotinto.com)

	* lib/old-dejagnu.exp:  Don't try and delete output from executable

Index: old-dejagnu.exp
===================================================================
RCS file: /cvs/gcc/egcs/gcc/testsuite/lib/old-dejagnu.exp,v
retrieving revision 1.22
diff -u -r1.22 old-dejagnu.exp
--- old-dejagnu.exp     2001/02/08 02:29:38     1.22
+++ old-dejagnu.exp     2001/03/15 23:13:15
@@ -574,9 +574,9 @@
            }
            $status "$name $pattern Execution test"
        }
+    } else {
+        verbose "deleting $output"
+        remote_file build delete $output
     }
-
-    verbose "deleting $output"
-    remote_file build delete $output
     return 0
 }



Hi guys,

My DJGPP bootstrap fix still has not been reviewed or applied. See 
http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00623.html .

Thanks,
Mark




Currently the i960 objc runtime fails to build:

/local/build/i960-coff/GNU/gcc-current/gcc/xgcc -B/local/build/i960-coff/GNU/gcc-current/gcc/ -nostdinc -B/local/build/i960-coff/GNU/gcc-current/i960-coff/newlib/ -isystem /local/build/i960-coff/GNU/gcc-current/i960-coff/newlib/targ-include -isystem /local/src/GNU/gcc-current/newlib/libc/include -B/local/i960-coff/bin/ -B/local/i960-coff/lib/ -isystem /local/i960-coff/include -c -I. -I../../../../../../src/GNU/gcc-current/libobjc -g -O2 -DIN_GCC -DIN_TARGET_LIBS -I../../../../../../src/GNU/gcc-current/libobjc/objc -I../../../../../../src/GNU/gcc-current/libobjc/../gcc -I../../../../../../src/GNU/gcc-current/libobjc/../gcc/config -I../../gcc -I../../../../../../src/GNU/gcc-current/libobjc/../include ../../../../../../src/GNU/gcc-current/libobjc/encoding.c -o encoding.o
../../../../../../src/GNU/gcc-current/libobjc/encoding.c: In function `objc_layout_finish_structure':
../../../../../../src/GNU/gcc-current/libobjc/encoding.c:875: `REAL_TYPE' undeclared (first use in this function)
../../../../../../src/GNU/gcc-current/libobjc/encoding.c:875: (Each undeclared identifier is reported only once
../../../../../../src/GNU/gcc-current/libobjc/encoding.c:875: for each function it appears in.)

because the i960 ROUND_TYPE_ALIGN macro uses REAL_TYPE which isn't defined.

ChangeLog:

Thu Mar 15 17:48:11 EST 2001  John Wehle  (john@feith.com)

	* encoding.c (REAL_TYPE): Define.

Enjoy!

-- John Wehle
------------------8<------------------------8<------------------------
*** libobjc/encoding.c.ORIGINAL	Thu Jan 11 17:15:39 2001
--- libobjc/encoding.c	Thu Mar 15 17:41:40 2001
*************** Boston, MA 02111-1307, USA.  */
*** 54,59 ****
--- 54,61 ----
  #define QUAL_UNION_TYPE _C_UNION_B
  #define ARRAY_TYPE      _C_ARY_B
  
+ #define REAL_TYPE       _C_DBL
+ 
  #define TYPE_FIELDS(TYPE)     objc_skip_typespec (TYPE)
  
  #define DECL_MODE(TYPE)         *(TYPE)
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------




>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:

> I think it should be clearly marked as deprecated, especially if the
> only reason it's around it to carry legacy code from a single client
> for a chip that's officially dead. (gak: i960)

I'd be surprised if that's the only legacy code that still uses it.  There
was a lot of code that relied on these pragmas several years back; I doubt
it's all been rewritten.

Hey, I'm not a big fan of these #pragmas either, but I'm bothered by the
"all extensions are evil, who cares about the users" attitude as well.

I am, however, in favor of improving the documentation so it doesn't seem
like we're suggesting that people use them in new code.

> ...especially if it's getting in the way of clear linkage
> implementations, or (my pet peeve) a pre-compiled header solution.

Except it isn't.

Jason



Benjamin Kosnik <bkoz@redhat.com> writes:

> These pragmas are removed in the current sources. There is no use of
> pragma interface/implementation in the libstdc++-v3 source tree.
...
> I think it should be clearly marked as deprecated, especially if the
> only reason it's around it to carry legacy code from a single client
> for a chip that's officially dead. (gak: i960)
> 
> ..especially if it's getting in the way of clear linkage
> implementations, or (my pet peeve) a pre-compiled header solution.
> Linkage is hairy enough as it is, why complicate otherwise rediculous
> requirements with additional complexity? 

Actually, the customer who uses b.out is the same customer that's
paying us for PCHs.  You can imagine that if we had to take out b.out
support in C++ to make PCHs work, they wouldn't think that was very
useful---and if we insisted that this is what they were getting,
they'd probably think twice before funding any such work again.

I would think that the GCC group should encourage such customers.
Without this project, the integrated preprocessor would still be
`experimental', and precompiled headers wouldn't even be in the design
phase (instead in the nearly-ready-to-contribute phase).

-- 
- Geoffrey Keating <geoffk@geoffk.org>



 > ***************
 > *** 3737,3742 ****
 > --- 3737,3743 ----
 >         else
 >         return \"fst%z0\\t%y0\";
 >       }
 > +   abort();
 >   }"
 >     [(set_attr "type" "sse,fmov")
 >      (set_attr "mode" "DF,SF")])

Our convention has been to add a default case calling abort() in the
switch statement.  Try searching for "switch (which_alternative)" in
i386.md to see what I mean.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions



Howdy,

In the conditional_trap instructions, ix86_expand_compare is
called with NULL_RTX rather than NULL, which causes the compiler
to issue warnings.  The attached patch fixes this, and
bootstrapped on i686-pc-linux-gnu.

Matt

2001-03-15  Matt Kraai  <kraai@alumni.carnegiemellon.edu>

	* i386.md (conditional_trap): Fix ix86_expand_compare args.

Index: gcc/config/i386/i386.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.md,v
retrieving revision 1.236
diff -c -3 -p -r1.236 i386.md
*** i386.md	2001/03/14 15:38:55	1.236
--- i386.md	2001/03/15 22:57:52
***************
*** 13875,13881 ****
  {
    emit_insn (gen_rtx_TRAP_IF (VOIDmode,
  			      ix86_expand_compare (GET_CODE (operands[0]),
! 						   NULL_RTX, NULL_RTX),
  			      operands[1]));
    DONE;
  }")
--- 13875,13881 ----
  {
    emit_insn (gen_rtx_TRAP_IF (VOIDmode,
  			      ix86_expand_compare (GET_CODE (operands[0]),
! 						   NULL, NULL),
  			      operands[1]));
    DONE;
  }")



Howdy,

This patch does not include prototypes for
x86_64_sign_extended_value and x86_64_zero_extended_value which
causes a number of new warnings to appear.

Matt

PGP signature



This clears up some confusion I introduced on March 2 wrt
offsets in debug information vs addresses in the program.

No one noticed the mistake so far because no platform currently
treats these differently in the assembly.  But I'm about to 
make the @secrel changes to IA-64 that HP/UX requires, and there
the difference does matter.


r~


        * dwarf2asm.c (dw2_asm_output_offset): Use ASM_OUTPUT_DWARF_OFFSET
        if provided by the target.
        (dw2_asm_output_pcrel): Likewise with ASM_OUTPUT_DWARF_PCREL.
        (dw2_asm_output_addr): New.
        * dwarf2asm.h (dw2_asm_output_addr): Declare.
        * dwarf2out.c (output_cfi): Use it for program addresses.
        (output_call_frame_info, output_die): Likewise.
        (output_aranges, output_line_info): Likewise.

Index: dwarf2asm.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2asm.c,v
retrieving revision 1.2
diff -c -p -d -r1.2 dwarf2asm.c
*** dwarf2asm.c	2001/03/06 23:29:30	1.2
--- dwarf2asm.c	2001/03/16 01:10:25
*************** unaligned_integer_asm_op (size)
*** 91,96 ****
--- 91,98 ----
  }
  #endif /* UNALIGNED_INT_ASM_OP */
  
+ /* Output an immediate constant in a given size.  */
+ 
  void
  dw2_asm_output_data VPARAMS ((int size, unsigned HOST_WIDE_INT value,
  			      const char *comment, ...))
*************** dw2_asm_output_data VPARAMS ((int size, 
*** 127,132 ****
--- 129,140 ----
    va_end (ap);
  }
  
+ /* Output the difference between two symbols in a given size.  */
+ /* ??? There appear to be assemblers that do not like such
+    subtraction, but do support ASM_SET_OP.  It's unfortunately
+    impossible to do here, since the ASM_SET_OP for the difference
+    symbol must appear after both symbols are defined.  */
+ 
  void
  dw2_asm_output_delta VPARAMS ((int size, const char *lab1, const char *lab2,
  			       const char *comment, ...))
*************** dw2_asm_output_delta VPARAMS ((int size,
*** 169,174 ****
--- 177,188 ----
    va_end (ap);
  }
  
+ /* Output a section-relative reference to a label.  In general this
+    can only be done for debugging symbols.  E.g. on most targets with
+    the GNU linker, this is accomplished with a direct reference and
+    the knowledge that the debugging section will be placed at VMA 0.
+    Some targets have special relocations for this that we must use.  */
+ 
  void
  dw2_asm_output_offset VPARAMS ((int size, const char *label,
  			       const char *comment, ...))
*************** dw2_asm_output_offset VPARAMS ((int size
*** 188,199 ****
--- 202,217 ----
    comment = va_arg (ap, const char *);
  #endif
  
+ #ifdef ASM_OUTPUT_DWARF_OFFSET
+   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, size, label);
+ #else
  #ifdef UNALIGNED_INT_ASM_OP
    fputs (unaligned_integer_asm_op (size), asm_out_file);
    assemble_name (asm_out_file, label);
  #else
    assemble_integer (gen_rtx_SYMBOL_REF (Pmode, label), size, 1);
  #endif
+ #endif
  
    if (flag_debug_asm && comment)
      {
*************** dw2_asm_output_offset VPARAMS ((int size
*** 205,210 ****
--- 223,231 ----
    va_end (ap);
  }
  
+ /* Output a self-relative reference to a label, possibly in a
+    different section or object file.  */
+ 
  void
  dw2_asm_output_pcrel VPARAMS ((int size, const char *label,
  			       const char *comment, ...))
*************** dw2_asm_output_pcrel VPARAMS ((int size,
*** 224,241 ****
    comment = va_arg (ap, const char *);
  #endif
  
  #ifdef UNALIGNED_INT_ASM_OP
    fputs (unaligned_integer_asm_op (size), asm_out_file);
- 
-   /* ??? This needs target conditionalization.  E.g. the solaris
-      assembler uses %r_disp32(label).  Others don't like "." and
-      we need to generate a temporary label here.  */
    assemble_name (asm_out_file, label);
    fputc ('-', asm_out_file);
    fputc ('.', asm_out_file);
  #else
    abort ();
  #endif
  
    if (flag_debug_asm && comment)
      {
--- 245,262 ----
    comment = va_arg (ap, const char *);
  #endif
  
+ #ifdef ASM_OUTPUT_DWARF_PCREL
+   ASM_OUTPUT_DWARF_PCREL (asm_out_file, size, label);
+ #else
  #ifdef UNALIGNED_INT_ASM_OP
    fputs (unaligned_integer_asm_op (size), asm_out_file);
    assemble_name (asm_out_file, label);
    fputc ('-', asm_out_file);
    fputc ('.', asm_out_file);
  #else
    abort ();
  #endif
+ #endif
  
    if (flag_debug_asm && comment)
      {
*************** dw2_asm_output_pcrel VPARAMS ((int size,
*** 246,251 ****
--- 267,312 ----
  
    va_end (ap);
  }
+ 
+ /* Output an absolute reference to a label.  */
+ 
+ void
+ dw2_asm_output_addr VPARAMS ((int size, const char *label,
+ 			      const char *comment, ...))
+ {
+ #ifndef ANSI_PROTOTYPES
+   int size;
+   const char *label;
+   const char *comment;
+ #endif
+   va_list ap;
+ 
+   VA_START (ap, comment);
+ 
+ #ifndef ANSI_PROTOTYPES
+   size = va_arg (ap, int);
+   label = va_arg (ap, const char *);
+   comment = va_arg (ap, const char *);
+ #endif
+ 
+ #ifdef UNALIGNED_INT_ASM_OP
+   fputs (unaligned_integer_asm_op (size), asm_out_file);
+   assemble_name (asm_out_file, label);
+ #else
+   assemble_integer (gen_rtx_SYMBOL_REF (Pmode, label), size, 1);
+ #endif
+ 
+   if (flag_debug_asm && comment)
+     {
+       fprintf (asm_out_file, "\t%s ", ASM_COMMENT_START);
+       vfprintf (asm_out_file, comment, ap);
+     }
+   fputc ('\n', asm_out_file);
+ 
+   va_end (ap);
+ }
+ 
+ /* Similar, but use an RTX expression instead of a text label.  */
  
  void
  dw2_asm_output_addr_rtx VPARAMS ((int size, rtx addr,
Index: dwarf2asm.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2asm.h,v
retrieving revision 1.1
diff -c -p -d -r1.1 dwarf2asm.h
*** dwarf2asm.h	2001/03/03 02:17:04	1.1
--- dwarf2asm.h	2001/03/16 01:10:25
*************** extern void dw2_asm_output_pcrel	PARAMS 
*** 40,45 ****
--- 40,49 ----
  						 const char *, ...))
       /* ATTRIBUTE_PRINTF_3 */;
  
+ extern void dw2_asm_output_addr		PARAMS ((int, const char *,
+ 						 const char *, ...))
+      /* ATTRIBUTE_PRINTF_3 */;
+ 
  extern void dw2_asm_output_addr_rtx	PARAMS ((int, rtx,
  						 const char *, ...))
       /* ATTRIBUTE_PRINTF_3 */;
Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.249
diff -c -p -d -r1.249 dwarf2out.c
*** dwarf2out.c	2001/03/10 16:33:56	1.249
--- dwarf2out.c	2001/03/16 01:10:25
*************** output_cfi (cfi, fde)
*** 1546,1553 ****
        switch (cfi->dw_cfi_opc)
  	{
  	case DW_CFA_set_loc:
! 	  dw2_asm_output_offset (DWARF2_ADDR_SIZE, 
! 				   cfi->dw_cfi_oprnd1.dw_cfi_addr, NULL);
  	  break;
  	case DW_CFA_advance_loc1:
  	  dw2_asm_output_delta (1, cfi->dw_cfi_oprnd1.dw_cfi_addr,
--- 1546,1553 ----
        switch (cfi->dw_cfi_opc)
  	{
  	case DW_CFA_set_loc:
! 	  dw2_asm_output_addr (DWARF2_ADDR_SIZE, 
! 			       cfi->dw_cfi_oprnd1.dw_cfi_addr, NULL);
  	  break;
  	case DW_CFA_advance_loc1:
  	  dw2_asm_output_delta (1, cfi->dw_cfi_oprnd1.dw_cfi_addr,
*************** output_call_frame_info (for_eh)
*** 1679,1686 ****
           trailing null) so the pointer is 4-byte aligned.  The Solaris ld
           can't handle unaligned relocs.  */
        dw2_asm_output_nstring ("eh", -1, "CIE Augmentation");
!       dw2_asm_output_offset (DWARF2_ADDR_SIZE, "__EXCEPTION_TABLE__",
! 			     "pointer to exception region info");
      }
    else
      {
--- 1679,1686 ----
           trailing null) so the pointer is 4-byte aligned.  The Solaris ld
           can't handle unaligned relocs.  */
        dw2_asm_output_nstring ("eh", -1, "CIE Augmentation");
!       dw2_asm_output_addr (DWARF2_ADDR_SIZE, "__EXCEPTION_TABLE__",
! 			   "pointer to exception region info");
      }
    else
      {
*************** output_call_frame_info (for_eh)
*** 1743,1750 ****
  			       stripattributes (FRAME_SECTION),
  			       "FDE CIE offset");
  
!       dw2_asm_output_offset (DWARF2_ADDR_SIZE, fde->dw_fde_begin,
! 			     "FDE initial location");
  
        dw2_asm_output_delta (DWARF2_ADDR_SIZE, fde->dw_fde_end,
  			    fde->dw_fde_begin, "FDE address range");
--- 1743,1750 ----
  			       stripattributes (FRAME_SECTION),
  			       "FDE CIE offset");
  
!       dw2_asm_output_addr (DWARF2_ADDR_SIZE, fde->dw_fde_begin,
! 			   "FDE initial location");
  
        dw2_asm_output_delta (DWARF2_ADDR_SIZE, fde->dw_fde_end,
  			    fde->dw_fde_begin, "FDE address range");
*************** output_die (die)
*** 5724,5730 ****
  	  break;
  
  	case dw_val_class_lbl_id:
! 	  dw2_asm_output_offset (DWARF2_ADDR_SIZE, AT_lbl (a), "%s", name);
  	  break;
  
  	case dw_val_class_lbl_offset:
--- 5724,5730 ----
  	  break;
  
  	case dw_val_class_lbl_id:
! 	  dw2_asm_output_addr (DWARF2_ADDR_SIZE, AT_lbl (a), "%s", name);
  	  break;
  
  	case dw_val_class_lbl_offset:
*************** output_aranges ()
*** 5938,5944 ****
  	dw2_asm_output_data (2, 0, NULL);
      }
  
!   dw2_asm_output_offset (DWARF2_ADDR_SIZE, text_section_label, "Address");
    dw2_asm_output_delta (DWARF2_ADDR_SIZE, text_end_label,
  			text_section_label, "Length");
  
--- 5938,5944 ----
  	dw2_asm_output_data (2, 0, NULL);
      }
  
!   dw2_asm_output_addr (DWARF2_ADDR_SIZE, text_section_label, "Address");
    dw2_asm_output_delta (DWARF2_ADDR_SIZE, text_end_label,
  			text_section_label, "Length");
  
*************** output_aranges ()
*** 5952,5958 ****
  
        if (die->die_tag == DW_TAG_subprogram)
  	{
! 	  dw2_asm_output_offset (DWARF2_ADDR_SIZE, get_AT_low_pc (die),
  				 "Address");
  	  dw2_asm_output_delta (DWARF2_ADDR_SIZE, get_AT_hi_pc (die),
  				get_AT_low_pc (die), "Length");
--- 5952,5958 ----
  
        if (die->die_tag == DW_TAG_subprogram)
  	{
! 	  dw2_asm_output_addr (DWARF2_ADDR_SIZE, get_AT_low_pc (die),
  				 "Address");
  	  dw2_asm_output_delta (DWARF2_ADDR_SIZE, get_AT_hi_pc (die),
  				get_AT_low_pc (die), "Length");
*************** output_line_info ()
*** 6440,6446 ****
  	  dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	  dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	  dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	  dw2_asm_output_offset (DWARF2_ADDR_SIZE, line_label, NULL);
  	}
        strcpy (prev_line_label, line_label);
  
--- 6440,6446 ----
  	  dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	  dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	  dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	  dw2_asm_output_addr (DWARF2_ADDR_SIZE, line_label, NULL);
  	}
        strcpy (prev_line_label, line_label);
  
*************** output_line_info ()
*** 6451,6457 ****
  	  current_file = line_info->dw_file_num;
  	  dw2_asm_output_data (1, DW_LNS_set_file, "DW_LNS_set_file");
  	  dw2_asm_output_data_uleb128 (current_file, "(\"%s\")",
! 				       line_file_table.table[current_file]);
  	}
  
        /* Emit debug info for the current line number, choosing the encoding
--- 6451,6457 ----
  	  current_file = line_info->dw_file_num;
  	  dw2_asm_output_data (1, DW_LNS_set_file, "DW_LNS_set_file");
  	  dw2_asm_output_data_uleb128 (current_file, "(\"%s\")",
! 				       file_table.table[current_file]);
  	}
  
        /* Emit debug info for the current line number, choosing the encoding
*************** output_line_info ()
*** 6498,6504 ****
        dw2_asm_output_data (1, 0, "DW_LNE_set_address");
        dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
        dw2_asm_output_data (1, DW_LNE_set_address, NULL);
!       dw2_asm_output_offset (DWARF2_ADDR_SIZE, text_end_label, NULL);
      }
  
    dw2_asm_output_data (1, 0, "DW_LNE_end_sequence");
--- 6498,6504 ----
        dw2_asm_output_data (1, 0, "DW_LNE_set_address");
        dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
        dw2_asm_output_data (1, DW_LNE_set_address, NULL);
!       dw2_asm_output_addr (DWARF2_ADDR_SIZE, text_end_label, NULL);
      }
  
    dw2_asm_output_data (1, 0, "DW_LNE_end_sequence");
*************** output_line_info ()
*** 6534,6540 ****
  	  dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	  dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	  dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	  dw2_asm_output_offset (DWARF2_ADDR_SIZE, line_label, NULL);
  	}
        else
  	{
--- 6534,6540 ----
  	  dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	  dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	  dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	  dw2_asm_output_addr (DWARF2_ADDR_SIZE, line_label, NULL);
  	}
        else
  	{
*************** output_line_info ()
*** 6550,6556 ****
  	      dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	      dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	      dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	      dw2_asm_output_offset (DWARF2_ADDR_SIZE, line_label, NULL);
  	    }
  	}
        strcpy (prev_line_label, line_label);
--- 6550,6556 ----
  	      dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	      dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	      dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	      dw2_asm_output_addr (DWARF2_ADDR_SIZE, line_label, NULL);
  	    }
  	}
        strcpy (prev_line_label, line_label);
*************** output_line_info ()
*** 6562,6568 ****
  	  current_file = line_info->dw_file_num;
  	  dw2_asm_output_data (1, DW_LNS_set_file, "DW_LNS_set_file");
  	  dw2_asm_output_data_uleb128 (current_file, "(\"%s\")",
! 				       line_file_table.table[current_file]);
  	}
  
        /* Emit debug info for the current line number, choosing the encoding
--- 6562,6568 ----
  	  current_file = line_info->dw_file_num;
  	  dw2_asm_output_data (1, DW_LNS_set_file, "DW_LNS_set_file");
  	  dw2_asm_output_data_uleb128 (current_file, "(\"%s\")",
! 				       file_table.table[current_file]);
  	}
  
        /* Emit debug info for the current line number, choosing the encoding
*************** output_line_info ()
*** 6611,6617 ****
  	      dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	      dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	      dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	      dw2_asm_output_offset (DWARF2_ADDR_SIZE, line_label, NULL);
  	    }
  
  	  /* Output the marker for the end of this sequence.  */
--- 6611,6617 ----
  	      dw2_asm_output_data (1, 0, "DW_LNE_set_address");
  	      dw2_asm_output_data_uleb128 (1 + DWARF2_ADDR_SIZE, NULL);
  	      dw2_asm_output_data (1, DW_LNE_set_address, NULL);
! 	      dw2_asm_output_addr (DWARF2_ADDR_SIZE, line_label, NULL);
  	    }
  
  	  /* Output the marker for the end of this sequence.  */



On Wed, 14 Mar 2001, Mark Mitchell wrote:

> Boostrapped and tested on i686-pc-linux-gnu, installed on the branch.
>
> 2001-03-14  Mark Mitchell  <mark@codesourcery.com>
>
> 	* tree.h (DECL_RTL): Allocate RTL lazily.
> 	(SET_DECL_RTL): New macro.
> 	(DECL_RTL_SET_P): Likewise.
> 	(COPY_DECL_RTL): Likewise.
> 	(DECL_RTL_IF_SET): Likewise.
> 	* varasm.c (make_decl_rtl): Add assertions about the kind of
> 	declaration we are processing.
[...]

Hi Mark,

It appears that this patch breaks bootstraps on native
armv4l-unknown-linux-gnu targets on the branch, and most likely on the
mainline, but I can't currently build the mainline so can't say for
certain.  If I check out a version of the tree shortly before this
change it passes the failure listed below.

Found from nightly build at
http://www.netwinder.org/build/branch/stats/gcc.html

The .i file is attached.

Thanks for the work you're doing,
-Rms

./xgcc -B./ -B/usr/local/armv4l-unknown-linux-gnu/bin/ -isystem
/usr/local/armv4l-unknown-linux-gnu/include -O2   -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem
./include  -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/home/build-rpm/BUILD/gcc/gcc
-I/home/build-rpm/BUILD/gcc/gcc/. -I/home/build-rpm/BUILD/gcc/gcc/config
-I/home/build-rpm/BUILD/gcc/gcc/../include  -DL_muldi3 -c
/home/build-rpm/BUILD/gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o
In file included from /home/build-rpm/BUILD/gcc/gcc/tsystem.h:80,
                 from /home/build-rpm/BUILD/gcc/gcc/libgcc2.c:37:
/usr/include/stdlib.h: In function `atof':
/usr/include/stdlib.h:306: Internal compiler error in make_decl_rtl, at
varasm.c:597
Please submit a full bug report, with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[3]: *** [libgcc/./_muldi3.o] Error 1
make[3]: Leaving directory `/home/build-rpm/BUILD/obj-gcc-20010315/gcc'

libgcc2.i.gz




I'll build a cross compiler and see if I can reproduce it.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com




I'm sorry, I was confused.  From what I can see, there was no patch
for this problem because we didn't encounter it; it was introduced
after we branched.  The GAS we shipped is based on sourceware as of
about July 1999; there was no merge from sourceware between then and
Feburary 2000, when the branch was cut.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]