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

Updated patch below. Jakub Jelinek wrote: 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 whe

[PATCH] Fix for PR64741 (UBSan/ASan integration)

Hi all, As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64741 , ASan may currently report false positives for UBSan internal variables due to their incomplete type information. This patch fixes this. Bootstrapped and regtested on Linux x64. Ok to commit? -Y commit cf083510ece7b7

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

> -Original Message- > From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] > Sent: Tuesday, January 27, 2015 12:52 PM > To: Hale Wang > Cc: GCC Patches > Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a > volatile register is contained. > > On Tue, Jan 2

RE: [PATCH 2/3, ARM, libgcc, ping6] Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc

> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > > > > > Secondly, in a shared library environment you need to ensure that > these > > names remain private to the instance linked into the library, so that > > you don't end up going t

RE: [PATCH, ARM, ping1] Fix PR64453: live high register not saved in function prolog with -Os

Ping? > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Friday, January 23, 2015 4:23 PM > To: Ramana Radhakrishnan > Cc: gcc-patches > Subject: RE: [PATCH, ARM] Fix PR64453: live high register not s

RE: [PATCH 2/3, ARM, libgcc, ping6] Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc

> From: Richard Earnshaw > Sent: Wednesday, January 14, 2015 10:49 PM > > Sorry, not ok. These symbols pollute the global namespace, yet do not > use reserved names. Are you referring to the Lml_* symbols? They appear with local binding in my environment which is expected since the single float

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

Dear Janus, I know somewhat less than nothing about such matters. I suggest that you contact the authors of the testcases that use libubsan that you mention. Sorry Paul On 26 January 2015 at 22:20, Janus Weil wrote: > Hi Paul, > >> The testcase has a dependence on libubsan.so, which my LD_LIBR

Re: [PATCH][RFA][PR target/15184] Partial fix for direct byte access on x86

On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote: > The second change we need is an additional simplification. > > If we have > (subreg:M1 (zero_extend:M2 (x)) > > Where M1 > M2 and both are scalar integer modes. It's advantageous to > strip the SUBREG and instead have a wider extension

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

On Tue, Jan 27, 2015 at 11:49:55AM +0800, Hale Wang wrote: Hi Hale, > > > diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c > > > b/gcc/testsuite/gcc.target/arm/pr46164.c > > > new file mode 100644 > > > index 000..ad3b7cb > > > --- /dev/null > > > +++ b/gcc/testsuite/gcc.target/arm/pr46164

Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

> +/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */ > + > +# if GCC_VERSION >= 4004 > +#pragma GCC diagnostic push > +#pragma GCC diagnostic ignored "-Wstrict-overflow" > +#endif > + #pragma diagnostic ignored was added in 4.4 but #pragma diagnostic push/pop wasn't add

Add a blurb about __has_cpp_attribute and __has_attribute to gcc-5/changes.

Gerald, Could I get a hand on checking in this last addition? -m 'Add a blurb to htdocs/gcc-5/changes.html to explain the __has_cpp_attribute and the equivalent __has_attribute macros.' Thanks, Ed Sorry, I forgot to add gcc-patches. Index: htdocs/gcc-5/changes.html

[rl78] avoid move-elim on volatile mems

See $subj. Committed. * config/rl78/rl78.c (move_elim_pass): Don't optimize away volatile memory references. Index: config/rl78/rl78.c === --- config/rl78/rl78.c (revision 220150) +++ config/rl78/rl78.c (working c

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

> -Original Message- > From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] > Sent: Tuesday, January 27, 2015 3:07 AM > To: Hale Wang > Cc: GCC Patches > Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a > volatile register is contained. > > On Mon, Jan 26,

[PATCH][RFA][PR target/15184] Partial fix for direct byte access on x86

Segher: I know you're not officially noted as a maintainer or reviewer for combine.c, but that's something I'd like to change if you're interested in a larger role. In the mean time, any feedback you have would be appreciated. So the issue mentioned in the BZ is that fairly obvious code sequ

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 12:02 PM, H.J. Lu wrote: On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote: Ping? Any thoughts? x86 for the family and x86-32/x86-64 for the 2 architectures? Works for me. [redirecting from gcc@ to gcc-patches@] OK, here is a patch that attempts to implement that conv

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

On Mon, 2015-01-26 at 15:21 -0700, Jeff Law wrote: > On 01/26/15 09:42, David Malcolm wrote: > > > update_web_docs_svn-support-the-JIT-documention-v2.patch > > > > > > From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00:00:00 2001 > > From: David Malcolm > > Date: Fri, 23 Jan 2015 17:26:5

