[Bug c++/38242] New: Overeager ADL searches associated namespaces of base class's template arguments

2008-11-23 Thread eric dot niebler at gmail dot com
The following code compiles. It shouldn't. The operator+ should not be found.
According to 3.4.2/2, the associated namespace of a type includes those of its
bases and of its template arguments, but not its bases' template arguments.

namespace N
{
struct S {};
template
void operator+(T const &, U const &) {}
}

template struct X {};
struct Y : X {};

int main()
{
Y y;
y+y; // this should fail.
}


-- 
   Summary: Overeager ADL searches associated namespaces of base
class's template arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: eric dot niebler at gmail dot com
 GCC build triplet: g++ 4.3.0


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



[Bug c++/38433] New: Incorrect handling of line termination character with trailing spaces

2008-12-06 Thread eric dot niebler at gmail dot com
In the attached file, there is a comment terminated with a line-termination
character (\) followed by spaces. This should NOT be considered a line
terminator, yet gcc considers it as such. From 2.1/2 in the C++03 standard:

"Each instance of a new-line character and an immediately preceding backslash
character is deleted, splicing physical source lines to form logical source
lines."

That is, only backslashes immediately followed by a newline are considered line
terminators. The existing behavior of gcc violates the standard and conflicts
with the behavior of other popular C++ compilers (EDG, MSVC).


-- 
   Summary: Incorrect handling of line termination character with
trailing spaces
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
 GCC build triplet: Configured with: ../gcc-4.3.0/configure --enable-
languages=c,c++
GCC target triplet: i686-pc-cygwin


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



[Bug c++/38433] Incorrect handling of line termination character with trailing spaces

2008-12-06 Thread eric dot niebler at gmail dot com


--- Comment #1 from eric dot niebler at gmail dot com  2008-12-06 23:59 
---
Created an attachment (id=16843)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16843&action=view)
Compile with: g++ -Wall test.cpp


-- 


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



[Bug c++/38433] Incorrect handling of line termination character with trailing spaces

2008-12-06 Thread eric dot niebler at gmail dot com


--- Comment #3 from eric dot niebler at gmail dot com  2008-12-07 00:46 
---
If you are referring to 2.1/1 ...

"Physical source file characters are mapped, in an implementation-defined
manner, to the basic source character set (introducing new-line characters for
end-of-line indicators) if necessary. Trigraph sequences (2.3) are replaced by
corresponding single-character internal representations. Any source file
character not in the basic source character set (2.2) is replaced by the
universal-character-name that designates that character. (An implementation may
use any internal encoding, so long as an actual extended character encountered
in the source file, and the same extended character expressed in the source
file as a universal-character-name (i.e. using the \u notation), are
handled equivalently.)"

I read this as permitting a mapping of characters, but not a deletion of
characters, which is what gcc is doing. The only deletion of characters I see
permitted is the deletion of a newline and an IMMEDIATELY preceding backslash.


-- 


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



[Bug c++/39509] New: bad optimization(?) pure virtual function call with -O2

2009-03-19 Thread eric dot niebler at gmail dot com
When attached code is compiled with "g++ -01 -x c++ main.i" the result executes
file. When compiled with -O2 it segfaults with "pure virtual function call".
This may be a case of an overeager optimization.


-- 
   Summary: bad optimization(?) pure virtual function call with -O2
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/39509] bad optimization(?) pure virtual function call with -O2

2009-03-19 Thread eric dot niebler at gmail dot com


--- Comment #1 from eric dot niebler at gmail dot com  2009-03-20 03:03 
---
Created an attachment (id=17501)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17501&action=view)
tarred, gzipped preprocessed c++ source file


-- 


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



[Bug c++/39509] bad optimization(?) pure virtual function call with -O2

2009-03-19 Thread eric dot niebler at gmail dot com


--- Comment #2 from eric dot niebler at gmail dot com  2009-03-20 04:04 
---
Additional information: adding "__attribute__((noinline))" to the constructor
for xpression_adaptor (line 82452) makes the problem go away. Definitely looks
like an optimization problem to me.


-- 


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



