http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
onent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
gcc 4.9.0 20130519 (experimental) compiled with the flags
-std=c++11 -Wall -pedantic-errors
rejects the following code:
//
int get_int();
#d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57480
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57480
--- Comment #3 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
My interprettaion is that the standard does not say anything about that (I
think I had once a similar question in regard to another type from the C
Library). I su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484
--- Comment #1 from Daniel Krügler ---
I haven't checked your bit arithmetics, but I have checked the full bit
patterns of the resulting NaNs in hex on my mingw-64 bit system. What I'm
getting for are the following results:
1) gcc 4.7.2/4.9.0 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484
--- Comment #4 from Daniel Krügler ---
(In reply to Charles L. Wilcox from comment #3)
> Signaling NaN for type "f" in hex is "7fe0".
I agree, this one doesn't look right to me, because that looks indeed like a
valid qNaN bit pattern only.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57502
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57504
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57505
--- Comment #2 from Daniel Krügler ---
This is fixed in gcc 4.9 trunk and I believe it has already been fixed in gcc
4.8 due to bug #50043.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57570
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57575
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588
--- Comment #5 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
> Although shouldn't it fail to compile, due to private destructor and copy
> constructor?
I agree, it should fail. Interesting is, that the code compiles even w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57595
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57626
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #3 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
> It does for G++, it's been accepted as an extension in C++03 mode for years.
What I actually meant to say with my comment is that for a proper bug report
the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57764
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #7 from Daniel Krügler ---
(In reply to Andy Lutomirski from comment #4)
> Daniel, I'm unconvinced that your interpretation is the intended one.
Well, [temp.spec] p5 says more strongly that an explicit instantiation shall
only follow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #28 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #27)
Yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #4 from Daniel Krügler ---
(In reply to Tomasz Kamiński from comment #2)
> Propably this is also causing the problem with the standard library
> is_function and is_member function traits, because they cannot be
> implemented correclty.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #5 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #3)
> Daniel, which library testcases did we commit?!? ;) Crazy.
During an intermediate state we had bug 57388 which prevented for some time the
proper specialization
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
gcc 4.9.0 20130616 (experimental) diagnoses a warning for the following code
compiled with the flags:
-Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57888
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
The following observations where originally found by testing the
std::is_trivial trait from , but the actual problem see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #3 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #2)
> I suppose a minimal reproducer could involve a file scope static of some
> sort...
I'm a bit confused by your reply, Paolo: Isn't my_cout also a "file scope
sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #6 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #5)
> Ah, in case isn't obvious already: it only happens when the "I/O expression"
> has the ! operator in front.
I suspected that and ensured that I added a similar o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #8 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #7)
> But it happens with -O0 too, right?
Yes.
> In any case we badly need a reduced testcase ;)
I agree. Unfortunately I'm on vacations from tomorrow on (1 week), s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58083
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58181
--- Comment #3 from Daniel Krügler ---
My understanding is that the presented program has undefined behaviour and that
its assertion may fail or may not. The reason being that the outer lambda
expression has return type std::tuple (where LI stands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58184
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191
--- Comment #3 from Daniel Krügler ---
First, this issue should be categorized as belonging to the component
"libstdc++", not to "c++".
Second, the defect report is invalid, because std::upper_bound requires a
minimum iterator category of "forwar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191
--- Comment #5 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #2)
> Francois, did we change anything in the library for 4.8.x?
I think that Francois added more iterator concept checking and this one looks
correct. Unfortunately I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
--- Comment #3 from Daniel Krügler ---
This is just a polite reminder for some response. I'm especially interested to
hear whether there exist any reasonable doubts on the validity of the arguments
brought forward. IMO it is important to fix at, b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352
--- Comment #3 from Daniel Krügler ---
(In reply to 1zeeky from comment #2)
> I am aware that the code is invalid; I'm not saying there shouldn't be an
> error.
Then I was mislead by your comment: "I'm not 100% sure the attached testcase
*should*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58352
--- Comment #4 from Daniel Krügler ---
Maybe related to bug 16564?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58353
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #9 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #8)
> About the duplication, you may want to review what Francois posted to the
> mailing list a few days ago and send your comments. Personally, I agree it
> would be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50157
Bug #: 50157
Summary: [C++0x] Non-silent SFINAE in new expression with
explicit conversion
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRME
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-08-22 22:26:07 UTC ---
Based on the FDIS wording (14.6 p. 8) this example should be ill-formed. But
maybe the diagnostic could be improved?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50209
Bug #: 50209
Summary: [C++0x] Braced-init-lists are rejected as function
default arguments
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRME
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-08-30 06:33:44 UTC ---
Seems to be fixed in 4.7.0 (Tested with 4.7.0 20110820 (experimental))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
--- Comment #3 from Daniel Krügler
2011-08-30 09:30:48 UTC ---
(In reply to comment #2)
> Good. 4_6-branch behaves the same. Do we agree that GCC is correct in
> rejecting
> this (without ICE-ing of course)?
I think that gcc is right rejecting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #2 from Daniel Krügler
2011-08-30 09:39:43 UTC ---
I believe I found a conforming usage of reinterpret_cast in constant
expressions useable in C++03:
//
struct X {
X* operator&();
};
X x[2];
const bool p = (reinter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
--- Comment #5 from Daniel Krügler
2011-08-30 09:52:19 UTC ---
I just notice that the current exclusion of reinterpret_cast in constant
expressions would make it impossible to define addressof as a constexpr
function. C++11 currently invalidates
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-09-05 06:38:19 UTC ---
It seems that this problem had been fixed now. The example code successfully
compiles with gcc 4.7.0 20110903 (experimental).
||googlemail dot com
--- Comment #4 from Daniel Krügler
2011-09-05 09:48:17 UTC ---
IMO the example program is broken and cannot be used to proof violation of
contract of the library. This is so, because istreambuf_iterator is an input
iterator and any usage of operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #6 from Daniel Krügler
2011-09-05 11:11:26 UTC ---
(In reply to comment #5)
> On the other hand, it looks like I can
> construct i2 from s (instead of copying from i1) and still hit the same issue
> with a valid program. Do you agree?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #8 from Daniel Krügler
2011-09-05 12:56:44 UTC ---
(In reply to comment #7)
> Oh, are you saying that this rule has priority over the one that says that
> operator* just forwards to sgetc?
This was not my intention, but I recognize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #10 from Daniel Krügler
2011-09-05 14:17:14 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Why do you think that either implementation form could be
> > considered as non-conforming?
>
> When I read that operator* re
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-09-08 09:20:26 UTC ---
This problem seems still to exist in gcc 4.7.0 20110903 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47765
--- Comment #4 from Daniel Krügler
2011-09-08 16:57:48 UTC ---
(In reply to comment #3)
In fact I expected that there is some implementation freedom which allows this
(I was thinking of 14.7.1 p6), but I still wonder: I have always understood
th
||googlemail dot com
--- Comment #2 from Daniel Krügler
2011-09-12 21:34:55 UTC ---
Isn't this a DUP of Bug 15339?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50370
Bug #: 50370
Summary: [C++0x] Multiple declarations with default template
arguments accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50371
Bug #: 50371
Summary: [C++0x] std::nullptr_t rejected as non-type
template-parameter
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-09-22 07:19:17 UTC ---
The problem seem to exist in 4.7.0 20110917 (experimental) as well, pointing to
joust, at cp/call.c:7960.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50479
Bug #: 50479
Summary: Unevaluated usage of parameters in function default
arguments is accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47436
--- Comment #3 from Daniel Krügler
2011-09-22 18:11:24 UTC ---
(In reply to comment #2)
> Suggestions about a better error message? (should be easy to change)
What about:
"error: every valid template specialization requires an empty template
pa
||googlemail dot com
--- Comment #4 from Daniel Krügler
2011-09-28 17:54:55 UTC ---
(In reply to comment #3)
> Reduced testcase:
Just to be sure: Is this testcase rejected? If so, this seems in violation to
the C++(03) standard based on 7.2 p4:
"[..] Otherwise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #8 from Daniel Krügler
2011-09-28 21:36:53 UTC ---
(In reply to comment #7)
> What happened to issue Core/983?
It was originally accepted but later found out to be the wrong solution,
therefore it became fixed again by CWG 1121.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-10-01 15:18:04 UTC ---
The problem also occurs with gcc 4.7.0 20110924 (experimental)
||googlemail dot com
--- Comment #5 from Daniel Krügler
2011-10-03 13:17:11 UTC ---
I would have expected that the shown program works as expected. I'm quoting
ISO/IEC 14882:2003(E) (but N3290 seems to say the same):
1) [lib.replacement.functions] p2+3:
&qu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #10 from Daniel Krügler
2011-10-03 13:49:01 UTC ---
(In reply to comment #8)
I agree that given the "make static" contract of -fwhole-program (which I was
not aware about) the compiler behaves accordingly. I wonder whether it would b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641
--- Comment #2 from Daniel Krügler
2011-10-07 05:36:02 UTC ---
1) The outcome of is_constructible is expected, because you cannot construct
From from To, the actually wanted test would have been
static_assert(std::is_constructible::value, "not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641
--- Comment #3 from Daniel Krügler
2011-10-07 06:46:56 UTC ---
(In reply to comment #2)
> This looks like not-a-bug to me.
This refers to the traits implementation. I believe that the core language
should consider to remove the need for the temp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641
--- Comment #5 from Daniel Krügler
2011-10-07 07:13:50 UTC ---
(In reply to comment #4)
> N3242 says that From needs to be
> "convertible" to To, but I'm not at all convinced that "convertible" means the
> same thing as "is_convertible". Maybe i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785
--- Comment #8 from Daniel Krügler
2011-10-19 12:54:24 UTC ---
I agree that the test case should require the definition of the static member,
the actual reason being that the constraint in 3.2 p2,
"[..] unless it is an object that satisfies the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785
--- Comment #10 from Daniel Krügler
2011-10-19 13:07:44 UTC ---
(In reply to comment #9)
> I disagree. It is odr-used because the lvalue-to-rvalue conversions is not
> immediately applied.
>
> In (1*test::value) the lvalue-to-rvalue conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50830
--- Comment #4 from Daniel Krügler
2011-10-22 21:15:20 UTC ---
(In reply to comment #3)
I agree, but the partial specialization
template class... F, class T>
struct test, T>;
should be fine, because only primary class templates require a templa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50830
--- Comment #6 from Daniel Krügler
2011-10-23 09:51:44 UTC ---
[I assume you refer to p8 and the sentence: "If an argument is a pack expansion
(14.5.3), it shall be the last argument in the template argument list."]
No. list_templates is not an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50830
--- Comment #7 from Daniel Krügler
2011-10-23 10:02:19 UTC ---
I can only guess that there is a compiler defect in regard to handling variadic
template template parameters. The corresponding example
template
struct S;
template
struct X;
templa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50835
--- Comment #1 from Daniel Krügler
2011-10-23 11:47:19 UTC ---
Simplified test case:
//---
template
struct vector {};
template
struct rvalue_probe
{
explicit rvalue_probe(T &t) : value(t) {}
operator T&() const { return value; }
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50835
--- Comment #2 from Daniel Krügler
2011-10-23 11:50:17 UTC ---
Further simplification:
//---
struct vector {};
template
struct rvalue_probe
{
explicit rvalue_probe(T &t) : value(t) {}
operator T&() const { return value; }
T& value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50835
--- Comment #3 from Daniel Krügler
2011-10-23 12:23:41 UTC ---
Removing as much templates as possible:
//---
struct A {};
struct B
{
explicit B(A &t) : value(t) {}
operator A&() const { return value; }
A& value;
};
void should_be_l
||googlemail dot com
--- Comment #1 from Daniel Krügler
2011-10-23 21:30:05 UTC ---
According to [dcl.fct] p5,
"any parameter of type “array of T” or “function returning T” is adjusted to be
“pointer to T” or “pointer to function returning T,” respectively. [..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50864
--- Comment #8 from Daniel Krügler
2011-10-25 18:08:01 UTC ---
(In reply to comment #7)
> The arrow operator (vs, eg, +) seems also essential.
That makes sense to me, because the code could never be valid, so I would
suggest that the keyword is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50864
--- Comment #10 from Daniel Krügler
2011-10-25 18:28:56 UTC ---
(In reply to comment #9)
> Now, however, in the light of the second half of your message, I guess we
> should have another PR for the ICE on valid issue. Are you willing to open it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50870
Bug #: 50870
Summary: [C++0x] ICE with decltype, operator->, and default
template arguments
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50864
--- Comment #11 from Daniel Krügler
2011-10-25 19:17:51 UTC ---
(In reply to comment #10)
See bug 50870
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
--- Comment #6 from Daniel Krügler
2011-10-26 10:44:55 UTC ---
The corresponding CWG issue is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1288
201 - 300 of 884 matches
Mail list logo
