* Re: Mini-patch for cccp.c
[not found] <no.id>
@ 1997-09-30 8:09 ` Thomas Koenig
1997-09-30 23:24 ` Jeffrey A Law
1997-10-06 8:25 ` Thomas Koenig
1997-11-16 18:42 ` A new bug in 971114 H.J. Lu
` (42 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: Thomas Koenig @ 1997-09-30 8:09 UTC (permalink / raw)
To: egcs
I wrote:
[...]
Playing around with checkergcc some more, I found that
expand_to_temp_buffer didn't initialize some of the members of the
FILE_BUF it returns. Dunno wether this has any grave consequences,
but I think it's a bad idea just on general principles.
Below is a patch against the origninal 970924 cccp.c which fixes this
(it also includes the previous patch).
Tue Sep 30 16:50:55 CEST 1997 Thomas Koenig (ig25@rz.uni-karlsruhe.de)
* cccp.c: (struct file_buf) change system_header_p to int
(expand_to_temp_buffer) initialize all members of obuf
static int last_error_tick; /* Incremented each time we print it. */
--- cccp.c.orig Tue Sep 30 14:43:08 1997
+++ cccp.c Tue Sep 30 16:05:35 1997
@@ -519,7 +519,7 @@
/* Object to be freed at end of input at this level. */
U_CHAR *free_ptr;
/* True if this is a header file included using <FILENAME>. */
- char system_header_p;
+ int system_header_p;
} instack[INPUT_STACK_MAX];
static int last_error_tick; /* Incremented each time we print it. */
@@ -3549,9 +3549,14 @@
obuf.length = length * 2 + 100; /* Usually enough. Why be stingy? */
obuf.bufp = obuf.buf = (U_CHAR *) xmalloc (obuf.length);
+ obuf.nominal_fname = 0;
+ obuf.inc = 0;
+ obuf.dir = 0;
obuf.fname = 0;
obuf.macro = 0;
+ obuf.if_stack = 0;
obuf.free_ptr = 0;
+ obuf.system_header_p = 0;
CHECK_DEPTH ({return obuf;});
--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Mini-patch for cccp.c
1997-09-30 8:09 ` Mini-patch for cccp.c Thomas Koenig
@ 1997-09-30 23:24 ` Jeffrey A Law
1997-10-06 8:25 ` Thomas Koenig
1 sibling, 0 replies; 175+ messages in thread
From: Jeffrey A Law @ 1997-09-30 23:24 UTC (permalink / raw)
To: Thomas König; +Cc: egcs
In message < 199709301508.QAA02218@mvmap66.ciw.uni-karlsruhe.de >you write:
> Below is a patch against the origninal 970924 cccp.c which fixes this
> (it also includes the previous patch).
>
> Tue Sep 30 16:50:55 CEST 1997 Thomas Koenig (ig25@rz.uni-karlsruhe.de)
>
> * cccp.c: (struct file_buf) change system_header_p to int
> (expand_to_temp_buffer) initialize all members of obuf
I installed the second hunk of this patch.
A couple ChangeLog notes.
The colon goes immediately after the first close paren. ie
* file (blah): Some change.
End sentences with a period.
The second line of a change should start with a single tab.
I've fixed these problems for the patches I've already installed.
Thanks!
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Mini-patch for cccp.c
1997-09-30 8:09 ` Mini-patch for cccp.c Thomas Koenig
1997-09-30 23:24 ` Jeffrey A Law
@ 1997-10-06 8:25 ` Thomas Koenig
1 sibling, 0 replies; 175+ messages in thread
From: Thomas Koenig @ 1997-10-06 8:25 UTC (permalink / raw)
To: egcs
I wrote:
[...]
Playing around with checkergcc some more, I found that
expand_to_temp_buffer didn't initialize some of the members of the
FILE_BUF it returns. Dunno wether this has any grave consequences,
but I think it's a bad idea just on general principles.
Below is a patch against the origninal 970924 cccp.c which fixes this
(it also includes the previous patch).
Tue Sep 30 16:50:55 CEST 1997 Thomas Koenig (ig25@rz.uni-karlsruhe.de)
* cccp.c: (struct file_buf) change system_header_p to int
(expand_to_temp_buffer) initialize all members of obuf
static int last_error_tick; /* Incremented each time we print it. */
--- cccp.c.orig Tue Sep 30 14:43:08 1997
+++ cccp.c Tue Sep 30 16:05:35 1997
@@ -519,7 +519,7 @@
/* Object to be freed at end of input at this level. */
U_CHAR *free_ptr;
/* True if this is a header file included using <FILENAME>. */
- char system_header_p;
+ int system_header_p;
} instack[INPUT_STACK_MAX];
static int last_error_tick; /* Incremented each time we print it. */
@@ -3549,9 +3549,14 @@
obuf.length = length * 2 + 100; /* Usually enough. Why be stingy? */
obuf.bufp = obuf.buf = (U_CHAR *) xmalloc (obuf.length);
+ obuf.nominal_fname = 0;
+ obuf.inc = 0;
+ obuf.dir = 0;
obuf.fname = 0;
obuf.macro = 0;
+ obuf.if_stack = 0;
obuf.free_ptr = 0;
+ obuf.system_header_p = 0;
CHECK_DEPTH ({return obuf;});
--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: A new bug in 971114
[not found] <no.id>
1997-09-30 8:09 ` Mini-patch for cccp.c Thomas Koenig
@ 1997-11-16 18:42 ` H.J. Lu
1998-04-20 11:44 ` egcs 1.0.3 on linux/alpha H.J. Lu
` (41 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: H.J. Lu @ 1997-11-16 18:42 UTC (permalink / raw)
To: hjl; +Cc: egcs
>
> On linux/x86, with egcs-971114, I got
>
> /home/work/gnu/bin/egcs/gcc/xgcc -B/home/work/gnu/bin/egcs/gcc/ -c -fthis-is-variable -c foo.cc
> foo.cc: In function `class Int * Proc0()':
> foo.cc:9: Internal compiler error.
> foo.cc:9: Please submit a full bug report to `egcs-bugs@cygnus.com'.
>
> egcs-971105 is fine.
>
>
> --
> H.J. Lu (hjl@gnu.ai.mit.edu)
> --
> class Int
> {
> public:
> Int ();
> };
>
> Int *Proc0()
> {
> return new Int;
> }
>
This kludge doesn't even look right to me. But at least, gcc doesn't
dump core now. Could someone please check it out and find a right
fix?
Thanks.
--
H.J. Lu (hjl@gnu.ai.mit.edu)
--
Sun Nov 16 18:34:08 1997 H.J. Lu (hjl@gnu.ai.mit.edu)
* init.c (build_new): Handle freeing allocated memory when the
constructor throws only if alloc_expr is not NULL.
Index: init.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/cp/init.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 init.c
--- init.c 1997/11/14 22:32:47 1.1.1.5
+++ init.c 1997/11/17 02:33:36
@@ -2720,7 +2720,7 @@
new-placement, then the deallocation function is called to free
the memory in which the object was being constructed. */
/* FIXME: handle placement delete. */
- if (flag_exceptions && ! placement)
+ if (flag_exceptions && ! placement && alloc_expr)
{
tree cleanup = alloc_expr;
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: egcs 1.0.3 on linux/alpha
[not found] <no.id>
1997-09-30 8:09 ` Mini-patch for cccp.c Thomas Koenig
1997-11-16 18:42 ` A new bug in 971114 H.J. Lu
@ 1998-04-20 11:44 ` H.J. Lu
1998-07-17 16:48 ` -Wall stops compiling of egcs-1.0.3 Joe Buck
` (40 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: H.J. Lu @ 1998-04-20 11:44 UTC (permalink / raw)
To: hjl; +Cc: law, gafton, rth, egcs
>
> I am glad to see the alpha bugs be fixed. However, with the current
> egcs 1.0.3 in CVS, there are 4 new failures:
>
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation, -O0
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation, -O1
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation, -O2
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation, -O2 -fomit-frame-pointer -finline-functions
>
> Can someone verify that?
>
OOoops. My fault. Please ignore it.
--
H.J. Lu (hjl@gnu.org)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: -Wall stops compiling of egcs-1.0.3
[not found] <no.id>
` (2 preceding siblings ...)
1998-04-20 11:44 ` egcs 1.0.3 on linux/alpha H.J. Lu
@ 1998-07-17 16:48 ` Joe Buck
1998-10-30 19:14 ` A bad EH bug H.J. Lu
` (39 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: Joe Buck @ 1998-07-17 16:48 UTC (permalink / raw)
To: Wilfried Noell; +Cc: egcs
> I tried to compile the complete set egcs-1.0.3 (the 9.5 MB tar.gz file)
> on our Sun (SunOS 5.5). The C-compiler version is
>
> /dr_users/noell % cc -V
> cc: SC3.0.1 13 Jul 1994
>
> The problems was, that the make process hit an error when the option -W
> or -Wall came up.
> What can I do about it? Is there any workaround? I tried to omit this
> option, but it wouldn't work either.
No one else has seen this problem, and lots of people have successfully
built egcs on Suns. Can you give the exact error messages you received?
^ permalink raw reply [flat|nested] 175+ messages in thread
* A bad EH bug
[not found] <no.id>
` (3 preceding siblings ...)
1998-07-17 16:48 ` -Wall stops compiling of egcs-1.0.3 Joe Buck
@ 1998-10-30 19:14 ` H.J. Lu
[not found] ` <19981218003619.B28066@cerebro.laendle>
` (38 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: H.J. Lu @ 1998-10-30 19:14 UTC (permalink / raw)
To: hjl; +Cc: oliva, matthew, jbuck, egcs, support
> >
> > > On Tue, Oct 13, 1998 at 02:48:36PM -0700, Joe Buck wrote:
> >
> > >> Please send a complete test case (a complete program) to
> > >> egcs-bugs@cygnus.com, so that the experts will be able to run it through
> > >> and figure out what goes wrong.
> >
> > > This demonstrates the problem quite effectively. However, I'm afraid
> > > it's rather big. I had a (quick) crack at isolating the problem with
> > > little success.
> >
# gcc bad.cc -g
# a.out
Foo::Foo
Foo::~Foo
zsh: 12158 segmentation fault ./a.out
# gdb a.out
(gdb) r
(gdb) r
Starting program: /home/hjl/bugs/g++/opt.3/a.out
Foo::Foo
Foo::~Foo
Program received signal SIGSEGV, Segmentation fault.
0x804a2b1 in __cp_pop_exception (p=0x4002fbaa)
at /home/work/misc/gnu/src/egcs-1.1/gcc/cp/exception.cc:211
211 --p->handlers;
(gdb) bt
#0 0x804a2b1 in __cp_pop_exception (p=0x4002fbaa)
at /home/work/misc/gnu/src/egcs-1.1/gcc/cp/exception.cc:211
#1 0x804947e in Base::dispatch (this=0xbffffc17, x=0) at bad.cc:80
#2 0x80494e9 in main () at bad.cc:101
BTW, it failed on Solaris/Sparc. But it works on HP-UX 10.20. It seems
it affects all platforms with DWARF2 based EH. FYI, egcs 1.0.3 is ok.
It must be a new bug. I'd like to see it be fixed in egcs 1.1.1.
Could someone please clean it up and put it into the g++ testsuite?
Thanks.
--
H.J. Lu (hjl@gnu.org)
---
#include <stdio.h>
class Base
{
public:
int dispatch (int);
};
class Derived : public Base
{
};
class Foo
{
public:
Foo ();
~Foo ();
int getValue (int);
};
template<class T>
class OBObjVar
{
T* ptr;
public:
OBObjVar (T *p) : ptr (p) {}
~OBObjVar() { delete ptr; }
T* operator->() const { return ptr; }
};
Foo * getFoo ();
Foo::Foo ()
{
printf ("Foo::Foo\n");
}
Foo::~Foo ()
{
printf ("Foo::~Foo\n");
}
int
Foo::getValue (int x)
{
return x;
}
Foo*
getFoo ()
{
return new Foo;
}
int
Base::dispatch (int x)
{
int y = 1;
while (y)
{
OBObjVar<Foo> f = getFoo ();
try
{
y = f->getValue (x);
}
catch (const char *s)
{
printf ("Base::dispatch: %s\n", s);
if (x == 0)
{
y = 0;
continue;
}
throw;
}
catch (int)
{
continue;
}
if (y == 0)
{
f->getValue (y);
throw "Throw an exception!";
}
break;
}
return y;
}
int
main ()
{
Derived x;
try
{
x.dispatch (0);
}
catch (const char *s)
{
printf ("Caught: %s\n", s);
}
}
^ permalink raw reply [flat|nested] 175+ messages in thread
[parent not found: <19981218003619.B28066@cerebro.laendle>]
* Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!
[not found] <no.id>
` (5 preceding siblings ...)
[not found] ` <19981218003619.B28066@cerebro.laendle>
@ 2000-12-19 21:48 ` John David Anglin
2000-12-21 14:32 ` John David Anglin
2001-01-01 16:37 ` pa reload problem John David Anglin
` (36 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2000-12-19 21:48 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, msokolov
> +(define_insn "call_value"
> [(set (match_operand 0 "" "=g")
> (call (match_operand:QI 1 "memory_operand" "m")
> - (match_operand:SI 2 "const_int_operand" "n")))
> - (set (reg:SI 14) (reg:SI 14))]
> + (match_operand:SI 2 "const_int_operand" "n")))]
> + ;; Operand 2 not used on the vax.
> ""
> - "*
> - if (INTVAL (operands[2]) > 255 * 4)
> - /* Vax `calls' really uses only one byte of #args, so pop explicitly. */
> - return \"calls $0,%1\;addl2 %2,sp\";
> - operands[2] = GEN_INT ((INTVAL (operands[2]) + 3)/ 4);
> - return \"calls %2,%1\";
> -")
> + "calls $0,%0")
There is a typo in the above. I knew I shouldn't have sent this until
it was tested.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!
2000-12-19 21:48 ` FWIW: VAX fix backport and gcc built on 4.3BSD first time ever! John David Anglin
@ 2000-12-21 14:32 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2000-12-21 14:32 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, msokolov
Here is a revised patch for the mainline vax.md. The bootstrap with
this patch looks like it is going ok, although it is far from complete.
I will submit the patch formally when I am certain that it is ok.
It is possible that using this new patched version with the 2.95 branch
would work. It now has the call and call_value patterns which might enable
it to work without the call_pop/call_value_pop patch. It also has at
least one other fix for a reload problem. It it does work, this might
be a more acceptable change to incorporate into the 2.95 branch since
it only affects the vax.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2000-12-21 John David Anglin <dave@hiauly1.hia.nrc.ca>
* vax.md (call_pop, call_value_pop): Change to define_expand.
(call_pop_internal, call, call_value): Define.
(casesi1 + 1): Make operands contiguous.
--- vax.md.orig Tue Sep 12 10:58:47 2000
+++ vax.md Wed Dec 20 13:33:13 2000
@@ -1818,70 +1818,74 @@
""
"decl %0\;jgequ %l1")
\f
-;; Note that operand 1 is total size of args, in bytes,
-;; and what the call insn wants is the number of words.
-;; It is used in the call instruction as a byte, but in the addl2 as
-;; a word. Since the only time we actually use it in the call instruction
-;; is when it is a constant, SImode (for addl2) is the proper mode.
-(define_insn "call_pop"
+;; Call instructions.
+
+;; Call procedure returning no value.
+;; Operand 2 is not used on the vax.
+
+(define_expand "call_pop"
[(call (match_operand:QI 0 "memory_operand" "m")
(match_operand:SI 1 "const_int_operand" "n"))
(set (reg:SI 14) (plus:SI (reg:SI 14)
(match_operand:SI 3 "immediate_operand" "i")))]
""
- "*
- if (INTVAL (operands[1]) > 255 * 4)
- /* Vax `calls' really uses only one byte of #args, so pop explicitly. */
- return \"calls $0,%0\;addl2 %1,sp\";
- operands[1] = GEN_INT ((INTVAL (operands[1]) + 3)/ 4);
- return \"calls %1,%0\";
-")
+ "
+{
+ emit_insn (gen_call_pop_internal (operands[0], operands[1]));
+ DONE;
+}")
+
+;; Call procedure returning a value in operand 0.
+;; Operand 3 is not used on the vax.
-(define_insn "call_value_pop"
+(define_expand "call_value_pop"
[(set (match_operand 0 "" "=g")
(call (match_operand:QI 1 "memory_operand" "m")
(match_operand:SI 2 "const_int_operand" "n")))
(set (reg:SI 14) (plus:SI (reg:SI 14)
(match_operand:SI 4 "immediate_operand" "i")))]
""
- "*
- if (INTVAL (operands[2]) > 255 * 4)
- /* Vax `calls' really uses only one byte of #args, so pop explicitly. */
- return \"calls $0,%1\;addl2 %2,sp\";
- operands[2] = GEN_INT ((INTVAL (operands[2]) + 3)/ 4);
- return \"calls %2,%1\";
-")
+ "
+{
+ emit_insn (gen_call_pop_internal (operands[1], operands[2]));
+ DONE;
+}")
-;; Define another set of these for the case of functions with no
-;; operands. In that case, combine may simplify the adjustment of sp.
-(define_insn ""
+;; Call procedure with no arguments.
+
+(define_insn "call"
[(call (match_operand:QI 0 "memory_operand" "m")
- (match_operand:SI 1 "const_int_operand" "n"))
- (set (reg:SI 14) (reg:SI 14))]
+ (const_int 0))]
""
- "*
- if (INTVAL (operands[1]) > 255 * 4)
- /* Vax `calls' really uses only one byte of #args, so pop explicitly. */
- return \"calls $0,%0\;addl2 %1,sp\";
- operands[1] = GEN_INT ((INTVAL (operands[1]) + 3)/ 4);
- return \"calls %1,%0\";
-")
+ "calls $0,%0")
-(define_insn ""
+;; Call procedure returning a value in operand 0 with no arguments.
+
+(define_insn "call_value"
[(set (match_operand 0 "" "=g")
(call (match_operand:QI 1 "memory_operand" "m")
- (match_operand:SI 2 "const_int_operand" "n")))
- (set (reg:SI 14) (reg:SI 14))]
+ (const_int 0)))]
+ ""
+ "calls $0,%1")
+
+;; Note that operand 1 is total size of args, in bytes,
+;; and what the call insn wants is the number of words.
+;; It is used in the call instruction as a byte, but in the addl2 as
+;; a word. Since the only time we actually use it in the call instruction
+;; is when it is a constant, SImode (for addl2) is the proper mode.
+(define_insn "call_pop_internal"
+ [(call (match_operand:QI 0 "memory_operand" "m")
+ (match_operand:SI 1 "const_int_operand" "n"))]
""
"*
- if (INTVAL (operands[2]) > 255 * 4)
+ if (INTVAL (operands[1]) > 255 * 4)
/* Vax `calls' really uses only one byte of #args, so pop explicitly. */
- return \"calls $0,%1\;addl2 %2,sp\";
- operands[2] = GEN_INT ((INTVAL (operands[2]) + 3)/ 4);
- return \"calls %2,%1\";
+ return \"calls $0,%0\;addl2 %1,sp\";
+ operands[1] = GEN_INT ((INTVAL (operands[1]) + 3)/ 4);
+ return \"calls %1,%0\";
")
-;; Call subroutine returning any type.
+;; Call procedure returning any type.
(define_expand "untyped_call"
[(parallel [(call (match_operand 0 "" "")
@@ -1986,7 +1990,7 @@
(mult:SI (minus:SI (match_dup 0)
(const_int 0))
(const_int 2)))))
- (label_ref:SI (match_operand 3 "" "")))
+ (label_ref:SI (match_operand 2 "" "")))
(pc)))]
""
"casel %0,$0,%1")
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
[not found] <no.id>
` (6 preceding siblings ...)
2000-12-19 21:48 ` FWIW: VAX fix backport and gcc built on 4.3BSD first time ever! John David Anglin
@ 2001-01-01 16:37 ` John David Anglin
2001-01-03 20:57 ` Jeffrey A Law
2001-01-12 19:40 ` RFC: Jump to const_int John David Anglin
` (35 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-01-01 16:37 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-bugs
> (insn 1067 1063 2002 (set (reg/f:SI 403)
> (mem/u:SI (lo_sum:SI (reg/f:SI 611)
> (unspec:SI[
> (symbol_ref:SI ("target_flags"))
> ] 0)) 0)) 69 {*pa.md:2099} (nil)
> (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
> (unspec:SI[
> (symbol_ref:SI ("target_flags"))
> ] 0)) 0)
> (expr_list:REG_DEAD (reg/f:SI 611)
> (nil))))
The REG_EQUIV note gets added in local-alloc.c here:
/* If this register is known to be equal to a constant, record that
it is always equivalent to the constant. */
if (note && ! rtx_varies_p (XEXP (note, 0)))
PUT_MODE (note, (enum machine_mode) REG_EQUIV);
The problem appears to be that the "constant" part of the lo_sum (the
symbol_ref) should be the first operand:
case LO_SUM:
/* The operand 0 of a LO_SUM is considered constant
(in fact is it related specifically to operand 1). */
return rtx_varies_p (XEXP (x, 1));
This problem appears to prevalent in a number of places in pa.md and pa.c.
It looks like the argument order for lo_sums in hte pa port needs to be
switched.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-01 16:37 ` pa reload problem John David Anglin
@ 2001-01-03 20:57 ` Jeffrey A Law
2001-01-03 22:08 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Jeffrey A Law @ 2001-01-03 20:57 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-bugs
In message < 200101020037.TAA26820@hiauly1.hia.nrc.ca >you write:
> > (insn 1067 1063 2002 (set (reg/f:SI 403)
> > (mem/u:SI (lo_sum:SI (reg/f:SI 611)
> > (unspec:SI[
> > (symbol_ref:SI ("target_flags"))
> > ] 0)) 0)) 69 {*pa.md:2099} (nil)
> > (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
> > (unspec:SI[
> > (symbol_ref:SI ("target_flags"))
> > ] 0)) 0)
> > (expr_list:REG_DEAD (reg/f:SI 611)
> > (nil))))
>
> The REG_EQUIV note gets added in local-alloc.c here:
>
> /* If this register is known to be equal to a constant, record that
> it is always equivalent to the constant. */
> if (note && ! rtx_varies_p (XEXP (note, 0)))
> PUT_MODE (note, (enum machine_mode) REG_EQUIV);
>
> The problem appears to be that the "constant" part of the lo_sum (the
> symbol_ref) should be the first operand:
>
> case LO_SUM:
> /* The operand 0 of a LO_SUM is considered constant
> (in fact is it related specifically to operand 1). */
> return rtx_varies_p (XEXP (x, 1));
>
> This problem appears to prevalent in a number of places in pa.md and pa.c.
> It looks like the argument order for lo_sums in hte pa port needs to be
> switched.
Huh? It follows the same convention as every other port that uses
HI and LO_SUM.
op0 is a register, but it is known to be a constant (the high part of
the expression found in op1).
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-03 20:57 ` Jeffrey A Law
@ 2001-01-03 22:08 ` John David Anglin
2001-01-04 9:55 ` Jeffrey A Law
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-01-03 22:08 UTC (permalink / raw)
To: law; +Cc: gcc, gcc-bugs
> In message < 200101020037.TAA26820@hiauly1.hia.nrc.ca >you write:
> > > (insn 1067 1063 2002 (set (reg/f:SI 403)
> > > (mem/u:SI (lo_sum:SI (reg/f:SI 611)
> > > (unspec:SI[
> > > (symbol_ref:SI ("target_flags"))
> > > ] 0)) 0)) 69 {*pa.md:2099} (nil)
> > > (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
> > > (unspec:SI[
> > > (symbol_ref:SI ("target_flags"))
> > > ] 0)) 0)
> > > (expr_list:REG_DEAD (reg/f:SI 611)
> > > (nil))))
> >
> > The REG_EQUIV note gets added in local-alloc.c here:
> >
> > /* If this register is known to be equal to a constant, record that
> > it is always equivalent to the constant. */
> > if (note && ! rtx_varies_p (XEXP (note, 0)))
> > PUT_MODE (note, (enum machine_mode) REG_EQUIV);
> >
> > The problem appears to be that the "constant" part of the lo_sum (the
> > symbol_ref) should be the first operand:
> >
> > case LO_SUM:
> > /* The operand 0 of a LO_SUM is considered constant
> > (in fact is it related specifically to operand 1). */
> > return rtx_varies_p (XEXP (x, 1));
> >
> > This problem appears to prevalent in a number of places in pa.md and pa.c.
> > It looks like the argument order for lo_sums in hte pa port needs to be
> > switched.
> Huh? It follows the same convention as every other port that uses
> HI and LO_SUM.
>
> op0 is a register, but it is known to be a constant (the high part of
> the expression found in op1).
The problem is that it is "constant" but not invariant. I was wrong
about the reversal, being confused by the fact that on the pa op1
is either a constant or symbol reference. Thus, it didn't make much
sense to test op1 of a lo_sum in rtx_varies_p. I had looked at the
documention but this convention is only documented in the code.
In this particular situation, the op0 register dies and the hard register
that reload asigns to it is reused. However, reload doesn't check for this
and still goes ahead and substitutes the mem to eliminate the "equivalent"
pseudo. My impression is that it would be easier to not create the REG_EQUIV
notes in local-alloc after the op0 register dies than fix the problem in
reload. It appears that reload may substitute a mem for a psuedo whenever it
finds such a note without much testing.
If the REG_EQUIV notes aren't created, it is possible that it may not be
necessary to merge the special pic load insns into the insn which handles
move_operands because the op0 register will always die in the lo_sum insn
and the mem will not be substituted by reload.
I was working on a patch to local-alloc but after updating to the current
cvs today, I find the pa port doesn't build even without -fPIC:
./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa1.1-hp-hpux10.20/include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/libgcc2.c -o libgcc/./_fixunstfdi.o
../../gcc/libgcc2.c: In function `__fixunstfdi':
../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resources, at resource.c:229
This occurs in stage 2 when built with -O3. For some reason, virtual-stack-vars
doesn't get a hard register during reload. This is a new problem introduced
in the last few days.
I have a couple of pic related patches, but the reload issue and the above
problem need to be resolved before they can be fully tested. I did have
a complete pic build of gcc when I patched rtx_varies_p to check op0
and op1 of the lo_sum (ie, to ensure that its argument is invariant and
not just constant). However, I decided this is wrong and that some
additional modifications need to be made to local-alloc to test for
this situation. I think there needs to be a scan from the init_insn.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-03 22:08 ` John David Anglin
@ 2001-01-04 9:55 ` Jeffrey A Law
2001-01-04 11:12 ` John David Anglin
2001-01-04 11:35 ` John David Anglin
0 siblings, 2 replies; 175+ messages in thread
From: Jeffrey A Law @ 2001-01-04 9:55 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-bugs
In message < 200101040608.BAA05571@hiauly1.hia.nrc.ca >you write:
> In this particular situation, the op0 register dies and the hard register
> that reload asigns to it is reused. However, reload doesn't check for this
> and still goes ahead and substitutes the mem to eliminate the "equivalent"
> pseudo.
And that is the bug. Blind replacement by reload is a constant source of
problems.
Now as I've mentioned before I've got changes to fix these kinds of problems.
But I haven't had time to finish testing them.
> My impression is that it would be easier to not create the REG_EQUIV
> notes in local-alloc after the op0 register dies than fix the problem in
> reload. It appears that reload may substitute a mem for a psuedo whenever
> it finds such a note without much testing.
That sound like you're barking up the wrong tree. The REG_EQUIV note is
perfectly valid. It's reload's fault for blindly substituting it in for
a pseudo that doesn't get a hard register.
> ./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa
> 1.1-hp-hpux10.20/include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstric
> t-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g1 -DIN_LIBGC
> C2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/
> config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/li
> bgcc2.c -o libgcc/./_fixunstfdi.o
> ../../gcc/libgcc2.c: In function `__fixunstfdi':
> ../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resourc
> es, at resource.c:229
>
> This occurs in stage 2 when built with -O3. For some reason, virtual-stack
> -vars
> doesn't get a hard register during reload. This is a new problem introduce
> d
> in the last few days.
Yes. It's due to some additional checking Alex put into reorg recently.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-04 9:55 ` Jeffrey A Law
@ 2001-01-04 11:12 ` John David Anglin
2001-01-04 11:35 ` John David Anglin
1 sibling, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-01-04 11:12 UTC (permalink / raw)
To: law; +Cc: gcc, gcc-bugs
> Now as I've mentioned before I've got changes to fix these kinds of problems.
> But I haven't had time to finish testing them.
If you send them, I will try to help with testing. Do these also deal
with the problem that reload may substitute a mem valid in one insn into
another in which it is not valid?
> > My impression is that it would be easier to not create the REG_EQUIV
> > notes in local-alloc after the op0 register dies than fix the problem in
> > reload. It appears that reload may substitute a mem for a psuedo whenever
> > it finds such a note without much testing.
> That sound like you're barking up the wrong tree. The REG_EQUIV note is
> perfectly valid. It's reload's fault for blindly substituting it in for
> a pseudo that doesn't get a hard register.
The initial one is perfectly valid but probably unnecessary because the
reg used in it dies in the same insn. It's the latter two which I really
question and cause the problem in reload. They might not be created if
we lose the initial equivalence or if some checking were added at the
point previously noted in local-alloc.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-04 9:55 ` Jeffrey A Law
2001-01-04 11:12 ` John David Anglin
@ 2001-01-04 11:35 ` John David Anglin
2001-01-04 11:48 ` Alexandre Oliva
1 sibling, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-01-04 11:35 UTC (permalink / raw)
To: law; +Cc: gcc, gcc-bugs, aoliva
> > ./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa
> > 1.1-hp-hpux10.20/include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstric
> > t-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g1 -DIN_LIBGC
> > C2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/
> > config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/li
> > bgcc2.c -o libgcc/./_fixunstfdi.o
> > ../../gcc/libgcc2.c: In function `__fixunstfdi':
> > ../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resourc
> > es, at resource.c:229
> >
> > This occurs in stage 2 when built with -O3. For some reason, virtual-stack
> > -vars
> > doesn't get a hard register during reload. This is a new problem introduce
> > d
> > in the last few days.
> Yes. It's due to some additional checking Alex put into reorg recently.
Is Alex working on resolving this?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-04 11:35 ` John David Anglin
@ 2001-01-04 11:48 ` Alexandre Oliva
2001-01-04 13:06 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Alexandre Oliva @ 2001-01-04 11:48 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc, gcc-bugs
On Jan 4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
>> > This occurs in stage 2 when built with -O3. For some reason, virtual-stack
>> > -vars
>> > doesn't get a hard register during reload. This is a new problem introduce
>> > d
>> > in the last few days.
>> Yes. It's due to some additional checking Alex put into reorg recently.
> Is Alex working on resolving this?
Not actively. It's on my to-do list, but I don't know when I'll be
able to get to it.
Please note that the check I've introduced just detects what has been
in error for a long time. It's not responsible for the failure, that
I'm yet to track down.
--
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-04 11:48 ` Alexandre Oliva
@ 2001-01-04 13:06 ` John David Anglin
2001-01-04 13:18 ` Alexandre Oliva
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-01-04 13:06 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: law, gcc, gcc-bugs
> On Jan 4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
>
> >> > This occurs in stage 2 when built with -O3. For some reason, virtual-stack
> >> > -vars
> >> > doesn't get a hard register during reload. This is a new problem introduce
As far as I can see, virtual-stack-vars is only left in expr_lists of
of call_insns. Here is a sample from the greg rtl:
(call_insn/u 51 45 53 (parallel[
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref:SI ("@_U_Qflt")) 0)
(const_int 16 [0x10])))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
] ) 272 {call_value_internal_symref} (insn_list 31 (insn_list 33 (insn_list 35 (insn_list 37 (insn_list 39 (insn_list 41 (insn_list 43 (insn_list 45 (insn_list:REG_DEP_ANTI 6 (insn_list:REG_DEP_ANTI 8 (insn_list:REG_DEP_ANTI 10 (insn_list:REG_DEP_ANTI 12 (insn_list 48 (insn_list 50 (nil)))))))))))))))
(expr_list:REG_EH_REGION (const_int -1 [0xffffffff])
(nil))
(expr_list (use (reg:SI 4 %r4))
(expr_list (use (reg:SI 19 %r19))
(expr_list (use (reg:SI 25 %r25))
(expr_list (use (reg:SI 26 %r26))
(expr_list (use (mem/f:TF (plus:SI (reg/f:SI 90 virtual-stack-vars)
(const_int 16 [0x10])) 28))
(expr_list (use (mem/f:TF (reg/f:SI 90 virtual-stack-vars) 28))
(nil))))))))
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-04 13:06 ` John David Anglin
@ 2001-01-04 13:18 ` Alexandre Oliva
2001-01-04 14:12 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Alexandre Oliva @ 2001-01-04 13:18 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc, gcc-bugs
On Jan 4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> As far as I can see, virtual-stack-vars is only left in expr_lists of
> of call_insns.
Yep. This matches my experience too. It turns out that I posted a
patch on Dec 30 that would cause them to be properly instantiated, but
it wasn't reviewed yet. And, if I install another patch that I had
posted about 10 minutes later, that was approved but that I put on
hold, you'd probably start getting other pseudos listed in call_insn
expr_lists, that would give you similar problems because they wouldn't
be handled by reload.
Oh, joy! :-(
--
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: pa reload problem
2001-01-04 13:18 ` Alexandre Oliva
@ 2001-01-04 14:12 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-01-04 14:12 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: law, gcc, gcc-bugs
> On Jan 4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
>
> > As far as I can see, virtual-stack-vars is only left in expr_lists of
> > of call_insns.
>
> Yep. This matches my experience too. It turns out that I posted a
> patch on Dec 30 that would cause them to be properly instantiated, but
> it wasn't reviewed yet. And, if I install another patch that I had
> posted about 10 minutes later, that was approved but that I put on
> hold, you'd probably start getting other pseudos listed in call_insn
> expr_lists, that would give you similar problems because they wouldn't
> be handled by reload.
Should this be backed out until a solution is found? It prevents the
building the compiler under hpux.
2000-12-29 Alexandre Oliva <aoliva@redhat.com>
* calls.c (emit_library_call_value_1): Add to call_fusage the
stack slot assigned to argument passed by reference.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: RFC: Jump to const_int
[not found] <no.id>
` (7 preceding siblings ...)
2001-01-01 16:37 ` pa reload problem John David Anglin
@ 2001-01-12 19:40 ` John David Anglin
2001-01-12 21:10 ` Fergus Henderson
2001-04-17 19:11 ` GCC 3.0 Status Report John David Anglin
` (34 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-01-12 19:40 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-bugs
> I found the following testcase fails (991213-3.c) with the above abort:
>
> int jump () { goto * (int (*) ()) 0xbabebec0; }
One further thought. The test looks bogus to me because the address
clearly can't be in the current function. Thus, the behavior of such
a jump is totally unpredictable.
Gcc allows as an extension goto's to any void * expression. Thus, the
above is accepted but it will clearly cause problems when edges are
to be calculated.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: RFC: Jump to const_int
2001-01-12 19:40 ` RFC: Jump to const_int John David Anglin
@ 2001-01-12 21:10 ` Fergus Henderson
0 siblings, 0 replies; 175+ messages in thread
From: Fergus Henderson @ 2001-01-12 21:10 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-bugs
On 12-Jan-2001, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > I found the following testcase fails (991213-3.c) with the above abort:
> >
> > int jump () { goto * (int (*) ()) 0xbabebec0; }
>
> One further thought. The test looks bogus to me because the address
> clearly can't be in the current function. Thus, the behavior of such
> a jump is totally unpredictable.
>
> Gcc allows as an extension goto's to any void * expression. Thus, the
> above is accepted but it will clearly cause problems when edges are
> to be calculated.
The *runtime* behaviour of such a jump is unpredictable.
It should be a runtime error, and a compile-time warning might be nice,
but it should not be a compile-time error and nor should the compiler
get an internal compiler error.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.0 Status Report
[not found] <no.id>
` (8 preceding siblings ...)
2001-01-12 19:40 ` RFC: Jump to const_int John David Anglin
@ 2001-04-17 19:11 ` John David Anglin
2001-04-18 0:55 ` Mark Mitchell
2001-04-21 19:33 ` C++ Issue on GCC 3.0 branch John David Anglin
` (33 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-17 19:11 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, gcc
Mark,
I would like to draw your attention to these two g++ patches
which I would like considered for both branch and main:
< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html >
< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html >
The first one potentially affects all targets. The second
only affects targets that define PCC_STATIC_STRUCT_RETURN.
However, it is crucial to g++ being usable.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.0 Status Report
2001-04-17 19:11 ` GCC 3.0 Status Report John David Anglin
@ 2001-04-18 0:55 ` Mark Mitchell
2001-04-18 9:00 ` John David Anglin
2001-04-18 13:51 ` John David Anglin
0 siblings, 2 replies; 175+ messages in thread
From: Mark Mitchell @ 2001-04-18 0:55 UTC (permalink / raw)
To: dave; +Cc: gcc
>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
First, note that Vax Ultrix is not a primary platform the release, so
these patches are not a high priority for me.
John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html
I would prefer a patch that simply did something like:
minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
TREE_INT_CST_HIGH (minnode));
if (unsignedp)
TREE_TYPE (minnode) = unsigned_type_node;
I think the hack where you adjust things according to the signedness
at the end is confusing.
John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html
Certainly the bit about setting old_ac is correct. I'll install that
part of the change.
I think that probably the other part is correct, but can you explain
it in more detail? Not what the problem is (I get that), but why your
fix is the correct approach?
I'm not sure that it's possible to get correct C++ semantics with the
PCC calling convention; you might end up with too many copy
constructors, for example.
ChangeLogs shouldn't have justifications in them. They should go in
the code instead.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.0 Status Report
2001-04-18 0:55 ` Mark Mitchell
@ 2001-04-18 9:00 ` John David Anglin
2001-04-18 13:51 ` John David Anglin
1 sibling, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-04-18 9:00 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
> I think that probably the other part is correct, but can you explain
> it in more detail? Not what the problem is (I get that), but why your
> fix is the correct approach?
I am not entirely certain the approach is correct as my knowledge of
C++ and g++ is limited. Can you see another way to copy the result
without using build_aggr_init?
My approach was based on debugging the existing code. The call_expr
is converted by ocp_convert to a tree expression containing another
aggr_init_expr in expand_default_init. Here is the code there:
if (flags & DIRECT_BIND)
/* Do nothing. We hit this in two cases: Reference initialization,
where we aren't initializing a real variable, so we don't want
to run a new constructor; and catching an exception, where we
have already built up the constructor call so we could wrap it
in an exception region. */;
else if (TREE_CODE (init) == CONSTRUCTOR)
/* A brace-enclosed initializer has whatever type is
required. There's no need to convert it. */
;
else
init = ocp_convert (type, init, CONV_IMPLICIT|CONV_FORCE_TEMP, flags);
It looked to me like the call was already built, so adding DIRECT_BIND
to the flags was the right thing to do to prevent the conversion. However,
maybe the code here should be checking for a CALL_EXPR. There is this
comment for build_aggr_init:
If INIT resolves to a CALL_EXPR which happens to return
something of the type we are looking for, then we know
that we can safely use that call to perform the
initialization.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.0 Status Report
2001-04-18 0:55 ` Mark Mitchell
2001-04-18 9:00 ` John David Anglin
@ 2001-04-18 13:51 ` John David Anglin
2001-04-20 13:36 ` Mark Mitchell
1 sibling, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-18 13:51 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
> >>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
>
> First, note that Vax Ultrix is not a primary platform the release, so
> these patches are not a high priority for me.
>
> John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html
I understand your priorities but as I noted this problem affects all
ports. Hey, next time I will provide an analysis on the i386! What
I am saying is that you have to be careful in ignoring problems on
low priority targets because they may well affect the high priority
ones as well.
> I would prefer a patch that simply did something like:
>
> minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
> TREE_INT_CST_HIGH (minnode));
> if (unsignedp)
> TREE_TYPE (minnode) = unsigned_type_node;
>
> I think the hack where you adjust things according to the signedness
> at the end is confusing.
The sign adjustment at the end is a bit of a hack but it was a compromise
which allows just one pass through the values as before, and an overall
simplification of the code.
I don't believe your suggestion works directly because minnode has
has the signedness of enumtype after the loop. The testing for signed
values could be put into the loop as in my patch.
I liked the idea of using the actual type and precision specified in
the original values for the minimum precision estimation, rather than
copying the min and max nodes after the loop and resetting their type
and precision. Doing the precision calculation in the loop is probably
less complicated than the comparisons needed to determine the min and
max values in the list.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
[not found] <no.id>
` (9 preceding siblings ...)
2001-04-17 19:11 ` GCC 3.0 Status Report John David Anglin
@ 2001-04-21 19:33 ` John David Anglin
2001-04-23 2:18 ` Bernd Schmidt
2001-04-25 10:26 ` Mark Mitchell
2001-04-23 15:21 ` John David Anglin
` (32 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2001-04-21 19:33 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, law, gcc-patches, gcc
> 2001-04-21 John David Anglin <dave@hiauly1.hia.nrc.ca>
>
> * builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.
Close but no cigar. This one actually bootstraps with no regressions under
i686 linux. However, I think it only addresses the symptom of the problem.
There must be a label uses problem somewhere. In any event, the testcase
for duplicate symbols will compile with the patch installed.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-04-21 John David Anglin <dave@hiauly1.hia.nrc.ca>
* builtins.c (expand_builtin_setjmp): Mark next_lab as used.
--- builtins.c.orig Wed Feb 7 05:24:22 2001
+++ builtins.c Sat Apr 21 20:18:59 2001
@@ -617,6 +617,7 @@
buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
next_lab = gen_label_rtx ();
+ LABEL_PRESERVE_P (next_lab) = 1;
cont_lab = gen_label_rtx ();
expand_builtin_setjmp_setup (buf_addr, next_lab);
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-21 19:33 ` C++ Issue on GCC 3.0 branch John David Anglin
@ 2001-04-23 2:18 ` Bernd Schmidt
2001-04-23 7:51 ` law
2001-04-25 10:26 ` Mark Mitchell
1 sibling, 1 reply; 175+ messages in thread
From: Bernd Schmidt @ 2001-04-23 2:18 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, law, gcc-patches, gcc
On Sat, 21 Apr 2001, John David Anglin wrote:
> > 2001-04-21 John David Anglin <dave@hiauly1.hia.nrc.ca>
> >
> > * builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.
>
> Close but no cigar. This one actually bootstraps with no regressions under
> i686 linux. However, I think it only addresses the symptom of the problem.
> There must be a label uses problem somewhere. In any event, the testcase
> for duplicate symbols will compile with the patch installed.
You might want to look at the patches I installed on the 2.95 branch after
2.95.3. This sounds like it's exactly the same problem.
Bernd
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-23 2:18 ` Bernd Schmidt
@ 2001-04-23 7:51 ` law
2001-04-23 7:55 ` Bernd Schmidt
2001-04-23 7:56 ` Bernd Schmidt
0 siblings, 2 replies; 175+ messages in thread
From: law @ 2001-04-23 7:51 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: John David Anglin, mark, gcc-patches, gcc
In message <Pine.LNX.4.33.0104231017340.7552-100000@host140.cambridge.redhat.
com>you write:
> > There must be a label uses problem somewhere. In any event, the testcase
> > for duplicate symbols will compile with the patch installed.
>
> You might want to look at the patches I installed on the 2.95 branch after
> 2.95.3. This sounds like it's exactly the same problem.
Are you referring to this patch?
2001-03-28 Bernd Schmidt <bernds@redhat.com>
* flow.c (propagate_block): When trying to delete a case vector, cope
if its label has LABEL_PRESERVE_P set.
* jump.c (jump_optimize_1): Move call to delete_barrier_successors to
a point where JUMP_LABELS and LABEL_NUSES are set up properly.
(delete_barrier_successors): If deleting a table jump, delete the case
vector as well.
* varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
so it won't get deleted.
Just want to be sure before I install it locally and fire off my tests.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-23 7:51 ` law
@ 2001-04-23 7:55 ` Bernd Schmidt
2001-04-23 7:56 ` Bernd Schmidt
1 sibling, 0 replies; 175+ messages in thread
From: Bernd Schmidt @ 2001-04-23 7:55 UTC (permalink / raw)
To: law; +Cc: John David Anglin, mark, gcc-patches, gcc
On Mon, 23 Apr 2001 law@redhat.com wrote:
> In message <Pine.LNX.4.33.0104231017340.7552-100000@host140.cambridge.redhat.
> com>you write:
> > > There must be a label uses problem somewhere. In any event, the testcase
> > > for duplicate symbols will compile with the patch installed.
> >
> > You might want to look at the patches I installed on the 2.95 branch after
> > 2.95.3. This sounds like it's exactly the same problem.
> Are you referring to this patch?
>
> 2001-03-28 Bernd Schmidt <bernds@redhat.com>
>
> * flow.c (propagate_block): When trying to delete a case vector, cope
> if its label has LABEL_PRESERVE_P set.
> * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
> a point where JUMP_LABELS and LABEL_NUSES are set up properly.
> (delete_barrier_successors): If deleting a table jump, delete the case
> vector as well.
> * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
> so it won't get deleted.
Yes.
Bernd
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-23 7:51 ` law
2001-04-23 7:55 ` Bernd Schmidt
@ 2001-04-23 7:56 ` Bernd Schmidt
2001-04-23 8:14 ` law
1 sibling, 1 reply; 175+ messages in thread
From: Bernd Schmidt @ 2001-04-23 7:56 UTC (permalink / raw)
To: law; +Cc: John David Anglin, mark, gcc-patches, gcc
On Mon, 23 Apr 2001 law@redhat.com wrote:
> 2001-03-28 Bernd Schmidt <bernds@redhat.com>
>
> * flow.c (propagate_block): When trying to delete a case vector, cope
> if its label has LABEL_PRESERVE_P set.
> * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
> a point where JUMP_LABELS and LABEL_NUSES are set up properly.
> (delete_barrier_successors): If deleting a table jump, delete the case
> vector as well.
> * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
> so it won't get deleted.
Just remembered; this also needs the followup
2001-03-30 Bernd Schmidt <bernds@redhat.com>
* jump.c (delete_barrier_successors): Fix error in last change.
Bernd
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-23 7:56 ` Bernd Schmidt
@ 2001-04-23 8:14 ` law
0 siblings, 0 replies; 175+ messages in thread
From: law @ 2001-04-23 8:14 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: John David Anglin, mark, gcc-patches, gcc
In message <Pine.LNX.4.33.0104231556040.7552-100000@host140.cambridge.redhat.
com>you write:
> Just remembered; this also needs the followup
>
> 2001-03-30 Bernd Schmidt <bernds@redhat.com>
>
> * jump.c (delete_barrier_successors): Fix error in last change.
OK. Thanks. I'll give the set a whirl on my PAs :-)
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-21 19:33 ` C++ Issue on GCC 3.0 branch John David Anglin
2001-04-23 2:18 ` Bernd Schmidt
@ 2001-04-25 10:26 ` Mark Mitchell
2001-04-25 14:04 ` John David Anglin
1 sibling, 1 reply; 175+ messages in thread
From: Mark Mitchell @ 2001-04-25 10:26 UTC (permalink / raw)
To: dave; +Cc: law, gcc-patches, gcc
2001-04-21 John David Anglin <dave@hiauly1.hia.nrc.ca>
* builtins.c (expand_builtin_setjmp): Mark next_lab as used.
--- builtins.c.orig Wed Feb 7 05:24:22 2001
+++ builtins.c Sat Apr 21 20:18:59 2001
@@ -617,6 +617,7 @@
buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
next_lab = gen_label_rtx ();
+ LABEL_PRESERVE_P (next_lab) = 1;
cont_lab = gen_label_rtx ();
expand_builtin_setjmp_setup (buf_addr, next_lab);
Even with this workaround patch I still get a crash using a cross
compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
patch.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-25 10:26 ` Mark Mitchell
@ 2001-04-25 14:04 ` John David Anglin
2001-04-25 17:31 ` Mark Mitchell
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-25 14:04 UTC (permalink / raw)
To: Mark Mitchell; +Cc: law, gcc-patches, gcc
> 2001-04-21 John David Anglin <dave@hiauly1.hia.nrc.ca>
>
> * builtins.c (expand_builtin_setjmp): Mark next_lab as used.
>
> --- builtins.c.orig Wed Feb 7 05:24:22 2001
> +++ builtins.c Sat Apr 21 20:18:59 2001
> @@ -617,6 +617,7 @@
> buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
>
> next_lab = gen_label_rtx ();
> + LABEL_PRESERVE_P (next_lab) = 1;
> cont_lab = gen_label_rtx ();
>
> expand_builtin_setjmp_setup (buf_addr, next_lab);
>
> Even with this workaround patch I still get a crash using a cross
> compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
> patch.
Strange. I just tried it again with the 3.0 source from a few hours
ago with no problems. The above patch was the only source change.
I just configured with `--with-gnu-as --target=hppa1.1-hp-hpux10.20' and
did a make. CFLAGS were the default `-g -O2'. My build gcc was 3.0
20010421 (prerelease).
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-25 14:04 ` John David Anglin
@ 2001-04-25 17:31 ` Mark Mitchell
2001-04-26 8:31 ` John David Anglin
2001-04-26 10:02 ` law
0 siblings, 2 replies; 175+ messages in thread
From: Mark Mitchell @ 2001-04-25 17:31 UTC (permalink / raw)
To: dave; +Cc: law, gcc-patches, gcc
After making Dave work hard sending me lots of information, it turns
out that his original patch is exactly the right thing.
I checked in the attached, on both the mainline and the branch;
hopefully it will remove the duplicate symbols on HPUX.
Tested on i686-pc-linux-gnu, and by looking at the .s output for
Dave's testcase.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
2001-04-25 Mark Mitchell <mark@codesourcery.com>
* optimize.c (maybe_clone_body): Copy TREE_PUBLIC before emitting
the clone.
Index: optimize.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/optimize.c,v
retrieving revision 1.51.2.13
diff -c -p -r1.51.2.13 optimize.c
*** optimize.c 2001/04/25 00:12:47 1.51.2.13
--- optimize.c 2001/04/26 00:28:07
*************** maybe_clone_body (fn)
*** 1051,1056 ****
--- 1051,1057 ----
DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn);
DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn);
DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn);
+ TREE_PUBLIC (clone) = TREE_PUBLIC (fn);
/* Start processing the function. */
push_to_top_level ();
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-25 17:31 ` Mark Mitchell
@ 2001-04-26 8:31 ` John David Anglin
2001-04-26 10:25 ` Mark Mitchell
2001-04-26 10:02 ` law
1 sibling, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-26 8:31 UTC (permalink / raw)
To: Mark Mitchell; +Cc: law, gcc-patches, gcc
Mark,
> After making Dave work hard sending me lots of information, it turns
> out that his original patch is exactly the right thing.
>
> I checked in the attached, on both the mainline and the branch;
> hopefully it will remove the duplicate symbols on HPUX.
While I am certain that the patch eliminates the duplicate symbols, I
am still concerned that assemble_external is being called with TREE_PUBLIC
and DECL_EXTERNAL set for the type declarations. This causes .IMPORT
statements to be generated for the symbols under hpux. While this appears
harmless under HPUX, I am not sure it would be under all circumstances.
It seemed to me that when there is no weak support these declarations
should not be external. I remember there was some discussion of this
under AIX back in January.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-26 8:31 ` John David Anglin
@ 2001-04-26 10:25 ` Mark Mitchell
0 siblings, 0 replies; 175+ messages in thread
From: Mark Mitchell @ 2001-04-26 10:25 UTC (permalink / raw)
To: dave; +Cc: law, gcc-patches, gcc
>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
John> While I am certain that the patch eliminates the duplicate
John> symbols, I am still concerned that assemble_external is
John> being called with TREE_PUBLIC and DECL_EXTERNAL set for the
John> type declarations. This causes .IMPORT statements to be
Yes, that's why I asked about this.
There's a basic problem here; both the C and C++ front-ends call
assemble_external in a way that is inconsistent with the
assemble_external documentation.
In particular, ASM_OUTPUT_EXTERNAL is documented as used when
something is
A C statement (sans semicolon) to output to the stdio stream
STREAM any text necessary for declaring the name of an external
symbol named NAME which is referenced in this compilation but not
defined. The value of DECL is the tree node for the declaration.
You can't know this until the end of the translation unit. But, we
compile a function-at-a-time, so if we see:
extern void f();
void g() { f(); }
void f() {}
we call this macro for `f'.
It's even more extreme in C++ because we don't make up our minds about
the linkages of some functions until very late in the game. (See the
tricks played with DECL_NOT_REALLY_EXTERN.) That's all really pretty
grotesque, but it's not easy to fix, and it's been that way for a long
time, so I'm guessing most systems deal with it OK.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-25 17:31 ` Mark Mitchell
2001-04-26 8:31 ` John David Anglin
@ 2001-04-26 10:02 ` law
1 sibling, 0 replies; 175+ messages in thread
From: law @ 2001-04-26 10:02 UTC (permalink / raw)
To: Mark Mitchell; +Cc: dave, gcc-patches, gcc
In message < 20010425173144F.mitchell@codesourcery.com >you write:
>
> After making Dave work hard sending me lots of information, it turns
> out that his original patch is exactly the right thing.
>
> I checked in the attached, on both the mainline and the branch;
> hopefully it will remove the duplicate symbols on HPUX.
>
> Tested on i686-pc-linux-gnu, and by looking at the .s output for
> Dave's testcase.
Noted. I'm testing hpux PA32 with it now.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
[not found] <no.id>
` (10 preceding siblings ...)
2001-04-21 19:33 ` C++ Issue on GCC 3.0 branch John David Anglin
@ 2001-04-23 15:21 ` John David Anglin
2001-04-24 19:21 ` law
2001-05-16 16:22 ` gcc 2.95.2 Joe Buck
` (31 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-23 15:21 UTC (permalink / raw)
To: John David Anglin; +Cc: law, mark, gcc
> 0x7adfdbd4 <_ZNSt8ios_base4InitC1Ev+124>: stw r26,-24(sr0,r3)
> 0x7adfdbd8 <_ZNSt8ios_base4InitC1Ev+128>:
> bl 0x7adfdac8 <__get_eh_context>,rp
> 0x7adfdbdc <_ZNSt8ios_base4InitC1Ev+132>: nop
> 0x7adfdbe0 <_ZNSt8ios_base4InitC1Ev+136>: ldw 9c(sr0,r3),r19
> 0x7adfdbe4 <_ZNSt8ios_base4InitC1Ev+140>: copy ret0,r20
> 0x7adfdbe8 <_ZNSt8ios_base4InitC1Ev+144>: stws r20,-10(sr0,sp)
> 0x7adfdbec <_ZNSt8ios_base4InitC1Ev+148>: fldws -10(sr0,sp),fr22
> 0x7adfdbf0 <_ZNSt8ios_base4InitC1Ev+152>: fstws fr22,-10(sr0,sp)
> 0x7adfdbf4 <_ZNSt8ios_base4InitC1Ev+156>: ldws -10(sr0,sp),r1
> 0x7adfdbf8 <_ZNSt8ios_base4InitC1Ev+160>: stw r1,a4(sr0,r3)
> 0x7adfdbfc <_ZNSt8ios_base4InitC1Ev+164>: stw r19,9c(sr0,r3)
The problem was not my patch. There is a real problem with pic C++ code.
The problem is that the "first" save for register r19 comes after the first
function call. The initial save of r19 was to meet ABI requirements. The
save at 0x7adfdbfc is the real save that was supposed to be used for
restoration of r19 after function calls.
You can see the problem in the rtl:
;; Function std::ios_base::Init::Init()
(note 1 0 6 ("../../../../libstdc++-v3/src/ios.cc") 137 0)
(insn 6 1 54 (set (reg/v/u/f:SI 94)
(reg:SI 26 %r26)) -1 (nil)
(expr_list:REG_EQUIV (mem/u/f:SI (plus:SI (reg/f:SI 89 virtual-incoming-args)
(const_int -4 [0xfffffffc])) 0)
(nil)))
(insn 54 6 43 (use:SI (reg:SI 105)) -1 (nil)
(expr_list:REG_EH_CONTEXT (reg:SI 105)
(nil)))
(insn 43 54 7 (set (reg:SI 103)
(reg:SI 19 %r19)) -1 (nil)
(nil))
(note 7 43 15 NOTE_INSN_FUNCTION_BEG 0)
(note 15 7 17 ("../../../../libstdc++-v3/src/ios.cc") 138 0)
As can be seen, the eh context stuff has been pushed to the beginning of
the function. We need insn 43 to be at the beginning before the eh
context stuff. We try to put the save at the start in hppa_init_pic_save:
void hppa_init_pic_save ()
{
rtx insn, picreg;
picreg = gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM);
PIC_OFFSET_TABLE_SAVE_RTX = gen_reg_rtx (Pmode);
insn = gen_rtx_SET (VOIDmode, PIC_OFFSET_TABLE_SAVE_RTX, picreg);
/* Emit the insn at the beginning of the function after the prologue. */
push_topmost_sequence ();
emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
pop_topmost_sequence ();
}
This is called when the first call insn is encountered. Any thoughts
on how to fix this?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-23 15:21 ` John David Anglin
@ 2001-04-24 19:21 ` law
2001-04-24 20:23 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: law @ 2001-04-24 19:21 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, gcc
In message < 200104232221.SAA21738@hiauly1.hia.nrc.ca >you write:
> As can be seen, the eh context stuff has been pushed to the beginning of
> the function. We need insn 43 to be at the beginning before the eh
> context stuff. We try to put the save at the start in hppa_init_pic_save:
Interesting. I'm not sure if I'll have time to peek at this tonight/tomorrow.
So, if you've got time, you'd want to investigate precisely how the code to
call get_eh_context gets inserted before the code to save the PIC register.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-24 19:21 ` law
@ 2001-04-24 20:23 ` John David Anglin
2001-04-26 16:45 ` law
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-24 20:23 UTC (permalink / raw)
To: law; +Cc: mark, gcc
> In message < 200104232221.SAA21738@hiauly1.hia.nrc.ca >you write:
> > As can be seen, the eh context stuff has been pushed to the beginning of
> > the function. We need insn 43 to be at the beginning before the eh
> > context stuff. We try to put the save at the start in hppa_init_pic_save:
> Interesting. I'm not sure if I'll have time to peek at this tonight/tomorrow.
> So, if you've got time, you'd want to investigate precisely how the code to
> call get_eh_context gets inserted before the code to save the PIC register.
Yes! I think that I have the fix. See below.
The call to get_eh_context gets inserted before the code to save the PIC
register with the same technique that we use to save the PIC register:
rtx
get_eh_context ()
{
if (current_function_ehc == 0)
{
rtx insn;
current_function_ehc = gen_reg_rtx (Pmode);
insn = gen_rtx_USE (GET_MODE (current_function_ehc),
current_function_ehc);
insn = emit_insn_before (insn, get_first_nonparm_insn ());
REG_NOTES (insn)
= gen_rtx_EXPR_LIST (REG_EH_CONTEXT, current_function_ehc,
REG_NOTES (insn));
}
return current_function_ehc;
}
Here are my latest test results for libstdc++-v3:
(chmod + ./mkcheck; \
srcdir=`cd ../../../libstdc++-v3; pwd`; builddir=`pwd`; \
test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \
cd testsuite; ${builddir}/mkcheck 0 ${builddir} ${srcdir})
running mkcheck
/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: testing the build directory
making utility ./printnow.exe
Detailed test results in ../20010424-mkcheck.txt
+: pass, -b: build failure, -r: run failure, x: disabled
------------------------------------------------------------------------
static shared test
------------------------------------------------------------------------
+ + 17_intro/header_ciso646.cc
+ + 17_intro/header_cstdio.cc
+ + 17_intro/header_cstdlib.cc
+ + 17_intro/header_cstring.cc
+ + 17_intro/header_ctime.cc
+ + 17_intro/header_cwchar.cc
+ + 17_intro/header_cwctype.cc
+ + 17_intro/header_fstream.cc
+ + 17_intro/header_iomanip.cc
+ + 17_intro/header_ios.cc
+ + 17_intro/header_iosfwd.cc
+ + 17_intro/header_iostream.cc
+ + 17_intro/header_istream.cc
+ + 17_intro/header_ostream.cc
+ + 17_intro/header_sstream.cc
+ + 17_intro/header_streambuf.cc
+ + 17_intro/headers.cc
+ + 17_intro/headers_c++.cc
+ + 17_intro/headers_c.cc
+ + 18_support/numeric_limits.cc
+ + 19_diagnostics/stdexceptions.cc
+ + 20_util/auto_ptr.cc
+ -r 21_strings/append.cc
-b -b 21_strings/capacity.cc
+ + 21_strings/char_traits_requirements.cc
+ + 21_strings/char_traits_typedefs.cc
+ + 21_strings/compare.cc
-r -r 21_strings/ctor_copy_dtor.cc
+ -r 21_strings/element_access.cc
+ + 21_strings/find.cc
+ -r 21_strings/insert.cc
+ + 21_strings/inserters_extractors.cc
+ + 21_strings/invariants.cc
+ + 21_strings/nonmember.cc
+ + 21_strings/operations.cc
+ + 21_strings/replace.cc
+ + 21_strings/rfind.cc
+ -r 21_strings/substr.cc
+ + 22_locale/codecvt_char_char.cc
+ + 22_locale/codecvt_unicode_char.cc
+ + 22_locale/codecvt_unicode_wchar_t.cc
+ + 22_locale/codecvt_wchar_t_char.cc
+ + 22_locale/ctor_copy_dtor.cc
+ + 22_locale/ctype.cc
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
22_locale/ctype_char_members.cc
+ + 22_locale/ctype_wchar_t_members.cc
+ + 22_locale/facet.cc
+ + 22_locale/global_templates.cc
+ + 22_locale/members.cc
-b -b 22_locale/numpunct.cc
+ + 22_locale/numpunct_byname.cc
+ + 22_locale/numpunct_char_members.cc
+ + 22_locale/operators.cc
+ + 22_locale/static_members.cc
+ + 23_containers/bitset_ctor.cc
+ + 23_containers/bitset_shift.cc
-b -b 23_containers/map_operators.cc
+ + 23_containers/multiset.cc
-b -b 23_containers/set_operators.cc
+ + 23_containers/vector_capacity.cc
+ + 23_containers/vector_ctor.cc
+ -r 23_containers/vector_element_access.cc
+ + 23_containers/vector_modifiers.cc
+ + 24_iterators/istreambuf_iterator.cc
+ + 24_iterators/iterator.cc
+ + 25_algorithms/equal.cc
+ + 25_algorithms/lower_bound.cc
+ + 25_algorithms/min_max.cc
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
26_numerics/binary_closure.cc
+ + 26_numerics/buggy_complex.cc
+ + 26_numerics/c99_macros.cc
+ + 26_numerics/c_math.cc
+ + 26_numerics/complex_inserters_extractors.cc
+ + 26_numerics/complex_value.cc
+ + 26_numerics/valarray.cc
-b -b 27_io/filebuf.cc
+ + 27_io/filebuf_members.cc
+ + 27_io/fpos.cc
+ + 27_io/ifstream_members.cc
+ + 27_io/ios_base_callbacks.cc
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
27_io/ios_base_members_static.cc
+ + 27_io/ios_base_storage.cc
+ + 27_io/ios_ctor.cc
+ + 27_io/ios_manip_basefield.cc
+ + 27_io/ios_manip_fmtflags.cc
+ -r 27_io/ios_members.cc
+ + 27_io/istream.cc
+ + 27_io/istream_extractor_arith.cc
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
27_io/istream_extractor_char.cc
+ + 27_io/istream_extractor_other.cc
+ + 27_io/istream_manip.cc
-b -b 27_io/istream_seeks.cc
+ + 27_io/istream_sentry.cc
diff: ./istream_unformatted-2.txt: No such file or directory
+ diff: ./istream_unformatted-2.txt: No such file or directory
+ 27_io/istream_unformatted.cc
+ + 27_io/istringstream_members.cc
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
+ /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
27_io/narrow_stream_objects.cc
+ + 27_io/ofstream_members.cc
+ + 27_io/ostream.cc
+ + 27_io/ostream_inserter_arith.cc
+ + 27_io/ostream_inserter_char.cc
+ + 27_io/ostream_inserter_other.cc
+ + 27_io/ostream_manip.cc
+ + 27_io/ostream_seeks.cc
+ + 27_io/ostream_unformatted.cc
+ + 27_io/streambuf.cc
+ + 27_io/stringbuf.cc
+ + 27_io/stringstream.cc
+ + 27_io/wide_stream_objects.cc
+ + ext/headers.cc
testrun == 9137 seconds
Most of the shared test now run sucessfully! Yeah!
Here is the configuration:
1) Patch below to add the pic save to the parameter insns.
2) Hack to make type constructors static:
< http://gcc.gnu.org/ml/gcc/2001-04/msg01011.html >. Mark was going to
provide a correct fix for this.
3) NM_FLAG fix:
< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01058.html >.
4) Full length subspace names:
< http://gcc.gnu.org/ml/gcc/2001-04/msg01067.html >.
5) GNU tools (as, nm, etc.) rather than HP.
I will try to look further into the section name problem tomorrow (I've just
driven 12 hours today). I did notice that HP `nm -p' prints the subspace
names as `t' symbols and they still come out even with "-pg". I will post
full testresults tomorrow.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-01-04 John David Anglin <dave@hiauly1.hia.nrc.ca>
* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
pic save insn.
--- pa.c.orig Tue Apr 17 14:36:50 2001
+++ pa.c Tue Apr 24 00:03:33 2001
@@ -3359,7 +3359,7 @@
/* Emit the insn at the beginning of the function after the prologue. */
push_topmost_sequence ();
- emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+ last_parm_insn = emit_insn_before (insn, get_first_nonparm_insn ());
pop_topmost_sequence ();
}
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-24 20:23 ` John David Anglin
@ 2001-04-26 16:45 ` law
2001-04-26 17:02 ` Mark Mitchell
` (3 more replies)
0 siblings, 4 replies; 175+ messages in thread
From: law @ 2001-04-26 16:45 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, gcc
In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
> 2001-01-04 John David Anglin <dave@hiauly1.hia.nrc.ca>
>
> * pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
> pic save insn.
This is fine for the mainline sources as well as the branch.
Thanks for tracking this down!
If you want another challenge -- the rethrow1.C test from the g++ testsuite is
getting into an infinite loop. A 2.95.x based compiler does the right thing.
I've started poking at this, but I don't have a real clear understanding of
the C++ language or its EH semantics. About the only tidbit I've got that
might be helpful is that we might be missing a call to cp_pop_exception.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-26 16:45 ` law
@ 2001-04-26 17:02 ` Mark Mitchell
2001-04-26 17:29 ` law
2001-04-27 10:43 ` John David Anglin
` (2 subsequent siblings)
3 siblings, 1 reply; 175+ messages in thread
From: Mark Mitchell @ 2001-04-26 17:02 UTC (permalink / raw)
To: law; +Cc: dave, gcc
>>>>> "law" == law <law@redhat.com> writes:
law> I've started poking at this, but I don't have a real clear
law> understanding of the C++ language or its EH semantics. About
law> the only tidbit I've got that might be helpful is that we
law> might be missing a call to cp_pop_exception.
I'm delighted that we're making progress on HPUX. That's exciting.
Of course, RTH is getting ready to stand EH on its head. So, unless
this happens on the mainline, it's probaby not worth looking at; the
whole land of exceptions is going to turn upside down RSN.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-26 17:02 ` Mark Mitchell
@ 2001-04-26 17:29 ` law
0 siblings, 0 replies; 175+ messages in thread
From: law @ 2001-04-26 17:29 UTC (permalink / raw)
To: Mark Mitchell; +Cc: dave, gcc
In message < 20010426170133Z.mitchell@codesourcery.com >you write:
> >>>>> "law" == law <law@redhat.com> writes:
>
> law> I've started poking at this, but I don't have a real clear
> law> understanding of the C++ language or its EH semantics. About
> law> the only tidbit I've got that might be helpful is that we
> law> might be missing a call to cp_pop_exception.
>
> I'm delighted that we're making progress on HPUX. That's exciting.
>
> Of course, RTH is getting ready to stand EH on its head. So, unless
> this happens on the mainline, it's probaby not worth looking at; the
> whole land of exceptions is going to turn upside down RSN.
I'm really not looking at the mainline at all. I'll put debugging EH stuff
on hold for now and look at other issues.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-26 16:45 ` law
2001-04-26 17:02 ` Mark Mitchell
@ 2001-04-27 10:43 ` John David Anglin
2001-04-27 15:14 ` John David Anglin
2001-04-30 8:59 ` John David Anglin
3 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-04-27 10:43 UTC (permalink / raw)
To: law; +Cc: mark, gcc
> In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
> > 2001-01-04 John David Anglin <dave@hiauly1.hia.nrc.ca>
> >
> > * pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
> > pic save insn.
> This is fine for the mainline sources as well as the branch.
>
> Thanks for tracking this down!
Before I installed this, I checked to make sure there were no gcc regressions
in the testsuite with -fPIC. I found that in fact there were some. It looks
like there are problems with the placement of the save instruction when
the first non parameter insn is nil. I think we need to place the save
after the first insn (the one returned by get_insns ()) in this case.
Some of the fails in the testsuite are due to an abort at integrate.c:430
due to first insn not being a note:
;; Function z
(note 2 0 26 NOTE_INSN_DELETED 0)
(insn 26 2 3 (set (reg:SI 98)
(reg:SI 19 %r19)) -1 (nil)
(nil))
(note 3 26 5 NOTE_INSN_FUNCTION_BEG 0)
I am going to go back to the original form and not use
get_first_nonparm_insn (). I think this will fix the problem.
This suggests that there is also a bug in get_eh_context () for
the same reason.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-26 16:45 ` law
2001-04-26 17:02 ` Mark Mitchell
2001-04-27 10:43 ` John David Anglin
@ 2001-04-27 15:14 ` John David Anglin
2001-04-28 9:55 ` law
2001-04-30 8:59 ` John David Anglin
3 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-04-27 15:14 UTC (permalink / raw)
To: law; +Cc: mark, gcc
> If you want another challenge -- the rethrow1.C test from the g++ testsuite is
> getting into an infinite loop. A 2.95.x based compiler does the right thing.
>
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics. About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.
I think we need to define builtin_setjmp_receiver to restore r19. The
default exception method I believe is exceptions via longjmp, so we need
this. However, I have no idea whether or not this will fix the problem
with rethrow1.C.
I also noticed a while back that exception_receiver uses a stack offset
of -32 to restore the pic offset table register. This won't work on
the 64-bit target. I think we should restore from the
PIC_OFFSET_TABLE_SAVE_RTX. However, we need to wait for it to be
initialized.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-27 15:14 ` John David Anglin
@ 2001-04-28 9:55 ` law
0 siblings, 0 replies; 175+ messages in thread
From: law @ 2001-04-28 9:55 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, gcc
In message < 200104272214.SAA06753@hiauly1.hia.nrc.ca >you write:
> I think we need to define builtin_setjmp_receiver to restore r19. The
> default exception method I believe is exceptions via longjmp, so we need
> this. However, I have no idea whether or not this will fix the problem
> with rethrow1.C.
Yes, we probably need to restore %r19, but I'm 99.9 certain that's not the
problem with the rethrow test since they fail with static libraries.
> I also noticed a while back that exception_receiver uses a stack offset
> of -32 to restore the pic offset table register. This won't work on
> the 64-bit target. I think we should restore from the
> PIC_OFFSET_TABLE_SAVE_RTX. However, we need to wait for it to be
> initialized.
Right.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: C++ Issue on GCC 3.0 branch
2001-04-26 16:45 ` law
` (2 preceding siblings ...)
2001-04-27 15:14 ` John David Anglin
@ 2001-04-30 8:59 ` John David Anglin
3 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-04-30 8:59 UTC (permalink / raw)
To: law; +Cc: mark, gcc
> In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
> > 2001-01-04 John David Anglin <dave@hiauly1.hia.nrc.ca>
> >
> > * pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
> > pic save insn.
> This is fine for the mainline sources as well as the branch.
I have installed it on the branch. The code on the main is different.
Thus, I don't know if the same problem exists there or not. The code
on the main looks strange to me. One change that looks certainly
correct is to set RTX_UNCHANGING_P in PIC_OFFSET_TABLE_SAVE_RTX.
> Thanks for tracking this down!
>
> If you want another challenge -- the rethrow1.C test from the g++ testsuite is
> getting into an infinite loop. A 2.95.x based compiler does the right thing.
>
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics. About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.
I have been looking at some of the g++ failures. I have some revisions
to the setjmp/longjmp stuff in pa.md. However, I noticed last night
that some code generated by builtin_setjmp was missing. It appears that
more than just labels were disappearing. Essentially, builtin_setjmp
was dropping into the receiver code on the intial setup.
I have updated my test source so that it now includes your disappearing
label patch. Hopefully, this will fix some of the problems. I visually
looked at the assembler code in __sjthrow and it now looks ok. Tests
are running..
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc 2.95.2
[not found] <no.id>
` (11 preceding siblings ...)
2001-04-23 15:21 ` John David Anglin
@ 2001-05-16 16:22 ` Joe Buck
2001-06-14 9:58 ` STL warnings recently appeared in the 3.0 branch John David Anglin
` (30 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: Joe Buck @ 2001-05-16 16:22 UTC (permalink / raw)
To: Sally S Maznabi; +Cc: gcc
> I am planning to install gcc 2.95.2 on an IBM AIX server. I am
> dowloading the gcc from the sunfreeware site. Does gcc 2.95.2 works on
> IBM AIX server.
sunfreeware provides precompiled binaries for Solaris, not for IBM AIX,
so that isn't going to work. But gcc does support AIX.
Please ask the gcc-help@gcc.gnu.org list for assistance; gcc@gcc.gnu.org
is the compiler developers' list.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: STL warnings recently appeared in the 3.0 branch
[not found] <no.id>
` (12 preceding siblings ...)
2001-05-16 16:22 ` gcc 2.95.2 Joe Buck
@ 2001-06-14 9:58 ` John David Anglin
2001-06-14 11:34 ` Possible corruption of gcc-3.0-20010614.tar.bz2 John David Anglin
` (29 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-06-14 9:58 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, aoliva, Sylvain.Pion
> On Jun 14, 2001, Sylvain Pion <Sylvain.Pion@sophia.inria.fr> wrote:
> > .../include/g++-v3/bits/stl_alloc.h:494:
> > warning: aggregate has a partly bracketed initializer
> > I don't get them on GNU-Linux, but they appear on Solaris.
> IIRC, this is a bug in Solaris' headers. The initializer for mutexes
> defined in some header file triggers this warning.
If you are using solaris threads (gthr-solaris.h), the system headers
(thread.h) are supposed to define DEFAULTMUTEX. If they don't, the
initializer is broken and the STL mutex locking won't work properly.
The integration of GTHREADS into v3 is new which is why your seeing
the warning. My previous comments probably don't apply to solaris.
The file gthr-solaris.h may need to check to see if DEFAULTMUTEX is
defined. If it isn't then, some fallback is needed. This could be
defining DEFAULTMUTEX, or using __GTHREAD_ONCE_INIT_FUNCTION instead
of __GTHREAD_ONCE_INIT.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Possible corruption of gcc-3.0-20010614.tar.bz2
[not found] <no.id>
` (13 preceding siblings ...)
2001-06-14 9:58 ` STL warnings recently appeared in the 3.0 branch John David Anglin
@ 2001-06-14 11:34 ` John David Anglin
2001-06-14 15:56 ` PATCH: Fix invalid loader fixups from shared libobjc with John David Anglin
` (28 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-06-14 11:34 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
> [11: huff+mtf
> bzip2: Caught a SIGSEGV or SIGBUS whilst decompressing,
> which probably indicates that the compressed data
> is corrupted.
> Input file = Z/gcc-3.0-20010614.tar.bz2, output file = (none)
The problem has been confirmed with a second download from a mirror
source. I also tried decompressing unde i686 linux with same result.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: PATCH: Fix invalid loader fixups from shared libobjc with
[not found] <no.id>
` (14 preceding siblings ...)
2001-06-14 11:34 ` Possible corruption of gcc-3.0-20010614.tar.bz2 John David Anglin
@ 2001-06-14 15:56 ` John David Anglin
2001-08-09 15:12 ` Simple returns are broken in gcc 3.X John David Anglin
` (27 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-06-14 15:56 UTC (permalink / raw)
To: John David Anglin; +Cc: mark, shebs, law, gcc
> The problem appears wider than just hpux. See for example,
> < http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00329.html >.
> This report is for i686-pc-linux-gnu. I can't say exactly what
I have just run a bootstrap and check to verify this problem. There
is a problem with the testsuite and the failures are not directly
related to the hpux problem:
/home/dave/gnu/gcc-3.0-20010614/objdir/gcc/testsuite/IMP.x: error in loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
I believe that this problem arises on my linux system because
LD_LIBRARY_PATH doesn't affect the patch for dependent libraries (libobjc).
I had some discussion with Alex about trying to fix this with libtool
but the objc testsuite doesn't use libtool. It just uses xgcc to
build and link testsuite apps.
A second problem is the installation location of libobjc. It got
installed in ${prefix}/lib/gcc-lib/i688-pc-linux-gnu/3.0. The other
shared libraries all went in the more normal location ${prefix}/lib.
${prefix}/lib/gcc-lib/i688-pc-linux-gnu/3.0 is not one of the paths
that my system normally uses in its shared library search. Do you
advise people to make this change or is libobjc being installed
in the wrong place now that it is possible to build a shared version
of it?
Regarding the hpux problem at hand, I see some warnings like this
in the objc.log:
spawn /home/dave/gnu/gcc-3.0-20010614/objdir/gcc/xgcc -B/home/dave/gnu/gcc-3.0-20010614/objdir/gcc/ /home/dave/gnu/gcc-3.0-20010614/gcc/testsuite/objc/execute/string4.m -w -O -I/home/dave/gnu/gcc-3.0-20010614/gcc/testsuite/../../libobjc -L/home/dave/gnu/gcc-3.0-20010614/objdir/i686-pc-linux-gnu/libobjc/.libs -lobjc -lm -o /home/dave/gnu/gcc-3.0-20010614/objdir/gcc/testsuite/string4.x
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/../../../../i686-pc-linux-gnu/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NXConstantString' are not defined
And in libobjc.a:
0000000000000004 ? __objc_class_name_Object
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Simple returns are broken in gcc 3.X
[not found] <no.id>
` (15 preceding siblings ...)
2001-06-14 15:56 ` PATCH: Fix invalid loader fixups from shared libobjc with John David Anglin
@ 2001-08-09 15:12 ` John David Anglin
2001-08-09 15:48 ` Richard Henderson
2001-12-12 8:49 ` Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880 John David Anglin
` (26 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-08-09 15:12 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-patches
> In looking into why g++ didn't work for vax-dec-ultrix4.3, I have found
> that simple returns are broken. Compiling this small test program
>
> static char *
> srealloc (char *p, char *q, int i)
> {
> if (i == 0)
> return p;
> else
> return q;
> }
>
> yields
>
> #NO_APP
> .text
> .align 1
> __Z8sreallocPcS_i:
> .word 0x0
> subl2 $12,sp
> tstl 12(ap)
> jneq L2
> ret
> L2:
> ret
This patch fixes the above problem by always forcing a "goto" return.
The patch only affects the vax since it is the only remaining port that
doesn't define an epilogue and allows the expansion of simple returns
prior to reload. This patch changes the vax port to use the same
code patch for return generation as all others. As a side benefit, the
change also fixes function instrumentation on the vax.
The above behavior is a regression versus previous gcc versions since
g++ was functional on the vax in version 2.8.1.
Full bootstrap has been done with vax-dec-ultrix4.3 with 3.0 branch.
Bootstrap and regression checked with 3.0 branch on hppa1.1-hp-hpux10.20
and i686-pc-linux-gnu. Bootstrap and regression checked with 3.1
mainline on i686-pc-linux-gnu.
OK for main? I would like it on the branch as well but there are a
couple of other patches needed before C++ will be fully functional
on the vax. Thus, it can wait until after 3.0.1 is released.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2001-08-09 John David Anglin <dave@hiauly1.hia.nrc.ca>
* stmt.c (expand_null_return_1): Remove code to generate simple returns
and "use_goto" argument.
(expand_null_return, expand_value_return): Update all callers.
* function.c (expand_function_end): Remove code to generate simple
return.
* config/vax/vax.md (epilogue): New expander for function return.
* doc/md.texi (epilogue): Remove "if defined".
--- stmt.c.orig Tue Jul 31 10:22:56 2001
+++ stmt.c Wed Aug 1 15:52:05 2001
@@ -403,7 +403,7 @@
static void expand_nl_goto_receivers PARAMS ((struct nesting *));
static void fixup_gotos PARAMS ((struct nesting *, rtx, tree,
rtx, int));
-static void expand_null_return_1 PARAMS ((rtx, int));
+static void expand_null_return_1 PARAMS ((rtx));
static void expand_value_return PARAMS ((rtx));
static int tail_recursion_args PARAMS ((tree, tree));
static void expand_cleanups PARAMS ((tree, tree, int, int));
@@ -2863,7 +2863,6 @@
void
expand_null_return ()
{
- struct nesting *block = block_stack;
rtx last_insn = get_last_insn ();
/* If this function was declared to return a value, but we
@@ -2871,13 +2870,7 @@
propogated live to the rest of the function. */
clobber_return_register ();
- /* Does any pending block have cleanups? */
- while (block && block->data.block.cleanups == 0)
- block = block->next;
-
- /* If yes, use a goto to return, since that runs cleanups. */
-
- expand_null_return_1 (last_insn, block != 0);
+ expand_null_return_1 (last_insn);
}
/* Generate RTL to return from the current function, with value VAL. */
@@ -2886,7 +2879,6 @@
expand_value_return (val)
rtx val;
{
- struct nesting *block = block_stack;
rtx last_insn = get_last_insn ();
rtx return_reg = DECL_RTL (DECL_RESULT (current_function_decl));
@@ -2913,27 +2905,15 @@
emit_move_insn (return_reg, val);
}
- /* Does any pending block have cleanups? */
-
- while (block && block->data.block.cleanups == 0)
- block = block->next;
-
- /* If yes, use a goto to return, since that runs cleanups.
- Use LAST_INSN to put cleanups *before* the move insn emitted above. */
-
- expand_null_return_1 (last_insn, block != 0);
+ expand_null_return_1 (last_insn);
}
/* Output a return with no value. If LAST_INSN is nonzero,
- pretend that the return takes place after LAST_INSN.
- If USE_GOTO is nonzero then don't use a return instruction;
- go to the return label instead. This causes any cleanups
- of pending blocks to be executed normally. */
+ pretend that the return takes place after LAST_INSN. */
static void
-expand_null_return_1 (last_insn, use_goto)
+expand_null_return_1 (last_insn)
rtx last_insn;
- int use_goto;
{
rtx end_label = cleanup_label ? cleanup_label : return_label;
@@ -2941,27 +2921,8 @@
do_pending_stack_adjust ();
last_expr_type = 0;
- /* PCC-struct return always uses an epilogue. */
- if (current_function_returns_pcc_struct || use_goto)
- {
- if (end_label == 0)
- end_label = return_label = gen_label_rtx ();
- expand_goto_internal (NULL_TREE, end_label, last_insn);
- return;
- }
-
- /* Otherwise output a simple return-insn if one is available,
- unless it won't do the job. */
-#ifdef HAVE_return
- if (HAVE_return && use_goto == 0 && cleanup_label == 0)
- {
- emit_jump_insn (gen_return ());
- emit_barrier ();
- return;
- }
-#endif
-
- /* Otherwise jump to the epilogue. */
+ if (end_label == 0)
+ end_label = return_label = gen_label_rtx ();
expand_goto_internal (NULL_TREE, end_label, last_insn);
}
\f
--- function.c.orig Sat Jun 9 15:22:26 2001
+++ function.c Wed Aug 1 12:40:23 2001
@@ -6949,18 +6949,6 @@
instead of using the general framework. */
use_return_register ();
- /* Output a return insn if we are using one.
- Otherwise, let the rtl chain end here, to drop through
- into the epilogue. */
-
-#ifdef HAVE_return
- if (HAVE_return)
- {
- emit_jump_insn (gen_return ());
- emit_barrier ();
- }
-#endif
-
/* Fix up any gotos that jumped out to the outermost
binding level of the function.
Must follow emitting RETURN_LABEL. */
--- config/vax/vax.md.orig Sun Jan 14 04:08:51 2001
+++ config/vax/vax.md Tue Jul 31 22:08:45 2001
@@ -1926,6 +1926,15 @@
""
"ret")
+(define_expand "epilogue"
+ [(return)]
+ ""
+ "
+{
+ emit_jump_insn (gen_return ());
+ DONE;
+}")
+
(define_insn "nop"
[(const_int 0)]
""
--- doc/md.texi.orig Thu Jun 14 18:54:21 2001
+++ doc/md.texi Thu Aug 9 12:24:04 2001
@@ -2859,7 +2859,7 @@
@cindex @code{epilogue} instruction pattern
@item @samp{epilogue}
-This pattern, if defined, emits RTL for exit from a function. The function
+This pattern emits RTL for exit from a function. The function
exit is responsible for deallocating the stack frame, restoring callee saved
registers and emitting the return instruction.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Simple returns are broken in gcc 3.X
2001-08-09 15:12 ` Simple returns are broken in gcc 3.X John David Anglin
@ 2001-08-09 15:48 ` Richard Henderson
0 siblings, 0 replies; 175+ messages in thread
From: Richard Henderson @ 2001-08-09 15:48 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-patches
On Thu, Aug 09, 2001 at 06:12:04PM -0400, John David Anglin wrote:
> * stmt.c (expand_null_return_1): Remove code to generate simple returns
> and "use_goto" argument.
> (expand_null_return, expand_value_return): Update all callers.
> * function.c (expand_function_end): Remove code to generate simple
> return.
> * config/vax/vax.md (epilogue): New expander for function return.
> * doc/md.texi (epilogue): Remove "if defined".
Ok.
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
[not found] <no.id>
` (16 preceding siblings ...)
2001-08-09 15:12 ` Simple returns are broken in gcc 3.X John David Anglin
@ 2001-12-12 8:49 ` John David Anglin
2001-12-12 15:58 ` John David Anglin
2002-01-30 17:36 ` condition codes, haifa-sched and virtual-stack-vars Ulrich Weigand
` (25 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-12-12 8:49 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, jh, rth
> I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> at function.c:3880, on vax-dec-ultrix4.3 with the main. The first one that
> I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
>
> (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
> (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> (subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> (const_int 16 [0x10]))
> (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
> (nil))
>
> It appears that instantiate_virtual_regs_1 ICEs because general_operand
> (see recog.c:966) doesn't allow a SUBREG with a nonzero SUBREG_BYTE and
> this causes the first instantiation to fail. Should this insn have been
> created in the first place if there is this limitation on SUBREG MEMs?
I see that the change to general_operand to prohibit nonzero subreg bytes
was made last last May to fix a "not so trivial powerpc regression"
<http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01309.html>. In this
message, there is mention of being less aggressive and verifying if
offsetted memory will match. On the otherhand, Richard suggested that
it would be better not to create these subregs in the first place.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
2001-12-12 8:49 ` Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880 John David Anglin
@ 2001-12-12 15:58 ` John David Anglin
2001-12-13 1:28 ` Jan Hubicka
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-12-12 15:58 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, jh, rth
> > I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> > at function.c:3880, on vax-dec-ultrix4.3 with the main. The first one that
> > I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
> >
> > (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
> > (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> > (subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> > (const_int 16 [0x10]))
> > (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
> > (nil))
> >
I have come to the conclusion that there is a problem with
GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
DCmode MEM with the above indexing) since the maximum number
of bytes that can be moved in a single insn is 8.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
2001-12-12 15:58 ` John David Anglin
@ 2001-12-13 1:28 ` Jan Hubicka
2001-12-13 11:57 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Jan Hubicka @ 2001-12-13 1:28 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, jh, rth
> > > I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> > > at function.c:3880, on vax-dec-ultrix4.3 with the main. The first one that
> > > I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
> > >
> > > (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
> > > (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> > > (subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> > > (const_int 16 [0x10]))
> > > (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
> > > (nil))
> > >
>
> I have come to the conclusion that there is a problem with
> GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> DCmode MEM with the above indexing) since the maximum number
> of bytes that can be moved in a single insn is 8.
Yes, this is the complex type hackery - basically it does the DC modes behind
scene w/o validation from backend splitting it later.
What you need is to figure out from where the subreg is comming and replace
gen_SUBREG by simplify_gen_subreg. That should be enought I guess.
In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
let me know.
Honza
>
> Dave
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
2001-12-13 1:28 ` Jan Hubicka
@ 2001-12-13 11:57 ` John David Anglin
2001-12-13 12:05 ` Jan Hubicka
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2001-12-13 11:57 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc, jh, rth
> > I have come to the conclusion that there is a problem with
> > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > DCmode MEM with the above indexing) since the maximum number
> > of bytes that can be moved in a single insn is 8.
> Yes, this is the complex type hackery - basically it does the DC modes behind
> scene w/o validation from backend splitting it later.
> What you need is to figure out from where the subreg is comming and replace
> gen_SUBREG by simplify_gen_subreg. That should be enought I guess.
>
> In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
> let me know.
The subreg is coming from simplify_gen_subreg:
new = simplify_subreg (outermode, op, innermode, byte);
if (new)
return new;
if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
return NULL_RTX;
return gen_rtx_SUBREG (outermode, op, byte);
}
The call to simplify_subreg us not successful because mode_dependent_address_p
returns true for:
(plus:SI (mult:SI (reg:SI 21)
(const_int 16 [0x10]))
(mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32]))
At the moment, GO_IF_MODE_DEPENDENT_ADDRESS only accepts a plus with
a register and a constant address.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
2001-12-13 11:57 ` John David Anglin
@ 2001-12-13 12:05 ` Jan Hubicka
2001-12-14 13:26 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Jan Hubicka @ 2001-12-13 12:05 UTC (permalink / raw)
To: John David Anglin; +Cc: Jan Hubicka, gcc, rth
> > > I have come to the conclusion that there is a problem with
> > > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > > DCmode MEM with the above indexing) since the maximum number
> > > of bytes that can be moved in a single insn is 8.
> > Yes, this is the complex type hackery - basically it does the DC modes behind
> > scene w/o validation from backend splitting it later.
> > What you need is to figure out from where the subreg is comming and replace
> > gen_SUBREG by simplify_gen_subreg. That should be enought I guess.
> >
> > In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
> > let me know.
>
> The subreg is coming from simplify_gen_subreg:
>
> new = simplify_subreg (outermode, op, innermode, byte);
> if (new)
> return new;
>
> if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
> return NULL_RTX;
>
> return gen_rtx_SUBREG (outermode, op, byte);
> }
>
> The call to simplify_subreg us not successful because mode_dependent_address_p
>
> returns true for:
>
> (plus:SI (mult:SI (reg:SI 21)
> (const_int 16 [0x10]))
> (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32]))
>
> At the moment, GO_IF_MODE_DEPENDENT_ADDRESS only accepts a plus with
> a register and a constant address.
I see. This is somewhat unfortunate.
What I was thinking about is to add simplify_subreg_force wrapper that will
do converison even if it looks wrong (resulting address is invalid or resulting
register having not valid mode).
This is usefull for few other places too (alter_subreg, split_di), perhaps it
can be used here too. Sound sane?
Honza
>
> Dave
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
2001-12-13 12:05 ` Jan Hubicka
@ 2001-12-14 13:26 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2001-12-14 13:26 UTC (permalink / raw)
To: Jan Hubicka; +Cc: jh, gcc, rth
> > > > I have come to the conclusion that there is a problem with
> > > > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > > > DCmode MEM with the above indexing) since the maximum number
> > > > of bytes that can be moved in a single insn is 8.
Changing GO_IF_LEGITIMATE_ADDRESS to reject DCmode (or larger) index
addresses in the form plus ((mult ((reg) (const_int))) (mem)) appears
to resolve the problem. Logically, this seems the correct approach as
the capability to index DCmode doesn't exist on all VAXen, and no DCmode
patterns are presently in the machine definition.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: condition codes, haifa-sched and virtual-stack-vars
[not found] <no.id>
` (17 preceding siblings ...)
2001-12-12 8:49 ` Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880 John David Anglin
@ 2002-01-30 17:36 ` Ulrich Weigand
2002-02-21 13:31 ` Help! DW function pointer encoding for PA John David Anglin
` (24 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: Ulrich Weigand @ 2002-01-30 17:36 UTC (permalink / raw)
To: geoffk; +Cc: gcc
Following up on myself:
> The reload_inhi pattern tries to allocate the carry register as the
> secondary reload scratch register. Now, in the interesting case
> where the carry register is in fact live at the location where the
> insn is inserted, this would mean that reload would need to spill
> the carry register and later on restore its old value, right?
> (Because there is only a single register in this class ...)
>
> However, I'm not sure how the carry register can be spilled,
> given that there is no mov* insn that touches it, unless I'm
> missing something ...
Hmm, what I was missing was that apparently the carry register
can *never* be live during reload, as all insns that actually
use it (except for just a clobber) are *only* ever emitted from
splitters after reload.
So what I called the 'interesting case' above never happens ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Help! DW function pointer encoding for PA
[not found] <no.id>
` (18 preceding siblings ...)
2002-01-30 17:36 ` condition codes, haifa-sched and virtual-stack-vars Ulrich Weigand
@ 2002-02-21 13:31 ` John David Anglin
2002-02-21 19:28 ` David Edelsohn
2002-04-05 12:45 ` middle-end/6180: Infinite loop in cc1 during dbr pass John David Anglin
` (23 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2002-02-21 13:31 UTC (permalink / raw)
To: John David Anglin; +Cc: rth, gcc
> I'll have to look more carefully at the ia64. I think I see what
> ia64_expand_call is doing to handle the function descriptor vs FDE
> issue:
It appears that the PA has a serious problem in its handling of function
descriptors. This small test program demonstrates the problem:
int f (int (*func)(void)) { func(); }
int main (void);
int (*i)(void) = &main;
int main() { f (i); f (main); }
This is the assembly output showing how the plabels for the two calls
in main are treated:
addil LR'i-$global$,%r27
ldw RR'i-$global$(%r1),%r26
.CALL ARGW0=GR
bl f,%r2
nop
ldil LR'L$C0000,%r19
ldw RR'L$C0000(%r19),%r26
.CALL ARGW0=GR
bl f,%r2
nop
As can be seen, the call using plabel "i" is handled correctly. However,
for the plabel L$C0000 used in the second call, we are in fact loading the
address of the function from the descriptor rather than the address of the
descriptor. Thus, indirect calls where the pic register changes value won't
work. I don't know how this went unnoticed for so long.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: middle-end/6180: Infinite loop in cc1 during dbr pass
[not found] <no.id>
` (19 preceding siblings ...)
2002-02-21 13:31 ` Help! DW function pointer encoding for PA John David Anglin
@ 2002-04-05 12:45 ` John David Anglin
2002-04-05 13:54 ` Richard Henderson
2002-04-10 15:30 ` gcc-64 on HP-UX 11.00 John David Anglin
` (22 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2002-04-05 12:45 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc-bugs, gcc, rth
> in an indeterminate position. reposition_prologue_and_epilogue_notes
> moves the epilogue begin note before the sequence. However, in
> fixing the insn chain, it apparently doesn't check for a sequence
> and the chain is left in a corrupt state. In particular, it doesn't
> touch the numbering inside the sequence.
reposition_prologue_and_epilogue_notes uses reorder_insns. The comments
for reorder_insns_nobb indicate that it doesn't know about sequences
and it looks like the same is true for reorder_insns. Thus, it can't
be used at this point.
Do we actually need to call reposition_prologue_and_epilogue_notes
at this point?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: middle-end/6180: Infinite loop in cc1 during dbr pass
2002-04-05 12:45 ` middle-end/6180: Infinite loop in cc1 during dbr pass John David Anglin
@ 2002-04-05 13:54 ` Richard Henderson
2002-04-06 12:58 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Richard Henderson @ 2002-04-05 13:54 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc-bugs, gcc
On Fri, Apr 05, 2002 at 02:54:08PM -0500, John David Anglin wrote:
> Do we actually need to call reposition_prologue_and_epilogue_notes
> at this point?
Dunno. Probably not.
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: middle-end/6180: Infinite loop in cc1 during dbr pass
2002-04-05 13:54 ` Richard Henderson
@ 2002-04-06 12:58 ` John David Anglin
2002-04-06 14:51 ` Richard Henderson
0 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2002-04-06 12:58 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc-bugs, gcc, gcc-patches
> On Fri, Apr 05, 2002 at 02:54:08PM -0500, John David Anglin wrote:
> > Do we actually need to call reposition_prologue_and_epilogue_notes
> > at this point?
My conclusion is that we can't reposition prologue and epilogue notes
at this point in dbr_schedule because the above function can't handle
sequences. Further, the exact end and start of the prologue and
epilogue, respectively, is indeterminant. Thus, I propose that the
notes not be repositioned.
I have confirmed that the enclosed patch fixes the compilation problem
of nm.c under hppa-linux. I have bootstrapped and checked that there
are no regressions with this patch under hppa-linux and
hppa2.0w-hp-hpux11.11.
The compilation failure of nm.c is a regression from 3.0.x. OK for
trunk and 3.1 branch?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2002-04-06 John David Anglin <dave@hiauly1.hia.nrc.ca>
* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.
Index: reorg.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reorg.c,v
retrieving revision 1.70
diff -u -3 -p -r1.70 reorg.c
--- reorg.c 31 Mar 2002 18:45:21 -0000 1.70
+++ reorg.c 6 Apr 2002 02:18:27 -0000
@@ -3686,10 +3686,6 @@ dbr_schedule (first, file)
/* It is not clear why the line below is needed, but it does seem to be. */
unfilled_firstobj = (rtx *) obstack_alloc (&unfilled_slots_obstack, 0);
- /* Reposition the prologue and epilogue notes in case we moved the
- prologue/epilogue insns. */
- reposition_prologue_and_epilogue_notes (first);
-
if (file)
{
int i, j, need_comma;
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] <no.id>
` (20 preceding siblings ...)
2002-04-05 12:45 ` middle-end/6180: Infinite loop in cc1 during dbr pass John David Anglin
@ 2002-04-10 15:30 ` John David Anglin
2002-04-11 10:25 ` John David Anglin
` (21 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-04-10 15:30 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
> > The latest 'snapshot' as in gcc-20020408.tar.bz2
>
> I'll try the current cvs.
I don't get the warnings or the seg fault. Have you got a recent header
and libc patch installed on your system? I have PHCO_23963 and PHCO_25707.
You will need to figure out where the warnings are coming from by looking at
the cpp output.
Some of the warnings seem to be from the macro definition for obstack_free
in include/obstack.h. The cast to int might be a problem on hppa64
# if defined __STDC__ && __STDC__
# define obstack_free(h,obj) \
( (h)->temp = (char *) (obj) - (char *) (h)->chunk, \
(((h)->temp > 0 && (h)->temp < (h)->chunk_limit - (char *) (h)->chunk)\
? (int) ((h)->next_free = (h)->object_base \
= (h)->temp + (char *) (h)->chunk) \
: (((obstack_free) ((h), (h)->temp + (char *) (h)->chunk), 0), 0)))
since pointers are 64bit and ints 32bit. This is probably not the problem
since the function version of obstack_free returns void.
What version of cc do you have?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] <no.id>
` (21 preceding siblings ...)
2002-04-10 15:30 ` gcc-64 on HP-UX 11.00 John David Anglin
@ 2002-04-11 10:25 ` John David Anglin
2002-04-11 10:43 ` H.Merijn Brand
2002-04-11 11:04 ` law
2002-04-15 13:39 ` John David Anglin
` (20 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2002-04-11 10:25 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc, law
> In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin
> " writes:
> > Gcc doesn't generate inline plabels on the PA. It would save one insn
> > and one data location if we could use these selectors. However, there
> > have been problems with them in 32bit land for years. I think the
> > current assembler can handle them but the SOM linker still doesn't
> > handle them.
> Actually the SOM linker can handle them, but there are corner cases with
> very large executables where it's impossible for the SOM linker to properly
> fixup an inline plabel. For that reason we stopped using them based on
> a recommendation from HP.
Interesting. The problem might be in the dynamic loader. In the research
I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>,
I tried using inline plabels with both the HP and GNU assembler/linkers
since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably
simpler. The HP assembler/linker compiled my little test PIC program
with inline plabels. However, when I executed it, the address loaded was
not the address of a function descriptor for the thunk target function.
GAS didn't like the LTP/RTP selectors at all. Thus, I was forced to create
a plabel in the data section. It was a bit tricky to do this in a manner
that was compatible with both hpux and linux.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 10:25 ` John David Anglin
@ 2002-04-11 10:43 ` H.Merijn Brand
2002-04-11 11:04 ` law
1 sibling, 0 replies; 175+ messages in thread
From: H.Merijn Brand @ 2002-04-11 10:43 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, law
On Thu 11 Apr 2002 19:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin
> > " writes:
> > > Gcc doesn't generate inline plabels on the PA. It would save one insn
> > > and one data location if we could use these selectors. However, there
> > > have been problems with them in 32bit land for years. I think the
> > > current assembler can handle them but the SOM linker still doesn't
> > > handle them.
> > Actually the SOM linker can handle them, but there are corner cases with
> > very large executables where it's impossible for the SOM linker to properly
> > fixup an inline plabel. For that reason we stopped using them based on
> > a recommendation from HP.
>
> Interesting. The problem might be in the dynamic loader. In the research
> I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>,
> I tried using inline plabels with both the HP and GNU assembler/linkers
> since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably
> simpler. The HP assembler/linker compiled my little test PIC program
> with inline plabels. However, when I executed it, the address loaded was
> not the address of a function descriptor for the thunk target function.
> GAS didn't like the LTP/RTP selectors at all. Thus, I was forced to create
> a plabel in the data section. It was a bit tricky to do this in a manner
> that was compatible with both hpux and linux.
I'm off now. If you want me to do more tests, please leave instructions on the
door when you leave. No problems with downloading another source tree, as long
as it is http https or ftp
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 10:25 ` John David Anglin
2002-04-11 10:43 ` H.Merijn Brand
@ 2002-04-11 11:04 ` law
1 sibling, 0 replies; 175+ messages in thread
From: law @ 2002-04-11 11:04 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
In message <200204111714.g3BHEf2h000643@hiauly1.hia.nrc.ca>, "John David
Anglin" writes:
> Interesting. The problem might be in the dynamic loader.
It was definitely the linker. If I recall correctly the problem was related
to the need for the linker to rewrite the inline plabel sequence when the
plabel
was satisfied from a shared library with an insanely large PLT.
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] <no.id>
` (22 preceding siblings ...)
2002-04-11 10:25 ` John David Anglin
@ 2002-04-15 13:39 ` John David Anglin
2002-04-16 13:14 ` law
2002-11-13 3:37 ` gcc-64 20021111 broken " H.Merijn Brand
2002-04-26 10:43 ` bison 1.33 problem with mainline c-parse.in: yyfree_stacks John David Anglin
` (19 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2002-04-15 13:39 UTC (permalink / raw)
To: John David Anglin; +Cc: law, h.m.brand, gcc
> However, the code from the actual perl function looks like:
>
> cmpib,= 0,%r3,L$1012
> addil LT'PL_sv_no,%r27
> addil LT'PL_sv_yes,%r27
> b L$1013
> fldd RT'PL_sv_yes(%r1),%fr22
> L$1012
> fldd RT'PL_sv_no(%r1),%fr22
> L$1013
> fstd %fr22,-272(%r30)
> b L$0783
> ldd -272(%r30),%r25
> [...]
> L$1017
> copy %r28,%r25
> L$0783
> copy %r25,%r28
> [restore registers and return]
I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is:
cmpib,= 0,%r28,L$0940
addil LT'PL_sv_yes,%r19
b L$0733
ldw RT'PL_sv_yes(%r1),%r28
L$0940
addil LT'PL_sv_no,%r19
b L$0733
ldw RT'PL_sv_no(%r1),%r28
So, this worked with 3.0.3 and we have a regression.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-15 13:39 ` John David Anglin
@ 2002-04-16 13:14 ` law
2002-04-16 15:25 ` John David Anglin
2002-11-13 3:37 ` gcc-64 20021111 broken " H.Merijn Brand
1 sibling, 1 reply; 175+ messages in thread
From: law @ 2002-04-16 13:14 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
In message <200204152027.g3FKRLuZ009642@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
> > However, the code from the actual perl function looks like:
> >
> > cmpib,= 0,%r3,L$1012
> > addil LT'PL_sv_no,%r27
> > addil LT'PL_sv_yes,%r27
> > b L$1013
> > fldd RT'PL_sv_yes(%r1),%fr22
> > L$1012
> > fldd RT'PL_sv_no(%r1),%fr22
> > L$1013
> > fstd %fr22,-272(%r30)
> > b L$0783
> > ldd -272(%r30),%r25
> > [...]
> > L$1017
> > copy %r28,%r25
> > L$0783
> > copy %r25,%r28
> > [restore registers and return]
>
> I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is:
>
> cmpib,= 0,%r28,L$0940
> addil LT'PL_sv_yes,%r19
> b L$0733
> ldw RT'PL_sv_yes(%r1),%r28
> L$0940
> addil LT'PL_sv_no,%r19
> b L$0733
> ldw RT'PL_sv_no(%r1),%r28
>
> So, this worked with 3.0.3 and we have a regression.
I don't doubt that it worked in the past. My point is that selecting an
FP register to hold an address like this is an exceedingly bad thing to
do. In fact, not assigning the value to a register and instead leaving it
in memory is actually cheaper than assigning it to an FP register.
In fact, from the fragments, it looks like we did something insanely stupid,
why don't we assign the value to %r28 or %r25?
jeff
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-16 13:14 ` law
@ 2002-04-16 15:25 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-04-16 15:25 UTC (permalink / raw)
To: law; +Cc: h.m.brand, gcc
> I don't doubt that it worked in the past. My point is that selecting an
My point in looking at whether it worked in the past was simply to determine
whether this was in fact a regression, and whether a fix could be applied
to the 3.1 branch.
> FP register to hold an address like this is an exceedingly bad thing to
> do. In fact, not assigning the value to a register and instead leaving it
> in memory is actually cheaper than assigning it to an FP register.
I don't quite follow that logic. Two insns are needed to load the
address and the result must end up in a register. You can't load
the address directly to memory. It takes a couple of insns to copy
the result from the FP register to a general register. Generally,
I guess this must be weighed against the cost of freeing up a general
general.
> In fact, from the fragments, it looks like we did something insanely stupid,
> why don't we assign the value to %r28 or %r25?
I agree it seems very dumb. We have the following rtl at the end of
function after lreg:
(insn 3088 3494 3091 (set (reg/i:DI 28 %r28)
(reg/f:DI 66)) 119 {*pa.md:3106} (nil)
(expr_list:REG_DEAD (reg/f:DI 66)
(nil)))
DI 66 is set in multiple places. It seems the compiler doesn't
recognize opportunities to replace DI 66 with DI 28, and so on.
Jeff, I will send you gv.i offline so that you can look at the problem
in more detail.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* gcc-64 20021111 broken on HP-UX 11.00
2002-04-15 13:39 ` John David Anglin
2002-04-16 13:14 ` law
@ 2002-11-13 3:37 ` H.Merijn Brand
2002-11-13 5:38 ` H.Merijn Brand
2002-11-13 8:30 ` John David Anglin
1 sibling, 2 replies; 175+ messages in thread
From: H.Merijn Brand @ 2002-11-13 3:37 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc
2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
FWIW 32bit version worked perfect
I'll try to rebuild gcc64 from scratch without using the 20021104 vs
a5:/pro/3gl/GNU/gcc 113 > ll -d src gcc-*
38813 drwxrwxrwx 17 merijn softwr 2048 Nov 12 18:38 gcc-20021111
33464 -rw-r--r-- 1 merijn softwr 20243290 Nov 12 13:24 gcc-20021111.tbz
33916 lrwxrwxrwx 1 merijn softwr 12 Nov 12 18:38 src -> gcc-20021111
a5:/pro/3gl/GNU/gcc 114 > cat Conf-gcc64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="gcc64 -mpa-risc-2-0"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
rm -rf obj
mkdir obj
cd obj
../src/configure \
--enable-languages=c,c++ \
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
--with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \
--disable-shared \
--disable-nls \
--host=hppa64-hp-hpux11.00
echo ""
echo "Now start 'Build-gcc64'"
a5:/pro/3gl/GNU/gcc 115 > gcc64 --version
gcc64 (GCC) 3.3 20021104 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
a5:/pro/3gl/GNU/gcc 116 > sh -x Conf-gcc64
+ export CONFIG_SITE=
+ export CC=gcc64 -mpa-risc-2-0
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin:/opt/imake/bin
+ rm -rf obj
+ mkdir obj
+ cd obj
+ ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as
--with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host
=hppa64-hp-hpux11.00
*** This configuration is not supported in the following subdirectories:
target-libffi target-boehm-gc target-zlib target-libjava target-libf2c zlib fastjar target-libobjc
(Any other directories should still work fine.)
Created "Makefile" in /pro/3gl/GNU/gcc/obj using "mh-frag"
ldd: "conftest" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
*** The command 'gcc64 -mpa-risc-2-0 -o conftest -g conftest.c' failed.
*** You must set the environment variable CC to a working compiler.
+ echo
+ echo Now start 'Build-gcc64'
Now start 'Build-gcc64'
a5:/pro/3gl/GNU/gcc 117 > gcc --version
gcc (GCC) 3.3 20021111 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
a5:/pro/3gl/GNU/gcc 118 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 20021111 broken on HP-UX 11.00
2002-11-13 3:37 ` gcc-64 20021111 broken " H.Merijn Brand
@ 2002-11-13 5:38 ` H.Merijn Brand
2002-11-13 8:31 ` John David Anglin
2002-11-13 13:12 ` John David Anglin
2002-11-13 8:30 ` John David Anglin
1 sibling, 2 replies; 175+ messages in thread
From: H.Merijn Brand @ 2002-11-13 5:38 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc
On Wed 13 Nov 2002 11:24, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:
> 2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
> FWIW 32bit version worked perfect
>
> I'll try to rebuild gcc64 from scratch without using the 20021104 vs
That succeeded. Installed OK. Now use that to rebuild gcc64:
` if [ -f /pro/3gl/GNU/gcc/obj/gcc/../binutils/ranlib ] ; then echo /pro/3gl/GNU/gcc/obj/gcc/../binutils/ranlib ; else if [ "hppa64-hp-hpux11.00" = "hppa64-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa64-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` stage1/libgcc_eh.a; \
else true; fi; fi
for f in .. ; do if [ x${f} != x.. ]; then \
cp stage1/${f} . ; \
else true; \
fi; done
mv cp/*.o stage1/cp
mv: cp/*.o: cannot access: No such file or directory
make[2]: [c++.stage1] Error 1 (ignored)
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
echo timestamp > stage1_copy
echo stage2_build > stage_last
(cd stage1 && rm -f `echo main.o libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgrtl.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o gtype-desc.o haifa-sched.o hashtable.o hooks.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o ra.o ra-build.o ra-colorize.o ra-debug.o ra-rewrite.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tracer.o tree.o tree-dump.o tree-inline.o unroll.o varasm.o varray.o version.o vmsdbgout.o xcoffout.o et-forest.o ggc-page.o pa.o c-parse.o c-lang.o c-pretty-print.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-objc-common.o c-dump.o libcpp.a cpplib.o cpplex.o cppmacro.o cppexp.o cppfiles.o cpptrad.o cpphash.o cpperror.o cppinit.o cppdefault.o cppmain.o hashtable.o line-map.o mkdeps.o prefix.o mbchar.o *.c *.h gen*`)
echo timestamp > clean_s1
make CC=" stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/" \
STAGE_PREFIX=stage1/ \
ADAC="\$(CC)" CFLAGS="-g -O2" LDFLAGS="" WARN_CFLAGS="\$(GCC_WARN_CFLAGS)" STRICT_WARN="-Wtraditional -pedantic -Wno-long-long" libdir=/usr/local/pa20_64/lib LANGUAGES="c gcov c++" MAKEOVERRIDES= OUTPUT_OPTION="-o \$@"
make[2]: Entering directory `/pro/3gl/GNU/gcc/obj/gcc'
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include ../../src/gcc/gengenrtl.c -o gengenrtl.o
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o gengenrtl \
gengenrtl.o ../libiberty/libiberty.a
ldd: "gengenrtl" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
make[2]: *** [gengenrtl] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make: *** [bootstrap-lean] Error 2
Exit 2
a5:/pro/3gl/GNU/gcc 131 > gcc64 --version
gcc64 (GCC) 3.3 20021111 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
a5:/pro/3gl/GNU/gcc 132 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 20021111 broken on HP-UX 11.00
2002-11-13 5:38 ` H.Merijn Brand
@ 2002-11-13 8:31 ` John David Anglin
2002-11-13 13:12 ` John David Anglin
1 sibling, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-11-13 8:31 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: law, gcc
> ldd: "gengenrtl" is not a shared executable.
This is in fact a GNU ld bug. If you use chatr, you will see that gengenrtl
is an incomplete executable and has dependencies on shared libraries.
ldd should list the dependent shared libraries. It does if you build using
the HP linker.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 20021111 broken on HP-UX 11.00
2002-11-13 5:38 ` H.Merijn Brand
2002-11-13 8:31 ` John David Anglin
@ 2002-11-13 13:12 ` John David Anglin
2002-11-15 9:54 ` H.Merijn Brand
1 sibling, 1 reply; 175+ messages in thread
From: John David Anglin @ 2002-11-13 13:12 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: law, gcc, gcc-patches
> ldd: "gengenrtl" is not a shared executable.
> collect2: /usr/ccs/bin/ldd returned 1 exit status
I have installed the patch below and it should fix the above problem.
However, we are back to the previous situation where global constructors
and destructors in dependent libraries are not executed. This causes
a variety of regressions when the HP linker was being used. For example,
objc is essentially unusable and g++ is compromised. This of course
is also the state with GNU ld.
If you use the HP linker, LD_INIT_SWITCH and LD_FINI_SWITCH can be
defined as shown below and this results in GCC testsuite results
fairly comparable to that of the 32-bit ports. You can even enable
the building of a shared libgcc in config.gcc.
Unfortunately, LD_INIT_SWITCH and LD_FINI_SWITCH can't be defined
with the GNU linker without other nasty things happening. As far
as I can tell, there is no way to define these symbols without
making the GCC code linker dependent. I don't think we want to
do this at this time, so I have disabled the above two macros.
Hopefully, the GNU ld bugs can be fixed in the near future and we
can use the above macros, or possibly .init and .fini sections.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2002-11-13 John David Anglin <dave@hiauly1.hia.nrc.ca>
* pa64-hpux.h (LINK_SPEC): Move "+Accept TypeMismatch" switch to the
beginning of the spec.
(LDD_SUFFIX, PARSE_LDD_OUTPUT): Delete.
(LD_INIT_SWITCH, LD_FINI_SWITCH): Define but don't enable. Add comment
regarding problems with global constructors when using GNU ld.
Index: config/pa/pa64-hpux.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa64-hpux.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 pa64-hpux.h
--- config/pa/pa64-hpux.h 10 Nov 2002 01:14:47 -0000 1.18
+++ config/pa/pa64-hpux.h 13 Nov 2002 17:12:03 -0000
@@ -31,14 +31,16 @@ Boston, MA 02111-1307, USA. */
N_("Assume code will be linked by HP ld") },
/* We can debug dynamically linked executables on hpux11; we also
- want dereferencing of a NULL pointer to cause a SEGV. */
+ want dereferencing of a NULL pointer to cause a SEGV. Do not move
+ the "+Accept TypeMismatch" switch. We check for it in collect2
+ to determine which init/fini is needed. */
#undef LINK_SPEC
#if ((TARGET_DEFAULT | TARGET_CPU_DEFAULT) & MASK_GNU_LD)
#define LINK_SPEC \
- "-E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}} %{mhp-ld:+Accept TypeMismatch}"
+ "%{mhp-ld:+Accept TypeMismatch} -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}}"
#else
#define LINK_SPEC \
- "-E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}} %{!mgnu-ld:+Accept TypeMismatch}"
+ "%{!mgnu-ld:+Accept TypeMismatch} -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}}"
#endif
/* Like the default, except no -lg. */
@@ -252,19 +254,26 @@ do { \
/* Since we are not yet using .init and .fini sections, we need to
explicitly arrange to run the global constructors and destructors.
- HPUX 11 has ldd and we use it to determine the dependencies of
- dynamic objects. It might be possible to use the ld options for
- running initializers and terminators and thereby avoid the necessity
- of running ldd, but unfortunately the options are different for
- the two linkers. */
-#define LDD_SUFFIX "/usr/ccs/bin/ldd"
-
-/* Skip to first '>' then advance to '/' at the beginning of the filename. */
-#define PARSE_LDD_OUTPUT(PTR) \
-do { \
- while (*PTR != '>') PTR++; \
- while (*PTR != '/') PTR++; \
-} while (0)
+ We could use ldd for this but it depends on LD_LIBRARY_PATH being
+ correctly set. So, we use the ld init and fini switches. However,
+ we need to support different switches for the GNU and HP linkers.
+ We can't check TARGET_GNU_LD in collect2, so we need a different
+ test. The +Accept switch is always the first switch when we are
+ using the HP linker (see define for LINK_SPEC). Checking for it
+ is a somewhat fragile as it depends on internal details of the
+ collect2 program but it is better than testing ld_file_name.
+
+ FIXME: The GNU linker is broken. The -init/-fini switches don't
+ work and ldd can't determine the dynamic dependences of executables
+ linked with GNU ld. The init and fini routines are not executed
+ although DT_INIT and DT_FINI appear ok. As a result, defining
+ LD_INIT_SWITCH and LD_FINI_SWITCH causes more harm than good when
+ using GNU ld. However, the definitions appear to work fine with
+ the HP linker. */
+#if 0
+#define LD_INIT_SWITCH (strcmp ("+Accept", ld2_argv[1]) ? "-init" : "+init")
+#define LD_FINI_SWITCH (strcmp ("+Accept", ld2_argv[1]) ? "-fini" : "+fini")
+#endif
/* If using HP ld do not call pxdb. Use size as a program that does nothing
and returns 0. /bin/true cannot be used because it is a script without
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 20021111 broken on HP-UX 11.00
2002-11-13 13:12 ` John David Anglin
@ 2002-11-15 9:54 ` H.Merijn Brand
0 siblings, 0 replies; 175+ messages in thread
From: H.Merijn Brand @ 2002-11-15 9:54 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc, gcc-patches
On Wed 13 Nov 2002 22:04, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > ldd: "gengenrtl" is not a shared executable.
> > collect2: /usr/ccs/bin/ldd returned 1 exit status
>
> I have installed the patch below and it should fix the above problem.
Confirm. Now works for gcc64.
> However, we are back to the previous situation where global constructors
> and destructors in dependent libraries are not executed. This causes
> a variety of regressions when the HP linker was being used. For example,
> objc is essentially unusable and g++ is compromised. This of course
> is also the state with GNU ld.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 20021111 broken on HP-UX 11.00
2002-11-13 3:37 ` gcc-64 20021111 broken " H.Merijn Brand
2002-11-13 5:38 ` H.Merijn Brand
@ 2002-11-13 8:30 ` John David Anglin
1 sibling, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-11-13 8:30 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: law, gcc
> 2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
> FWIW 32bit version worked perfect
Sigh, I know. I am testing a "fix". However, the problem is really
GNU ld is broken. Using HP ld should work fine.
I tried to fix the fact that constructors are not being collected
from dependent shared libraries. Unfortunately, I missed testing
with GNU ld as I was mainly concerned about assembler issues.
This is what ld reports for any executable (not shared libraries)
bash-2.05a$ ldd cc1
ldd: "cc1" is not a shared executable.
I must admit that I first noted a problem using ldd to find
dependencies when I tried a bootstrap with the HP linker and a shared
libgcc. The problem is LD_LIBRARY_PATH needs to be set correctly
for it to work and this is problematic when building packages
with shared libraries.
Basically, we have to back out from trying to search dependencies
for global constructors until GNU ld is fixed. This leaves using
shared libraries with constructors broken (various v3, g++ and objc
testsuite fails are caused by this).
I tested an alternative approach using the +init/+fini switches
with the HP linker. This works fine and I was sucessful building
gcc with a shared libgcc with no regressions. However, with
the GNU linker, we hit another bug. The init and fini routines are
not called although DT_INIT and DT_FINI look ok. The result of this
is worse than not doing the dependency search, so we are in dammed
if we do and dammed if we don't situation.
Anyhow, either use the HP linker or "--disable-shared" for the moment.
I will install a patch later today to restore the previous behavior.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: bison 1.33 problem with mainline c-parse.in: yyfree_stacks
[not found] <no.id>
` (23 preceding siblings ...)
2002-04-15 13:39 ` John David Anglin
@ 2002-04-26 10:43 ` John David Anglin
2002-05-11 20:28 ` corrections to recent profile-arcs change John David Anglin
` (18 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-04-26 10:43 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, mec
> > /berman/migchain/install/native/bison-1.33/share/bison/bison.simple: In function `yyparse':
> > /berman/migchain/install/native/bison-1.33/share/bison/bison.simple:521: `yyfree_stacks' undeclared (first use in this function)
It looks like this incompatibility was introduced by this patch:
2002-04-25 Richard Henderson <rth@redhat.com>
PR c/2161
* c-parse.in (yyoverflow): New.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: corrections to recent profile-arcs change
[not found] <no.id>
` (24 preceding siblings ...)
2002-04-26 10:43 ` bison 1.33 problem with mainline c-parse.in: yyfree_stacks John David Anglin
@ 2002-05-11 20:28 ` John David Anglin
2002-06-01 17:01 ` vax double precision broken Joe Buck
` (17 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-05-11 20:28 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, rth
> FAIL: g++.dg/bprob/bprob-1.C compilation, -O2 -fprofile-arcs
This one a SIGSEGV:
(gdb) r -fprofile-arcs -O2 bprob-1.ii
...
Program received signal SIGSEGV, Segmentation fault.
0x0010c574 in ok_to_generate_alias_set_for_type (t=0x402dda10)
at ../../gcc/gcc/cp/cp-lang.c:214
214 if (! CLASSTYPE_NON_POD_P(t))
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: vax double precision broken
[not found] <no.id>
` (25 preceding siblings ...)
2002-05-11 20:28 ` corrections to recent profile-arcs change John David Anglin
@ 2002-06-01 17:01 ` Joe Buck
2002-07-11 6:34 ` Bootstrapping hppa64? CPP problem John David Anglin
` (16 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: Joe Buck @ 2002-06-01 17:01 UTC (permalink / raw)
To: Paul Koning; +Cc: gcc
> The single and double IEEE formats do indeed look similar to VAX F and
> G formats respectively, but they do NOT match. There are three key
> differences: the halfwords are in the opposite order (sign bit is bit
> 31 in each case for IEEE); the exponent bias is one less -- 127 and
> 1023 for IEEE vs. 128 and 1024 for VAX; and the hidden high order bit
> is interpreted as the bit just to the left of the binary point (2**0)
> in IEEE rather than just to the right (2**-1) as in VAX. (In
> addition, IEEE has both Inf and NaN, while DEC format only has NaN.
> And IEEE has denormals; DEC does not.)
There's a 4th difference: F-floating has the same exponent size as IEEE
single precision, but D-floating has the same number of exponent bits
as F-floating while IEEE doubles have more exponent bits. (Conversion
from Vax-D to Vax-F is a simple matter of rounding off the mantissa, while
for IEEE, overflow can occur because the double precision type has greater
range).
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Bootstrapping hppa64? CPP problem
[not found] <no.id>
` (26 preceding siblings ...)
2002-06-01 17:01 ` vax double precision broken Joe Buck
@ 2002-07-11 6:34 ` John David Anglin
2002-07-16 13:21 ` [parisc-linux] gcc-3.[02] alignment problem John David Anglin
` (15 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-07-11 6:34 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, sje
> > I am curious if anyone is currently bootstrapping the hppa64 GCC
> > compiler from the latest sources? I am running into a very curious cpp
> > problem. With the attached example, using the cc1 that I just built I
> > get two definitions of sigpause showing up because _SVID2 seems to be
> > considered defined and undefined at the same time. It doesn't happen on
> > the other platforms I have tried but it happens consistenly for me on
> > PA64.
I am currently bootstrapping the latest sources for 3.1.1 and 3.2.
3.2 is now in stage2 and doesn't exhibit the problem described, so I
expect that you have a problem with your tools.
There have been a fair number of changes to binutils affecting hppa64
in the last month or so. I suggest you rebuild them. The only unexpected
errors should be 7 in the ld suite. Then, I suggest that you build
3.1.1 starting with either the HP builtin or ANSI compiler. You should
be able to build 3.2 starting with the HP ANSI compiler. I'm using
3.1.1 as my default for hppa64 builds.
I will let you know if the problem that you describe appears later
in the build process.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [parisc-linux] gcc-3.[02] alignment problem
[not found] <no.id>
` (27 preceding siblings ...)
2002-07-11 6:34 ` Bootstrapping hppa64? CPP problem John David Anglin
@ 2002-07-16 13:21 ` John David Anglin
2002-07-16 13:43 ` Randolph Chung
2002-07-26 20:16 ` mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8 John David Anglin
` (14 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2002-07-16 13:21 UTC (permalink / raw)
To: John David Anglin; +Cc: randolph, parisc-linux, gcc
> These messages are coming from the assembler (remove "-pipe"). The
> first is from "std %r4,44(%r3)". The offset "44" is not correct for
> a store double. This is probably a problem with pointer arithmetic
> in the source.
Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [parisc-linux] gcc-3.[02] alignment problem
2002-07-16 13:21 ` [parisc-linux] gcc-3.[02] alignment problem John David Anglin
@ 2002-07-16 13:43 ` Randolph Chung
2002-07-16 13:45 ` Matthew Wilcox
2002-07-16 14:26 ` Richard Henderson
0 siblings, 2 replies; 175+ messages in thread
From: Randolph Chung @ 2002-07-16 13:43 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux, gcc
In reference to a message from John David Anglin, dated Jul 16:
> > These messages are coming from the assembler (remove "-pipe"). The
> > first is from "std %r4,44(%r3)". The offset "44" is not correct for
> > a store double. This is probably a problem with pointer arithmetic
> > in the source.
>
> Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.
ah, this is not it, but i see what it is now.
include/linux/tcp_diag.h defines:
struct tcpdiag_sockid
{
__u16 tcpdiag_sport;
__u16 tcpdiag_dport;
__u32 tcpdiag_src[4];
__u32 tcpdiag_dst[4];
__u32 tcpdiag_if;
__u32 tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};
the code goes on to do:
*((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))
even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't....
the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:
struct tcpdiag_sockid
{
__u16 tcpdiag_sport;
__u16 tcpdiag_dport;
__u32 tcpdiag_src[4];
__u32 tcpdiag_dst[4];
__u32 tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
char * parisc_hack_to_align_tcpdiag_cookie;
#endif
__u32 tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};
why is the offset of tcpdiag_cookie[0] 44 and not 40?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [parisc-linux] gcc-3.[02] alignment problem
2002-07-16 13:43 ` Randolph Chung
@ 2002-07-16 13:45 ` Matthew Wilcox
2002-07-17 5:26 ` Randolph Chung
2002-07-16 14:26 ` Richard Henderson
1 sibling, 1 reply; 175+ messages in thread
From: Matthew Wilcox @ 2002-07-16 13:45 UTC (permalink / raw)
To: Randolph Chung; +Cc: John David Anglin, parisc-linux, gcc
On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> include/linux/tcp_diag.h defines:
>
> struct tcpdiag_sockid
> {
> __u16 tcpdiag_sport;
> __u16 tcpdiag_dport;
> __u32 tcpdiag_src[4];
> __u32 tcpdiag_dst[4];
> __u32 tcpdiag_if;
> __u32 tcpdiag_cookie[2];
> #define TCPDIAG_NOCOOKIE (~0U)
> };
> why is the offset of tcpdiag_cookie[0] 44 and not 40?
0 tcpdiag_sport
2 tcpdiag_dport
4 tcpdiag_src
20 tcpdiag_dst
36 tcpdiag_if
40 tcpdiag_cookie
hmm.. worth checking that dport is at offset 2, not offset 4?
--
Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [parisc-linux] gcc-3.[02] alignment problem
2002-07-16 13:45 ` Matthew Wilcox
@ 2002-07-17 5:26 ` Randolph Chung
0 siblings, 0 replies; 175+ messages in thread
From: Randolph Chung @ 2002-07-17 5:26 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: John David Anglin, parisc-linux, gcc
> > why is the offset of tcpdiag_cookie[0] 44 and not 40?
>
> 0 tcpdiag_sport
> 2 tcpdiag_dport
> 4 tcpdiag_src
> 20 tcpdiag_dst
> 36 tcpdiag_if
> 40 tcpdiag_cookie
>
> hmm.. worth checking that dport is at offset 2, not offset 4?
oic, it's embedded inside another structure:
struct tcpdiagmsg
{
__u8 tcpdiag_family;
__u8 tcpdiag_state;
__u8 tcpdiag_timer;
__u8 tcpdiag_retrans;
struct tcpdiag_sockid id;
__u32 tcpdiag_expires;
__u32 tcpdiag_rqueue;
__u32 tcpdiag_wqueue;
__u32 tcpdiag_uid;
__u32 tcpdiag_inode;
};
that's why it's 44...
randolph
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [parisc-linux] gcc-3.[02] alignment problem
2002-07-16 13:43 ` Randolph Chung
2002-07-16 13:45 ` Matthew Wilcox
@ 2002-07-16 14:26 ` Richard Henderson
1 sibling, 0 replies; 175+ messages in thread
From: Richard Henderson @ 2002-07-16 14:26 UTC (permalink / raw)
To: Randolph Chung; +Cc: John David Anglin, parisc-linux, gcc
On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> __u32 tcpdiag_cookie[2];
> #define TCPDIAG_NOCOOKIE (~0U)
> };
>
> the code goes on to do:
> *((struct sock **)&r->id.tcpdiag_cookie) = sk;
> and
> sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))
This is absolutely awful.
> the "vomit grade hack" alan mentioned in another post is that in our
> tree, we have:
>
> struct tcpdiag_sockid
> {
> __u16 tcpdiag_sport;
> __u16 tcpdiag_dport;
> __u32 tcpdiag_src[4];
> __u32 tcpdiag_dst[4];
> __u32 tcpdiag_if;
> #if defined (__hppa__) && defined (__LP64__)
> char * parisc_hack_to_align_tcpdiag_cookie;
> #endif
> __u32 tcpdiag_cookie[2];
An only marginally better fix is
__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));
Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.
A much nicer fix would be to, gasp, use a union.
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8
[not found] <no.id>
` (28 preceding siblings ...)
2002-07-16 13:21 ` [parisc-linux] gcc-3.[02] alignment problem John David Anglin
@ 2002-07-26 20:16 ` John David Anglin
2002-07-27 18:50 ` Richard Henderson
2002-07-28 4:50 ` Richard Henderson
2002-08-01 12:02 ` gcc 3.2's cpp breaks configure scripts John David Anglin
` (13 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2002-07-26 20:16 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, rth, joern.rennecke, lucier
> > stage2/xgcc -Bstage2/ -B/home/c/lucier/local/gcc-test/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/bitmap.c -o bitmap.o
> > In file included from ../../gcc/system.h:171,
> > from ../../gcc/bitmap.c:22:
> > ../../gcc/hwint.h:39:9: warning: integer overflow in preprocessor expression
>
> A similar error occurs on hppa-linux near the end of stage2:
> <http://gcc.gnu.org/ml/gcc/2002-07/msg01238.html>.
The following patch appears to be the origin of the bootstrap failure
under hppa-linux:
2002-07-25 Richard Henderson <rth@redhat.com>
* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
in ARRAY_REF of DECL_P case.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8
2002-07-26 20:16 ` mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8 John David Anglin
@ 2002-07-27 18:50 ` Richard Henderson
2002-07-28 4:50 ` Richard Henderson
1 sibling, 0 replies; 175+ messages in thread
From: Richard Henderson @ 2002-07-27 18:50 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, joern.rennecke, lucier
On Fri, Jul 26, 2002 at 01:42:06PM -0400, John David Anglin wrote:
> > A similar error occurs on hppa-linux near the end of stage2:
> > <http://gcc.gnu.org/ml/gcc/2002-07/msg01238.html>.
>
> The following patch appears to be the origin of the bootstrap failure
> under hppa-linux:
>
> 2002-07-25 Richard Henderson <rth@redhat.com>
>
> * emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
> in ARRAY_REF of DECL_P case.
Surprising, to say the least, since I can only imagine problems
_without_ that patch, as evidenced by the SH problems it fixed.
If this is a stage2 failure, can you help me out by finding what
bit of stage1 got miscompiled?
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8
2002-07-26 20:16 ` mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8 John David Anglin
2002-07-27 18:50 ` Richard Henderson
@ 2002-07-28 4:50 ` Richard Henderson
2002-07-28 13:08 ` John David Anglin
2002-07-28 21:35 ` John David Anglin
1 sibling, 2 replies; 175+ messages in thread
From: Richard Henderson @ 2002-07-28 4:50 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, joern.rennecke, lucier
On Fri, Jul 26, 2002 at 01:42:06PM -0400, John David Anglin wrote:
> The following patch appears to be the origin of the bootstrap failure
> under hppa-linux:
>
> 2002-07-25 Richard Henderson <rth@redhat.com>
>
> * emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
> in ARRAY_REF of DECL_P case.
Please try
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc 3.2's cpp breaks configure scripts
[not found] <no.id>
` (29 preceding siblings ...)
2002-07-26 20:16 ` mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8 John David Anglin
@ 2002-08-01 12:02 ` John David Anglin
2002-10-08 16:26 ` soft-float support Graeme Peterson
` (12 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-08-01 12:02 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, tilps
> > Turning the warning off is not the correct solution, although there
> > may be some circumstances in which it is emitted when it shouldn't
> > be.
>
> I think so... but I am probably wrong hehe...
You can display the include search order with "gcc -v -E". The situation
where gcc emits the message when it shouldn't is when a user include directory
is specified and it is the same as the first directory searched by gcc.
For example,
gcc -v -E main.c -I/opt/gnu/include
...
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/opt/gnu/hppa2.0w-hp-hpux11.00/include"
cpp0: warning: changing search order for system directory "/opt/gnu/include"
cpp0: warning: as it has already been specified as a non-system directory
ignoring duplicate directory "/opt/gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/gnu/include
/opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
/usr/include
End of search list.
As can be seen, the search order hasn't really changed. If "-I/usr/include"
were added to the command, the search order would really have changed.
These are rules under which the macro lib-prefix.m4 used by configure
in textutils-2.1 adds include directories to CPPFLAGS:
dnl Potentially add $additional_includedir to $CPPFLAGS.
dnl But don't add it
dnl 1. if it's the standard /usr/include,
dnl 2. if it's already present in $CPPFLAGS,
dnl 3. if it's /usr/local/include and we are using GCC on Linux,
dnl 4. if it doesn't exist as a directory.
"/opt/gnu" is my standard prefix. As can be seen, the above macro
will add "-I/opt/gnu/include" to CPPFLAGS and cause a gcc warning
if something interesting is found there (e.g., libintl.h).
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: soft-float support
[not found] <no.id>
` (30 preceding siblings ...)
2002-08-01 12:02 ` gcc 3.2's cpp breaks configure scripts John David Anglin
@ 2002-10-08 16:26 ` Graeme Peterson
2002-11-13 14:19 ` gcc-64 20021111 broken on HP-UX 11.00 John David Anglin
` (11 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: Graeme Peterson @ 2002-10-08 16:26 UTC (permalink / raw)
To: Graeme Peterson; +Cc: Andrew Haley, gcc
This got it working. I also had to add:
# Do not build libgcc1.
LIBGCC1 =
CROSS_LIBGCC1 =
Thanks, all.
GP
>
> I dug a little and found this, which I copied from t-rs6000:
>
> LIB2FUNCS_EXTRA = fp-bit.c dp-bit.c tramp.S
>
> dp-bit.c: $(srcdir)/config/fp-bit.c
> cat $(srcdir)/config/fp-bit.c > dp-bit.c
>
> fp-bit.c: $(srcdir)/config/fp-bit.c
> echo '#define FLOAT' > fp-bit.c
> cat $(srcdir)/config/fp-bit.c >> fp-bit.c
>
> I'm building it now, but the comment at the top of fp-bit.c
> seems promising:
>
> "/* This is a software floating point library which can be used instead of
> the floating point routines in libgcc1.c for targets without hardware
> floating point. */ "
>
> Think that might be it? :-)
>
> GP
>
> >
> > Graeme Peterson writes:
> > > Hi, all.
> > >
> > > I have done some searching, and it seems that gcc (in this case
> > > 2.95.3 targetting ppc-QNX6) does not have support for statically
> > > linked software emulated floating point instructions.
> > >
> > > Can someone clarify for me what is required to get this going? Do
> > > I need to implement the floating point emulation and tell gcc to
> > > use it in place of the fadd in the __adddf3 call? If so, how do I
> > > do that?
> >
> > You need to specify the multilibs in your target file for qnx.
> >
> > For example, in the current gcc source, gcc/config/rs6000/t-rs6000
> > contains
> >
> > MULTILIB_OPTIONS = msoft-float
> > MULTILIB_DIRNAMES = soft-float
> >
> > Andrew.
> >
>
>
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: gcc-64 20021111 broken on HP-UX 11.00
[not found] <no.id>
` (31 preceding siblings ...)
2002-10-08 16:26 ` soft-float support Graeme Peterson
@ 2002-11-13 14:19 ` John David Anglin
2002-11-23 0:26 ` HP-UX IA64 Patch to fix earlier patch John David Anglin
` (10 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-11-13 14:19 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, law, gcc, gcc-patches
> > ldd: "gengenrtl" is not a shared executable.
> > collect2: /usr/ccs/bin/ldd returned 1 exit status
>
> I have installed the patch below and it should fix the above problem.
I forgot to say it was tested with both HP and GNU ld on hppa64-hp-hpux11.11.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: HP-UX IA64 Patch to fix earlier patch
[not found] <no.id>
` (32 preceding siblings ...)
2002-11-13 14:19 ` gcc-64 20021111 broken on HP-UX 11.00 John David Anglin
@ 2002-11-23 0:26 ` John David Anglin
2002-12-17 9:52 ` Setting LD tool default to ld breaks configure check for ld used by GCC John David Anglin
` (9 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-11-23 0:26 UTC (permalink / raw)
To: John David Anglin; +Cc: sje, gcc, wilson, law, rth
> > I am working on using the PARALLEL method for IA64 they way you did on
> > PA64 so we can get rid of FUNCTION_ARG_REG_LITTLE_ENDIAN and noticed
> > that on PA64 you use it in function_arg to handle arguments but there is
> > nothing to handle function return values and I think we need it there
> > too to handle returns of small structures.
>
> You are correct, PA64 GCC incorrectly returns small structs. I will
> try and see if I can detemine what is wrong with your patch.
There is a problem with using the PARALLEL method for function
values and sjlj exception handling. After a lot of C++ debugging, I
have determined why g++.robertl/eb21.C fails with the patch that
I have to return a PARALLEL.
The function _ZSt24__uninitialized_copy_auxIN9........ is miscompiled.
It returns a small structure in register %r28. The return value is output
by expand_value_return at insn 88 followed by a jump to label 162.
However, after code_label 162, we have a call to _Unwind_SjLj_Unregister
which clobbers the return value %r28. It would also clobber any
value in the other return register %r29.
The call to _Unwind_SjLj_Unregister obviously has to occur before
the return value is copied to the return registers but I am not sure
how to do this. I am not sure why this isn't a problem when we don't
use a PARALLEL. There is a bug in cfg.c that causes an ICE when
dumping rtl. The global max_regno is not always in sync with the
number of pseudos. I need to rebuild gcc with this fixed before
I can compare what happens without PARALLEL function values.
The rtl from the first jump pass is enclosed below.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
begin 640 eb21.jump.gz
M'XL(")6PWCT``V5B,C$N:G5M<`#M7'MOW+@1_]^?@@AZ0'QU$I%Z44Y;-(^]
MJQ'#R7D=H&U@"/N0[;VNI3U)ZR17]+MWAI)V)2U%2NO5>7/G%#TD*W+F-^2\
M1>KE2_+#,IRDLR@D_@]1_'D43T_2("9).CT^]OUE.`MGZ6PTG_T:3/U)M/CJ
MCY9?GOHGX6*9XL`C4OE[B03\R[\:S9/`3[\N@D/RZ?,LO2F-)G^%`=?ATI]\
M^8*LPBB^'<W]&3P:I5'\ETD4AH%`YJ??'V6`[N"'VJ/\R6@^CR8;\_Y&X']5
M6+\9V\N#`VI0$@?7LP2()\\/#L[SOQ/'(<LDF!)*TMEMD)#1)(Z2A!AD%B9A
M\I(D09H_>TFF,Q@P"^'A8CZ:!/#T[+U_/OAQ2**8A%$(0Q;1+`2R%0YNQH$I
M..3/6K"H4.;WP4[)^&NJX^#M<'7*A%VC[V5W:5_065^$S;X(6WT1MOLBO$NK
MK!#NS1C=>QFCBG!?-LAW:8,5PGV9'N_+]'A?IL>MOO2-W\OVK!;.G[N]<[B7
MS;3BX.UR_:6!QNO+C+Q=FI$<.NM+.[U=&I0<^RZ#FIS#+J.;G$/OR:?7NPU[
MNXQ[<AEV&0"E'*C15SI*(<L>);,)&4-U\I_DB%";!-/K`&N0U^L'Q#@F5[,X
M205#0AW[B,Q'\$_&CL@B#N[(,WI$PN`+P(`G4;3PI\$"BCCCB$RB99CB7Z[B
MX!=B/#_X$`?3`(`E49P<$S(XNSC_%WD*!>`\O8F7AP?#Y63]E):?%`N2D/GL
M+B"C%$JK49P>DZ?A;"Y['(33XN%)>`>UZ90DRUL279%HF5[#*EP#^F@\&L_F
M4+O"NAG/C>^JDM.*Y";-!3>=7'`CEYMUE=N"'6J2FI6>$$Z>CL9'H_$$?CD*
M;AYF&5A-`=QB';Q\'8K]-[NN`VU<!;.\"M:#B&W6Q.:YV):1B\URL:VN8K-&
ML>T'D=2J2&JQ7%"WV%\S%]3N+&C-H!]$.KLB'2^DXX5T5BZ=TU4ZLR:=\2#B
M.54UY68N'Z6%@'8NH-M50%X5T-T[S^1697>M0G9FY[([N>R\J^Q.HXWNA>2\
M(CEC3A&45\')S27WNDKNUN3#I:C^0.LK4%D?KZPFSH.LCE?3BV)UJ%?X;EZD
M+$9GHVA2C'M)6LT[ZBE7X;.H8^7XO1S_L\ZYAUW=K<$_3RX>(L\Z.$CCKWZT
M@,1U]FO@3ZZN2=9=QY<,].`@;\;C=$Q*"7OV-Y.D$;')U6@V#Z;/#YZ&40J_
M0RH%.2DDNA<#_^1L>.:_'9P.+@9O84VS$?B4$6:Y,/+3>$R,R]+@UZ^&)V_\
MUZ?OW[S#"9DUP5"<9,($H_:'/,5\^VD<7!^_/2$N/3P@^9_B-^:2[V+F'AY"
M7IROBWB,?UNQ,`432\G@Q162<YP2B\5\F>"/Z\?,0V[>>HP8-XG")/4AT2?/
M'(M\,KY<5?Y,C,M#P$=MC_SW^\7H^>WTV.2V^[]&N!8`MIO!W@:W+VJX`#;P
MQ9<[J,=_-LB0DU>.=2E9+P<E<-3K90,$IPV`S14J+Z!D@3@N#X?UR."BF2G1
MVHC65J-U`*_;"UKJ(%QJK/#&0;*<JQ%;B-A2(W8!,]>JN^-*R)M(WE23Y\#`
MZT9^E-S,KE)P//GRU`?4%L86"V-RH=@*)!Y@H88:RD_`B9>@9/OUTS;[Q83U
MT5R_<)LH>27^I<`(^#Q(WYI!_AK$D0_>/QY-LO5)EN-\B4H"$*-QM0JE;[&:
M&QON:%P;``<!*-/I_T[7LXHRD[\)9184&`)E!IKI.AK\\/'LS<7)>P@+@Q_7
MX0`&P7!FJ`TDP\^]!G==#@W59;^97=]DN_CU=AS-P:2O7BS%#T^^/_W3&V#"
MGAP>:O0:T2%09JCM3((2MR/C-X]\"-W5#>&>9$.68;(()OCXT\;#U2"E.-)I
MEZ"RPJ\5SDPCLI>)K;-GX.T9=8$SZ2IRMN<,'`5WE9$"EP8?CQ[35*JYRU#-
MK2(L-?IV#]>+4KX.XXR;S6$<\0KL*NLL2+-=*/)JWT^';U]1E[LM-!EM30#5
MYU\5D$UZ7!^XK1;+9-F%&H.<F<QMTD%/DG&"<'4.P9=%[,\A4S\^'_SH#W[Z
M^.JTM2@9O!(^*\>HS@"W5G9NH++;ADK95\)W4W<[0V^U\=R>V:#PC7*491`1
MU>8=\VI$EJ%4)+=KA$VQI0W"4N:H44<GAZ7.8*N\8?%T>^=UW#LW@T);[9U=
M8CD?C8.5EC-)98$,UL9Q^NKUX!3';2H^SV&T":F>)95ZLU*0FN8&YF9K]#)@
M3!'TFJW1TYABN1A2;::FG$!T`BG;*D!J4-:*(`5.TT";,'1@:0:8J:-BCDU=
MCZN-L)2^=G(3@"Q#J0^)13DMVS5-D8WD,U9M(M%&YT&V&OGZ-W8GLJVL=B>N
M.G0GL`/IY^"M7`!YF%J,8A@;S&NQ7E#(='%83<'OLB#Y=_]C^'D63OWASZ<_
M^T7[ZTFN>A9Y9;)+I;9F#1C+N#RL+\,\&H^#.-LY8$YAK:AN$,-%KP]:)D&9
MHXBG%7Z7&B?T#WQ)#'6/C$K-$]7FY\SKO:_U),G(JO[49&FB7'2)-I<Z<Y!E
M-;8S;5#XGJ8\MM38TT3)G`VPX$C7!+T-1HXS#>I-C7JIU5OG1V/;B-DTFO&J
ML.F3N`UXDV6LZDHYK=,!4:Z;Z)Z)24NU^NG[]Q^*.GT230-?Q%`<8V)'V`%[
M<BAY\H1\$F>5DLM20]@1PQ@,P88PU36$<202]#C,:-[N;*U<0^D2Z]LLB[[J
M_@J@0$">!V`4Z@W.@I?3HE(40CYL4V&DF<GFM*;41"!"<&8SL,+/;J-B9@9@
M%?;KOK<D]2$>XBXT"PR5-L=61`O`34NYM9K(ZF@B*U`'/J:MYY&WER4\7$T:
M`]21C=-"1?<L=`-F7!K'E4)O"MR59>,H$)>ICS:\__O,6UWU"(.3#Y25+VD,
M4R>[UW$RI/YPA/\=P)_Q^;NSH4_=C9LA)Q?^A0%#AJ]]78Y06]!2GO!M)0I4
M>/Z]212*%S2;NM`YM5@+D^<7>?APA<JZZ!$A?#!M^'"S.5"UZ<Q_VWP$:`,7
MT]-R<-DF\<)ZFCC\O+Q=Y);J(2?J*"193$H,9E=^>A.$?C#']0Z#U9N*X4D9
M$;&4CG]33<6`5<U,K%IW#T%HVO\@`@AC&1!W<`]-Q1ZNQ;<,,=&"W*&5^&N$
M?+-%5^`9C^)X!H8+5($^BE+)9RR&3ZCCX1M0JR&?\7"8#02$,)9.(>V,H`VD
M.\>\>_6=VI>\MI#'-I4(]S*:`68$;TF1]Q7,7LS6X>S=.I[)`E2K`#<-!G=_
ME/CUS1:ZH&.H;+;>BK<-*T`;F3A:#J[9/:QD'!S!Q-W"$[7.OH$ZLN'?H"_A
M`KSWZ$M68QY]23^^Q$-E<XS^?`G0!B8.U?L2:TM?`K2!B;--5K-V8VH.3#!1
M9R6-=7PNG)J#*9C(LX>]]E6`&<'+HU'W[GO)"PU3:OAO$'.\G*0G-9\#U?;=
MAPO__!W4W8]M^=]3M9VIE2TTJT6"L(5C$N43T`8F+CJF6G?YS?NSB_4128HC
MW2V]2[M,!:@#&_<;K'H`,X)_N*IG!XG*8O&8J%3G[V&B`BJ&NM9CT0.TD8F^
MZ'FPY@A@0Y!JG[B?;L(5X.6EV*.;>'03C>.[N@DN=$U>.=_73:P[PL``.'%%
MV=30$#:;J1<-8:`*Y#E=)2H<7X_AAV9J:<K@[&VM:0QC8#"%7,+&<D+:-(:'
M.`SOJF#3V-8UC6&DF./"!$T!5ZY[>CU6T.5$(0`'$3C7PY<5AIH;/T`6Z7M:
MXAO^J\15KV[``#AY1C.;!G6CCOX%!)`%^I2;-66"7_`9LZ`NQ?14IDWX4(QS
M8`RJDZ-0)YSQ(L&Q8IH!B342W;C!EQ_-Q!,3JYLQ%*=1`Z%L6^/K[J\8&29J
MF$HF>QE?$70F@"4%W_?+=`BL(W\<7,]"?S)*)S>/<7+/XR0JBE`:VL*DMLVH
MD;A@1-4F)6AMWKQ[B/-R"%7`IG)#JD!N>\3O-XUWB!RE8"V<)3<DFZKIMB)=
MY,&$G]0<1"LKS>;)D8X'T1H.G)20F3DZNQG9;W(2S>UR$@WA,F&*SO;1C6M.
MB2%Q9$2IJ]<*R5TCU]/1=W,>7"]$4Y.<:_T)SQEYWV"(IEXF@-LM1+=LE7/_
M;9"D<?3U9.M:EXE:EXF#;H.["W_(_PB-=5-<>=Z;$-[_,3;7RG2109TI<G97
M5P+B4#&-63"EKV2!61DC9BN9[*=Q`^A,`%<*?OM;*"*SCH/T)HX^_R&ML3KI
M[/WYX.+CN3H)+RE^WV:<FU>IG$85H.*.B%,MJ*'TQ=N&^)Q9-GX;(^O0L(V:
M6DR&_[MX-0`,E&N_7)/39%##<4GF4Q4E2W0TUT9X3M23$JPH"))$-5+TMO);
MKUY.6$ZT:N'44%^H4'?85;:ME-O+8(+OT$.L0:AB[W3K5=QS0;94OG_BQKI_
M%\U'Z6P>;'B1YKL:>"==*3!P%-PAMU4)?"_7CL0S1J:4R2BY!?2+);!Z\D1'
MRLS)66J\X+6\,M0>\OX..3["S:#;VF5VZ["W+2HMX1A9_5YO-\6T<^R.%C>W
M=H5;7(@RZ_=\6^)>=TT1-`I`&ZQ*=VX]^$6J2A+$JX*V:I>E/BRONRK=476(
M%E28#+;?U7U2MY3;.6(6!57S1.CPM+D=7H02TRS\2!*N3'-A*+E$H&VKX@TK
MY`$;H:4O.4W*-0>GJ-A@;$>H\>]1VI@W*ZP<NX.?R)(K9Z_-"DGJULJAE;)>
M-#`AARM=^WMFO4$X;==-_AWDO1GLW[P*7:>O^8:Z8E.IR;7&NGVAAU>)!"-/
MR\25T%?<J<GI>QD/R]1[',F94]Z<&Q>.V3(%%V:@3U.Y9J]D[[:8QPR%O1?]
M0RXUTV=4XG>N.K=1F\@TMU6=##V^@GS0MBKOU%;E7$"GW%,O^+U>&HHWIQP_
M,*MDLD?1I^2^`;00P&-2\+OZ=$:RO`U^7RZ\51?B&W@5N.I9>"S3!L<HW2XT
MLM\=)OM2XL;A$_2+#LNF<7SOAX?R9?T-\=3!$L[%4>)+#/IO\^)@CI.R[WAJ
M+,WC:B-3]@ZV_5H/7O3%V\$8?^[SN1[="SB,/,@+KZ5^>]_KL8Q,`HO*T>_&
MZWP,X\=/]B@=Q#Z<0D`E$&KL6"U,9NN$T[$$)V$NE7PPL(P:=O5]H_\#OB3Y
%CA%U``!/
`
end
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Setting LD tool default to ld breaks configure check for ld used by GCC
[not found] <no.id>
` (33 preceding siblings ...)
2002-11-23 0:26 ` HP-UX IA64 Patch to fix earlier patch John David Anglin
@ 2002-12-17 9:52 ` John David Anglin
2002-12-20 17:39 ` John David Anglin
2003-01-02 17:48 ` Miscompilation of glibc with CVS mainline John David Anglin
` (8 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2002-12-17 9:52 UTC (permalink / raw)
To: John David Anglin; +Cc: binutils, gcc-bugs, gcc, libtool
> The toplevel configure script sets "LD=ld". The ld used by the GCC check
> in the opcodes directory has the line
>
> test -z "$LD" && LD="$ac_prog"
The above line comes from libtool.m4. If we set LD="" in the toplevel
configure script, the libtool script then sets LD to ld program used by
GCC. However, this define for LD isn't a proper default. So, I am
wondering if the libtool script should also reset LD when LD=ld?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Setting LD tool default to ld breaks configure check for ld used by GCC
2002-12-17 9:52 ` Setting LD tool default to ld breaks configure check for ld used by GCC John David Anglin
@ 2002-12-20 17:39 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2002-12-20 17:39 UTC (permalink / raw)
To: John David Anglin; +Cc: binutils, gcc-bugs, gcc, libtool, dj
> > The toplevel configure script sets "LD=ld". The ld used by the GCC check
> > in the opcodes directory has the line
> >
> > test -z "$LD" && LD="$ac_prog"
>
> The above line comes from libtool.m4. If we set LD="" in the toplevel
> configure script, the libtool script then sets LD to ld program used by
> GCC. However, this define for LD isn't a proper default. So, I am
> wondering if the libtool script should also reset LD when LD=ld?
After some discussion of this matter on the libtool list, the conclusion
is that Cygnus configure shouldn't be setting LD and other similar defines
in native builds. PR 9031 has more details.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Miscompilation of glibc with CVS mainline
[not found] <no.id>
` (34 preceding siblings ...)
2002-12-17 9:52 ` Setting LD tool default to ld breaks configure check for ld used by GCC John David Anglin
@ 2003-01-02 17:48 ` John David Anglin
2003-01-02 17:54 ` Jakub Jelinek
2003-01-02 17:57 ` Daniel Jacobowitz
2003-02-03 5:02 ` hppa-linux regressions and 3.2.2 release John David Anglin
` (7 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2003-01-02 17:48 UTC (permalink / raw)
To: John David Anglin; +Cc: jakub, aj, gcc, libc-alpha
> > > Here's a small testcase that has the same behaviour:
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > extern void weak_func (void *arg);
> > > asm (".weak weak_func");
> > >
> > > void
> > > test (void *arg)
> > > {
> > > if (&weak_func != (void *)0)
> > > weak_func (arg);
> > >
> > > }
> >
> > As GCC is not told in any way that weak_func is actually weak, I think
> > it is glibc's fault.
>
> This is definitely a gcc problem. This is the code arising from
> Andreas' testcase for hppa-linux at -O2:
>
> stw %r2,-20(%r30)
> ldo 64(%r30),%r30
> ldw -84(%r30),%r2
> bl weak_func,%r0
> ldo -64(%r30),%r30
>
> We have completely lost the `if'. As a result, weak_func is always
> called.
There is another problem. The call to weak_func has been turned into
a sibcall. It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
consulted as we don't allow indirect sibcalls on hppa-linux.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Miscompilation of glibc with CVS mainline
2003-01-02 17:48 ` Miscompilation of glibc with CVS mainline John David Anglin
@ 2003-01-02 17:54 ` Jakub Jelinek
2003-01-02 18:58 ` John David Anglin
2003-01-02 17:57 ` Daniel Jacobowitz
1 sibling, 1 reply; 175+ messages in thread
From: Jakub Jelinek @ 2003-01-02 17:54 UTC (permalink / raw)
To: John David Anglin; +Cc: aj, gcc, libc-alpha
On Thu, Jan 02, 2003 at 12:48:23PM -0500, John David Anglin wrote:
> There is another problem. The call to weak_func has been turned into
> a sibcall. It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
> consulted as we don't allow indirect sibcalls on hppa-linux.
The call is not indirect, it is normal direct call
(even if weak_func is marked __attribute__((weak)) or #pragma weak).
Jakub
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Miscompilation of glibc with CVS mainline
2003-01-02 17:54 ` Jakub Jelinek
@ 2003-01-02 18:58 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2003-01-02 18:58 UTC (permalink / raw)
To: jakub; +Cc: aj, gcc, libc-alpha
> The call is not indirect, it is normal direct call
> (even if weak_func is marked __attribute__((weak)) or #pragma weak).
Sorry, for the net garbage. My original analysis of the glibc problem
involved an indirect call.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Miscompilation of glibc with CVS mainline
2003-01-02 17:48 ` Miscompilation of glibc with CVS mainline John David Anglin
2003-01-02 17:54 ` Jakub Jelinek
@ 2003-01-02 17:57 ` Daniel Jacobowitz
1 sibling, 0 replies; 175+ messages in thread
From: Daniel Jacobowitz @ 2003-01-02 17:57 UTC (permalink / raw)
To: gcc, libc-alpha
On Thu, Jan 02, 2003 at 12:48:23PM -0500, John David Anglin wrote:
> > > > Here's a small testcase that has the same behaviour:
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > extern void weak_func (void *arg);
> > > > asm (".weak weak_func");
> > > >
> > > > void
> > > > test (void *arg)
> > > > {
> > > > if (&weak_func != (void *)0)
> > > > weak_func (arg);
> > > >
> > > > }
> > >
> > > As GCC is not told in any way that weak_func is actually weak, I think
> > > it is glibc's fault.
> >
> > This is definitely a gcc problem. This is the code arising from
> > Andreas' testcase for hppa-linux at -O2:
> >
> > stw %r2,-20(%r30)
> > ldo 64(%r30),%r30
> > ldw -84(%r30),%r2
> > bl weak_func,%r0
> > ldo -64(%r30),%r30
> >
> > We have completely lost the `if'. As a result, weak_func is always
> > called.
>
> There is another problem. The call to weak_func has been turned into
> a sibcall. It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
> consulted as we don't allow indirect sibcalls on hppa-linux.
This isn't an indirect call, though. weak_func is not a pointer...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: hppa-linux regressions and 3.2.2 release
[not found] <no.id>
` (35 preceding siblings ...)
2003-01-02 17:48 ` Miscompilation of glibc with CVS mainline John David Anglin
@ 2003-02-03 5:02 ` John David Anglin
2003-02-03 11:03 ` Gabriel Dos Reis
2003-02-03 16:26 ` John David Anglin
2003-02-11 19:37 ` Bootstrap failure on hppa-unknown-linux-gnu, trunk John David Anglin
` (6 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2003-02-03 5:02 UTC (permalink / raw)
To: John David Anglin; +Cc: gdr, ebotcazou, randolph, gcc, gcc-patches
> I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
> and hppa-unknown-linux-gnu including the patch set for the other PR from
> Franz Sirl. I will post the results as soon as available.
The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
run without Franz's patch:
<http://gcc.gnu.org/ml/gcc-testresults/2003-02/msg00130.html>.
I had to restart the hppa64-hp-hpux11.00 run. I used the HP linker
and it generates a warning on each link. This totally messes
up the testsuite results. I would like to apply the following patch
from Steve Ellcey to correct the problem. It has been on the main and
3.3 since early last October. The comment describes what it does. It
only affects hppa64-hp-hpux11* and doesn't affect code generation.
As you are doing preleases, I will wait for your OK.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2003-02-02 Steve Ellcey <sje@cup.hp.com>
* config/pa/pa64-hpux.h (INIT_ENVIRONMENT): New.
Index: config/pa/pa64-hpux.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa64-hpux.h,v
retrieving revision 1.9
diff -u -3 -p -r1.9 pa64-hpux.h
--- config/pa/pa64-hpux.h 21 Jan 2002 21:22:19 -0000 1.9
+++ config/pa/pa64-hpux.h 3 Feb 2003 04:38:07 -0000
@@ -232,3 +232,8 @@ do { \
#ifndef ASM_DECLARE_RESULT
#define ASM_DECLARE_RESULT(FILE, RESULT)
#endif
+
+/* If using HP ld do not call pxdb. Use size as a program that does nothing
+ and returns 0. /bin/true cannot be used because it is a script without
+ an interpreter. */
+#define INIT_ENVIRONMENT "LD_PXDB=/usr/ccs/bin/size"
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: hppa-linux regressions and 3.2.2 release
2003-02-03 5:02 ` hppa-linux regressions and 3.2.2 release John David Anglin
@ 2003-02-03 11:03 ` Gabriel Dos Reis
2003-02-03 16:26 ` John David Anglin
1 sibling, 0 replies; 175+ messages in thread
From: Gabriel Dos Reis @ 2003-02-03 11:03 UTC (permalink / raw)
To: John David Anglin; +Cc: ebotcazou, randolph, gcc, gcc-patches
"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
[...]
| As you are doing preleases, I will wait for your OK.
It is OK.
Thanks,
-- Gaby
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: hppa-linux regressions and 3.2.2 release
2003-02-03 5:02 ` hppa-linux regressions and 3.2.2 release John David Anglin
2003-02-03 11:03 ` Gabriel Dos Reis
@ 2003-02-03 16:26 ` John David Anglin
2003-02-03 16:54 ` Gabriel Dos Reis
1 sibling, 1 reply; 175+ messages in thread
From: John David Anglin @ 2003-02-03 16:26 UTC (permalink / raw)
To: John David Anglin; +Cc: gdr, ebotcazou, randolph, gcc, gcc-patches
> > I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
> > and hppa-unknown-linux-gnu including the patch set for the other PR from
> > Franz Sirl. I will post the results as soon as available.
>
> The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
> run without Franz's patch:
All test runs are complete and posted. There are no regressions.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: hppa-linux regressions and 3.2.2 release
2003-02-03 16:26 ` John David Anglin
@ 2003-02-03 16:54 ` Gabriel Dos Reis
2003-02-03 18:02 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Gabriel Dos Reis @ 2003-02-03 16:54 UTC (permalink / raw)
To: John David Anglin; +Cc: ebotcazou, randolph, gcc, gcc-patches
"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
| > > I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
| > > and hppa-unknown-linux-gnu including the patch set for the other PR from
| > > Franz Sirl. I will post the results as soon as available.
| >
| > The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
| > run without Franz's patch:
|
| All test runs are complete and posted. There are no regressions.
Thanks for the report. Please commit the set of patches you tested.
This hopefully will be the last patch to commit.
-- Gaby
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk
[not found] <no.id>
` (36 preceding siblings ...)
2003-02-03 5:02 ` hppa-linux regressions and 3.2.2 release John David Anglin
@ 2003-02-11 19:37 ` John David Anglin
2003-02-11 22:37 ` Josef Zlomek
2003-03-05 22:03 ` Josef Zlomek
2003-02-11 19:59 ` Altivec + 16 byte alignment John David Anglin
` (5 subsequent siblings)
43 siblings, 2 replies; 175+ messages in thread
From: John David Anglin @ 2003-02-11 19:37 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-patches, zlomekj
> stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> (mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> (reg:DI 74 %fr25))) -1 (nil)
> (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> (expr_list:REG_DEAD (reg:DI 74 %fr25)
> (nil))))
> ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
I have determined that it is the addition of this patch that results in
the above ICE:
2003-02-10 Josef Zlomek <zlomekj@suse.cz>
* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
* bb-reorder.c (make_reorder_chain): Deleted.
(make_reorder_chain_1): Deleted.
(find_traces): New function.
(rotate_loop): New function.
(mark_bb_visited): New function.
(find_traces_1_round): New function.
(copy_bb): New function.
(bb_to_key): New function.
(better_edge_p): New function.
(connect_traces): New function.
(copy_bb_p): New function.
(get_uncond_jump_length): New function.
(reorder_basic_blocks): Use new functions (Software Trace Cache).
* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
boundaries.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk
2003-02-11 19:37 ` Bootstrap failure on hppa-unknown-linux-gnu, trunk John David Anglin
@ 2003-02-11 22:37 ` Josef Zlomek
2003-02-11 22:51 ` John David Anglin
2003-03-05 22:03 ` Josef Zlomek
1 sibling, 1 reply; 175+ messages in thread
From: Josef Zlomek @ 2003-02-11 22:37 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-patches
> > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > (mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > (reg:DI 74 %fr25))) -1 (nil)
> > (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > (expr_list:REG_DEAD (reg:DI 74 %fr25)
> > (nil))))
> > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
>
> I have determined that it is the addition of this patch that results in
> the above ICE:
>
> 2003-02-10 Josef Zlomek <zlomekj@suse.cz>
>
> * Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
> * bb-reorder.c (make_reorder_chain): Deleted.
> (make_reorder_chain_1): Deleted.
> (find_traces): New function.
> (rotate_loop): New function.
> (mark_bb_visited): New function.
> (find_traces_1_round): New function.
> (copy_bb): New function.
> (bb_to_key): New function.
> (better_edge_p): New function.
> (connect_traces): New function.
> (copy_bb_p): New function.
> (get_uncond_jump_length): New function.
> (reorder_basic_blocks): Use new functions (Software Trace Cache).
> * cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
> boundaries.
I apologize for the breakage. It seems that new bb-reorder has uncovered
bugs in machine descriptions.
Honza Hubicka has checked in a patch
(http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html)
which hopefully should enable gcc to bootstrap again.
Josef
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk
2003-02-11 22:37 ` Josef Zlomek
@ 2003-02-11 22:51 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2003-02-11 22:51 UTC (permalink / raw)
To: Josef Zlomek; +Cc: gcc, gcc-patches
> > > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > > (mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > > (reg:DI 74 %fr25))) -1 (nil)
> > > (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > > (expr_list:REG_DEAD (reg:DI 74 %fr25)
> > > (nil))))
> > > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
> >
> > I have determined that it is the addition of this patch that results in
> > the above ICE:
> >
> > 2003-02-10 Josef Zlomek <zlomekj@suse.cz>
> >
> > * Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
> > * bb-reorder.c (make_reorder_chain): Deleted.
> > (make_reorder_chain_1): Deleted.
> > (find_traces): New function.
> > (rotate_loop): New function.
> > (mark_bb_visited): New function.
> > (find_traces_1_round): New function.
> > (copy_bb): New function.
> > (bb_to_key): New function.
> > (better_edge_p): New function.
> > (connect_traces): New function.
> > (copy_bb_p): New function.
> > (get_uncond_jump_length): New function.
> > (reorder_basic_blocks): Use new functions (Software Trace Cache).
> > * cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
> > boundaries.
>
> I apologize for the breakage. It seems that new bb-reorder has uncovered
> bugs in machine descriptions.
> Honza Hubicka has checked in a patch
> (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html)
> which hopefully should enable gcc to bootstrap again.
I have been looking at the patterns which use the xmpyu insn on the PA.
There are two patterns (32 and 64 bit) which have an uint32_operand
predicate and "f" constraint. The "f" constraint is inconsistent with
the predicate. The uint32_operand predicate is inconsistent with the
actual capability of the machine instruction. I had queried Jeff Law
about this in the past. This was his response:
> I thought changing the operands of the pattern to register_operand is a more
> accurate description of the machine insn although reloads still can
> potentially occur.
It's certainly more accurate, but due to secondary effects of register
allocation
and reloading it's actually more profitable to be more general in the
operand predicates than what the instruction actually allows. That is
generally a bad thing to do, but from time to time it is helpful.
Basically, some games are being played with the predicate and constraint
to improve the generated code.
The 32-bit seems to be building again. However, the have been some
"strange" warning messages on hppa64-hp-hpux11.11:
g-yacc.29398.c: In function `yystrlen':
g-yacc.29398.c:708: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yystpcpy':
g-yacc.29398.c:733: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yydestruct':
g-yacc.29398.c:800: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yyparse':
g-yacc.29398.c:863: warning: traditional C rejects ISO C style function definiti
ons
and
c-p29635.c: In function `yy_stack_print':
c-p29635.c:2150: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yy_reduce_print':
c-p29635.c:2176: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yysymprint':
c-p29635.c:2297: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yydestruct':
c-p29635.c:2333: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yyparse':
c-p29635.c:2396: warning: traditional C rejects ISO C style function definitions
Possibly, this is a bison 1.875 problem. Yes, it seems to be.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk
2003-02-11 19:37 ` Bootstrap failure on hppa-unknown-linux-gnu, trunk John David Anglin
2003-02-11 22:37 ` Josef Zlomek
@ 2003-03-05 22:03 ` Josef Zlomek
2003-03-05 22:05 ` Josef Zlomek
1 sibling, 1 reply; 175+ messages in thread
From: Josef Zlomek @ 2003-03-05 22:03 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-patches
> > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > (mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > (reg:DI 74 %fr25))) -1 (nil)
> > (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > (expr_list:REG_DEAD (reg:DI 74 %fr25)
> > (nil))))
> > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
>
> I have determined that it is the addition of this patch that results in
> the above ICE:
Maybe it is a similar problem in machine descriptions as alpha and sh did
have (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01295.html). But maybe I'm wrong.
The bb-reorder itself is pretty high level, it is a probably first use
of code duplication functions which went to mainline.
Anyway, I apologize for the breakage.
Josef
> 2003-02-10 Josef Zlomek <zlomekj@suse.cz>
>
> * Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
> * bb-reorder.c (make_reorder_chain): Deleted.
> (make_reorder_chain_1): Deleted.
> (find_traces): New function.
> (rotate_loop): New function.
> (mark_bb_visited): New function.
> (find_traces_1_round): New function.
> (copy_bb): New function.
> (bb_to_key): New function.
> (better_edge_p): New function.
> (connect_traces): New function.
> (copy_bb_p): New function.
> (get_uncond_jump_length): New function.
> (reorder_basic_blocks): Use new functions (Software Trace Cache).
> * cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
> boundaries.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk
2003-03-05 22:03 ` Josef Zlomek
@ 2003-03-05 22:05 ` Josef Zlomek
0 siblings, 0 replies; 175+ messages in thread
From: Josef Zlomek @ 2003-03-05 22:05 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gcc-patches
> > > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > > (mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > > (reg:DI 74 %fr25))) -1 (nil)
> > > (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > > (expr_list:REG_DEAD (reg:DI 74 %fr25)
> > > (nil))))
> > > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
> >
> > I have determined that it is the addition of this patch that results in
> > the above ICE:
>
> Maybe it is a similar problem in machine descriptions as alpha and sh did
> have (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01295.html). But maybe I'm wrong.
> The bb-reorder itself is pretty high level, it is a probably first use
> of code duplication functions which went to mainline.
> Anyway, I apologize for the breakage.
Or there simply is some code in bb-reorder.c which uncovers another bug.
Josef
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Altivec + 16 byte alignment
[not found] <no.id>
` (37 preceding siblings ...)
2003-02-11 19:37 ` Bootstrap failure on hppa-unknown-linux-gnu, trunk John David Anglin
@ 2003-02-11 19:59 ` John David Anglin
2003-02-11 21:02 ` Mike Stump
2003-05-07 1:13 ` GCC 3.3 Prelease broken on s390 Ulrich Weigand
` (4 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2003-02-11 19:59 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gianni, kenner
> /* Ignore alignment we can't do with expected alignment of the
> boundary. */
> if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
> alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
>
> but really that's wrong, and at a minimum it should warn the user
> that their requested alignment isn't going to happen (better would be
> to just ensure the requested alignment). We occasionally get bug
> reports about this, but so far no-one has invested the effort to
> implement arbitrary stack alignment.
>
> Now we have *yet another* macro involved in alignment!
Another issue is GCC's alignment attribute is silently ignored for stack
locals and the documentation doesn't say that.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Altivec + 16 byte alignment
2003-02-11 19:59 ` Altivec + 16 byte alignment John David Anglin
@ 2003-02-11 21:02 ` Mike Stump
2003-02-12 5:55 ` Fergus Henderson
0 siblings, 1 reply; 175+ messages in thread
From: Mike Stump @ 2003-02-11 21:02 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, gianni, kenner
On Tuesday, February 11, 2003, at 11:59 AM, John David Anglin wrote:
>> /* Ignore alignment we can't do with expected alignment of the
>> boundary. */
>> if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
>> alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
>>
>> but really that's wrong, and at a minimum it should warn the user
>> that their requested alignment isn't going to happen (better
>> would be
>> to just ensure the requested alignment). We occasionally get bug
>> reports about this, but so far no-one has invested the effort to
>> implement arbitrary stack alignment.
>>
>> Now we have *yet another* macro involved in alignment!
>
> Another issue is GCC's alignment attribute is silently ignored for
> stack
> locals and the documentation doesn't say that.
Let us agree that this is just a bug, or at least a bug for CPUs that
have hard requirements of say 16 bytes (Altivec, SSE) and the user asks
for 16 byte alignment and we silently only do 8 byte alignment.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Altivec + 16 byte alignment
2003-02-11 21:02 ` Mike Stump
@ 2003-02-12 5:55 ` Fergus Henderson
2003-02-12 16:39 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Fergus Henderson @ 2003-02-12 5:55 UTC (permalink / raw)
To: Mike Stump; +Cc: John David Anglin, gcc, gianni, kenner
On 11-Feb-2003, Mike Stump <mstump@apple.com> wrote:
> On Tuesday, February 11, 2003, at 11:59 AM, John David Anglin wrote:
> > Another issue is GCC's alignment attribute is silently ignored for
> > stack locals and the documentation doesn't say that.
>
> Let us agree that this is just a bug, or at least a bug for CPUs that
> have hard requirements of say 16 bytes (Altivec, SSE) and the user asks
> for 16 byte alignment and we silently only do 8 byte alignment.
Please let us agree that this is just a bug, regardless of the CPU's
requirements. The alignment declaration might be used by the programmer
to ensure that the lower bits are available for use as tag bits.
For example, the following program should result in either success
or a compile error (if the requested alignment is not supported).
But IMHO it should not result in an assertion failure.
#include <assert.h>
#define ALIGN 32
int main() {
char c __attribute__((aligned(ALIGN)));
assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
return 0;
}
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Altivec + 16 byte alignment
2003-02-12 5:55 ` Fergus Henderson
@ 2003-02-12 16:39 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2003-02-12 16:39 UTC (permalink / raw)
To: Fergus Henderson; +Cc: mstump, gcc, gianni, kenner
> Please let us agree that this is just a bug, regardless of the CPU's
> requirements. The alignment declaration might be used by the programmer
> to ensure that the lower bits are available for use as tag bits.
>
> For example, the following program should result in either success
> or a compile error (if the requested alignment is not supported).
> But IMHO it should not result in an assertion failure.
>
> #include <assert.h>
> #define ALIGN 32
> int main() {
> char c __attribute__((aligned(ALIGN)));
> assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
> return 0;
> }
You have my vote on the matter.
If we go back to Franz's original reply to my post regarding the
rs6000 port, he said "BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY
is 64 unless you give -mabi=altivec (in 3.2+)." If you look at
assign_stack_temp_for_type and assign_stack_local_1, you will see
that BLKmode objects are aligned to BIGGEST_ALIGNMENT. Thus, without
-mabi=altivec, you would randomly get an assertion failure, depending
on the stack alignment, if you checked the alignment of structs with
code similar to that above. In other words, you aren't getting the
alignment of BLKmode stack locals that you have specified in the
backend. Possibly, this doesn't matter, but it seems inconsistent
and I think would lead to problems if the compiler checked alignment
requests as suggested above.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
[not found] <no.id>
` (38 preceding siblings ...)
2003-02-11 19:59 ` Altivec + 16 byte alignment John David Anglin
@ 2003-05-07 1:13 ` Ulrich Weigand
2003-05-07 1:27 ` Richard Henderson
2003-07-05 17:01 ` Solaris 8/SPARC bootstrap broken building 64-bit libgcc John David Anglin
` (3 subsequent siblings)
43 siblings, 1 reply; 175+ messages in thread
From: Ulrich Weigand @ 2003-05-07 1:13 UTC (permalink / raw)
To: rth; +Cc: mark, gcc
I wrote:
> Interestingly, mainline works fine without any patch.
When your latest mainline patch to unwind-dw2.c is backported
to 3.3, it works again as well; the patch below does this.
(A full bootstrap/regtest is still running.)
Note that I really only need the first hunk, as the
rest only changes the return value from uw_install_context_1,
which is completely ignored on s390 anyway (as SP is
restored from its stack slot, where the correct new
value was already stored by uw_install_context_1).
What do you think?
Bye,
Ulrich
ChangeLog:
* unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
previous frame didn't save sp. Clear sp for next frame.
(uw_install_context_1): Honor saved sp from frame.
*** unwind-dw2.c.orig Wed May 7 02:52:49 2003
--- unwind-dw2.c Wed May 7 03:00:45 2003
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1059,1069 ****
In very special situations (such as unwind info for signal return),
there may be location expressions that use the stack pointer as well.
! Given that other unwind mechanisms generally won't work if you try
! to represent stack pointer saves and restores directly, we don't
! bother conditionalizing this at all. */
! tmp_sp = (_Unwind_Ptr) context->cfa;
! orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
/* Compute this frame's CFA. */
switch (fs->cfa_how)
--- 1059,1075 ----
In very special situations (such as unwind info for signal return),
there may be location expressions that use the stack pointer as well.
! Do this conditionally for one frame. This allows the unwind info
! for one frame to save a copy of the stack pointer from the previous
! frame, and be able to use much easier CFA mechanisms to do it.
! Always zap the saved stack pointer value for the next frame; carrying
! the value over from one frame to another doesn't make sense. */
! if (!orig_context.reg[__builtin_dwarf_sp_column ()])
! {
! tmp_sp = (_Unwind_Ptr) context->cfa;
! orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
! }
! context->reg[__builtin_dwarf_sp_column ()] = NULL;
/* Compute this frame's CFA. */
switch (fs->cfa_how)
*************** uw_install_context_1 (struct _Unwind_Con
*** 1201,1206 ****
--- 1207,1213 ----
struct _Unwind_Context *target)
{
long i;
+ void *target_cfa;
#if __GTHREADS
{
*************** uw_install_context_1 (struct _Unwind_Con
*** 1222,1232 ****
memcpy (c, t, dwarf_reg_size_table[i]);
}
/* We adjust SP by the difference between CURRENT and TARGET's CFA. */
if (STACK_GROWS_DOWNWARD)
! return target->cfa - current->cfa + target->args_size;
else
! return current->cfa - target->cfa - target->args_size;
}
static inline _Unwind_Ptr
--- 1229,1246 ----
memcpy (c, t, dwarf_reg_size_table[i]);
}
+ /* If the last frame records a saved stack pointer, use it. */
+ if (target->reg[__builtin_dwarf_sp_column ()])
+ target_cfa = (void *)(_Unwind_Ptr)
+ _Unwind_GetGR (target, __builtin_dwarf_sp_column ());
+ else
+ target_cfa = target->cfa;
+
/* We adjust SP by the difference between CURRENT and TARGET's CFA. */
if (STACK_GROWS_DOWNWARD)
! return target_cfa - current->cfa + target->args_size;
else
! return current->cfa - target_cfa - target->args_size;
}
static inline _Unwind_Ptr
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 1:13 ` GCC 3.3 Prelease broken on s390 Ulrich Weigand
@ 2003-05-07 1:27 ` Richard Henderson
2003-05-07 5:53 ` Mark Mitchell
2003-05-07 14:54 ` Ulrich Weigand
0 siblings, 2 replies; 175+ messages in thread
From: Richard Henderson @ 2003-05-07 1:27 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: mark, gcc
On Wed, May 07, 2003 at 03:13:39AM +0200, Ulrich Weigand wrote:
> ... which is completely ignored on s390 anyway (as SP is
> restored from its stack slot, where the correct new
> value was already stored by uw_install_context_1).
Ah, now I get it. This was the piece I couldn't understand.
And if *this* is the case, it means that it doesn't matter
where you place the CFA relative to the stack frame, just so
long as the stack pointer itself is computed properly.
> What do you think?
>
> * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
> previous frame didn't save sp. Clear sp for next frame.
> (uw_install_context_1): Honor saved sp from frame.
If this works, great.
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 1:27 ` Richard Henderson
@ 2003-05-07 5:53 ` Mark Mitchell
2003-05-07 14:54 ` Ulrich Weigand
1 sibling, 0 replies; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 5:53 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ulrich Weigand, gcc
> > What do you think?
> >
> > * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
> > previous frame didn't save sp. Clear sp for next frame.
> > (uw_install_context_1): Honor saved sp from frame.
>
> If this works, great.
Ulrich --
Take that as approval from Richard; if it fixes your problem, please
check it in and close the PR.
Thanks,
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 1:27 ` Richard Henderson
2003-05-07 5:53 ` Mark Mitchell
@ 2003-05-07 14:54 ` Ulrich Weigand
2003-05-07 15:53 ` Mark Mitchell
2003-05-07 17:51 ` Richard Henderson
1 sibling, 2 replies; 175+ messages in thread
From: Ulrich Weigand @ 2003-05-07 14:54 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ulrich Weigand, mark, gcc
Richard Henderson wrote:
> Ah, now I get it. This was the piece I couldn't understand.
> And if *this* is the case, it means that it doesn't matter
> where you place the CFA relative to the stack frame, just so
> long as the stack pointer itself is computed properly.
This is what I was thinking, yes.
> > * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
> > previous frame didn't save sp. Clear sp for next frame.
> > (uw_install_context_1): Honor saved sp from frame.
>
> If this works, great.
Unfortunately, while it fixes most of the problems, it is not a
complete solution:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00418.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00419.html
The Java test case PR218 is still failing. This is because
this test case throws an exception from a signal handler
through a *leaf* function that was interrupted by the
signal.
When unwinding through the leaf function, there is no CFA code
to restore the stack pointer, because the *correct* behaviour
would have been to reuse the stack pointer from the frame below
(the signal return stub frame) unchanged -- the leaf function
really did not allocate any stack space.
However, this now triggers again the new code that sets the
stack pointer to the cfa, incorrect on s390.
Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?
Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
on top of the current 3.3 implementation?
What about an alternate target macro that says that this target
handles SP by itself via FDE records, and doesn't need any
other SP fiddling? This would then allow us to remove the
unnecessary EH_RETURN_STACKADJ_RTX handling completely.
Maybe this behaviour could actually be triggered by the target
leaving EH_RETURN_STACKADJ_RTX undefined?
If no other solution works for 3.3, we could always fix it
ad-hoc with #ifdef __s390__ ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 14:54 ` Ulrich Weigand
@ 2003-05-07 15:53 ` Mark Mitchell
2003-05-07 16:03 ` Joe Buck
2003-05-07 17:02 ` Ulrich Weigand
2003-05-07 17:51 ` Richard Henderson
1 sibling, 2 replies; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 15:53 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Richard Henderson, Ulrich Weigand, gcc
> Unfortunately, while it fixes most of the problems, it is not a
> complete solution:
Bummer.
> Would you suggest to check the above patch in anyway to make 3.3
> more similar to head (apparently the patch is already in 3.2 ...),
> and because it fixes at least C++?
No, that doesn't seem worth it.
> Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
> on top of the current 3.3 implementation?
That seems fine, if it will work. The key criteria are:
(1) You can do it in such a way that it's obvious it doesn't affect
other platforms.
(2) You can do it quickly.
Engineering beauty is not a consideration at all, in this case.
#ifdef __s390__ is fine, for example; if you can just do
#ifdef __s390__
cfa += 196;
#endif
that is absolutely fine by me.
If we can't meet those criteria, we may be forced to punt; s390 is not a
primary evaluation platform.
Please see if you can get this fixed in the next twenty-four hours or
so.
Thanks,
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 15:53 ` Mark Mitchell
@ 2003-05-07 16:03 ` Joe Buck
2003-05-07 16:13 ` Mark Mitchell
2003-05-07 17:02 ` Ulrich Weigand
1 sibling, 1 reply; 175+ messages in thread
From: Joe Buck @ 2003-05-07 16:03 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Ulrich Weigand, Richard Henderson, Ulrich Weigand, gcc
On Wed, May 07, 2003 at 08:53:40AM -0700, Mark Mitchell wrote:
> Engineering beauty is not a consideration at all, in this case.
>
> #ifdef __s390__ is fine, for example; if you can just do
>
> #ifdef __s390__
> cfa += 196;
> #endif
>
> that is absolutely fine by me.
If we go for such a solution, I think that it should be a one-release-only
emergency fix, to be replaced ASAP with a better one; seas of #ifdef's
tend to grow if not whacked back.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 16:03 ` Joe Buck
@ 2003-05-07 16:13 ` Mark Mitchell
0 siblings, 0 replies; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 16:13 UTC (permalink / raw)
To: Joe Buck; +Cc: Ulrich Weigand, Richard Henderson, Ulrich Weigand, gcc
On Wed, 2003-05-07 at 09:01, Joe Buck wrote:
> On Wed, May 07, 2003 at 08:53:40AM -0700, Mark Mitchell wrote:
> > Engineering beauty is not a consideration at all, in this case.
> >
> > #ifdef __s390__ is fine, for example; if you can just do
> >
> > #ifdef __s390__
> > cfa += 196;
> > #endif
> >
> > that is absolutely fine by me.
>
> If we go for such a solution, I think that it should be a one-release-only
> emergency fix, to be replaced ASAP with a better one; seas of #ifdef's
> tend to grow if not whacked back.
There's no way something like this will go on the mainline.
If we had to live with this through the 3.3 series, that would be OK;
that is bounded.
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 15:53 ` Mark Mitchell
2003-05-07 16:03 ` Joe Buck
@ 2003-05-07 17:02 ` Ulrich Weigand
2003-05-07 17:09 ` Joe Buck
` (2 more replies)
1 sibling, 3 replies; 175+ messages in thread
From: Ulrich Weigand @ 2003-05-07 17:02 UTC (permalink / raw)
To: Mark Mitchell; +Cc: rth, gcc
Mark Mitchell wrote:
> That seems fine, if it will work. The key criteria are:
>
> (1) You can do it in such a way that it's obvious it doesn't affect
> other platforms.
>
> (2) You can do it quickly.
>
> Engineering beauty is not a consideration at all, in this case.
I can offer the following patch, which passes bootstrap/regtest
on s390-ibm-linux and s390x-ibm-linux and restores both targets
to their previous behaviour in all cases, including that Java
leaf-function test case. See:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00428.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00429.html
It should be obvious that it does not affect other platforms;
the hunk in uw_update_context_1 is under #ifdef, and the hunk
in uw_init_context_1 does not affect non-s390 platforms because
for them uw_update_context_1 will immediately undo that change
(never mind that even if it didn't, the change would in fact
be correct for other platforms as well).
I will continue to work on a cleaner solution, but I cannot
guarantee that this will succeed within 24 hours (and I'd
also like to ask for Richard's opinion).
Do you think we should use the patch below for 3.3?
Bye,
Ulrich
PR other/10650
* unwind-dw2.c (uw_update_context_1): Don't set sp as cfa on s390.
(uw_init_context_1): Set initial sp to outer cfa.
Index: gcc/unwind-dw2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.22.2.4
diff -c -p -r1.22.2.4 unwind-dw2.c
*** gcc/unwind-dw2.c 5 May 2003 16:59:21 -0000 1.22.2.4
--- gcc/unwind-dw2.c 7 May 2003 14:54:10 -0000
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1062,1069 ****
--- 1062,1071 ----
Given that other unwind mechanisms generally won't work if you try
to represent stack pointer saves and restores directly, we don't
bother conditionalizing this at all. */
+ #ifndef __s390__
tmp_sp = (_Unwind_Ptr) context->cfa;
orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif
/* Compute this frame's CFA. */
switch (fs->cfa_how)
*************** uw_init_context_1 (struct _Unwind_Contex
*** 1164,1169 ****
--- 1166,1172 ----
/* Force the frame state to use the known cfa value. */
context->cfa = outer_cfa;
+ context->reg[__builtin_dwarf_sp_column ()] = &outer_cfa;
fs.cfa_how = CFA_REG_OFFSET;
fs.cfa_reg = __builtin_dwarf_sp_column ();
fs.cfa_offset = 0;
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 17:02 ` Ulrich Weigand
@ 2003-05-07 17:09 ` Joe Buck
2003-05-07 17:11 ` Mark Mitchell
2003-05-07 18:19 ` Jonathan Lennox
2 siblings, 0 replies; 175+ messages in thread
From: Joe Buck @ 2003-05-07 17:09 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Mark Mitchell, rth, gcc
On Wed, May 07, 2003 at 07:02:49PM +0200, Ulrich Weigand wrote:
> It should be obvious that it does not affect other platforms;
> the hunk in uw_update_context_1 is under #ifdef, and the hunk
> in uw_init_context_1 does not affect non-s390 platforms because
> for them uw_update_context_1 will immediately undo that change
> (never mind that even if it didn't, the change would in fact
> be correct for other platforms as well).
Given the very short time remaining for testing, if you're ifdef'ing
one hunk, you might as well ifdef them both. The patch would then
have zero risk for other platforms.
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 17:02 ` Ulrich Weigand
2003-05-07 17:09 ` Joe Buck
@ 2003-05-07 17:11 ` Mark Mitchell
2003-05-07 19:39 ` Ulrich Weigand
2003-05-07 18:19 ` Jonathan Lennox
2 siblings, 1 reply; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 17:11 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: rth, gcc
> I will continue to work on a cleaner solution, but I cannot
> guarantee that this will succeed within 24 hours (and I'd
> also like to ask for Richard's opinion).
>
> Do you think we should use the patch below for 3.3?
Yes -- but please enclose the second hunk in #ifdef as well. If we're
going to be ugly, let's not try to be smart while we're being ugly.
Please check this in, and close the PR.
Thanks,
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 17:11 ` Mark Mitchell
@ 2003-05-07 19:39 ` Ulrich Weigand
2003-05-07 19:45 ` Mark Mitchell
0 siblings, 1 reply; 175+ messages in thread
From: Ulrich Weigand @ 2003-05-07 19:39 UTC (permalink / raw)
To: Mark Mitchell; +Cc: rth, gcc, gcc-patches
Mark Mitchell wrote:
> Yes -- but please enclose the second hunk in #ifdef as well. If we're
> going to be ugly, let's not try to be smart while we're being ugly.
Fine with me.
> Please check this in, and close the PR.
For the record, I've checked in the patch below and closed the PR.
Bye,
Ulrich
Index: gcc/ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 1.16114.2.511
diff -c -p -r1.16114.2.511 ChangeLog
*** gcc/ChangeLog 7 May 2003 06:02:01 -0000 1.16114.2.511
--- gcc/ChangeLog 7 May 2003 19:26:21 -0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2003-05-06 Ulrich Weigand <uweigand@de.ibm.com>
+
+ PR other/10650
+ * unwind-dw2.c (uw_update_context_1): Don't set sp as cfa on s390.
+ (uw_init_context_1): Set initial sp to outer cfa on s390.
+
2003-05-06 Mark Mitchell <mark@codesourcery.com>
PR other/10658
Index: gcc/unwind-dw2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.22.2.4
diff -c -p -r1.22.2.4 unwind-dw2.c
*** gcc/unwind-dw2.c 5 May 2003 16:59:21 -0000 1.22.2.4
--- gcc/unwind-dw2.c 7 May 2003 19:26:21 -0000
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1062,1069 ****
--- 1062,1071 ----
Given that other unwind mechanisms generally won't work if you try
to represent stack pointer saves and restores directly, we don't
bother conditionalizing this at all. */
+ #ifndef __s390__
tmp_sp = (_Unwind_Ptr) context->cfa;
orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif
/* Compute this frame's CFA. */
switch (fs->cfa_how)
*************** uw_init_context_1 (struct _Unwind_Contex
*** 1164,1169 ****
--- 1166,1174 ----
/* Force the frame state to use the known cfa value. */
context->cfa = outer_cfa;
+ #ifdef __s390__
+ context->reg[__builtin_dwarf_sp_column ()] = &outer_cfa;
+ #endif
fs.cfa_how = CFA_REG_OFFSET;
fs.cfa_reg = __builtin_dwarf_sp_column ();
fs.cfa_offset = 0;
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 19:39 ` Ulrich Weigand
@ 2003-05-07 19:45 ` Mark Mitchell
0 siblings, 0 replies; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 19:45 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: rth, gcc, gcc-patches
On Wed, 2003-05-07 at 12:39, Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
> > Yes -- but please enclose the second hunk in #ifdef as well. If we're
> > going to be ugly, let's not try to be smart while we're being ugly.
>
> Fine with me.
>
> > Please check this in, and close the PR.
>
> For the record, I've checked in the patch below and closed the PR.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 17:02 ` Ulrich Weigand
2003-05-07 17:09 ` Joe Buck
2003-05-07 17:11 ` Mark Mitchell
@ 2003-05-07 18:19 ` Jonathan Lennox
2003-05-07 18:27 ` Mark Mitchell
2 siblings, 1 reply; 175+ messages in thread
From: Jonathan Lennox @ 2003-05-07 18:19 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Mark Mitchell, rth, gcc
Ulrich Weigand writes:
> + #ifndef __s390__
> tmp_sp = (_Unwind_Ptr) context->cfa;
> orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
> + #endif
Doesn't __s390__ indicate the build system, not the target?
--
Jonathan Lennox
lennox@cs.columbia.edu
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 18:19 ` Jonathan Lennox
@ 2003-05-07 18:27 ` Mark Mitchell
2003-05-07 18:30 ` Jonathan Lennox
0 siblings, 1 reply; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 18:27 UTC (permalink / raw)
To: Jonathan Lennox; +Cc: Ulrich Weigand, rth, gcc
On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> Ulrich Weigand writes:
> > + #ifndef __s390__
> > tmp_sp = (_Unwind_Ptr) context->cfa;
> > orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
> > + #endif
>
> Doesn't __s390__ indicate the build system, not the target?
Yes, but this code is built with the new GCC, so I think that will work
our correctly.
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 18:27 ` Mark Mitchell
@ 2003-05-07 18:30 ` Jonathan Lennox
2003-05-07 18:36 ` Mark Mitchell
2003-05-07 18:49 ` Daniel Jacobowitz
0 siblings, 2 replies; 175+ messages in thread
From: Jonathan Lennox @ 2003-05-07 18:30 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Ulrich Weigand, rth, gcc
On , May 7 2003, "Mark Mitchell" wrote to "Jonathan Lennox, Ulrich Weigand, rth@redhat.com, gcc@gcc.gnu.org" saying:
> On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> > Doesn't __s390__ indicate the build system, not the target?
>
> Yes, but this code is built with the new GCC, so I think that will work
> our correctly.
What about cross-compilers to s390, or built on it?
("They don't work" is a fine answer.)
--
Jonathan Lennox
lennox@cs.columbia.edu
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 18:30 ` Jonathan Lennox
@ 2003-05-07 18:36 ` Mark Mitchell
2003-05-07 18:49 ` Daniel Jacobowitz
1 sibling, 0 replies; 175+ messages in thread
From: Mark Mitchell @ 2003-05-07 18:36 UTC (permalink / raw)
To: Jonathan Lennox; +Cc: Ulrich Weigand, rth, gcc
On Wed, 2003-05-07 at 11:30, Jonathan Lennox wrote:
> On , May 7 2003, "Mark Mitchell" wrote to "Jonathan Lennox, Ulrich Weigand, rth@redhat.com, gcc@gcc.gnu.org" saying:
>
> > On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> > > Doesn't __s390__ indicate the build system, not the target?
> >
> > Yes, but this code is built with the new GCC, so I think that will work
> > our correctly.
>
> What about cross-compilers to s390, or built on it?
They will set __s390__ if they are cross compilers to __s390__, and will
not set it if they are not, so all will be well.
And, in fact, even were this broken it would not be too bad -- it's not
like s390 is one of our most-used platforms. The goal here is to get a
minimally intrusive patch that makes it possible for s390 people to use
GCC 3.3.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 18:30 ` Jonathan Lennox
2003-05-07 18:36 ` Mark Mitchell
@ 2003-05-07 18:49 ` Daniel Jacobowitz
1 sibling, 0 replies; 175+ messages in thread
From: Daniel Jacobowitz @ 2003-05-07 18:49 UTC (permalink / raw)
To: Jonathan Lennox; +Cc: Mark Mitchell, Ulrich Weigand, rth, gcc
On Wed, May 07, 2003 at 02:30:23PM -0400, Jonathan Lennox wrote:
> On , May 7 2003, "Mark Mitchell" wrote to "Jonathan Lennox, Ulrich Weigand, rth@redhat.com, gcc@gcc.gnu.org" saying:
>
> > On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> > > Doesn't __s390__ indicate the build system, not the target?
> >
> > Yes, but this code is built with the new GCC, so I think that will work
> > our correctly.
>
> What about cross-compilers to s390, or built on it?
>
> ("They don't work" is a fine answer.)
This code is built for the target, not for the build machine. Checking
__s390__ should be correct. (It's part of libgcc)
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 14:54 ` Ulrich Weigand
2003-05-07 15:53 ` Mark Mitchell
@ 2003-05-07 17:51 ` Richard Henderson
2003-05-07 19:42 ` Ulrich Weigand
1 sibling, 1 reply; 175+ messages in thread
From: Richard Henderson @ 2003-05-07 17:51 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: mark, gcc
On Wed, May 07, 2003 at 04:49:12PM +0200, Ulrich Weigand wrote:
> However, this now triggers again the new code that sets the
> stack pointer to the cfa, incorrect on s390.
If I understand correctly, then this would be fixed by
+ #ifndef __s390__
_Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
+ #endif
correct?
> Would you suggest to check the above patch in anyway to make 3.3
> more similar to head (apparently the patch is already in 3.2 ...),
> and because it fixes at least C++?
Well, not to make it more similar to head, but because it gets
more cases demonstrably correct. On s390 and elsewhere.
r~
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: GCC 3.3 Prelease broken on s390
2003-05-07 17:51 ` Richard Henderson
@ 2003-05-07 19:42 ` Ulrich Weigand
2003-05-07 19:46 ` Mark Mitchell
0 siblings, 1 reply; 175+ messages in thread
From: Ulrich Weigand @ 2003-05-07 19:42 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ulrich Weigand, mark, gcc
Richard Henderson wrote:
> If I understand correctly, then this would be fixed by
>
> + #ifndef __s390__
> _Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
> + #endif
>
> correct?
Basically yes, except that then the initial cfa is no longer
found when called from uw_init_context_1. This is fixed by the
second hunk of the patch I just committed ...
> > Would you suggest to check the above patch in anyway to make 3.3
> > more similar to head (apparently the patch is already in 3.2 ...),
> > and because it fixes at least C++?
>
> Well, not to make it more similar to head, but because it gets
> more cases demonstrably correct. On s390 and elsewhere.
We should certainly fix it properly on the head and for 3.3.1.
Whether this is something for 3.3 I have no strong opinion on
-- that's Mark's call ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc
[not found] <no.id>
` (39 preceding siblings ...)
2003-05-07 1:13 ` GCC 3.3 Prelease broken on s390 Ulrich Weigand
@ 2003-07-05 17:01 ` John David Anglin
2003-10-08 3:11 ` Someone broke bootstrap John David Anglin
` (2 subsequent siblings)
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2003-07-05 17:01 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, jh, pinskia, ro
> I have seen the same error but in a different place for the past two days:
>
> stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -gstabs -O2 -DIN
> _GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
> ic -Wno-long-long -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I.
> -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../
> include -I../intl ../../gcc/gcc/genautomata.c -o genautomata.o
> ../../gcc/gcc/genautomata.c: In function `automata_list_eq_p':
> ../../gcc/gcc/genautomata.c:4463: error: head insn 90 for block 0 not found in t
> he insn stream
> ../../gcc/gcc/genautomata.c:4463: internal compiler error: Segmentation fault
Zdenek's patch
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00457.html
fixed the above failure. However, there are still a bunch of new segmentation
faults in the testsuite. For example,
Executing on host: /home/dave/gcc-3.4/objdir/gcc/xgcc -B/home/dave/gcc-3.4/objdi
r/gcc/ -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -w -c
-o 20000728-1.o /home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000
728-1.c (timeout = 300)
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c: In func
tion `foo':
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c:15: inte
rnal compiler error: Segmentation fault
The stack backtrace is:
#0 0x000ec654 in verify_dominators (dom=0x486f58)
at ../../gcc/gcc/dominance.c:695
#1 0x002f4bcc in unroll_and_peel_loops (loops=0x486e48, flags=4739680)
at ../../gcc/gcc/loop-unroll.c:145
#2 0x0029b614 in rest_of_handle_loop2 (decl=0x486e48, insns=0x401d1ba0)
at ../../gcc/gcc/toplev.c:3303
#3 0x0029bda4 in rest_of_compilation (decl=0x401d0a80)
at ../../gcc/gcc/toplev.c:3576
#4 0x0003e438 in c_expand_body_1 (fndecl=0x401d0a80, nested_p=0)
at ../../gcc/gcc/c-decl.c:6379
#5 0x002d4500 in cgraph_expand_function (node=0x40017340)
at ../../gcc/gcc/cgraphunit.c:282
#6 0x002d46c8 in cgraph_expand_functions () at ../../gcc/gcc/cgraphunit.c:372
#7 0x002d49d0 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:462
#8 0x0007dfe0 in c_objc_common_finish_file ()
at ../../gcc/gcc/c-objc-common.c:363
#9 0x00019d3c in yyparse () at c-parse.y:339
#10 0x0006f398 in c_common_parse_file (set_yydebug=4732136)
at ../../gcc/gcc/c-opts.c:1188
#11 0x00298e20 in compile_file () at ../../gcc/gcc/toplev.c:2069
#12 0x0029e3d0 in do_compile () at ../../gcc/gcc/toplev.c:4959
#13 0x0029e44c in toplev_main (argc=18, argv=0xfaf005b0)
at ../../gcc/gcc/toplev.c:4990
It appears dom_bb is 0x0.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Someone broke bootstrap
[not found] <no.id>
` (40 preceding siblings ...)
2003-07-05 17:01 ` Solaris 8/SPARC bootstrap broken building 64-bit libgcc John David Anglin
@ 2003-10-08 3:11 ` John David Anglin
2003-10-08 7:25 ` Eric Christopher
2004-01-06 0:43 ` autoconf changes break bootstrap on hppa*-*-hpux* John David Anglin
2007-04-15 19:13 ` Call to arms: testsuite failures on various targets John David Anglin
43 siblings, 1 reply; 175+ messages in thread
From: John David Anglin @ 2003-10-08 3:11 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
> There are also a bunch of testsuite regressions on hppa64-hp-hpux11.11.
See <http://gcc.gnu.org/ml/gcc-testresults/2003-10/msg00324.html>.
The gcc.log has messages similar to the following for the new regressions:
/xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/compat/scalar-by-value-1_x.c:154: inte
rnal compiler error: in copy_rtx, at rtl.c:377
Please submit a full bug report,
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Someone broke bootstrap
2003-10-08 3:11 ` Someone broke bootstrap John David Anglin
@ 2003-10-08 7:25 ` Eric Christopher
2003-10-08 17:26 ` John David Anglin
0 siblings, 1 reply; 175+ messages in thread
From: Eric Christopher @ 2003-10-08 7:25 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, zack
On Tue, 2003-10-07 at 20:11, John David Anglin wrote:
> > There are also a bunch of testsuite regressions on hppa64-hp-hpux11.11.
>
> See <http://gcc.gnu.org/ml/gcc-testresults/2003-10/msg00324.html>.
>
> The gcc.log has messages similar to the following for the new regressions:
>
> /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/compat/scalar-by-value-1_x.c:154: inte
> rnal compiler error: in copy_rtx, at rtl.c:377
> Please submit a full bug report,
I'm seeing this on frv too. I blame Zack (at least in the little bit of
looking I did...), but that's ok. I'm sure he'll fix it.
-eric
--
Eric Christopher <echristo@redhat.com>
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Someone broke bootstrap
2003-10-08 7:25 ` Eric Christopher
@ 2003-10-08 17:26 ` John David Anglin
0 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2003-10-08 17:26 UTC (permalink / raw)
To: Eric Christopher; +Cc: gcc, zack
> I'm seeing this on frv too. I blame Zack (at least in the little bit of
> looking I did...), but that's ok. I'm sure he'll fix it.
Yes, it looks as if this is caused by one of Zack's recent changes.
We have:
#0 0x400000000035ee3c in copy_rtx (orig=0x0) at ../../gcc/gcc/rtl.c:377
#1 0x40000000002f869c in emit_libcall_block (insns=0x800003fffed1f550,
target=0x800003fffed20600, result=0x800003fffed1f2d0, equiv=0x0)
at ../../gcc/gcc/optabs.c:3397
#2 0x40000000002f9430 in emit_cmp_and_jump_insns (x=0x800003fffed3bfa0,
y=0x800003fffeff2768, comparison=NE, size=0x72, mode=TFmode, unsignedp=0,
label=0x800003fffed3bf50) at ../../gcc/gcc/optabs.c:3946
emit_libcall_block is called with equiv=0 when optimize is 0. We end
up trying to copy a NULL_RTX at optabs.c:3397.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: autoconf changes break bootstrap on hppa*-*-hpux*
[not found] <no.id>
` (41 preceding siblings ...)
2003-10-08 3:11 ` Someone broke bootstrap John David Anglin
@ 2004-01-06 0:43 ` John David Anglin
2007-04-15 19:13 ` Call to arms: testsuite failures on various targets John David Anglin
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2004-01-06 0:43 UTC (permalink / raw)
To: John David Anglin; +Cc: neroden, gcc
> > So how, precisely is config.cache "not found"? Is it deleted between line
> > 489 and line 491? Or is your shell busted?
> The PATH environment variable isn't set correctly.
Possibly, I should add that /bin/sh under hpux 11 is the POSIX shell
and supposedly conforms to the POSIX standards in effect at the time
hpux 11 was introduced. This means that the source command doesn't
search the current directory. If I add `.' to PATH, then config.cache
is found.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: Call to arms: testsuite failures on various targets
[not found] <no.id>
` (42 preceding siblings ...)
2004-01-06 0:43 ` autoconf changes break bootstrap on hppa*-*-hpux* John David Anglin
@ 2007-04-15 19:13 ` John David Anglin
43 siblings, 0 replies; 175+ messages in thread
From: John David Anglin @ 2007-04-15 19:13 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, fxcoudert
> * hppa64-hp-hpux11.11: many failures
Most of these are "Type/rank mismatch in argument":
FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:22: E
rror: Type/rank mismatch in argument 'charr' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:23: E
rror: Type/rank mismatch in argument 'charr' at (1)
In gfortran.dg/entry_1.f90:
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:15: Error: Type/rank mis
match in argument 'p' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:16: Error: Type/rank mis
match in argument 'p' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:40: Fatal Error: Can't o
pen module file 'm.mod' for reading at (1): No such file or directory
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 175+ messages in thread