Re: [PATCH, 10/10] aarch64: Handle ccmp in ifcvt to make it work with cmov

Andrew, Thanks for the input. Patch is updated with your codes. In addition, add "cstorecc4" and 4 test cases. So it can optimized the following example int foo (int a, int b) { return a > 0 && b < 7; } to: cmpw0, wzr ccmpw1, #6, #9, gt csetw0, le Bootstrap and no make

Re: *ping* - [Patch, Fortran] Coarray fixes for select type/associate and type of derived components

Another somewhat early PING**2 On June 29, 2014, Tobias Burnus wrote: This patch fixes some issues with polymorphic coarrays. I still have to fix at least one issue. Fixed by the patch: a) The temporary pointer generated with SELECT TYPE has to be a coarray. That's fixed with the resolve.c

[PATCH 2/2] Remove x86 cmpstrnsi

From: Andi Kleen In my tests the optimized glibc out of line strcmp is always faster than using inline rep ; cmpsb, even for small strings. The Intel optimization manual also recommends to not use it. So remove the cmpstrnsi instruction. Tested on Sandy Bridge, Westmere Intel CPUs. gcc/: 2014-

[PATCH 1/2] Remove i386 cmpstrnsi peephole

From: Andi Kleen The peephole that removes the code to compute a tristate for cmpstrnsi when only a boolean jump is needed never triggers in my tests. Just remove it. gcc/: 2014-07-02 Andi Kleen * config/i386/i386.md: Remove peepholes for cmpstrn*. --- gcc/config/i386/i386.md | 77

[PATCH] PR rtl-optimization/61712

Hi, This crash is due to fail to consider the exception situation that the insn variable may not be a insn at all. arm.c (thumb1_reorg): if the selected insn is not a insn, continue to next bb. --- gcc/config/arm/arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/

[PATCH] Fix confusion between target, host and symbolic number byte sizes

The bswap pass deals with 3 possibly different byte size: host, target and the size a byte marker occupied in the symbolic_number structure [1]. However, as of now the code mixes the three size. This works in practice as the pass is only enabled for target with BITS_PER_UNIT == 8 and nobody runs

Re: [PATCH] Fix high handling in wi::mul_internal (PR tree-optimization/61682)

On Jul 3, 2014, at 2:53 PM, Richard Sandiford wrote: > Jakub Jelinek writes: >> >> + if (sgn == SIGNED && wi::neg_p (op1)) > > I think the preferred way of writing this is "wi::neg_p (op1, svn)" Yes.

Re: [PATCH] Fix high handling in wi::mul_internal (PR tree-optimization/61682)

