https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920
--- Comment #6 from Johannes Schaub ---
Well then you can replace the class with a nameepace, I think, to remove the
class-scope complication. I think GCC would still incorrectly apply typename
lookup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71425
--- Comment #1 from Johannes Schaub ---
(This bug report is due to
https://stackoverflow.com/questions/37645347/clang-does-not-infer-template-argument-in-variadic-template-function-with-vararg)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: schaub.johannes at googlemail dot com
Target Milestone: ---
The following testcase should fail to compile because Args is not deduced
(stays empty), but surprisingly, GCC accept it
#include
template
T method(std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71377
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71007
--- Comment #1 from Johannes Schaub ---
Sorry, forgot to actually add the code of the reduced testcase:
template
void f(char(&)[N])
{ }
int main() {
char x[1];
f(x);
}
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schaub.johannes at googlemail dot com
Target Milestone: ---
The following is supposed to tell the user that char[0] is an invalid type,
dur
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schaub.johannes at googlemail dot com
Target Milestone: ---
The following fails to compile. This is a big show-stopper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68386
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com ---
We also have this bug and it took us several days to find the cause. Testcase
by my colleague attached.
Perhaps this should fire an assertion if it is hard to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56190
Bug #: 56190
Summary: GCC fails deducing a void(*)(int, float, double) to
a void(*)(T..., float, double) with T={int}
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55809
Bug #: 55809
Summary: Doesn't differentiate elaborated type specifier and
typename specifier in dependent types
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
Bug #: 55713
Summary: std::tupleElementType incorrectly is convertible to
ElementType when it is an empty class
Classification: Unclassified
Product: gcc
Version: 4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2012-12-16 17:52:14 UTC ---
(In reply to comment #1)
This was done for an optimization. And I think it is allowed by the C++
standard too.
From the feedback I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2012-12-10 16:42:59 UTC ---
(In reply to comment #4)
(In reply to comment #3)
Kai, I don't think anyone disputes that B's constructor is called, the
question
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2012-11-18 21:29:15 UTC ---
(In reply to comment #3)
Is this a duplicate of Bug 41933 ?
This looks like a different one. I am not trying to capture a list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54165
Bug #: 54165
Summary: Cast to void should not implicitly call conversion
functions
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Bug #: 53499
Summary: Incorrect partial ordering result with member vs
non-member
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2012-05-27 14:00:20 UTC ---
Sorry, GCC picks the same function (non-member) disregarding of the C++
Standards mode. The comments were a left-over from a clang bug report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53464
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
--- Comment #16 from Johannes Schaub schaub.johannes at googlemail dot com
2012-04-02 07:43:23 UTC ---
(In reply to comment #15)
(In reply to comment #14)
Good point, I've pointed out the problem with the proposed resolution.
Note that we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
--- Comment #14 from Johannes Schaub schaub.johannes at googlemail dot com
2012-04-01 14:14:46 UTC ---
(In reply to comment #13)
Jason, does http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1435
not render the explicit specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51805
Bug #: 51805
Summary: Invalid list-initialization accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51805
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2012-01-08 11:41:18 UTC ---
I asked the committee at that time, and they reinforced that this is intended
to work as specified in the C++11 spec.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51789
Bug #: 51789
Summary: GCC does not consider SFINAE in template parameter
list of template parameter pack
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51689
Bug #: 51689
Summary: GCC apparently is inconsistent with warning about
invalid brace-elision use
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50921
Bug #: 50921
Summary: GCC cannot find dependent conversion-function-id even
if there's a using declaration for it
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50921
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2011-10-30 13:54:21 UTC ---
Someone notified me that you can substantially reduce this to the following
templatetypename T
struct Base {
operator int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #10 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-29 06:10:26 UTC ---
(In reply to comment #9)
Excellent, then could you possibly comment on the implication for this PR?
(for
you it's easy, I'm sure)
Hi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #11 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-29 06:14:32 UTC ---
(In reply to comment #10)
(In reply to comment #9)
Excellent, then could you possibly comment on the implication for this PR?
(for
you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
--- Comment #6 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-25 14:22:33 UTC ---
(In reply to comment #5)
Johannes, sorry about the dumb question: now I understand the issue decently
well - and after all boils down
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-22 19:01:51 UTC ---
(In reply to comment #3)
(In reply to comment #2)
Suggestions about a better error message? (should be easy to change)
What about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50445
Bug #: 50445
Summary: Rejects use of constant expression using a pointer
non-type template parameter
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50387
Bug #: 50387
Summary: Doesn't process _Pragma when expanding a token
sequence for #include
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169
Bug #: 50169
Summary: new struct X {{}}; incorrectly treated as an invalid
struct-definition
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #7 from Johannes Schaub schaub.johannes at googlemail dot com
2011-08-03 19:17:04 UTC ---
(In reply to comment #6)
You can define it as follows to make it work in both cases
#define PTHREAD_COND_INITIALIZER {}
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49928
Summary: Only workaround for -Wundef is defined(Macro)
Macro, but it is undefined behavior?
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2011-07-29 12:23:35 UTC ---
(In reply to comment #4)
struct A { int a[2]; A():a({1, 2}) { } };
Should be valid. Example:
class cond_variable
{
::pthread_cond_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49637
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2011-06-26 13:40:34 UTC ---
(In reply to comment #4)
Hmm, the example in 14.8.2p8 does seem to contradict my interpretation of the
normative wording. I'll raise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49531
Summary: Doesn't resolve to conversion function template
specialization in expressions
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49514
Summary: Crashes on valid use of constexpr constructor
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
--- Comment #7 from Johannes Schaub schaub.johannes at googlemail dot com
2011-06-20 15:56:42 UTC ---
(In reply to comment #6)
(In reply to comment #1)
While this behavior is erroneous, consensus at clang was that WG21 made an
oversight
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372
Summary: Temporaries evaluated for arguments of a default
constructors of array elements not destructed properly
(?)
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2011-06-11 13:46:46 UTC ---
To elaborate on it, I have the following weird behavior:
- GCC4.6 outputs nothing for the program (on my linux machine). That seems
definitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49267
Summary: Ambiguity with conversion functions T and T,
initializing a T
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49224
Summary: Scoped enumeration instantiated even if not required
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
Summary: Default constructor with pack expansion parameter not
detected
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-28 01:45:29 UTC ---
(In reply to comment #1)
While this behavior is erroneous, consensus at clang was that WG21 made an
oversight in allowing this. Template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-28 02:06:07 UTC ---
(In reply to comment #3)
I would expect that the initialization text would be amended appropriately. I
think that we should go for consistency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49102
Summary: Use of deleted copy constructor not diagnosed
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49102
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-21 20:04:16 UTC ---
(In reply to comment #0)
The following program should be diagnosed at the call to f for using a
deleted copy constructor in an lvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-19 16:26:30 UTC ---
(In reply to comment #1)
I disagree. The transformation of array to pointer is done immediately at
declaration time (8.3.5/6), so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #3 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-19 16:56:07 UTC ---
(In reply to comment #2)
(In reply to comment #1)
I disagree. The transformation of array to pointer is done immediately at
declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
Summary: Doesn't SFINAE away an invalid substitution into
toplevel parameter type T[N]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-14 16:18:58 UTC ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
(In reply to comment #0)
Fails to compile, but should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #3 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-12 05:23:15 UTC ---
I think we have the FDIS clear about these cases now. To update:
// invalid
struct A { int a[2]; A():a({1, 2}) { } };
// invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #3 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 16:46:18 UTC ---
(In reply to comment #2)
(In reply to comment #1)
I don't think that this is intended, but I would like to await feedback from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 16:59:50 UTC ---
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
the line marked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 17:07:30 UTC ---
(In reply to comment #4)
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code
at
the line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #6 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-10 17:20:31 UTC ---
(In reply to comment #4)
(In reply to comment #0)
gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code
at
the line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-09 10:55:06 UTC ---
(In reply to comment #4)
Indeed, C has no user-provided constructors, so it is an aggregate.
Jason, what about c1? It seems that it is default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-08 21:47:01 UTC ---
(In reply to comment #1)
I think it can be argued that this is a bug in the Standard rather than in
GCC.
The Standard says that members of C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
--- Comment #3 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-08 22:02:29 UTC ---
(In reply to comment #2)
(In reply to comment #1)
I think it can be argued that this is a bug in the Standard rather than in
GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920
Summary: typename specifier should not ignore non-type names
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48920
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-06 23:47:33 UTC ---
(In reply to comment #0)
[…] As a perhaps related issue, the following looks well-formed:
templatetypename T
void f(typename T::B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
Summary: Incorrect scalar increment result
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-04-29 10:42:12 UTC ---
Since the order of evaluation is undefined it may evaluate count++ and
incr() in any order, as it pleases.
Since there is a sequence point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com
2011-04-29 16:20:44 UTC ---
(In reply to comment #4)
I think the relevant wording in the C1X DIS is With respect to an
indeterminately-sequenced function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
Summary: Prematurely destroys initializer_list array when using
new-expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47828
Summary: GCC instantiates function template with auto type
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47604
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47651
Summary: new (T(*[1])) is parsed as a functional-cast getting
a lambda-expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47604
Summary: GCC doesn't accept auto *f() - int, but only
accepts auto f() - int.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436
Summary: Variadic base-specifier-list of union rejected
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Summary: Various non-conforming behaviors with braced-init-list
initialization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-01-25 03:37:01 UTC ---
(In reply to comment #0)
In short, the intent seems to be that a ({ ... }) initializer is only
allowed
for class types, where it will hit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
Summary: GCC doesn't expand template parameter pack that
appears in a lambda-expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47227
Summary: GCC ignores conversion function template
specializatons if a derived class' conversion function
converts to the same type
Product: gcc
Version: 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com
2011-01-01 18:11:27 UTC ---
(In reply to comment #1)
4.4 rejects it:
inv.cc:1: error: expected class-name before ‘int’
inv.cc:1: error: expected ‘(’ before ‘int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-01-01 18:41:53 UTC ---
(In reply to comment #3)
(In reply to comment #2)
what 4.6.0 version are you using?
Hmm, 4.6.0 20101113 (experimental).
Ah, maybe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
Summary: Doesn't reject attempt to define type in template
argument; results in weird parse
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080
Summary: explicit conversion function return conversions not
restricted to qualifications
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2010-12-28 19:10:25 UTC ---
It should be noted that this can yield to ambiguities in combination with other
conversion functions. Consider
enum E { };
struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
Johannes Schaub schaub.johannes at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46831
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2010-12-07 04:09:25 UTC ---
-
GCC also rejects this valid code:
--
struct A {
templatetypename T = void operator
94 matches
Mail list logo
