Re: Fix PR ipa/64693

On 01/23/2015 10:26 PM, Jan Hubicka wrote: Hello. Following patch is a fix for PR ipa/64693, where ICF merges a pair of functions that somehow take a references to a different functions. Unfortunately, such function pointer can be used for function comparison that can break an executable. Test

[PATCHv2][wwwdocs] Mention -freport-bug in release notes

> On 01/16/2015 12:18 PM, Yury Gribov wrote: This is a wwwdocs patch to changes.html to announce -freport-bug flag. Ok to commit? Hi all, Second version of patch with updates from Gerald Pfeifer. Ok to commit? -Y ? the Index: htdocs/gcc-5/changes.html ===

RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro

On Thu, 22 Jan 2015, Matthew Fortune wrote: > > This is a follow-up to a change [1] in glibc. It fixes the issue [2] > > when jal can not reach a target in different region. Is it not a problem that can be solved with rearranging the order of sections in output? > > It has been tested with Deja

Re: [ARM] Wire up the new scheduler description for the ARM Cortex-A57 processor

On Mon, Jan 19, 2015 at 5:44 PM, James Greenhalgh wrote: > > On Fri, Jan 16, 2015 at 11:14:42AM +, Ramana Radhakrishnan wrote: >> >> >> On 16/01/15 10:20, Marcus Shawcroft wrote: >> > On 15 January 2015 at 09:50, James Greenhalgh >> > wrote: >> > >> >> 2015-01-15 James Greenhalgh >> >> >>

[Patch][wwwdocs]Deprecate the ARM TPCS related options in gcc 5.0

Hi there, This patch intends to update gcc 5.0 change.html to deprecate TPCS related options because TPCS is obsoleted per the ABI document at http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf. Is it OK? BR, Terry Index: htdocs/gcc-5/changes.html ===

Re: [debug-early] C++ clones and limbo DIEs

On Fri, Jan 23, 2015 at 7:45 PM, Aldy Hernandez wrote: > Phew... ok, I'm a little stuck here with the interaction between dwarf2out > and LTO, and I'm hoping y'all can shed some light. Please bear with me > through the verbosity, it gets clearer (I hope) near the end. > > > On 01/16/2015 12:45 PM

Re: PATCH: PR bootstrap/64754: [5 Regression] bootstrap failed with --with-build-config=bootstrap-lto

On Fri, Jan 23, 2015 at 11:43 PM, H.J. Lu wrote: > Hi, > > r218005 added: > > + /* ??? Store somewhere better. */ > + unsigned short ruid; > > > + if (restrict_var->ruid == 0) > + restrict_var->ruid = ++last_ruid; > + MR_DEPENDENCE_CLIQUE (ref) = clique; > + M

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

> While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs, > some targets like i?86/x86_64 choose to populate it again during machine > reorg and some target don't free it at the end of machine reorg. > This patch updates cleanup_barrier pass, so that it adjusts basic block > boundaries a

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote: > > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs, > > some targets like i?86/x86_64 choose to populate it again during machine > > reorg and some target don't free it at the end of machine reorg. > > This patch upda

Re: [RFC] PR64703, glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

On Sat, Jan 24, 2015 at 12:23 AM, Alan Modra wrote: > How does this look as a potential fix for PR64703? I haven't made > many forays into gimple code, so even though this patch passes > bootstrap and regression testing on powerpc64-linux it's quite > possible this is the wrong place to change.

Re: [4.8] backport PR57748 fixes (wrong-code and ICE regression)

On Sun, Jan 25, 2015 at 3:25 PM, Mikael Pettersson wrote: > This backports the fixes for PR middle-end/57748, a wrong-code and ICE > regression, to the 4.8 branch. > > Tested extensively on x86_64, powerpc64, sparc64, ARMv{5,7}, and m68k. > > Ok for 4.8? Ok - I assume you have checked that all re

