|
|
Blitz Bugs : |
From: Julian Cummings (cummings_at_[hidden])
Date: 2004-01-20 20:33:15
This is a cross-posting from the blitz-support mailing list, addressing
a couple of old items that were posted on the blitz-bugs mailing list.
Dave Johnson wrote:
>
> I see the following reports in the lists with no followups. I don't
> understand how I would know if these were fixed or not. And which
> changes were important for them.
>
> * To: blitz-bugs_at_[hidden]
> * Subject: [Blitz-bugs] Bug with range-assignments in
> Fortran-style arrays, if optimizing
> * From: Christopher Eltschka
> <christopher.eltschka_at_[hidden]>
> * Date: Thu, 07 Aug 2003 21:15:57 +0200
> * Organization: Physik
>
This bug appears to have been cleared up already, either in the move
from blitz 0.6 to 0.7, or in upgrading from gcc 3.2.3 to gcc 3.3. I
cannot reproduce the bug.
> *
>
>
> * To: blitz-bugs_at_[hidden]
> * Subject: [Blitz-bugs] Ouch! (-O causes blitz 0.7 bug?)
> * From: Creon Levit <creon_at_[hidden]>
> * Date: Tue, 2 Dec 2003 19:29:39 -0800
>
I was able to reproduce this bug, which was triggered by repeatedly
assigning a scalar to a slice of an Array. The code would crash during
the second assignment if compiled with gcc 3.3 and optimization -O1 or
higher. After some fiddling, I found that the problem occurs between
the call to Array::initialize(T_numtype) and the resulting call to
Array::operator=(ETBase<T_expr>&). The gcc optimizer is doing something
wrong here because the Array's data_ pointer suddenly becomes null, even
though we do nothing more than access (*this) between the two function
calls. I discovered that the bug is triggered by the inlining of the
Array::initialize(T_numtype) function, so I have removed the inline
keyword on line 39 of <blitz/array/ops.cc> in order to resolve this bug.
Regards, Julian C.
-- Dr. Julian C. Cummings E-mail: cummings_at_[hidden] California Institute of Technology Phone: 626-395-2543 1200 E. California Blvd., Mail Code 158-79 Fax: 626-584-5917 Pasadena, CA 91125