This finally tries to solve the issue that PRE uses the VN tables
and their expression representation for insertion. While for VN
things like alignment and aliasing do not matter it is quite important
to insert expressions that are compatible with the original one which
means not blindly take the
On Wednesday 25 May 2016 14:32:54 Kyrill Tkachov wrote:
> Hi Thomas,
>
> On 25/05/16 14:26, Thomas Preudhomme wrote:
> > On Thursday 19 May 2016 17:59:26 Kyrill Tkachov wrote:
> >> Hi Thomas,
> >
> > Hi Kyrill,
> >
> > Please find an updated patch in attachment. ChangeLog entries are now as
> >
On Friday 20 May 2016 13:41:30 Kyrill Tkachov wrote:
> Hi Thomas,
>
> On 19/05/16 17:10, Thomas Preudhomme wrote:
> > On Wednesday 18 May 2016 11:47:47 Kyrill Tkachov wrote:
> >> Hi Thomas,
> >
> > Hi Kyrill,
> >
> > Please find below the updated patch and associated ChangeLog entry.
> >
> > **
On 06/07/16 16:55, Christophe Lyon wrote:
On 6 July 2016 at 17:44, Kyrill Tkachov wrote:
Hi all,
On 06/07/16 16:29, James Greenhalgh wrote:
On Wed, Jul 06, 2016 at 02:11:51PM +0100, Jiong Wang wrote:
The current vmaxnm/vminnm float intrinsics are implemented using
__builtin_aarch64_smax/min
On Thu, Jul 07, 2016 at 10:16:31AM +0100, Jiong Wang wrote:
> I was using dg-xfail-if, (the description is still using "marked as
> XFAIL"...),
> but later found it's actually broken under advsimd-intrinsics,
> UNRESOLVEDs are
> given at the same time instead of clean XFAIL, I suspect those dg-do-w
gcc/testsuite/ChangeLog:
2016-07-01 Martin Liska
* gfortran.dg/do_1.f90: Remove a corner case that triggers
an undefined behavior.
* gfortran.dg/do_3.F90: Likewise.
* gfortran.dg/do_check_11.f90: New test.
* gfortran.dg/do_check_12.f90: New test.
gcc/fortran/ChangeLog:
2016-07-01 Martin Liska
* trans-stmt.c (gfc_trans_do): Add expect builtin for DO
loops with step bigger than +-1.
gcc/testsuite/ChangeLog:
2016-07-01 Martin Liska
* gfortran.dg/predict-1.f90: Ammend the test.
* gfortran.dg/predict-2.
Hello.
As discussed in [1], I would like to change code emission from:
D.3428 = (*array)[0];
D.3429 = (*array)[1];
i = D.3428;
if (i <= D.3429)
{
while (1)
{
{
logical(kind=4) D.3432;
(*block)[(integer(kind=8)) i + -
Tested on Linux-x64.
2016-07-07 Ville Voutilainen
Implement std::optional.
* include/Makefile.am: Add optional to exported headers.
* include/Makefile.in: Likewise.
* include/std/optional: New.
* testsuite/20_util/optional/typedefs.cc: Likewise.
* testsuite/20_util/opti
Ping.
On Mon, Jun 27, 2016 at 06:51:01PM -0500, Segher Boessenkool wrote:
> Ping.
>
> On Wed, Jun 08, 2016 at 01:47:31AM +, Segher Boessenkool wrote:
> > This patch series introduces separate shrink-wrapping.
> >
> > There are many things the prologue/epilogue of a function do, and most of
>
> I'm still a little suprised people actually read ChangeLogs, but anyway
ChangeLogs are a very effective mean of knowing whether changes were intended
or instead made by mistake for example.
> I doubt people want to be spammed with a bunch more email just for some
> changes to ChangeLogs so I'l
On 7 July 2016 at 11:16, Jiong Wang wrote:
> On 06/07/16 16:55, Christophe Lyon wrote:
>>
>> On 6 July 2016 at 17:44, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>> On 06/07/16 16:29, James Greenhalgh wrote:
On Wed, Jul 06, 2016 at 02:11:51PM +0100, Jiong Wang wrote:
>
> T
On 7 July 2016 at 11:16, Jiong Wang wrote:
> On 06/07/16 16:55, Christophe Lyon wrote:
>>
>> On 6 July 2016 at 17:44, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>> On 06/07/16 16:29, James Greenhalgh wrote:
On Wed, Jul 06, 2016 at 02:11:51PM +0100, Jiong Wang wrote:
>
> T
On Wed, Jul 06, 2016 at 02:01:06PM +0200, Bernd Schmidt wrote:
> There's one thing I don't quite understand and which seems to have
> changed since v1:
>
> On 07/04/2016 02:19 PM, Dominik Vogt wrote:
> >@@ -1099,8 +1101,10 @@ expand_stack_vars (bool (*pred) (size_t), struct
> >stack_vars_data *da
marxin wrote:
> gcc/fortran/ChangeLog:
>
> 2016-07-01 Martin Liska
> * lang.opt (Wundefined-do-loop): New option.
>* resolve.c (gfc_resolve_iterator): Warn for Wundefined-do-loop.
> (gfc_trans_simple_do): Generate a c-style loop.
> (gfc_trans_do): Fix GNU coding style.
marxin wrote:
> gcc/fortran/ChangeLog:
> 2016-07-01 Martin Liska
>
> * trans-stmt.c (gfc_trans_do): Add expect builtin for DO
> loops with step bigger than +-1.
>
> gcc/testsuite/ChangeLog:
> 2016-07-01 Martin Liska
>
> * gfortran.dg/predict-1.f90: Ammend the test.
> *
Hi Andre,
I think you have a typo in your patch. I need to change :
+text_section->unnamed.data = "\t.section
.text,\"0x2006\",%%progbits";
into
+text_section->unnamed.data = "\t.section
.text,\"0x2006\",%progbits";
to make it works.
Regards
Mickael
On 06/30/2016 04:32 PM
Hi Andre,
Another feedback on your purecode patch.
You have to disable casesi pattern since then it will
generate wrong code with -mpure-code option.
Indeed it will generate an 'adr rx, .Lx' (aka
'subs rx, PC, #offset') which will not work in our
case since 'Lx' label is put in an .rodata sect
Hey,
As a first step of my GSOC project
(https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported the
gnulib library inside the gcc tree. I have created gnulib as a top level
directory which contains the necessary scripts to import the modules. It also
contains the necessary Makefi
On 07/07/16 12:36, Christophe Lyon wrote:
On 7 July 2016 at 11:16, Jiong Wang wrote:
I was using dg-xfail-if, (the description is still using "marked as
XFAIL"...),
but later found it's actually broken under advsimd-intrinsics, UNRESOLVEDs
are
given at the same time instead of clean XFAIL, I
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux following 18
trunk/6.x commits and committed them to gcc-5-branch.
Jakub
2016-07-07 Jakub Jelinek
Backported from mainline
2016-02-02 Segher Boessenkool
* c-c++-common/vector-compare-4.c: Prune
This patch fixes some spurious errors arising when class-wide preconditions
in an generic instance are overridden in a child instance.
The following must compile quietly:
gcc -c r.ads
---
generic package P is
type T1 is abstract tagged private;
procedure P1 (This : in out T1)
with
This change is aimed at clarifying the semantics of the -gnatn switch, both
in the code and in the documentation. In particular, it makes it explicit
that -gnatn only pertains to inter-unit inlining (inlining across modules)
and has no effect on intra-unit inlining (inlining within a given module)
On Thu, Jul 7, 2016 at 11:32 AM, marxin wrote:
> Hello.
>
> As discussed in [1], I would like to change code emission from:
>
> D.3428 = (*array)[0];
> D.3429 = (*array)[1];
> i = D.3428;
> if (i <= D.3429)
> {
> while (1)
> {
> {
>
On 07/01/2016 12:15 PM, Richard Biener wrote:
> IMHO using fold-convert in this case is bogus and ideally the testcase
> should have been diagnosed.
>
> fold_convertible_p has a comment
>
> /* Returns true, if ARG is convertible to TYPE using a NOP_EXPR. *
>
> but clearly it isn't generating ju
On 7 July 2016 at 14:54, Jiong Wang wrote:
>
>
> On 07/07/16 12:36, Christophe Lyon wrote:
>>
>> On 7 July 2016 at 11:16, Jiong Wang wrote:
>>>
>>>
>>> I was using dg-xfail-if, (the description is still using "marked as
>>> XFAIL"...),
>>> but later found it's actually broken under advsimd-intrin
On Thu, Jul 7, 2016 at 4:01 PM, Martin Liška wrote:
> On 07/01/2016 12:15 PM, Richard Biener wrote:
>> IMHO using fold-convert in this case is bogus and ideally the testcase
>> should have been diagnosed.
>>
>> fold_convertible_p has a comment
>>
>> /* Returns true, if ARG is convertible to TYPE u
Hi Kyrill,
Please find an updated version in attachment. Please note I made quite a few
other changes as well. The most important one was to add new ARMv8-M Baseline
only alternatives to the two movt insns in order to have non predicable output
template for ARMv8-M Baseline. I also inverted the
Ping.
From: Alan Hayward
To: "gcc-patches at gcc dot gnu dot org"
Date: Wed, 29 Jun 2016 08:49:34 +0100
Subject: [PATCH] PR 71667 - Handle live operations with DEBUG uses
Authentication-results: sourceware.org; auth=none
In vectorizable_live_operation() we always assume uses a of live operatio
On 07/07/16 15:13, Christophe Lyon wrote:
On 7 July 2016 at 14:54, Jiong Wang wrote:
On 07/07/16 12:36, Christophe Lyon wrote:
On 7 July 2016 at 11:16, Jiong Wang wrote:
I was using dg-xfail-if, (the description is still using "marked as
XFAIL"...),
but later found it's actually broken u
>
> Why is the behavior only undefined for step 1 if the last iteration IV
> increment overflows?
> Doesn't this apply to all step values?
This is what Fortran standard says:
The iteration count is established and is the value of the expression
(m2-m1+m3)/m3 unless that value is negative,
i
Hi,
this patch re-factors the TYPE_ALIGN_OK into a new TYPE_LANG_FLAG,
and removes one of the 9 parameters of get_inner_reference. It therefore
simplifies the middle end slightly.
It is quite a while ago, when I last proposed a similar patch, which focused
only on get_inner_referene. According
On 07/07/2016 08:53 AM, Bernd Edlinger wrote:
Hi,
this patch re-factors the TYPE_ALIGN_OK into a new TYPE_LANG_FLAG,
and removes one of the 9 parameters of get_inner_reference. It therefore
simplifies the middle end slightly.
It is quite a while ago, when I last proposed a similar patch, which
On Thu, Jul 07, 2016 at 02:13:12PM +0200, Tobias Burnus wrote:
> marxin wrote:
> > gcc/fortran/ChangeLog:
> >
> > 2016-07-01 Martin Liska
> > * lang.opt (Wundefined-do-loop): New option.
> >* resolve.c (gfc_resolve_iterator): Warn for Wundefined-do-loop.
> > (gfc_trans_simple_do
On Thu, Jul 07, 2016 at 02:58:17AM +, Segher Boessenkool wrote:
> Similar to PR70098, which is about integers in floating point registers,
> we can have the completely analogous problem with vector registers as well
> now that we allow integers in vector registers. So, this patch solves it
> i
On 20.06.2016 10:30, Trevor Saunders wrote:
> On Mon, Jun 20, 2016 at 09:25:17AM +0100, Kyrill Tkachov wrote:
>> Hi Trev,
>>
>> On 20/06/16 06:47, tbsaunde+...@tbsaunde.org wrote:
>>> From: Trevor Saunders
>>>
>>> Hi,
>>>
>>> later than I hoped, but here's the series to remove the targets obsolete
Hello,
As a follow up of
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01240.html,
This patch set adds ARMv8.2-A FP16 scalar and vector intrinsics support,
gcc middle-end will also be aware of some standard operations that some
instructions can be auto-generated.
According to ACLE, ARMv8.2-A F
Several data-processing instructions are agnostic to the type of their
operands. This patch add the mapping between them and those bit- and
lane-manipulation instructions.
No ARMv8.2-A FP16 extension hardware support is required for these
intrinsics.
gcc/
2016-07-07 Jiong Wang
* confi
This patch add ARMv8.2-A FP16 reduction vector intrinsics.
gcc/
2016-07-07 Jiong Wang
* config/aarch64/arm_neon.h (vmaxv_f16): New.
(vmaxvq_f16): Likewise.
(vminv_f16): Likewise.
(vminvq_f16): Likewise.
(vmaxnmv_f16): Likewise.
(vmaxnmvq_f16): Li
This patch add ARMv8.2-A FP16 two operands scalar intrinsics.
2016-07-07 Jiong Wang
gcc/
* config/aarch64/aarch64-simd-builtins.def: Register new builtins.
* config/aarch64/aarch64.md
(hf3): New.
(hf3): Likewise.
(add3): Likewise.
(sub3): Likewise.
This patch add ARMv8.2-A FP16 three operands scalar intrinsics.
gcc/
2016-07-07 Jiong Wang
* config/aarch64/aarch64-simd-builtins.def: Register new builtins.
* config/aarch64/aarch64.md (fma): New for HF.
(fnma): Likewise.
* config/aarch64/arm_fp16.h (vfmah_f16)
This patch adds ARMv8.2-A FP16 lane scalar intrinsics.
gcc/
2016-07-07 Jiong Wang
* config/aarch64/arm_neon.h (vfmah_lane_f16): New.
(vfmah_laneq_f16): Likewise.
(vfmsh_lane_f16): Likewise.
(vfmsh_laneq_f16): Likewise.
(vmulh_lane_f16): Likewise.
ARMv8.2-A adds support for scalar and vector FP16 instructions to ARM and
AArch64. This patch adds support for testing code for AArch64 targets
using the new instructions. It is based on the target-support code for
ARMv8.2-A added for ARM (AArch32).
The patch
- Updates effective-target directives
This patch contains testcases for those new scalar intrinsics which are only
available for AArch64.
gcc/testsuite/
2016-07-07 Jiong Wang
* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
(FP16_SUPPORTED):
Enable AArch64.
* gcc.target/aarch64/advsimd-intrinsics/vd
This patch contains testcases for those new vector intrinsics which are only
available for AArch64.
gcc/testsuite/
2016-07-07 Jiong Wang
* gcc.target/aarch64/advsimd-intrinsics/vdiv_f16_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vfmas_lane_f16_1.c: New.
* gcc.ta
This patch contains testcases for those new scalar intrinsics which are only
available for AArch64.
gcc/testsuite/
2016-07-07 Jiong Wang
* gcc.target/aarch64/advsimd-intrinsics/unary_scalar_op.inc:
Support FMT64.
* gcc.target/aarch64/advsimd-intrinsics/vabdh_f16_1.c: New.
This patch add ARMv8.2-A FP16 two operands vector intrinsics.
gcc/
2016-07-07 Jiong Wang
* config/aarch64/aarch64-simd-builtins.def: Register new builtins.
* config/aarch64/aarch64-simd.md
(aarch64_rsqrts): Extend to HF modes.
(fabd3): Likewise.
(3): Likewise.
(
This patch add ARMv8.2-A FP16 one operand vector intrinsics.
We introduced new mode iterators to cover HF modes, qualified patterns
which was using old mode iterators are switched to new ones.
We can't simply extend old iterator like VDQF to conver HF modes,
because not all patterns using VDQF a
This patch add ARMv8.2-A FP16 lane vector intrinsics.
Lane intrinsics are generally derivatives of multiply intrinsics,
including multiply accumulate. All necessary backend support for them
are there already except fmulx, the implementions are largely a
combination of existed multiply intrinsics
This patch add ARMv8.2-A FP16 one operand scalar intrinsics
Scalar intrinsics are kept in arm_fp16.h instead of arm_neon.h.
gcc/
2016-07-07 Jiong Wang
* config.gcc (aarch64*-*-*): Install arm_fp16.h.
* config/aarch64/aarch64-builtins.c (hi_UP): New.
* config/aarch64/aa
This patch add ARMv8.2-A FP16 three operands vector intrinsics.
Three operands intrinsics only contain fma and fms.
2016-07-07 Jiong Wang
gcc/
* config/aarch64/aarch64-simd-builtins.def: Register new builtins.
* config/aarch64/aarch64-simd.md (fma4): Extend to HF modes.
On 06/07/16 13:40, Kyrill Tkachov wrote:
On 06/07/16 13:31, Rainer Orth wrote:
Hi Kyrill,
On 05/07/16 12:24, Rainer Orth wrote:
Marc Glisse writes:
On Tue, 5 Jul 2016, Kyrill Tkachov wrote:
As for testing I've bootstrapped and tested the patch on aarch64 and
x86_64 with synth_shift_p i
On 07/07/16 17:40, Jeff Law wrote:
> On 07/07/2016 08:53 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this patch re-factors the TYPE_ALIGN_OK into a new TYPE_LANG_FLAG,
>> and removes one of the 9 parameters of get_inner_reference. It therefore
>> simplifies the middle end slightly.
>>
>> It is quite a
On Thu, Jul 7, 2016 at 12:32 PM, Jason Merrill wrote:
> Hmm, I wonder if walk_tree_1 should walk into DECL_EXPR like it does into
> BIND_EXPR_VARS. But your patch is OK.
>
> Jason
>
>
> On Fri, Jul 1, 2016 at 11:23 AM, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> As mentioned in the PR, we ICE on these
Committed to trunk.
* doc/xml/manual/status_cxx2014.xml: Update LFTS status table.
* doc/html/*: Regenerate.
(PMR support is only partial as we don't provide the two concrete
memory resource types).
commit 2b73ef0f620d5130a1afca4bf2ed43a35210ce29
Author: Jonathan Wakely
Date:
Hi all,
This testcase currently fails on GCC 5, for LE only. Since it is fixed
for 6 and later, and backporting the relevant code is rather invasive,
let's just weaken the testcase for GCC 5 instead.
Segher
2016-07-07 Segher Boessenkool
PR target/69019
* gcc.target/powerpc/t
On Thu, Jul 07, 2016 at 12:32:02PM -0400, Jason Merrill wrote:
> Hmm, I wonder if walk_tree_1 should walk into DECL_EXPR like it does into
> BIND_EXPR_VARS. But your patch is OK.
Well, walk_tree_1 does walk into DECL_EXPR, but cp_genericize_r says
*walk_subtrees on the VAR_DECL inside of it.
When
On Thu, Jul 7, 2016 at 2:23 PM, Jakub Jelinek wrote:
> On Thu, Jul 07, 2016 at 12:32:02PM -0400, Jason Merrill wrote:
>> Hmm, I wonder if walk_tree_1 should walk into DECL_EXPR like it does into
>> BIND_EXPR_VARS. But your patch is OK.
>
> Well, walk_tree_1 does walk into DECL_EXPR, but cp_generi
Hi,
PR71297 reports that we ICE when __builtin_vec_ld or __builtin_vec_st is
provided with an incorrect number of arguments. This patch fixes it by
bypassing special handling for these intrinsics when the number of
arguments is wrong, thus allowing the standard error handling for
builtins to kick
On Tue, Jun 28, 2016 at 10:00 AM, Richard Biener
wrote:
> On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek wrote:
>> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
>>> gimple_predicate
>>> rhs_predicate_for (tree lhs)
>>> {
>>> - if (is_gimple_reg (lhs))
>>> + if (will_be_gimpl
* Claudiu Zissulescu [2016-06-30 12:36:10
+0200]:
> Small patches batch.
>
> Ok to apply?
> Claudiu
>
> gcc/
> 2016-05-09 Claudiu Zissulescu
>
> * config/arc/arc.c (arc_process_double_reg_moves): Change.
> * config/arc/arc.md (movsi_insn): Disable unsupported move
> instr
On 07/03/2016 05:22 PM, Sandra Loosemore wrote:
On 07/01/2016 05:56 PM, Martin Sebor wrote:
The bug points out a couple of conformance problems in the GCC
manual where is discusses compound literals and casts to unions
and says that a compound literal is equivalent to a cast. It
isn't because a
Resending since I thinkoed Segher's email address. Sorry for the noise.
Bill
On Thu, 2016-07-07 at 14:11 -0500, Bill Schmidt wrote:
> Hi,
>
> PR71297 reports that we ICE when __builtin_vec_ld or __builtin_vec_st is
> provided with an incorrect number of arguments. This patch fixes it by
> bypa
The following patch corrects the constraint so that we only generate 'stxsiwx'
on Power8 or later hardware. Ok for trunk after successful bootstrap/regtest?
-Pat
2016-07-07 Pat Haugen
PR target/71800
* config/rs6000/rs6000.md (stfiwx): Change constraint to 'wu' to
p
On 7 July 2016 at 13:48, ayush goel wrote:
> In order to show the setup works, I’ve replaced libiberty’s version by
> obstack by gnulib’s. This was made possible by replacing the corresponding
> header file and then including gnulib headers and gnulib static library in
> the build path required
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux and committed
following backports from gcc-5-branch and trunk to gcc-4_9-branch:
Jakub
2016-07-07 Jakub Jelinek
Backported from mainline
2014-12-12 Richard Biener
PR middle-end/64280
* t
FT32 makes use of multiple address spaces. When trying to inspect
objects in GDB, GDB was treating them as a straight "const". The cause
seems to be in GCC DWARF2 output.
This output is handled in gcc/gcc/dwarf2out.c, where modified_type_die()
checks that TYPE has qualifiers CV_QUALS. However whil
On Fri, Jul 08, 2016 at 01:28:05AM +0930, Alan Modra wrote:
> BTW, both pr70098 and pr71763 are triggered by combine, not
> loop-doloop as I was thinking earlier. See rtl dumps for the
> testcases. I doubt the "optimization" done by combine here is worth
> keeping, since loop-doloop.c ought to al
This trivial patch removes the problem. As far as I can tell, looking at
-fdump-tree-original, the results are correct.
Regression tested on x86-64. I will add a test case from the PR.
I plan to commit to trunk and then backport after about a week if no
problems show up.
Regards,
Jerry
20
On Thu, Jul 07, 2016 at 03:40:28PM -0500, Bill Schmidt wrote:
> > PR71297 reports that we ICE when __builtin_vec_ld or __builtin_vec_st is
> > provided with an incorrect number of arguments. This patch fixes it by
> > bypassing special handling for these intrinsics when the number of
> > arguments
Hi Pat,
On Thu, Jul 07, 2016 at 03:42:55PM -0500, Pat Haugen wrote:
> The following patch corrects the constraint so that we only generate
> 'stxsiwx' on Power8 or later hardware. Ok for trunk after successful
> bootstrap/regtest?
I don't really understand this. Before, it required UPPER_REGS_
71 matches
Mail list logo
