[Bug c++/26904] A template named the same as its member confuses lookup through inheritance
--- Comment #3 from dave at boost-consulting dot com 2006-05-01 02:43 --- I'm afraid I don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
[Bug c++/40063] New: Internal Compiler Error with -std=gnu++0x
Compile the enclosed with g++-4 fu.cpp -o /tmp/fu -- Summary: Internal Compiler Error with -std=gnu++0x Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com GCC build triplet: 4.4.0 GCC target triplet: i386-apple-darwin-9.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40063
[Bug c++/40874] New: Function object abstraction penalty
The following program shows that wrapping a simple class around a function
pointer costs important optimizations. If you change the #if 1 to #if 0,
you'll see that the call is completely optimized away.
#if 1
struct pf
{
inline pf(int(*x)(int)) : x(x) {}
inline int operator()(int a) const
{
return x(a);
}
int (*x)(int);
};
#else
typedef int(*pf)(int);
#endif
inline int g(int x) { return x/x - 1; }
int main(int argc, char* argv[])
{
pf f(g);
return f(3);
}
--
Summary: Function object abstraction penalty
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave at boost-consulting dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #3 from dave at boost-consulting dot com 2009-07-27 16:26 --- The missing inlining is the cause, abstraction penalty is the symptom. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #6 from dave at boost-consulting dot com 2009-07-28 18:42 --- The next step would be to verify that the penalty is eliminated when using boost::function / tr1::function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug c++/25185] New: deep typedef substitution in error message
The enclosed produces the following as part of the error backtrace:
../../../../boost/sequence/make_range.hpp:60: instantiated from
'boost::sequence::range_::range::type>
boost::sequence::detail::range_maker::operator()...
note boost::result_of::type, which is a typedef name. GCC
should show a "canonical" type name here.
--
Summary: deep typedef substitution in error message
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave at boost-consulting dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #1 from dave at boost-consulting dot com 2005-11-30 17:48 --- Created an attachment (id=10370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10370&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-23 04:55 --- "should GCC try and remember which arguments were really specified in the template-id (hard to do), or a simple check of equalness between the argument and the default parameter would suffice?" GCC should not try to remember the arguments. That path is a slippery slope, and leads to things similar to "deep typedef substitution," which makes error messages much harder to read than necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-23 12:55 --- Doesn't sound right to me. I think you should either show vector or include A in the "with" clause of vector. I'm sort of inclined to the former; Don't forget that parameter names are not always so short. Another related issue is that "with" clauses are sometimes unhelpful, as in the case you cite. vector is much, much clearer. GCC ought to have a heuristic based on the lengths of the version with the "with" clause and the version with a full argument substitution, to decide whether to use "with" or just substitute the arguments in-line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-26
02:01 ---
Subject: Re: Do not print default template arguments in error messages
"gdr at integrable-solutions dot net" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From gdr at integrable-solutions dot net
> 2005-03-25 22:06 ---
> Subject: Re: Do not print default template arguments in error messages
>
> "giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes:
>
> | --- Additional Comments From giovannibajo at libero dot it 2005-03-23
> 02:44 ---
> | I'll try to do this. This is a simple testcase:
> |
> | ---
> | template
> | struct A
> | {
> |typedef typename T::x x;
> | };
> | void foo(void)
> | {
> | A a;
> | }
> | ---
> | test.cc: At global scope:
> | test.cc: In instantiation of 'A':
> | test.cc:8: instantiated from here
> | test.cc:4: error: 'void' is not a class, struct, or union type
> |
> | Do we want the error message to show 'A' or 'A'? In other
> words,
>
> Most of the time, we want to print what user wrote.
That rule could be really bad in cases like:
A::value>
The actual identity of the 2nd argument is usually far more important
at the point where the error is reported than seeing the way the user
wrote it, and the deduction needed for the user to determine that
foo::value is actually 0, 1, or whatever can be arbitrarily
complicated. The user may have to look through an arbitrary number of
template definitions in arbitrary locations, finding all
specializations and essentially doing instantiation by hand. By
contrast, finding out how a template argument was written is trivial
because GCC gives you a nice backtrace where you will see each
template in the instantiation chain being supplied with arguments.
Please, I'm begging you not to go down this road. GCC is one of the
only compilers that gets it right today (VC8 will follow), and all the
ones that try to follow the "show how it was written" rule often give
errors that are, for all practical purposes, unusable. If you make
GCC work like the others, it will be a leap backwards and a terrible
disservice to users.
If you choose to show an argument that happens to match the default
but was in fact supplied explicitly, I have no real objection. Just
show it in its simplified normal form and do not try to show "what was
written."
If you never really meant to go in the direction I fear, I just ask
that you try find a way to describe what you want that can't be
misinterpreted the way I did. Someone might go off and do the wrong
thing anyway unless it is expressed clearly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-26
12:57 ---
Subject: Re: Do not print default template arguments in error messages
"gdr at integrable-solutions dot net" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From gdr at integrable-solutions dot net
> 2005-03-26 04:13 ---
> Subject: Re: Do not print default template arguments in error messages
>
> "dave at boost-consulting dot com" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Please, I'm begging you not to go down this road. GCC is one of the
>
> I know you have strong opinions on what compilers should print; we had
> part of this discussions on -core and it did not seem like that was a
> universal solution that handles all the cases.
First, I don't know if I've misunderstood what you meant by "show how
it was written," so I'd really appreciate if you'd clarify that before
we go any further down this road. To make it easy on you, let me try
to be very clear about what I fear. If you run this through the
Comeau on-line compiler:
template
struct foo1
{
// ...
typedef T* pointer;
};
template
struct foo2
{
// ...
typedef T** pointer; // oops, should've been T*
};
template
struct bar
{
bar( V v )
{
U u = v;
}
};
template
struct baz
{
baz()
{
bar<
typename foo1::pointer,
typename foo2::pointer
> b(0);
};
};
baz x;
You'll get a message that says:
line 20: error: a value of type "foo2::pointer" cannot be
used to initialize an entity of type "foo1::pointer"
U u = v;
^
detected during:
instantiation of "bar::bar(V) [with U=foo1::pointer,
V=foo2::pointer]" at line 32
instantiation of "baz::baz() [with U=int, V=int]" at line 36
It is the appearance of "foo1::pointer" and "foo2::pointer"
in the error message, rather than "int*" and "int**", that I'm
concerned about. Nothing in the error message points at
the definition of foo1 or foo2 above, so the user gets no help in
understanding which one might be the true cause of the error. And
even if it pointed at foo1 or foo2, in general the real source of
foo2::pointer could easily have been some other template:
template
struct foo1
{
typedef typename foobar::value_type* pointer;
};
This happens very typically in the standard library, where nested
types are transferred and modified from allocators into containers and
so forth. I want to be sure that GCC continues to show "int*"
and "int**" in these cases.
> I'm going to scheme that handle the majority of the cases right.
Assuming your intention is to do what I fear (otherwise, please ignore
the rest):
On what basis can you say that? Have you got some measurement of what
the majority of cases look like, and an objective way to understand
what "right" is?
No solution universally handles all the cases perfectly, but we can
make some objective analysis of how tractable it is to find any given
piece of important information in the various schemes. Going down the
EDG path may make a few kinds of analysis incrementally easier, but it
makes other kinds vastly harder, to the point of being nearly
impossible. I keep a copy of GCC on hand at all times just for
situations like this, no mater what compiler I'm using. I find it
ironic that if GCC makes the change I fear, the only compiler left
that yields workable error messages in these kinds of situations will
be from Microsoft.
> | only compilers that gets it right today (VC8 will follow), and all
> | the ones that try to follow the "show how it was written" rule
> | often give errors that are, for all practical purposes, unusable.
> | If you make GCC work like the others, it will be a leap backwards
> | and a terrible disservice to users.
>
> yes, you're entitled to your opinions.
This is very disappointing. Condescencion is entirely uncalled for.
I won't claim to know what your level of expertise is, but I know I've
done more comparative research on template-related error messages than
most people. If you care about GCC's usability you ought at least to
take what I say seriously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-26 16:14 --- This is obviously becoming personal. I wanted a record of my technical concerns in the bug database, but as the tone has changed I don't think it's appropriate to continue this here. I will reply to Gaby offline and try to clear up the misunderstandings there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-27
01:52 ---
This is obviously becoming personal. I wanted a record of my technical concerns
in the bug database, but as the tone has changed I don't think it's appropriate
to continue this here. I will reply to Gaby offline and try to clear up the
misunderstandings there.
--
What|Removed |Added
CC|dave at boost-consulting dot|
|com |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/25185] deep typedef substitution in error message
--- Comment #2 from dave at boost-consulting dot com 2008-11-06 19:59 --- This is really a serious problem! For example, consider this error message I got today. If you look carefully, you can see the fundamental problem is that two unsigned int lvalues are being passed to this function call operator. So naturally I'm wondering what types I'm allowed to pass there. However, the parameter types to the function are shown as const boost::property_traits::key_type &, and const boost ::property_traits< boost::vec_adj_list_vertex_property_map< boost::adjacency_list< boost::listS, boost::vecS, boost::directedS, boost ::property< boost::vertex_name_t, unsigned int, boost::property< boost::vertex_rank_t, int, boost::no_property> >, boost::property< boost::edge_locally_owned_t, bool, boost::property< boost::edge_target_processor_id_t, int, boost ::property< boost::edge_weight_t, double, boost ::no_property> > >, boost::no_property, boost ::listS>, boost::adjacency_list< boost::listS, boost::vecS, boost::directedS, boost ::property< boost::vertex_name_t, unsigned int, boost::property< boost::vertex_rank_t, int, boost::no_property> >, boost::property< boost::edge_locally_owned_t, bool, boost::property< boost::edge_target_processor_id_t, int, boost ::property< boost::edge_weight_t, double, boost ::no_property> > >, boost::no_property, boost ::listS> *, unsigned int, unsigned int &, boost ::vertex_name_t> >::value_type & !! Naturally, this message is useless for debugging my problem. I don't know when things changed; GCC never used to do this deep typedef substitution, which made it my favorite compiler for template programming. *** Please, Please, Please *** restore the old behavior. ../../../../boost/parallel/detail/ghost_store.hpp:349: error: no match for call to ( const boost::parallel::distributed_property_map< boost::parallel::mpi::bsp_process_group, boost::detail::parallel ::global_descriptor_property_map, boost ::vec_adj_list_vertex_property_map< boost::adjacency_list< boost::listS, boost::vecS, boost::directedS, boost ::property< boost::vertex_name_t, unsigned int, boost::property< boost::vertex_rank_t, int, boost::no_property> >, boost::property< boost::edge_locally_owned_t, bool, boost::property< boost::edge_target_processor_id_t, int, boost ::property< boost::edge_weight_t, double, boost ::no_property> > >, boost::no_property, boost ::listS>, boost::adjacency_list< boost::listS, boost::vecS, boost::directedS, boost ::property< boost::vertex_name_t, unsigned int, boost::property< boost::vertex_rank_t, int, boost::no_property> >, boost::property< boost::edge_locally_owned_t, bool, boost::property< boost::edge_target_processor_id_t, int, boost ::property< boost::edge_weight_t, double, boost ::no_property> > >, boost::no_property, boost ::listS> *, unsigned int, unsigned int &, boost ::vertex_name_t> >::assimilate_from_reduce< boost::property_reduce::apply>) (unsigned int &, unsigned int &) ../../../../boost/parallel/distributed_property_map.hpp:395: candidates are: void boost::parallel::distributed_property_map< boost::parallel::mpi::bsp_process_group, boost::detail::parallel ::global_descriptor_property_map, boost ::vec_adj_list_vertex_property_map< boost::adjacency_list< boost::listS, boost::vecS, boost::directedS, boost::property< boost::vertex_name_t, unsigned int, boost::property< boost::
[Bug c++/25185] deep typedef substitution in error message
--- Comment #5 from dave at boost-consulting dot com 2009-03-02 16:39 --- Why do you think I want to see the typedef name when I've explicitly asked for the opposite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #9 from dave at boost-consulting dot com 2009-03-02 20:24 --- Hi Jason, Please assume I know what I'm asking for and stop turning it into a different problem. Go back and look at the original report more closely, particularly the part that discusses boost::result_of::type. And lastly, I don't know GCC internals, so I'm unable to interpret the result of your proposed fix (of a problem I'm not having). Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/21682] Disallowed using declaration
--- Comment #5 from dave at boost-consulting dot com 2009-03-03 21:11 --- I don't know that SFINAE has anything to do with this. Looks like I was just doing namespace composition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug c++/25185] deep typedef substitution in error message
--- Comment #16 from dave at boost-consulting dot com 2009-04-03 19:38 --- (In reply to comment #13) > GCC will now say > > ../../../../boost/sequence/make_range.hpp:60: instantiated from > boost::sequence::detail::range_maker::type > boost::sequence::detail::range_maker CalcSize>::operator()(const L&, const B&, const E&, const C&) const [with L = > boost::sequence::intrinsic::iterator_range_operations, > boost::range_iterator > >::elements::type, B = char*, > E > = char*, C = boost::sequence::detail::size_difference, > const boost::array >, Elements = > boost::sequence::identity_property_map, Begin = char*, End = char*, CalcSize = > boost::sequence::detail::size_difference, > boost::array >, typename boost::result_of::type = > boost::detail::get_result_of 11u>, boost::array >, > boost::sequence::detail::size_difference, > boost::array >(), true>::type] > > note the last piece, > > typename boost::result_of::type = > boost::detail::get_result_of 11u>, boost::array >, > boost::sequence::detail::size_difference, > boost::array >(), true>::type Hi Jason, I'm afraid that's not an improvement. It remains just as opaque as ever. Basically, I never want to see a type name ending with >::identifier in error messages, or at least, I want a version where the canonical type name is spelled out. -- dave at boost-consulting dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #29 from dave at boost-consulting dot com 2009-04-08 19:49 --- Although I really appreciate the fix, I really don't like the name of the option. "Pretty" templates means something much more like the formatting I used in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185#c2 I can't see why you wouldn't use -fno-deep-typedef-substitution. I'm not attached to that term, but at least it has an accepted meaning in some circles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #31 from dave at boost-consulting dot com 2009-04-09 13:58 --- OK, I don't get what it's controlling then, but maybe that's not important. Still, I suggest you choose a more specific name to leave the door open for "prettier" template printing in the future. If you did introduce indenting or other prettification that wasn't controlled by this option, it would be confusing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug libstdc++/32017] New: Exception-safety bug
list::insert(pos, start, finish) doesn't provide the strong guarantee as required by 23.2.3.3 list modifiers See http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/b215edcb44b19bb9/c875353acb4da29e It's almost a sure bet that libstdc++ contains other exception-safety bugs. I suggest you adapt and adopt the test mentioned here: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/1ff1165766b913f5/92dcc2c639b9ce39 and here: http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/5272e2a3501ad534/3c80688532fcf240 -- Summary: Exception-safety bug Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug libstdc++/32017] Exception-safety bug
--- Comment #2 from dave at boost-consulting dot com 2007-05-21 14:25 --- I won't push the subject any further, but again, if you don't adopt the tests mentioned in the threads cited above, you will almost certainly have further exception safety bugs lurking. Howard Hinnant can verify that this test works as he used it to validate the MSL. -- dave at boost-consulting dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32017
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #5 from dave at boost-consulting dot com 2007-05-21 17:16 --- Just "adding a throwing allocator" (especially one that throws randomly like this one) will not test the library guarantees anywhere nearly as effectively as the STLPort tests do. The technique is outlined in http://www.boost.org/more/generic_exception_safety.html Use this technique. In fact, if you can, use my code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug libstdc++/21772] exception safety testing allocator
--- Comment #7 from dave at boost-consulting dot com 2007-05-27 23:07 --- (In reply to comment #6) > (In reply to comment #5) > > Use this technique. In fact, if you can, use my code. > > In fact, Howard already mentioned that, at some point. To be clear, and avoid > misunderstandings, I want to clearly state that I consider your offer very > kind. Thanks. However, the normal way to manage that would be you filing a > copyright assignment and the contributing the code, with full acknowledgment > of > your help. I'm not sure we can "speed-up" the procedure much... OK, please send me a private email pointing to how to file such an assignment. Note also that the code may have been modified by others and IIRC it doesn't exactly test the current standard guarantees, so it will need to be worked over. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug c++/17365] [DR 218] Should ADL find non-functions?
--- Comment #10 from dave at boost-consulting dot com 2008-07-20 19:15 --- Since the issue in question is now a DR, can this bug be re-activated? http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#218 Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
[Bug c++/36883] New: Overeager ADL again
If I understand correctly, the following should not compile, because normal
lookup is supposed to look backwards from the calling template's
point-of-definition. There's nothing to make foo an associated namespace of
boo::X.
namespace boo
{
struct X {};
}
namespace foo
{
template
void bar( T x )
{
baz(x); // <== should fail here
}
void baz(boo::X) {}
}
int main()
{
foo::bar( boo::X() );
}
--
Summary: Overeager ADL again
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave at boost-consulting dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36883
[Bug c++/26904] New: A template named the same as its member confuses lookup through inheritance
The enclosed demonstrates. define either SUPPRESS_BUG or SUPPRESS_BUG2 to show that either not using inheritance or using a template called typer instead of type will suppress the bug. -- Summary: A template named the same as its member confuses lookup through inheritance Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
[Bug c++/26904] A template named the same as its member confuses lookup through inheritance
--- Comment #1 from dave at boost-consulting dot com 2006-03-28 15:16 --- Created an attachment (id=11136) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11136&action=view) Preprocessed C++ source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
[Bug web/21679] New: Download > Releases doesn't take me to appropriate info
If I wanted to download a GCC release, I'd follow the link under Download
labelled "releases," but that link doesn't lead to any information about how to
download a release or any links that lead to releases.
--
Summary: Download > Releases doesn't take me to appropriate info
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave at boost-consulting dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug web/21679] Download > Releases doesn't take me to appropriate info
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 15:38 --- Subject: Re: Download > Releases doesn't take me to appropriate info "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: > --- Additional Comments From pcarlini at suse dot de 2005-05-20 15:20 > --- > Hi Dave: I think you have point. What I find misleading is so much space > devoted > to GCC Timeline - in the Download page - and only one line (on top, ok...) > redirecting to the list of mirrors (actually holding the files). Moving the > historical elsewhere and having the list of mirrors right here would be > better, > I guess?!? Or something similar. I don't know, but I completely missed the list of mirrors. What I see is a list of releases, and I naturally try to click on the release I'm interested in so I can download it... doesn't work out too well. Also there's nothing telling me how to navigate the mirrors and find the release I'm interested in. Yes, I've figured it out, but what about Joe average? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug c++/21681] New: Internal Compiler Error
Compile the enclosed source for an ICE -- Summary: Internal Compiler Error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21681] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 17:08 --- Created an attachment (id=8938) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8938&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21682] New: Disallowed using declaration
GCC reports ../../../../boost/sequence/begin.hpp:53: error: 'begin' is already declared in this scope When creating an overload set by bringing a function into a namespace via using-declaration. Compile the enclosed source to demonstrate. -- Summary: Disallowed using declaration Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug c++/21682] Disallowed using declaration
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 17:13 --- Created an attachment (id=8939) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8939&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug c++/21681] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 18:05 --- (In reply to comment #2) > This code is invalid. How did you come to that determination? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20 19:56 --- The code is definitely invalid; I was just wondering how you decided that so quickly ;-) It still should never cause an ICE, of course ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
23:12 ---
Subject: Re: [4.0/4.1 Regression] Internal Compiler Error
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
> 19:59 ---
> (In reply to comment #5)
>> The code is definitely invalid; I was just wondering how you decided that so
>> quickly ;-)
>
> I looked into the source and found where it crashing. It was obvious from
> where the crash was it was
> invalid code as there was a function call as a template argument.
That wasn't a function call; it was a function type.
template struct x {};
x legal;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug web/21679] Download > Releases doesn't take me to appropriate info
--- Additional Comments From dave at boost-consulting dot com 2005-05-22 03:11 --- Subject: Re: Download > Releases doesn't take me to appropriate info "gerald at pfeifer dot com" <[EMAIL PROTECTED]> writes: > --- Additional Comments From gerald at pfeifer dot com 2005-05-21 23:24 > --- > I installed a patch which makes "Download" a section of its own on the > "Releases" page and directly link to that section from the navigation bar. > > (This will take up to 24 hours to become active on the production server.) > > If this is not sufficient, we could consider creating a download page of > its own, though this would add yet another level of indirection in many > cases. > > Having a selectable list of releases which lead to a download site for > that *particular* release seems beyond what we can do with acceptable > effort. We'd have to do quite some scripting and regularily check every > mirror site for every release, but not all mirrors are reachable from > everywhere and always. I'm not advocating that, neccessarily. However, when a table of linked release names dominates the downloads page and *doesn't* lead to downloadable releases, then there's a major usability problem. It might be enough to eliminate or de-emphasize the table. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