[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

2009-04-20 Thread eric dot niebler at gmail dot com


--- Comment #4 from eric dot niebler at gmail dot com  2009-04-21 01:10 
---
I'm sorry to say that I no longer have access to the Linux machine on which I
gcc-4.3 installed. I have only my windows laptop now, and I can't for the life
of me get gcc-4.3 working under cygwin. I can, however, refer you to the
original bug report, filed against a library in Boost:

https://svn.boost.org/trac/boost/ticket/2655

For reference, here is the source code (requires Boost to be in the path, but
uses the header-only parts of Boost and so does not require you to build or
link to any part of Boost).

{{{
#include  
#include  
using std::string; 
namespace xpr = boost::xpressive;

int main()
{
string text = "at";

xpr::sregex r1 = xpr::as_xpr('a');
xpr::sregex r2 = 'b' >> r1;
xpr::sregex r3 = r2 | r1;

xpr::regex_replace(text, r3, string(""));
return 0;
}
}}}


-- 


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



[Bug c++/41141] New: Support for C++0x standard layout and trivial types is broken

2009-08-21 Thread eric dot niebler at gmail dot com
GCC is claiming support for Standard Layout Types
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm) in its 4.4
series. However, the following example, taken directly from n2342, fails to
compile (with either --std=gnu++0x or --std=c++0x):

{{{
 #include 

 struct B
 {
   int n;
   B() = default;
   B(int n_) : n(n_) {}
 };

 static_assert(std::is_pod::value, "B is not POD!");

 int main() {}
}}}

I have checked with Beman Dawes, the author of n2342, and he confirms that the
code should compile under a conforming c++0x compiler.


-- 
   Summary: Support for C++0x standard layout and trivial types is
broken
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/31730] New: nested typedef to template of same name rejected

2007-04-27 Thread eric dot niebler at gmail dot com
The following code should compile. With gcc 4.3 it does not.

   template struct match_context { };

   template
   struct match_state
   {
 typedef match_context match_context;
   };


-- 
   Summary: nested typedef to template of same name rejected
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/31730] nested typedef to template of same name rejected

2007-04-27 Thread eric dot niebler at gmail dot com


--- Comment #2 from eric dot niebler at gmail dot com  2007-04-27 21:24 
---
Yep, thanks. According to Doug Gregor, this case is covered in the first para
of
[basic.scope.class]. My bad.


-- 


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



[Bug c++/43330] New: trivial types are not being statically initialized

2010-03-11 Thread eric dot niebler at gmail dot com
According to the C++0x status page
(http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), "Standard Layout Types"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm) have been
implemented in gcc-4.5. A quick test shows that trivial types are not being
statically initialized, as the paper requires. The following struct S is
trivial and the non-local constant s should be statically initialized, IIUC:

  struct S
  {
S() {}
  };

  S const s{};

However, when compiled with -O2 -std=c++0x -S using the latest 4.5 snapshot, I
see the following assembly:

.file   "main.cpp"
.text
.p2align 4,,15
.def__GLOBAL__I_main.cpp;   .scl3;  .type   32; .endef
__GLOBAL__I_main.cpp:
pushl   %ebp
movl%esp, %ebp
popl%ebp
ret
.section.ctors,"w"
.align 4
.long   __GLOBAL__I_main.cpp

Unless I'm mistaken, the global s is still being dynamically initialized.
Apologies in advance if I'm reading this wrong.


-- 
   Summary: trivial types are not being statically initialized
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: eric dot niebler at gmail dot com
 GCC build triplet: gcc-4.5-20100304


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



[Bug c++/43330] trivial types are not being statically initialized

2010-03-11 Thread eric dot niebler at gmail dot com


--- Comment #2 from eric dot niebler at gmail dot com  2010-03-11 11:53 
---
You're right. Let me amend my example.

  struct S
  {
S() = default;
S(S const &) = default;
S(int i) : i(i) {}
int i;
  };

  S const s {1};

S would seem to satisfy the requirements for a trivial type now, correct? N2342
states:

