469,602 Members | 1,675 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,602 developers. It's quick & easy.

gnu optimization bug

Recently i found that my C++ program was running fine with no
optimization and giving segmentation fault with error code 139 when
compiled with optimization level 2. I searched somewhat but never find
any systematic solution. In my recent attempt, i found the problem with
the optimization tool itself, which iam discussing here.

I found that the problem of segmentation fault was boiled down to a
statement of the form A = B, with no pointer or array usage, so forget
about the illegal memory write problems. When i removed this statement,
the problem disappers, so concluded that the segmentation fault problem
is with this statement. A careful study revealed that this statement
was redundant because A was never used in the program after this
statement. So i inserted one more statement after the above statement
which is "X = A", where X is a dummy variable and in that case the
problem again disappears. Inserting this new statement has made my
initial statement no more redundant.

I think the optimization tool had detected that A = B is a redundant
statement but failed to do its work. So its a clear bug in the
optimization tool itself.

The gcc -v output of my system is following:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 (Debian 4.0.2-2)

May 31 '06 #1
3 2067

"Abhishek" <ab************@gmail.com> wrote in message

| Recently i found that my C++ program was running fine with no
| optimization and giving segmentation fault with error code 139 when
| compiled with optimization level 2. I searched somewhat but never find
| any systematic solution. In my recent attempt, i found the problem with
| the optimization tool itself, which iam discussing here.

You should take the topic to the gcc mailing list.

Sharad
May 31 '06 #2
Abhishek wrote:
[g++ bug report redacted]

Bug reports for particular compilers are off-topic in this group. All we can
do is help you determine whether there is actually a bug. Since you did not
post the code, which may or may not exhibit undefined behavior, we cannot
help with that either.
Best

Kai-Uwe Bux

May 31 '06 #3
Abhishek wrote:
Recently i found that my C++ program was running fine with no
optimization and giving segmentation fault with error code 139 when
compiled with optimization level 2. I searched somewhat but never find
any systematic solution. In my recent attempt, i found the problem with
the optimization tool itself, which iam discussing here.

I found that the problem of segmentation fault was boiled down to a
statement of the form A = B, with no pointer or array usage, so forget
about the illegal memory write problems. When i removed this statement,
the problem disappers, so concluded that the segmentation fault problem
is with this statement. A careful study revealed that this statement
was redundant because A was never used in the program after this
statement. So i inserted one more statement after the above statement
which is "X = A", where X is a dummy variable and in that case the
problem again disappears. Inserting this new statement has made my
initial statement no more redundant.

I think the optimization tool had detected that A = B is a redundant
statement but failed to do its work. So its a clear bug in the
optimization tool itself.


Without any more code, it's hard to say if you're right. What type are A and
B? Could you provide a minimal, but complete program that shows the
behavior. Sometimes, a program crash happens in a place different from the
one that contains the error.

As others already mentioned: A g++ bug report would have to go to a
different place than here, but here, we could tell you if it's actually a
bug in the compiler or an error in your code. However, for that, you'd have
to show some code.

May 31 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Alex Vinokur | last post: by
9 posts views Thread by Rune | last post: by
5 posts views Thread by AC Slater | last post: by
2 posts views Thread by Eugene | last post: by
21 posts views Thread by mjbackues at yahoo | last post: by
5 posts views Thread by wkaras | last post: by
20 posts views Thread by Ravikiran | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.