On Sat, Mar 8, 2014 at 8:30 PM, Mike Stump wrote:
> Are they any plans to change the default language for C++?
Probably problematic for compatibility reasons. But how about adding
c++1, g++11, and c++14, and g++14 wrappers similar to c99?
The code would only remove a variable from a common block if it was just
defined in the previous statement. The PR showed a case where a pre-existing
variable was put in the common block. When it was not removed, the common
block list was wrong and segfaulted (or infinite looped) when used la
On Fri, Mar 7, 2014 at 8:03 PM, Ian Lance Taylor wrote:
>> Attached patch avoids a bunch of:
>>
>> ../../../gcc-svn/trunk/libgcc/crtstuff.c: In function 'frame_dummy':
>> ../../../gcc-svn/trunk/libgcc/crtstuff.c:463:19: warning: array
>> subscript is above array bounds [-Warray-bounds]
>>if (
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.9-b20140202.sv.po',
Hello,
here is a fix for a wrong code issue, where we pass a descriptor with
broken bounds when the actual argument is a transposed array and the
dummy an assumed shape dummy.
The bug comes from the interaction of the transpose optimization,
which creates a descriptor with transposed bounds withou
On Sat, Mar 08, 2014 at 11:08:14PM +0100, Gerald Pfeifer wrote:
> On Thu, 6 Mar 2014, Jakub Jelinek wrote:
> > I've backported a few bugfixes to 4.8 branch, bootstrapped/regtested
> > on x86_64-linux and i686-linux, committed to branch.
>
> This reminds my: what are your plans doing new release
On Sun, Mar 9, 2014 at 6:57 AM, Uros Bizjak wrote:
> On Fri, Mar 7, 2014 at 8:03 PM, Ian Lance Taylor wrote:
>
>>> Attached patch avoids a bunch of:
>>>
>>> ../../../gcc-svn/trunk/libgcc/crtstuff.c: In function 'frame_dummy':
>>> ../../../gcc-svn/trunk/libgcc/crtstuff.c:463:19: warning: array
>>>
Hello,
Le 09/03/2014 13:59, jimmie.da...@l-3com.com a écrit :
>
>
> The code would only remove a variable from a common block if it was just
> defined in the previous statement. The PR showed a case where a pre-existing
> variable was put in the common block. When it was not removed, the comm
On Sun, Mar 09, 2014 at 09:41:59AM -0700, Ian Lance Taylor wrote:
> >>> Attached patch avoids a bunch of:
> >>>
> >>> ../../../gcc-svn/trunk/libgcc/crtstuff.c: In function 'frame_dummy':
> >>> ../../../gcc-svn/trunk/libgcc/crtstuff.c:463:19: warning: array
> >>> subscript is above array bounds [-Wa
This is my first shot at library patches. Do tell me if there's
anything massively
wrong. Tested on x86_64-linux.
2014-03-09 Ville Voutilainen
Implement is_trivially_default_constructible.
* doc/xml/manual/status_cxx2011.xml: Remove mention of is_trivially_default_cons
tructible not being imp
Comments from Mikael:
#1. Please merge the two ifs; it seems they have exactly the same scope
after the patch.
#2. This comment applies to the TOUPPER thing below...
.. so it should be put here. Also the indentation is wrong.
#3.This is unnecessary.
===
All corre
Hello,
This is new patch version.
Approach suggested by Richard Biener with lowering bit-field accesses instead
of modifying gimple trees is implemented.
Although, algorithm still detects adjacent bit field accesses, which copy
values from one to another bit-field of same type.
If those accesses
Le 09/03/2014 20:47, jimmie.da...@l-3com.com a écrit :
> Comments from Mikael:
>
> #1. Please merge the two ifs; it seems they have exactly the same scope
> after the patch.
>
> #2. This comment applies to the TOUPPER thing below...
> .. so it should be put here. Also the indentation is wron
On Sun, Mar 9, 2014 at 6:31 PM, Jakub Jelinek wrote:
> On Sun, Mar 09, 2014 at 09:41:59AM -0700, Ian Lance Taylor wrote:
>> >>> Attached patch avoids a bunch of:
>> >>>
>> >>> ../../../gcc-svn/trunk/libgcc/crtstuff.c: In function 'frame_dummy':
>> >>> ../../../gcc-svn/trunk/libgcc/crtstuff.c:463:1
Hi all,
This final patch does two things.
First: In read.c it implements a simple space skipping scheme in read_decimal
where I found a lot of repeated next_char calls happening. This gives a pretty
good boost in performance and is applicable in general for reading integers.
Second: I have take
From: Mikael Morin [mikael.mo...@sfr.fr]
Sent: Sunday, March 09, 2014 3:40 PM
To: Davis, Bud @ SSG - Link; gcc-patches@gcc.gnu.org; fort...@gcc.gnu.org
Subject: Re: patch fortran, pr 59746, internal compiler error : segmentation
fault
> - if (p->
16 matches
Mail list logo
