[Bug c++/95883] Attributes on lambdas appear to be parsed in the wrong place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95883 Patrick Moran changed: What|Removed |Added CC||patrick.a.moran at gmail dot com --- Comment #3 from Patrick Moran --- My argument in favor of restoring the pre-9-series behavior is that of compiler portability. When you have a lambda with a trailing return type that you want to mark with __attribute__((always_inline)) there's now one syntax that works with GCCs before 9.1 and with clang (who is matching gcc), and another syntax that works with GCCs after 9.3, but not with any GCC before 9.3 or any version of clang. If you want to write code that works with GCC 8.3 and 10.1, or with both GCC 10.1 and any clang, then you have to write macros to move the attributes around. Whereas if the patch in this bug (or another like it), then at least the one existing codebase I'm working on won't have to add a macro layer to be able to support lambdas across our range of supported compilers.
[Bug libstdc++/90454] filesystem::path template constructor void* overload interference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90454 --- Comment #4 from Patrick Moran --- I just did a clean build of gcc with the change linked from ViewVC and confirmed that my reproduction is fixed. Thank you. I admit I'm uncertain of the etiquette regarding this ticket itself - I'm not changing the status yet in case that would mess with release management conventions, but I can confirm that the patch fixes the reported issue. If I should mark as "RESOLVED", I'm happy to do so.
[Bug libstdc++/90454] New: filesystem::path template constructor void* overload interference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90454
Bug ID: 90454
Summary: filesystem::path template constructor void* overload
interference
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 46349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46349=edit
A reproduction of the issue described
I've marked the issue as 8.1.0 because that's the earliest version I've
confirmed it on, but I've seen it on 8.2.0, 8.3.0, 9.1.0, and the version that
godbolt.org was calling "HEAD" on 2019.05.10. I suspect it has been there as
long as has been present.
I attached a short reproduction. The end-user symptom is that if you have two
overloads of a function, one taking std::filesystem::path (or a const reference
thereto) and another taking void* (or a const reference thereto), then you
won't be able to pass a void* to the void*-taking function. You will get
${GCC_INSTALL}/include/c++/9.1.0/bits/stl_iterator_base_types.h: In
instantiation of ‘struct std::iterator_traits’:
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:82:13: required by
substitution of ‘template using
__is_path_iter_src =
std::__and_::type>,
std::is_base_of > [with _Iter = void*; _Iter_traits =
std::iterator_traits]’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:89:7: required by
substitution of ‘template static
std::filesystem::__cxx11::path::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::path::__is_path_src(_Iter, int) [with _Iter = void*]’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:113:31: required from ‘struct
std::filesystem::__cxx11::path::__constructible_from’
${GCC_INSTALL}/include/c++/9.1.0/type_traits:131:12: required from ‘struct
std::__and_ >,
std::filesystem::__cxx11::path::__constructible_from >’
${GCC_INSTALL}/include/c++/9.1.0/type_traits:136:12: required from ‘struct
std::__and_ >,
std::__not_ >,
std::filesystem::__cxx11::path::__constructible_from\
>’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:117:13: required by
substitution of ‘template using _Path = typename
std::enable_if >::type, st\
d::filesystem::__cxx11::path> >, std::__not_ >,
std::filesystem::__cxx11::path::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = void*; _Tp2 = void]’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:190:7: required by
substitution of ‘template
std::filesystem::__cxx11::path::path(const _Source&,
std::filesystem::__cxx11::path::format) [with _Source = void*; _Require = ]’
path_repro.cpp:7:21: required from here
${GCC_INSTALL}/include/c++/9.1.0/bits/stl_iterator_base_types.h:184:43: error:
forming reference to void
184 | typedef _Tp&reference;
| ^
I've traced the issue this far: std::filesystem::path has a predicate
__is_path_iter_src that is used through a chain of dependencies to
conditionally enable constructor #5 from 30.11.7.4.1 - the one taking a
template Source argument. That argument is supposed to be string-like, and
30.11.7.3 2 specifies that the constructor not take part in overload resolution
unless for the Source argument "the qualified-id
iterator_traits>::value_type is valid and denotes a possibly
const encoded character type"
The problem is that actually instantiating std::iterator_traits triggers
that "forming reference to void" error.
Because of this, constructor 5 is not being removed from the set of overloads,
we're encountering a compilation failure while in the process of determining if
it should participate in overload resolution.
The way this relates to the end-user symptom is that this compile-failure will
break the user's build, even though the overload that takes void* would be the
better match.
[Bug c++/90338] New: member function pointer non-type template parameter compile fail while matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90338
Bug ID: 90338
Summary: member function pointer non-type template parameter
compile fail while matching
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 46280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46280=edit
A reproduction of the issue described
The code in question compiled in 8.3.0, but fails in 9.1.0.
We have two template functions that each take one type template parameter and
one non-type template parameter. The first template function's non-type
template parameter is of a member function type, and the second template
function's non-type template parameter is it's type template parameter. (I
think this is clearer in the reproduction).
If you then call the first template function actually giving it a pointer to a
member function that exactly matches, but the class whose member function it is
is non-literal, you get a compile-failure (error below).
> repro.cpp:13:22: error: ‘B’ is not a valid type for a template non-type
> parameter because it is not literal
>13 | match();
> | ^
> repro.cpp:1:8: note: ‘B’ is not literal because:
> 1 | struct B {
> |^
> repro.cpp:1:8: note: ‘B’ is not an aggregate, does not have a trivial
> default constructor, and has no ‘constexpr’ constructor that is not a copy or
> move constructor
It appears that when it considers
template
void match();
as a match, it errors out based on the fact that you _couldn't_ pass your class
type as a non-type template parameter (even though you're making no attempt to
do so). If you make the class trivial so that this error doesn't happen, you
can see that it does choose the correct match().
[Bug c++/90333] New: Can't apply attributes to lambdas with trailing returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
Bug ID: 90333
Summary: Can't apply attributes to lambdas with trailing
returns
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
In 8.3.0 we could do either one of these:
> []() __attribute__((always_inline)) -> int { return 0; }
> []() [[gnu::always_inline]] -> int { return 0; }
I understand that __attribute__ is a GCC extension, but it's my understanding
that the second one is standard behavior.
As of 9.1.0, the __attribute__ variant both fails with "expected '{' before
'->' token", and the [[gnu::always_inline]] variant fails because it's applying
the attribute to the trailing return type rather than the lambda.
I tried every possible position, but each fails
* __attribute__((always_inline)) []() -> int { return 0; }
* [[gnu::always_inline]] []() -> int { return 0; }
* These fail with "attributes at the beginning of statement are ignored"
* IE, it's not actually applying to the lambda.
* [] __attribute__((always_inline)) () -> int { return 0; }
* [] [[gnu::always_inline]] () -> int { return 0; }
* These fail with "expected '{' before '[' token" (or "__attribute__")
* []() __attribute__((always_inline)) -> int { return 0; }
* This fails with "expected '{' before '->' token
* []() [[gnu::always_inline]] -> int { return 0; }
* This fails with "attribute ignored"
* It is applying the attribute as an attribute of the return type
* []() -> __attribute__((always_inline)) int { return 0; }
* []() -> [[gnu::always_inline]] int { return 0; }
* This fails with "attribute does not apply to types"
* It is applying the attribute as an attribute of the return type
* []() -> int [[gnu::always_inline]] { return 0; }
* []() -> int __attribute__((always_inline)) { return 0; }
* This fails with "attribute does not apply to types"
* It is applying the attribute as an attribute of the return type
* []() -> int { return 0; } __attribute__((always_inline))
* Fails with "expected ';' before '__attribute__'"
* []() -> int { return 0; } [[gnu::always_inline]]
* Fails with "two consecutive '[' shall only introduce an attribute before
'[' token
It would appear that in 9.1.0 there's no way to specify attributes for a lambda
that has a trailing return type?
[Bug c++/81757] function reference on nonnull and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81757 Patrick Moran changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Patrick Moran --- I returned to check on this bug and it appears this no longer occurs in either the 7.2.0 release nor in 8.3.0. Closing this since it was fixed.
[Bug sanitizer/89764] New: ubsan diagnostic on generic lambdas decayed to function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89764 Bug ID: 89764 Summary: ubsan diagnostic on generic lambdas decayed to function pointers Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: patrick.a.moran at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45992 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45992=edit The minimal reproduction as a separate file I've observed this on a vanilla built-from-source gcc 8.3.0. You can reproduce by running (with the attached repro.cpp) gcc -fsanitize=undefined repro.cpp -o repro && ./repro You get the error message repro.cpp:2:34: runtime error: member call on null pointer of type 'const struct __lambda0' The error does occur if a generic lambda with an empty capture is used, but the error does not occur if a non-generic lambda with an empty capture is used (ie, if you alter the repro to replace the "auto" with an "int", the error goes away). I know that by 8.1.5.1.6, the produced function point need only have "the same effect as invoking the closure type’s function call operator", so requiring the closure object to still be alive for the free function to be called is probably one of the permitted behaviors, but I was hoping that this was unintentional, particularly since that is true of non-generic lambdas. Being able to use lambdas with empty captures to generate free functions is an ergonomic win for us.
[Bug c++/87506] New: ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506
Bug ID: 87506
Summary: ICE with inherited constexpr constructor with const
argument
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 44777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44777=edit
A reproduction of the issue described
I've attached what I believe is a minimal reproduction. It can be built with
> gcc --std=c++14 -c ice_repro.cpp
* It reproduces with g++ 8.2.0 (I've confirmed it does not occur with 7.3.0)
* It reproduces with a --std= of c++11, c++14, c++17, c++1z and c++2a
* It uses constexpr, so it fails for uninterested reasons below C++11
* No other command-line flags are needed
* And I've not found any that cause the failure not to reproduce.
* I found this on a Linux box (Ubuntu 14.04.1), but the gcc was built from
source and no headers are included in the reproduction.
The failure mode is an internal compiler error (full error message at the
bottom). Changing any of the following will cause the failure not to happen:
* If you drop the constexpr from B::B(A)
* If you change "constexpr B(const A) {}" to "constexpr B(A) {}"
* If you use a built-in type like int as the tag argument instead of the
struct A
* If you change the argument to B::B(A) to be any reference category
The full error message is:
> ice_repro.cpp: In function ‘void func()’:
> ice_repro.cpp:8:24: in ‘constexpr’ expansion of ‘obj.C::C((A{}, A()))’
> ice_repro.cpp:8:24: internal compiler error: in adjust_temp_type, at
> cp/constexpr.c:1255
> void func() { C obj(A{}); }
> ^
> 0x58c00e adjust_temp_type
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1255
> 0x5ee55b cxx_bind_parameters_in_call
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1330
> 0x5ee55b cxx_eval_call_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1602
> 0x5f08c4 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4211
> 0x5ef958 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4337
> 0x5ef958 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4337
> 0x5f01d5 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4689
> 0x5eef24 cxx_eval_call_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:1709
> 0x5f08c4 cxx_eval_constant_expression
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4211
> 0x5f39c9 cxx_eval_outermost_constant_expr
> ../../gcc-8.2.0/gcc/cp/constexpr.c:4861
> 0x5f5ad8 maybe_constant_init_1
> ../../gcc-8.2.0/gcc/cp/constexpr.c:5187
> 0x64105c expand_default_init
> ../../gcc-8.2.0/gcc/cp/init.c:1918
> 0x64105c expand_aggr_init_1
> ../../gcc-8.2.0/gcc/cp/init.c:2021
> 0x64143b build_aggr_init(tree_node*, tree_node*, int, int)
> ../../gcc-8.2.0/gcc/cp/init.c:1761
> 0x60fb07 build_aggr_init_full_exprs
> ../../gcc-8.2.0/gcc/cp/decl.c:6283
> 0x60fb07 check_initializer
> ../../gcc-8.2.0/gcc/cp/decl.c:6432
> 0x61e62b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
> ../../gcc-8.2.0/gcc/cp/decl.c:7145
> 0x697710 cp_parser_init_declarator
> ../../gcc-8.2.0/gcc/cp/parser.c:19749
> 0x69e488 cp_parser_simple_declaration
> ../../gcc-8.2.0/gcc/cp/parser.c:13052
> 0x69f218 cp_parser_block_declaration
> ../../gcc-8.2.0/gcc/cp/parser.c:12871
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/83470] New: Type morphing nested lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83470
Bug ID: 83470
Summary: Type morphing nested lambda capture
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 42908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42908=edit
The minimal reproduction as a separate file
I found this compiling with gcc 7.2.0 with
--std=c++1z -Wall -Wextra
Including my very-minimal repro inline here because I don't know how else to
explain the issue.
--
#include
// This has to be templated, but the argument doesn't need to be
// used for anything
template double& g();
template
int f() {
auto& v = g();
static_assert(std::is_same<decltype(v), T&>::value);
[](auto inner) {
inner(true);
}([&](auto) {
static_assert(std::is_same<decltype(v), bool&>::value);
});
return 0;
}
int dummy = f();
--
As you can see, in this very specific circumstance, the type of v morphs from
double& to bool& in the inner lambda. It isn't that bool is special - whatever
type we pass as the ignored argument to the inner lambda, v will become that
type (lvalue-ref'ed). Changing any of the following will cause the bug to go
away:
* Making f() not a template
* Making g() not a template, or giving g() a template argument that isn't the
template argument to f().
* Changing the declaration of v to explicitly spell out double& rather than
letting auto& deduce it.
* Eliminating the lambda-wrapping. If you directly call the inner lambda, it
won't reproduce.
[Bug c++/81929] New: exponential slowdown in undefined behavior sanitizer for streaming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81929 Bug ID: 81929 Summary: exponential slowdown in undefined behavior sanitizer for streaming Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.a.moran at gmail dot com Target Milestone: --- Created attachment 42028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42028=edit A reproduction of the issue described I've attached a reproduction. The trigger for the behavior we identified is: * To stream a number of ints (or other numeric types) into a std::ostringstream * To call .str() on that std::ostringstream * To do all of the above in a single expression * Build with -fsanitize=undefined It seems that all the above conditions are necessary - the problem vanishes if you: * Split the same logic into multiple logical lines of code * Call some member function other than .str() (like .rdbuf()) * Stream string literals instead of numeric types * Compile without -fsanitize=undefined The behavior we see is a compile-time that seems to grow as roughly 4^n, where n is the number of ints being streamed in. On my box 10 numbers = 0.671s 11 numbers = 1.608s 12 numbers = 5.356s 13 numbers = 20.250s 14 numbers = 80.163s 15 numbers = 318.994s Salient output from perf record / perf report: # Overhead Command Shared Object Symbol # . # 59.95% cc1plus cc1plus[.] walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*)) 23.54% cc1plus cc1plus[.] replace_placeholders_r(tree_node**, int*, void*) 14.87% cc1plus cc1plus[.] cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*) 0.07% cc1plus cc1plus[.] push_to_top_level() 0.06% cc1plus [kernel.kallsyms] [k] clear_page_c_e 0.04% cc1plus cc1plus[.] lookup_name_real(tree_node*, int, int, bool, int, int)
[Bug c++/81757] New: function reference on nonnull and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81757
Bug ID: 81757
Summary: function reference on nonnull and noexcept
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 41948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41948=edit
a minimal reproduction
We have noticed a behavior that we believe to be a bug. It appears in the
recent 7.2 release candidate, and we know for sure that the behavior was not
present in 6.3. It manifests in --std=c++17 or --std=c++1z.
I have attached a minimal reproduction.
g++ --std=c++17 -c repro.cpp
We get a failure to compile with the following message
--
error: invalid initialization of reference of type ‘void (&)(void*) noexcept’
from expression of type ‘void(void*) noexcept’
void do_stuff() { test(foo); }
^
note: in passing argument 1 of ‘void test(TFunction&&) [with TFunction = void
(&)(void*) noexcept]’
void test(TFunction&& function);
--
We encounter the error only if _all_ the following conditions are met:
1. The function passed as an argument takes a pointer-typed argument is forward
declared with __attribute__((nonnull(n))) (With "n" replaced with the 1-based
index of the pointer-typed argument).
2. The function is declared noexcept
3. That function is passed as an argument to another function via forwarding
reference
[Bug c++/61370] decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 --- Comment #4 from Patrick Moran patrick.a.moran at gmail dot com --- This bug does indeed seem to be related to / duplicate of c++/52830. That is, the two bugs reports are referring to the same trigger, but the bug manifests differently in the two versions (in the 4.9.0 I tested, I got this error, in the 4.8.0 it tested they got ICE). When I built c++/52830's test case with 4.9.0, I got this error message. A bit unsure of the ettiquette here - as the original reporter is it appropriate for me to go ahead and mark this ticket dup?
[Bug c++/52830] ICE: canonical types differ for identity types ... when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Patrick Moran patrick.a.moran at gmail dot com changed: What|Removed |Added CC||patrick.a.moran at gmail dot com --- Comment #1 from Patrick Moran patrick.a.moran at gmail dot com --- Created attachment 32992 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32992action=edit Another reproduction Adding my reproducing test case from a duplicate bug I filed before I mark it a duplicate (the failure behavior is different on 4.9.0 than from snapshot, but I've confirmed it's the same issue).
[Bug c++/52830] ICE: canonical types differ for identity types ... when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 --- Comment #2 from Patrick Moran patrick.a.moran at gmail dot com --- *** Bug 61370 has been marked as a duplicate of this bug. ***
[Bug c++/61370] decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 Patrick Moran patrick.a.moran at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Patrick Moran patrick.a.moran at gmail dot com --- Marking this as a duplicate - it is the same problem as c++/52830, it just manifests differently in 4.9.0 than in head. *** This bug has been marked as a duplicate of bug 52830 ***
[Bug c++/61370] New: decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 Bug ID: 61370 Summary: decltype, enable_if, previous arguments Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.a.moran at gmail dot com Created attachment 32878 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32878action=edit minimal reproduction SFINAE that depednds on the decltype of a previous argument fails to funciton in a member function if the definition is external to the class. The out-of-class definition is reported as having a prototype that does not match any in the class. In the attached test case you can see the error. If you define WORKAROUND, you will see the same code with the definition moved into the class and the error will not recur.
[Bug c++/47252] GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47252 --- Comment #5 from Patrick Moran patrick.a.moran at gmail dot com 2011-01-16 15:26:27 UTC --- Created attachment 22985 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22985 (Gzipped) preprocessed source Oops, sorry this was missing earlier. I had apparently missed the note that the upload failed for being too large. Here is a gzipped one that fits.
[Bug c++/47252] GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47252 Patrick Moran patrick.a.moran at gmail dot com changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|FIXED |
[Bug c++/47252] GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47252 --- Comment #3 from Patrick Moran patrick.a.moran at gmail dot com 2011-01-16 04:10:26 UTC --- Confirmed that the code does in fact work with boost 1.42 on gcc 4.6.0. I guess that makes this already fixed.
[Bug c++/47252] GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47252 Patrick Moran patrick.a.moran at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED
[Bug c++/47252] New: GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47252
Summary: GCC Segfaults when boost/range.hpp is included and
deduced parameter is a initializer_list
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.a.mo...@gmail.com
For an unknown reason, gcc-4.5.1 as shipped by Ubuntu 11.04 will segfault when
asked to deduce the template parameter of a templated constructor from an
initializer_list if boost/range.hpp (version 1.40 as shipped by Ubuntu 11.04)
has been previously included. The segfault goes away if the include is
omitted.
An attached file holds the preprocessed input.
The original is below:
--
class Scope
{
public:
templatetypename StateSeq
Scope(StateSeq const );
};
templatetypename StateSeq
Scope::Scope(StateSeq const seq)
{}
#include boost/range.hpp
int main()
{
Scope body({ 3 });
}
