Hello,
The following invalid snippet triggers an ICE since 4.0.1:
extern int i;
extern int i;
int i[] = { 0 };
The problem is that 'finish_decl' ends up calling 'composite_type' with
incompatible types when updating the type of the declaration of 'i'
already encountered.
The attac
Hi, the following patch will be committed to google/main. The patch added
multiple
source file support for FDO and a couple of multi-source test cases for LIPO. It
also include a couple of bug fixes related to missing assembler name binding
cleanup.
regression test and SPEC with LIPO.
David
20
On Sun, 1 May 2011, Tom G. Christensen wrote:
> Latest results for 4.5.x
Thank you, Tom.
Gerald
Installed.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.19
diff -u -r1.19 gcc.css
--- gcc.css 25 Apr 2011 19:53:22 - 1.19
+++ gcc.css 1 May 2011 21:24:02 -
@@ -7,7 +
Linux 2.6.35 and later on ARM randomise the address space, breaking
precompiled header support in GCC. The fix is to use the support in
GCC for mmap()ing into a fixed, likely to be free address. The ARM
memory map is modeled on the i386 so I used the same definition.
Tested on trunk with a Ubunt
On Sun, 1 May 2011, Tom G. Christensen wrote:
> Latest results for 4.4.x.
Thanks, Tom!
Gerald
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -2995,7 +2995,7 @@ gfc_match_import (void)
>gfc_error ("Type name '%s' at %C is ambiguous", name);
>return MATCH_ERROR;
> }
> - else if (gfc_current_ns->proc_name->ns->parent != NULL
> +
Hi,
this patch fixes thinko I introduced while fixing another thinko
in accounting stack frame sizes. Due to the bug we did not
take into account stack size of the outermost function in the
inline tree resulting in too many decisions to not inline
because of large-stack-frae-growth limits.
The pa
I need this support for LIPO but it might be also useful for trunk.
The support is 'borrowed' from lib/lto.exp. I have tested with it and
it works fine. The only limitation is for any subdirectory with a
multi-source test case, all the other single source test case need
also to follow the same nam
On Sun, May 1, 2011 at 7:16 AM, Jan Hubicka wrote:
>> How about change "tree_profile_ipa" to "tree-profile" and
>> "ipa-profile" to "profile-estimate" -- basically drop the ipa in the
>> name. There are also many other passes using '_' though. Can tree
>> level pass_profile's name also be changed
Latest results for 4.6.x
-tgc
Testresults for 4.6.0:
armv7l-unknown-linux-gnueabi (2)
i386-pc-solaris2.8
i686-pc-linux-gnu (2)
ia64-unknown-linux-gnu
x86_64-unknown-linux-gnu
Index: buildstat.html
===
RCS file: /cvs/gcc/www
Latest results for 4.5.x
-tgc
Testresults for 4.5.3:
i686-apple-darwin9
x86_64-apple-darwin10.7.0
Testresults for 4.5.2:
mips-sgi-irix6.2
s390x-ibm-linux-gnu
x86_64-unknown-linux-gnu
Index: buildstat.html
===
RCS file: /cv
Latest results for 4.4.x.
-tgc
Testresults for 4.4.6:
i686-apple-darwin9
Testresults for 4.4.5:
i686-pc-linux-gnu
Testresults for 4.4.3:
i686-pc-linux-gnu
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/bu
> How about change "tree_profile_ipa" to "tree-profile" and
> "ipa-profile" to "profile-estimate" -- basically drop the ipa in the
> name. There are also many other passes using '_' though. Can tree
> level pass_profile's name also be changed to 'profile-estimate'? Their
> dump names won't collide
Hi,
I noticed that this field is write-only. The last use was for store
motion, which overloaded this 'loads' field with ANTIC_STORE_LIST. I
went back as far as gcc 3.3.6 but couldn't figure out what the field
is supposed to do for load motion. So this patch simply removes the
field.
Makes Nathan
Hello world,
after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.
In the long run, another option is to use interface mapping to eva
On Sat, Apr 30, 2011 at 16:37, Jerry DeLisle wrote:
> On 04/30/2011 12:56 AM, Janne Blomqvist wrote:
>>
>> On Sat, Apr 30, 2011 at 04:33, Jerry DeLisle
>> wrote:
>>>
>>> Hi,
>>>
>>> The attached patch does some cleanup and a check for trailing zeros to
>>> decide whether or not to round.
>>>
>>>
> What is wrong? x86-64 has 128byte redzone.
Nothing wrong, just strange. ISTM that it doesn't serve any useful purpose.
And I'm not sure that the rest of the code in ix86_expand_prologue is really
prepared for a negative size either.
--
Eric Botcazou
gcc-patches-ow...@gcc.gnu.org wrote on 20/04/2011 02:24:55 PM:
>
> Hi,
>
> In gcc.dg/vect/slp-3.c and gcc.dg/vect/no-vfa-pr29145.c vectorization is
> expected to fail on targets vect_no_align. But no realignment is
necessary
> here except for having the array bases aligned. This patch removes xf
Ramana Radhakrishnan wrote on 07/04/2011
03:16:44 PM:
>
> On 07/04/11 08:42, Ira Rosen wrote:
> > Hi,
> >
> > This patch makes both outputs of neon_vzip/vuzp/vtrn_internal
> > explicitly dependent on both inputs, preventing incorrect
> > optimization:
> > for
> > (a,b)<- vzip (c,d)
> > and
> >
Dear Tobias,
I applied your patch and have the following comments:
On Fri, Apr 29, 2011 at 11:46 PM, Tobias Burnus wrote:
> Dear all,
>
> gfc_trans_deferred_vars is a bit of a mess; there is first a block which
> handles function results of the type proc_sym->result == proc_sym.
> Afterwards, de
21 matches
Mail list logo