Re: [PATCH] Fix half of PR63439

> For the second half we really need to fix SPARC to be a vect64 > target (the testcase is vectorized with v8qi). Yes, that makes sense in conjunction with the options used for vectorization. -- Eric Botcazou

Re: [PATCH] Fix half of PR63439

On Mon, 26 Jan 2015, Eric Botcazou wrote: > > For the second half we really need to fix SPARC to be a vect64 > > target (the testcase is vectorized with v8qi). > > Yes, that makes sense in conjunction with the options used for vectorization. As I can't test sparc can you or rainer do the change

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On Mon, Jan 26, 2015 at 10:11:00AM +0100, Jakub Jelinek wrote: > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote: > > > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs, > > > some targets like i?86/x86_64 choose to populate it again during machine > > > reorg and som

Re: [RFC] POWER8 default for PPC64LE

On Sat, Jan 17, 2015 at 09:18:14PM -0500, David Edelsohn wrote: > Thanks, David > > * config/rs6000/default64.h: Include rs6000-cpus.def. > (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). > * config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7. >

[PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

Hi, The GCC combine pass combines the insns even though they contain volatile registers. This doesn't make sence. The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 shows the expected asm command "mov r1, r1" is not generated."r1" is defined as a volatile register, and the

Fix PR testsuite/64712

It's an uninitialized variable in a testcase I added back in 2008 that had been silent until we started to generate overflow checks by default. Tested on x86_64-suse-linux, applied on the mainline and 4.9 branch. 2015-01-26 Eric Botcazou PR testsuite/64712 * gnat.dg/unchecke

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Mon, Jan 26, 2015 at 1:55 AM, Hale Wang wrote: > Hi, > > The GCC combine pass combines the insns even though they contain volatile > registers. This doesn't make sence. > > The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 > shows the expected asm command "mov r1, r1" i

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote: > The GCC combine pass combines the insns even though they contain volatile > registers. This doesn't make sence. > > The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 > shows the expected asm command "mov r1, r1"

Re: [PATCH] Fix half of PR63439

Richard Biener writes: > On Mon, 26 Jan 2015, Eric Botcazou wrote: > >> > For the second half we really need to fix SPARC to be a vect64 >> > target (the testcase is vectorized with v8qi). >> >> Yes, that makes sense in conjunction with the options used for vectorization. > > As I can't test spa

Re: [PATCH] Fix half of PR63439

> Here's what I had in my local tree during last weekend's bootstraps: it > worked fine indeed. > > Rainer > > > 2015-01-23 Rainer Orth > > * lib/target-supports.exp (check_effective_target_vect64): Add > sparc*-*-*. Fine with me then, thanks. -- Eric Botcazou

Re: [wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html

On Sunday 2015-01-25 23:10, Ed Smith-Rowland wrote: Here is a new patch (no change from previous).. If you could apply it that would be great. Sure thing. Applied right away. Gerald

Re: [patch] [C++14] Implement N3657: heterogeneous lookup in associative containers.

On 24/01/15 22:46 +, Jonathan Wakely wrote: On 24/01/15 23:03 +0100, François Dumont wrote: types. I am also surprised that it is not using enable_if, IMHO it makes the code clearer. It doesn't work though. @@ -1155,9 +1150,8 @@ return _S_iter(__y); } - template::

Re: [Patch][wwwdocs]Deprecate the ARM TPCS related options in gcc 5.0

On Monday 2015-01-26 16:47, Terry Guo wrote: > This patch intends to update gcc 5.0 change.html to deprecate TPCS > related options because TPCS is obsoleted per the ABI document at > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf. > Is it OK? >From a language pers

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote: > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote: >> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs, >> > some targets like i?86/x86_64 choose to populate it again during machine >> > reorg and some target do

Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

On Friday 2015-01-23 17:44, David Malcolm wrote: > The following patch builds and installs the JIT documentation for > the website (just HTML for now). > > It's tricky to test (I don't have a copy of /www/gcc/bin/preprocess), > but I was able to use this to generate sane-looking documentation, > b

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On Mon, Jan 26, 2015 at 12:35:30PM +0100, Steven Bosscher wrote: > On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote: > > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote: > >> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs, > >> > some targets like i?86/x86_64

[PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

Hi, Here is a patch to clean up a large number of reported failures when a toolchain is configured with --with-nan=2008 for mips*-linux-gnu triplet and clean up a failures for mips-img-linux-gnu where nan2008 is set by the default. In the former case, regression involves testing e.g. -mips4 with

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

On 25/01/15 21:05, Christophe Lyon wrote: On 23 January 2015 at 14:44, Christophe Lyon wrote: On 23 January 2015 at 12:42, Christophe Lyon wrote: On 23 January 2015 at 11:18, Tejas Belagod wrote: On 22/01/15 21:31, Christophe Lyon wrote: On 22 January 2015 at 16:22, Tejas Belagod wrote:

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On Mon, Jan 26, 2015 at 12:47 PM, Jakub Jelinek wrote: > On Mon, Jan 26, 2015 at 12:35:30PM +0100, Steven Bosscher wrote: >> On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote: >> > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote: >> >> > While the cleanup_barriers runs after clea

Re: [Patch, Fortran] PR63861 - fix OpenMP/ACC's gfc_has_alloc_comps

Dear all, I wrote: > - while (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type)) > + if (GFC_DESCRIPTOR_TYPE_P (type) > + || (GFC_ARRAY_TYPE_P (type) && GFC_TYPE_ARRAY_RANK (type) == 0)) That's nonsense: It should be "!= 0". If one has an array type which has a rank > 0 (i.e. it is n

Re: [Patch, AArch64, Obvious] Fix PR64231.

On 23/01/15 17:15, Jakub Jelinek wrote: On Fri, Jan 23, 2015 at 08:48:43AM -0800, Mike Stump wrote: On Jan 23, 2015, at 3:03 AM, Tejas Belagod wrote: This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi and as proposed by Jakub. Kinda crappy code. The macro to use here

Re: [Patch, Fortran] PR63861 - fix OpenMP/ACC's gfc_has_alloc_comps

On Mon, Jan 26, 2015 at 01:14:39PM +0100, Tobias Burnus wrote: > The question is why I didn't see the nonsense in the test suite. It > doesn't seem to be tested for in gcc/testsuite/gfortran.dg/; it might be > tested in libgomp/testsuite/ - I don't recall whether I retested after > the (incomplete)

RE: [PATCH, RFC] LRA subreg handling

> > Here we do have a hard register, but it isn't valid to form the subreg > > on that hard register. Reload had to cope with that case too. > > > > Since the subreg on the original hard register is invalid, we can't use > > it to decide whether the intention was to write to only a part of the > >

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

On 26 January 2015 at 13:10, Tejas Belagod wrote: > On 25/01/15 21:05, Christophe Lyon wrote: >> >> On 23 January 2015 at 14:44, Christophe Lyon >> wrote: >>> >>> On 23 January 2015 at 12:42, Christophe Lyon >>> wrote: On 23 January 2015 at 11:18, Tejas Belagod wrote: > >

Re: [PATCH, i386] Remove EBX usage from asm code

Uros Bizjak writes: >> Yes, the name is better. It would also fit with Solaris. > > Bootstrap and regression test was OK. > > Committed with following ChangeLogs: > > libgcc/ChangeLog: > > 2015-01-23 Uros Bizjak > > * config/i386/elf-lib.h: New file. > (CRT_GET_RFIB_DATA): Move definit

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On Mon, Jan 26, 2015 at 01:11:01PM +0100, Richard Biener wrote: > > I agree that freeing the cfg and immediately computing it again doesn't make > > sense, but I just don't see this patch being incompatible with that. > > I wonder if handing over pass pipeline control to targets at > machine_reorg

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

Hi! Sorry for the late answer -- I've been on sick leave, and just now returning to work. Julian, would you please have a look at the following issues? > > > In r219682, I have committed to trunk our current set of OpenACC changes, > > > which we had prepared on gomp-4_0-branch. Thanks to every

Re: [PATCH][AARCH64]Fix TLS local exec model addressing code generation inconsistency.

On 20 January 2015 at 14:57, Renlin Li wrote: > gcc/ChangeLog: > > 2015-01-20 Renlin Li > > * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Correct > the comment. > * config/aarch64/aarch64.md (tlsle_small_): Add left shift 12-bit > for higher part. OK /Marcus

Re: [[ARM/AArch64][testsuite] 13/36] Add vmla_n and vmls_n tests.

On 20 January 2015 at 15:28, Christophe Lyon wrote: > On 16 January 2015 at 17:24, Tejas Belagod wrote: >>> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, >>> + 0x33, 0x33, 0x33, 0x33 }; >>> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x,

