New Swedish PO file for 'gcc' (version 6.1-b20160131)

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-6.1-b20160131.sv.po',

Re: [PATCH, i386]: Fix PR 70024, wrong code with -fPIC and -mred-zone on i686

On Sun, Mar 6, 2016 at 1:39 PM, Uros Bizjak wrote: > Hello! > > Attached patch prevents red-zone with -fPIC for leaf functions on > i686. The idea is to mark when set_got is expanded as a call to a pc > thunk, and use this flag to prevent red-zone in the current function. > >

[PATCH, i386]: Fix PR 70024, wrong code with -fPIC and -mred-zone on i686

Hello! Attached patch prevents red-zone with -fPIC for leaf functions on i686. The idea is to mark when set_got is expanded as a call to a pc thunk, and use this flag to prevent red-zone in the current function. Please note that using red-zone with i686 violates all known ABIs, but some future

Re: [PATCH] Fix PR c++/66786 (ICE with nested lambdas in variable template)

On Sun, Mar 6, 2016 at 1:42 AM, Jason Merrill wrote: > On 02/08/2016 12:19 AM, Patrick Palka wrote: >> >> Here, we are calling template_class_depth on a FIELD_DECL corresponding >> to a lambda that is used inside variable template. template_class_depth >> however does not see

[PATCH, RFC]. Some initial work on coroutines

Hi, all! I decided to start working on coroutines support in C++ (according to P0057R2 proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0057r2.pdf). I did some analysis of how other compilers implement coroutines: https://github.com/miyuki-chan/coroutines This github repo has a

[PATCH][ARM,testsuite] fix pragma_cpp_fma testcase

Hi, In commit r233654, Christian introduced a new test: pragma_cpp_fma. Unfortunately, this test fails when gcc is configured --with-fpu >= neonvfpv4: __ARM_FEATURE_FMA is still defined after the last pop_options. To address this, I propose to simply force fpu=vfp via a pragma at the beginning

Re: [committed, libffi] Match upstream soname

On 05.03.2016 19:28, Richard Henderson wrote: When I went to apply my symbol versioning patch to upstream, I discovered that upstream had already bumped their soname to 6.4.0, beyond the bump that I'd applied to gcc to 5.0.0. So I bumped upstream to 7.0.0, including the symbol versioning, and

[PATCH] Enable the whole-vector-shift tests for PPC64

Hi, Anton Blanchard pointed out that we don't currently execute the whole-vector-shift tests for PowerPC. I tested enabling them on powerpc64le-unknown-linux-gnu, which resulted in 8 more test successes and no additional failures. I still need to test this on big-endian. Assuming no problems

[PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements

GCC 4.9 had added support for C++ VLAs as specified in WG21 document N3639 expected to be included in C++ 14. However, WG21 ultimately decided not to include N3639 in C++ 14 and the G++ support was partially removed in 5.1. Unfortunately, the removal rendered some safe albeit erroneous G++ 4.9

[Patch, fortran] PRs 70031 and 69524 - submodule tweaks

Dear All, These are two rather trivial modifications to permit, 'module' to appear at any position in the list of prefixes in the procedure declaration and to allow module procedures to appear within a module contains section. I was rather astonished at this latter since it does seem to be rather

Re: [PATCH][ARM] PR target/70008

New patch that adds the predicate "reg_or_arm_rhs_operand" as suggested by Richard. Tested on all arm and thumb targets as before. Okay for trunk? 2016-03-07 Michael Collison PR target/70008 * config/arm/predicates.md (reg_or_arm_rhs_operand): New

Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE

On Wed, Feb 17, 2016 at 10:20 AM, Christophe Lyon wrote: > On 17 February 2016 at 11:05, Kyrill Tkachov > wrote: >> >> On 17/02/16 10:03, Christophe Lyon wrote: >>> >>> On 15 February 2016 at 12:32, Kyrill Tkachov >>>

Re: [PATCH][ARM] Error out of arm_neon.h if compiling for soft-float ABI

On Mon, Feb 29, 2016 at 5:48 PM, Kyrill Tkachov wrote: > Hi all, > > Now that we've moved to pragmas guarding the various intrinsics in > arm_neon.h I think we should still > throw a #error if someone tries to include the header while compiling for > -mfloat-abi=soft.

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

On Tue, Jan 26, 2016 at 2:42 PM, Christophe Lyon wrote: > Hi, > > This is a followup to PR63304. > > As discussed in bugzilla, this patch disables pcrelative_literal_loads > when -mfix-cortex-a53-843419 (or its default configure option) is > used. > > I copied the

Re: [patch, testsuite, ARM] don't try to execute simd.exp tests on targets without NEON

On Wed, Mar 2, 2016 at 1:33 PM, Andre Vieira (lists) wrote: > On 21/05/15 10:01, Kyrill Tkachov wrote: >> Hi Sandra, >> >> On 21/05/15 06:43, Sandra Loosemore wrote: >>> This is another patch aimed at fixing bugs relating to trying to execute >>> NEON code on a

Re: [PATCH][ARM] PR target/70008

On Mon, Mar 7, 2016 at 3:51 AM, Michael Collison wrote: > New patch that adds the predicate "reg_or_arm_rhs_operand" as suggested by > Richard. Tested on all arm and thumb targets as before. > > Okay for trunk? Missing comment on the predicate. Ok, please queue this

Re: Please include ada-hurd.diff upstream (try2)

[adding Eric for review] On 02.03.2016 00:42, Svante Signell wrote: Hello, As time progresses, the ada-hurd.diff patch has now been living in Debian since gcc-4.6 and is now in gcc-5 and gcc-6. Last try to get it included upstream was in 2012, and 2014, e.g see

Re: [PATCH] Enable the whole-vector-shift tests for PPC64

On March 7, 2016 2:03:30 AM GMT+01:00, Bill Schmidt wrote: >Hi, > >Anton Blanchard pointed out that we don't currently execute the >whole-vector-shift tests for PowerPC. I tested enabling them on >powerpc64le-unknown-linux-gnu, which resulted in 8 more test

Re: [PATCH] Fix pr70061

On 03/05/2016 01:02 PM, Richard Henderson wrote: The problem is that we are emitting copy sequences to edges without caring for deferred popping of arguments. Thus when we began emitting code for the first block, which in this case starts with a label, we had 32 bytes of pending stack