"When an aggregate with static storage duration is initialized with a
brace-enclosed initializer-list, if all the member initializer expressions are
constant expressions, and the aggregate is a trivial type, the initialization
shall be done during the static phase of initialization"

GCC initializes s dynamically. That doesn't seem right. I see that constant
expressions are not yet implemented in gcc-4.5. Am I correct in assuming that
once constant expressions are implemented, this initialization will be static?


-- 


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



[Bug c++/43330] trivial types are not being statically initialized

2010-03-11 Thread eric dot niebler at gmail dot com


--- Comment #3 from eric dot niebler at gmail dot com  2010-03-11 11:56 
---
Oops, it's not an aggregate. Disregard.


-- 

eric dot niebler at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c++/33939] New: Rvalue references not deduced correctly in vararg function templates

2007-10-29 Thread eric dot niebler at gmail dot com
This is g++ with -std=c++0x flag. The compiler version is g++ (GCC) 4.3.0
20070921 (experimental).

I believe the following code should compile. It does not:

{{{
template
struct refs_only;

template
struct refs_only
{};

template
refs_only foo( T && t)
{
return refs_only();
}

template
struct va_refs_only;

template
struct va_refs_only
  : refs_only
{};

template
va_refs_only bar( T &&... t)
{
return va_refs_only();
}

int main()
{
int j = 0;
foo(j);
bar(j); // error: invalid use of incomplete type 'struct refs_only'
}
}}}

The use of template varargs should not affect the type that the compiler is
deducing for the parameter {{{j}}}.


-- 
   Summary: Rvalue references not deduced correctly in vararg
function templates
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/33943] New: ICE with partial specialization on vararg template template parameter

2007-10-29 Thread eric dot niebler at gmail dot com
Compiled with -std=c++0x, version g++ (GCC) 4.3.0 20070921 (experimental), the
following program causes an ICE.

{{{
template
struct foo {};

template
struct bar {};

template
struct baz;

template class T, typename... U>
struct baz< T >
{};

template class T, typename U, typename... V>
struct baz< T >
{};

baz< foo > b1;
baz< bar > b2;
}}}


-- 
   Summary: ICE with partial specialization on vararg template
template parameter
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/33955] New: internal compiler error: in dependent_type_p, at cp/pt.c:15245 (vararg template problem)

2007-10-30 Thread eric dot niebler at gmail dot com
Compile the attached preprocessed file with "g++ -std=c++0x -c -x c++ bug.i".
The compiler ICEs. Seems to be a problem with template varargs.

This is with the latest g++, built from svn on 10/30/2007, with some patches
from Doug Gregor for various problems.


-- 
   Summary: internal compiler error: in dependent_type_p, at
cp/pt.c:15245 (vararg template problem)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/33955] internal compiler error: in dependent_type_p, at cp/pt.c:15245 (vararg template problem)

2007-10-30 Thread eric dot niebler at gmail dot com


--- Comment #1 from eric dot niebler at gmail dot com  2007-10-31 05:56 
---
Created an attachment (id=14446)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14446&action=view)
preprocessed source code


-- 


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



[Bug c++/33964] New: internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)

2007-10-31 Thread eric dot niebler at gmail dot com
I'm not sure if the following should compile or not, but it certainly should
ICE the compiler. Latest gcc from SVN with vararg template patches from Doug
Gregor. Build with -std=c++0x.

Doug, no rush on this one. Just logging it for posterity.

template
struct foo
{
static bool const value = true;
};

template
struct foo< typename Args::is_applied... >
{
static bool const value = false;
};

struct not_applied { typedef void is_applied; };
struct applied { typedef applied is_applied; };

int main()
{
foo i;
}


-- 
   Summary: internal compiler error: in dependent_type_p, at
cp/pt.c:15319 (vararg templates)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/33965] New: internal compiler error: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.c:6955 (vararg templates)

2007-10-31 Thread eric dot niebler at gmail dot com
In the following SFINAE scenario involving vararg templates an non-type
template parameters, the compiler ICEs instead of ignoring the specialization.

Latest SVN g++ with patches from Doug Gregor for vararg templates.

template
struct foo
{
static bool const value = false;
};