Re: [[ARM/AArch64][testsuite] 09/36] Add vsubhn, vraddhn and vrsubhn tests. Split vaddhn.c into vXXXhn.inc and vaddhn.c to share code with other new tests.

On 20 January 2015 at 15:24, Christophe Lyon wrote: > Here is an updated version, where I have removed a few more useless > variables than you noticed: the [u]int64x1 as well as the 128 bits > ones. OK /Marcus

[gomp4] Merge trunk r219681 (2015-01-15) into gomp-4_0-branch

Hi! In r220110, I have committed a merge from trunk r219681 (2015-01-15) into gomp-4_0-branch. This is the last trunk revision before the »Merge current set of OpenACC changes from gomp-4_0-branch« commit. Grüße, Thomas pgpFT6G9VIhcG.pgp Description: PGP signature

Re: [[ARM/AArch64][testsuite] 17/36] Add vpadd, vpmax and vpmin tests.

On 20 January 2015 at 15:30, Christophe Lyon wrote: + /* Apply a unary operator named INSN_NAME. */ >>> >>> >>> Unary op? >>> >> Hmm cut & paste issue. Thanks >> > Here is an updated versoin, also renaming VPADD into VPXXX, since it's > in a template. Updated version is OK /Marcus

Re: [[ARM/AArch64][testsuite] 21/36] Add vmovl tests.

