http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #19 from Kerrek SB 2011-10-04 11:59:39
UTC ---
> The following allocation and deallocation functions (18.6) are implicitly
declared in global scope in each translation unit of a program.
If those functions are declared implicitly, co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #13 from Kerrek SB 2011-10-03 16:12:28
UTC ---
Very interesting. I understand that making the function static makes the
program ill-formed, but it's still somewhat surprising that a compiler flag
should turn a perfectly valid program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #3 from Kerrek SB 2011-10-02 23:32:47
UTC ---
Thank you for the replies. Is this behaviour standard-conforming? Also, could
you tell me how I "mark the operators as exported", or just anything else
that'll make the program behave as e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
Bug #: 50594
Summary: Option -fwhole-program discards replaced new operator
for std::string
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458
--- Comment #1 from Kerrek SB 2011-09-19 22:13:29
UTC ---
(I am told that this is no longer a problem in the latest snapshot.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458
Bug #: 50458
Summary: ICE when using brace-initializer for new array
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50443
--- Comment #3 from Kerrek SB 2011-09-17 21:50:05
UTC ---
Alright, if it's fixed already, that's fine. I only have the full release
versions, so I didn't test anything newer than 4.6.1. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50443
Bug #: 50443
Summary: ICE when using brace-enclosed initializer for C-style
array in constructor
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075
--- Comment #7 from Kerrek SB 2011-08-15 13:57:51
UTC ---
This is great, thank you!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075
--- Comment #2 from Kerrek SB 2011-08-13 14:09:20
UTC ---
Indeed, according to the FDIS size() is *not* constexpr, but I had initially
just checked the GCC implementation, in which it *is* declared as constexpr!
(This is in "c++/4.6.1/initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075
Bug #: 50075
Summary: ICE related to parameter deduction and
initializer_list
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49952
--- Comment #3 from Kerrek SB 2011-08-03 11:36:41
UTC ---
Maybe it could trigger a warning in -pedantic mode?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49952
Summary: Unicode literals do not generate errors as prescribed
by the FDIS standard
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
--- Comment #4 from Kerrek SB 2011-07-07 16:09:55
UTC ---
You're right, it works in 4.6.1 - thanks! (Just updated.)
Say, since you're here, if I change the definition of x from "Foo[2]" to
"std::array", should I be allowed to initialize it with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
--- Comment #2 from Kerrek SB 2011-07-07 11:49:46
UTC ---
Yes, I know that the code is invalid, but that shouldn't make the compiler
crash, should it?
For that matter, your proposed correct syntax is also rejected by 4.6.0:
Goo::Goo() : x{Foo(4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
Summary: Compiler crashes with "internal compiler error: in
perform_member_init, at cp/init.c:530"
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
16 matches
Mail list logo
