[RFC PATCH] Reducing GCC initialization time by merging builtins

The attached patch illustrates the following idea: we can replace several builtins having the same signature with one auxiliary builtin with a special argument. This argument will specify which particular builtin the auxiliary one should expand to. We pull the argument out at the expand stage and b

New Vietnamese PO file for 'gcc' (version 5.1-b20150208)

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 Vietnamese team of translators. The file is available at: http://translationproject.org/latest/gcc/vi.po (This file, 'gcc-5.1-b20150208.vi.po

Re: [doc, rfa] (v2) improve x86 transactional memory intrinsics section

On 02/24/2015 01:51 AM, Sandra Loosemore wrote: On 02/23/2015 03:36 AM, Patrick Marlier wrote: On 02/22/2015 04:06 AM, Sandra Loosemore wrote: +Here is an example showing handling for @code{_XABORT_RETRY} +and a fallback path for other failures: + +@smallexample +#include + +int n_tries, max_

Re: Merge current set of OpenACC changes from gomp-4_0-branch

Hi, On Wed, 4 Feb 2015 15:05:45 + Julian Brown wrote: > The major changes are: > > * The removal of the OpenACC-specific plugin hooks open_device, > close_device, set_device_num and get_device_num. The functionality > has been moved into the init/fini hooks (for the first two) or moved

Fwd: Re: [PATCH][4/5] Handle internal_fn in operand_equal_p

