On Tue, May 17, 2016 at 08:31:00PM -0400, John David Anglin wrote:
> r235550 introduced the use of long long, and the macros LLONG_MIN and
> LLONG_MAX. These macros
> are not defined by default and we need to include when compiling
> with c++ to define them.
IMNSHO we should get rid of those l
On Tue, May 17, 2016 at 11:21 AM, H.J. Lu wrote:
> On Tue, May 17, 2016 at 5:51 AM, Richard Biener wrote:
>>
>> The following fixes a latent issue in loop distribution catched by
>> the fake edge placement adjustment.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>>
>> Richa
On Tue, 17 May 2016, Matthew Wahab wrote:
> In some tests, there are unavoidable differences in precision when
> calculating the actual and the expected results of an FP16 operation. A
> new support function CHECK_FP_BIAS is used so that these tests can check
> for an acceptable margin of error. I
On Tue, 17 May 2016, Matthew Wahab wrote:
> As with the VFP FP16 arithmetic instructions, operations on __fp16
> values are done by conversion to single-precision. Any new optimization
> supported by the instruction descriptions can only apply to code
> generated using intrinsics added in this pat
On Wed, 18 May 2016, Joseph Myers wrote:
> But why do you need to force that? If the instructions follow IEEE
> semantics including for exceptions and rounding modes, then X OP Y
> computed directly with binary16 arithmetic has the same value as results
> from promoting to binary32, doing bina
On Tue, 17 May 2016, Matthew Wahab wrote:
> In most cases the instructions are added using non-standard pattern
> names. This is to force operations on __fp16 values to be done, by
> conversion, using the single-precision instructions. The exceptions are
> the precision preserving operations ABS a
r235550 introduced the use of long long, and the macros LLONG_MIN and
LLONG_MAX. These macros
are not defined by default and we need to include when compiling with
c++ to define them.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Okay for trunk?
Dave
--
John David Anglin dav
This patch has many improperly formatted diagnostic messages (e.g.
starting with capital letters, ending with '.' or failing to use %q for
quoting). I also note cases where you use %lu as a format for size_t,
which is not correct (you'd need to add pretty-print.c support for %zu
before you cou
On Mon, 16 May 2016, Pekka Jääskeläinen wrote:
> The diffstat is as follows:
I don't see any .texi files in this diffstat. New front ends need all
relevant documentation updated.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, May 17, 2016 at 06:45:49PM -0400, Michael Meissner wrote:
> As I mentioned in the last message, my previous patch had some problems that
> showed up on big endian systems, using RELOAD (one of the tests that failed
> was
> the vshuf-v32qi.c test in the testsuite). Little endian and IRA di
As I mentioned in the last message, my previous patch had some problems that
showed up on big endian systems, using RELOAD (one of the tests that failed was
the vshuf-v32qi.c test in the testsuite). Little endian and IRA did compiled
the test fine. This patch fixes the problem. I went over the a
On Tue, May 17, 2016 at 06:01:32PM -0400, David Malcolm wrote:
> This implements the libgccjit support for must-tail-call via
> a new:
> gcc_jit_rvalue_set_bool_require_tail_call
> API entrypoint.
It seems to me like that's not a great name, the rvalue and bool parts
are just about the argument
> I built cross-compilers for 30 targets, and built Linux with that.
> 6 of those failed for unrelated reasons. Of the 24 that do build,
> five show a few insns difference between having a cleanup_cfg before
> shrink-wrapping or not (CLEANUP_EXPENSIVE made no difference there).
> These targets are
On Tue, May 17, 2016 at 04:17:58AM -0500, Segher Boessenkool wrote:
> On Tue, May 17, 2016 at 11:08:53AM +0200, Eric Botcazou wrote:
> > > How would it? The shrink-wrapping algorithms do not much care how you
> > > write your control flow. The only things I can think of are drastic
> > > things l
Hi,
On 17/05/2016 20:15, Jason Merrill wrote:
On 05/17/2016 04:47 AM, Paolo Carlini wrote:
... alternately, if the substance of my patchlet is right, we could
simplify a bit the logic per the below.
Here's a well-formed variant that was accepted by 4.5. Does your
patch fix it? I also think
This patch moves part of the logic for determining if tail
call optimizations are possible to a new helper function.
There are no functional changes.
expand_call is 1300 lines long, so there's arguably a
case for doing this on its own, but this change also
enables the followup patch.
The patch c
This patch implements support for marking CALL_EXPRs
as being mandatory for tail-call-optimization. expand_call
tries harder to perform the optimization on such CALL_EXPRs,
and issues an error if it fails.
Currently this flag isn't accessible from any frontend,
so the patch uses a plugin for testi
This implements the libgccjit support for must-tail-call via
a new:
gcc_jit_rvalue_set_bool_require_tail_call
API entrypoint.
(I didn't implement a wrapper for this within the C++ bindings)
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
gcc/jit/ChangeLog:
* docs/topics/compa
There have been requests [1] for libgccjit to better support
functional programming by supporting the contination-passing style,
in which every function "returns" by calling a "continuation"
function pointer.
These calls must be guaranteed to be implemented as a jump,
otherwise the program could c
This adjusts a few more tests:
* I'd missed the optimization glob on a ptx skip-if, so it wasn't being skipped.
* An asm test relied on the register allocator being run to assign an input to
the same register as an output.
* An atomic test operated on automatic storage, which doesn't work on ptx
On 05/17/2016 02:22 PM, Andrew Pinski wrote:
> On Tue, May 17, 2016 at 2:10 PM, Cesar Philippidis
> wrote:
>> On 05/13/2016 01:13 PM, Andrew Pinski wrote:
>>> On Fri, May 13, 2016 at 12:58 PM, Richard Biener
>>> wrote:
On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
wrote:
>>>
On Tue, May 17, 2016 at 2:10 PM, Cesar Philippidis
wrote:
> On 05/13/2016 01:13 PM, Andrew Pinski wrote:
>> On Fri, May 13, 2016 at 12:58 PM, Richard Biener
>> wrote:
>>> On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
>>> wrote:
The cse_sincos pass tries to optimize sequences such
On 05/13/2016 01:13 PM, Andrew Pinski wrote:
> On Fri, May 13, 2016 at 12:58 PM, Richard Biener
> wrote:
>> On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
>> wrote:
>>> The cse_sincos pass tries to optimize sequences such as
>>>
>>> sin (x);
>>> cos (x);
>>>
>>> into a single call to
On 05/17/2016 06:09 PM, Richard Biener wrote:
>
> The patch is ok.
>
Committed as r236344.
--
Regards,
Mikhail Maltsev
Hi,
this ICE during error recovery exposes a rather more general weakness:
we should never call cp_lexer_peek_nth_token (*, 2) when a previous
cp_lexer_peek_token returns CPP_EOF.
The fix seems easy, just reshape a bit the condition and delay the
latter. It should also be a net, albeit minor
On 05/16/2016 07:09 PM, Segher Boessenkool wrote:
Make new functions make_split_prologue_seq, make_prologue_seq, and
make_epilogue_seq.
Tested as in the previous patch; is this okay for trunk?
Segher
2016-05-16 Segher Boessenkool
* function.c (make_split_prologue_seq, make_prolog
On 05/17/2016 03:04 AM, Bin Cheng wrote:
Hi,
After supporting all vcond/vcondu patterns in AArch64 backend, now we can
vectorize VEC_COND_EXPR with different type in comparison operands and value
operands on AArch64. GCC uses vect_cond_mixed to control such test cases, for
now, there are belo
On 14/05/2016 19:06, Daniel Krügler wrote:
2016-05-14 18:13 GMT+02:00 François Dumont :
New patch attached, tested under linux x86_64.
François
1) The function __clp2 is declared using _GLIBCXX14_CONSTEXPR, which
means that it is an inline function if and *only* if
_GLIBCXX14_CONSTEXPR really
Since Honza's change in r236012 we're able to expand thunks inline, and as
a side-effect we can redirect call within thunk to __buitin_unreachable (at
least that's my understanding ;).
But that means we need to employ the maybe_remove_unused_call_args function
so that we don't left __buitin_unreac
On 05/12/2016 06:34 PM, Martin Sebor wrote:
Attached is a resubmission of the patch for c++/60760 originally
submitted late in the 6.0 cycle along with a patch for c++/67376.
Since c++/60760 was not a regression, it was decided that it
would be safer to defer the fix until after the 6.1.0 release
libgccjit performs numerous checks at the API boundary, but
if these succeed, it ignores errors and other diagnostics emitted
within the core of gcc, and treats the compile of a gcc_jit_context
as having succeeded.
This patch ensures that if any diagnostics are emitted, they
are visible from the l
Every version of libgccjit.h in trunk has had
gcc_jit_context_new_call_through_ptr, but it wasn't
documented until now.
Committed to trunk as r236341.
gcc/jit/ChangeLog:
* docs/topics/expressions.rst (Function calls): Document
gcc_jit_context_new_call_through_ptr.
* docs/_
On 05/01/2016 12:39 PM, Martin Sebor wrote:
+ if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
+{
+ if (tree result = size_binop_loc (EXPR_LOC_OR_LOC (t, input_location),
+ opcode, arg0, arg1))
+ {
+ if (TREE_OVE
This is an implementation of the Standard is_swappable traits according to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html
During that work it has been found that std::array's member swap's exception
specification for zero-size arrays was incorrectly depending on the value_ty
On Tue, May 17, 2016 at 5:51 AM, Richard Biener wrote:
>
> The following fixes a latent issue in loop distribution catched by
> the fake edge placement adjustment.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2016-05-17 Richard Biener
>
> PR tree-op
On 05/17/2016 04:47 AM, Paolo Carlini wrote:
... alternately, if the substance of my patchlet is right, we could
simplify a bit the logic per the below.
Here's a well-formed variant that was accepted by 4.5. Does your patch
fix it? I also think with your patch we can drop the C++11 check, si
On May 17, 2016, at 8:19 AM, Sandra Loosemore wrote:
>
> I thought I remembered mail going by that changes to a release branch require
> RM approval too.
For time to time, the RM can close any release branch at any time for any
reason. :-) For example, a gcc 3.2.x release branch has been clo
Hi!
Tested on x86_64-linux, committed to gomp-4_5-branch.
2016-05-17 Jakub Jelinek
* trans-openmp.c (gfc_split_omp_clauses): Handle EXEC_OMP_TARGET_SIMD.
(gfc_trans_omp_teams): Don't wrap into OMP_TEAMS if -fopenmp-simd.
(gfc_trans_omp_target): Set OMP_TARGET_COMBINED
Hi!
On Thu, 28 Apr 2016 12:26:24 +0200, I wrote:
> Richard's r235511 changes (quoted below) cause certain nvptx offloading
> test cases to run into SIGSEGVs:
With these changes recently having been ported to gcc-6-branch in
r236210, these failures/regressions now also show up there:
> [...]
James Greenhalgh wrote:
> It would be handy if you could raise something in bugzilla for the
> register allocator deficiency.
The register allocation issues are well known and we have multiple
workarounds for this in place. When you allow modes to be tieable
the workarounds are not as effective.
ping
From: Wilco Dijkstra
Sent: 22 April 2016 16:35
To: gcc-patches@gcc.gnu.org
Cc: nd
Subject: [PATCH][AArch64] Adjust SIMD integer preference
SIMD operations like combine prefer to have their operands in FP registers,
so increase the cost of integer regi
On May 15, 2016, at 1:30 PM, Andrew Pinski wrote:
>
> Can we recommend that clang disable this warning by default instead?
No. We want to ensure the class/struct tags match as there is no good reason
to have them differ.
> Or use an option flag to disable the warning while compiling gcc?
Don
On 05/17/2016 06:37 AM, Nick Clifton wrote:
Hi Jeff,
Currently dwarf2out.c:mem_loc_descriptor() has some special case
code to handle the situation where an address is held in a register
whose mode is not of type MODE_INT. It generates a
DW_OP_GNU_regval_type expression which may later
Hi,
On Tue, 17 May 2016, Richard Biener wrote:
> BIT_INSERT_EXPR
This.
> Any preference?
Ciao,
Michael.
On 05/17/2016 03:27 AM, Ramana Radhakrishnan wrote:
On Tue, May 17, 2016 at 1:22 AM, Sandra Loosemore
wrote:
On 05/16/2016 04:35 PM, Jim Wilson wrote:
This is my fifth ping. I just need someone to rubber stamp it so I
can check it in.
The documentation change looks fine, but as a document
On Tue, May 17, 2016 at 4:05 PM, Marc Glisse wrote:
> On Tue, 17 May 2016, Richard Biener wrote:
>
>> On Fri, May 13, 2016 at 3:36 PM, Marc Glisse wrote:
>>>
>>> On Fri, 13 May 2016, Mikhail Maltsev wrote:
>>>
> I don't know if we might want some :c / single_use restrictions, maybe
> on
>
Support for using the half-precision floating point operations added by
the ARMv8.2-A FP16 extension is based on the macros and intrinsics added
to the ACLE for the extension.
This patch adds executable tests for the ACLE scalar (floating point)
intrinsics to the advsimd-intrinsics testsuite. The
The ARMv8.2-A architecture introduces an optional FP16 extension adding
half-precision floating point data processing instructions to the
existing scalar (floating point) support. A future version of the ACLE
will add support for these instructions and this patch implements that
support.
The ACLE
Support for using the half-precision floating point operations added by
the ARMv8.2-A FP16 extension is based on the macros and intrinsics added
to the ACLE for the extension.
This patch adds tests to check the compilers treatment of the ACLE
macros and the code generated for the new intrinsics.
The ARMv8.2-A architecture introduces an optional FP16 extension adding
half-precision floating point data processing instructions to the
existing Adv.SIMD (NEON) support. A future version of the ACLE will add
support for these instructions and this patch implements that support.
The ACLE will in
On Tue, May 17, 2016 at 05:38:27PM +0300, Maxim Ostapenko wrote:
> Hi Jakub,
>
> thanks for backporting this! Do you have any plans to apply this patch to
> GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug by
> using GCC 5.3.1 on Fedora 23.
I don't have the newer glibc on my
This patch adds the builtins data for the ACLE intrinsics introduced to
support the NEON instructions of the ARMv8.2-A FP16 extension.
Tested the series for arm-none-linux-gnueabihf with native bootstrap and
make check and for arm-none-eabi and armeb-none-eabi with make check on
an ARMv8.2-A emul
The ARMv8.2-A FP16 extension adds a number of arithmetic instrutctions
to the VFP instruction set. This patch adds support for these
instructions to the ARM backend.
In most cases the instructions are added using non-standard pattern
names. This is to force operations on __fp16 values to be done,
The ACLE intrinsics introduced to support the ARMv8.2 FP16 extensions
require that intrinsics for scalar floating pointer (VFP) instructions
are available under different conditions from those for the NEON
intrinsics.
This patch adds the support code and builtins data for the new VFP
intrinsics.
The ACLE intrinsics introduced to support the ARMv8.2 FP16 extensions
require that intrinsics for scalar (VFP) instructions are available
under different conditions from those for the NEON intrinsics. To
support this, changes to the builtins support code are needed to enable
the scalar intrinsics
Hi Jakub,
thanks for backporting this! Do you have any plans to apply this patch
to GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug
by using GCC 5.3.1 on Fedora 23.
On 17/05/16 12:23, Jakub Jelinek wrote:
Hi!
This is a cherry-pick of upstream fix, so that dlsym can cal
The ARMv8.2-A FP16 extension adds a number of arithmetic instrutctions
to the NEON instruction set. This patch adds support for these
instructions to the ARM backend.
As with the VFP FP16 arithmetic instructions, operations on __fp16
values are done by conversion to single-precision. Any new opti
The ARMv8.2-A FP16 extension adds a number of instructions to support
data movement for FP16 values. This patch adds these instructions to the
backend, making them available to the compiler code generator.
The new instructions include VSEL which selects between two registers
depending on a condit
The ACLE specifies a number of intrinsics for manipulating vectors
holding values in most of the integer and floating point type. These
include 16-bit integer types but not 16-bit floating point even though
the same instruction is used for both.
A future version of the ACLE extends the data proce
The handling of 16-bit integer data-movement in the ARM backend doesn't
make full use of the VFP instructions when they are available, even when
the values are for use in VFP operations.
This patch adds support for using the VFP instructions and registers
when moving 16-bit integer and floating p
The FP16 extension introduced with the ARMv8.2-A architecture adds
instructions operating on FP16 values to the VFP and NEON instruction
sets.
The patch adds the feature macro __ARM_FEATURE_FP16_SCALAR_ARITHMETIC
which is defined to be 1 if the VFP FP16 instructions are available; it
is otherwise
The ARMv8.2-A FP16 extension adds to both the VFP and the NEON
instruction sets. This patch adds support to the testsuite to select
targets and set options for tests that make use of these
instructions. It also adds documentation for ARMv8.1-A selectors.
Tested the series for arm-none-linux-gnuea
The ARMv8.2-A FP16 extension only supports the IEEE format for FP16
data. It is not compatible with the option -mfp16-format=none nor with
the option -mfp16-format=alternative (selecting the ARM alternative FP16
format). Using either with the FP16 extension will trigger a compiler
error.
This pat
This patch adds the command options for the architecture ARMv8.2-A and
the half-precision extension. The architecture is selected by
-march=armv8.2-a and has all the properties of -march=armv8.1-a.
This patch also enables the CRC extension (+crc) which is required
for both ARMv8.2-A and ARMv8.1-A
Hello,
The ARMv8.2-A architecture builds on ARMv8.1-A and includes an optional
extension supporting half-precision floating point (FP16)
arithmetic. This extension adds instructions to the VFP and NEON
instructions sets to provide operations on IEEE754-2008 formatted FP16
values.
This patch set
On Tue, 17 May 2016, Richard Biener wrote:
On Fri, May 13, 2016 at 3:36 PM, Marc Glisse wrote:
On Fri, 13 May 2016, Mikhail Maltsev wrote:
I don't know if we might want some :c / single_use restrictions, maybe on
the
outer convert and the rshift/rotate.
I don't think :c can be used here.
On 05/17/2016 04:39 PM, Richard Biener wrote:
>
> Are you sure narrowing conversions are valid for rotates?
>
> (char)short_var < byte.
>
Yes, but the transformation leaves conversions as-is. Only bit_not is removed.
--
Regards,
Mikhail Maltsev
On Fri, May 13, 2016 at 3:36 PM, Marc Glisse wrote:
> On Fri, 13 May 2016, Mikhail Maltsev wrote:
>
>>> I don't know if we might want some :c / single_use restrictions, maybe on
>>> the
>>> outer convert and the rshift/rotate.
>>>
>> I don't think :c can be used here.
>
>
> Oups, typo for :s.
>
>>
On 17 May 2016 at 12:02, James Greenhalgh wrote:
> On Tue, May 17, 2016 at 11:32:36AM +0100, Marcus Shawcroft wrote:
>> On 17 May 2016 at 10:06, James Greenhalgh wrote:
>> >
>> > Hi,
>> >
>> > This is just a simplification, it probably makes life easier for register
>> > allocation in some corner
The following fixes a latent issue in loop distribution catched by
the fake edge placement adjustment.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-05-17 Richard Biener
PR tree-optimization/71132
* tree-loop-distribution.c (create_rdg_cd_edges)
On 17/05/16 13:40, Kyrill Tkachov wrote:
On 17/05/16 13:20, James Greenhalgh wrote:
On Mon, May 16, 2016 at 10:09:26AM +0100, Jiong Wang wrote:
The support of vfma_n_f64, vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64 are
missing in current gcc arm_neon.h.
Meanwhile, besides "(fma (vec_dup (vec_select
On 17/05/16 13:20, James Greenhalgh wrote:
On Mon, May 16, 2016 at 10:09:26AM +0100, Jiong Wang wrote:
The support of vfma_n_f64, vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64 are
missing in current gcc arm_neon.h.
Meanwhile, besides "(fma (vec_dup (vec_select)))", fma by element can
also comes from "(
On Mon, May 16, 2016 at 10:09:42AM +0100, Jiong Wang wrote:
> This patch remove inline assembly and reimplement all mvn/mvnq vector
> integer intrinsics through the standard "one_cmpl2" pattern was
> introduced later after the initial implementation of those intrinsics.
> that's why inline assembly
Hi Jeff,
>> Currently dwarf2out.c:mem_loc_descriptor() has some special case
>> code to handle the situation where an address is held in a register
>> whose mode is not of type MODE_INT. It generates a
>> DW_OP_GNU_regval_type expression which may later on be converted into
>> a frame p
On Mon, May 16, 2016 at 10:09:37AM +0100, Jiong Wang wrote:
> This patch reimplement vector multiply by element on top of the existed
> vmul_lane* intrinsics instead of inline assembly.
>
> There is no code generation change from this patch.
>
> OK for trunk?
>
> 2016-05-16 Jiong Wang
>
> gcc/
On Tue, May 17, 2016 at 1:25 PM, Christophe Lyon
wrote:
> On 1 April 2016 at 17:32, Ramana Radhakrishnan
> wrote:
>> I've had this in my tree for a few months now but never got
>> around to submitting it.
>>
>> This partially fixes PR target/53440 atleast in ARM and
>> Thumb2 state. I haven't yet
On Mon, May 16, 2016 at 10:09:31AM +0100, Jiong Wang wrote:
> AArch64 support vector multiply by element for V2DF, V2SF, V4SF, V2SI,
> V4SI, V4HI, V8HI.
>
> All above are well supported by "*aarch64_mul3_elt" pattern and
> "*aarch64_mul3_elt_" if there is lane size
> change.
>
> Above patterns ar
The following patch addresses PR71104 which shows verify-SSA ICEs
after gimplify-into-SSA. The issue is that for returns-twice calls
we gimplify register uses in the LHS before the actual call which leads to
p.0_1 = p;
_2 = vfork ();
*p.0_1 = _2;
when gimplifying *p = vfork (). That of c
On 1 April 2016 at 17:32, Ramana Radhakrishnan
wrote:
> I've had this in my tree for a few months now but never got
> around to submitting it.
>
> This partially fixes PR target/53440 atleast in ARM and
> Thumb2 state. I haven't yet managed to get my head around
> rewriting the Thumb1 support yet.
On Mon, May 16, 2016 at 10:09:26AM +0100, Jiong Wang wrote:
> The support of vfma_n_f64, vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64 are
> missing in current gcc arm_neon.h.
>
> Meanwhile, besides "(fma (vec_dup (vec_select)))", fma by element can
> also comes from "(fma (vec_dup(scalar" where the scalar
On Tue, May 17, 2016 at 1:56 PM, Kumar, Venkataramanan
wrote:
> Hi Richard,
>
> I created the patch by passing -b option to git. Now the patch is more
> readable.
>
> As per your suggestion I tried to fix the PR by splitting the SLP store group
> at vector boundary after the SLP tree is built.
>
Hi,
this patch fixes ICE while building Firefox (and probably xalancbmk, too)
with -O3 -flto. I originally tested the whole patchset on several bigger apps
including the inline heuristics change which teach it that thunks are very
cheap.
Mainline doesn't contain it that makes us to inline into th
On Mon, 16 May 2016, Jeff Law wrote:
- Now that I think of it, maybe I should check that the variable is not
a pointer before calling set_range_info? Having range [0, 1] makes it
unlikely, but who knows...
Maybe using an assert would be better.
I don't think having a pointer there would be co
Hi Richard,
I created the patch by passing -b option to git. Now the patch is more readable.
As per your suggestion I tried to fix the PR by splitting the SLP store group
at vector boundary after the SLP tree is built.
Boot strap PASSED on x86_64.
Checked the patch with check_GNU_style.sh.
Th
On Tue, May 17, 2016 at 8:59 AM, Marc Glisse wrote:
> Hello,
>
> the testcase for this patch is taken from
> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00683.html
>
> get_nonzero_bits only gives may-be-set bits. To handle an equivalent
> transform for bit_ior, I would need must-be-set bits, may
On Fri, May 13, 2016 at 9:07 PM, Marc Glisse wrote:
> Hello,
>
> maybe this would fit better in VRP, but it is easier (and not completely
> useless) to put it in match.pd.
>
> Since the transformation is restricted to GIMPLE, I think I don't need to
> check that @0 is SSA_NAME. I didn't test if @0
On Tue, May 17, 2016 at 1:18 PM, Jiong Wang wrote:
> On 17/05/16 11:23, Uros Bizjak wrote:
>>
>> On Tue, May 17, 2016 at 12:17 PM, Uros Bizjak wrote:
>>>
>>> Hello!
>>>
This bug is introduced by my commit r236181 where the inner rtx of
SUBREG haven't been checked while it should as "in_
On Mon, May 16, 2016 at 9:34 PM, Jan Hubicka wrote:
> Hi,
> this patch fixes chkp ICE when we try to inline into an instrumentation thunk.
> This is not really a thunk and ths can't be hanled as such.
>
> Bootstrapped/regtested x86_64-linux
>
> Honza
>
> 2016-05-16 Jan Hubicka
>
> * ipa
On Mon, May 16, 2016 at 8:48 PM, Jeff Law wrote:
> On 05/12/2016 08:29 AM, David Malcolm wrote:
>>
>>
>> One wart I ran into is that system.h has this:
>>
>> /* Front ends should never have to include middle-end headers. Enforce
>>this by poisoning the header double-include protection defines
On 17/05/16 11:23, Uros Bizjak wrote:
On Tue, May 17, 2016 at 12:17 PM, Uros Bizjak wrote:
Hello!
This bug is introduced by my commit r236181 where the inner rtx of
SUBREG haven't been checked while it should as "in_class_p" only
works with REG, and SUBREG_REG is actually not always REG. If
On Mon, May 16, 2016 at 10:09 AM, Bin.Cheng wrote:
> On Fri, May 13, 2016 at 5:53 PM, Richard Biener
> wrote:
>> On May 13, 2016 6:02:27 PM GMT+02:00, Bin Cheng wrote:
>>>Hi,
>>>As PR69848 reported, GCC vectorizer now generates comparison outside of
>>>VEC_COND_EXPR for COND_REDUCTION case, as b
On Tue, May 17, 2016 at 11:37:57AM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> The aarch64_vmls pattern claims to perform a normal vector
> floating-point multiply-subtract but in fact performs a fused
> multiply-subtract. This is fine when -ffp-contract=fast, but it's not guarded
> on anything so
On Tue, May 17, 2016 at 11:32:36AM +0100, Marcus Shawcroft wrote:
> On 17 May 2016 at 10:06, James Greenhalgh wrote:
> >
> > Hi,
> >
> > This is just a simplification, it probably makes life easier for register
> > allocation in some corner cases and seems the right thing to do. We don't
> > use t
On 13/05/16 12:05, Kyrill Tkachov wrote:
Hi Christophe,
On 12/05/16 20:57, Christophe Lyon wrote:
On 12 May 2016 at 11:48, Ramana Radhakrishnan wrote:
On Thu, May 5, 2016 at 12:50 PM, Kyrill Tkachov
wrote:
Hi all,
In this PR we deal with some fallout from the conversion to unified
assembl
Hi all,
The aarch64_vmls pattern claims to perform a normal vector floating-point
multiply-subtract but in fact
performs a fused multiply-subtract. This is fine when -ffp-contract=fast, but
it's not guarded on anything so
will generate the FMLS instruction even when -ffp-contract=off.
The solu
On 17 May 2016 at 10:06, James Greenhalgh wrote:
>
> Hi,
>
> This is just a simplification, it probably makes life easier for register
> allocation in some corner cases and seems the right thing to do. We don't
> use the internal version elsewhere, so we're safe to delete it and change
> the types
On 17 May 2016 at 10:13, James Greenhalgh wrote:
>
> Hi,
>
> As in the ARM port [1] , the AArch64 port wants to put out "b = a" to set
> an alias. This doesn't cause us any trouble yet, as the AArch64 port doesn't
> warn for this construct - but at the same time there is no reason for us
> not to
On Tue, May 17, 2016 at 12:17 PM, Uros Bizjak wrote:
> Hello!
>
>> This bug is introduced by my commit r236181 where the inner rtx of
>> SUBREG haven't been checked while it should as "in_class_p" only
>> works with REG, and SUBREG_REG is actually not always REG. If REG_P
>> check failed, then w
Hello!
> This bug is introduced by my commit r236181 where the inner rtx of
> SUBREG haven't been checked while it should as "in_class_p" only
> works with REG, and SUBREG_REG is actually not always REG. If REG_P
> check failed, then we should fall back to normal code patch. The
> following simp
Ping?
*** gcc/ChangeLog ***
2015-12-17 Thomas Preud'homme
* config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M Mainline.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index
347b5b0a5cc0bc1e3b5020c8124d968e76ce48a4..e154bd31b8084f9f45ad4409e7b38de652538c51
100644
1 - 100 of 139 matches
Mail list logo
