help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave chokes on this in some systems


From: Shai Ayal
Subject: Re: Octave chokes on this in some systems
Date: Wed, 30 Nov 2005 11:32:11 +0200
User-agent: Thunderbird 1.5 (X11/20051025)

I am not sure what is the status of this problem, especially if something has been done regarding this in the fc4 rpm's.

I now understand John's position on hiding bugs and I agree with him that we should work to fix the bug in gcc rahter than workaround in octave. However, what should be done in the meantime?

My suggestion is to advise against compiling with gcc-4 until it has been resolved -- maybe add in the README or somewhere appropriate: "Warning: gcc 4.0.0 -> gcc 4.0.x has a bug which might affect ...." where one day, when it is resolved, we can fill in the x.

As for the fc4 packages, I suggest that they should be compiled with gcc32,g++32,g77 available for fc4. This is what I do now when compiling from source and all works well, even when combining with the fc4 lapac, atlas & fftw3 packages (presumably since they are not c++ and not linked against any c++ code, so they are not affected by this bug). I do not follow gcc development: does gcc-4 has some "killer feature" which would make using gcc32 to compile octave too big a setback?

IF we do it this way we have a rpm which we know is free of this bug without hiding anything, or patching octave, just avoiding buggy code by using a bug-free version of gcc.

Shai

John W. Eaton wrote:
On 15-Nov-2005, Quentin Spencer wrote:

| I'm willing to update the Fedora release of 2.1.72 with this patch, but | for some reason when I tried patching the sources with your patch, it | didn't work. I keeps complaining that the patch is reversed, even though | it looks correct--maybe I found a bug in patch. Maybe this is the same | thing Paul ran into yesterday.

I don't understand why patch is failing.  The patch also looks correct
to me (it is supposed to be removing the resize function from
oct-obj.cc and adding it to oct-obj.h).

In any case, I'm not yet convinced that the bug is in GCC or Octave.

Can you please try the following and see if it avoids the bug:

  export GLIBCXX_FORCE_NEW=1
  octave
  ...
  octave:1> test_caller

Setting this environment variable forces the mt_allocator in GCC 4.0.2
to always use new/delete instead of the custom allocator.  Doing that
makes the code work for me. Otherwise, it is crashing inside
  void __pool<true>::_M_reclaim_block(char* __p, size_t __bytes)

in mt_allocator.cc (part of libstdc++).  Older versions of
mt_allocator (up until GCC 3.4, it appears) always used operator
new/delete.  So this is starting to look like a bug in mt_allocator,
but I still don't know how to write a concise test case for the bug
without doing a lot of work.

I still think that applying the patch is just hiding the bug, and so
it would not surprise me to find it biting again somewhere else.

BTW, I tried building Octave with the current SVN sources of GCC to
see if the problem was already fixed.  Unfortunately it was not.
Doubly unfortunate is that the C++ compiler seems much slower now
(maybe more optimizations?) and it took >10 minutes to create
liboctinterp.so.  Would someone like to verify this problem and
compare the build times (possibly also timing some individual steps
like creating shared libraries) between GCC 3.4, 4.0, and the current
SVN sources of GCC?  If GCC built from the current sources is really
as slow as I experienced (and the problem wasn't due to something
stupid that I did) then I think we need to report the problem.

jwe

--
Shai Ayal, Ph.D.
Head of Research
BioControl Medical BCM
3 Geron St.
Yehud 56100
ISRAEL
Tel:  + 972 3 6322 126 ext 223
Fax:  + 972 3 6322 125
email: address@hidden



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]