Hi Harry,
On Wed, Jan 04, 2012 at 01:16:57PM +0100, Harry van der Wolf wrote:
> 2012/1/4 Carlos Eduardo G. Carvalho (Cartola) <[email protected]>
>
> > gcc version 4.2.1 20070719 [FreeBSD]
> I don't think it has to do with the compiler but with the data declarations
> in the program.
I'm sorry. I forgot a sentence in my post....
Either it is something with the compiler, OR there is something wrong in
the program.
Either the program does something that "could" crash always (*), but
because of compiler-details sometimes works just fine. And in this case the
compiler details happen to be "-O" versus "-O2".
(*) I.e. according to the language standard the behaviour is undefined.
An example is:
int *p;
p = malloc (sizeof (int));
*p = something ();
....
free (p);
y = *p; // Undefined.
In practise this piece of code will almost always set a value for "y".
Depending on implementation details, the value of y might even be
the value returned by the "something ()" function. However the behaviour
is undefined: The program could segfault. For example, the "free"
function could determine that the page where *p resides is no longer
used at all and return it to the operating system.
(*) I.e. according to the language standard the behaviour is undefined.
> For what it's worth.
> When doing a straight compilation on MacOSX (snow leopard 10.6.8): g++ 4.2
> is used and -O2 works fine. So, this will ceate a x86_64 64bit binary which
> works fine.
> When crosscompiling, using a massive set of all kind of settings, the
> x86_64 version is compiled with g++ 4.2 as well. However, as it needs to
> run on Leopard, Snow Leopard and Lion I use that set of extra settings. For
> this version when using -O2 it segfaults. -O works.
> The i386 binary is compiled with g++ 4.0 otherwise it wouldn't run on on
> Tiger. These segfault also with -O2 and work fine with -O.
> (note: other binaries which I cross-compile for triple universal
> x86_64/i386/ppc, the ppc part is also compiled with gcc/g++ 4.0 for the
> same reason).
I've tried to put things in a table
http://gaia.bitwizard.nl/wiki/index.php/Multiblend_segfault_problem
Is this about correct?
> Next to that: Versions of enblend before version 4.0 were "unstable" when
> cross-compiling with -O3 but worked fine with -O2. Version 4.0 and some
> development versions before that, worked fine with -O3. Somewhere during
> the development I tried switching to -O3 and it "suddenly" worked. I don't
> have a clue which changeset(s) made this possible.
Enblend has always "made mistakes" that sometimes result in black bands
across the result or segfaults. This usually didn't happen on small images
but only on larger ones. Again this COULD be a compiler issue, but a
coding problem in enblend is more likely.
As to your "-O3" problems, it could be that the compiler optimizes
something that cannot be optimized or it could be an undefined behaviour
that exhibits itself only with -O3.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