Jakub Jelinek writes: > @@ -1302,12 +1310,28 @@ wi::mul_internal (HOST_WIDE_INT *val, co >/* Handle multiplications by 1. */ >if (op1 == 1) > { > + if (high) > + { > + if (sgn == SIGNED && wi::neg_p (op2)) > + val[0] = -1; > + else > + val[0] = 0;

Re: [wwwdocs] Buildstat update for 4.8

On Thu, 3 Jul 2014, Tom G. Christensen wrote: > Latest results for 4.8.x Thanks, applied! Gerald

RE: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

Hello Dodji, I found time this morning to run your changes through our system. I patched our gcc-4.8.1 with your latest change, and ran it through our folly testsuite. One thing that I immediately noticed was that this increased the preprocessed size substantially. When preprocessing my favori

[PATCH] PowerPC: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

This patch implements the TARGET_ATOMIC_ASSIGN_EXPAND_FENV for powerpc-fpu. I have to adjust current c11-atomic-exec-5 testcase because for IBM long double 0 += LDBL_MAX might generate overflow/underflow in internal __gcc_qadd calculations. The c11-atomic-exec-5 now passes for linux/powerpc, chec

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On Thu, 2014-07-03 at 22:14 +0200, Jakub Jelinek wrote: > On Thu, Jul 03, 2014 at 10:04:35PM +0200, Mark Wielaard wrote: > > On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote: > > > On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek wrote: > > > >On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On Thu, Jul 03, 2014 at 10:04:35PM +0200, Mark Wielaard wrote: > On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote: > > On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek wrote: > > >On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote: > > >> Well, simply removing the regression testi

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote: > On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek wrote: > >On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote: > >> Well, simply removing the regression testing for LTO is a > >maintainance nightmare as well. > >> > >> The guali

Re: [patch 1/4] change specific int128 -> generic intN

> That's what'll need fixing then. Can I change TYPE_SIZE to TYPE_SIZE_WITH_PADDING then? Because it's not reflecting the type's size any more. Why do we have to round up a type's size anyway? That's a pointless assumption *unless* you're allocating memory space for it, and in that case, you w

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek wrote: >On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote: >> Well, simply removing the regression testing for LTO is a >maintainance nightmare as well. >> >> The guality testsuite is very noisy anyway with all the xfail and >xpass. > >L

Re: [PATCH] Add guality [p]type test.

>> Is what gdb prints for ptype stable across different gdb versions (except >> for whitespace that you canonicalize)? If yes, this looks good to me. Mark> Yes, I believe it is (I tested against gdb git master and gdb 7.6.50). Mark> It tries to print the expression as a canonical C type, so it sh

[wwwdocs] Buildstat update for 4.8

Latest results for 4.8.x -tgc Testresults for 4.8.3: i686-pc-linux-gnu sparc-sun-solaris2.9 sparc64-sun-solaris2.9 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v retrieving revision 1.8 di

[wwwdocs] Buildstat update for 4.7

Latest results for 4.7.x -tgc Testresults for 4.7.4: i386-pc-solaris2.8 i386-pc-solaris2.9 sparc-sun-solaris2.8 sparc-sun-solaris2.9 sparc64-sun-solaris2.8 x86_64-apple-darwin13.2.0 x86_64-pc-linux-gnu Index: buildstat.html ==

[wwwdocs] Adjust two textual references to http://gcc.gnu.org

There were two cases, where we did not have links any more, but textual references to gcc.gnu.org via http. This addresses it. Applied. Gerald Index: gcc-2.96.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.96.html,v retrieving re

Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse

On 07/03/2014 10:01 AM, Thomas Schwinge wrote: > I'm happy to, but why don't we just get you set up? You're covered by > the general Mentor Graphics/CodeSourcery copyright assignment. Please > request an account per , and on >

Re: Normalize interface for all *-dg-runtest

On Jul 3, 2014, at 5:49 AM, Thomas Schwinge wrote: > I have a need to pass »flags« to a gfortran-dg-runtest call, but found > that not to be possible as the *-dg-runtest interfaces are "narrowed" > compared to dg-runtest. Here is a patch to fix that. So far only tested > in libgomp. OK in princ

[PATCH] Fix ICE with thunks (PR middle-end/61654)

Hi! update_ssa that expand_thunk calls, if it needs to change anything, computes CDI_DOMINATORS, but we assert that dominators are not computed when we release e.g. an unused thunk. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.9? 2014-07-03 Jakub Jelinek

[PATCH] Fix recognize_single_bit_test (PR tree-optimization/61684)

Hi! The rhs1 of CONVERT_EXPR_CODE_P doesn't have to be a SSA_NAME, can be e.g. invariant like ADDR_EXPR of a var, but ifcombine didn't think about that possibility. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.9/4.8? 2014-07-03 Jakub Jelinek PR

[PATCH] Fix high handling in wi::mul_internal (PR tree-optimization/61682)

Hi! Several places in wi::mul_internal didn't handle high parameter and would return the low bits instead of high bits. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2014-07-03 Jakub Jelinek PR tree-optimization/61682 * wide-int.cc (wi::mu

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote: > Well, simply removing the regression testing for LTO is a maintainance > nightmare as well. > > The guality testsuite is very noisy anyway with all the xfail and xpass. Let's keep it as is then? Jakub

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On July 3, 2014 9:55:36 AM CEST, Jakub Jelinek wrote: >On Thu, Jul 03, 2014 at 09:41:15AM +0200, Richard Biener wrote: >> On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek >wrote: >> >On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote: >> >> I think that makes sense; I'm not aware of anyo

Re: Strenghten assumption about dynamic type changes (placement new)

> On 07/02/2014 06:30 PM, Jan Hubicka wrote: > >But this is one of things that was not quite clear to me. I know that > >polymorphic type A > >was created at a give memory location. THis means that accesses to that > >location in one > >alias class has been made. > >Now I destroy A and turn it

PR C++/60209 - Declaration of user-defined literal operator cause error

Support operator"" ""(...) per CWG 1473. I'll be AFK over the holiday. Bootstrapped and tested on x86_64-linux. OK? I'm less sure if this is appropriate for 4.9. Index: cp/parser.c === --- cp/parser.c (revision 212248) +++ cp/par

Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse

Hi Cesar! On Wed, 2 Jul 2014 17:27:48 -0700, Cesar Philippidis wrote: > Thomas, is this patch ok for gomp-4_0-branch? Tobias has approved the patch (and I'm confirming it does fix the issue); thanks to you and Tobias for looking into this! > If so, please check it in. I'm happy to, but why d

Re: [PATCH, ARM] Work around erratum in VFP9

On Thu, Jul 3, 2014 at 4:15 PM, Richard Earnshaw wrote: > The VFP9 floating-point unit (as occasionally used with ARM9 devices) > has an erratum (760019) whereby it is possible for floating-point > division and square-root instructions to be executed twice. This is not > a problem if the destinat

Re: [patch 1/4] change specific int128 -> generic intN

On 07/03/2014 06:12 PM, DJ Delorie wrote: The hardware transfers data in and out of byte-oriented memory in TYPE_SIZE_UNITS chunks. Once in a hardware register, all operations are either 8, 16, or 20 bits (TYPE_SIZE) in size. So yes, values are padded in memory, but no, they are not padded in r

Re: [patch 1/4] change specific int128 -> generic intN

> And the hardware really loads 20 bits and not 24 bits? If so, I > think you might want to consider changing the unit to 4 bits instead > of 8 bits. If no, the mode is padded and has 24-bit size so why is > setting TYPE_PRECISION to 20 not sufficient to achieve what you > want? The hardware tr

Re: [patch 1/4] change specific int128 -> generic intN

> Yes. That's exactly the problem I'm trying to solve here. I'm making > partial int modes have real corresponding types, and they can be any > bit size, with target PS*modes to match. The MSP430, for example, has > 20-bit modes, 20-bit operands, and __int20. Rounding up to byte sizes > forces

[PATCH][ARM/AArch64 Testsuite] Fix vext[us]64_1.c test on ARM by unsharing test body

Moving into own thread from https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01895.html This fixes the compilation failures of gcc.target/arm/simd/vexts64_1.c and gcc.target/arm/simd/vextu64_1.c that I introduced in r by unsharing the test body on AArch64. (As [u]int64x1_t are vector types on AAr

[PATCH, ARM] Work around erratum in VFP9

The VFP9 floating-point unit (as occasionally used with ARM9 devices) has an erratum (760019) whereby it is possible for floating-point division and square-root instructions to be executed twice. This is not a problem if the destination register is not used as an input, but can cause incorrect res

[patch] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

Hello, From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include crtbegin.o and crtend.o unconditionally. libgcc/config.host includes crtbegin.o and crtend.o in extra_parts for i[34567]86-*-mingw* but not for x86_64-*-mingw*. Building a toolchain for x86_64-pc-mingw32 then rapidly

Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

Jason Merrill writes: > On 06/27/2014 03:27 AM, Dodji Seketeli wrote: >> + && print.prev_was_system_token != !!in_system_header_at(loc)) >> +/* The system-ness of this token is different from the one >> + of the previous token. Let's emit a line change to >> +

Re: [PATCH] rs6000: Fix the shift patterns, and add test

On Wed, Jul 2, 2014 at 5:06 PM, Segher Boessenkool wrote: > Firstly, it adds back the split conditions that I accidentally removed. > Without it the dot insns are never generated, or rather, always split > back to a separate compare instruction. > > Secondly, the shift amount should be SI always,

Re: [PATCH] [ARM] [RFC] Fix longstanding push_minipool_fix ICE (PR49423, lp1296601)

On 02/07/14 13:05, Charles Baylis wrote: > On 30 June 2014 14:26, Richard Earnshaw wrote: >> On 30/06/14 13:53, Charles Baylis wrote: >>> I see two options to fix it - one is to teach the back-end to >>> successfully generate code for this insn, and the other is to teach >>> the back-end that such

Re: More informative ODR warnings

+@opindex Wodr +@opindex Wno-odr +@opindex Wodr +Warn about One Definition Rule violations during link time optimization. +Require @option{-flto-odr-type-merging} to be enabled. Enabled by default Duplicated @opindex Wodr. (@item is missing) "Requires". Period after "default" But according to cur

Re: [PATCH]Enable elimination of IV use with unsigned type candidate

On Tue, Jul 1, 2014 at 10:32 AM, Bin.Cheng wrote: > Sorry for this late reply, I spent some time in understanding the problem. > > On Tue, Jun 24, 2014 at 12:36 PM, Richard Biener > wrote: >> On Mon, Jun 23, 2014 at 11:49 AM, Bin Cheng wrote: > >>> expressions. It's possible to have iv_eliminat

Re: [Patch AArch64_be] Fix some vec_concat big-endian confusions

*ping* Thanks, James On Tue, Jun 24, 2014 at 09:45:28AM +0100, James Greenhalgh wrote: > > Hi, > > vec_concat ( { a, b }, { c, d }) should give a new vector { a, b, c, d }. > > On big-endian aarch64 targets, we have to think carefully about what this > means as we map GCC's view of endian-ness

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-03 16:07 GMT+04:00 Uros Bizjak : > On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich wrote: > >> I didn't find a nice way to fix peephole2 patterns to take register >> constraints into account. Is there any way to do it? > > Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint.

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

On Thu, Jul 3, 2014 at 2:43 PM, FX wrote: > Here’s an updated patch, providing support for underflow control in the > IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc. > > Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha. The testcase still needs: ! { d

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

Here’s an updated patch, providing support for underflow control in the IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc. Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha. OK to commit? underflow.ChangeLog Description: Binary data underflow.diff Des

Normalize interface for all *-dg-runtest

Hi! I have a need to pass »flags« to a gfortran-dg-runtest call, but found that not to be possible as the *-dg-runtest interfaces are "narrowed" compared to dg-runtest. Here is a patch to fix that. So far only tested in libgomp. OK in principle? I'll then test this thoroughly, and, of course,

Re: [PATCH] Memory leak in parallel/unique_copy

On 03/07/14 13:40 +0100, Goncalo Carvalho wrote: Hi, Many thanks! I'll try add a test to the suite (unsure how foolproof will be in terms of detecting memory usage). Yes, it might not be worth adding to the testsuite, but I want to be able to verify the patch changes something :-) The 11000

Re: gfortran-dg-runtest, torture options

On Thu, Jul 03, 2014 at 02:37:41PM +0200, Thomas Schwinge wrote: > OK to document as follows? > > 2014-07-03 Jakub Jelinek > > libgomp/ > * testsuite/libgomp.fortran/fortran.exp: Explain > gfortran-dg-runtest usage. You wrote the patch, so put your name on it. Ok with that

Re: [PATCH] Memory leak in parallel/unique_copy

Hi, Many thanks! I'll try add a test to the suite (unsure how foolproof will be in terms of detecting memory usage). The 11000 is simply to go beyond the minimum unique_count needed to specialise the parallel version. This was on g++ (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6) but the issue still exis

Re: [PATCH PR61576]

Ping! 2014-06-24 13:37 GMT+04:00 Yuri Rumyantsev : > Hi All, > > Here is a fix for PR 61576 - additional test was added that block > containing reduction statement is predecessor of block containing phi > to choose the correct condition. > > Bootstrap and regression testing did not show any new fa

Re: gfortran-dg-runtest, torture options

Hi! On Thu, 3 Jul 2014 13:09:57 +0200, Jakub Jelinek wrote: > On Thu, Jul 03, 2014 at 01:06:48PM +0200, Thomas Schwinge wrote: > > On Thu, 3 Jul 2014 12:58:32 +0200, Jakub Jelinek wrote: > > > On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote: > > > > Thanks Janis and Mikael for yo

Re: [Patch, libgomp] libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}

Hi! On Thu, 3 Jul 2014 13:35:15 +0200, Jakub Jelinek wrote: > On Thu, Jul 03, 2014 at 12:19:15PM +0200, Thomas Schwinge wrote: > > I found the following to work (but so far only did libgomp testing), but > > that is a little bit more intrusive, but may actually be the right thing > > to do. (Pos

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich wrote: > I didn't find a nice way to fix peephole2 patterns to take register > constraints into account. Is there any way to do it? Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint. > Also fully restrict xmm8-15 does not seem rig

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-03 15:11 GMT+04:00 Uros Bizjak : > On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich wrote: > Silvermont processors have penalty for instructions having 4+ bytes of prefixes (including escape bytes in opcode). This situation happens when REX prefix is used in SSE4 instr

Re: [Patch, libgomp] libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}

On Thu, Jul 03, 2014 at 12:19:15PM +0200, Thomas Schwinge wrote: > I found the following to work (but so far only did libgomp testing), but > that is a little bit more intrusive, but may actually be the right thing > to do. (Possibly also in additional places where ${tool}_target_compile > is used

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

Hello! >> There is already a higher priority for registers not requiring REX. >> My patch affects cases when compiler has to use xmm8-15 and it just >> tries to say LRA to assign them for non SSE4 instructions. I doubt it >> would have some use for other targets than Silvermont. > > When it is ju

Re: [PATCH] Add guality [p]type test.

On Thu, 2014-07-03 at 12:05 +0200, Jakub Jelinek wrote: > On Thu, Jul 03, 2014 at 11:53:29AM +0200, Mark Wielaard wrote: > > I pulled out the guality.exp [p]type test extension from the actual > > dwarf2out.c changes (which I will repost soon with some tweaks). I think > > the test extension itself

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich wrote: >>> Silvermont processors have penalty for instructions having 4+ bytes of >>> prefixes (including escape >>> bytes in opcode). This situation happens when REX prefix is used in SSE4 >>> instructions. This >>> patch tries to avoid such sit

Re: gfortran-dg-runtest, torture options

On Thu, Jul 03, 2014 at 01:06:48PM +0200, Thomas Schwinge wrote: > On Thu, 3 Jul 2014 12:58:32 +0200, Jakub Jelinek wrote: > > On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote: > > > Thanks Janis and Mikael for your replies (nearly a year ago...), but > > > still my questions remain

Re: [Patch ARM-AArch64/testsuite v2 03/21] Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub.

On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon wrote: > > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog > index 44c4990..73709c6 100644 > --- a/gcc/testsuite/ChangeLog > +++ b/gcc/testsuite/ChangeLog > @@ -1,5 +1,16 @@ > 2014-06-30 Christophe Lyon > > + * gcc.target/aa

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-03 14:56 GMT+04:00 Jakub Jelinek : > On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote: >> 2014-07-02 20:21 GMT+04:00 Andi Kleen : >> > Ilya Enkovich writes: >> > >> >> Silvermont processors have penalty for instructions having 4+ bytes of >> >> prefixes (including escape bytes

Re: [Patch ARM-AArch64/testsuite v2 02/21] Add unary operators: vabs and vneg.

On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon wrote: > > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog > index 3a0f99b..44c4990 100644 > --- a/gcc/testsuite/ChangeLog > +++ b/gcc/testsuite/ChangeLog > @@ -1,5 +1,11 @@ > 2014-06-30 Christophe Lyon > > + * gcc.target/aa

Re: gfortran-dg-runtest, torture options

Hi! On Thu, 3 Jul 2014 12:58:32 +0200, Jakub Jelinek wrote: > On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote: > > Thanks Janis and Mikael for your replies (nearly a year ago...), but > > still my questions remain to be answered: in my understanding, the > > libgomp testsuite is n

Re: gfortran-dg-runtest, torture options

On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote: > Thanks Janis and Mikael for your replies (nearly a year ago...), but > still my questions remain to be answered: in my understanding, the > libgomp testsuite is not the place for compiler torture testing > (different optimization fl

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote: > 2014-07-02 20:21 GMT+04:00 Andi Kleen : > > Ilya Enkovich writes: > > > >> Silvermont processors have penalty for instructions having 4+ bytes of > >> prefixes (including escape bytes in opcode). This situation happens > >> when REX

Re: [PATCH] Implement -fsanitize=bounds and internal calls in FEs

On Thu, Jul 03, 2014 at 12:46:35PM +0200, Jakub Jelinek wrote: > On Thu, Jul 03, 2014 at 12:41:46PM +0200, Marek Polacek wrote: > > On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote: > > > On Fri, 20 Jun 2014, Marek Polacek wrote: > > > +@item -fsanitize=bounds > > > +@opindex fsanitiz

Re: gfortran-dg-runtest, torture options

Hi! On Tue, 13 Aug 2013 13:06:30 +0200, I wrote: > I noticed something strange in the libgomp testresults (but not > necessarily specific to libgomp): an "arbitrary" set of the Fortran > execution tests are run just for -O, and others for each of the full set > of torture options: -O0, -O1, -O2, a

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-02 20:27 GMT+04:00 Jakub Jelinek : > On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote: >> Ilya Enkovich writes: >> >> > Silvermont processors have penalty for instructions having 4+ bytes of >> > prefixes (including escape bytes in opcode). This situation happens >> > when REX p

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-02 20:21 GMT+04:00 Andi Kleen : > Ilya Enkovich writes: > >> Silvermont processors have penalty for instructions having 4+ bytes of >> prefixes (including escape bytes in opcode). This situation happens >> when REX prefix is used in SSE4 instructions. This patch tries to >> avoid such si

Re: [PATCH] Memory leak in parallel/unique_copy

On 02/07/14 22:42 +0100, Goncalo Carvalho wrote: Hi, In parallel/unique_copy.h __counter is never deleted. I'm also trying to follow from other posts how to submit a patch but is well possible I missed some of the conventions. Many apologies if that's the case. Thanks for this, it looks corre

Re: [PATCH] Implement -fsanitize=bounds and internal calls in FEs

On Thu, Jul 03, 2014 at 12:41:46PM +0200, Marek Polacek wrote: > On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote: > > On Fri, 20 Jun 2014, Marek Polacek wrote: > > +@item -fsanitize=bounds > > +@opindex fsanitize=bounds > > + > > +This option enables instrumentation of array bounds.

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-02 21:03 GMT+04:00 Uros Bizjak : > Hello! > >> Silvermont processors have penalty for instructions having 4+ bytes of >> prefixes (including escape >> bytes in opcode). This situation happens when REX prefix is used in SSE4 >> instructions. This >> patch tries to avoid such situation by

Re: [PATCH] Implement -fsanitize=bounds and internal calls in FEs

On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote: > On Fri, 20 Jun 2014, Marek Polacek wrote: > +@item -fsanitize=bounds > +@opindex fsanitize=bounds > + > +This option enables instrumentation of array bounds. Various out of bounds > +accesses are detected. Flexible array members ar

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

On Thu, Jul 3, 2014 at 12:26 PM, FX wrote: >> I'd suggest to name this fie ieee_underflow_1.f90 for consistency. > > In fact, since the directory is called ieee/, I think I’ll rename the others > so they don’t all start with ieee_ > > >> BTW: underflow control also works on alpha, using following

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

> I'd suggest to name this fie ieee_underflow_1.f90 for consistency. In fact, since the directory is called ieee/, I think I’ll rename the others so they don’t all start with ieee_ > BTW: underflow control also works on alpha, using following code: Could you test the attached libgfortran/confi

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

On Thu, Jul 3, 2014 at 11:42 AM, FX wrote: >> (I don't think -O0 is needed, but have to check with a testsuite run.) > > On x86_64-apple-darwin, -O0 or -O1 are needed: at -O2 my “use_real” call is > optimized out anyway, and the division simplified at compile time. You can mark variables with:

Re: [Patch, libgomp] libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}

Hi! On Wed, 2 Jul 2014 21:14:11 +0200, Tobias Burnus wrote: > Thomas Schwinge wrote: > > Reopening this oldie: > > > >> index 5fa42f4..68440d18 100644 > >> --- a/libgomp/testsuite/libgomp.fortran/fortran.exp > >> +++ b/libgomp/testsuite/libgomp.fortran/fortran.exp > >> @@ -14,6 +14,7 @@ set quadm

Re: [PATCH] Don't ICE with huge alignment (PR middle-end/60226)

On Mon, Jun 30, 2014 at 03:40:18PM -0700, Mike Stump wrote: > I glanced at it: > > (gdb) p/x TYPE_ALIGN (type) > $1 = 2147483648 > (gdb) p/x TYPE_ALIGN (type) > $2 = 0x8000 > > The callee is int, the caller uses unsigned int. The assert I see is because > the routines are not type correct:

Re: [i386] Replace builtins with vector extensions

Hello Marc, On 28 Jun 12:42, Marc Glisse wrote: > It would enable a number of optimizations, like constant > propagation, FMA contraction, etc. It would also allow us to remove > several builtins. This should be main motivation for replacing built-ins. But this approach IMHO should only be used for

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

On Thu, Jul 3, 2014 at 11:25 AM, Uros Bizjak wrote: >> The attached patch provides support for underflow control in the >> IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base). >> Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase. > Index: gcc/testsuite/g

Re: [PATCH] Don't ICE with huge alignment (PR middle-end/60226)

On Mon, Jun 30, 2014 at 01:50:12PM -0600, Jeff Law wrote: > On 03/04/14 09:40, Marek Polacek wrote: > >This should fix ICE on insane alignment. Normally, check_user_alignment > >detects e.g. alignment 1 << 32, but not 1 << 28. However, record_align > >is in bits, so it's actually 8 * (1 << 28) an

Re: [PATCH] Add guality [p]type test.

On Thu, Jul 03, 2014 at 11:53:29AM +0200, Mark Wielaard wrote: > I pulled out the guality.exp [p]type test extension from the actual > dwarf2out.c changes (which I will repost soon with some tweaks). I think > the test extension itself is useful on its own (and will use it to > add tests for my new

Re: [PATCH 1/2, x86] Add palignr support for AVX2.

The "expand_vec_perm_palignr" is similar for SSSE3 and AVX2 cases, but AVX2 requires more instructions to complete the scheme. The patch below adds AVX2 support for six instructions, leaving SSSE3 for two. Is it ok? diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 2cffcef..70f

[PATCH] Add guality [p]type test.

Hi, I pulled out the guality.exp [p]type test extension from the actual dwarf2out.c changes (which I will repost soon with some tweaks). I think the test extension itself is useful on its own (and will use it to add tests for my new patches). All new tests PASS, except when using -flto, so you'll

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

> (I don't think -O0 is needed, but have to check with a testsuite run.) On x86_64-apple-darwin, -O0 or -O1 are needed: at -O2 my “use_real” call is optimized out anyway, and the division simplified at compile time. FX

[PATCH, libbacktrace]: fix pointer from integer without a cast

Hello the following patch fixes some post-build-checks from our distro build system, better to upstream it: [ 4077s] E: rust 64bit-portability-issue /home/abuild/rpmbuild/BUILD/rust-0.11.0+git.1403898616.aa1163b/src/libbacktrace/dwarf.c:2690, 2873, 3005 [ 4077s] E: rust 64bit-portability-issue /h

Re: [C/C++ PATCH] Implement -Wsizeof-array-argument (PR c/6940)

On Wed, Jul 02, 2014 at 07:27:07PM -0700, Jason Merrill wrote: > On 06/26/2014 03:22 PM, Marek Polacek wrote: > >The following is a revamped patch for -Wsizeof-array-argument. > >Its purpose is to detect suspicious usage of the sizeof operator on an array > >function parameter. > > Then the name s

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

On Thu, Jul 3, 2014 at 11:06 AM, FX wrote: > Hi all, > > The attached patch provides support for underflow control in the > IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base). > Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase. +int +support_fpu_underfl

[fortran,patch] Support for IEEE underflow control on x86/x86_64

Hi all, The attached patch provides support for underflow control in the IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base). Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase. OK to commit? FX underflow.ChangeLog Description: Binary data underflow

Re: [PATCH, x86] Improves x86 permutation expand

The following patch should fix 61618 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 8046c67..2cffcef 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -43211,12 +43211,10 @@ expand_vec_perm_pblendv (struct exp

[C++ Patch] PR 51448, 53618, 58059 (Take 2)

Hi again, this is IMHO more spot-on, because I figured out where exactly things go wrong as part of the most_specialized_class call. In complete analogy with the get_bindings case for functions, the problem happens in get_class_bindings, thus I added a simple push_tinst_level check around the

Re: [AArch64,PATCH] Refactor acquire/release determination into output template

On 4 June 2014 01:07, Jones, Joel wrote: > There is duplicate code for determining whether a load or store > instruction needs acquire or release semantics. This patch removes the > duplicated code and uses a modifying operator to output a/l instead. Since > the testsuite already contains test

Re: combination of read/write and earlyclobber constraint modifier

On 03-07-14 10:20, Marcus Shawcroft wrote: On 2 July 2014 09:02, Tom de Vries wrote: On 02-07-14 08:23, Marc Glisse wrote: In the first example you gave, looking at the pattern (no match_dup, setting the full register), it seems that it may have wanted "=&" instead of "+&". [ move discussi

Re: combination of read/write and earlyclobber constraint modifier

On 2 July 2014 09:02, Tom de Vries wrote: > On 02-07-14 08:23, Marc Glisse wrote: >> >> In the first example you gave, looking at the pattern (no match_dup, >> setting the >> full register), it seems that it may have wanted "=&" instead of "+&". > > > [ move discussion from gcc ml to gcc-patches m

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On Thu, Jul 03, 2014 at 09:41:15AM +0200, Richard Biener wrote: > On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek wrote: > >On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote: > >> I think that makes sense; I'm not aware of anyone working on > >improving LTO > >> debugging. > > > >I thin

Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.

On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek wrote: >On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote: >> I think that makes sense; I'm not aware of anyone working on >improving LTO >> debugging. > >I think at this point all we care about is that with -flto we don't ICE >on >those,