||googlemail dot com
--- Comment #4 from Johannes Schaub
2010-12-27 11:24:36 UTC ---
Same problem happens with
int m;
int(m), m++;
I think GCC is wrong rejecting this.
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
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080
--- Comment #1 from Johannes Schaub
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 A {
explicit operator int();
operator E();
};
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
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #2 from Johannes Schaub
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’
>
> 4.5 accepts it without error
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
--- Comment #4 from Johannes Schaub
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 that accepted it, but curren
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
Stat
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: unass
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 changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #2 from Johannes Schaub
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 8.5.16p6.
>
I'm sorry. I meant 8.
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=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
Johannes Schaub changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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=36587
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
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: UNCONF
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: UNCONFIR
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=47436
--- Comment #4 from Johannes Schaub
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:
>
> "error: every valid template specia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
--- Comment #6 from Johannes Schaub
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 to adding a warning - but I'm not sure to
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #10 from Johannes Schaub
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, wanna chime in here. It has no implicat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #11 from Johannes Schaub
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 it's easy, I'm sure)
>
...
> P
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
2011-10-30 13:54:21 UTC ---
Someone notified me that you can substantially reduce this to the following
template
struct Base {
operator int();
};
template
struct Derived : Base {
using Base::operator int;
||googlemail dot com
--- Comment #2 from Johannes Schaub
2012-05-24 07:51:09 UTC ---
Daniel, nice to meet you again :)
See my SO answer and Richard's opinion at
http://stackoverflow.com/a/10727719/34509 .
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
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=54165
Bug #: 54165
Summary: Cast to "void" should not implicitly call conversion
functions
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
||googlemail dot com
--- Comment #13 from Johannes Schaub
2012-04-01 14:03:40 UTC ---
Jason, does http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1435
not render the explicit specialization ill-formed for C++11TC1? It only allows
a simple identifier, and not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
--- Comment #14 from Johannes Schaub
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 ill-formed for C++11TC1? It only all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
--- Comment #16 from Johannes Schaub
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 currently have
http://www.open-std.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
--- Comment #5 from Johannes Schaub ---
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 efficiently, instead
of simply letting thin
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: UNC
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
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #1 from Johannes Schaub
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=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 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #4 from Johannes Schaub
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 of variables
that result of expansion of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372
--- Comment #5 from Johannes Schaub
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
> > is why 12.2/4 doesn't apply.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
Bug #: 55713
Summary: std::tuple 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
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 received from Stackoverflow (
http:
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: unknow
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
Versi
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 for
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
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);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71377
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
++
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=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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68386
Johannes Schaub changed:
What|Removed |Added
CC||schaub.johannes@googlemail.
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=48814
Summary: Incorrect scalar increment result
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #2 from Johannes Schaub
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 before entering a function, and befor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #5 from Johannes Schaub
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, the operation of postfix ++ is a
> single e
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
2011-05-06 23:47:33 UTC ---
(In reply to comment #0)
> […] As a perhaps related issue, the following looks well-formed:
>
> template
> void f(typename T::B) { }
>
> template
> void f(struct T:
||googlemail dot com
--- Comment #1 from Johannes Schaub
2011-05-08 21:22:20 UTC ---
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 are zero initialized.
It says that the default constructor is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
--- Comment #2 from Johannes Schaub
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 are zero initialized.
>
Let me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
--- Comment #3 from Johannes Schaub
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.
> > The Standard says that members of C a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48930
--- Comment #5 from Johannes Schaub
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-initialized, which would want
to cal
||googlemail dot com
--- Comment #1 from Johannes Schaub
2011-05-10 14:49:18 UTC ---
(In reply to comment #0)
> gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
> the line marked with #:
>
> //---
> struct B {
> friend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #3 from Johannes Schaub
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
> the developer group before submitting a corres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #4 from Johannes Schaub
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 with #:
>
> //---
> struct B {
> friend constexpr int f(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #5 from Johannes Schaub
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 marked with #:
> >
> > //---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48948
--- Comment #6 from Johannes Schaub
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 marked with #:
> >
> > //---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #3 from Johannes Schaub
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
int a({0});
// invalid
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
--- Comment #4 from Johannes Schaub
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:
> > > >
> > > > struct A {
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=49051
--- Comment #2 from Johannes Schaub
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 there is no substitution into an array type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #3 from Johannes Schaub
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 time (8.3.5/6), so there is no subs
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: unassi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49102
--- Comment #1 from Johannes Schaub
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 to rvalue conversion
>
I'm sorry. I mean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46831
--- Comment #1 from Johannes Schaub
2010-12-07 04:09:25 UTC ---
-
GCC also rejects this valid code:
--
struct A {
template operator short();
template operator long();
};
void f(lon
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
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
--- Comment #2 from Johannes Schaub
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 constructors are banned from being copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
--- Comment #4 from Johannes Schaub
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 and say non-templates only, the sam
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++
AssignedTo:
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=49372
Summary: Temporaries evaluated for arguments of a default
constructors of array elements not destructed properly
(?)
Product: gcc
Version: 4.7.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372
--- Comment #1 from Johannes Schaub
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 wrong in any case.
- GCC4.7 "4.7.0 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205
--- Comment #7 from Johannes Schaub
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 in allowing this. Template constructo
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: unassi
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: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #5 from Johannes Schaub
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 this with core.
A related question, if in t
||googlemail dot com
--- Comment #5 from Johannes Schaub
2011-07-05 16:36:14 UTC ---
(In reply to comment #1)
> Created attachment 24686 [details]
> minimal test case
IMO this is ambiguous. When doing partial ordering, in both cases the 'T'
remains u
||googlemail dot com
--- Comment #2 from Johannes Schaub
2011-07-06 05:27:41 UTC ---
(In reply to comment #1)
> This is correct for C99. inline alone in C99 is the same GNU's C90's extern
> inline.
For an explanation, see
http://stackoverflow.com/q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #5 from Johannes Schaub
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 cond;
> public:
> constexp
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 #7 from Johannes Schaub
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 cannot define/redefine this valu
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.
94 matches
Mail list logo
