Re: Add VIEW_CONVERT_EXPR to operand_equal_p

On Thu, Oct 29, 2015 at 12:31 PM, Richard Biener wrote: > On Thu, Oct 29, 2015 at 12:22 PM, Richard Biener > wrote: >> On Thu, Oct 29, 2015 at 4:39 AM, Jan Hubicka wrote: > Added and comitted now. Thanks.

Re: PATCH: Fix cross build for CXX_FOR_BUILD != CXX

On 23/10/15 16:41, H.J. Lu wrote: > On Fri, Oct 23, 2015 at 7:23 AM, Marcus Shawcroft > wrote: >> On 23 October 2015 at 13:34, H.J. Lu wrote: >>> On Fri, Oct 23, 2015 at 4:54 AM, Marcus Shawcroft >>> wrote: Hi,

Re: [Boolean Vector, patch 1/5] Introduce boolean vector to be used as a vector comparison type

On 28 Oct 22:37, Ilya Enkovich wrote: > Seems the problem occurs in this check in expand_vector_operations_1: > > /* A scalar operation pretending to be a vector one. */ > if (VECTOR_BOOLEAN_TYPE_P (type) > && !VECTOR_MODE_P (TYPE_MODE (type)) > && TYPE_MODE (type) != BLKmode) >

Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check

On 29/10/15 14:00, Marcus Shawcroft wrote: On 29 October 2015 at 13:50, Kyrill Tkachov wrote: Ok for trunk? rtl.h exposes reg_or_subregno() already doesn't that do what we need here? reg_or_subregno assumes that what it's passed is REG or a SUBREG. It will ICE on

Re: [C++ Patch] PR 67845

OK. Jason

[Patch] [x86_64] libgcc changes to add znver1

Hi Uros, As per your comments in https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02326.html please find the patch that also adds changes to libgcc. It was bootstrapped and regressed tested on x86_64. Ok for trunk? Change logs gcc/ChangeLog 2015-10-29 Venkataramanan Kumar

Re: [PATCH v2] [PR debug/67192] Fix C loops' back-jump location

Ping: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html On Fri, Oct 23 2015, Andreas Arnez wrote: > After parsing an unconditional "while"- or "for"-loop, the C front-end > generates a backward-goto statement and implicitly sets its location to > the current input_location. But in

Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check

