iler generated copy
constructor of class Bar calls the explicit copy constructor of class
Foo. The fix is to implement ISO C++/17 16.3.1.4 (over.match.copy)
correctly.
Bootstrapped and tested with 'make check' on x86_64-linux.
Mukesh
/gcc/cp
2017-11-14 Mukesh Kapoor
On 11/3/2017 7:31 AM, Paolo Carlini wrote:
Hi,
On 02/11/2017 15:42, Jason Merrill wrote:
This is a good suggestion. I have attached the revised patch. Thanks.
OK, thanks!
Thanks Jason.
I was about to volunteer committing the patch but then noticed that
the testcase includes quite a lot, e
On 11/1/2017 1:02 PM, Jason Merrill wrote:
On Tue, Oct 31, 2017 at 12:17 PM, Mukesh Kapoor
wrote:
On 10/25/2017 6:44 PM, Mukesh Kapoor wrote:
On 10/25/2017 4:20 AM, Nathan Sidwell wrote:
On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:
Thanks for pointing this out. Checking in the front end
On 10/25/2017 6:44 PM, Mukesh Kapoor wrote:
On 10/25/2017 4:20 AM, Nathan Sidwell wrote:
On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:
Thanks for pointing this out. Checking in the front end will be
difficult because the front end gets tokens after macro expansion. I
think the difficulty of
On 10/25/2017 4:20 AM, Nathan Sidwell wrote:
On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:
Thanks for pointing this out. Checking in the front end will be
difficult because the front end gets tokens after macro expansion. I
think the difficulty of fixing this bug comes because of the
On 10/25/2017 9:06 AM, Jason Merrill wrote:
On Wed, Oct 25, 2017 at 7:20 AM, Nathan Sidwell wrote:
On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:
Thanks for pointing this out. Checking in the front end will be difficult
because the front end gets tokens after macro expansion. I think the
On 10/24/2017 7:05 AM, Jason Merrill wrote:
On Fri, Oct 20, 2017 at 3:52 PM, Mukesh Kapoor wrote:
On 10/20/2017 11:00 AM, Mukesh Kapoor wrote:
On 10/20/2017 10:45 AM, Nathan Sidwell wrote:
On 10/20/2017 12:37 PM, Mukesh Kapoor wrote:
This patch fixes https://gcc.gnu.org/bugzilla
On 10/20/2017 11:00 AM, Mukesh Kapoor wrote:
Hi,
On 10/20/2017 10:45 AM, Nathan Sidwell wrote:
On 10/20/2017 12:37 PM, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955.
Handle user-defined literals correctly in lex_string(). An empty
string
Hi,
On 10/20/2017 10:45 AM, Nathan Sidwell wrote:
On 10/20/2017 12:37 PM, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955.
Handle user-defined literals correctly in lex_string(). An empty
string followed by an identifier is
a valid user-defined
by an identifier.
+For an empty string "", (cur-base)==2. Bug 80955 */
+ if (is_macro (pfile, cur) && ((cur-base) != 2))
{
/* Raise a warning, but do not consume subsequent tokens. */
if (CPP_OPTION (pfile, warn_literal_suffix) &a
long type and this causes compilation errors later on. The fix is to
simply use the fixed underlying type of the enum instead of creating a
new one.
Mukesh
On 10/18/2017 1:10 PM, Nathan Sidwell wrote:
On 10/18/2017 12:17 PM, Mukesh Kapoor wrote:
On 10/9/2017 12:20 PM, Mukesh Kapoor wrote:
Hi,
On 10/9/2017 12:20 PM, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307.
For an unscoped enum with a fixed underlying type, the function
type_promotes_to() does not always return the same type as the
underlying type. The fix is to use the underlying
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307.
For an unscoped enum with a fixed underlying type, the function
type_promotes_to() does not always return the same type as the
underlying type. The fix is to use the underlying type of the enum
instead of creating a new o
13 matches
Mail list logo
