Adding myself as Write After Approval maintainer

2013-03-24 Thread Tilo Schwarz
Adding myself as Write After Approval maintainer. 2013-02-24 Tilo Schwarz * MAINTAINERS (Write After Approval): Add myself. Regards, Tilo MAINTAINERS.patch Description: Binary data

[patch] fix libstdc++/56170

2013-03-24 Thread Jonathan Wakely
PR libstdc++/56170 * include/ext/debug_allocator.h (debug_allocator): Add missing members to meet allocator requirements. * testsuite/ext/debug_allocator/56170.cc: New. Tested x86_64-linux, committed to trunk. commit 489ac73182ce76281198730d49fde9b44c68c95e Author:

[PATCH, i386]: Add a couple of missing MMX move alternatives

2013-03-24 Thread Uros Bizjak
Hello! y->r and r->y interunit alternatives were missing for 64bit targets for true MMX moves. These alternatives are present in a movdi pattern. 2013-03-24 Uros Bizjak * config/i386/mmx.md (mov): Add ?!Ym,r and r,?!Ym alternatives. Tested on x86_64-pc-linux-gnu {,-m32} and committed

Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin

2013-03-24 Thread Kai Tietz
2013/3/23 Dave Korn : > On 23/03/2013 00:57, Kai Tietz wrote: >> 2013/3/23 Dave Korn : >>> On 23/03/2013 00:24, Kai Tietz wrote: 2013/3/23 Dave Korn : > On 23/03/2013 00:16, Kai Tietz wrote: > >> welcome, too. It would be even better if we could rethink actual the >> need of l

New Swedish PO file for 'gcc' (version 4.8-b20130224)

2013-03-24 Thread Translation Project Robot
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.8-b20130224.sv.po',

[Patch, fortran] Module loading improvements part 1/3

2013-03-24 Thread Janne Blomqvist
Hi, gfortran's handling of .mod files leaves a lot to be desired. One problem being that the parsing of the module is done in such a way that we seek back and forth in the file; see e.g. comments in PR 25708. This not only causes us to spend unnecessary time executing lseek syscalls, but we also r

Re: [patch, fortran, 4.9] Improve efficiency of array constructor operators

2013-03-24 Thread Thomas Koenig
Hello world, this updated patch fixes a regression in my previous patch, with a test case for that regression also attached. Regression-tested. OK for trunk? Thomas 2013-03-24 Thomas Koenig PR fortran/55806 * frontend-passes.c (optimize_code): Keep track of

[PATCH 5/n, i386]: Merge *movv2sf_internal and *movv2sf_internal_rex64 with base MMX move pattern

2013-03-24 Thread Uros Bizjak
Hello! 2013-03-24 Uros Bizjak * config/i386/sse.md (mov): Merge with movv2sf expander using MMXMODE mode iterator. (*move_internal): Merge with *movv2sf_internal and *movv2sf_internal_rex64 using MMXMODE mode iterator. Tested on x86_64-pc-linux-gnu {,-m32}, com

Re: extend fwprop optimization

2013-03-24 Thread Oleg Endo
Hi, On Sat, 2013-03-23 at 21:18 -0700, Wei Mi wrote: > This is the patch to add the shift truncation in > simplify_binary_operation_1. I add a new hook > TARGET_SHIFT_COUNT_TRUNCATED which uses enum rtx_code to decide > whether we can do shift truncation. I didn't use > TARGET_SHIFT_TRUNCATION_MAS

Re: [PATCH] Make ipa_read_jump_function use ipa_set_jf_* helpers

2013-03-24 Thread Jan Hubicka
> Hi, > > the following patch makes ipa_read_jump_function use the helper > functions to set up jump functions instead of doing it itself. The > main reason is that I plan to add some less-trivial code to one of the > helpers but setting the functions always in one place is a good idea > anyway.

Re: [PATCH] Teach IPA-CP to make calls direct based on contents of aggregates

2013-03-24 Thread Jan Hubicka
> > The reason why ipa_get_indirect_edge_target is split into two is that > unlike in the inlining case, this one has to understand the > description of known aggregate values in clones which are different > from aggregate jump functions (they are quite simpler). Otherwise the > patch is hopefull

Re: RFC: Add ADD_RESTRICT tree code

2013-03-24 Thread Tobias Burnus
Given that GCC is again in Stage 1, I would like to bring attention to the following RFC patch. To quote Richard in PR 45586: "I believe the correct solution will involve implementing the proposal for introducing explicit restrict tags and using that in the fortran frontend (removing the restr