[ forwarding. for some reason, this email didn't make it to gcc-patches ml archive ] Forwarded Message Subject: Re: [PATCH][4/5] Handle internal_fn in operand_equal_p Date: Mon, 23 Feb 2015 10:03:34 +0100 From: Richard Biener To: Tom de Vries CC: Jakub Jelinek , GCC Patches ,

Re: [PATCH] ASan phase place change

On 02/20/2015 03:07 PM, Jakub Jelinek wrote: On Fri, Feb 20, 2015 at 02:59:51PM +0300, Marat Zakirov wrote: Here is simple patch that moves asan phase just behind sanopt for all O0/O1/O2/O3 modes which gives +7% on x86 SPEC2006 (ref dataset). Regression testing and sanitized GCC bootstrapping w

[patch, avr] Tidy up avr-log.c

avr-log.c and respective macros in avr-protos.h still assume that the implementation language is C90, i.e. no variadic macros are available. This patch cleans up the code from the cumbersome old approach and uses variadic macros for avr_dump, avr_edump and avr_fdump. Ok for trunk? Johann

[PATCH PR65161]

Hi All! Here is a simple patch to not perform instruction reordering for selective scheduling since it uses interface of list scheduling defined in "sched-int.h". Bootstrap and regression testing did not show any new failures. Is it OK for trunk? ChangeLog: 2015-02-24 Yuri Rumyantsev PR tar

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 02/23/15 18:33, Chen Gang S wrote: On 2/24/15 07:14, Jeff Law wrote: On 02/23/15 16:09, Steven Bosscher wrote: Which violate the rule for matching constraints. ...and should never have worked at all... Yup. It's only been fairly recently that we started statically checking MD files in

Re: [PATCH PR65161]

On Tue, Feb 24, 2015 at 7:10 AM, Yuri Rumyantsev wrote: > Hi All! > > Here is a simple patch to not perform instruction reordering for > selective scheduling since it uses interface of list scheduling > defined in "sched-int.h". > > Bootstrap and regression testing did not show any new failures. >

[PATCH 1/3] S/390: Implement TARGET_BUILTIN_DECL

Hi, the attached patch defines the TARGET_BUILTIN_DECL macro for S/390 in order to make our target specific builtins to work with lto. I'll commit this to mainline after waiting few days for comments. Bye, -Andreas- 2015-02-24 Andreas Krebbel * config/s390/s390.c: (enum s390_built

[PATCH 2/3] S/390: Implement two new builtins for efpc and sfpc

Hi, this patch defines two new S/390 target specific macros: __builtin_s390_efpc __builtin_s390_sfpc for extracting and setting the floating point control register. I'll commit this to mainline after waiting a few days for comments. Bye, -Andreas- 2015-02-24 Andreas Krebbel * con

[PATCH 3/3] S/390: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

Hi, the attached patch implements the TARGET_ATOMIC_ASSIGN_EXPAND_FENV for S/390 fixing the c11-atomic-exec-5.c testsuite fails. I'll commit this to mainline after waiting a few days for comments. Bye, -Andreas- 2015-02-24 Andreas Krebbel * config/s390/s390.c: (s390_atomic_assign_e

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 2/24/15 23:54, Jeff Law wrote: > On 02/23/15 18:33, Chen Gang S wrote: >> OK, thanks. I shall try to finish within this month (although I am >> not quite sure whether I can finish on time). > No problem. Any contribution you can make in this area is appreciated. > OK, thanks. >> OK, thanks.

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter

Hi! On Fri, 16 Jan 2015 21:34:15 +0100, I wrote: > On Thu, 15 Jan 2015 21:20:07 +0100, I wrote: > > In r219682, I have committed to trunk our current set of OpenACC changes, > > Here is a patch to remove the __OFFLOAD_SYMBOL__ variable/formal > parameter, as discussed in

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S wrote: > > - After this patch, it can continue compiling, but can we be sure that >it always generates correct code for execution? After this patch, it should be no worse than it was--lucky. Someone is working on fixing the underlying xtensa patt

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 2/25/15 01:03, augustine.sterl...@gmail.com wrote: > On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S wrote: >> >> - After this patch, it can continue compiling, but can we be sure that >>it always generates correct code for execution? > > After this patch, it should be no worse than it was-

Commit: V850: Pass -msoft-float/-mhard-float on to the assembler

Hi Guys, I am applying the patch below to update the V850 backend so that it will pass on the -msoft-float and -mhard-float options to the assembler. This matches up with a recent update to the assembler that accepts these options. Cheers Nick gcc/ChangeLog 2015-02-24 Nick Clifton

Re: [PATCH PR65161]

On Tue, 24 Feb 2015, Yuri Rumyantsev wrote: > Hi All! > > Here is a simple patch to not perform instruction reordering for > selective scheduling since it uses interface of list scheduling > defined in "sched-int.h". As I see, the exact problem is that swap_top_of_ready_list accesses HID, so p

patch to fix PR65123

The following patch fixes the P1 PR. The details can be found on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65123 The patch was bootstrapped and tested on x86-64. There is no new test case as the PR is reported against a test in GCC testuite. Committed as rev.220946. 2015-02-24 Vladimir

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 02/24/15 10:29, Chen Gang S wrote: On 2/25/15 01:03, augustine.sterl...@gmail.com wrote: On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S wrote: - After this patch, it can continue compiling, but can we be sure that it always generates correct code for execution? After this patch, it

Re: [PATCH] PR63175 - [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

On 02/23/15 20:38, Martin Sebor wrote: On 02/22/2015 11:45 AM, David Edelsohn wrote: Does this patch really fix the problem? The PR notes that the testcase fails and code quality has regressed. Has the code generation been corrected but the testcase looks for the wrong string? Presumably the

[PATCH] Fix up LTO TARGET_OPTION_NODE handling on x86 (PR lto/64374)

Hi! As mentioned in the PR, the ix86_cmodel option is TargetSave, but during option processing is adjusted from flag_pic, which is for LTO a global option. This causes a problem when some translation unit is compiled with LTO without -fpic, and then the final link is done with -fpic - then ix86_cm

Re: [PATCH] Fix up LTO TARGET_OPTION_NODE handling on x86 (PR lto/64374)

> Hi! > > As mentioned in the PR, the ix86_cmodel option is TargetSave, > but during option processing is adjusted from flag_pic, which is > for LTO a global option. > This causes a problem when some translation unit is compiled with LTO > without -fpic, and then the final link is done with -fpic

Re: [PATCH] Fix up LTO TARGET_OPTION_NODE handling on x86 (PR lto/64374)

On Tue, Feb 24, 2015 at 08:48:19PM +0100, Jan Hubicka wrote: > Thanks, the i386 parts of the patch are OK, but I think you want to add the > reverse > transformation, too. I.e. if someone compiles with -fPIC but links without. I've only done it this way because that is what ix86_option_override_

Re: [google/gcc-4_9] Fix -ftwo-level-line-tables to output non-inlined subprogram info

ok. Dehao On Mon, Feb 23, 2015 at 11:02 AM, Cary Coutant wrote: > Minor changes to -ftwo-level-line-tables. > > This patch is for the google/gcc-4_9 branch. > > Originally, -ftwo-level-line-tables would output .subprog directives > only for inlined subprograms, and not for non-inlined ones. This

Re: [PATCH PR target/65058] AIX: missing extern decorations "[DS]" for functions and "[RW]" for variables

Am 2015-02-13 um 23:02 schrieb Michael Haubenwallner: > Hi David, > > this is the patch I'm currently testing with gcc-4.8.4 for > http://gcc.gnu.org/PR65058 There's one unused variable now - obvious patch committed. /haubi/ >From bfea87e3e9e84c995a3b678a4c234cd0187a41fe Mon Sep 17 00:00:00 200

Re: [PATCH] Fix up LTO TARGET_OPTION_NODE handling on x86 (PR lto/64374)

> On Tue, Feb 24, 2015 at 08:48:19PM +0100, Jan Hubicka wrote: > > Thanks, the i386 parts of the patch are OK, but I think you want to add the > > reverse > > transformation, too. I.e. if someone compiles with -fPIC but links without. > > I've only done it this way because that is what > ix86_op

[rl78] fix SFmode moves

SFmode moves were using 8-bit transfers instead of 16-bit. This patch copies the SImode move pattern, which expands into 16-bit moves. Since this only affects rl78, and the SImode code is well tested, I'm applying this now so it will be in gcc 5. * config/rl78/rl78-protos.h (rl78_split_

[patch] fix --enable-gather-detailed-mem-stats

I guess no one has used --enable-gather-detailed-mem-stats in a while, because it doesn't even build. Fixed with the attached patch. Tested by building cc1plus/cc1 with --enable-gather-detailed-mem-stats. Committed to mainline. commit 458f0b8665bc5adc99b5095d812089e918d62176 Author: Aldy Herna

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

Hi, On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law wrote: > > You can tackle them in any order you wish. However, I suspect fixing the > xtensa backend may be easier. I don't have any good way to test xtensa, but > something like the attached patch for the xtensa port should be sufficient. I can co

[patch] PR debug/58315: Mark cdtor_label as artificial

Technically this doesn't solve the issue in the PR, not by a long shot. Alex has a patch for that already. However, this is another problem I found while debugging this PR. I saw a few of these useless debug statements in the gimple dumps, which couldn't be removed by DSE/DCE because the la

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 02/24/15 15:05, Max Filippov wrote: Hi, On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law wrote: You can tackle them in any order you wish. However, I suspect fixing the xtensa backend may be easier. I don't have any good way to test xtensa, but something like the attached patch for the xtensa p

Re: [PATCH] Fix up LTO TARGET_OPTION_NODE handling on x86 (PR lto/64374)

On Tue, Feb 24, 2015 at 10:21:23PM +0100, Jan Hubicka wrote: > > On Tue, Feb 24, 2015 at 08:48:19PM +0100, Jan Hubicka wrote: > > > Thanks, the i386 parts of the patch are OK, but I think you want to add > > > the reverse > > > transformation, too. I.e. if someone compiles with -fPIC but links >

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On Tue, Feb 24, 2015 at 2:05 PM, Max Filippov wrote: > Hi, > > On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law wrote: >> >> You can tackle them in any order you wish. However, I suspect fixing the >> xtensa backend may be easier. I don't have any good way to test xtensa, but >> something like the att

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 2/25/15 03:22, Jeff Law wrote: > On 02/24/15 10:29, Chen Gang S wrote: >> >> So for me, I shall let genrecog report error instead of warning when it >> find this issue, next. > Yes, I think an error would be appropriate here. That way nobody has to > debug same issue you just did in find_reloa

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On 2/25/15 07:36, augustine.sterl...@gmail.com wrote: > On Tue, Feb 24, 2015 at 2:05 PM, Max Filippov wrote: >> Hi, >> >> On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law wrote: >>> >>> You can tackle them in any order you wish. However, I suspect fixing the >>> xtensa backend may be easier. I don't h

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

Sterling, On Wed, Feb 25, 2015 at 2:36 AM, augustine.sterl...@gmail.com wrote: > On Tue, Feb 24, 2015 at 2:05 PM, Max Filippov wrote: >> On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law wrote: >>> You can tackle them in any order you wish. However, I suspect fixing the >>> xtensa backend may be easie

Re: [doc, rfa] (v2) improve x86 transactional memory intrinsics section

On 02/24/2015 03:01 AM, Patrick Marlier wrote: On 02/24/2015 01:51 AM, Sandra Loosemore wrote: [snip] Revised patch attached. OK to commit this version? -Sandra _XBEGIN_EXPLICIT does not exist right? maybe 0 is better to avoid confusion? or ~_XBEGIN_STARTED? Argh, I meant to change _XBEGIN

Re: [PATCH] Fix up LTO TARGET_OPTION_NODE handling on x86 (PR lto/64374)

On 02/24/15 15:56, Jakub Jelinek wrote: On Tue, Feb 24, 2015 at 10:21:23PM +0100, Jan Hubicka wrote: On Tue, Feb 24, 2015 at 08:48:19PM +0100, Jan Hubicka wrote: Thanks, the i386 parts of the patch are OK, but I think you want to add the reverse transformation, too. I.e. if someone compiles w

Re: [PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

On 02/17/15 08:31, Marcus Shawcroft wrote: On 9 February 2015 at 05:41, Andrew Pinski wrote: The problem here is that we get a symbol_ref which is SImode but for the sibcall patterns we only match symbol_refs which use DImode. I added a new testcase that tests the non-value sibcall pattern too

Re: [PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

On Tue, Feb 24, 2015 at 9:18 PM, Jeff Law wrote: > On 02/17/15 08:31, Marcus Shawcroft wrote: >> >> On 9 February 2015 at 05:41, Andrew Pinski wrote: >>> >>> The problem here is that we get a symbol_ref which is SImode but for >>> the sibcall patterns we only match symbol_refs which use DImode.

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

On Tue, Feb 24, 2015 at 4:45 PM, Max Filippov wrote: > > Sterling, > > I was referring Jeff's patch, do you say that his patch is not the proper > fix? No, I was thinking of Chen's patch. Jeff's patch is the right one. Jeff, your patch is OK for xtensa. Do you mind checking it in?

Re: [PATCH, wwwdoc] Describe the changes of NDS32 port in GCC-5.0.

2015-02-15 10:33 GMT+08:00 Chung-Ju Wu : > Hi, all, > > There are some major changes on NDS32 port in GCC-5.0: > https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00316.html > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00992.html > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00993.html > > T

Patch ping

On Wed, Feb 18, 2015 at 11:00:35AM +0100, Jakub Jelinek wrote: > On Tue, Feb 17, 2015 at 11:00:14AM +0100, Richard Biener wrote: > > I'm just looking for a way to make this less of a hack (and the LTO IL > > less target dependent). Not for GCC 5 for which something like your > > patch is probably