template class T, typename... Args>
struct foo >
{
static bool const value = false;
};

template
struct int_
{};

int main()
{
foo > f; // ICE
}


-- 
   Summary: internal compiler error: tree check: expected class
'type', have 'constant' (integer_cst) in cp_type_quals,
at cp/typeck.c:6955 (vararg templates)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/34022] New: Rvalue references and std::forward() broken with built-in types

2007-11-07 Thread eric dot niebler at gmail dot com
Compile the following program with -std=c++0x. In my understanding, the two
printed addresses should be the same. They are when I invoke foo() with a class
type, but not with built-in types like char.

This is with the latest g++ built from SVN.

#include 
#include 

template void bar(T &&t)
{
std::printf("%p\n", &t);
}

template void foo(T &&t)
{
std::printf("%p\n", &t);
bar(std::forward(t));
}

struct S {};

int main()
{
foo('a'); // WRONG, prints 2 different addresses
foo(S()); // OK, prints the same address twice
}


-- 
   Summary: Rvalue references and std::forward() broken with built-
in types
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/34032] New: -std=c++0x causes undeclared symbols errors on cygwin

2007-11-08 Thread eric dot niebler at gmail dot com
Building with -std=c++0x causes __STRICT_ANSI__ to be defined. The new C++
headers expect the system C headers (ctype.h, stdio.h, etc.,) to declare
certain functions (isblank(), snprintf(), etc.) that are part of C++0x. The
system C headers that are part of cygwin aren't privy to this. The result is
that simple programs like the following to not compile with -std=c++0x on a
stock cygwin install.

  #include 
  int main() {}

The error is:

In file included from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/cctype:98,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/bits/localefwd.h:49,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/ios:47,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/ostream:45,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/iostream:45,
 from main.cpp:1:
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c++/4.3.0/tr1_impl/ccty
pe:43: error: '::isblank' has not been declared



For another example, the following program also does not compile on cygwin with
-std=c++0x:


  #include 

  int main()
  {
char buf[50];
snprintf(buf, 50, "hello");
  }


main.cpp: In function 'int main()':
main.cpp:6: error: 'snprintf' was not declared in this scope


This is with a stock g++ built on cygwin from latest source from svn,
configured with "--prefix=/usr/local/g++-4.3 --enable-languages=c,c++".


-- 
   Summary: -std=c++0x causes undeclared symbols errors on cygwin
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
  GCC host triplet: cygwin


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



[Bug c++/34032] -std=c++0x causes undeclared symbols errors on cygwin

2007-11-08 Thread eric dot niebler at gmail dot com


--- Comment #2 from eric dot niebler at gmail dot com  2007-11-08 19:16 
---
I didn't know about -std=gnu++0x. That seems to work. -std=c++0x doesn't. 

FWIW, the stock gcc that comes with cygwin is 3.4:
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.


-- 


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



[Bug c++/34314] New: ICE on invalid code (with variadic templates): tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in template_class_depth

2007-12-02 Thread eric dot niebler at gmail dot com
Compile with -std=c++0x

template
struct call;

template
struct call
{
template
struct result;

template
struct result
{
typedef X type;
};
};


-- 
   Summary: ICE on invalid code (with variadic templates): tree
check: expected class ‘type’, have ‘exceptional’
(error_mark) in template_class_depth
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/34700] New: rvalue erroneously binding to non-const lvalue reference

2008-01-06 Thread eric dot niebler at gmail dot com
Consider the following code, compiled with the latest gcc built from sources,
with the -std=c++0x flag:

#include 
struct S
{
S() {}
S(S &s) { std::cout << "L-value ref" << std::endl; }
S(S &&s) { std::cout << "R-value ref" << std::endl; }
};

S source() { static S s; return s; }

int main()
{
std::cout << "here 1 \n";
S s;
std::cout << "here 2 \n";
S t(s);
std::cout << "here 3 \n";
S u(source()); // ERROR HERE
}

For me, this prints:

here 1
here 2
L-value ref
here 3
L-value ref

It should print:

here 1
here 2
L-value ref
here 3
R-value ref

