Trying to understand a GCC error

Question

I have the following bit of code:

#include <iostream>
#include <list>
#include <algorithm>
#include <iterator>

template<typename Iterator>
void foo(Iterator begin, Iterator end)
{
   typedef typename std::iterator_traits<Iterator>::value_type type;
   type smallest = (*std::min_element(begin,end));
   std::cout << smallest << std::endl;
}

int main()
{
   std::list<int> l;
   l.push_back(1);   
   l.push_back(2);
   foo(l.begin(),l.end());
   return 0;
}

when I compile it as follows:

g++ -pedantic -ansi -Wall -Werror -O2 -o test test.cpp

I get the following error:

cc1plus: warnings being treated as errors In function ‘int main()’: cc1plus: error: dereferencing pointer ‘pretmp.163’ does break strict-aliasing rules cc1plus: note: initialized from here

This error is seen with O3, but not with O1. I've compiled the code using the comeau online compiler, MS VC9.0 and icc v11 and in all cases the code compiles without an issue.

The code works fine with std::vector, std::deque, std::set, char*, int* iterators, seems to be something very specific to the implementation of std::list.

I was hoping someone could provide some insight into what this particular error(warning) means and how to go about resolving it.

Note: The GCC version is:

gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Answer 1

No clu 'bout gnu ... but this seems useful : http://code.google.com/p/v8/issues/detail?id=413

Answer 2

Just hazarding a guess: if you declared the args of foo to be const, it may fix this issue. The "aliasing" issue, if I understand it correctly, comes up when more than one pointer in a loop could be pointing to the same data - this leads to potential order of operation bugs with some optimizations (which is what the warning is referring to).

Answer 3

Here's a bugzilla case that seems to represent this problem or something very similar:

• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937

It's marked as fixed in 4.4.0, so you've either run into another corner case, or ???. But this bug might give you a leg up on a resolution for you.