Re: PR middle-end/35535 part I

> On 12/17/13 23:53, Tobias Burnus wrote: > >Am 17.12.2013 21:56, schrieb Jeff Law: > >>>* tree-vrp.c (extract_range_from_unary_expr_1): Add OBJ_TYPE_REF > >>s/Add/Handle. Please add the PR marker as well. > >> > >>OK with that trivial nit. > > > >And the proper PR. I don't think that INVALID

Re: [patch] Fix PR debug/59418

> Is it really a good idea to put the XVECLEN into the loop condition? > I mean, the functions that are called in the loop are unlikely pure > and thus the length will need to be uselessly reread for each iteration. I'm not sure we are supposed to care about this kind of micro-optimization in the

RFA: Fix test pr32912-2.c for 16-bit targets

Hi Guys, The test gcc/testsuite/gcc.dg/pr32912-2.c fails to execute correctly on targets that use 16-bit integers, because it assumes at least a 32-bit integer. The patch below removes this assumption, and it also tidies up the code slightly so that __SIZEOF_INT__ is only tested in one

Re: [ARM] Fix register r3 wrongly used to save ip in nested APCS frame

> Revised patch attached, your testcase passes on arm-eabi with it. Does it > look OK to you? If so, I'll run a testing cycle on arm-vxworks and > arm-eabi. > > > * config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with > arguments to push onto the stack and no varargs,

Re: [PATCH, i386 testsuite]: Fix -mabi=ms related failures for -mtune=corei7

Uros Bizjak writes: > On Sun, Dec 15, 2013 at 1:14 PM, Dominique Dhumieres > wrote: >>> OTOH, I can't test darwin properly, please provide the patch and I'll >>> commit it for you. >> >> Basically the patch I have in my tree since the PR replace 'linux' with >> *' (see below). >> Since I can on

Re: [PATCH, i386 testsuite]: Fix -mabi=ms related failures for -mtune=corei7

On Wed, Dec 18, 2013 at 11:44 AM, Rainer Orth wrote: >> On Sun, Dec 15, 2013 at 1:14 PM, Dominique Dhumieres >> wrote: OTOH, I can't test darwin properly, please provide the patch and I'll commit it for you. >>> >>> Basically the patch I have in my tree since the PR replace 'linux' wi

[patch] Cleaning after the gfortran test suite

This patch extend the cleaning proposed in http://gcc.gnu.org/ml/fortran/2013-10/msg00083.html to opened files. The patch is mostly obvious except for gfortran.dg/open_negative_unit_1.f90 for which I assumed that the second OPEN closes the file foo.txt without deleting it (and that it is the inten

Re: Fix PR58477, part II

On Mon, Dec 16, 2013 at 2:58 PM, Jan Hubicka wrote: >> Hi, >> >> On Sat, Dec 14, 2013 at 11:01:53PM +0100, Jan Hubicka wrote: >> > Hi, >> > this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed >> > previously. >> >> This is the first time I hear about this but the change is ob

Re: Vectorization for store with negative step