[PATCH, committed] Fix gcc_jit_context_get_last_error docs

gcc_jit_context_get_last_error was documented as returning a string that's valid for the rest of the lifetime of the context. In fact, the buffer becomes invalid if any other errors occur on the context. Fix the docs and header file comments to reflect this. Also, fix a couple of other minor jit

Re: [SH] Introduce treg_set_expr

On Thu, 2015-01-22 at 23:46 +0100, Oleg Endo wrote: > I will install this the patch from > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01743.html > in 24h if there are no further objections. > The above mentioned patch has been committed as r220081. This is a small follow up patch that fixes

[PATCH 2/3] [SH] Add jump insn for -freorder-blocks-and-partition

This patch adds a new jump insn for the jump crossing between hot/cold pertitions and reenables -freorder-blocks-and-partition on SH in some cases. -- PR target/64761 * config/sh/sh.c (sh_option_override): Don't change -freorder-blocks-and-partition to -freorder-blocks even

[PATCH 0/3] Fix PR target/64761

[i'd like to add Joern to CC list because this is based on his patch.] Hi, This patch series is to fix PR target/64761 which is formally a 4.9/5 regression. The fix is splitted into 3 pieces: [PATCH 1/3] Replace MD_REDIRECT_BRANCH with TARGET_CAN_FOLLOW_JUMP [PATCH 2/3] [SH] Add jump insn for -

[PATCH 3/3] Fix dbr_schedule for -freorder-blocks-and-partition

This patch is to fix 2 issues found in dbr_schedule when trying to fix PR target/64761. The first is relax_delay_slots removes the jump insn in the insns like below: (jump_insn/j 74 58 59 (set (pc) (label_ref:SI 29)) ...) (barrier 59 74 105) (note 105 59 29 NOTE_INSN_SWITCH_TEXT_SECTIONS) (code_l

[PATCH 1/3] Replace MD_REDIRECT_BRANCH with TARGET_CAN_FOLLOW_JUMP

This is an updated patch of the patch proposed by Joern https://gcc.gnu.org/ml/gcc-patches/2013-04/msg01332.html which replaces MD_REDIRECT_BRANCH of which SH is the last user with TARGET_CAN_FOLLOW_JUMP. -- 2015-01-27 Joern Rennecke Kaz Kojima PR target/64761 *

[patch] libstdc++/64368 Fix invalid frees in numpunct_shim with clocale=generic

This should fix most of the FAILs seen on targets that use --enable-clocale=generic When I added numpunct_shim I think I got confused/scared by the clocale=gnu version of numpunct::_M_initialize_numpunct() and decided not to touch the _M_grouping member of the cache. Looking at it again now, _M_g

Re: Stage3 closing soon, call for patch pings

On Fri, Jan 16, 2015 at 7:05 AM, Jeff Law wrote: > On 01/15/15 16:43, Nathaniel Smith wrote: >>> >>> >>> Jakub, myself and management have discussed this issue extensively and >>> those >>> patches specifically. I'm painfully aware of how this affects the >>> ability >>> to utilize numerical pack

Re: RFA: RL78: Minor prologue and epilogue enhancements

> OK to apply ? Ok.

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

> OK to apply ? Ok.

Re: [PATCH] toplev.c: Process the failure when read fails for random_seed

On 1/27/15 05:56, Jeff Law wrote: > On 01/22/15 13:50, Chen Gang S wrote: >> On 01/23/2015 03:53 AM, Jeff Law wrote: >>> On 01/22/15 12:42, Chen Gang S wrote: Thank you very much for your help applying the 3 patches. :-) >>> No problem. >>> After finish the assignment worki

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

On 01/26/15 09:42, David Malcolm wrote: update_web_docs_svn-support-the-JIT-documention-v2.patch From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00:00:00 2001 From: David Malcolm Date: Fri, 23 Jan 2015 17:26:57 -0500 Subject: [PATCH] update_web_docs_svn: support the JIT documentation

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

Hi Paul, > The testcase has a dependence on libubsan.so, which my LD_LIBRARY_PATH > does not seem to be able to resolve. It therefore fails in the > regression test. When I point to ~/lib64, I get the message: > > /svn/trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90:8: runtime > error: signe

Re: [PATCH] toplev: gcc version information for jit

On 01/23/15 13:06, David Malcolm wrote: libgccjit can print detailed logs and generate testcases for reproducing bugs (using gcc_jit_context_set_logfile and gcc_jit_context_dump_reproducer_to_file respectively). It strikes me that such files really ought to contain version information, so the fo

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

On 01/26/15 07:30, Tobias Burnus wrote: 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

Re: [C PATCH] Fix ICE with assignment to FUNCTION_DECL (PR c/64766)

On 01/26/15 14:13, Jakub Jelinek wrote: Hi! On the following testcase we ICE during error recovery. Setting DECL_INITIAL of a FUNCTION_DECL to error_mark_node can't be possibly helpful, the error must have been diagnosed already; DECL_INITIAL on the FUNCTION_DECL should be kept as BLOCK. Bootst

Re: [Patch, fortran] PR62044 ICE when loading use-renamed extended derived type

Dear All, The fix for the failing testcases in comments #6 and #7 in this PR have been fixed as 'obvious' in r220140. Thanks to Mikael for reopening the PR as a placeholder. This is such an embarrassing bug that I intend to commit to 4.9 as well even if it is not a regression, unless there are o

Re: [PATCH, CHKP] Fix bounds return check for calls

On 01/26/15 09:45, Ilya Enkovich wrote: 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? Thank

Re: [PATCH] toplev.c: Process the failure when read fails for random_seed

On 01/22/15 13:50, Chen Gang S wrote: On 01/23/2015 03:53 AM, Jeff Law wrote: On 01/22/15 12:42, Chen Gang S wrote: Thank you very much for your help applying the 3 patches. :-) No problem. After finish the assignment working flow, I guess, I may have the write access, then can finish the

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

