Re: cc optimisation levels ?

Temporary workaround: Add GCC 2.95.3 to the list of compilers where
optimizations is banned in configure.in (2.95.[12] is already there).

However, I'd like to have this tested in a more official 2.95.3 release
(i.e. 2.95.3-test2, released a few days ago) than the old snapshot
release OpenBSD 2.8 apparently ships with before permanently adding
2.95.3 to the list of banned compilers. From reading the mail archives
there seems to have been quite a bit of cleanups in gcc-2.95 the last
months, preparing for the 2.95.3 release, and if adding to this that
there is patched 2.95.2 versions around which does not exibit the
problem I see it likely to be fixed in 2.95.3.

/Henrik

Robert Collins wrote:
>
> Graeme Lee reported no data returned from squid on openbsd 2.8. I have openBSD 2.7 & had just upgraded to 2.8, just after upgrading
> I ran into a problem, which I hadn't tracked down.
>
> I suspected it mightbe the same, so I asked grame for a bt from the squid.core if one was created:
>
> It was the same problem as mine. - but I'm currently waiting confirmation from Graeme before I report the O level consistently
> fixing it - so this is a little premature.
>
> I looked at the code and couldn't see anything wrong with rfc1035NamePack & rfc1035QuestionPack. I rebuilt rfc1035.c with O1 and
> updated the library, relinked squid and voila the problem was gone.
>
> > Would be quite a mess to maintain, and if the compiler is found to fail
> > on one file, how does you know that it doesn't produce similar errors in
> > other files? It is not like we have an extensive test suite that makes
> > sure each line of code is tested...
>
> But we do have a large user base that is likely to appreciate the ?increased? performance and report problems.
>
> == the start of my dmesg ==
> OpenBSD 2.8 (GENERIC) #399: Mon Nov 6 10:59:23 MST 2000
> deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: F00F bug workaround installed
> cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 150 MHz
> cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
> real mem = 100249600 (97900K)
> avail mem = 87871488 (85812K)
>
> === ggc -v ===
> Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd2.8/2.95.3/specs
> gcc version 2.95.3 19991030 (prerelease)
>
> == faulty cmd line
> gcc -g -O2 -Wall -I../include -I../../squid/include -c ../../squid/lib/rfc1035.c
> === working cmd line
> gcc -g -O1 -Wall -I../include -I../../squid/include -c ../../squid/lib/rfc1035.c
>
> == symptoms
> The hostname parameter from rfc1035BuildAQuery reached rfc1035QuestionPack as a NULL pointer when O2 is used in that environment.
>
> === graeme's bt ===
> (gdb) bt
> #0 0x400fb6a8 in strdup ()
> #1 0x71428 in rfc1035NamePack (buf=0x4b940c "", sz=500, name=0x0)
> at rfc1035.c:176
> #2 0x714f2 in rfc1035QuestionPack (buf=0x4b940c "", sz=500, name=0x0,
> type=1,
> class=1) at rfc1035.c:201
> #3 0x71e42 in rfc1035BuildAQuery (hostname=0x4b14e0 "www.omni.net.au",
> buf=0x4b9400 "", szp=0x4b9600) at rfc1035.c:480
> #4 0x23c0e in idnsALookup (name=0x4b14e0 "www.omni.net.au",
> callback=0x4042c <ipcacheHandleReply>, data=0x4b1500) at
> dns_internal.c:480
> #5 0x40a0b in ipcache_nbgethostbyname (name=0x494888 "www.omni.net.au",
> handler=0x1bfe8 <commConnectDnsHandle>, handlerData=0x4955c0)
> at ipcache.c:500
> #6 0x1bf1b in commConnectStart (fd=15, host=0x494888 "www.omni.net.au",
> port=80, callback=0x2670c <fwdConnectDone>, data=0x495580) at
> comm.c:237
> #7 0x26c9d in fwdConnectStart (data=0x495580) at forward.c:271
> #8 0x26d09 in fwdStartComplete (servers=0x4b14a0, data=0x495580)
> at forward.c:281
> #9 0x4bad0 in peerSelectCallback (psstate=0x4aff00) at peer_select.c:198
> #10 0x4bec2 in peerSelectFoo (ps=0x4aff00) at peer_select.c:281
> #11 0x4b8d8 in peerCheckAlwaysDirectDone (answer=1, data=0x4aff00)
> at peer_select.c:173
> #12 0x65c5 in aclCheckCallback (checklist=0x4bc000, answer=ACCESS_ALLOWED)
> at acl.c:1653
> ---Type <return> to continue, or q <return> to quit---
> #13 0x6428 in aclCheck (checklist=0x4bc000) at acl.c:1613
> #14 0x68ae in aclNBCheck (checklist=0x4bc000,
> callback=0x4b880 <peerCheckAlwaysDirectDone>, callback_data=0x4aff00)
> at acl.c:1763
> #15 0x4bdda in peerSelectFoo (ps=0x4aff00) at peer_select.c:252
> #16 0x4b7c3 in peerSelect (request=0x494800, entry=0x4a5f40,
> callback=0x26cbc <fwdStartComplete>, callback_data=0x495580)
> at peer_select.c:153
> #17 0x2750c in fwdStart (fd=14, e=0x4a5f40, r=0x494800) at forward.c:478
> #18 0x19250 in clientProcessMiss (http=0x4b9000) at client_side.c:2057
> #19 0x18fc1 in clientProcessRequest (http=0x4b9000) at client_side.c:1996
> #20 0x141dc in clientRedirectDone (data=0x4b9000, result=0x0)
> at client_side.c:299
> #21 0x4e1aa in redirectStart (http=0x4b9000,
> handler=0x13f74 <clientRedirectDone>, data=0x4b9000) at redirect.c:103
> #22 0x13d9d in clientAccessCheckDone (answer=1, data=0x4b9000)
> at client_side.c:215
> #23 0x65c5 in aclCheckCallback (checklist=0x4b2f00, answer=ACCESS_ALLOWED)
> at acl.c:1653
> #24 0x6428 in aclCheck (checklist=0x4b2f00) at acl.c:1613
> #25 0x68ae in aclNBCheck (checklist=0x4b2f00,
> callback=0x13cc8 <clientAccessCheckDone>, callback_data=0x4b9000)
> at acl.c:1763
> ---Type <return> to continue, or q <return> to quit---
> #26 0x13b16 in clientAccessCheck (data=0x4b9000) at client_side.c:162
> #27 0x1ad02 in clientReadRequest (fd=14, data=0x4b2d00) at
> client_side.c:2534
> #28 0x1e9b6 in comm_poll (msec=0) at comm_select.c:437
> #29 0x43731 in main (argc=2, argv=0xdfbfdcfc) at main.c:698
> ===
>
> ----- Original Message -----
> From: "Henrik Nordstrom" <hno@hem.passagen.se>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> Cc: <squid-dev@squid-cache.org>
> Sent: Sunday, January 21, 2001 12:46 AM
> Subject: Re: cc optimisation levels ?
>
> > Robert Collins wrote:
> > >
> > > I've just tracked down the problem reported by Grame on thursday
> > > to squid users on openbsd 2.8 as a -O2 issue with rfc1035.c
> >
> > Details please:
> > * Processor
> > * Compiler, version, patchlevel
> > * Compiler flags used
> > * Symptoms
> >
> > > Is there anything we can do in the code to allow higher
> > > optimisation levels?
> >
> > Not much besides
> > a) When it is our fault, fix the code
> > b) When it is the compilers fault, either fix the compiler or change our
> > code to work around the bug.
> >
> > > I think we should only pull the O level down for files that break -
> > > no need to reduce efficiency on the whole package.
> >
> > Would be quite a mess to maintain, and if the compiler is found to fail
> > on one file, how does you know that it doesn't produce similar errors in
> > other files? It is not like we have an extensive test suite that makes
> > sure each line of code is tested...
> >
> > /Henrik
> >
> >
Received on Sat Jan 20 2001 - 16:26:16 MST