On Mon, Dec 16, 2013 at 5:54 PM, Bingfeng Mei wrote: > Hi, > I was looking at some loops that can be vectorized by LLVM, but not GCC. One > type of loop is with store of negative step. > > void test1(short * __restrict__ x, short * __restrict__ y, short * > __restrict__ z) > { > int i; >

Re: [patch] remove docs for SSA_OP_VMAYUSE and other doc/tree-ssa.texi cleanups

On Mon, Dec 16, 2013 at 6:59 PM, Aldy Hernandez wrote: > While debugging something completely unrelated I ran into this... > > SSA_OP_VMAYUSE hasn't been around for a looong time. For that matter, I > think it was even me that got rid of it, so this was an sloppy oversight on > my part. > > I als

RE: Vectorization for store with negative step

Thanks, Richard. I will file a bug report and prepare a complete patch. For perm_mask_for_reverse function, should I move it before vectorizable_store or add a declaration. Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 18 December 2013 11:2

Re: RFC Asan instrumentation control

Hi all, On 12/06/2013 05:32 PM, Yury Gribov wrote: So it looks like people are generally ok with * --param asan-instrument-reads=0/1 * --param asan-instrument-writes=0/1 * --param asan-stack=0/1 * --param asan-globals=0/1 I've implemented these options. Tested on x86_64. * --param asan-memint

Re: [Patch,avr]: Fix wrong warning PR59396

On Tue, Dec 17, 2013 at 2:05 PM, Georg-Johann Lay wrote: > Am 12/05/2013 04:09 PM, schrieb Richard Biener: >> >> On Thu, Dec 5, 2013 at 3:53 PM, Georg-Johann Lay wrote: >> >>> This is a fix of a wrong warning for a bas ISR name. The assumption was >>> that if DECL_ASSEMBLER_NAME is set, it would

Re: [patch] fix .DOT file generation for IPA passes

On Tue, Dec 17, 2013 at 9:10 PM, Aldy Hernandez wrote: > I was trying to generate a graph file with > -fdump-ipa-tmipa-blocks-details-vops-graph, but the .dot file was corrupted. > It looks like the header bits printed in start_graph_dump() are not dumped > because we are predicating the calls to

Re: Vectorization for store with negative step

On Wed, Dec 18, 2013 at 12:34 PM, Bingfeng Mei wrote: > Thanks, Richard. I will file a bug report and prepare a complete patch. For > perm_mask_for_reverse function, should I move it before vectorizable_store or > add a declaration. Move it. Richard. > > Bingfeng > -Original Message-

[PATCH][ARM] Add new cores to t-aprofile

Hi all, This patch adds the recently introduced cores to the t-aprofile multilib machinery. The values added are cortex-a15.cortex-a7, cortex-a12, cortex-a57 and cortex-a57.cortex-a53. Tested arm-none-eabi on qemu and model. Ok for trunk? Thanks, Kyrill 2013-12-18 James Greenhalgh

Re: RFC Asan instrumentation control

On Wed, Dec 18, 2013 at 03:35:35PM +0400, Maxim Ostapenko wrote: > 2013-12-18 Max Ostapenko > > * gcc/asan.c (asan_emit_stack_protection): Optionally disable stack > protection. > (instrument_derefs): Optionally disable memory access instrumentation. > (instrument_mem_region_

[AArch64 1/3 big.LITTLE] Driver rewriting of big.LITTLE names.

Hi, As in the ARM backend we would like to use specs to rewrite a -mcpu=big.LITTLE style name to just -mcpu=big before handing off to the assembler. As with the ARM backend, we can do this using ASM_SPEC. We need to do a little more wiring up here, as the AArch64 backend doesn't yet use these sp

[AArch64 0/3 big.LITTLE]

Hi, This patch series adds support for tuning for big.LITTLE systems when compiling for the AArch64 target. The patch series progresses as the one for the ARM backend did yesterday. (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01475.html) As with the ARM backend, we take the convention that for

[AArch64 3/3 big.LITTLE] Add support for -mcpu=cortex-a57.cortex-a53

Hi, This patch wires up support for -mcpu=cortex-a57.cortex-a53. Tested on aarch64-none-elf with no regressions. OK? --- 2013-12-18 James Greenhalgh * config/aarch64/aarch64-cores.def: Add support for -mcpu=cortex-a57.cortex-a53. * config/aarch64/aarch64-tune.md: Re

[AArch64 2/3 big.LITTLE] Allow tuning parameters without unique tuning targets.

Hi, AArch64 imports the limitation from ARM that each entry in the CORE_IDENT column in aarch64-cores.def must be unique (as this column is used to generate enums). We would like to have different -mcpu values map to the same scheduler description, so remove that limitation. One oddity this enfo

Re: [GOMP4] Patch to add option for offloading

Ping On Fri, Dec 13, 2013 at 3:09 PM, Andrey Turetskiy wrote: > Hi, > I've added option -foffload-target to specify target and options for > target compiler for offloading. > Please, have a look. > > -- > Best regards, > Andrey Turetskiy -- Best regards, Andrey Turetskiy

Re: Fix PR58477, part II

> > OK, so the explanation is not as simple as claim that non-POD types > > needs to be constructed or copied by constructor and C++ FE always > > generate an explicit vtbl store? > > No as optimizers may combine stores for example. Yep, I understand we can design "evil" optimization that will ma

[AArch64 4.8-branch] Backport: Fix CM instruction generation.

Hi, Recently it was pointed out that GCC 4.8 can generate instruction aliases which are no longer mentioned in the AArch64 portion of the ARMv8 architecture reference manual. It turns out that a series of patches to GCC 4.9 actually corrected this behaviour, though at the time the instructions w

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

Update patch. Solved __attribute((target("arch=corei7-avx"))) by defining proper architectures for the recent Intel families instead of renaming submodels. I am thinking the patch is starting to touch a bit many different details, perhaps it should be split up, or is it good as is? Regards `A

Re: [PATCH][ARM] Add new cores to t-aprofile

On 18/12/13 11:46, Kyrill Tkachov wrote: Hi all, This patch adds the recently introduced cores to the t-aprofile multilib machinery. The values added are cortex-a15.cortex-a7, cortex-a12, cortex-a57 and cortex-a57.cortex-a53. Tested arm-none-eabi on qemu and model. Ok for trunk? Ok. Ramana

Re: [PATCH i386 4/8] [AVX512] [5/8] Add substed patterns: rounding subst.

Hello, On 02 Dec 16:09, Kirill Yukhin wrote: > Hello, > On 19 Nov 12:08, Kirill Yukhin wrote: > > Hello, > > On 15 Nov 20:06, Kirill Yukhin wrote: > > > Ping. > > Ping. > Ping. Ping. Rebased patch in the bottom. -- Thanks, K --- gcc/config/i386/i386.c | 32 gcc/config/i386/i386.md | 1

Re: [PATCH i386 4/8] [AVX512] [6/8] Add substed patterns: `sae' subst.

Hello, On 02 Dec 16:10, Kirill Yukhin wrote: > Hello, > On 19 Nov 12:11, Kirill Yukhin wrote: > > Hello, > > On 15 Nov 20:07, Kirill Yukhin wrote: > > > > Is it ok for trunk? > > > Ping. > > Ping. > Ping. Ping. Rebased patch in the bottom. -- Thanks, K --- gcc/config/i386/sse.md | 168 ++

Re: [PATCH i386 4/8] [AVX512] [7/8] Add substed patterns: `round for expand' subst.

Hello, On 02 Dec 16:11, Kirill Yukhin wrote: > Hello, > On 19 Nov 12:12, Kirill Yukhin wrote: > > Hello, > > On 15 Nov 20:08, Kirill Yukhin wrote: > > > > Is it ok for trunk? > > > Ping. > > Ping. > Ping. Ping. Rebased patch in the bottom. -- Thanks, K --- gcc/config/i386/sse.md | 24 +++

Re: [Patch, AArch64] [2/6] Implement support for Crypto -- Instruction types.

On Fri, Dec 6, 2013 at 5:35 PM, Tejas Belagod wrote: > > Hi, > > The attached patch adds crypto types for instruction classificiation. > > Tested on aarch64-none-elf. OK for trunk? Ok but please work with Kyryll to make sure only one version of this gets in, obviously. Ramana > > Thanks, > Teja

Re: [PATCH i386 4/8] [AVX512] [8/8] Add substed patterns: `sae-only for expand' subst.

Hello, On 02 Dec 16:11, Kirill Yukhin wrote: > Hello, > On 19 Nov 12:14, Kirill Yukhin wrote: > > Hello, > > On 15 Nov 20:09, Kirill Yukhin wrote: > > > > Is it ok for trunk? > > > Ping. > > Ping. > Ping. Ping. Rebased patch in the bottom. -- Thanks, K

Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.

Hello, On 02 Dec 16:13, Kirill Yukhin wrote: > Hello, > On 19 Nov 12:14, Kirill Yukhin wrote: > > Hello, > > On 15 Nov 20:10, Kirill Yukhin wrote: > > > > Is it ok to commit to main trunk? > > > Ping. > > Ping. > Ping. Ping. Updated patch in the bottom. -- Thanks, K --- gcc/config/i386/i386.c

Re: [PATCH i386 4/8] [AVX512] [8/8] Add substed patterns: `sae-only for expand' subst.

> Rebased patch in the bottom. Adding the patch. -- Thanks, K --- gcc/config/i386/sse.md | 18 ++ gcc/config/i386/subst.md | 20 2 files changed, 30 insertions(+), 8 deletions(-) diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index e15e1b1..8

Re: [PATCH i386 6/8] [AVX-512] Add builtins/intrinsics.

Hello, On 02 Dec 16:15, Kirill Yukhin wrote: > Hello > > Ok for trunk? > Ping? Ping. Rebased patch attached. Thanks, K p.patch.bz2 Description: BZip2 compressed data

[PATCH] Vectorization for store with negative step

Hi, I created PR59544 and here is the patch. OK to commit? Thanks, Bingfeng 2013-12-18 Bingfeng Mei PR tree-optimization/59544 * tree-vect-stmts.c (perm_mask_for_reverse): Move before vectorizable_store. (vectorizable_store): Handle negative step. 2013-12-18 Bingfeng M

RE: Two build != host fixes

Hi, On Wed, 18 Dec 2013 09:58:39, Alan Modra wrote: > > On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote: >> the reason for this is overwriting GMPINC for the auto-build generation, >> because >> many test scripts include which fails now completely (it is not >> installed, >> I ha

Re: [PATCH] Vectorization for store with negative step

On Wed, Dec 18, 2013 at 01:31:05PM +, Bingfeng Mei wrote: Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 206016) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2013-12-18 Bingfeng Mei + + PR tree-optim

[PATCH] Avoid uninitialized warning in i386.c

Bootstrap with -fsanitize=undefined revealed that the alg variable may be used uninitialized. Or at least gcc thinks so. This patch initializes it to 0. Regtested/bootstrapped on x86_64-linux, ok for trunk? 2013-12-18 Marek Polacek * config/i386/i386.c (ix86_parse_stringop_strategy_

Re: [PATCH] Avoid uninitialized warning in i386.c

On Wed, Dec 18, 2013 at 02:39:44PM +0100, Marek Polacek wrote: > Bootstrap with -fsanitize=undefined revealed that the alg variable > may be used uninitialized. Or at least gcc thinks so. This patch > initializes it to 0. > > Regtested/bootstrapped on x86_64-linux, ok for trunk? Do stri

[Patch, ARM, LRA] Fix Thumb1 ICE

Hi, this patch from Vladimir fixes an ICE when compiling newlib in Thumb1. It returns NO_REGS in THUMB_SECONDARY_OUTPUT_RELOAD_CLASS, the same way we did for THUMB_SECONDARY_INPUT_RELOAD_CLASS. The testsuite is OK with this patch, but as we have also a regression on iWMMXT, I tried to avoid the

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Wed, Dec 18, 2013 at 1:57 PM, Allan Sandfeld Jensen wrote: > Update patch. Solved __attribute((target("arch=corei7-avx"))) by defining > proper architectures for the recent Intel families instead of renaming > submodels. @@ -30922,9 +30955,13 @@ F_SSE2, F_SSE3, F_SSSE3, +F_S

Re: RFA: Fix test pr32912-2.c for 16-bit targets

On 12/18/13 03:09, Nick Clifton wrote: Hi Guys, The test gcc/testsuite/gcc.dg/pr32912-2.c fails to execute correctly on targets that use 16-bit integers, because it assumes at least a 32-bit integer. The patch below removes this assumption, and it also tidies up the code slightly so

[Patch, Fortran, OOP] PR 59493: Cleanup of vtab generation code

Hi all, here is a follow-up to my recent patch for PR59493, doing some cleanup related to the generation of vtab symbols: 1) Since the function gfc_find_intrinsic_vtab, contrary to its name, handles not only intrinsic but also derived types, I removed the latter functionality, and instead introduc

RE: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental functions) for C

> -Original Message- > From: Jakub Jelinek [mailto:ja...@zalov.cz] > Sent: Wednesday, December 18, 2013 1:31 AM > To: Iyer, Balaji V > Cc: Joseph S. Myers; Aldy Hernandez (al...@redhat.com); 'gcc- > patc...@gcc.gnu.org' > Subject: Re: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (former

Re: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental functions) for C

On Wed, Dec 18, 2013 at 02:32:54PM +, Iyer, Balaji V wrote: > > Yes, though I still want to optimize it a little bit (generate thunks and/or > > aliases when desirable/possible), but that only affects exported > > entry-points > > for OpenMP, for Cilk+ the code matches more the Intel ABI paper

Re: [RS6000] bswapdi2 pattern, reload and lra

On Tue, Dec 17, 2013 at 6:50 AM, Alan Modra wrote: > Bootstrapped and regression tested powerpc64-linux. Output of > pr53199.c inspected for sanity with -mcpu=power{6,7} -m{32,64} and > {-mlra,}. OK to apply? > > gcc/ > * config/rs6000/rs6000.md (bswapdi2): Remove one scratch reg. >

RE: [PATCH] Fix PR58944

On Tue, 17 Dec 2013 10:29:03, Sriraman Tallam wrote: > > On Fri, Dec 13, 2013 at 5:06 AM, H.J. Lu wrote: >> On Mon, Dec 2, 2013 at 6:46 PM, Sriraman Tallam wrote: >>> On Thu, Nov 28, 2013 at 9:36 PM, Bernd Edlinger >>> wrote: Hi, On Wed, 27 Nov 2013 19:49:39, Uros Bizjak wrote: >>

[PATCH] Improve _mm*loadu* intrinsics handling (PR target/59539)

Hi! As discussed in the PR, this patch similarly to the recent changes in movmisalign expansion for TARGET_AVX for unaligned loads from misaligned_operand just expands those as *mov_internal pattern, because that pattern emits vmovdqu/vmovup[sd] too, but doesn't contain UNSPECs and thus can be als

[ARM] Fix thinko in arm_expand_epilogue_apcs_frame

While arm_expand_epilogue has the correct: if (crtl->calls_eh_return) emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, gen_rtx_REG (SImode, ARM_EH_STACKADJ_REGNUM))); arm_expand_epilogue_apcs_frame has the bogus: if (crtl

[PATCH] Fix ifcvt (PR rtl-optimization/58668)

Hi! As discussed in the PR, this testcase ICEs on arm, because ifcvt is relying on active instruction counts from various routines (count_bb_insns, flow_find_cross_jump and flow_find_head_matching_sequence), but each of those routines have different view of what counts as active insns. Fixed thus

Re: [PATCH] Avoid uninitialized warning in i386.c

On Wed, Dec 18, 2013 at 02:45:12PM +0100, Jakub Jelinek wrote: > On Wed, Dec 18, 2013 at 02:39:44PM +0100, Marek Polacek wrote: > > Bootstrap with -fsanitize=undefined revealed that the alg variable > > may be used uninitialized. Or at least gcc thinks so. This patch > > initializes it to 0. > >

Re: [Patch, AArch64] [3/6] Implement support for Crypto -- AES.

Marcus Shawcroft wrote: On 6 December 2013 17:36, Tejas Belagod wrote: * gcc.target/aarch64/aes.c: New. Add _1 on the test case file name (see http://gcc.gnu.org/wiki/TestCaseWriting) diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h index dc56170..9f35e09

Re: [Patch, AArch64] [4/6] Implement support for Crypto -- SHA1.

Marcus Shawcroft wrote: Same comments as previous patch: On 6 December 2013 17:36, Tejas Belagod wrote: testsuite/ * gcc.target/aarch64/sha1.c: New. Add _1 on the test case file name (see http://gcc.gnu.org/wiki/TestCaseWriting) +static __inline uint32x4_t +vsha1cq_u32 (uint32x4_t

Re: [Patch, AArch64] [6/6] Implement support for Crypto -- PMULL.64.

Tejas Belagod wrote: Hi, This patch implements support for crypto pmull.64. Tested on aarch64-none-elf. OK for trunk? Thanks, Tejas. 2013-12-06 Tejas Belagod gcc/ * config/aarch64/aarch64-builtins.c: Define builtin types for poly64_t poly128_t. * aarch64/aarch64-si

Re: [Patch, AArch64] [5/6] Implement support for Crypto -- SHA256.

Marcus Shawcroft wrote: On 6 December 2013 17:36, Tejas Belagod wrote: Hi, The attached patch implements support for crypto sha256. Same comments as previous crypto patch. Thanks for the review. Here is an improved patch. Tested on aarch64-none-elf. OK for trunk? Thanks Tejas. 2013-12-1

Re: [PATCH][ARM] Implement CRC32 intrinsics for AArch32 in ARMv8-A

On Tue, Dec 3, 2013 at 1:46 PM, Kyrill Tkachov wrote: > Ping? > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02351.html > > Thanks, > Kyrill Ok if no objections in 24 hours. Ramana > > > On 26/11/13 09:44, Kyrill Tkachov wrote: >> >> Ping? >> >> Thanks, >> Kyrill >> >> On 19/11/13 17:04, Kyrill

RE: [Patch, i386] PR 59422 - Support more targets for function multi versioning

Ping! "Gopalasubramanian, Ganesh" wrote: > Yes, I figured that was the original idea behind it, but the final family of > the jaguar processors seems to have become 16h instead of 14h (bobcat) at > some point. Yes. It is amdfam16h. I was supposed to pass on some comments on the patch. 1. Am

Re: [PATCH] Avoid uninitialized warning in i386.c

On Wed, Dec 18, 2013 at 04:27:23PM +0100, Marek Polacek wrote: > Okay. Regtested/bootstrapped on x86_64-linux, ok now? > > 2013-12-18 Marek Polacek > > * config/i386/i386.c (ix86_parse_stringop_strategy_string): Remove > variable alg. Use index variable i directly. Yes, thanks.

Re: [PATCH i386 7/8] [AVX-512] Add tests.

On Wed, Dec 18, 2013 at 2:23 PM, Kirill Yukhin wrote: > Hello, > On 02 Dec 16:18, Kirill Yukhin wrote: >> Hello, >> > Is it ok now? >> Ping? > Ping. > > Rebased patch attached. Whoa. --- a/gcc/config/i386/sse.md +++ b/gcc/config/i386/sse.md No, not in this patch. +/* { dg-do run } */ +/* { dg-

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Wed, Dec 18, 2013 at 4:38 PM, Gopalasubramanian, Ganesh wrote: > > Ping! > > "Gopalasubramanian, Ganesh" wrote: > > >> Yes, I figured that was the original idea behind it, but the final family of >> the jaguar processors seems to have become 16h instead of 14h (bobcat) at >> some point. > >

RE: [PATCH] Vectorization for store with negative step

Hi, Jakub, Sorry for all the formatting issues. Haven't submit a patch for a while :-). Please find the updated patch. Thanks, Bingfeng -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: 18 December 2013 13:38 To: Bingfeng Mei Cc: Richard Biener; gcc-patches@gcc.gnu.

Re: [PATCH] Improve _mm*loadu* intrinsics handling (PR target/59539)

On Wed, Dec 18, 2013 at 4:11 PM, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, this patch similarly to the recent changes > in movmisalign expansion for TARGET_AVX for unaligned loads from > misaligned_operand just expands those as *mov_internal pattern, > because that pattern emits vmovd

Re: [PATCH i386 6/8] [AVX-512] Add builtins/intrinsics.

On Wed, Dec 18, 2013 at 2:21 PM, Kirill Yukhin wrote: > Hello, > > On 02 Dec 16:15, Kirill Yukhin wrote: >> Hello >> > Ok for trunk? >> Ping? > Ping. > > Rebased patch attached. + error ("third argument must be comparison constant."); "the third ...", without dot at the end. Please review m

Re: [RFC] libgcov.c re-factoring and offline profile-tool

>> >> #ifdef L_gcov_merge_ior >> /* The profile merging function that just adds the counters. It is given >> - an array COUNTERS of N_COUNTERS old counters and it reads the same number >> - of counters from the gcov file. */ >> + an array COUNTERS of N_COUNTERS old counters. >> + When S

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Wednesday 18 December 2013, Gopalasubramanian, Ganesh wrote: > Ping! > > "Gopalasubramanian, Ganesh" wrote: > > Yes, I figured that was the original idea behind it, but the final family > > of the jaguar processors seems to have become 16h instead of 14h > > (bobcat) at some point. > > Yes. I

Re: [REPOST] Invalid Code when reading from unaligned zero-sized array

On Mon, 16 Dec 2013, Eric Botcazou wrote: > which of course blatantly violates the do-not-rely-on-mode rule. Although > the > layout change apparently occurs very rarely, I think that this rules out the > direct mode change in stor-layout.c... Well - makes such a change unsuitable for 4.9.

Re: [PATCH] Ubsan load of bool/enum sanitization

On Mon, 16 Dec 2013, Jakub Jelinek wrote: > On Mon, Dec 16, 2013 at 07:40:16PM +0100, Jakub Jelinek wrote: > > It can be the last thing, sure. I think the still unimplemented and > > potentially useful are the floating point overflow sanitization (haven't > > looked yet what exactly it is, I supp

Re: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental functions) for C

On Mon, 16 Dec 2013, Jakub Jelinek wrote: > On Mon, Dec 16, 2013 at 09:41:43PM +, Iyer, Balaji V wrote: > > --- gcc/c/c-parser.c(revision 205759) > > +++ gcc/c/c-parser.c(working copy) > > @@ -208,6 +208,12 @@ > >/* True if we are in a context where the Objective-C "Propert

Re: [PATCH] Ubsan load of bool/enum sanitization

On Mon, 16 Dec 2013, Jakub Jelinek wrote: > It can be the last thing, sure. I think the still unimplemented and > potentially useful are the floating point overflow sanitization (haven't > looked yet what exactly it is, I suppose casts from floating point to > integers where the values are out of

Re: [AArch64 2/3 big.LITTLE] Allow tuning parameters without unique tuning targets.

On 18 December 2013 12:23, James Greenhalgh wrote: > 2013-12-18 James Greenhalgh > > * config/aarch64/aarch64-cores.def: Add new column for > SCHEDULER_IDENT. > * config/aarch64/aarch64-opts.h (AARCH64_CORE): Handle > SCHEDULER_IDENT. > * config/aarch64/

Re: [AArch64 1/3 big.LITTLE] Driver rewriting of big.LITTLE names.

On 18 December 2013 12:23, James Greenhalgh wrote: > 2013-12-18 James Greenhalgh > > * common/config/aarch64/aarch64-common.c > (aarch64_rewrite_selected_cpu): New. > (aarch64_rewrite_mcpu): New. > * config/aarch64/aarch64-protos.h > (aarch64_rewrite_sel

Re: [AArch64 3/3 big.LITTLE] Add support for -mcpu=cortex-a57.cortex-a53

On 18 December 2013 12:23, James Greenhalgh wrote: > 2013-12-18 James Greenhalgh > > * config/aarch64/aarch64-cores.def: Add support for > -mcpu=cortex-a57.cortex-a53. > * config/aarch64/aarch64-tune.md: Regenerate. > * doc/invoke.texi: Document -mcpu=cortex-a57

Re: [Patch, AArch64] [3/6] Implement support for Crypto -- AES.

On 18 December 2013 15:28, Tejas Belagod wrote: > 2013-12-18 Tejas Belagod > > > gcc/ > * config/aarch64/aarch64-simd-builtins.def: Update builtins table. > * config/aarch64/aarch64-builtins.c > (aarch64_types_binopu_qualifiers, > TYPES_BINOPU): New. > > * confi

Re: [Patch, AArch64] [4/6] Implement support for Crypto -- SHA1.

On 18 December 2013 15:28, Tejas Belagod wrote: > 2013-12-18 Tejas Belagod > > gcc/ > * config/aarch64/aarch64-simd-builtins.def: Update builtins table. > * config/aarch64/aarch64-builtins.c > (aarch64_types_ternopu_qualifiers, > TYPES_TERNOPU): New. > > * confi

Re: [Patch, AArch64] [5/6] Implement support for Crypto -- SHA256.

On 18 December 2013 15:28, Tejas Belagod wrote: > 2013-12-18 Tejas Belagod > > > gcc/ > * config/aarch64/aarch64-simd-builtins.def: Update builtins table. > * config/aarch64/aarch64-simd.md > (aarch64_crypto_sha256hv4si, > aarch64_crypto_sha256su0v4si, aarch64_crypto_sh

Re: [Patch, AArch64] [6/6] Implement support for Crypto -- PMULL.64.

On 18 December 2013 15:28, Tejas Belagod wrote: >> 2013-12-06 Tejas Belagod >> >> gcc/ >> * config/aarch64/aarch64-builtins.c: Define builtin types for >> poly64_t >> poly128_t. >> * aarch64/aarch64-simd-builtins.def: Update builtins table. >> * config/aarch64/a

Re: GOMP_target: alignment (was: [gomp4] #pragma omp target* fixes)

Hi! This one's owed to me still learning about GCC internals; if someone could please be so kind to poit me to the appropriate documentation, or explain: On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote: > The reason for 3 separate arrays is that some of the values > are always variable,

Re: [Patch, Fortran, OOP] PR 59493: Cleanup of vtab generation code

Janus Weil wrote: here is a follow-up to my recent patch for PR59493, doing some cleanup related to the generation of vtab symbols: 1) Since the function gfc_find_intrinsic_vtab, contrary to its name, handles not only intrinsic but also derived types, I removed the latter functionality, and inste

Re: GOMP_target: alignment (was: [gomp4] #pragma omp target* fixes)

On Wed, Dec 18, 2013 at 09:03:40PM +0100, Thomas Schwinge wrote: > This one's owed to me still learning about GCC internals; if someone > could please be so kind to poit me to the appropriate documentation, or > explain: > > On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote: > > The reason

lra_in_progress check in simplify_subreg_regno

Hi Vlad, The initial LRA merge added the lra_in_progress check to this code in simplify_subreg_regno: /* Give the backend a chance to disallow the mode change. */ if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT && REG_CANNOT_CHANGE_M

Re: [Patch, Fortran, OOP] PR 59493: Cleanup of vtab generation code

2013/12/18 Tobias Burnus : > Janus Weil wrote: >> >> here is a follow-up to my recent patch for PR59493, doing some cleanup >> related to the generation of vtab symbols: >> 1) Since the function gfc_find_intrinsic_vtab, contrary to its name, >> handles not only intrinsic but also derived types, I r

Re: [PATCH] Fix ifcvt (PR rtl-optimization/58668)

On Wednesday, December 18, 2013, Jakub Jelinek wrote: > > Hi! > > As discussed in the PR, this testcase ICEs on arm, because ifcvt > is relying on active instruction counts from various routines > (count_bb_insns, flow_find_cross_jump and flow_find_head_matching_sequence), > but each of those routi

RE: [GOMP4][PATCH] SIMD-enabled functions (formerly Elemental functions) for C++

Hello Jakub, Attached, please find a patch that will implement SIMD-enabled functions for C++. To my best knowledge, I have incorporated all the changes you have mentioned in C patch that are applicable for C++. Is this Ok to trunk? It passes all the tests on my SUSE machine for

[PATCH,committed] Convert assert to runtime error in reading exponents in Fortran

I committed the following changes to gfortran's runtime library. It converts an assert on an invalid floating-point exponent into a runtime error. 2013-12-18 Steven G. Kargl * io/read.c (read_f): Convert assert to runtime error. 2013-12-18 Steven G. Kargl * gfortran.dg/io_

Add const char* constructors for exception classes in

Hello, When writing code such as ... throw std::logic_error ("cold coffee"); ... currently the construction of std::string happens in the code that throws the exception, which results in code bloat. Implementing the const char* constructors as defined by C++11 fixes the issue. I'm not sure whet

Re: PATCH: PR driver/59321: -fuse-ld has no effect on -print-prog-name nor on --with-ld=

On Mon, 2 Dec 2013, H.J. Lu wrote: > @@ -3952,6 +3955,10 @@ process_command (unsigned int decoded_options_count, >free (fname); > continue; > } > + else if (decoded_options[j].opt_index == OPT_fuse_ld_bfd) > + use_ld = ".bfd"; > + else if (decoded_options[j]

Re: Add const char* constructors for exception classes in

On 19 December 2013 00:10, Oleg Endo wrote: > Hello, > > When writing code such as > ... > throw std::logic_error ("cold coffee"); > ... > currently the construction of std::string happens in the code that > throws the exception, which results in code bloat. Implementing the > const char* constr

Re: PATCH: PR driver/59321: -fuse-ld has no effect on -print-prog-name nor on --with-ld=

On Wed, Dec 18, 2013 at 4:13 PM, Joseph S. Myers wrote: > On Mon, 2 Dec 2013, H.J. Lu wrote: > >> @@ -3952,6 +3955,10 @@ process_command (unsigned int decoded_options_count, >>free (fname); >> continue; >> } >> + else if (decoded_options[j].opt_index == OPT_fuse_ld_b

RE: [Patch, i386] PR 59422 - Support more targets for function multi versioning

> Yes, I changed that in the last patch, though I consider it momentarily > problematic because you do not yet enable AVX with march=btver2 (AVX versions > would currently be better than btver2 versions for a btver2 arch), but expect march=btver2 will be fixed soon. The " processor_alias_table"

Re: [GOMP4][PATCH] SIMD-enabled functions (formerly Elemental functions) for C++

On Wed, Dec 18, 2013 at 11:36:04PM +, Iyer, Balaji V wrote: > --- a/gcc/cp/decl2.c > +++ b/gcc/cp/decl2.c > @@ -1124,6 +1124,10 @@ is_late_template_attribute (tree attr, tree decl) >&& is_attribute_p ("omp declare simd", name)) > return true; > > + /* Ditto as above for Cilk Plu