On 28 October 2015 at 10:07, Kyrill Tkachov wrote: > Hi all, > > This RTL checking error occurs on aarch64 in aarch_accumulator_forwarding > when processing an msubsi insn > with subregs: > (insn 15 14 16 3 (set (reg/v:SI 78 [ i ]) > (minus:SI (subreg:SI (reg/v:DI

Re: [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279)

On Thu, Oct 29, 2015 at 11:38 AM, Tom de Vries wrote: > [ quote-pasted from https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00464.html > ] > >> CAST_RESTRICT based disambiguation unfortunately isn't reliable, >> e.g. to store a non-restrict pointer into a restricted field,

Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check

On 29 October 2015 at 13:50, Kyrill Tkachov wrote: >>> Ok for trunk? >> >> rtl.h exposes reg_or_subregno() already doesn't that do what we need here? > > > reg_or_subregno assumes that what it's passed is REG or a SUBREG. > It will ICE on any other rtx. Here I want to

[PATCH] Fix PR68142

This avoids simplifying 2 * (a * (__INT_MAX__/2 + 1)) to a * INT_MIN which introduces undefined overflow for a == -1. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-10-29 Richard Biener PR middle-end/68142 * fold-const.c

Re: [gomp4 00/14] NVPTX: further porting

On Thu, 29 Oct 2015, Jakub Jelinek wrote: > > rather provide a dummy 'usleep' under #ifdef __nvptx__. WDYT? > > Such ifdefs aren't really easily possible in OpenMP right now, the > preprocessing is done with the host compiler only, you'd need to arrange for > usleep being defined only in the PTX

Re: PATCH: Fix cross build for CXX_FOR_BUILD != CXX

On Thu, Oct 29, 2015 at 5:05 AM, Richard Earnshaw wrote: > On 23/10/15 16:41, H.J. Lu wrote: >> On Fri, Oct 23, 2015 at 7:23 AM, Marcus Shawcroft >> wrote: >>> On 23 October 2015 at 13:34, H.J. Lu wrote: On

Re: [Patch, committed] PR67933

On Thu, 2015-10-29 at 12:18 +0100, Dominique d'Humières wrote: > > > The recent patches on trunk to gfc_trans_allocate have fixed PR67933. > > > I have added a testcase, which has been committed as revision 229452. > > > > This test case fails at runtime on powerpc64le-linux-gnu. … > This should

[PATCH] Fix c-c++-common/torture/vector-compare-1.c on powerpc

Hi, This patches powerpc fails for c-c++-common/torture/vector-compare-1.c test. The problem is that vector comparison lowering produces vector of 0s and 1s instead of 0s and -1s. It doesn't matter if it usage is also lowered (like happens on ARM and i386 with -mno-sse) byt on powerpc we may

Re: [PATCH], PowerPC IEEE 128-bit patch #9 (enable __float128 by default on VSX systems)

Hi! On Tue, Oct 27, 2015 at 06:31:41PM -0400, Michael Meissner wrote: > Index: gcc/testsuite/gcc.target/powerpc/float128-1.c > === > --- gcc/testsuite/gcc.target/powerpc/float128-1.c (revision 0) > +++

[gomp4] revert num_gangs, num_workers, vector_length and num_threads parser changes in c/c++

In gomp-4_0-branch, we've tried to consolidate the parsing all of the clauses of the form foo (int-expression) into a single c*_parser_omp_positive_int_clause function. At the time, such clauses included num_gangs, num_workers, vector_length and num_threads. Looking at OpenMP 4.5, there are

Re: [PATCH] New attribute to create target clones

On Mon, Oct 26, 2015 at 6:50 PM, Jeff Law wrote: > On 10/12/2015 05:35 PM, Evgeny Stupachenko wrote: >> >> Hi All, >> >> Here is a new version of patch (attached). >> Bootstrap and make check are in progress (all new tests passed). >> >> New test case g++.dg/ext/mvc4.C fails with

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

On Thu, Oct 29, 2015 at 12:22 PM, Richard Biener wrote: > On Thu, Oct 29, 2015 at 4:39 AM, Jan Hubicka wrote: >>> > Added and comitted now. >>> >>> Thanks. Now on to the wrong code issues. :-) >>> >>> Up to the change, the useless_type_conversion_p

Re: [PATCH, 1/6] Simplify constraint handling

On 29/10/15 12:13, Richard Biener wrote: On Wed, 28 Oct 2015, Tom de Vries wrote: >On 28/10/15 16:35, Richard Biener wrote: > >On Tue, 27 Oct 2015, Tom de Vries wrote: > > > > >On 27/10/15 13:24, Tom de Vries wrote: > > > >Thinking it over a bit more, I realized the constraint handling

Re: [PATCH] Pass manager: add support for termination of pass list

On Thu, Oct 29, 2015 at 10:49 AM, Martin Liška wrote: > On 10/28/2015 04:23 PM, Richard Biener wrote: >> On Tue, Oct 27, 2015 at 4:30 PM, Martin Liška wrote: >>> On 10/27/2015 03:49 PM, Richard Biener wrote: On Tue, Oct 27, 2015 at 1:36 PM, Martin Liška

Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check

Hi Marcus, On 29/10/15 13:46, Marcus Shawcroft wrote: On 28 October 2015 at 10:07, Kyrill Tkachov wrote: Hi all, This RTL checking error occurs on aarch64 in aarch_accumulator_forwarding when processing an msubsi insn with subregs: (insn 15 14 16 3 (set (reg/v:SI 78 [

Re: [PATCH, 1/6] Simplify constraint handling

On Thu, 29 Oct 2015, Tom de Vries wrote: > On 29/10/15 12:13, Richard Biener wrote: > > On Wed, 28 Oct 2015, Tom de Vries wrote: > > > > > >On 28/10/15 16:35, Richard Biener wrote: > > > > > >On Tue, 27 Oct 2015, Tom de Vries wrote: > > > > > > > > > > > > > >On 27/10/15 13:24, Tom de Vries

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #16

On Fri, Oct 23, 2015 at 2:03 PM, Michael Meissner wrote: > This patch adds a test to make sure __float128 are passed and returned like > vector objects, and not as IBM extended double did. > > This is the last subpatch of patch #7. I have bootstrapped the compiler

[committed] Remove redundant variable from tree-call-cdce.c

shrink_wrap_one_built_in_call had both guard_bb and guard_bb0. It looks like an earlier version of the pass may have updated one of the variables in the while loop, but now they're just two names for the same thing. Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi. Committed as

Re: Robustify REAL_MODE_FORMAT

On 10/29/2015 04:30 PM, Richard Sandiford wrote: Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid mode, rather than stepping beyond the bounds of an array. It turned out that some code was passing non-float modes to the real.h routines. gcc/ * real.h

Re: [PING][PATCH][4.9]Backport "Fix register corruption bug in ree"

On Thu, Jun 4, 2015 at 2:16 PM, Renlin Li wrote: > Ping ~ > > Can somebody review it? Thank you! > > Regards, > Renlin Li > > > On 16/04/15 10:32, Renlin Li wrote: >> >> Ping~ >> >> Regards, >> Renlin Li >> >> On 16/04/15 10:09, wrote: >>> >>> Ping~ >>> Anybody has time to

[libgomp] task scheduler rewrite and task priorities implementation

Yo! As promised, here is the work implementing a new API for the task scheduler, rewriting the scheduler to fit into this new API, and implementing the task priorities that are in OpenMP > 4.1. There are also lots of cleanups and documentation. For the record, task priorities allow a

[PATCH, trivial] Cleanup fipa-pta constraint dumping

Hi, Consider testcase: ... int __attribute__((noinline, noclone)) foo (int *__restrict__ a, int *__restrict__ b) { *a = 1; *b = 2; } int __attribute__((noinline, noclone)) bar (int *a, int *b) { foo (a, b); } ... Using this patch we have this diff in the pta dumpfile: ... @@ -24,7 +24,7

Re: Allow real_format to be passed to more real.h functions

On October 29, 2015 4:53:59 PM GMT+01:00, Richard Sandiford wrote: >Most real.h routines used machine modes to specify the format of >an operation and converted that to a float_format * internally. >Some also had alternative versions that accepted a float_format *. >

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #06

On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner wrote: > This patch sets up all of the emulation functions. > > I have built the compiler with this patch and the previous subpatches (1-4). > I > have bootstrapped the compiler with all 16 subpatches installed, and

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #09

On Fri, Oct 23, 2015 at 1:47 PM, Michael Meissner wrote: > This patch is the new patch from the last submission. It sets up a hook so > that > the compiler will not allow IBM extended double and IEEE 128-bit floating > point > to intermix in a binary expression

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #07

On Fri, Oct 23, 2015 at 1:43 PM, Michael Meissner wrote: > This patch updates to use the unordered comparison function for IEEE 128-bit > floating point to mimic the behaviour of SFmode/DFmode using the fcmpu > instruction. > > It also restructures the code to allow a

Require c99_runtime for builtin-convert-1.c

...which was failing on *-elf. This test is making sure that we narrow maths calls, e.g. sinh -> sinhf, but we can only do that if we know that the target has a full c99 libm or if we have other proof that the function we want to generate is available. Tested on aarch64-none-elf (where it's

Re: Fix real_2expN mode arguments in fixed-value.c

On 10/29/2015 04:28 PM, Richard Sandiford wrote: * fixed-value.c (check_real_for_fixed_mode, fixed_from_string) (fixed_to_decimal, fixed_convert_from_real) (real_convert_from_fixed): Fix mode arguments to real_2expN. Passing VOIDmode rather than the real mode is a bit

[PATCH][ARM] Fix checking RTL error in cortex_a9_sched_adjust_cost

Hi all, An arm-none-eabi build with RTL checking and --with-cpu=cortex-a9 fails because cortex_a9_sched_adjust_cost tries to access the SET_DEST of a PARALLEL. The correct thing to do is to call single_set on dep, which will return a simple SET that we can take the SET_DEST of or NULL if

Re: [Docs] Reword the documentation for -fdump-rtl-

On 10/29/2015 09:52 AM, James Greenhalgh wrote: diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 76fdc31..148f063 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -6665,17 +6665,19 @@ Says to make debugging dumps during compilation at times specified by @var{letters}.

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #15

On Fri, Oct 23, 2015 at 2:01 PM, Michael Meissner wrote: > This patch adds the documentation. > > I have built the compiler with this patch and the previous subpatches (1-14). > I have bootstrapped the compiler with all 16 subpatches installed, and there > were no

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

> > IMHO it was always wrong/fragile for backends to look at the actual arguments > to > decide on the calling convention. The backends should _solely_ rely on > gimple_call_fntype and its TYPE_ARG_TYPES here. > > Of course then there are varargs ... (not sure if we hit this here). Yep, you

Re: Require c99_runtime for builtin-convert-1.c

On Thu, Oct 29, 2015 at 4:12 PM, Richard Sandiford wrote: > ...which was failing on *-elf. This test is making sure that we narrow > maths calls, e.g. sinh -> sinhf, but we can only do that if we know that > the target has a full c99 libm or if we have other proof that

Fix real_2expN mode arguments in fixed-value.c

fixed-value.c was passing a fixed-point mode to the floating-point real_2expN routine. That didn't cause a problem in practice because all real_2expN did was check for decimal float modes, but it triggered a failure with an upcoming patch. Tested on x86_64-linux-gnu, arm-linux-gnueabi and

Robustify REAL_MODE_FORMAT

Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid mode, rather than stepping beyond the bounds of an array. It turned out that some code was passing non-float modes to the real.h routines. Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu. OK to install?

Allow real_format to be passed to more real.h functions

Most real.h routines used machine modes to specify the format of an operation and converted that to a float_format * internally. Some also had alternative versions that accepted a float_format *. In an upcoming patch it seemed more convenient for the callers I was adding to use float_format

Re: [PATCH][auto-inc-dec.c] Account for cost of move operation in FORM_PRE_ADD and FORM_POST_ADD cases

On 28/10/15 17:45, Kyrill Tkachov wrote: On 28/10/15 17:23, Christophe Lyon wrote: Hi Kyrill, Hi Christophe, On 26 October 2015 at 12:52, Kyrill Tkachov wrote: On 26/10/15 11:28, Bernd Schmidt wrote: On 10/26/2015 12:12 PM, Bernd Schmidt wrote: But isn't that

[Docs] Reword the documentation for -fdump-rtl-

Hi, The text for -fdump-rtl- is a little misleading about how much you can derive about pass ordering from the numbers on the dumps. This patch tries to update the text to clarify that (most of the time) you can quite happily derive execution order from these pass numbers. While I'm there I've

[PATCH][PR tree-optimization/67892] Use FSM threader to handle backedges

As as been noted in the past, the old jump threader's support for threading across a loop backedge introduces significant complexity. The most serious complexity is the need to handle processing statements a second time (as we come around the top of the loop). This requires invalidation

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #04

On Fri, Oct 23, 2015 at 1:36 PM, Michael Meissner wrote: > This patch allows SUBREG's for the reg_or_indexed_operand, which is used when > you have an integral value in a float/vector register, and you want to move > the > value (either via direct move on power8, or

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #14

On Fri, Oct 23, 2015 at 2:00 PM, Michael Meissner wrote: > This patch makes TFmode be fully switchable for comparisons. > > I have built the compiler with this patch and the previous subpatches (1-13). > I have bootstrapped the compiler with all 16 subpatches

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

On Thu, Oct 29, 2015 at 4:02 PM, Jan Hubicka wrote: >> >> IMHO it was always wrong/fragile for backends to look at the actual >> arguments to >> decide on the calling convention. The backends should _solely_ rely on >> gimple_call_fntype and its TYPE_ARG_TYPES here. >> >> Of

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

> On Thu, Oct 29, 2015 at 4:02 PM, Jan Hubicka wrote: > >> > >> IMHO it was always wrong/fragile for backends to look at the actual > >> arguments to > >> decide on the calling convention. The backends should _solely_ rely on > >> gimple_call_fntype and its TYPE_ARG_TYPES here.

Re: [PATCH 00/16] Unit tests framework (v3)

On Wed, 2015-10-28 at 12:38 +0100, Bernd Schmidt wrote: > On 10/27/2015 08:48 PM, David Malcolm wrote: > > The following patch kit adds a unit tests framework for gcc, > > as a new subdirectory below gcc/testsuite. > > So, as a general comment I think this would be a very good thing to > have,

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #05

On Fri, Oct 23, 2015 at 1:39 PM, Michael Meissner wrote: > This patch prevents the compiler from calling the IEEE 128-bit emulation > functions with the vector value in both GPRs and vector registers due to the > fact that the library function did not have a

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #02

On Fri, Oct 23, 2015 at 1:30 PM, Michael Meissner wrote: > This patch changes the switch from -mfloat128-software and -mfloat128-none to > be a binary switch, -mfloat128 and -mno-float128. It also provides some of > the > basic setup for IEEE types. It also removes

Re: [PATCH] Fix c-c++-common/torture/vector-compare-1.c on powerpc

On Thu, Oct 29, 2015 at 2:42 PM, Ilya Enkovich wrote: > Hi, > > This patches powerpc fails for c-c++-common/torture/vector-compare-1.c test. > The problem is that vector comparison lowering produces vector of 0s and 1s > instead of 0s and -1s. It doesn't matter if it

[PATCH] Remove fold () dispatch from fold_gimple_assign

After Index: gcc/gimple-fold.c === --- gcc/gimple-fold.c (revision 229518) +++ gcc/gimple-fold.c (working copy) @@ -398,7 +398,10 @@ fold_gimple_assign (gimple_stmt_iterator /* If we couldn't fold the RHS, hand over to

Re: [PATCH] Fix PR67600 testcase

> > Remove the 600k preprocessed headers. > > tested on x86_64 with -m32 and -m64, committed. Ah, thank you! I had shorter testcase but apparently managed to swap it for original one :( Honza > > Richard. > > 2015-10-28 Richard Biener > > *

Re: Fix real_2expN mode arguments in fixed-value.c

Bernd Schmidt writes: > On 10/29/2015 04:28 PM, Richard Sandiford wrote: >> * fixed-value.c (check_real_for_fixed_mode, fixed_from_string) >> (fixed_to_decimal, fixed_convert_from_real) >> (real_convert_from_fixed): Fix mode arguments to real_2expN. > > Passing

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #01

On Fri, Oct 23, 2015 at 1:26 PM, Michael Meissner wrote: > This patch is the rs6000.h changes. It makes the IEEE 128-bit floating point > type that can go in vector registers a 'vector' type, so that the address code > in rs6000.c that determines whether to use VSX

Fix X - (X / Y) * Y in match.pd

Hello, before we completely forget about it, this fixes the pattern as discussed around https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01459.html . Note that, as seen in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68008#c1 , we would sometimes like to allow a conversion between trunc_div

Re: Fix real_2expN mode arguments in fixed-value.c

On October 29, 2015 4:28:05 PM GMT+01:00, Richard Sandiford wrote: >fixed-value.c was passing a fixed-point mode to the floating-point >real_2expN routine. That didn't cause a problem in practice because >all real_2expN did was check for decimal float modes, but it

Re: [ARM] libgcc: include crtfastmath.o

On 29 October 2015 at 11:07, Ramana Radhakrishnan wrote: > On Thu, Oct 29, 2015 at 9:25 AM, Christophe Lyon > wrote: >> Hi, >> >> On arm*-*-eabi*, arm*-*-symbianelf*, arm*-*-rtems* targets, >> crtfastmath.o is not part of $extra_parts, which

Re: [PATCH v2] [PR debug/67192] Fix C loops' back-jump location

On 10/23/2015 11:14 AM, Andreas Arnez wrote: This patch adds a new parameter to c_finish_loop that expclitly specifies the location to be used for the loop iteration. All calls to c_finish_loop are adjusted accordingly. I think the general principle of this is probably ok. + bool is_braced

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #11

On Fri, Oct 23, 2015 at 1:52 PM, Michael Meissner wrote: > This patch changes the mangling for __float128. I came to the conclusion that > the current code is so tangled, that it would be better to use U10__float128 > rather than "e". However, if it is felt that we

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #13

On Fri, Oct 23, 2015 at 1:58 PM, Michael Meissner wrote: > This patch is the second part to allow TFmode to be IBM extended double or > IEEE > 128-bit floating point depending on switches. > > I have built the compiler with this patch and the previous subpatches

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #12

On Fri, Oct 23, 2015 at 1:57 PM, Michael Meissner wrote: > This patch is the first of two rs6000.md patches to straighten out the IFmode, > KFmode, and TFmode support. Part of the change is to change the iterator > names > to be easier to understand, using IEEE128,

Re: [PATCH] Pass manager: add support for termination of pass list

On 10/29/2015 02:15 PM, Richard Biener wrote: > On Thu, Oct 29, 2015 at 10:49 AM, Martin Liška wrote: >> On 10/28/2015 04:23 PM, Richard Biener wrote: >>> On Tue, Oct 27, 2015 at 4:30 PM, Martin Liška wrote: On 10/27/2015 03:49 PM, Richard Biener wrote: >

[committed] Remove unnecessary label from tree-call-cdce.c

Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu. Committed as preapproved by Richard B. Thanks, Richard gcc/ * tree-call-cdce.c (shrink_wrap_one_built_in_call): Remove unnecessary label. diff --git a/gcc/tree-call-cdce.c b/gcc/tree-call-cdce.c index

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #03

On Fri, Oct 23, 2015 at 1:33 PM, Michael Meissner wrote: > This patch defines 3 macros to tell the user whether -mfloat128 is enabled or > not, and whether long double is IBM extended double or IEEE 128-bit floating > point. > > I have built the compiler with this

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #10

On Fri, Oct 23, 2015 at 1:49 PM, Michael Meissner wrote: > This patch is part of the support needed to properly swap IEEE 128-bit > floating > point on little endian systems. Note, you will need the rs6000.md changes for > this to become effective. > > I have built

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #08

On Fri, Oct 23, 2015 at 1:45 PM, Michael Meissner wrote: > This patch adds support for using 'q' or 'Q' as a suffix for __float128 > constants, which is compatible with the existing x86_64 implmenetation of > their > __float128 support. > > I have built the compiler

Re: Fix X - (X / Y) * Y in match.pd

On Thu, Oct 29, 2015 at 4:06 PM, Marc Glisse wrote: > Hello, > > before we completely forget about it, this fixes the pattern as discussed > around https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01459.html . > > Note that, as seen in

Re: [PATCH, 1/6] Simplify constraint handling

On 29/10/15 14:12, Richard Biener wrote: On Thu, 29 Oct 2015, Tom de Vries wrote: >On 29/10/15 12:13, Richard Biener wrote: > >On Wed, 28 Oct 2015, Tom de Vries wrote: > > > > > >On 28/10/15 16:35, Richard Biener wrote: > > > > > >On Tue, 27 Oct 2015, Tom de Vries wrote: > > > > > > > > >

Re: [PATCH 6/9] ENABLE_CHECKING refactoring: generators

On 10/18/2015 05:55 PM, Mikhail Maltsev wrote: On 10/06/2015 03:56 PM, Richard Biener wrote: The generators should simply unconditionally check (not in generated files, of course). And the generated code parts should use flag_checking. Richard. genautomata has some macros similar to tree

[PATCH] lra: Don't remove the scratch in (mem:BLK (scratch))

LRA wants to replace SCRATCH registers with real registers. It should not do that with (mem:BLK (scratch)), which is special, not really a scratch register. I don't know if this patch handles this in the best place to handle it; I don't even know if it is really correct. It does solve the

Re: [PATCH] New attribute to create target clones

> Yes. This is not necessary. However that way we'll have the following > code in dispatcher: > cmpl$6, __cpu_model+4(%rip) > sete%al > movzbl %al, %eax > testl %eax, %eax > jle .L16 > movl$foo.target_clone.1, %eax > I think it is

Re: [PATCH] rs6000: Save the PIC reg when needed

On Thu, Oct 29, 2015 at 12:52 PM, Segher Boessenkool wrote: > The PIC reg (r30) needs to be saved whenever the prologue sets it up, > not just if it is used elsewhere in the function. Without this patch > the prologue for such a function will modify r30 without saving

Re: [Docs] Reword the documentation for -fdump-rtl-

On 10/29/2015 10:55 AM, James Greenhalgh wrote: diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 76fdc31..5549f17 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -6665,17 +6665,19 @@ Says to make debugging dumps during compilation at times specified by @var{letters}.

Re: [PATCH 1/4] -Wmisleading-indentation: don't warn in presence of entirely blank lines

On Thu, 2015-10-29 at 13:35 -0400, Patrick Palka wrote: > On Thu, Oct 29, 2015 at 12:49 PM, David Malcolm wrote: > > Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran > > into a few failures where the indentation, although bad, was arguably > > not

[PATCH 4/4] Add -Wmisleading-indentation to -Wall

Our documentation describes -Wall as enabling "all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros." I believe that -Wmisleading-indentation meets these criteria, and is likely

Re: [PING][PATCH][4.9]Backport "Fix register corruption bug in ree"

On October 29, 2015 4:37:08 PM GMT+01:00, Ramana Radhakrishnan wrote: >On Thu, Jun 4, 2015 at 2:16 PM, Renlin Li wrote: >> Ping ~ >> >> Can somebody review it? Thank you! >> >> Regards, >> Renlin Li >> >> >> On 16/04/15 10:32, Renlin Li wrote: >>>

Re: [PATCH 1/4] -Wmisleading-indentation: don't warn in presence of entirely blank lines

On 10/29/2015 10:49 AM, David Malcolm wrote: Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran into a few failures where the indentation, although bad, was arguably not misleading. In regrename.c:scan_rtx_address: 1308 case PRE_MODIFY: 1309/* If the

Re: [PATCH 2/4] Fix misleading indentation in tree-ssa-loop-unswitch.c

On 10/29/2015 10:49 AM, David Malcolm wrote: tree-ssa-loop-unswitch.c has this bad indentation at line 452: 449if (dump_file && (dump_flags & TDF_DETAILS)) 450 fprintf (dump_file, ";; Not unswitching, loop is not expected" 451 " to iterate\n");

Re: [PATCH 1/4] -Wmisleading-indentation: don't warn in presence of entirely blank lines

On Thu, Oct 29, 2015 at 1:35 PM, Patrick Palka wrote: > On Thu, Oct 29, 2015 at 12:49 PM, David Malcolm wrote: >> Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran >> into a few failures where the indentation, although bad, was

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #06

On Thu, Oct 29, 2015 at 10:33:48AM -0400, David Edelsohn wrote: > On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner > wrote: > > This patch sets up all of the emulation functions. > > > > I have built the compiler with this patch and the previous subpatches > >

[gomp4.5] Fix checking ICE with atomic in a template

Hi! This patch fixes an ICE, where c_finish_omp_atomic is called on a template for diagnostics purposes because the expressions aren't type dependent, but still calling save_expr on C++ trees is harmful (e.g. SCOPE_REF contains a type as one of the arguments, rather than expression). 2015-10-29

Re: [PATCH 1/4] -Wmisleading-indentation: don't warn in presence of entirely blank lines

On Thu, Oct 29, 2015 at 1:50 PM, Mike Stump wrote: > On Oct 29, 2015, at 10:42 AM, Patrick Palka wrote: >> However we should definitely not warn on >> >>if (foo) >> bar (); >> >> { >>baz (); >> } >> >> Since that is valid

[PATCH 1/4] -Wmisleading-indentation: don't warn in presence of entirely blank lines

Attempting to bootstrap gcc with -Wmisleading-indentation enabled I ran into a few failures where the indentation, although bad, was arguably not misleading. In regrename.c:scan_rtx_address: 1308 case PRE_MODIFY: 1309/* If the target doesn't claim to handle autoinc, this must be

[PATCH 3/4] Fix misleading indentation in tree-nested.c

tree-nested.c has this code: 2333 for (c = gimple_omp_taskreg_clauses (stmt); 2334 c; 2335 c = OMP_CLAUSE_CHAIN (c)) 2336if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_FIRSTPRIVATE 2337 || OMP_CLAUSE_CODE (c)

[PATCH 0/4] -Wmisleading-indentation

The following patches: * tweak -Wmisleading-indentation to suppress a kind of false positive that occurred in three places in gcc's source tree, and * fix the two remaining truly misleadingly-indented places where the warning fires * adds -Wmisleading-indentation to -Wall

Go patch committed: Use Go function closures for type hash/equal functions

This patch changes the type descriptor hash and equal functions from C code pointers to Go func values. This permits them to be set to a Go function closure. This is in preparation for the Go 1.5, so that we can use a closure for the hash/equal functions returned by the new reflect.ArrayOf

Re: PING: [PATCH] PR target/67215: -fno-plt needs improvements for x86

On 10/29/2015 03:25 AM, Ramana Radhakrishnan wrote: Actually this is even worse than I thought because it sounds like you're saying you knowingly checked something in while being aware it would break another port. Only when -fno-plt was used. So, that's a target independent feature in GCC !

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

On 10/29/2015 10:49 AM, David Malcolm wrote: Our documentation describes -Wall as enabling "all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros." I believe that

Re: [PATCH 1/4] -Wmisleading-indentation: don't warn in presence of entirely blank lines

On Oct 29, 2015, at 10:56 AM, Patrick Palka wrote: > On Thu, Oct 29, 2015 at 1:50 PM, Mike Stump wrote: >> On Oct 29, 2015, at 10:42 AM, Patrick Palka wrote: >>> However we should definitely not warn on >>> >>> if (foo) >>>

Go patch committed: Drop zero field from type descriptors

The gc Go library added a zero field to type descriptors for use by maps. It was added to gccgo in a library updated a while back, although gccgo never used it. The gc library has since dropped it. This patch removes it from gccgo. This is in preparation for an update to the Go 1.5 library.

[PATCH] libitm: Support sized delete.

This patch supports the sized variants of operator delete. Tested on x86_64-linux. Is this OK or is it completely sufficient to just call non-sized operator delete from libitm even if the program has a sized delete? (If the latter is the case, I would just remove the special handling for that

[PATCH 2/4] Fix misleading indentation in tree-ssa-loop-unswitch.c

tree-ssa-loop-unswitch.c has this bad indentation at line 452: 449if (dump_file && (dump_flags & TDF_DETAILS)) 450 fprintf (dump_file, ";; Not unswitching, loop is not expected" 451 " to iterate\n"); 452 return false; which leads to this

Re: Robustify REAL_MODE_FORMAT

Richard Biener writes: > On October 29, 2015 4:33:17 PM GMT+01:00, Bernd Schmidt > wrote: >>On 10/29/2015 04:30 PM, Richard Sandiford wrote: >>> Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid >>mode, >>> rather than stepping

[PATCH] [ARM] neon-testgen.ml typo

I noticed a comment typo in this file while using grep to look for other stuff. The typo is easy to fix. I tried running neon-testgen.ml to verify, but it is apparently no longer valid ocaml, as it doesn't work with the ocamlc 4.01.0 I have on Ubuntu 14.04. I get a syntax error. Someone who

[PATCH] rs6000: Save the PIC reg when needed

The PIC reg (r30) needs to be saved whenever the prologue sets it up, not just if it is used elsewhere in the function. Without this patch the prologue for such a function will modify r30 without saving it first, leading to disaster back in its callers. This happened in the testsuite for -m32

Re: PING: [PATCH] PR target/67215: -fno-plt needs improvements for x86

On 10/28/2015 07:14 PM, H.J. Lu wrote: On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote: On 10/29/2015 02:10 AM, H.J. Lu wrote: On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote: So I'll ask again, why did you commit a patch which you clearly knew

  1   2   >