Hi Janus, The testcase has a dependence on libubsan.so, which my LD_LIBRARY_PATH does not seem to be able to resolve. It therefore fails in the regression test. When I point to ~/lib64, I get the message: /svn/trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90:8: runtime error: signed integer

[committed] Fix #pragma omp declare simd mangling (PR middle-end/64421)

Hi! If #pragma omp declare simd function has a name set using __asm, DECL_ASSEMBLER_NAME starts with *. We certainly don't want to put that * as part of the mangled name, if not anything else because most of the assemblers don't handle it as part of identifiers. Fixed thusly, committed to trunk

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

Hi Thanks a lot for those explanations, very educative. I was indeed wondering what was the additional template parameter for. So here is a new attempt. While moving __is_transparent to std namespace I renamed to __has_is_transparent to not conflict with existing __is_transparent. I

[PATCH] wide-int division fix (PR tree-optimization/64807)

Hi! On the following testcase we generate wrong code, because apparently divmod_internal_2 relies on 0 being the topmost element (at b_dividend[m]): algorithm. M is the number of significant elements of U however there needs to be at least one extra element of B_DIVIDEND allocated, N is

Re: [PATCH] Fix ICE during ipa dumping (PR ipa/64730)

> Hi! > > On various targets, %s in fprintf can't handle NULL arguments, > and even when edge->call_stmt is non-NULL, it still might have > UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename. > In this particular case it is a fnsplit created call. > > Fixed thusly, bootstrapped/regte

[PATCH] Fix ICE due to invalid thunk (PR ipa/64776)

Hi! On x86_64-darwin, we ICE on one of the pr64307.c testcase, because expand_thunk doesn't load non-gimple_val arguments into registers for the first argument, only for all the other ones. Supposedly normally thunks were meant to have this argument as pointer first and thus it wasn't an issue, bu

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

On Mon, Jan 26, 2015 at 10:10:56PM +0100, Jakub Jelinek wrote: > 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

[PATCH] Fix ICE during ipa dumping (PR ipa/64730)

Hi! On various targets, %s in fprintf can't handle NULL arguments, and even when edge->call_stmt is non-NULL, it still might have UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename. In this particular case it is a fnsplit created call. Fixed thusly, bootstrapped/regtested on x86_64-l

[C PATCH] Fix ICE with assignment to FUNCTION_DECL (PR c/64766)

Hi! On the following testcase we ICE during error recovery. Setting DECL_INITIAL of a FUNCTION_DECL to error_mark_node can't be possibly helpful, the error must have been diagnosed already; DECL_INITIAL on the FUNCTION_DECL should be kept as BLOCK. Bootstrapped/regtested on x86_64-linux and i686-

[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

[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

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, 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: 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

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: #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: [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: [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 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: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 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: [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 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: [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 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

[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 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

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] 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, 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, 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: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: [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 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: [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 [

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

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

[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

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, 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][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

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

[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 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

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

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: [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

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: [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: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: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: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

[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][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][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

[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

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: > >

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: [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, 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: [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] [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: [[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: [[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] 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

  1   2   >