On Wed, Jul 1, 2015 at 11:26 AM, Jason Merrill wrote:
> I've been threatening to do this for a couple of months, and now that the
> regressions are under control I think it's time. This patch changes the
> default C++ dialect to C++14.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
This caus
On 07/02/2015 07:41 PM, Jim Wilson wrote:
The code compiles with -std=c++98. It does not compile with -std=c++14.
So this testcase should be fixed to work with c++14.
Done.
Jason
On Fri, Jul 3, 2015 at 1:41 AM, Jim Wilson wrote:
> On 07/01/2015 11:17 PM, Jim Wilson wrote:
>> On Wed, Jul 1, 2015 at 10:21 PM, Jason Merrill wrote:
>>> This document also says that "A workaround until libraries get updated is to
>>> include or before any headers from that library."
>>> Can y
On 07/01/2015 11:17 PM, Jim Wilson wrote:
> On Wed, Jul 1, 2015 at 10:21 PM, Jason Merrill wrote:
>> This document also says that "A workaround until libraries get updated is to
>> include or before any headers from that library."
>> Can you try modifying the graphite* files accordingly?
>
> Ri
On Thu, Jul 2, 2015 at 6:08 AM, Richard Biener
wrote:
> On Thu, Jul 2, 2015 at 3:05 PM, Richard Biener
> wrote:
>> Yeah, I _think_ the fix is to move the isl includes below the system.h
>> include.
I tried this, and got a conflict for pretty much every macro defined
by ctype.h, e.g.
/usr/includ
On Thu, Jul 2, 2015 at 3:05 PM, Richard Biener
wrote:
> On Thu, Jul 2, 2015 at 8:18 AM, Marc Glisse wrote:
>> On Thu, 2 Jul 2015, Jason Merrill wrote:
>>
>>> On 07/02/2015 12:10 AM, Jim Wilson wrote:
This is a known gmp problem, documented in PR56019 and in
https://gcc.gnu.org
On Thu, Jul 2, 2015 at 8:18 AM, Marc Glisse wrote:
> On Thu, 2 Jul 2015, Jason Merrill wrote:
>
>> On 07/02/2015 12:10 AM, Jim Wilson wrote:
>>>
>>> This is a known gmp problem, documented in PR56019 and in
>>> https://gcc.gnu.org/gcc-4.9/porting_to.html
>>> near the bottom where it discusses
On Thu, 2 Jul 2015, Jason Merrill wrote:
On 07/02/2015 12:10 AM, Jim Wilson wrote:
This is a known gmp problem, documented in PR56019 and in
https://gcc.gnu.org/gcc-4.9/porting_to.html
near the bottom where it discusses cstddef.h changes.
This document also says that "A workaround until
On Wed, Jul 1, 2015 at 10:21 PM, Jason Merrill wrote:
> This document also says that "A workaround until libraries get updated is to
> include or before any headers from that library."
> Can you try modifying the graphite* files accordingly?
Right. I forgot to try that. Trying it now, I see t
On 07/02/2015 12:10 AM, Jim Wilson wrote:
This is a known gmp problem, documented in PR56019 and in
https://gcc.gnu.org/gcc-4.9/porting_to.html
near the bottom where it discusses cstddef.h changes.
This document also says that "A workaround until libraries get updated
is to include or b
On 07/01/2015 11:26 AM, Jason Merrill wrote:
> I've been threatening to do this for a couple of months, and now that
> the regressions are under control I think it's time. This patch changes
> the default C++ dialect to C++14.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
This causes a buil
On Wed, Jul 01, 2015 at 02:26:59PM -0400, Jason Merrill wrote:
> I've been threatening to do this for a couple of months, and now that the
> regressions are under control I think it's time. This patch changes the
> default C++ dialect to C++14.
Great!
It seems that our cppopts.texi is very outda
I've been threatening to do this for a couple of months, and now that
the regressions are under control I think it's time. This patch changes
the default C++ dialect to C++14.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6f2b3941ffb3734cecc05507dd8ed46f6a6d4f2d
Author: Jason Merrill
13 matches
Mail list logo