On 20 January 2015 at 15:32, Christophe Lyon wrote: >> No poly or float for vmovl. >> > Here is a new version, with more cleanup: only 16x8, 32x4 and 64x2 > variants are necessary. This version is OK /Marcus

Re: [[ARM/AArch64][testsuite] 28/36] Add vmnv tests.

On 20 January 2015 at 15:33, Christophe Lyon wrote: > On 16 January 2015 at 19:27, Tejas Belagod wrote: >>> +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x, 0x, 0x, 0x, >>> +0x, 0x, 0x, 0x }; >>> +VECT_VAR_DECL(expected,hfloat,3

Re: [[ARM/AArch64][testsuite] 29/36] Add vpadal tests.

On 20 January 2015 at 15:34, Christophe Lyon wrote: > On 16 January 2015 at 19:29, Tejas Belagod wrote: >>> +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, >>> +0x33, 0x33, 0x33, 0x33, >>> +0x33, 0x3

Re: [[ARM/AArch64][testsuite] 30/36] Add vpaddl tests.

On 20 January 2015 at 15:35, Christophe Lyon wrote: >> Hmm changed my mind: vpaddl takes only one vector as input, although >> it does add 2 vector elements. >> > Here is an updated version, removing poly, float and int8 variants. OK /Marcus

RE: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

> -Original Message- > From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: Monday, January 26, 2015 6:03 PM > To: Hale Wang > Cc: GCC Patches > Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a > volatile register is contained. > > > I think it is allowed to t

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

FX writes: >> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB >> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] >> This means that the PIC library is being built with non-pic relocs. > > config

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 26 Jan 2015, at 14:13, Rainer Orth wrote: > FX writes: > >>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB >>> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] >>> This means that the PIC

