public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libobjc/917: Build failed
@ 2001-06-16 6:06 neil
0 siblings, 0 replies; 2+ messages in thread
From: neil @ 2001-06-16 6:06 UTC (permalink / raw)
To: ask, gcc-bugs, gcc-prs, nobody
Synopsis: Build failed
State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Sat Jun 16 06:06:29 2001
State-Changed-Why:
I imagine this has been fixed. If you can reproduce it with 3.0, I'll reopen the PR.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=917&database=gcc
^ permalink raw reply [flat|nested] 2+ messages in thread
* libobjc/917: Build failed
@ 2000-11-28 6:36 ask
0 siblings, 0 replies; 2+ messages in thread
From: ask @ 2000-11-28 6:36 UTC (permalink / raw)
To: gcc-gnats
>Number: 917
>Category: libobjc
>Synopsis: Build failed
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Nov 28 06:36:02 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: Alexander Klimov
>Release: Nov 28 16:19:10 IST 2000 from cvs
>Organization:
>Environment:
SunOS iridium 5.6 Generic_105181-20 sun4u sparc SUNW,Ultra-5_10
>Description:
I get gcc from cvs today, run
../gcc/configure --prefix=/usr/local/gcc --enable-shared && make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
from separate directory and get:
...
/export/home/ask/build/gcc-build/gcc/xgcc -B/export/home/ask/build/gcc-build/gcc/ -B/usr/local/gcc/sparc-sun-solaris2.6/bin/ -B/usr/local/gcc/sparc-sun-solaris2.6/lib/ -isystem /usr/local/gcc/sparc-sun-solaris2.6/include -shared -Wl,-h -Wl,libobjc.so.1 -o .libs/libobjc.so.1.0.0 .libs/archive.o .libs/class.o .libs/encoding.o .libs/gc.o .libs/hash.o .libs/init.o .libs/linking.o .libs/misc.o .libs/nil_method.o .libs/NXConstStr.o .libs/Object.o .libs/objects.o .libs/Protocol.o .libs/sarray.o .libs/selector.o .libs/sendmsg.o .libs/thr.o .libs/thr-objc.o -lc
Text relocation remains referenced
against symbol offset in file
__objc_class_name_Object 0x0 .libs/NXConstStr.o
__objc_class_name_Object 0x1c .libs/linking.o
__objc_class_name_Object 0x0 .libs/Protocol.o
__objc_class_name_NXConstantString 0x20 .libs/linking.o
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
make[2]: *** [libobjc.la] Error 1
make[2]: Leaving directory `/export/home/ask/build/gcc-build/sparc-sun-solaris2.6/libobjc'
make[1]: *** [all-target-libobjc] Error 2
make[1]: Leaving directory `/export/home/ask/build/gcc-build'
make: *** [bootstrap] Error 2
>How-To-Repeat:
My compiler is gcc version 2.95.2 19991024 (release)
>Fix:
I guess -fPIC should be added somethere in makefiles, but it is only guess
>Release-Note:
>Audit-Trail:
>Unformatted:
>From jakub@redhat.com Tue Nov 28 07:56:00 2000
From: jakub@redhat.com
To: gcc-gnats@gcc.gnu.org
Subject: c++/919: segfault in setup_class_bindings
Date: Tue, 28 Nov 2000 07:56:00 -0000
Message-id: <20001128155107.26563.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00602.html
Content-length: 845
>Number: 919
>Category: c++
>Synopsis: segfault in setup_class_bindings
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Nov 28 07:56:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: jakub@redhat.com
>Release: g++ 2.97 20001128
>Organization:
>Environment:
i386-redhat-linux
>Description:
G++ segfaults on
struct a { int a; };
struct b : a {};
grokdeclarator has a comment that field can have the
same name as enclosing class if it does not have
explicit constructor but apparently this is not handled
properly by dfs_push_type_decls.
>How-To-Repeat:
cat >test.C <<EOF
struct a { int a; };
struct b : a {};
EOF
g++ test.C
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
>From fandrieu@canal-plus.fr Tue Nov 28 09:46:00 2000
From: fandrieu@canal-plus.fr
To: gcc-gnats@gcc.gnu.org
Subject: c/920: Error while building cross gcc for m68k target
Date: Tue, 28 Nov 2000 09:46:00 -0000
Message-id: <20001128173720.5859.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00603.html
Content-length: 2918
>Number: 920
>Category: c
>Synopsis: Error while building cross gcc for m68k target
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Nov 28 09:46:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: fandrieu@canal-plus.fr
>Release: gcc version 2.96 20000731 (Red Hat Linux 7.0)
>Organization:
>Environment:
Linux Redhat 7.0 with binutils-2.10.1
>Description:
Compilation stops :
/usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/gcc/xgcc -B/usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/gcc/ -B/usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/m68k-coff/newlib/ -isystem /usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/m68k-coff/newlib/targ-include -isystem /usr/src/redhat/SOURCES/gcc-2.96-20000731/newlib/libc/include -B/usr/local/m68k/m68k-coff/bin/ -B/usr/local/m68k/m68k-coff/lib/ -isystem /usr/local/m68k/m68k-coff/include -O2 -DCROSS_COMPILE -DIN_GCC -g -O2 -isystem ./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I../../../../../gcc-2.96-20000731/gcc -I../../../../../gcc-2.96-20000731/gcc/config -I../../../../../gcc-2.96-20000731/gcc/../include -fexceptions -DL_eh -c ../../../../../gcc-2.96-20000731/gcc/libgcc2.c -o libgcc/./_eh.o
../../../../../gcc-2.96-20000731/gcc/libgcc2.c: In function `eh_context_static':
../../../../../gcc-2.96-20000731/gcc/libgcc2.c:3161: warning: alignment of `eh' is greater than maximum object file alignment. Using 2.
/usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/gcc/xgcc -B/usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/gcc/ -B/usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/m68k-coff/newlib/ -isystem /usr/src/redhat/SOURCES/gcc-2.96-20000731/INSTALL/__build/build_gcc/m68k-coff/newlib/targ-include -isystem /usr/src/redhat/SOURCES/gcc-2.96-20000731/newlib/libc/include -B/usr/local/m68k/m68k-coff/bin/ -B/usr/local/m68k/m68k-coff/lib/ -isystem /usr/local/m68k/m68k-coff/include -O2 -DCROSS_COMPILE -DIN_GCC -g -O2 -isystem ./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I../../../../../gcc-2.96-20000731/gcc -I../../../../../gcc-2.96-20000731/gcc/config -I../../../../../gcc-2.96-20000731/gcc/../include -c ../../../../../gcc-2.96-20000731/gcc/frame-dwarf2.c -o libgcc/./frame-dwarf2.o
../../../../../gcc-2.96-20000731/gcc/frame-dwarf2.c: In function `add_fdes':
../../../../../gcc-2.96-20000731/gcc/frame-dwarf2.c:284: Internal compiler error in find_auto_inc, at flow.c:5002
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
make[2]: *** [libgcc/./frame-dwarf2.o] Error 1
m
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
>From ejm@onmedia.com Tue Nov 28 10:06:00 2000
From: ejm@onmedia.com
To: gcc-gnats@gcc.gnu.org
Subject: c++/921: 2.95.2 generates incorrect ref to static initialized char[] in classes. 2.8.1 works fine
Date: Tue, 28 Nov 2000 10:06:00 -0000
Message-id: <20001128175749.16296.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00604.html
Content-length: 20837
>Number: 921
>Category: c++
>Synopsis: 2.95.2 generates incorrect ref to static initialized char[] in classes. 2.8.1 works fine
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Nov 28 10:06:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: ejm@onmedia.com
>Release: gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
Tested on i386-pc-solaris2.7 and i386-unknown-freebsdelf
>Description:
When referencing an initialized const static char[] from a class, the compiler generates a ref. to the static member rather than the string. I'm not a C++ expert, so perhaps I'm violating the language, but compiler versions 2.8.1 and prior worked fine. 2.95.2 generates an incorrect reference.
>How-To-Repeat:
info.zip contains 2 zips (one with files from 2.8.1 that work and one with 2.95.2 files that don't work) plus "x.cc"
x.cc for reference:
#include <iostream.h>
class X {
public:
void doit();
const static char xyz[]= "123";
};
main()
{
X x;
x.doit();
}
void
X::doit()
{
cout.form("xyz is %s\n" , xyz);
}
Compile on 2.8.1:
% g++ -v -o x x.cc
% ./x
xyz is 123
%
on 2.95.2:
% g++ -o x x.cc
/var/tmp/cck56486.o: In function `X::doit(void)':
/var/tmp/cck56486.o(.text+0x32): undefined reference to `X::xyz'
collect2: ld returned 1 exit status
%
>Fix:
I'm either a c++ bozo, or someone smarter than me needs to look at the g++ code generation...
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/x-zip-compressed; name="info.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="info.zip"
UEsDBBQAAAAIANJWfClitKSVmAAAAMgAAAAEAAAAeC5jYz2N3QqCQBCFr3dg3mHYCBRCqO7s5zmE
6mJbDQd0N5w1rPDdcxO8Pec731mxs01fVnRkL6GrTJvVZwQE2xgRKuiL8OzvDdscQb08l1R6Dkl6
iJCy3kkgCSawJVubjob353I7kd7u9npixj/XGnZJijDJVKGGeTtki2mMAULUIxR5Phczb30fsofv
2kRPbmKhtVydpk28WsY/UEsDBAoAAAAAANBWfCkaTX4JARkAAAEZAAATAAAAd29ya3Mtd2l0aDIt
OC0xLnppcFBLAwQUAAAACACmVnwpZUqL6X0VAADtXAAABAAQAHguaWlVWAwACPEjOgjxIzroAwAA
vVzrb9tIkv9s/RWdBKeR5EdsJ+PNWFEG2L3buQCHPRzuywCzA4KiKJkbmRT4sJ11PH/71qMf1WST
kieZdRCb7K76VXV3dXVVd0uv1IV6+XCWJC9Hr/DxdVOVr7dFEm9fZ3mybVbp683x8eusqOoyjW/P
bl4C1ZuRGvX+vNqV8eY2Vllep+U6TlIqHMBm5GWzPgA8iK4UcaQPUJSrl395qR4HBW6zZVYcIiyg
95t3V6dN/ikv7vPTdZmmy2p1eXZ59r0VEP0UJUW+zjZWgJBQf96lq3St7A80A34DDzy8i2oVRXFd
l9myqdMomkyi6LZY4VMU/d/HKJpOp3OL0eRVtsnTFWMARPN8DF8PVuPiahDjvwf10Go8FyOkx5vL
QYz/P0SP52KE9Lh6O4jxn4focSjGKIrQigGhyKNIGchtkW/4F+Bt8WHeQ2mFeyyN5mmboU+NlgtW
/imq+xuzSu9ktVEHH9a7ohpi3WSroeosL4LV1U1REgH11iBFvs3yT33qFeu1rNJSd6yU6BNTUZer
zGdpawxvVVq32LtE//S0NurU2W24NdZqVgF175ObuNQS5U+LrGpLtW7mHp5kBeKpGdbcxdE2q7rQ
0gcaH1fVK2A+zIMOwNzGyU2Wp69jaPszwQJ0qq+2RfpKvfmhtz2XoILtziPstiNhCa0qdVQ2eWqH
w1R5Q3lkhqLLHBjMV+rd1desN6w+tPB8/+LHtJ1B+v77/axvega0+ly9TqCB1XNHs3+02updnL8d
EvpmH8JzfqAzfnhuP3aEv1I/XB3ao30YwzUQPzUJzPuP/xv9o7ndgUUpJcr++vF//muOrNB5V89T
BVdC4ynuimxFeGaJMAoJUbdx+SktIfryFNClsyiHFWs+6igHNRVEf3OO4/AXr78RLChz1PqHA0YB
tH6ae8oQ9KPBWm/jTTU/OlIjIwL/4wycETWEoCt0+vOjQHmar4Lly7hK2xX3ZQbre39NQAZXBIRA
rwSRsNySmyroRqiq4jstvVWxjJNPzc5UBZgQkAcgNHb8UM1HwfEDqCynOu7sbJvmxdy8Lref0AvO
2aTMWgxP8BdWUF2OKrXX9KQpwbttm9t8bhSOmryp0pV7J1LokV8ufp3bXIB+nrzFrKV1tNs20Byd
NIQq6Q2WhiyPTsxz0dTuJS3LyM4DM08YafTILdUrsVKTGVrMFB46vXfCcwv+CgagnHcgyFB6MGAR
qOphJI7QEKhK0089OHZ4TnDwNDMO42QG0WEVFk9kT1SQFMWnLI2yIlo3eVJDeEpRIfSQ4NJEaCej
x4BFYQWNsGjUXR0vuZTfGYOa1idWyde5tgcvTbSvZKhgWzCo621xD41stc6nO4CmuAtAuU7t/Ehm
oN+kdeKxRjB+HSlQu2uIkIUmJ2o/xzot1gdBr8HCizJM2lEDTCqhxQGmb5hDZul2OVkjC453b3c6
0ibfS2xVr8vP/cRDHX+3rpI4X7eGjS2RXeaJiJd5moR1uFvvSng+GEpiyIlP3Ruv8q4ldSe6YBfc
FVhTm126CgEgu0T4DEKBIQbf0MLxHYYz8H4MeO1iaCI5QTrjD/GvWcdicKehcX1C9SEA7g90vO0m
Ct6eBkNG6y+Oj9FjJNu4qlTGKLhgckFhCvjVCpmLoE2kpXoFZDJ48XJW019cS1GQrLZ2wfV6ae3J
6aP1bc2xT5eC188I9/biOhXRE5SAb063q2r0yLGSaxBGa3Vp4jXTbohLanbGes2/z1b1Db87HUwY
xoi0xFOwsDWEWhVY1FmjVmn6kKQ77cytpF2ZJhlug/Dqr+0aDKSMP1c4QE8dZwsx5eXbwwwEo2E9
5GC112rXLLdZIruIY8yiGqtil5ZxXZSLCb5OdZiFfBOe86YYShnn2guxRUe5UZME2F47Wu0KkJ7j
Hkm3RtoJ1qV5c4tLI/fq4+hoUxSrZVarhTpXJ6MjWB747QLf1nG25ddLfF3GmvStUk8CD8XTHg0C
ZrnhhoDJcKIwZMPH3Q4e3+EjmFyeIPUVvuVFAroS4ZtLLijT3TZOsOSKeJcMfgnc0JP4GpefdYmn
EbqaaJVBPqKW6Qb8blOeQM3qye8hnxYf4C+TKAf2qKpP2e6+gi6idkH5Nl3X8ApqqjLb3ODzW/Zf
4C/iLVKea9JVmiAlvKoiIUJ8vEkfiMhQwYy4x/icSJEAC3YFABKHIWt2YGcJ0wGzI6yY0cIlWZrX
2TpLmB0J19lDutJ8Fi/PMH7WzAQHQW+hmc7JfSGd7NtH6nrQgebAAtp3DA07hhahxWyLuKYKGBan
xTEJx9Ff/aOpLAF24zF14LHpOpKD0xYm6p/+dPhE9RwS+KPJVC+2j6pM6wZXI/RS6qlLaV/u4u0U
6O075kYLZsPfC6ifGzSsQzRhLNqroVMLSCdfp8VLSv2cp/fr6ejoUb8W29UaOkhz0R94RSKrAZLM
Gc/5DvwdEk4ORQWp7SugR9wFMI6mEKRgIenCIPyXtYlkl2hSIwbdj3XQAZ2c8w4y4BtI2JE6reQQ
JKETkRDuGSomPv0UceajI6fnrtMXkIyuXVeEugFcX+W6YXSk++HLQrU6AQn345+4utu4+nSoOGic
fhqr35jxi5rgCI0ZZ68m0DeeLs+RPl6w0D4hOGi0/AfGm8OCDiE+6YlHCxbMKxSsqfmv8vvYzr2R
WPaj+qYs7iNcsppSTv8nQZRs07icmKCCf4Ozo+ZH5lUHOepHTXDNf7/w8gedka1hELhuLCOTaUcJ
01wSDt1uRWN3YpM1DBgRlnwVNjHtE4C++/kicGAwUAiMqu406ERJDGFEL+0Y45jra440JBOKHeCa
EBsPwhd61uGJpybU75Osx9Ew6Q4rV9yBPcx25dCBHnX7rEutG/EjzEkkmJ6D+ejHyemFp6qBetGH
0lbRDVVASxEgS8MQPBYmx90UtnlXDYbPFc82Qj9JmEFPwp9gP1LuYNbANoOXZkwptG5nHwVFDRbI
TFQsmvPcVhPnAJFc6BfXELyTi/mcJ+BX6hva4SvIAxX5dC7peFK1CHE+tcvckGpO60XBxuItRC4T
HxmlPXgVZB1jtbsvyhUqI4tFKfcn12GCB9bc4qC0L+sw2B8XqnBa8xGiP93PMidRXEHNfbLxGNCU
RZ0mdbq61ia8zfIUjXMixrJaokM98SKsqC7Iy84l311W1g0sW78hQKsKOz8DHXxgH1QjPnnHazzB
bUQfmac57dOaf/RLJut6qxtSvDK7o3TTP9GA1bOEUHbVzfClA9Z72mxP9EgOGLc8FrqAbUV2tlRA
ToFqqfvkN49i6rJfWAWzfEOjpA1eXUj3skq3dTyR3GPBzbW6A3Xy78S7ZNeepmjL8ToiK3SW6pfq
/ZBuTdFbI9Xkarn/O454B1g2djZxFDNwrnY/aDatb7JKHSszNVt2q+ehMC3agotijLS5kRZqrB7o
fEMK1ice0slGTR7hBQQ5oxWVRMirG0RnOJtdXRrfqGdbK0xX4HPPHzA1hFXEO9eBYfHOq7QKDLwT
wALSO3zyGNLfqwqOmtCEDo884H2qdDh22LohDj668oTgZuC36EiClsj9utgzuZYmwdVOnNXJ8GSb
hnIhR6xOg6LIoh52TY3WV05o+y5Bo5x5I3x8DK4mkQIfTErY7pwAEQVhQEl/XcqnbM4HRS7/XG/n
UjdMKjwUy/SFuPppeRud0hA7kE7gxA2my3fWLtsRuJtlc7vjxLGLJGxh4hnD8SKfXk/kxMIS2bad
wEVE2ePqGBLhdii+nGhTOrE2wo2MF+dTf9HYadKdJd0J3b0JsPAELyCH9abUIt219dhMnHjtfk70
6UO6cSEWhXutbpoGt90n6Fqh0zWjN4kwgFzOPQ8FRZu55ymQaCPnD6x0+hDXs1FTaOM32v/MtS4B
czZ6G2wlJPykp7TlkUD7XEMAL/2JHdw+vH5HKdH+vF8718fXvrZ+T/65pVbn7D/QlDZPj3DXFHdh
QIr+W7sRA2qmfwvo2YbF8b5h/s6Ie+P1AneuO1z6zoLHpst8DpoqHTOXk7TJKw/RBAm0XQUOGTe+
ewzy3bmvWgWJQ3ID4TAe8WpGluSnROwXEUb7Cz9itHnEettUNxi4TALZi63EQAQXqXVapiunvw3A
nVjTbF1Dgaw+yiaVcLMes1jVAcFae4LelUHV/VU77HvKeUkKquHRuFMMWDugz/OJO0iFzOBEEuSt
Rni8eBY6OZwLQ3d98jmx53UnLq3QKxeM44ISjyznjYmiqQfxdjZnwhL474CghwNQwjyIo1l21FKF
UEythlTrhEvigJc8/AmCAQSyi/y2Jf6ZreiTisxaKmH0CK2+biBaQM8ege5gclaa0tJl13AEgRAv
MJFw4yA0wVYFbQbQ1tPcrXWoJLocP4FT+PfEJXBeWg1MMDdwKiUmQBRVTY7XSmQC2eTOKQTc1yWG
Shfg9b2dPd+XBL3eJUdZHqv2pJaTlnM876DgI5sqt5t+CS4z3YJnF3vOl76/9pQYgGJdunCm3DXL
jQGfbyGUXtK+fPF6ampafD4fHRGwfvcG0ltqSWeqNGGOgMetU4i2NDd7YdlWr0KGQvEdbzV6E8ou
1qfBVJE8OqxZ93FWtzYP/Kj2tCf5Ei5zvyN24NprA0E+DUDhDRc2WXjqBTF3YYyzQNIg3JCbb/kf
omQ8Tznq4w2eQIv9NdoGh4WbryV6ezGutLUdhxLQXE1G0KzltRuV63gcZnN2e2JiCpzDERW1Jnei
F8hWp2BFcqJ0cC7iDUxckvYokx/o0rJ7cKSTiSJEpaanH7yo/gNEAaE6tLvx2LtL5+jQ0Cl2wASM
/l6r2cS/kDKbhoFBKN7xkdrihWJSV+9Wt/Qb0ImbbtWZ4gG3aTIWtKa1lxgen5h+8lOtuqiqxM5s
T5n3ni7TFp5s0x1ePtOem2bVbH1bn3vXxFSMa0xRzbRR07UNaSMhBHV2diZo7tZFebtXjGAI0mtQ
ewTXjbaqzxU1VFq+rIZf/aEaMpP3kQ5G8vfHV8CJi2cwTgiuy1VEt1tDizOBQUytT3Dm+oYx7Yfj
RjJvXuJFQ2/X1G2kPnb3H93udl9or28M6Ys9yG6CZi3JqGpeaZRWwUKT+HuxiR6038JwMxXXdZzc
BGFnpJMYFTAHvPId36b+9UYO4w5m5VBL32OiOEx7Q2g9WvnV1dvA+MiU4+DUxTn4KiKNgpc10rxA
R+IFP+vA2aID+dHyXWtPYo7eTft77cwPAv/4ROSA2PX35Fy/L9fyo2M3W5QaKTlW6ExaQYvZBX6x
MNvZ/t4sfoigvcEhgX5UZkP+Wm+gdzdJZjR+bRi9B9QK9L6dF3yuK/sK39nj6AYdpfGC3okdW97w
sV1UF7Rou+sW1RKGgXjNXcRr/5xeHEAvMOg+0ue+i2rJF7MAhJHNfREg4ztTi+/Ud6Dlkb6/wpOD
b/PxBFmlCTUGKOwFosUVcPMdUqUdwMgddkIT2yeeoRbq80uo00UdGD74pA8isJVj5MBipxgPptA7
v/xqNJmPnkZPuPy8Um8O+6w+fzht+Apz61hOnKKO1WQWRbdxnu2m+k6rq2Z6JskMjS4UdIWkKzRd
4ejspXlDd19ZGOg/iE8NhUWiTS2LgblMiAoCre0hRFWHyL/SDZZoZoBe2aEnRo/t1G5VREW1fuiu
5xpGnKSbkgH7WbViumKH0CbQfcH3cLpZqA49AWBKk+L0A/cVzmV7ZnMxf5JxK2uNGS9OKzZBc15k
LtzoK6I8XejOw3RKxPjjWu63zwzUdO6Xwjoizq70PD79wKlN4q5uzDBGN1e8fIi2Z1Oz8OoSZGil
G23O9hYVs0o3OuUs8alfxB8ugI/EvxUybYa5rbB258nq4PrjVqs63W53nRHn5EGGfFAQ1yInsaR3
PbSt1KTcVGajzM1efZXq/Xt/5ytE4NuAzKUnM04N379XBDNNOmYtcL4NimfIA1qH7Ze2vUJy5bDv
F/+HgLKd7gbaxCeqB4zUPkLaaTkIyVISqf9FGr3IHvx+nsAXceRDFst3mnFrylyqdXW0ndSdtSFp
gzCyKxmvF3BZFFu1FAbdVmfpbv2F+FcFrIABPyxI6FMC3maclMEAU96Ma7v/9thYaYdg9SGZ6ETh
J0a9qUwFehIMmbwOlQxAm9Fb1gZcio0KOMR+sgFJdkhA0tpokB8E3CRFk9fifCHCKDi6r7pBS2aC
lmvDpibnLoIx1T0RTDuAMa2EbNBkmnVpc025+wmx9nd/z78LMXpubz+C8F/IzXKnxEUcemfVb5BT
cewOTnqVGHsu30oZT5MgrtgBfn7zifmruoAQntMN7ZY+o6mTf9NQUZv+XX1iM3hY0JA2EG/6tK2F
usvUjteIS6qT92jxR+Hq5fqbAJIZGP8wJv9wiKFXuosxuO2lx70gzIj480Hpyn5+w8uOHs2nLeSn
BGzKBPrqpIk+3TYf6dyHNhPGkPkwMPqxL1/MffbTD+LQ7T3JnrZTLQP0ggAQyaVTYu/BpW/SDQOv
PHi4gBJ9/dpr+bk8o/wGDe5rQ1jzr1D84hsrjv0bGpsFWUS3UT3q8d6Vy4TlZ15AM3Oo80I3wfaA
OSyy6TfuMt+4zydAWquP3+Y2XyYkJDKb0a7x/HkYSavlJDe27Enohl+6YLItsdLziu0d+em1vz1J
3fGmyhcX9lIBTbj2Tjluz6pJe8piKrjp5I7B6gNyx00HX5+E6pTuxs5y/VEkPNaTOwjm5oM423Mf
+DLbiVP3OUAZjVmZdE1iMijK3KT4GjF8UDeUFlvSux7acFpsN0wsv4kvP3zQXnveW98OMgJBNVAZ
59/1+4JIAn0NTk9A1qc0x2U9sihkOUjlr4GB+TIeUJc+uhNOQPvIleE5jKWbf1p5wWZj3jikscwd
D6KT6g4SWtG9pJiMDhJQKjkkjDPAfSOi9pOp5+d4IRizY35YrhkcMJklihTRbVqb3JALTsy7JqB8
0cv4uvvUtmh/muc0wKsNWiZ9RA7KYJw7+oBvddLDPN4XargDg0PI+yjKm4pj2Y4rWuC3WuHBe5TE
Vf3eyPugJshDQ+G3sRhoY9HTxi6PVLpot3GYvI/i4DYWPW00X9wTHsgEv+hNSaJAT0CwAUtTkpal
jxci3RYbXK4CJ0H4/U09Z0FiqR6gKjykfWdBGqpzGlTxB+M+GuUz+sQkxGH0BS/iOG+M3/NB52R4
FxGCwTP6kL05Y9T3G+CJz1Fu0gd9QJ+IcDfDYZCYQNaDid+28fswobYHE2qegUmHkfxFoPQd4urS
fl3Oz8L6j/QJGV93GR3pDWd90QXDmYfP//zl14V6eXH55iV7k1v6xB24qaOfjx6Q6eHMAOCGICKO
fgYtqQzJ0ObO6PTgJaCBhaj/qP6ev1QnCM5c/wJQSwMEFAAAAAgAp1Z8KbBJi+DgAAAAWwEAAAMA
EAB4Lm9VWAwACfEjOgnxIzroAwAAY2hjZE9gQIAQKK0BpUM7nza/YXnx9f///72u/wNeyADFmo+w
GB54zTjh5GFDI2OGisoqhcxiBdViLqj64O5Yjgw5IDtDCUSARF9sBepvPsLTeaA79s/Jw0j2uQMx
GwMDrxOQZmVg4LEF0ixAZAGl2YE0M1CeBcIHA2Ekti5IHxOEbQzEjFBxa6i4AZB2RRL3RmLHA3F6
crJRfHJ+bkFmTmqKHkN8fHx6XilcID65IKe0GIQZ4nMTM/NA8hA6JT+zJD7eMIIBqLa0hCE+Lb8o
Nz7ePL+4pCg1MTfAOTmVAQBQSwMEFAAAAAgAplZ8KSv88htCAQAAoQIAAAMAEAB4LnNVWAwACPEj
OgjxIzroAwAAhZFBb4MgFIDP8CuIaZMtUSKuyVpPS3rtYccdmhCK6FhQjGBj++sHVdFmhx1M3vve
88H7ALiUSoBowJxHsOI8o1zXrWMFziGltGr6QChvVW/8l0NsxWAhwEzJqkEZxJXSF4VozWTjsL21
AoxZ/FH2DbdSN/CR5xC0vflWaCsuLQS1vvrQtPGYm96N2exijyDgTLmhdBqrBFMoIS++89V1sGGZ
5eOxu9DSUkq+IGBFsZo16G5snP78qVt0yvb7ZYs4HQ4p9Cx/HHYVEHTCwlMpiCPYyHvYyrNkvNfp
mPoqM1xKFJHs7ZxGDpIVHG53JA3amjPJfPWvuOXWs7yZrAXO7B+JoTZMtX1wdgnONu7eq5iE2D14
b2ebpe5qSt+1sZ1g9eeRi9krySax0+mzWOfvkE802T0d/Ow0WzkNy3qeLDZ+AVBLAQIVAxQAAAAI
AKZWfCllSovpfRUAAO1cAAAEAAwAAAAAAAEAAEC0gQAAAAB4LmlpVVgIAAjxIzoI8SM6UEsBAhUD
FAAAAAgAp1Z8KbBJi+DgAAAAWwEAAAMADAAAAAAAAAAAQLSBrxUAAHgub1VYCAAJ8SM6CfEjOlBL
AQIVAxQAAAAIAKZWfCkr/PIbQgEAAKECAAADAAwAAAAAAAEAAEC0gcAWAAB4LnNVWAgACPEjOgjx
IzpQSwUGAAAAAAMAAwC4AAAAMxgAAAAAUEsDBAoAAAAAAM1WfCktNyiRIhwAACIcAAAUAAAAZmFp
bHMtd2l0aDItOTUtMi56aXBQSwMEFAAAAAgAdlZ8KdW+NiAMFgAAnWIAAAQAEAB4LmlpVVgMALDw
Izqw8CM66APoA71d62/bSJL/LP0VnQTnkeRHbCeTzVhRBti9u7kBDns43JcBZgcERVEyNzIp8GE7
63j+9qtHP6rJJiVP4snuWmR31a+qX9VV1S3tK3WhXt6fJcnL8St8fN1U5ettkcTb19ts+XqTJKf4
mb15/+60yT/lxV1+ui7TdFmt0u369eXZD9+fXb4+O3P/zfJk26zS15vj49M3r7Oiqss0vjm7fgnw
b8Zq3Pvv1a6MNzexyvI6LddxklLhcyjFKi2b9QFaBdVSijjSeyjK1cu/vVQPz6MpMGfFIVp+u57q
ITV6RT9FSZGvs43WSr0dK0+x+vMuXaVrZf9Bx8Ff4IOH91Gtoiiu6zJbNnUaRZNJFN0UK3yKov/9
OYqm0+ncYjR5lW3ydMUYANE8HcPXg9W4eDeI8V+Demg1nooR0uPN5SDG/x2ix1MxQnq8ezuI8e+H
6HEoxjiKcN0AQpFHkTKQ2yLf8B/A2+LDvIfSCvdYGs3TnoY+Nc5eWB6forq/Mav0VlZT6b5mId96
V1RDuJtsNVSd5UWwurouSiIgmYMU+TbLP/0h3Yv1usP3U7RjjUVvmoq6XGU+S7s58FaldYu9S/Qv
r0lmjOrsJtxUO99WAXXvkuu41BJDFskIbUu1BuoOnmQF4qkZ1tzG0TarutDS7BoLWdUrYBbmcdBs
DwDdxMl1lqevY2j9k+GCdKqvXoXJdEeMDppHoxHQaENg+3DkD91ejMjakrlTxWBFkcbCgQFxigW+
D8ozNJHZNBwNLZgRV2pLHgDQVBrAJ4ICx48WONxgy80kbXbihrXUz87cmgTnyJsfemfbJU0Pf9BG
YqW2qtSobPLULpfgeI3MUukyBxbbK/X+/Z/ugphWQ9ecP6P/BWK6y+mV+v77Z5T5RgvpGJjP1esE
RqJ6ulHoXfKBtl2cvxsSzN3eh9IpDxCCiL+82SsCqH44369IF/z7H/7s+dBtJPbi22efIv1dPFQD
UVCTgE3++X+ifzY3O1jLSomy//z5v/9jjqw4TH9SG9AtNZvvbZGtSBHjr5mWCB1v4vJTWkLw5Wmu
S2dRDu7jfNxpFdRUEPzNOYzDP+wMR+DAzaG5l+d/ed7mPs69VpBOD0aJ9TbeVHPYHcZGN/wfWtsZ
UUPoukIHbD4KlKf5Kli+jKu0XXFXZrAN99cEZHBFQAh0ZxAJyy25qYL+h6oqvtXSWxXLOPnU7ExV
gAkBeeRCg84P1XwcHHiAynKq487OtmlezM3rcvsJd7w5z0XjF8MTfII3q8tRpbbznTQlbErb5iaf
G4WjJm+qdOXeiRR65NeL3+Y2h0D/Hj3HsqV1tNs20BydbAhV0hs4AlkenZjnoqndS1qWkV1AZoEx
0viBW6q9YqUmM5wxU3jo9N4JL0r4FAxAOe9A0ETpwYC9u6qHkTiUQqAqTT/14NjhOcHB08w4jJMZ
xHhVWDyRPVJBUhSfsjTKimjd5EkNQSaFb9BDgksT4TwZPwRmFFbQCItG3dbxkkv5nTGoaX1ilXyd
6/ngpZfsK/vRTQ6Dut4Wd9DIVut8ugNoitsAlOvUzj/JDPSbtE481gjGryMFancNEbLQ5ETt51in
xfog6DXM8KIMk3bUgCmV0K4CyzfMIbN7dh9aIwuOd293OtIm30tsVa/Lz/3EQx1/u66SOF+3ho1n
IpvMExG78jIJ63C73pXwfDCUxJALn7o3XuXdmdRd6IJdcFcwm9rs0lQIANklwmYQCgwx2IYWjm8w
3ATvx4DXLoYmkgukM/7gGJh9LAZzGhrXR1QfopZ3z5zfJk/1cdDdt4bm+BhNTbKNq0pljII7LRcU
poBfrZB5N2Egtk4mg5e5rDQdzbXkd8lqO6G4Xu/JPSm9aH1Ts9PUpeCNN8JTiLhOhdsFJWDU0+2q
Gj+wk+UahP5hXRoP0bQbHJqarbh2Fu6yVX3N704H478xIvkG5GVsDaFWBbwB1qhVmt4n6U7vAlbS
rkyTDLOg7DboBQEzq4w/VzhAjx0rDU775TM47d7MQsddzxVYJ1dq1yy3WSL7lr3aojpSxS4t47oo
FxN8nWrHDvkmbGVMMZQyzpUXDYgedsMtCbCj7DC3K0B6jqkmv6ZvoiFNmjc3uCnzsDyMR5uiWC2z
Wi3UuToZj2Bj4rcLfFvH2ZZfL/F1GWvSt0o9CjxUg1JeCJjlhhtcNcOJwpANH3c7eHyPjzBn8wSp
3+FbXiSgKxG+ueSCMt1t4wRL3hHvksEvgRt6FF/j8rMu8TRCIxetMgih1DLdgMVvyhOoWT36PeXT
4gN8MolyYA+q+pTt7iroImoXlG/TdQ2voKYqs801Pr9lywkGJ94i5bkmXaUJUsKrKhIixMfr9J6I
DBUsqTuMDIgUCbBgVwAgcRiyZgfzLWE6YHaEFTNauCRL8zpbZwmzI+E6u09Xms/i5Rl67pqZ4MDd
LjTTOdk/pJN9+0BdDzrQWlhA+46hYcfQIpwx2yKuqQKGxWlxTMJx9Ff/bCpLgN14TB14bLqO5OC6
x/D8GeLVzkr3TCFYwslU+wcPqkzrBjdQtI/qsUtpX27j7RTo7TuGcwtmw78LqJ8bNKxDNDHLtD1F
cxqQTlZWi5eU+jlP79bT8ehBvxbb1Rp6VnPRB7wikdUASeaM54wP/g0JJ4ukgtT2FdAj7gKYAKYQ
pGAh6cIg/MnaRLJLNKkRg5bNbg0Bndy2EWTAN5CwI3Va8SxIQusjIdwzVEx8+inizMcjp+eu0xcQ
P69dV4S6AWxm5bphPNL98GWhWp2AhPvxT1zdTVx9OlQcNE4/HanfmfGLmuAIHTHOXk2gbzxdniL9
aMFC+4TgoJHjERhvdkg6hPikFx4+4rpCwZqaP5Xfx3btjYXDEdXXZXEX4V7XlHL5PwqiZJvG5cS4
M/wXrCQ1PzKv2r1SP2qCK/78wvsmdEa2hkHguiPpE007SpjmknDodisauxObrGFgEmHJV2ET0z4B
aPSfLgIHBj2MwKjqToNOlMTgf/TSHqEjdHXFLopkQrEDXBNi40H4Qs/ar/HUhPp9kvU4GibdYeWK
O7CH2e4c2lOkbp91qXUjfoQ1iQTTc5g++nFyeuGpaqBe9KG0VXRDFdBSuOZyYggeC5NjAojnvKuG
ic8VT56Efngyg56Ej2A/UtRi9sA2gxfgTMk3b8c9BbkbFsgsVCya89pWE2cAkVzoF9fg/ZOJ+Zwn
YFfqa0pKFmSBinw6l3S8qFqEuJ7aZW5INae1ojDH4i24PBMfGaXdexU0O47U7q4oV6iMLBal3J9c
h6ElzOYWBwWcWYfB/nOuCsdFP4PbqPtZBjWKK6i5j9aRA5qyqNOkTldXegpvszzFyTkRY1kt0aCe
eB5WVBdkZeeS7zYr6wa2rd8RoFWFnZ+BDj6wD6oRH73TX17gNhSIzNOcUsvmP/RHpgl0dh5ixDK7
pUDXP72B3bMEH3jVzS1IA6zT8Dyf6JEMMGZpFrqA54rsbKmAXALVUvfJ7x7F1MXdsAtm+YZGSU94
dSHNCzjSdTyR3EeCm2t1B+q0gxPvomV7AKRnjtcRWaHDXL9UZ2K6NUVvjVSTq2XK+ijipLVs7Gzi
KGZgXG0Kazatr7NKHSuzNFvzVq9DMbUoaxjF6GlzIy3UkbqnIxkpWB/SSCMbNXmEl5vkilZUEiGv
bhAdO212dWlso15tLTddgc09v8eYEnYR7ygKhsU7YtMqMPBOAAtI77zMY0j/qCo4akITOu/ygPep
0uHYYeuGOPi0zROC+ctv0ZEELZH7dbHHiC1NgrudOF6U7sk2DcVCjlidBkXRjLrfNTXOvnJCicME
J+XMG+HjYzA1iRR4b0LCducEiMgJA0r6dCGfsjEfFLn4c72dS90wqPBQLNMX4uqn5cw/hSF2IJ3A
iRtMF++sXbQjcDfL5mbHgWMXScyFiTcZjhf59GoiFxaWyLbtBC4iyh5XxxAIt13x5URPpRM7R7iR
8eJ86m8aO026s6Q7obu3ABae4AXEsN6SWqS7th6biROvzc+JPjBJN87FInev1U3T4EnBBE0rdLpm
9BYROpDLuWehoGgz9ywFEm3k+oGdTp87e3PUFFr/jRKoudYlMJ2N3gZbCQk/6SVteSTQPtMQwEt/
YgO3D6/fUEq0v+7XzvXxla+t35N/banVua4QaEqbp0e4a4q74yBF/73diAE1078H9GzD4nhfM39n
xL3xeoEp7w6Xvmbhsekyn4OWSmeay0Xa5JWHaJwESleBQcaMec+EfH/uq1ZB4JBcgzuMp9KakSX5
IRHbRYTR9sL3GG0csd421TU6LpNA9GIr0RHBTWqdlunK6W8dcCfWNFvXkCOrT99JJczyYxSrOiBY
aw/9uzKour9qh31PMS9JQTU8Gnf8AXsH9Hk+cWe/EBmcSIK81QiPF49vJ4dzoeuuD2sn9qTwxIUV
eueCcVxQ4JHlnJgomnoQb2djJiyB/zkg6OEAlJgexNEsO2qpQiimVkOqddwlcSZNFv4EwQAC2UV8
2xL/xFb0SUVmLZUweoRWXzcQLaAnj0B3MDkqTWnrsns4goCLF1hImDgILbBVQckASj3N3V6HSqLJ
8QM4hZ8nLoDzwmpggrWBSykxDqKoanK8CSMDyCZ3RiFgvi7RVboAq+9l9nxbErR6l+xleazaklpO
2s7xvIOcj2yqXDb9EkxmugXLLnLOl7699pQYgGJdunCm3DXLjQEfjCGU3tK+fPF6ampafD4fjwhY
v3sD6W21pDNVGjdHwGPqFLwtzc1WWLbVq5CuUHzLqUZvQdnN+jQYKpJFhz3rLs7qVvLA92pPe4Iv
YTL3G2IHrq02EOTTABReyuEpC0+9IOb6jjEWSBqEGzLzLftDlIznKUd9vMGja5FfozQ4bNx8k9LL
xbjSVjoOJeB0NRFBs5Y3hVSu/XFYzdnNifEpcA1HVNRa3IneIFudghXJidLOufA3MHBJ2qNMdqBL
y+bBkU4mihCVmp5+9Lz6j+AFhOpw3h0dedf/HB1OdPIdMACjzys1m/hXYWbTMDAIxWtJUlu8PE3q
6mx1S78BnbjpVp0pnoybJmNBa1l7geHxieknP9Sqi6pK7Mr2lPng6TJt4ck23eJ9OW25aVXN1jf1
uXezTcW4xxTVTE9quu8h50gIQZ2dnQma23VR3uwVIxiC9BrUHsF1va3qc0UNlTNfVsOfflcNmcn6
SAMj+fv9K+DEzTPoJwT35SqiC7mhzZnAwKfWJzhzfSma8uGYSObkJd6N9LKmLpH60M0/uux2n2uv
rxzpm0HIbpxmLcmoal5plFbBQhP4e76JHrTfw3AzFdd1nFwHYWekkxgVmA54Sz2+Sf0bmezGHczK
rpa+CEV+mLaG0Hqc5e/evQ2Mjww5Dg5dnIGvItIoeFkjzQs0JJ7zsw6cLTqQHy3flbYk5ujdtL93
nvlO4PMHIgf4rn8k5vpjsZbvHbvVotRYybFCY9JyWkwW+MXCpLP93Cx+76Gd4JBAPyqTkL/SCfRu
kmRG49eG0TmglqP37azgU03ZV9jOHkM3aCiNFfRO7HjmDR/bRXVBm7a7blEtYRiI11xivPLP6cUB
9AKd7pE+911US76YBSCMbO6LABnfmVp8p74DLUf6/govDr4GyAtklSbUGKCwF4gW74Cbb68qbQDG
7rATmtg+8Qy1UJ9fQp0u6sDwwSd9d0JMIf5rbxmAE5jW6a+/gVPBGuGJ3fgR96FX6s0z/yIKf4tw
+Pp162BPnMMeqcksim7iPNtN9bVaV830TJIZGl0o6ApJV2i6wtHZbwoYurvKwsAIYG9pCotEaTGL
gdFQiApcte0hRFWHyL+ODnPZrCHtG0BPjB/aweGqiIpqfd/1CDSMOIs3JQMzcNXyCosdQhtX+QXf
5OnGsdp5BYApLavTj9xXaA3sqc/F/FF6vqw1xsy4MPkowZw4mSs7+nYqLzi6NTGdEjH+cy3322cG
ajr3S2EnEqdf2hKcfuTgKHGXP2bo5ZtLYj5E2zaqWXh/CjK0ApY2ZzvJxazSEE85znzsF/HsAvhQ
/VshUzrNJdPanSergzuY2+/qdLvddUacww/pNEJBXIuoxpLe9tC2gptyU5lUm1u92uJ++ODnzkIE
/hyQ0fhkxsHlhw+KYKZJZ1oLnG+D4k3kAa3D85cSZyG5ctj3i38WUJ6nu4E28ZnsASO1j5ByNQch
WUoi9X8DqBfZg9/PE/gNoXxoxvKtaExumWu5ro4SUt1VG5I2CCO7kvF6AZdFsVVLMaHb6izdvcEQ
/6qAHTBghwUJfUHBS+dJGQww5XRe2/y3x8ZKOwSrD8l4Jwq/JustZSrQi2BoymtXyQC0Gb1tbcCk
WK+AnfRH65BkhzgkrVSF/PbjJimavBYnFBH60dFd1XVaMuO0XBk2NTl3Hoyp7vFg2g6MaSXEkyZW
rUsbrcr8KXjr3/0j/y7E6Jm9/QjCfiE3y50SF3Ho3KzfIKfikTt66VXiyDP5VsrRNAniihzy05tP
zF/VBYTwlG5ot/QJTZ38SUNFbfqz+sTmAGBDQ9qAv+nTtjbqLlPbXyMuqU7eo8Vz4ert+psA0jQw
9uGI7MMhE73SXYzObS89ZpMwIuJvGKUr+w0QLzp6MN/XkN8zsCET6KuDJvpi3XysYx9KRxxB5MPA
aMe+fDE34k8/imO7DyR72g61DNALAkAkF06J7IUL36QZBl55dHEBJfoCt9fyc3nK+Q0a3NeGsOZf
ofjFN1Yc+zc0NguaEd1G9ajH2S8XCctvzYBm5ljohW6C7QFz3GTDb8xTX7tvOEBYqw/w5jZeJiQk
Muls13j+Ro1Hq3MKtkALTq5t2aNQFn96woRfYuvnLdw7RdTOQHvVuhNTlS8u7D0FWoHt5DtmfNWk
vYYxNtx0gslg9QHB5KaDrw9XdYx3bZe9/nYTnhTKlIK5TCGOC913yEyGcuq+WijdMyuTbl5MBkWZ
yxlfI4bP/obiZEt620MbjpNtBsXyG4fz40dtxue99W2vI+BlA5XZDbobgSCSQF+D0+Oh9SnNjlqP
LPJhDlL5a2BgvRwNqEvfBgpHpH3kyvAcxtINSK28YLMxkBzSWAaTB9FJdQcJreheUoxOBwkothwS
xiHhvhFR+8nU04O+EIxJoR8WfAYHTIaNImZ0WWwTLHLBiXnXBBRAeiFgN3Fti/bHfU4DvC2hZdK3
7qAMxrmjD9hWJz3M4/3IhztBOIS8j6K8rti57ZiiBf62F57lR0lc1R+MvI9qgjw0FH4bi4E2Fj1t
7PJIpYt2G4fJ+ygObmPR00bz80XhgUzw5+6UJAr0BDgbsDUlaVn6eCHSbbHB7SpwNIS/YtVzOCS2
6gGqwkPadzikoTrHQxV/1+5no3xGX8IEP4x+dEacEB7hb47QwRlebwTv8Iy+t2+OLfWVCXjig5Xr
9F6f+SfC/81wGCQmkPVg4i9//DFMqO3BhJonYNKxJv+iLP1/PqhL+xM+v4jZP9JHZnyDZjzSGWh9
dwbdmfvP//r1t4V6eXH55iVbkxv6Eh+YqdEvo3tkuj8zAJghRMTxL6AllSEZzrkzOk54CWgwQ9S/
Vf/IX6oTBGeu/wdQSwMEFAAAAAgAdlZ8KUQ3kgp6AgAA/wYAAAMAEAB4LnNVWAwAsPAjOrDwIzro
A+gDpZRdi5tAFIav9VeIZCEBHXTUaHK13TQJC+lSWgq9KAxGJ4nFL3Sym+yv3xmd0YmY0tIrz7zH
c+ac541RwCFJsaJfQBTp6jGKIIqKrKRaDJYqOKbFPtUQIqeqeFMBwReiKiBMk2OuuSKdhUlOVXIt
sdIcjMfDOY9IUuQqO9I+u82TvVSV8lyfUu0B70sqrTbPFtWy4pVJdWn0Onu3PtPWE+gaLNfKkMph
HFPZtGGrKykOU820p6x4RrXw0l9D46bOoXVRmKZaXCQEIfunaGPPeZdLUbUFvMPvrNTADs5dulcJ
+b6G4auNuGyufcWqUmHCllvbbMcDZnODOnkXHBrNbPiAGjdEFFAVcUhCNpnVvE6qJD9SB67vWlJr
D/WvXL9Hup+f0xaCRFxILXU4Qt29Q93rqVsS9bncghP1RYugA09TwhzuGa+a0GEmdLvuzDbvDlFx
Jm3PQLh0KKoMIb+gZHCYfV1FeOgXc8ETI5jQvRliYA1srYG9NR20Rjc7qJJH+IQOVZhhQw/fdOOx
rIrjPiG1itDm26cva/S03j6/IMR6uvsrwQrY7VbPa5te9Z09+4R1obsCHtp9OK76UR8HfSip7mgY
BLftut/Nbi3GqTERUxpcNvm08habz+0W7Cmv1wjmYH8pTz9w+dQ0bzVpWpFmn/4wj0c3D7w+hneb
sctYz/6FuA+9u2VOWyYNAaUpbOsWpCDCQbKjwWWT8xmAdDhIZwjS+SNIeAMSmkIbX8Id5v8HpNcS
cf8RpN+WSS8EzugUg7qgrfP/2gDn1gCHG+BwA9ilSYxzoujb1WqpTbcvP2YaBAsPQM1eLBa2BV1t
WmH6H1Hjma5+AFBLAwQUAAAACAB2VnwpkmFo4DoCAADgBAAAAwAQAHgub1VYDACx8CM6sPAjOugD
6AOVVF9r01AUP2myGvfPWhQG+hBlGx1iMGE6qyKuXdspbhS3iiDjkqV3trAskkTsRPAhCI4x8AP4
IXzwAwjry978EkLBvQji0yCem9zau1AQD/xy7u+cc8+5J/fPu8rjqiRJUPUoLa0tgQQyYiABJ/Px
twDjcBZEaex9D4+nwu6vg0pU7+XREnZzxtcfZw6+zDL/0eHe7zjmwtr+hhp2T1rMOvj0TqIowin7
G72jQ+Sd3Tda29dm/FGAHK8hgfRWHVeUD7iWKUjA5CpicVJ9nylNjDzSc3CZr3MaMSf4lkK1obNk
tXL5jlaorTbmNFMv3tRNzSgWi8YNc14reHSbWj7Febq/6wTWJurAS3SrPwpoJwAdQ/moaQUW6Ju+
j0Y3IbRFtjzLoUnYgNmu49CdAP5DLsW9A2Q5f4BYEfz9/3MFIe7KZwVAQz3K5yMFFXGNc5nHfUzV
U7g2ePy/4m7xfBkhbkyI65+j+6m6nxD1IfmWU318U5IeWR9ZoY+nQm4mx4jZIXXPCzWZ5NFBhsSJ
PTBZlxPjGK/N6ub42sR86+h4PiRfWkS7Aj8j0SenZsmnKjCu/N3/YVVkGEnxLFw8Zcmm/CrMCJz1
dZ2P2X3KY34TBneI8bup+HKKL6c4dHTbhhe2bRI89S/b27SpAyHVJ4srFVKq1B6uEoI8aHnua3Cs
9g403XZAiPEMENP4BIDtvgpgy/UcQhZcvH3Ucuplm0K8NmkCYIFpbO0e05N411FnzkH8Bki4mbe5
/gNQSwECFQMUAAAACAB2Vnwp1b42IAwWAACdYgAABAAMAAAAAAABAABAtIEAAAAAeC5paVVYCACw
8CM6sPAjOlBLAQIVAxQAAAAIAHZWfClEN5IKegIAAP8GAAADAAwAAAAAAAEAAEC0gT4WAAB4LnNV
WAgAsPAjOrDwIzpQSwECFQMUAAAACAB2VnwpkmFo4DoCAADgBAAAAwAMAAAAAAAAAABAtIHpGAAA
eC5vVVgIALHwIzqw8CM6UEsFBgAAAAADAAMAuAAAAFQbAAAAAFBLAQIUABQAAAAIANJWfClitKSV
mAAAAMgAAAAEAAAAAAAAAAEAIAC2gQAAAAB4LmNjUEsBAhQACgAAAAAA0FZ8KRpNfgkBGQAAARkA
ABMAAAAAAAAAAAAgALaBugAAAHdvcmtzLXdpdGgyLTgtMS56aXBQSwECFAAKAAAAAADNVnwpLTco
kSIcAAAiHAAAFAAAAAAAAAAAACAAtoHsGQAAZmFpbHMtd2l0aDItOTUtMi56aXBQSwUGAAAAAAMA
AwC1AAAAQDYAAAAA
>From rth@redhat.com Tue Nov 28 13:56:00 2000
From: Richard Henderson <rth@redhat.com>
To: toon@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: fortran/893: Preliminary loop exit compiled wrongly
Date: Tue, 28 Nov 2000 13:56:00 -0000
Message-id: <20001128215601.8176.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00605.html
Content-length: 983
The following reply was made to PR fortran/893; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: toon@moene.indiv.nluug.nl
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: fortran/893: Preliminary loop exit compiled wrongly
Date: Tue, 28 Nov 2000 13:47:26 -0800
On Sun, Nov 26, 2000 at 04:30:48PM -0000, toon@moene.indiv.nluug.nl wrote:
> The following code:
>
> DOUBLE PRECISION VALUE(2), TOLD, BK
> DATA VALUE /0D0, 1D0/
> DATA TOLD /0D0/
> DO I=1, 2
> BK = VALUE(I)
> IF(BK .GT. TOLD) GOTO 10
> ENDDO
> WRITE(*,*)'Error: BK = ', BK
> CALL ABORT
> 10 CONTINUE
> WRITE(*,*)'No Error: BK = ', BK
> END
>
> which is g77 (execute) testsuite item 20001111.f compiles
> wrongly on i?86-linux with any optimisation on.
See if http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01594.html
helps. The general form of the bug appears to be identical.
r~
>From rth@redhat.com Tue Nov 28 15:06:00 2000
From: Richard Henderson <rth@redhat.com>
To: toon@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: fortran/892: -Wunused complains unnecessarily for COMMON block items
Date: Tue, 28 Nov 2000 15:06:00 -0000
Message-id: <20001128230601.30267.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00606.html
Content-length: 1171
The following reply was made to PR fortran/892; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: toon@moene.indiv.nluug.nl
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: fortran/892: -Wunused complains unnecessarily for COMMON block items
Date: Tue, 28 Nov 2000 14:57:13 -0800
On Sun, Nov 26, 2000 at 04:26:29PM -0000, toon@moene.indiv.nluug.nl wrote:
> SUBROUTINE SUB
> COMMON /COM/ A
> END
[...]
> unused.f:3: warning: unused variable `a'
Fixed thus.
r~
* com.c (ffecom_member_phase2_): Set TREE_USED on the debugging decl.
Index: com.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/f/com.c,v
retrieving revision 1.99
diff -c -p -d -r1.99 com.c
*** com.c 2000/11/10 20:36:15 1.99
--- com.c 2000/11/28 22:55:36
*************** ffecom_member_phase2_ (ffestorag mst, ff
*** 7110,7115 ****
--- 7110,7116 ----
TREE_STATIC (t) = TREE_STATIC (mt);
DECL_INITIAL (t) = NULL_TREE;
TREE_ASM_WRITTEN (t) = 1;
+ TREE_USED (t) = 1;
DECL_RTL (t)
= gen_rtx (MEM, TYPE_MODE (type),
>From rth@redhat.com Tue Nov 28 16:26:00 2000
From: Richard Henderson <rth@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 16:26:00 -0000
Message-id: <20001129002600.19188.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00607.html
Content-length: 2637
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Fergus Henderson <fjh@cs.mu.oz.au>
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 16:19:23 -0800
On Mon, Nov 27, 2000 at 10:06:43PM +1100, Fergus Henderson wrote:
> static void empty(void)
> {
> }
>
> static void foo (int a, int * b, int c, int * d)
> {
> malloc(20);
> empty();
> }
We recognize that empty does nothing and mark it CONST. This leads us to
/* When calling a const function, we must pop the stack args right away,
so that the pop is deleted or moved with the call. */
if (flags & (ECF_CONST | ECF_PURE))
NO_DEFER_POP;
For some reason, do_pending_stack_adjust does nothing if NO_DEFER_POP
is active. I found this highly confusing, but didn't have the guts to
change it, since it has been that way since before egcs forked in '97.
The simple fix is to move this code fragment down 10 lines.
Bootstrapped on i686 with -O2 -fomit-frame-pointer.
r~
* calls.c (expand_call): Defer const/pure NO_DEFER_POP until
after sibcall do_pending_stack_adjust.
Index: calls.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/calls.c,v
retrieving revision 1.166
diff -c -p -d -r1.166 calls.c
*** calls.c 2000/11/28 19:34:59 1.166
--- calls.c 2000/11/28 23:15:49
*************** expand_call (exp, target, ignore)
*** 2657,2667 ****
expand_start_target_temps ();
}
- /* When calling a const function, we must pop the stack args right away,
- so that the pop is deleted or moved with the call. */
- if (flags & (ECF_CONST | ECF_PURE))
- NO_DEFER_POP;
-
/* Don't let pending stack adjusts add up to too much.
Also, do all pending adjustments now if there is any chance
this might be a call to alloca or if we are expanding a sibling
--- 2657,2662 ----
*************** expand_call (exp, target, ignore)
*** 2670,2675 ****
--- 2665,2675 ----
|| (pending_stack_adjust > 0 && (flags & ECF_MAY_BE_ALLOCA))
|| pass == 0)
do_pending_stack_adjust ();
+
+ /* When calling a const function, we must pop the stack args right away,
+ so that the pop is deleted or moved with the call. */
+ if (flags & (ECF_CONST | ECF_PURE))
+ NO_DEFER_POP;
/* Push the temporary stack slot level so that we can free any
temporaries we make. */
>From zackw@stanford.edu Tue Nov 28 16:56:00 2000
From: "Zack Weinberg" <zackw@stanford.edu>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 16:56:00 -0000
Message-id: <20001129005601.27409.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00608.html
Content-length: 909
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@stanford.edu>
To: Richard Henderson <rth@redhat.com>
Cc: Fergus Henderson <fjh@cs.mu.oz.au>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 16:48:25 -0800
On Tue, Nov 28, 2000 at 04:19:23PM -0800, Richard Henderson wrote:
> On Mon, Nov 27, 2000 at 10:06:43PM +1100, Fergus Henderson wrote:
> > static void empty(void)
> > {
> > }
> >
> > static void foo (int a, int * b, int c, int * d)
> > {
> > malloc(20);
> > empty();
> > }
>
> We recognize that empty does nothing and mark it CONST.
Would it be practical to recognize that empty does nothing, and not
call it at all? This could be as simple as marking it to-be-inlined.
zw
>From rth@redhat.com Tue Nov 28 17:46:00 2000
From: Richard Henderson <rth@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 17:46:00 -0000
Message-id: <20001129014601.8009.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00609.html
Content-length: 775
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Zack Weinberg <zackw@stanford.edu>
Cc: Fergus Henderson <fjh@cs.mu.oz.au>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 17:43:21 -0800
On Tue, Nov 28, 2000 at 04:48:25PM -0800, Zack Weinberg wrote:
> > We recognize that empty does nothing and mark it CONST.
>
> Would it be practical to recognize that empty does nothing, and not
> call it at all? This could be as simple as marking it to-be-inlined.
I'd rather not, since otherwise it'll be neigh impossible to
write ld.so style breakpoint hooks.
r~
>From fjh@cs.mu.oz.au Tue Nov 28 17:56:00 2000
From: Fergus Henderson <fjh@cs.mu.oz.au>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 17:56:00 -0000
Message-id: <20001129015600.13501.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00610.html
Content-length: 1411
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: Fergus Henderson <fjh@cs.mu.oz.au>
To: Richard Henderson <rth@redhat.com>
Cc: Zack Weinberg <zackw@stanford.edu>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Wed, 29 Nov 2000 12:48:37 +1100
On 28-Nov-2000, Richard Henderson <rth@redhat.com> wrote:
> On Tue, Nov 28, 2000 at 04:48:25PM -0800, Zack Weinberg wrote:
> > > We recognize that empty does nothing and mark it CONST.
> >
> > Would it be practical to recognize that empty does nothing, and not
> > call it at all? This could be as simple as marking it to-be-inlined.
>
> I'd rather not, since otherwise it'll be neigh impossible to
> write ld.so style breakpoint hooks.
If inlining is enabled (i.e. `-O3'), then the programmer should not
expect calls to empty functions to be honoured.
If you really want to ensure that something will not be inlined, then
you should say so explicitly. In Mercury we have `pragma no_inline'
for that. Perhaps GNU C should have `__attribute__((__no_inline__))'?
--
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.
>From rth@gcc.gnu.org Tue Nov 28 17:56:00 2000
From: rth@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902
Date: Tue, 28 Nov 2000 17:56:00 -0000
Message-id: <20001129015600.13506.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00611.html
Content-length: 531
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: rth@gcc.gnu.org
To: fjh@cs.mu.oz.au, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:
Subject: Re: optimization/902
Date: 29 Nov 2000 01:50:16 -0000
Synopsis: x86 optimization bug with sibling call and -fomit-frame-pointer
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Tue Nov 28 17:50:16 2000
State-Changed-Why:
Patch applied.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=902&database=gcc
>From rth@gcc.gnu.org Tue Nov 28 17:56:00 2000
From: rth@gcc.gnu.org
To: toon@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: fortran/892
Date: Tue, 28 Nov 2000 17:56:00 -0000
Message-id: <20001129015600.13519.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00612.html
Content-length: 521
The following reply was made to PR fortran/892; it has been noted by GNATS.
From: rth@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, toon@gcc.gnu.org, toon@moene.indiv.nluug.nl
Cc:
Subject: Re: fortran/892
Date: 29 Nov 2000 01:51:40 -0000
Synopsis: -Wunused complains unnecessarily for COMMON block items
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Tue Nov 28 17:51:40 2000
State-Changed-Why:
Patch applied.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=892&database=gcc
>From rth@redhat.com Tue Nov 28 18:06:00 2000
From: Richard Henderson <rth@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 18:06:00 -0000
Message-id: <20001129020601.16190.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00613.html
Content-length: 734
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Fergus Henderson <fjh@cs.mu.oz.au>
Cc: Zack Weinberg <zackw@stanford.edu>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 18:01:16 -0800
On Wed, Nov 29, 2000 at 12:48:37PM +1100, Fergus Henderson wrote:
> If inlining is enabled (i.e. `-O3'), then the programmer should not
> expect calls to empty functions to be honoured.
Right, but if -fno-inline-functions is specified (or not -O3),
then we should not do automatic inlining. Which is what Zack
was suggesting.
r~
>From rth@gcc.gnu.org Tue Nov 28 18:06:00 2000
From: rth@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/858
Date: Tue, 28 Nov 2000 18:06:00 -0000
Message-id: <20001129020601.16184.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00614.html
Content-length: 524
The following reply was made to PR optimization/858; it has been noted by GNATS.
From: rth@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, igor@txc.com, nobody@gcc.gnu.org
Cc:
Subject: Re: optimization/858
Date: 29 Nov 2000 01:58:10 -0000
Synopsis: Internal compiler error in scan_rtx_reg, at regrename.c:334
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Tue Nov 28 17:58:10 2000
State-Changed-Why:
Patch applied.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=858&database=gcc
>From zackw@Stanford.EDU Tue Nov 28 19:26:00 2000
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 19:26:00 -0000
Message-id: <20001129032601.2235.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00615.html
Content-length: 1290
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Richard Henderson <rth@redhat.com>
Cc: Fergus Henderson <fjh@cs.mu.oz.au>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 19:21:43 -0800
On Tue, Nov 28, 2000 at 05:43:21PM -0800, Richard Henderson wrote:
> On Tue, Nov 28, 2000 at 04:48:25PM -0800, Zack Weinberg wrote:
> > > We recognize that empty does nothing and mark it CONST.
> >
> > Would it be practical to recognize that empty does nothing, and not
> > call it at all? This could be as simple as marking it to-be-inlined.
>
> I'd rather not, since otherwise it'll be neigh impossible to
> write ld.so style breakpoint hooks.
You just have to put them in a separate file and not make them
static. With the current compiler, you can put them below their call
sites, but that is likely to change in the future. Or have them
perform some trivial side effect like frobbing a static variable.
This is sort of the same argument as deleting empty loops. It seems
to me that C++ abstractions could produce empty functions just as
easily as empty loops.
zw
>From rth@redhat.com Tue Nov 28 20:56:00 2000
From: Richard Henderson <rth@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 20:56:00 -0000
Message-id: <20001129045602.15807.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00617.html
Content-length: 555
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Fergus Henderson <fjh@cs.mu.oz.au>
Cc: Zack Weinberg <zackw@stanford.edu>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 20:47:03 -0800
On Wed, Nov 29, 2000 at 12:48:37PM +1100, Fergus Henderson wrote:
> Perhaps GNU C should have `__attribute__((__no_inline__))'?
Probably you're right.
r~
>From rth@redhat.com Tue Nov 28 20:56:00 2000
From: Richard Henderson <rth@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 20:56:00 -0000
Message-id: <20001129045603.15813.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00616.html
Content-length: 722
The following reply was made to PR optimization/902; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Zack Weinberg <zackw@Stanford.EDU>
Cc: Fergus Henderson <fjh@cs.mu.oz.au>, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Date: Tue, 28 Nov 2000 20:47:57 -0800
On Tue, Nov 28, 2000 at 07:21:43PM -0800, Zack Weinberg wrote:
> This is sort of the same argument as deleting empty loops. It seems
> to me that C++ abstractions could produce empty functions just as
> easily as empty loops.
True enough. In either case, however, it makes no difference
to the patch in question.
r`
>From list@pceet030.cern.ch Wed Nov 29 00:16:00 2000
From: List subscription <list@pceet030.cern.ch>
To: toon@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: fortran/893: Preliminary loop exit compiled wrongly
Date: Wed, 29 Nov 2000 00:16:00 -0000
Message-id: <20001129081601.15365.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00618.html
Content-length: 2665
The following reply was made to PR fortran/893; it has been noted by GNATS.
From: List subscription <list@pceet030.cern.ch>
To: Richard Henderson <rth@redhat.com>
Cc: <toon@moene.indiv.nluug.nl>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>
Subject: Re: fortran/893: Preliminary loop exit compiled wrongly
Date: Wed, 29 Nov 2000 09:12:57 +0100 (CET)
Yes
that patch seems to fix that bug and similar ones I found and reported.
The patch was issued after I made a report to Bugzilla (the RH bug tracking
system). They reacted at the speed of light.... many thanks to Jakub
Jelinek from RedHat.
For Toon: indeed the 7+ miscompiled routines I had seem to be all ok after
this patch (the bug was indeed very "popular"), I am still in the process
to check carefully whether there are other problems floating around or not
for what concerns our codes, I'll let you know. A naive question: is
there any reason why the present g77 is significantly slower than the
one in egcs-1.1.2 (20-30% slower on all the tests I made up to now, and
now the results are consistent so the comparison should be sound)?
Ciao
Alfredo Ferrari
On Tue, 28 Nov 2000, Richard Henderson wrote:
> On Sun, Nov 26, 2000 at 04:30:48PM -0000, toon@moene.indiv.nluug.nl wrote:
> > The following code:
> >
> > DOUBLE PRECISION VALUE(2), TOLD, BK
> > DATA VALUE /0D0, 1D0/
> > DATA TOLD /0D0/
> > DO I=1, 2
> > BK = VALUE(I)
> > IF(BK .GT. TOLD) GOTO 10
> > ENDDO
> > WRITE(*,*)'Error: BK = ', BK
> > CALL ABORT
> > 10 CONTINUE
> > WRITE(*,*)'No Error: BK = ', BK
> > END
> >
> > which is g77 (execute) testsuite item 20001111.f compiles
> > wrongly on i?86-linux with any optimisation on.
>
> See if http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01594.html
> helps. The general form of the bug appears to be identical.
>
>
> r~
>
--
+----------------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.767.6119 |
| C.E.R.N. || Fax.: +41.22.767.7555 |
| European Laboratory for Particle Physics|| |
| SL Division / EET Project || e-mail: |
| 1211 Geneva 23 || Alfredo.Ferrari@cern.ch |
| Switzerland || Alfredo.Ferrari@mi.infn.it |
+----------------------------------------------------------------------------+
>From fjh@cs.mu.oz.au Wed Nov 29 00:36:00 2000
From: Fergus Henderson <fjh@cs.mu.oz.au>
To: gcc-gnats@gcc.gnu.org
Subject: c/922: asm("%%eax"::) gives "%%eax" instead of "%eax"
Date: Wed, 29 Nov 2000 00:36:00 -0000
Message-id: <200011290828.TAA20418@hg.cs.mu.oz.au>
X-SW-Source: 2000-q4/msg00619.html
Content-length: 1611
>Number: 922
>Category: c
>Synopsis: asm("%%eax"::) gives "%%eax" instead of "%eax"
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 00:36:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:
>Release: 2.97 20001124 (experimental)
>Organization:
Comp Sci, University of Melbourne
>Environment:
System: Linux hg 2.2.13 #1 Mon Nov 8 20:35:50 GMT 1999 i686 unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: configure --prefix=/usr/local/gcc-snapshot : (reconfigured) configure : (reconfigured) configure --prefix=/usr/local/gcc-snapshot
>Description:
The handling of `%' inside `asm("..."::)' constructs has changed,
and no longer matches what it says in the gcc manual.
For example, in egcs-1.1.2 the following worked fine
int main() {
asm("pushl %%ebx; popl %%ebx" : : );
return 0;
}
but with the 20001124 snapshot that now produces "%%" in the
assembler, rather than "%", and so the assembler complains.
Either the compiler should be changed, or the documentation should be
changed. For backwards compatibility I'd prefer the former.
>How-To-Repeat:
$ cat foo.c
int main() {
asm("pushl %%ebx; popl %%ebx" : : );
return 0;
}
$ gcc -c foo.c
/tmp/ccdAoAW0.s: Assembler messages:
/tmp/ccdAoAW0.s:12: Error: bad register name ('%%ebx')
/tmp/ccdAoAW0.s:12: Error: bad register name ('%%ebx')
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
>From fjh@cs.mu.oz.au Wed Nov 29 00:36:00 2000
From: Fergus Henderson <fjh@cs.mu.oz.au>
To: gcc-gnats@gcc.gnu.org
Subject: c/923: gcc crashes on empty .c files
Date: Wed, 29 Nov 2000 00:36:00 -0000
Message-id: <200011290833.TAA20525@hg.cs.mu.oz.au>
X-SW-Source: 2000-q4/msg00620.html
Content-length: 1145
>Number: 923
>Category: c
>Synopsis: gcc crashes on empty .c files
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 00:36:02 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:
>Release: 2.97 20001124 (experimental)
>Organization:
Comp Sci, University of Melbourne
>Environment:
System: Linux hg 2.2.13 #1 Mon Nov 8 20:35:50 GMT 1999 i686 unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: configure --prefix=/usr/local/gcc-snapshot : (reconfigured) configure : (reconfigured) configure --prefix=/usr/local/gcc-snapshot
>Description:
GNU C crashes with an internal compiler error when you give it an
empty .c file.
>How-To-Repeat:
$ rm -f foo.c
$ touch foo.c
$ gcc foo.c
foo.c:0: Internal error: Segmentation fault.
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
>From neil@gcc.gnu.org Wed Nov 29 01:16:00 2000
From: neil@gcc.gnu.org
To: neil@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: preprocessor/923
Date: Wed, 29 Nov 2000 01:16:00 -0000
Message-id: <20001129091601.28858.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00621.html
Content-length: 762
The following reply was made to PR preprocessor/923; it has been noted by GNATS.
From: neil@gcc.gnu.org
To: fjh@cs.mu.oz.au, gcc-gnats@gcc.gnu.org, neil@gcc.gnu.org,
nobody@gcc.gnu.org
Cc:
Subject: Re: preprocessor/923
Date: 29 Nov 2000 09:10:43 -0000
Synopsis: gcc crashes on empty .c files
Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-By: neil
Responsible-Changed-When: Wed Nov 29 01:10:42 2000
Responsible-Changed-Why:
This is an integrated cpp problem; I'll get to it soon but not immediately.
State-Changed-From-To: open->analyzed
State-Changed-By: neil
State-Changed-When: Wed Nov 29 01:10:42 2000
State-Changed-Why:
Confirmed as a bug.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=923&database=gcc
>From mdejong@redhat.com Wed Nov 29 02:26:00 2000
From: mdejong@redhat.com
To: gcc-gnats@gcc.gnu.org
Subject: c++/924: -Wuninitialized does not seem to warn on uninitialize class members.
Date: Wed, 29 Nov 2000 02:26:00 -0000
Message-id: <20001129102332.14938.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00622.html
Content-length: 1086
>Number: 924
>Category: c++
>Synopsis: -Wuninitialized does not seem to warn on uninitialize class members.
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 02:26:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: mdejong@redhat.com
>Release: CVS gcc as of Wed Nov 29 2000, all earlier releases
>Organization:
>Environment:
Linux (Red Hat 6.2)
>Description:
I would think that the following uninitialize
memory would get noticed by g++. I get
no warnings, even when I pass the -Wall
and -Wuninitialized flags.
class no_init {
private:
int num;
char *ptr;
public:
no_init(): num(0) {
}
~no_init() {
delete [] ptr; // This memory is never initialized!
}
};
int main() {
no_init();
}
% g++ -static -o noinit -g -Wall -O2 -Wuninitialized no_init.cpp
% ./noinit
Segmentation fault (core dumped)
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
>From rmgiroux@hotmail.com Wed Nov 29 07:16:00 2000
From: rmgiroux@hotmail.com
To: gcc-gnats@gcc.gnu.org
Subject: c++/925: Follow-up to c++/909 with more info
Date: Wed, 29 Nov 2000 07:16:00 -0000
Message-id: <20001129150806.21198.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00623.html
Content-length: 2611
>Number: 925
>Category: c++
>Synopsis: Follow-up to c++/909 with more info
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 07:16:02 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: rmgiroux@hotmail.com
>Release: 2.95.2 && gcc version 2.97 20001120 (experimental)
>Organization:
>Environment:
Linux, cygwin
>Description:
Here's the error messages resulting from compilation of the c++/909 test case, with calls added to a method in the constructed objects so the compiler prints what it THINKS the constructor is generating.
testExp.cpp: In function `int main()':
testExp.cpp:21: type specifier omitted for parameter
testExp.cpp:22: type specifier omitted for parameter
testExp.cpp:28: type specifier omitted for parameter
testExp.cpp:31: request for member `f' in `a', which is of non-aggregate type `A ()(A::Nested)'
testExp.cpp:32: request for member `f' in `b', which is of non-aggregate type `A ()(A::Nested (*)(int))'
testExp.cpp:35: request for member `f' in `e', which is of non-aggregate type `A ()(A::Nested)'
testExp.cpp:38: request for member `f' in `g', which is of non-aggregate type `B ()(A::Nested)'
>How-To-Repeat:
Compile the attached file.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/cpp; name="testExp.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="testExp.cpp"
Y2xhc3MgQSB7CiAgICBwdWJsaWM6CiAgICAgICAgc3RydWN0IE5lc3RlZCB7IE5lc3RlZChpbnQg
aSkge30gfTsKCiAgICAgICAgQShjb25zdCBOZXN0ZWQgJm4sIGludCAqcD0wKSA7CgogICAgICAg
IGludCBmKHZvaWQpOwp9OwoKY2xhc3MgQiB7CiAgICBwdWJsaWM6CiAgICAgICAgQihjb25zdCBB
OjpOZXN0ZWQgJm4sIGludCAqcD0wKTsKCiAgICAgICAgaW50IGYodm9pZCk7Cn07CgppbnQgbWFp
bih2b2lkKQp7CiAgICBpbnQgKlo9MDsKICAgIGludCBpPTE7CiAgICBBIGEoQTo6TmVzdGVkKGkp
LCBaKTsgICAgICAvLyBFUlJPUjogIHR5cGUgc3BlY2lmaWVyIG9taXR0ZWQgZm9yIHBhcmFtZXRl
cgogICAgQSBiKEE6Ok5lc3RlZChpbnQoaSkpLCBaKTsgLy8gRVJST1I6ICB0eXBlIHNwZWNpZmll
ciBvbWl0dGVkIGZvciBwYXJhbWV0ZXIKICAgIEEgYyhBOjpOZXN0ZWQoKGludClpKSwgWik7IC8v
IE9LCiAgICBBIGQoQTo6TmVzdGVkKDEpLCBaKTsgICAgICAvLyBPSwogICAgQSBlKEE6Ok5lc3Rl
ZChpKSk7ICAgICAgICAgLy8gT0sKICAgIEEgZihpLCBaKTsgICAgICAgICAgICAgICAgIC8vIE9L
CgogICAgQiBnKEE6Ok5lc3RlZChpKSwgWik7ICAgICAgLy8gRVJST1I6ICB0eXBlIHNwZWNpZmll
ciBvbWl0dGVkIGZvciBwYXJhbWV0ZXIKICAgIEIgaChpLCBaKTsgICAgICAgICAgICAgICAgIC8v
IE9LCgogICAgYS5mKCk7CiAgICBiLmYoKTsKICAgIGMuZigpOwogICAgZC5mKCk7CiAgICBlLmYo
KTsKICAgIGYuZigpOwogICAgCiAgICBnLmYoKTsKICAgIGguZigpOwp9Cg==
>From binder@iue.tuwien.ac.at Wed Nov 29 07:46:00 2000
From: binder@iue.tuwien.ac.at
To: gcc-gnats@gcc.gnu.org
Subject: c++/926: Internal compiler error in expand_expr, at expr.c:5992
Date: Wed, 29 Nov 2000 07:46:00 -0000
Message-id: <20001129154304.30795.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00624.html
Content-length: 2723
>Number: 926
>Category: c++
>Synopsis: Internal compiler error in expand_expr, at expr.c:5992
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 07:46:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: g++
>Release: gcc version 2.96 20000731 (Red Hat Linux 7.0)
>Organization:
>Environment:
Red Hat Linux 7.0
>Description:
The attached file fails to compile with internal compiler error
binder@in22:~/bug$ g++ -v -c -save-temps test.cc
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
/usr/lib/gcc-lib/i386-redhat-linux/2.96/cpp0 -lang-c++ -D__GNUG__=2 -v -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_i386__ test.cc test.ii
GNU CPP version 2.96 20000731 (Red Hat Linux 7.0) (cpplib)
(i386 Linux/ELF)
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/g++-3
/usr/lib/gcc-lib/i386-redhat-linux/2.96/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/2.96/cc1plus test.ii -quiet -dumpbase test.cc -version -o test.s
GNU C++ version 2.96 20000731 (Red Hat Linux 7.0) (i386-redhat-linux) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.0).
test.cc: In function `int main ()':
test.cc:44: Internal compiler error in expand_expr, at expr.c:5992
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
>How-To-Repeat:
g++ -v -c -save-temps test.cc
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="test.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.cc"
LyoqCiAqIEBmaWxlCiAqIFwkSWQ6IHRlc3QuY2MsdiAxLjM5IDIwMDAvMTEvMjQgMTk6MDg6MTQg
aG9lc3NpbmcgRXhwICQKICovCgpzdHJ1Y3QgVGVzdGVyCnsKCXZpcnR1YWwgflRlc3RlcigpCgl7
fQp9OwoKCnN0cnVjdCBNZW51RW50cnkKewkKCWNvbnN0IFRlc3RlcioJdGVzdGVyOwoKCU1lbnVF
bnRyeShjb25zdCBUZXN0ZXIqIHR0ID0gbmV3IFRlc3RlcigpKTogCgkJdGVzdGVyKHR0KQoJe30K
fTsKCgpzdHJ1Y3QgTWVudQp7CQoJdm9pZCBhZGQoY29uc3QgTWVudUVudHJ5KiBtZW50cnkpOwp9
OwoKCnN0cnVjdCBBTEdFQlJBX1RFU1Q6IHB1YmxpYyBUZXN0ZXIKewkKCU1lbnUJc3ViOwoKCUFM
R0VCUkFfVEVTVCAoKQoJewoJCXN1Yi5hZGQobmV3IE1lbnVFbnRyeSgpKTsKCX0KfTsKCgppbnQg
bWFpbiAoKQp7CQoJTWVudQltZW51OwoKCW1lbnUuYWRkKG5ldyBNZW51RW50cnkoKSk7Cn0KCg==
>From jpalkovic@hyperfeed.com Wed Nov 29 09:26:00 2000
From: John Palkovic <jpalkovic@hyperfeed.com>
To: gcc-gnats@gcc.gnu.org
Subject: c/927: stage1/xgcc from branch 1.256.2 crashes when compiling gcc/global.c version 1.63.2.2
Date: Wed, 29 Nov 2000 09:26:00 -0000
Message-id: <20001129171447.3388.qmail@coredump.pcqt.com>
X-SW-Source: 2000-q4/msg00625.html
Content-length: 2640
>Number: 927
>Category: c
>Synopsis: stage1/xgcc from branch 1.256.2 crashes when compiling gcc/global.c version 1.63.2.2
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 09:26:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:
>Release: 2.96
>Organization:
HyperFeed Technologies
>Environment:
System: SunOS sun28 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4
host: sparcv9-sun-solaris2.8
build: sparcv9-sun-solaris2.8
target: sparcv9-sun-solaris2.8
>Description:
compilation failed in stage1. Called configure like so:
/home/palkovic/anoncvs/gcc/configure \
--enable-languages=c++ \
--prefix=/usr/local/gcc-new sparcv9-sun-solaris2.8
>How-To-Repeat:
Configure as above on and type 'make bootstrap-lean'.
I was trying to build a gcc with -m64 supported on ultrasparc. I saw
some messages that indicated the subreg-byte-branch was the focus of
64 bit development for gcc and grabbed the latest snapshot. I have
rerun stage1/xgcc with the -dr flage to generate a global.c.00.rtl
file (984682 bytes) and can make it available for download if
necessary. Here is the compiler output:
stage1/xgcc -Bstage1/ -B/usr/local/gcc-new/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC -DSVR4 -O2 -g -O2 -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I/home/palkovic/anoncvs/gcc/gcc -I/home/palkovic/anoncvs/gcc/gcc/config -I/home/palkovic/anoncvs/gcc/gcc/../include /home/palkovic/anoncvs/gcc/gcc/local-alloc.c
stage1/xgcc -Bstage1/ -B/usr/local/gcc-new/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC -DSVR4 -O2 -g -O2 -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I/home/palkovic/anoncvs/gcc/gcc -I/home/palkovic/anoncvs/gcc/gcc/config -I/home/palkovic/anoncvs/gcc/gcc/../include /home/palkovic/anoncvs/gcc/gcc/global.c
/home/palkovic/anoncvs/gcc/gcc/global.c: In function `record_one_conflict':
/home/palkovic/anoncvs/gcc/gcc/global.c:1342: Internal compiler error in gen_rtx_SUBREG, at emit-rtl.c:361
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
make[2]: *** [global.o] Error 1
make[2]: Leaving directory `/usr/local/bld/gcc'
make[1]: *** [stage_c] Error 2
make[1]: Leaving directory `/usr/local/bld/gcc'
make: *** [bootstrap-lean] Error 2
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted:
>From christophe.lyon@st.com Wed Nov 29 09:56:00 2000
From: christophe.lyon@st.com
To: gcc-gnats@gcc.gnu.org
Subject: c/929: Incorrect code generation on Sparc under -O3
Date: Wed, 29 Nov 2000 09:56:00 -0000
Message-id: <20001129175412.18109.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-q4/msg00627.html
Content-length: 1226
>Number: 929
>Category: c
>Synopsis: Incorrect code generation on Sparc under -O3
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Wed Nov 29 09:56:03 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: Christophe Lyon
>Release: gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
SunOS 5.5.1 Generic_103640-29 sun4u sparc SUNW,Ultra-60
>Description:
The code generated is incorrect. This test is part of a
commercial C validation suite, and thus is self-testing:
when running the produced executable I get
***** Reached first test *****
ERROR in int1.c at line 80: (2) != (1)
***** 9 successful test cases in int1.c *****
***** 1 error detected in int1.c *****
***** 0 skipped sections in int1.c *****
I have about 10 other tests that fail.
>How-To-Repeat:
gcc -ansi -O3 -c int1.i util.i
gcc int1.o util.o -o int1
./int1
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="int1.i"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="int1.i"
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-06-16 6:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-16 6:06 libobjc/917: Build failed neil
-- strict thread matches above, loose matches on Subject: below --
2000-11-28 6:36 ask
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).