On Thu, Jan 02, 2003 at 01:37:29PM +0100, Marko Asplund via RT wrote:
> On Tue, 31 Dec 2002, Andy Polyakov via RT wrote:
>
> > First of all it would facilitate if you could file a single problem per
> > report. In which the person who is considering to close the ticket won't
> > end up judging over things he doesn't feel like capable of judging.
> > ...
>
> i'm sorry about this but i didn't file the problem reports explicitly, i
> just sent the reports to [EMAIL PROTECTED] without realizing they
> would end up in the request tracker.
When walking through the mailbox I tend to bounce messages that I consider
important enough into the request tracker.
> > As implied in RT#410 closing note it smells like a compiler bug. From my
> > personal experience HP compilers seldom work out-of-the-box and usually
> > require patching. In either case do try to lower the optimization level
> > [as INSTALL suggests]!
>
> changing optimization level from +O3 to +O2 in the hpux-parisc2-cc target
> seems to fix the BN_kronecker test problem with the no-asm option. i'll
> try and see if HP has patches related to this issue.
I am not yet sure about the backgrounds. I just ran to tests on a PA-RISC 2
machine:
* hpux-parisc-cc no-asm
* hpux-parisc2-cc no-asm
Both settings compile with +O3 but the last one fails in BN_kronecker test
(endless loop) when compiled with HP's ANSI C compiler on HP-UX 10.20.
# what /opt/ansic/bin/cc
/opt/ansic/bin/cc:
LINT A.10.32.30 CXREF A.10.32.30
HP92453-01 A.10.32.30 HP C Compiler
/usr/lib/libc: $Revision: 76.3 $
The difference between both settings is, that in hpux-parisc-cc there is
cflags= ... -DBN_DIV2W -DMD32_XARRAY
bn_ops= MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT
while for hpux-parisc2-cc there is
cflags= ... -DMD32_XARRAY
bn_ops= SIXTY_FOUR_BIT MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1
It therefore has to be determined, which of the defines (BN_DIV2W,
SIXTY_FOUR_BIT, DES_INT) that are different, is triggering the problem.
I am using HP's ANSI compilers since a decade now and have learned that
the compilers are better than their reputation. More or less all problems
appearing could finally be tracked down to a bug in the application.
For +O2/+O3 differences: up to +O2 automatic variables are initialized
to 0 by the compiler; as of +O3 this is not done any longer. Therefore
application failures when using +O3 can be caused by the use of uninitialized
variables. It is therefore be possible, that there is some uninitialized
variable somewhere in the bignum code that only shows its effect when
the defines discussed above are set (or not) and +O3 is being used.
I therefore hesitate to simply declare this a compiler bug.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