Re: [COMMITTED] Merge libffi with upstream

"H.J. Lu" writes: > On Fri, Jan 16, 2015 at 5:38 AM, Rainer Orth > wrote: >> Jakub Jelinek writes: >> @@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl set targetabis { "" } if [string match $compiler_vendor "gnu"] { -if [istarget "i?86-*-*"

Re: [patch, libbacktrace/libsanitizer/libquadmath/libcilkrts] fix multilib builds

Matthias Klose wrote: > >> However for the libbacktrace and the libsanitizer builds, the > >> AM_ENABLE_MULTILIB > >> macro is included way too late. Scan the generated configure file for > >> "cross_compiling" and see that the above snippet is added after the failing > >> checks. The fix seems t

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

On 26 Jan 14:44, Thomas Schwinge wrote: > On 17 Jan 02:16, Ilya Verbin wrote: > > Such things are not covered by the > > testsuite, that's why you missed this issue. Here is a simple testcase: > >

[PATCH] Fix PR64764

The following fixes PR64764. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2015-01-26 Richard Biener PR middle-end/64764 * tree-ssa-uninit.c (is_pred_expr_subset_of): Handle combining two BIT_AND_EXPR predicates. * gcc.dg/un

[PATCH][1/2] Improve array bound warnings

I've looked at PR64277 and noticed we haven't been applying TLC to the array-bound warning code for a long time. I noticed we don't warn for out-of-bound return &a[11]; - fixed with the simplifications. I also noticed that anti-range handling has off-by-one errors (well, always applied ignore_off

Re: [PATCH][1/2] Improve array bound warnings

On Mon, Jan 26, 2015 at 03:57:20PM +0100, Richard Biener wrote: > > I've looked at PR64277 and noticed we haven't been applying TLC to the > array-bound warning code for a long time. I noticed we don't > warn for out-of-bound return &a[11]; - fixed with the simplifications. > I also noticed that

[PATCH][2/2] Improve array-bound warnings and VRP

This is the 2nd thing I came up with after looking at PR64277. VRP does a poor job computing value-ranges of unrolled loop IVs thus a very simple thing to do is to factor in previous VRP results by intersecting what VRP2 computes with recorded SSA name range infos (that also makes errors in those

Re: [PATCH][2/2] Improve array-bound warnings and VRP

On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote: > > This is the 2nd thing I came up with after looking at PR64277. > VRP does a poor job computing value-ranges of unrolled loop IVs > thus a very simple thing to do is to factor in previous VRP results > by intersecting what VRP2 com

Re: [PATCH][2/2] Improve array-bound warnings and VRP

On Mon, 26 Jan 2015, Jakub Jelinek wrote: > On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote: > > > > This is the 2nd thing I came up with after looking at PR64277. > > VRP does a poor job computing value-ranges of unrolled loop IVs > > thus a very simple thing to do is to factor in

Re: [PATCH][2/2] Improve array-bound warnings and VRP

On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote: > > > Ok for trunk? Or should I delay this to GCC 6? > > > > Does this work even without the other patch? > > Yes, I've actually developed 2/2 first. The other patch only ever > emits more warnings... Then it probably should be ok

Re: [PATCH][2/2] Improve array-bound warnings and VRP

On Mon, 26 Jan 2015, Jakub Jelinek wrote: > On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote: > > > > Ok for trunk? Or should I delay this to GCC 6? > > > > > > Does this work even without the other patch? > > > > Yes, I've actually developed 2/2 first. The other patch only ever

Re: [PATCH][2/2] Improve array-bound warnings and VRP

On Mon, Jan 26, 2015 at 04:28:02PM +0100, Richard Biener wrote: > Sure - but for unrolling > > int a[2]; > for (int i = 0; i < 5; i++) > a[i] = i; > > I'd like to see warnings and we only warn if we unroll this because > the value-range of i includes indexes that are valid. Don't we warn her

Re: [RFC] POWER8 default for PPC64LE

On Mon, Jan 26, 2015 at 4:46 AM, Jakub Jelinek wrote: > On Sat, Jan 17, 2015 at 09:18:14PM -0500, David Edelsohn wrote: >> Thanks, David >> >> * config/rs6000/default64.h: Include rs6000-cpus.def. >> (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). >> * config/rs6000

Retracted: [PATCH 0/4][ARM Intrinsics][RFTesting] Add missing float16x8_t type, and float16x[48] intrinsics

There are still bugs in these patches, they should not go in. Hope to have something ready, with tests, in the next stage 1. Cheers, Alan Alan Lawrence wrote: These add all the V[48]HFmode insns and corresponding intrinsics for ARM. Depends on the two patches at https://gcc.gnu.org/ml/gcc-pat

Re: [Patch, Fortran, OOP] PR 64230: [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component

2015-01-24 18:18 GMT+01:00 Tobias Burnus : >> this is a second patch dealing with finalization-related regressions, >> [...] >> This patch fixes an invalid memory reference inside the finalizer >> routine (at runtime), which apparently was caused by dereferencing a >> pointer without checking if it

RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

> -Original Message- > From: Robert Suchanek [mailto:robert.sucha...@imgtec.com] > Sent: Monday, January 26, 2015 6:48 AM > To: gcc-patches@gcc.gnu.org > Cc: Matthew Fortune; Moore, Catherine > Subject: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain > > Hi, > > Here is a patc

[PATCH RFC] Running auto-vectorization tests multiple times

Hi, I'm trying to lift the restriction to run auto-vectorization tests more than once and would like to check if I'm going in the right direction. I attached a draft patch. Currently, auto-vectorization tests are enabled by a call to check_vect_support_and_set_flags procedure and if there is sup

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote: > The GCC combine pass combines the insns even though they contain volatile > registers. "Local register variable", "register asm". > This doesn't make sence. On the contrary, it makes a lot of sense: you *want* insns 41+43 to be combine

RE: [PATCH][4.9] PR 64569 - Backport support for MIPS binutils 2.25

> This is a minimal backport of features added to GCC 5 to enable use > of binutils 2.25 with GCC 4.9 for MIPS soft-float builds. Further > details in the PR: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64569 > > The commits which are being backported are listed below (the last > one is post

[PATCH, CHKP] Fix bounds return check for calls

Hi, Currently chkp_call_returns_bounds_p works incorrectly for bounds narrowing. Also it doesn't reflect recent changes in calls instrumentation. This patch fixes the problem. Bootstrapped and checked on x86_64-unknown-linux-gnu. OK for trunk? Thanks, Ilya -- 2015-01-26 Ilya Enkovich

Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

On Mon, 2015-01-26 at 12:43 +0100, Gerald Pfeifer wrote: > On Friday 2015-01-23 17:44, David Malcolm wrote: > > The following patch builds and installs the JIT documentation for > > the website (just HTML for now). > > > > It's tricky to test (I don't have a copy of /www/gcc/bin/preprocess), > > b

[PATCH][AArch64] Remove an unused reload hook.

Hello, The LEGITIMIZE_RELOAD_ADDRESS macro is only needed for reload. Since the Aarch64 backend no longer supports reload, this macro is not needed and this patch removes it. Tested aarch64-none-linux-gnu with gcc-check. No new failures. Ok for trunk? Matthew gcc/ 2015-01-26 Matthew Wahab

RFA: RL78: Minor prologue and epilogue enhancements

Hi DJ, The patch below contains two minor enhancements for the RL78 prologue and epilogue code. The first is for when a large amount of local stack space needs to be allocated. Rather than generating a long sequence of SUB SP, # instructions, the patched codes moves SP into AX, perform

RFA: RL78: Add assembler versions of some libgcc functions.

Hi DJ, The attached patch provides some enhancements to libgcc for the RL78. It includes faster and smaller versions of the bit counting and simple floating point functions, and a version of the integer multiply support function designed to work on the G10. Tested on an rl78-elf toolcha

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

> > The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 > > shows the expected asm command "mov r1, r1" is not generated."r1" is defined > > as a volatile register, and there are three insns related to r1: > > > > (insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak wrote: > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak wrote: >> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen >> wrote: >>> On Saturday 24 January 2015, Uros Bizjak wrote: On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak wrote: > Hel

Re: [COMMITTED] Merge libffi with upstream

On 01/26/2015 06:19 AM, Rainer Orth wrote: > 2015-01-16 Rainer Orth > > * testsuite/lib/libffi.exp: Load target-supports.exp. > (run-many-tests): Only set targetabis for ia32. Ok. r~

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Mon, Jan 26, 2015 at 10:04 AM, H.J. Lu wrote: > On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak wrote: >> On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak wrote: >>> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen >>> wrote: On Saturday 24 January 2015, Uros Bizjak wrote: > On Mon

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: > On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak wrote: > > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak wrote: > >> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen > >> > >> wrote: > >>> On Saturday 24 January 2015, Uros Bizjak wrote: > On

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen wrote: > On Monday 26 January 2015, H.J. Lu wrote: >> On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak wrote: >> > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak wrote: >> >> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen >> >> >> >> w

Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

On Jan 26, 2015, at 3:43 AM, Gerald Pfeifer wrote: >> +# Again, the jit is a special case, with nested subdirectories >> +# below "jit", and with some non-HTML files (.png images from us, >> +# plus .js and .css supplied by sphinx). >> +for file in $(find jit \ >> +-name "*.html" -

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

On 01/26/15 06:34, Jakub Jelinek wrote: On Mon, Jan 26, 2015 at 01:11:01PM +0100, Richard Biener wrote: I agree that freeing the cfg and immediately computing it again doesn't make sense, but I just don't see this patch being incompatible with that. I wonder if handing over pass pipeline contr

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, you wrote: > On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen > > wrote: > > On Monday 26 January 2015, H.J. Lu wrote: > >> On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak wrote: > >> > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak wrote: > >> >> On Sat, Jan 24, 2

[PATCH, i386]: Fix PR64795, too many memor references for 'lea'

Hello! Attached patch tightens the condition for TYPE_LEA instructions. 2015-01-26 Uros Bizjak PR target/64795 * config/i386/i386.md (*movdi_internal): Also check operand 0 to determine TYPE_LEA operand. (*movsi_internal): Ditto. Bootstrapped and regression tested on x86_

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen wrote: >> >> >> >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part >> >> >> in gcc/config/i386/i386.c, and mv17.C test didn't compile at all due >> >> >> to missing parenthesis). >> >> > >> >> > ... and now with comm

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote: > diff --git a/gcc/combine.c b/gcc/combine.c > index 5c763b4..cf48666 100644 > --- a/gcc/combine.c > +++ b/gcc/combine.c > @@ -2004,6 +2004,13 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn > *pred ATTRIBUTE_UNUSED, >

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: > On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen > > wrote: > >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu > >> >> >> part in gcc/config/i386/i386.c, and mv17.C test didn't compile at > >> >> >> all due to missing paren

Re: [doc, committed] copy-edit documentation for -fisolate-erroneous-paths-*

On Mon, 26 Jan 2015, Gerald Pfeifer wrote: > On Saturday 2015-01-03 17:59, Sandra Loosemore wrote: > > * most places in the manual use "null" or more rarely "@code{NULL}" > > rather than "NULL" > > So, should this be documented in gcc.gnu.org/codingconventions.html? Expanding / revising where i

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen wrote: > On Monday 26 January 2015, H.J. Lu wrote: >> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen >> >> wrote: >> >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu >> >> >> >> part in gcc/config/i386/i386.c,

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Mon, Jan 26, 2015 at 8:15 PM, H.J. Lu wrote: > On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen > wrote: >> On Monday 26 January 2015, H.J. Lu wrote: >>> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen >>> >>> wrote: >>> >> >> >> Committed with a bunch of fixes (e.g. missing fo

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: > On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen > > wrote: > > On Monday 26 January 2015, H.J. Lu wrote: > >> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen > >> > >> wrote: > >> >> >> >> Committed with a bunch of fixes (e.g. missing

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Mon, Jan 26, 2015 at 8:22 PM, Allan Sandfeld Jensen wrote: >> > I guess since they represent the exact same effective ISA, they would >> > have equal priority, so that it would likely chose whatever comes last. >> >> I have no strong opinion on this. But this is a user visible compiler >> beh

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

---On Mon, Jan 26, 2015 at 11:25 AM, Uros Bizjak wrote: > On Mon, Jan 26, 2015 at 8:22 PM, Allan Sandfeld Jensen > wrote: > >>> > I guess since they represent the exact same effective ISA, they would >>> > have equal priority, so that it would likely chose whatever comes last. >>> >>> I have no s

Re: #pragma GCC unroll support

Jason, Joseph, this is stage 1 material (unless someone else wants to try and make an argument for it sooner), if you could review the parser (frontend) bits, that would be wonderful. The mid-end, and back-end bits Richard was reviewing. On Jan 8, 2015, at 4:45 AM, Richard Biener wrote: > But

Re: #pragma GCC unroll support

I missed including the documentation patch in the last set. :-( Here it is: Index: extend.texi === --- extend.texi (revision 220084) +++ extend.texi (working copy) @@ -17881,6 +17881,17 @@ void ignore_vec_dep (int *a, int k, int @}

Re: RFA: patch to fix a bad code generation for PR64110 -- new constraints addition

On 01/24/15 04:29, Richard Sandiford wrote: Yeah. I expect in practice most people who used "?" and "!" attached them to a particular operand for a reason. From a quick scan through 386.exp it looked like almost all uses would either want this behaviour or wouldn't care. An interesting except

[PATCH, committed] PR jit/64708: remove libgccjit.so from COMPILERS

libgccjit.so is installed by jit/Make-lang.in's jit.install-common, into $(DESTDIR)/$(libdir). jit/config-lang.in listed "compilers" as "libgccjit.so", leading to the makefile variable COMPILERS containing libgccjit.so. This in turn led to gcc/Makefile's install-common installing a redundant copy

Re: [4.8] backport PR57748 fixes (wrong-code and ICE regression)

Richard Biener writes: > On Sun, Jan 25, 2015 at 3:25 PM, Mikael Pettersson > wrote: > > This backports the fixes for PR middle-end/57748, a wrong-code and ICE > > regression, to the 4.8 branch. > > > > Tested extensively on x86_64, powerpc64, sparc64, ARMv{5,7}, and m68k. > > > > Ok for

[Patch, Fortran, committed] Minor follow up patch for the recent io.c change

This patch replaces the hard-wired -1 of patch https://gcc.gnu.org/ml/fortran/2015-01/msg00046.html by the later-added #define. Committed as obvious as Rev. 220135. Tobias Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog

[C PATCH] Fix ICE with invalid function call (PR c/64778)

Hi! On the following testcase we ICE, because we end up with a CALL_EXPR with error_mark_node argument and gimplification can't cope with that. Normally, if one or more arguments are error_mark_node we return -1 and drop the whole call, but if we also report too many arguments, we failed to do so

  1   2   >