On ARM soft-float, the float to double conversion doesn't convert a sNaN
to qNaN as the IEEE Std 754 standard mandates:
"Under default exception handling, any operation signaling an invalid
operation exception and for which a floating-point result is to be
delivered shall deliver a quiet NaN."
Gi
Hi Yan-Ting,
> After contributing our porting for GDB, we need a patch to enable GDB
> building.
>
> Is this patch OK for commit?
It is. I have applied the patch to the binutils sources.
Please note however that the top level configure and configure.ac files are
shared
with the gcc project,
On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno wrote:
> On ARM soft-float, the float to double conversion doesn't convert a sNaN
> to qNaN as the IEEE Std 754 standard mandates:
>
> "Under default exception handling, any operation signaling an invalid
> operation exception and for which a floatin
Hi.
Graphite uses comparison of gsi_stmt_iterators (later_of_the_two) to find a
place where
to insert a new gimple statement. Problem of the function is that it does not
distinguish between
PHI and non-PHI statements, where the former one always stands before the later
one. The patch
fixes that
On 19/07/16 16:31, Wilco Dijkstra wrote:
> When zero extending a 32-bit value to 64 bits, there should always be a
> SET operation on the outside, according to the patterns in aarch64.md.
> However, the mid-end can also ask for the cost of a made-up instruction,
> where the zero-extend is part of a
Richard,
Jakub has already fixed it.
Sorry for troubles.
Yuri.
2016-07-19 18:29 GMT+03:00 Renlin Li :
> Hi Yuri,
>
> I saw this test case runs on arm platforms, and maybe other platforms as
> well.
>
> testsuite/g++.dg/vect/pr70729.cc:7:10: fatal error: xmmintrin.h: No such
> file or directory
>
On 19/07/16 16:32, Wilco Dijkstra wrote:
> On AArch64 the UXTB and UXTH instructions are aliases of UBFM,
> which does a shift as part of its operation. An AND immediate is a
> simpler operation, and might be faster on some implementations, so it is
> better to emit this this instead of UBFM.
>
>
Hi gcc-patches group,
Please find the patch for adding the basic scheduler for vulcan
in the aarch64 port.
Tested the patch with compiling cross aarch64-linux-gcc,
bootstrapped native aarch64-unknown-linux-gnu and
run gcc regression.
Kindly review and merge the patch to trunk, if the patch is ok
Hi Mikael,
> > + if(st == ST_FAIL_IMAGE)
> > +new_st.op = EXEC_FAIL_IMAGE;
> > + else
> > +gcc_unreachable();
> You can use
> gcc_assert (st == ST_FAIL_IMAGE);
> foo...;
> instead of
> if (st == ST_FAIL_IMAGE)
> foo...;
> else
> gcc_
Splicing replies to Bernd, Bernhard and Jeff.
Jeff, thanks for reviewing the patch set, I appreciate the ack, though I've
held off committing while I was working through Bernd's criticism of the
size cost model that this patch introduced and trying to get that right.
Sorry to cause extra reviewin
Hi,
This patch adds a short-circuit to optabs.c for the case where both
source operands are identical (i.e. we would be assigning the same
value in both branches).
This can show up for the memory optimisation in noce_cmove_arith in ifcvt.c,
if both branches would load from the same address. This
Hi,
This patch modifies the way we calculate costs in ifcvt.c. Rather than
using a combination of magic numbers and approximations to descide if we
should perform the transformation before constructing the new RTL, we
instead construct the new RTL and use the cost of that to form our cost model.
Hi,
This patch pulls some duplicate logic out from noce_try_cmove_arith.
We do this in order to make reasoning about the code easier.
Some of the natural simplification that comes from this process improves
the generation of temporaries in the code, which is good as it reduces
the size and speed
On 2016-07-20 10:10, Ramana Radhakrishnan wrote:
> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno wrote:
> > On ARM soft-float, the float to double conversion doesn't convert a sNaN
> > to qNaN as the IEEE Std 754 standard mandates:
> >
> > "Under default exception handling, any operation signali
On Tue, Jul 19, 2016 at 6:15 PM, Bin.Cheng wrote:
> On Tue, Jul 19, 2016 at 1:10 PM, Richard Biener
> wrote:
>> On Mon, Jul 18, 2016 at 6:27 PM, Bin Cheng wrote:
>>> Hi,
>>> Scalar evolution needs to prove no-overflow for source variable when
>>> handling type conversion. This is important bec
On Tue, Jul 19, 2016 at 3:27 PM, Alexander Monakov wrote:
> On Tue, 19 Jul 2016, Richard Biener wrote:
>> Yes. The other option is to enable this checking not with ENABLE_CHECKING
>> but some new checking option, say ENABLE_CHECKING_ALGORITHMS, and
>> do full checking in that case.
>
> Thanks - I
On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno wrote:
> On 2016-07-20 10:10, Ramana Radhakrishnan wrote:
>> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno wrote:
>> > On ARM soft-float, the float to double conversion doesn't convert a sNaN
>> > to qNaN as the IEEE Std 754 standard mandates:
>>
On 2016-07-20 11:04, Ramana Radhakrishnan wrote:
> On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno wrote:
> > On 2016-07-20 10:10, Ramana Radhakrishnan wrote:
> >> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno
> >> wrote:
> >> > On ARM soft-float, the float to double conversion doesn't conver
On Wed, Jul 20, 2016 at 11:14 AM, Aurelien Jarno wrote:
> On 2016-07-20 11:04, Ramana Radhakrishnan wrote:
>> On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno
>> wrote:
>> > On 2016-07-20 10:10, Ramana Radhakrishnan wrote:
>> >> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno
>> >> wrote:
>> >
On Wed, Jul 20, 2016 at 4:16 AM, kugan
wrote:
> Hi Richard,
>
> As discussed in IPA-VRP discussion, this patch makes tree-vrp allocations
> use alloc-pool and obstack for value_range and vr->equiv respectively. Other
> allocations are rare and left as it is.
>
> Bootstrapped and regression tested
On Wed, Jul 20, 2016 at 11:24 AM, Martin Liška wrote:
> Hi.
>
> Graphite uses comparison of gsi_stmt_iterators (later_of_the_two) to find a
> place where
> to insert a new gimple statement. Problem of the function is that it does not
> distinguish between
> PHI and non-PHI statements, where the
On 07/19/2016 10:16 AM, Georg-Johann Lay wrote:
Done. Attached is the updated version of the change, log entry is the
same as before.
Johann
LGTM.
Bernd
On 07/19/2016 01:18 PM, Richard Biener wrote:
On Tue, Jul 19, 2016 at 1:07 PM, Bernd Schmidt wrote:
On 07/19/2016 12:35 PM, Richard Biener wrote:
I think that start/end_recording_case_labels also merged adjacent labels
via group_case_labels_stmt. Not sure why you need to stop recording
case
On 07/19/2016 05:35 PM, Segher Boessenkool wrote:
On Tue, Jul 19, 2016 at 04:49:26PM +0200, Bernd Schmidt wrote:
But you need the profile to make even reasonably good decisions.
I'm not worried about making cost decisions: as far as I'm concerned
it's perfectly fine for that. I'm worried abo
Version 3 of the patch. See below for changes. Regression tested
on s390x and s390.
On Tue, Jul 19, 2016 at 01:05:52PM +0200, Andreas Krebbel wrote:
> On 07/19/2016 11:37 AM, Dominik Vogt wrote:
> > +(define_insn_and_split "*andc_split"
>
> Please append here to make the insn name unique.
Don
On 07/19/2016 10:20 AM, Richard Biener wrote:
I like it. Improving re-build time in my dev tree is very much
welcome, and yes,
libbackend build time is a big part of it usually (plus of course cc1
link time).
Since that wasn't an entirely explicit ack, I'll add mine. Thank you for
doing this.
On 07/20/2016 11:51 AM, James Greenhalgh wrote:
2016-07-20 James Greenhalgh
* target.def (max_noce_ifcvt_seq_cost): New.
* doc/tm.texi.in (TARGET_MAX_NOCE_IFCVT_SEQ_COST): Document it.
* doc/tm.texi: Regenerate.
* targhooks.h (default_max_noce_ifcvt_seq_cost)
On 07/20/16 12:46, Richard Biener wrote:
> On Wed, 20 Jul 2016, Richard Biener wrote:
>
>> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
>>
>>> Hi!
>>>
>>> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
>>> we have a _very_ old hack in gcc, that recognizes certain functions by
>>>
ping * 3 https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
Thanks,
Prathamesh
On 5 July 2016 at 10:53, Prathamesh Kulkarni
wrote:
> ping * 2 ping https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
>
> Thanks,
> Prathamesh
>
> On 28 June 2016 at 14:49, Prathamesh Kulkarni
> wrote:
>
ping * 3 https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02008.html
Thanks,
Prathamesh
On 29 June 2016 at 22:09, Prathamesh Kulkarni
wrote:
> ping * 2 https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02008.html
>
> Thanks,
> Prathamesh
>
> On 7 June 2016 at 13:56, Prathamesh Kulkarni
> wrote:
>> pin
Hi!
Ping.
On Wed, 13 Jul 2016 11:25:46 +0200, I wrote:
> Working on something else regarding the C/C++ OpenACC routine directive,
> I couldn't but untangle that arcane location_t handling, currently using
> a dummy OMP_CLAUSE_SEQ. Along the way, I also updated some comments, and
> simplified som
Hi!
Ping.
On Wed, 13 Jul 2016 16:10:31 +0200, I wrote:
> On Wed, 13 Jul 2016 11:25:46 +0200, I wrote:
> > Working on something else regarding the C/C++ OpenACC routine directive,
> > I couldn't but untangle [...]
>
> > (Another C/C++ OpenACC routine
> > cleanup patch is emerging, depending on th
Hi!
Ping.
On Wed, 13 Jul 2016 12:37:07 +0200, I wrote:
> As discussed before, "offloading compilation is slow; I suppose because
> of having to invoke several tools (LTO streaming -> mkoffload -> offload
> compilers, assemblers, linkers -> combine the resulting images; but I
> have not done a det
On Wed, 20 Jul 2016, Bernd Edlinger wrote:
> On 07/20/16 12:46, Richard Biener wrote:
> > On Wed, 20 Jul 2016, Richard Biener wrote:
> >
> >> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> >>
> >>> Hi!
> >>>
> >>> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
> >>> we have a _v
The attached patch rewrites the pr67443.c testcase in a different
way so that the test still works with the changed allocation of
globals pinned to registers. The test ist hopefully more robust
now. The test ist hopefully more robust now. Tested on s390 and s390x biarch.
Ciao
Dominik ^_^ ^_^
On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote:
> Patch:
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html
>
> On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote:
> > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or
> > newer since this commit:
>
On 07/20/16 13:53, Richard Biener wrote:
> On Wed, 20 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/20/16 12:46, Richard Biener wrote:
>>> On Wed, 20 Jul 2016, Richard Biener wrote:
>>>
On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> Hi!
>
> As discussed at https://gcc.gnu.org/bugzi
On Thu, Jul 14, 2016 at 10:24:38AM +0100, Dominik Vogt wrote:
> On Wed, Jul 13, 2016 at 07:43:13PM +0200, Bernd Schmidt wrote:
> > On 07/13/2016 05:29 PM, Dominik Vogt wrote:
> >
> > >Unfortunately this patch (or whatever got actually committed) has
> > >broken the gcc.target/s390/pr679443.c test
2016-07-19 14:46 GMT+02:00 Uros Bizjak :
> The result of exercises with sed in gcc/ directory.
Some more conversions:
2016-07-20 Uros Bizjak
* cse.c: Use HOST_WIDE_INT_M1 instead of ~(HOST_WIDE_INT) 0.
* combine.c: Use HOST_WIDE_INT_M1U instead of
~(unsigned HOST_WIDE_INT) 0.
On 07/19/16 14:34, Alexander Monakov wrote:
Hi,
I've recently committed a middle-end patch that adds handling of undefined
variables (that the nvptx backend needs) under -fno-toplevel-reorder (svn rev.
238371). With that change, it's no longer necessary to implicitly enable
-ftoplevel-reorder i
On 2016-07-20 11:22, Ramana Radhakrishnan wrote:
> On Wed, Jul 20, 2016 at 11:14 AM, Aurelien Jarno wrote:
> > On 2016-07-20 11:04, Ramana Radhakrishnan wrote:
> >> On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno
> >> wrote:
> >> > On 2016-07-20 10:10, Ramana Radhakrishnan wrote:
> >> >> On Wed
On 8 July 2016 at 12:29, Richard Biener wrote:
> On Fri, 8 Jul 2016, Richard Biener wrote:
>
>> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
>>
>> > Hi Richard,
>> > For the following test-case:
>> >
>> > int f(int x, int y)
>> > {
>> >int ret;
>> >
>> >if (x == y)
>> > ret = x ^ y;
This adds some insns that set a destination bit expressed as zero_extract to a
source bit expressed as extract, right shift, and simple combinations thereof.
Purpose is smaller code and to avoid costly extracts or shifts. This applies
mostly to bitfields; for open-coded bit insertions the patt
Currently aarch64_add_constant is using aarch64_build_constant to move
an immediate into the destination register.
It has considered the following situations:
* immediate can fit into bitmask pattern that only needs single
instruction.
* immediate can fit into single movz/movn.
* immed
This patch optimize immediate addition sequences generated by
aarch64_add_constant.
The current addition sequences generated are:
* If immediate fit into unsigned 12bit range, generate single add/sub.
* Otherwise if it fit into unsigned 24bit range, generate two add/sub.
* Otherwise
Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
are doing exactly what's aarch64_add_constant offered, except they also
need to be aware of dwarf generation.
This patch teach existed aarch64_add_constant about dwarf generation and
currently SP register is supported. When
Richard Earnshaw wrote:
> I'm not sure about this, while rtx_cost is called recursively as it
> walks the RTL, I'd normally expect the outer levels of the recursion to
> catch the cases where zero-extend is folded into a more complex
> operation. Hitting a case like this suggests that something is
On 07/20/2016 02:25 PM, Uros Bizjak wrote:
2016-07-19 14:46 GMT+02:00 Uros Bizjak :
The result of exercises with sed in gcc/ directory.
Some more conversions:
2016-07-20 Uros Bizjak
* cse.c: Use HOST_WIDE_INT_M1 instead of ~(HOST_WIDE_INT) 0.
* combine.c: Use HOST_WIDE_INT_M1U i
On 20/07/16 14:08, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> I'm not sure about this, while rtx_cost is called recursively as it
>> walks the RTL, I'd normally expect the outer levels of the recursion to
>> catch the cases where zero-extend is folded into a more complex
>> operation. Hitt
On 19/07/16 10:32 +0100, Jonathan Wakely wrote:
On 18/07/16 12:49 -0400, Jason Merrill wrote:
Perhaps the right answer is to drop support for catching nullptr as a
pointers to member from the language.
Yes, I've been drafting a ballot comment along those lines.
On the CWG reflector Richard S
Hi.
Following patch addresses ICE which happens when coverage.c computes checksum
of a function w/o xloc.file. My patch assumes it's a valid state having a
function
w/o xloc.file, which is situation exposed by cilkplus functions.
Patch can bootstrap on ppc64le-redhat-linux and survives regressio
All function classes listed in gcc/coretypes.h are supported by musl.
Most of the optimizations based on these function classes are not
relevant for standard conform c code, but this is required to get
rid of some test system noise.
gcc/
2016-07-20 Szabolcs Nagy
* config/linux.c (linu
OK.
On Mon, Jul 18, 2016 at 5:07 PM, Jakub Jelinek wrote:
> On Mon, Jul 18, 2016 at 02:42:43PM -0400, Jason Merrill wrote:
>> Ah, I guess we need to check cxx_dialect in cxx_eval_store_expression,
>> not just in potential_constant_expression.
>
> Here is an updated version, bootstrapped/regtested
Richard Earnshaw wrote:
> Why does combine care what the cost is if the instruction isn't valid?
No idea. Combine does lots of odd things that don't make sense to me.
Unfortunately the costs we give for cases like this need to be accurate or
they negatively affect code quality. The reason for thi
OK.
On Mon, Jul 18, 2016 at 5:14 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes two issues:
> 1) as shown in the first testcase, cp_parser_save_member_function_body
>adds the catch () { ... } tokens into the saved token range
>even when there is no function try block (missing try
> Musl libc does not support gnu ifunc, so disable it by default.
> (not disabled on s390-* since that has no musl support yet.)
Musl libc now supports PPC64. Support for s390 is in progress.
- David
Musl libc does not support gnu ifunc, so disable it by default.
(not disabled on s390-* since that has no musl support yet.)
gcc/
2016-07-20 Szabolcs Nagy
* config.gcc (*-*-*musl*): Disable gnu-indirect-function.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 1f75f17..f3f6e14 10064
On Mon, Jul 18, 2016 at 6:15 PM, Martin Sebor wrote:
> On 07/18/2016 11:51 AM, Jason Merrill wrote:
>>
>> On 07/06/2016 06:20 PM, Martin Sebor wrote:
>>>
>>> @@ -2911,6 +2923,14 @@ cxx_eval_indirect_ref (const constexpr_ctx
>>> *ctx, tree t,
>>>if (*non_constant_p)
>>> return t;
>>>
>
On 20/07/16 14:40, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Why does combine care what the cost is if the instruction isn't valid?
>
> No idea. Combine does lots of odd things that don't make sense to me.
> Unfortunately the costs we give for cases like this need to be accurate or
> the
since gcc can be built with --enable-default-pie, there
is a -no-pie flag to turn off PIE.
gcc cannot be built as PIE (pr 71934), so the gcc build
system has to detect the -no-pie flag to disable PIE.
historically default pie toolchains used the -nopie flag
(e.g. gentoo hardened), those toolchain
Fix target library tests when gcc is built using --with-build-sysroot.
The dejagnu find_gcc function cannot handle if CC needs extra flags
like --sysroot. So for testing target libraries use the same CC that
was used for building the target libs. This change assumes the test
is ran from make.
Ano
On 20/07/16 14:02, Jiong Wang wrote:
> Currently aarch64_add_constant is using aarch64_build_constant to move
> an immediate into the destination register.
>
> It has considered the following situations:
>
> * immediate can fit into bitmask pattern that only needs single
> instruction.
>
On 20/07/16 14:45, David Edelsohn wrote:
>> Musl libc does not support gnu ifunc, so disable it by default.
>> (not disabled on s390-* since that has no musl support yet.)
>
> Musl libc now supports PPC64. Support for s390 is in progress.
>
it seemed to me that on ppc64 ifunc is disabled by defa
On Wed, 20 Jul 2016, Bernd Schmidt wrote:
> On 07/19/2016 10:20 AM, Richard Biener wrote:
> > I like it. Improving re-build time in my dev tree is very much
> > welcome, and yes,
> > libbackend build time is a big part of it usually (plus of course cc1
> > link time).
>
> Since that wasn't an en
Changes in v2:
- split out the non-C++ parts already approved by Jeff (I've committed
these as r238522).
- updated to mirror the fixes for PR c/71858 Jakub made to the
corresponding C implementation in r238352, skipping anticipated decls
of builtin functions
- rewritten to more closely
On 20/07/16 14:02, Jiong Wang wrote:
> This patch optimize immediate addition sequences generated by
> aarch64_add_constant.
>
> The current addition sequences generated are:
>
> * If immediate fit into unsigned 12bit range, generate single add/sub.
> * Otherwise if it fit into unsigned 2
On Wed, Jul 20, 2016 at 7:09 AM, Szabolcs Nagy wrote:
> On 20/07/16 14:45, David Edelsohn wrote:
>>> Musl libc does not support gnu ifunc, so disable it by default.
>>> (not disabled on s390-* since that has no musl support yet.)
>>
>> Musl libc now supports PPC64. Support for s390 is in progress.
On 20/07/16 14:03, Jiong Wang wrote:
> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
> are doing exactly what's aarch64_add_constant offered, except they also
> need to be aware of dwarf generation.
>
> This patch teach existed aarch64_add_constant about dwarf generation
On Wed, Jul 20, 2016 at 10:46:58AM -0400, David Malcolm wrote:
> + /* Skip anticipated decls of builtin functions. */
> + if (TREE_CODE (t) == FUNCTION_DECL)
> + if (DECL_BUILT_IN (t))
> + if (DECL_ANTICIPATED (t))
Just a style comment, wouldn't
if (TREE_CODE (t) == FUNC
On 18.07.2016 08:58, Denis Chertykov wrote:
2016-07-15 18:26 GMT+03:00 Georg-Johann Lay :
This patch needs new hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00839.html
This patch turns attribute progmem into a working feature for AVR_TINY
cores.
It boils
On 20/07/16 15:13, David Edelsohn wrote:
> On Wed, Jul 20, 2016 at 7:09 AM, Szabolcs Nagy wrote:
>> On 20/07/16 14:45, David Edelsohn wrote:
Musl libc does not support gnu ifunc, so disable it by default.
(not disabled on s390-* since that has no musl support yet.)
>>>
>>> Musl libc now
On 14 Jul 16:04, Jeff Law wrote:
> On 06/28/2016 06:24 AM, Ilya Enkovich wrote:
>
> >
> >Here is an updated patch version.
> >
> >Thanks,
> >Ilya
> >--
> >gcc/
> >
> >+/* Function vect_gen_loop_masks.
> >+
> >+ Create masks to mask a loop described by LOOP_VINFO. Masks
> >+ are created accord
On Wed, Jul 20, 2016 at 10:46 AM, David Malcolm wrote:
> @@ -1407,6 +1407,10 @@ lookup_field_fuzzy_info::fuzzy_lookup_field (tree type)
> The TYPE_FIELDS of TYPENAME_TYPE is its TYPENAME_TYPE_FULLNAME. */
> return;
>
> + /* TYPE_FIELDS is not valid for a TYPE_PACK_EXPANSION. */
> +
On 20/07/16 15:18, Richard Earnshaw (lists) wrote:
On 20/07/16 14:03, Jiong Wang wrote:
Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
are doing exactly what's aarch64_add_constant offered, except they also
need to be aware of dwarf generation.
This patch teach existed
On Wed, Jul 20, 2016 at 01:23:44PM +0200, Bernd Schmidt wrote:
> >>>But you need the profile to make even reasonably good decisions.
> >>
> >>I'm not worried about making cost decisions: as far as I'm concerned
> >>it's perfectly fine for that. I'm worried about correctness - you can't
> >>validly
On 20/07/16 16:02, Jiong Wang wrote:
> On 20/07/16 15:18, Richard Earnshaw (lists) wrote:
>> On 20/07/16 14:03, Jiong Wang wrote:
>>> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
>>> are doing exactly what's aarch64_add_constant offered, except they also
>>> need to be a
Richard Earnshaw wrote:
> Both of which look reasonable to me.
Yes the code we generate for these examples is fine, I don't believe this
example ever went bad. It's just the cost calculation that is incorrect with
the outer check.
Wilco
On 20/07/16 16:28, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Both of which look reasonable to me.
>
> Yes the code we generate for these examples is fine, I don't believe this
> example ever went bad. It's just the cost calculation that is incorrect with
> the outer check.
>
> Wilco
>
>
On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote:
> On 8 July 2016 at 12:29, Richard Biener wrote:
> > On Fri, 8 Jul 2016, Richard Biener wrote:
> >
> >> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
> >>
> >> > Hi Richard,
> >> > For the following test-case:
> >> >
> >> > int f(int x, int y)
> >>
Richard Earnshaw wrote:
> So under what circumstances does it lead to sub-optimal code?
If the cost is incorrect Combine can make the wrong decision, for example
whether to emit a multiply-add or not. I'm not sure whether this still happens
as Kyrill fixed several issues in Combine since this patc
On 07/20/2016 09:35 AM, Richard Biener wrote:
I have reported it as PR71947.
Could you help me point out how to fix this ?
Not record both equivalences. This might break the testcase it was
introduced for (obviously). Which is why I CCed Jeff for his opinion.
It's on my todo list. I'm still
On Wed, Jul 20, 2016 at 3:15 PM, Bernd Schmidt wrote:
>
>
> On 07/20/2016 02:25 PM, Uros Bizjak wrote:
>>
>> 2016-07-19 14:46 GMT+02:00 Uros Bizjak :
>>>
>>> The result of exercises with sed in gcc/ directory.
>>
>>
>> Some more conversions:
>>
>> 2016-07-20 Uros Bizjak
>>
>> * cse.c: Use H
On 07/20/2016 05:14 AM, Bernd Schmidt wrote:
On 07/19/2016 01:18 PM, Richard Biener wrote:
On Tue, Jul 19, 2016 at 1:07 PM, Bernd Schmidt
wrote:
On 07/19/2016 12:35 PM, Richard Biener wrote:
I think that start/end_recording_case_labels also merged
adjacent labels via group_case_labels_stmt.
On 07/20/2016 05:53 AM, Richard Biener wrote:
Is it OK after boot-strap and regression-testing?
I think the __builtin_setjmp change is wrong - __builtin_setjmp is
_not_ 'setjmp' it is part of the GCC internal machinery (using setjmp
and longjmp in the end) for SJLJ exception handing.
Am I corr
On Wed, Jul 20, 2016 at 11:01 AM, Richard Biener
wrote:
> On Tue, Jul 19, 2016 at 6:15 PM, Bin.Cheng wrote:
>> On Tue, Jul 19, 2016 at 1:10 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 18, 2016 at 6:27 PM, Bin Cheng wrote:
Hi,
Scalar evolution needs to prove no-overflow for source var
On 07/20/2016 08:37 AM, Ilya Enkovich wrote:
Here is an updated version.
Thanks,
Ilya
--
gcc/
2016-07-20 Ilya Enkovich
* dbgcnt.def (vect_tail_combine): New.
* params.def (PARAM_VECT_COST_INCREASE_COMBINE_THRESHOLD): New.
* tree-vect-data-refs.c (vect_get_new_ssa_na
On 07/20/2016 06:09 PM, Jeff Law wrote:
So I'm going to let Richi run with the review on this one since the two
of you are already iterating. But I did have one comment on the
placement of the pass.
I believe one of the key things to consider for whether or not something
like this belongs in th
On 07/20/16 18:15, Jeff Law wrote:
> On 07/20/2016 05:53 AM, Richard Biener wrote:
>>> Is it OK after boot-strap and regression-testing?
>>
>> I think the __builtin_setjmp change is wrong - __builtin_setjmp is
>> _not_ 'setjmp' it is part of the GCC internal machinery (using setjmp
>> and longjmp i
On Wed, Jul 06, 2016 at 04:18:49PM +0200, Roger Pau Monne wrote:
> At the moment the -m16 option only passes the "--32" parameter to the
> assembler on glibc OSes, while on other OSes the assembler is called without
> any specific flag. This is wrong and causes the assembler to fail. Fix it
> by ad
On Wed, Jul 20, 2016 at 01:41:39PM +0200, Bernd Schmidt wrote:
> On 07/20/2016 11:51 AM, James Greenhalgh wrote:
>
> >
> >2016-07-20 James Greenhalgh
> >
> > * target.def (max_noce_ifcvt_seq_cost): New.
> > * doc/tm.texi.in (TARGET_MAX_NOCE_IFCVT_SEQ_COST): Document it.
> > * doc/tm
Hi,
This patch cleans up function number_of_iterations_lt_to_ne mainly by removing
computation of may_be_zero. The computation is unnecessary and may_be_zero in
this case must be true. Specifically, DELTA is integer constant and iv0.base <
iv1.base bounds to be true because the false case is h
On 07/20/16 18:20, Jeff Law wrote:
> On 07/20/2016 09:41 AM, Bernd Edlinger wrote:
>> On 07/20/16 12:44, Richard Biener wrote:
>>> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
>>>
Hi!
As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
we have a _very_ old hack in
Hi,
After patch @238301, issue reported in PR65206 is also exposed by case
gcc.dg/vect/vect-mask-store-move-1.c. This patch xfail the case for the moment.
Test result checked, is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2016-07-14 Bin Cheng
* gcc.dg/vect/vect-mask-store-move-1.c: X
On 07/07/16 17:14, Jiong Wang wrote:
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,
On 07/07/16 17:15, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 two operands vector intrinsics.
The updated patch resolve the conflict with
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html
The change is to let aarch64_emit_approx_div return false for
V4HFmode and V8HFmode.
gcc/
On 07/07/16 17:17, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 one operand scalar intrinsics
Scalar intrinsics are kept in arm_fp16.h instead of arm_neon.h.
The updated patch resolve the conflict with
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00308.html
The change is to let aarch6
On 07/07/16 17:17, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 two operands scalar intrinsics.
The updated patch resolve the conflict with
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html
The change is to let aarch64_emit_approx_div return false for HFmode.
gcc/
2016-07-20 Ji
This patch renames the configure switches to be explicit that they are for the
PowerPC, and that they are temporary. I would hope by the time GCC 7 exits
stage1 that these switches will be removed, but having them now will allow us
to move to LRA and __float128 in an orderly fashion.
I built a bo
On 07/19/2016 11:40 AM, Dominik Vogt wrote:
> The attached patch XFAILs some of the "insv" testcases as
> discussed internally. Tested on s390x biarch and s390.
Applied. Thanks!
-Andreas-
On 07/20/2016 01:55 PM, Dominik Vogt wrote:
> The attached patch rewrites the pr67443.c testcase in a different
> way so that the test still works with the changed allocation of
> globals pinned to registers. The test ist hopefully more robust
> now. The test ist hopefully more robust now. Teste
1 - 100 of 146 matches
Mail list logo
