Bug 519010 - Compiling a program works in -O0 but don't work with -O2
Summary: Compiling a program works in -O0 but don't work with -O2
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-24 15:23 UTC by Victor Bogado
Modified: 2009-09-08 13:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-08 09:58:20 UTC
Type: ---


Attachments (Terms of Use)
test program (1.19 KB, text/x-c++src)
2009-08-24 15:23 UTC, Victor Bogado
no flags Details

Description Victor Bogado 2009-08-24 15:23:11 UTC
Created attachment 358471 [details]
test program

Description of problem:
If I compile the attached program with -O1 it have no results, while if I had used -O0 it yields the results that I expect. It should work in a similar way of a ls but giving "size = filename" for each given file. (it ignores directories)

Version-Release number of selected component (if applicable):
4.4.0-4.x86_64

How reproducible:
everytime

Steps to Reproduce:
1. compile the test with "gxx test.cc -O0 --std=c++0x -o test"
2. run "./test test*", verify that it outputs something similar to :
files in container : 2
1219 = test.cpp
85767 = test
3. repeat steps 1 and 2 with "-O1" instead of "-O0" and get the following result: 
files in container : 2
 
Actual results:
The run with and without optimizations are different.

Expected results:
The run with and without optimizations should be identical.

Additional info:
With the aid of localized printing I identified that what is becoming different is the printing loop at the end of the main function.

Comment 1 Jakub Jelinek 2009-09-02 11:12:23 UTC
This doesn't even compile:
/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/tr1_impl/type_traits: In function 'bool boost::filesystem::is_empty(const boost::filesystem::path&)':
/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/tr1_impl/type_traits:326: error: 'template<class _Tp> struct std::is_empty' is not a function,
/usr/include/boost/filesystem/operations.hpp:361: error:   conflict with 'template<class Path> typename boost::enable_if<boost::filesystem::is_basic_path<Path>, bool>::type boost::filesystem::is_empty(const Path&)'
/usr/include/boost/filesystem/operations.hpp:660: error:   in call to 'is_empty'
/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/tr1_impl/type_traits: In function 'bool boost::filesystem::is_empty(const boost::filesystem::wpath&)':
/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/tr1_impl/type_traits:326: error: 'template<class _Tp> struct std::is_empty' is not a function,
/usr/include/boost/filesystem/operations.hpp:361: error:   conflict with 'template<class Path> typename boost::enable_if<boost::filesystem::is_basic_path<Path>, bool>::type boost::filesystem::is_empty(const Path&)'
/usr/include/boost/filesystem/operations.hpp:662: error:   in call to 'is_empty'

Comment 2 Victor Bogado 2009-09-03 12:23:28 UTC
You need to have the latest boost '1.37.0-7.fc11.x86_64', I think it is on testing yet. I also forgot to mention that it requires the -lboost_filesystem-mt lib in the command line.

The correct comand line to test it is the following : 

--------------------------------------------------------------------
$ g++ test.cc -O0 --std=c++0x -lboost_filesystem-mt -o test

$ ./test *
files in container : [number of files in this dir]
[size_1] = [filename_1]
[size_2] = [filename_2]
[size_3] = [filename_3]
...
[size_n] = [filename_n]

$
--------------------------------------------------------------------
The weird part happend when you use -O1 as bellow : 
--------------------------------------------------------------------
$ g++ test.cc -O1 --std=c++0x -lboost_filesystem-mt -o test

$ ./test *
files in container : [number of files in this dir]

$
--------------------------------------------------------------------

As you can see it seems to have populated the container correctly but have not printed the result, as it did when compiling without optimizations.

Comment 3 Victor Bogado 2009-09-03 12:25:34 UTC
-O1 is the lowest optimization that I got this behaviour, -O2 and -O3 get the same result as the -O1.

Comment 4 Jakub Jelinek 2009-09-08 09:58:20 UTC
Before you submit a bugreport it is better if you bother to compile with -W -Wall:

rh519010.C: In member function ‘std::_Rb_tree_iterator<std::pair<const long long int, boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> > > FileCollection::begin()’:
rh519010.C:46: warning: no return statement in function returning non-void
rh519010.C: In member function ‘std::_Rb_tree_iterator<std::pair<const long long int, boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> > > FileCollection::end()’:
rh519010.C:51: warning: no return statement in function returning non-void

From this it would be obvious the bug is on your side.

Comment 5 Victor Bogado 2009-09-08 13:51:38 UTC
Ops., I usually do compile with -Wall and -Werror, but for some reason my project is not using them, I even stated in the configure.ac :

AM_INIT_AUTOMAKE([-Wall -Werror foreign dist-bzip2 subdir-objects])

But I checked now and there was no -Wall nor -Werror on the compilation command lines on the project. :-( I am a newbie on using auto-tools, sorry about that.


Note You need to log in before you can comment on or make changes to this bug.