can auto type deduction possibly cause conversion error?

Question

I have a very simple parser rule (for AXE), like this:

auto space = axe::r_lit(' ');
auto spaces = space & space & space;

The last line compiles and works as expected in VC2010, but gives a strange error in gcc 4.6:

parsers.cpp:68:34: error: conversion from 
'axe::r_and_t<
    axe::r_and_t<axe::r_char_t<char>&, axe::r_char_t<char>&>, 
    axe::r_char_t<char>&
>' to non-scalar type 
'axe::r_and_t<
    axe::r_and_t<axe::r_char_t<char>&, axe::r_char_t<char>&>&, 
    axe::r_char_t<char>&
>' requested

I wonder, whether it's a (known) bug in gcc, and whether it's even possible to get conversion errors with auto declaration. Shouldn't the deduced type for auto be always exactly the same type as the initializer?

AXE overloads operator& like this:

template<class R1, class R2>
r_and_t<
    typename std::enable_if<
       is_rule<typename std::remove_reference<R1>::type>::value, R1>::type, 
    typename std::enable_if<
       is_rule<typename std::remove_reference<R2>::type>::value, R2>::type
>
operator& (R1&& r1, R2&& r2)
{
    return r_and_t<R1, R2>(std::forward<R1>(r1), std::forward<R2>(r2));
}

I wasn't able to reduce the problem to a short test case, unfortunately every time I try to come with simple example, it compiles.

Answer 1

auto is not always exactly the type of initializer, because auto is dropping references, making it type T where you would expect T&. If you need reference - spell auto&.

Answer 2

Don't rate this answer, it's for information purposes only

This was indeed a bug in previous versions of gcc, it was fixed in gcc-4.7.0.