ponent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following program (using -Wall -Wextra -std=c++2a -pedantic) is rejected:
#include
bool ok = std::shared_ptr{} <=> nullptr;
int main
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following code is accepted for language versions c++14, c++17, as well as
c++20 using the following additional compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94563
--- Comment #1 from Daniel Krügler ---
To clarify the actual bug character of this issue, the following example shows
it more clearly:
template
bool test(T*)
{
return true;
}
int main()
{
test((int*)(nullptr));
}
This program should be ill
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following program is accepted when compiling against C++20, but should be
rejected, because the C++20 working draft does
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
The following program should be accepted, but is rejected due to a violation of
the static_assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554
--- Comment #3 from Daniel Krügler ---
(In reply to Melissa from comment #0)
> Clang errors on this case, so it's possible that my code is invalid: Is it
> legal to compare a function pointer against null in a constant-expression?
The example is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94049
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94619
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
--- Comment #1 from Daniel Krügler ---
This looks like a variant fo bug 90415 to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94550
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644
--- Comment #3 from Daniel Krügler ---
(In reply to Avi Kivity from comment #2)
> PR 94033 is also related to constructibity trait testing with an
> inaccessible constructor. Looks like the intrinsic depends on where it was
> evaluated.
Indeed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
--- Comment #2 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #1)
[..]
> I'm surprised that the Visual Studio compiler (I tested 2019) rejects the
> original example, this looks like a bug to me, especially since that
> compiler
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Target Milestone: ---
Using the compiler flags
-Wall -Wextra -std=c++2a -pedantic
the following code example
//--
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94721
--- Comment #2 from Daniel Krügler ---
(In reply to Marek Polacek from comment #1)
> Confirmed, thanks for the report.
Sigh, thanks. I'm starting to realize now, that it seems that the *intention*
of
https://wg21.link/p1959r0 adopted in November
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94923
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #3 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #2)
> Another way to implement the __unspec constructor would be:
>
> consteval __unspec(int __n) { if (__n != 0) throw __n; }
>
> But I think I discussed this w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #5 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #4)
> It's consteval, the throw is there to make it not a constant expression and
> give an error if anything except 0 is used. i.e. it can never throw, it
> either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95368
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #7 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #6)
> A new LWG issue has been submitted, and there is a suggested resolution.
Will take care and inform in this issue here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #12 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > A new LWG issue has been submitted, and there is a suggested resolution.
>
> Will take care and inform in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95686
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
Bug #: 56208
Summary: sizeof sfinae fails to work
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
--- Comment #1 from Daniel Krügler
2013-02-04 19:54:47 UTC ---
I just notice that the problem is not restricted to sizeof sfinae. In fact if
we define the first test overload as follows:
template
static one test(decltype(
(make() << make(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
--- Comment #2 from Daniel Krügler
2013-02-04 19:57:18 UTC ---
The actually tested gcc version was 4.8.0 20130127 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
Daniel Krügler changed:
What|Removed |Added
Summary|[4.8 Regression] sizeof |[4.8 Regression] Some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
--- Comment #5 from Daniel Krügler
2013-02-05 06:37:06 UTC ---
I think I found the problem, the root is actually not related to sfinae
(fortunately), but to the way how name-lookup in classes work in gcc. The
problem can be fixed (as a workaroun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
--- Comment #9 from Daniel Krügler
2013-02-05 19:09:15 UTC ---
Further data about the root of the problem: It seems actually to be an access
problem, the requirements for reproducing seem to be:
1) Some class B derives *privately* from a base c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222
--- Comment #2 from Daniel Krügler
2013-02-06 11:42:21 UTC ---
The code looks valid to me, I don't see any reason for capturing something
here. The expression "&Test::y" should be valid in that scope and returns an
rvalue.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-02-06 19:35:15 UTC ---
The problem seems to be fixed in 4.7.2 and in 4.8.0 trunk.
||googlemail dot com
--- Comment #7 from Daniel Krügler
2013-02-10 16:00:42 UTC ---
(In reply to comment #6)
I agree with Paolo and Andrew when considered as a potentially C++03 code, but
I would like to add that the example code is indeed valid in C++11, because
||googlemail dot com
--- Comment #4 from Daniel Krügler
2013-02-14 20:36:52 UTC ---
Seems to be a dup of bug 55017
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
--- Comment #3 from Daniel Krügler
2013-02-16 11:57:21 UTC ---
(In reply to comment #2)
> I'm not opposed to this behavior, but I think it would be a language change.
Thanks Jason. I just see now
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56358
Bug #: 56358
Summary: [C++11] Erroneous interaction of typedef and inherited
constructor declarations
Classification: Unclassified
Product: gcc
Version: 4.8.0
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-02-19 09:16:50 UTC ---
The problem also exists on 4.8.0 trunk
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-02-19 09:23:34 UTC ---
The problem also exists for 4.7.2, so no regression. The diagnostics is
interesting:
"7:9: error: '...' handler must be the last handler for its try block
[-fpermissive]
catch(...){
^"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56358
--- Comment #1 from Daniel Krügler
2013-02-20 12:09:13 UTC ---
As of the more recent trunk gcc 4.8.0 20130217 (experimental) these problems
have been partially reolved. Template B1 is now accepted, but template B2 still
causes problems. The redu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #3 from Daniel Krügler
2013-02-22 10:59:28 UTC ---
(In reply to comment #2)
> Isn't G++ correct? Foo::type exists unconditionally, so SFINAE doesn't apply.
> The invalid type is not in the immediate context of the substitution.
This
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #7 from Daniel Krügler
2013-02-22 22:01:18 UTC ---
(In reply to comment #4)
> I think 13.3 [over.match] ¶2 and 13.3.1 [over.match.funcs] ¶7 say the
> function
> template specialization must be generated before the number of argumen
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-02-23 22:30:35 UTC ---
This issue may have similar reasons as bug 54812.
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-03-03 19:46:42 UTC ---
I don't think that either example should be accepted. My understanding is, that
the second T is still considered as a parameter pack but not as an expansion
(because it is not fol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043
--- Comment #13 from Daniel Krügler
2013-03-04 10:46:27 UTC ---
(In reply to comment #12)
> Then I suppose that if anything this is library, not core, even if there are
> interactions. Is there an open LWG DR?
You may want to refer to:
http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506
--- Comment #4 from Daniel Krügler
2013-03-05 20:18:00 UTC ---
(In reply to comment #3)
Presumably my judgment was a bit premature and I think there is a logical flaw
in my original argumentation: I think I misinterpreted 14.5.3 p5. I'm switchin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609
Bug #: 56609
Summary: [C++11] Several type traits give incorrect results for
std::nullptr_t
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609
--- Comment #2 from Daniel Krügler
2013-03-13 09:55:33 UTC ---
(In reply to comment #1)
> Seems straightforward enough to be fixable in 4.8.0 too. Does this patchlet
> cover all the issues you can see?
Thanks Paolo! I cannot test this from here
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-03-20 08:38:22 UTC ---
It also works for gcc 4.8.0 trunk using mingw 64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636
--- Comment #4 from Daniel Krügler
2013-03-20 10:19:47 UTC ---
(In reply to comment #3)
I tested gcc 4.8.0 20130310 (experimental)
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-03-23 12:20:30 UTC ---
This looks like
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1584
to me
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-03-28 12:15:30 UTC ---
This line does not what you expect it would do (Search for "most vexing
parse"):
CLockGuard sGuard(CIntLock());
It does *not* construct an CIntLock object nor does it declare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782
Bug #: 56782
Summary: [C++11] Regression with empty pack expansions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
||googlemail dot com
--- Comment #4 from Daniel Krügler
2013-04-03 22:15:49 UTC ---
I agree with Andrew: In this case the copy-constructor will be called, because
the template constructor is not a better match (In C++11 template constructors
can be selected for copying
||googlemail dot com
--- Comment #6 from Daniel Krügler
2013-04-07 21:32:46 UTC ---
IMO this behaviour should be considered in the light of
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#903
Assuming the P/R of this issue becomes accepted, both
||googlemail dot com
--- Comment #3 from Daniel Krügler
2013-04-08 14:55:54 UTC ---
I agree, it looks like bug 52072 to me.
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-04-09 09:10:52 UTC ---
There are several problems in your example:
1) You have not declared a default constructor in template Stack, but you have
provided user-declared constructors (The deleted ones). This
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889
--- Comment #2 from Daniel Krügler
2013-04-09 09:36:29 UTC ---
(In reply to comment #1)
In addition I would like to remark that the precise declaration state of the
inherited initializer-list constructor in vector_stack is unclear, because of
h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889
--- Comment #5 from Daniel Krügler
2013-04-09 19:13:55 UTC ---
This issue is not the right place for discussing programming idioms, but as a
last comment to the code: Your reference to PL alone does not solve your
programing error: You need to d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56905
Bug #: 56905
Summary: [C++11][DR 1130] std::copy_exception should be removed
or no longer be used
Classification: Unclassified
Product: gcc
Version: 4.8.0
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56905
--- Comment #2 from Daniel Krügler
2013-04-11 18:05:18 UTC ---
Here is my suggestion for a possible test, to be compiled with flags
-std=c++11 -Wall -W -pedantic
//-
#define copy_exception k42;
#include
#include
//---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
--- Comment #4 from Daniel Krügler
2013-04-13 11:26:25 UTC ---
(In reply to comment #3)
> The example in PR 56943 gives a wrong-code example
Could you explain why? It looks valid to me. According to my understanding, the
free operator+ overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
--- Comment #6 from Daniel Krügler
2013-04-13 11:55:36 UTC ---
(In reply to comment #5)
> and G++ calls the global one, returning the wrong result, so it's wrong-code
OK, I misunderstood the meaning of "wrong-code": I thought that was intended t
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-04-25 09:55:47 UTC ---
Here are two different things to consider:
1) The standard library specification of basic_string's move-assignment
operator currently requires that it works for self-assignment:
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-04-25 10:55:08 UTC ---
For gcc 4.9.0 20130421 (experimental) this gives me an ICE:
"main.cpp|8|internal compiler error: canonical types differ for identical types
b and b|"
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-04-25 11:04:31 UTC ---
It seems to me as if you are observing the core language issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1604
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55708
--- Comment #1 from Daniel Krügler
2013-04-26 10:37:55 UTC ---
gcc 4.9.0 20130421 (experimental) accepts the code on my system (64-bit mingw).
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-04-26 19:09:43 UTC ---
gcc 4.9.0 20130421 (experimental), compiled with flags -std=c++11 -Wall
-pedantic-errors accepts the code as written on my system (mingw 64-bit).
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-04-27 22:40:20 UTC ---
A similar ICE occurs for gcc 4.9.0 20130421 (experimental):
main.cpp|3|internal compiler error: in finish_decltype_type, at
cp/semantics.c:5406|"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172
Bug #: 57172
Summary: [C++11][DR 1164] Template overload resolution
ambiguous for T&& versus T&
Classification: Unclassified
Product: gcc
Version: 4.9.0
Sta
||googlemail dot com
--- Comment #3 from Daniel Krügler
2013-05-06 11:35:05 UTC ---
(In reply to comment #2)
> Good point. Sadly, is_convertible is not equivalent to implicit convertibility
> exactly due to that additional requirement (not sure if the lat
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-05-06 12:09:34 UTC ---
I agree that the code should be accepted, because the member initializer
performs direct-initialization. The very same problem also exists for gcc 4.9.0
20130428 (experimental).
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-05-06 12:23:02 UTC ---
Unless I'm misunderstanding your suggestion I think that a compiler is not
allowed to apply copy-elision here, because that case was explicitly excluded
from 12.8 p31 by
http://www
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
--- Comment #3 from Daniel Krügler
2013-05-06 13:11:15 UTC ---
(In reply to comment #2)
> Do you have a link to the discussion, or happen to remember the arguments?
> I can see that there are more possible issues with the parameter (it lives
>
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-05-07 20:52:28 UTC ---
Here a more simplified version that reproduces the problem:
//---
#include
template
struct set {
set() = default;
set(std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Bug #: 57220
Summary: [mingw] Undefined reference to __mingw_strtod
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Daniel Krügler changed:
What|Removed |Added
Keywords||link-failure
--- Comment #1 from Daniel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Daniel Krügler changed:
What|Removed |Added
CC||ktietz70 at googlemail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
--- Comment #5 from Daniel Krügler
2013-05-08 19:56:06 UTC ---
(In reply to comment #3)
Thanks for the litmus test, Kay. The result output I'm getting is:
MinGW-W64 Runtime 3.0 (alpha - rev. 0) -00-00
so it seems this is indeed the version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
--- Comment #7 from Daniel Krügler
2013-05-08 20:25:44 UTC ---
(In reply to comment #6)
The attached '-v' '-save-temps' output indicates version 4.9.0 20130505
(experimental) (x86_64-w64-mingw32), but I'm not sure whether this is reliable
in this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
--- Comment #9 from Daniel Krügler
2013-05-08 21:41:40 UTC ---
(In reply to comment #8)
> Well, you should us the nm tool to check for existance of a symbol. Grepping
> for strings might lead you to wrong direction.
My apologies, I had seen the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Daniel Krügler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
--- Comment #13 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #10)
FWIW, I fully agree with Jason: VLAs are very restricted and don't even allow
for forming references to them, so that the standard library won't even try to
provi
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
Consider this as a reminder bug entry to provide the atomic_* overloads for
std::shared_ptr. A minimal test case could be:
#include
int main() {
const std::shared_ptr p;
bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57250
--- Comment #2 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #1)
Thanks for the pointer to the status page - sorry, I didn't check it before.
For the future: Does it make sense to open such reminder bugs for "not yet
complete C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57253
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57270
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
The following code is rejected if compiled with gcc 4.9.0 20130505
(experimental) using the flags
-std=c++11 -Wall -pedantic-errors
||googlemail dot com
--- Comment #3 from Daniel Krügler
2012-08-12 22:58:09 UTC ---
(In reply to comment #2)
> I actually think GCC is correct, A causes all member functions to be
> instantiated.
I disagree, the instantiation of A shall only instantiate all
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-12 23:25:51 UTC ---
The problem still exists in gcc 4.8 trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Bug #: 54249
Summary: [C++11] No ::nullptr_t in header
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Daniel Krügler changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Daniel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #3 from Daniel Krügler
2012-08-14 09:52:30 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > "Every C header, each of which has a name of the form name.h, behaves as if
> > each name placed in the standard library namesp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #11 from Daniel Krügler
2012-08-14 11:01:47 UTC ---
(In reply to comment #9)
> I must also add that frankly personally I don't consider these issues so
> serious: IMHO a new C++ project should immediately use the c* headers. I see
> t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Daniel Krügler changed:
What|Removed |Added
Severity|normal |minor
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-15 21:15:16 UTC ---
The problem still exists in gcc 4.8.trunk. Version 4.8.0 20120729
(experimental)
delivers:
7|internal compiler error: vector VEC(tree,base) index domain error, in
insert_capture_proxy at
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-16 06:20:47 UTC ---
The problem seems to be fixed in gcc 4.8.0 20120729 (experimental)
||googlemail dot com
--- Comment #1 from Daniel Krügler
2012-08-16 06:24:26 UTC ---
The problem still exists in gcc 4.8.0 20120729 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289
--- Comment #2 from Daniel Krügler
2012-08-16 19:38:16 UTC ---
The problem seems still to exist in gcc 4.8.0 20120729 (experimental).
Just to be sure that this is not due to a badly formed error description I
tested to compile the folowing code
1 - 100 of 884 matches
Mail list logo
