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
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
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,
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
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
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
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/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/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 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 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 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
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
13 matches
Mail list logo