An rvalue should under no circumstance bind to a non-const lvalue reference.


-- 
   Summary: rvalue erroneously binding to non-const lvalue reference
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
     Component: c++
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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



[Bug c++/29653] New: boost/mpl/aux_/has_tag.hpp:20: internal compiler error: Segmentation fault

2006-10-30 Thread eric dot niebler at gmail dot com
, 1l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::pass_through_transformer, 1l> >,
boost::proto::ref, 1l>
> >, 2l>, mpl_::void
_, boost::spirit2::skipper_tag>, boost::fusion::void_> >'
../../../boost/xpressive/proto/compiler/pass_through.hpp:60:   instantiated
from 'boost::proto::pass
_through_compiler::apply, 1l> >, boost::proto::basic_expr, 1l> >, 2l> >, boost::proto::basic_expr, 1
l> >, 2l> >, boost::proto::basic_expr, 1l> >,
2l> >, boost::proto::basic_expr, 1l> >, 2l>, b
oost::proto::basic_expr, 1l> >, boost::p
roto::ref
, 1l> > >, 2l>, mpl_::void_, boost::proto::right_shift_tag>'
../../../boost/xpressive/proto/compiler/conditional.hpp:40:   instantiated from
'boost::proto::condi
tional_compiler
>::apply, 1l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l>,
boost::proto::basic_expr, 1l> >,
boost::proto::ref, 1l> > >, 2l>, mpl_::void_>'
../../../boost/xpressive/proto/compile.hpp:25:   instantiated from
'boost::proto::meta::compile, 1l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l> >,
boost::proto::basic_expr, 1l> >, 2l>,
boost::proto::basic_expr, 1l> >,
boost::proto::ref, 1l> > >, 2l>, mpl_::void_,
boost::spirit2::skipper_tag>'

main.cpp:605:   instantiated from 'bool boost::spirit2::parse(FwdIter, FwdIter,
const Rule&, const S
kipper&) [with FwdIter = __gnu_cxx::__normal_iterator, std::allocator > >, Rule =
boost::proto::basic_expr, 1l> >, boost::proto::basic_expr, 1l> >,
2l> >, boost::proto::basic_expr, 1l> >, 2l> >,
 boost::proto::basic_expr, 1l> >, 2l> >, boost
::proto::basic_expr, 1l>
>, 2l>, Skipper = boo
st::proto::basic_expr, 1l> >, boost::pro
to::ref,
1l> > >, 2l>]'
main.cpp:692:   instantiated from here
../../../boost/mpl/aux_/has_tag.hpp:20: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: boost/mpl/aux_/has_tag.hpp:20: internal compiler error:
Segmentation fault
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
 GCC build triplet: Configured with: ../gcc-4.1.1/configure --enable-
languages=c,c++
  GCC host triplet: CYGWIN_NT-5.1 AERIX-DESK 1.5.21(0.156/4/2) 2006-07-30
14:21 i686
GCC target triplet: i686-pc-cygwin


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



[Bug c++/29653] boost/mpl/aux_/has_tag.hpp:20: internal compiler error: Segmentation fault

2006-10-30 Thread eric dot niebler at gmail dot com


--- Comment #1 from eric dot niebler at gmail dot com  2006-10-30 15:42 
---
Created an attachment (id=12513)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12513&action=view)
preprocessed input file

preprocessed input file, compressed because of file size restrictions


-- 


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



[Bug c++/29701] New: mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus overload ambiguity

2006-11-03 Thread eric dot niebler at gmail dot com
Attached preprocessed code compiles with gcc 3.4.4 and gcc 4.0.3, fails with
4.1.1. Compiler is not preferring a function template over a vararg function.


-- 
   Summary: mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus
overload ambiguity
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
GCC target triplet: i686-pc-cygwin


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



[Bug c++/29701] mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus overload ambiguity

2006-11-03 Thread eric dot niebler at gmail dot com


--- Comment #1 from eric dot niebler at gmail dot com  2006-11-03 20:01 
---
Created an attachment (id=12543)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12543&action=view)
preprocessed input file

preprocessed C++ source code.


-- 


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