Hi,
> This patch works on the intrinsic calls handling issue in IVOPT mentioned
> here:
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>
> In find_interesting_uses_stmt, it changes
>
> arg = expr
> __builtin_xxx (arg)
>
> to
>
> arg = expr;
> tmp = addr_expr (mem_ref(arg));
> __bui
../../../libgfortran/intrinsics/erfc_scaled.c:59:1: error: unknown type name
'GFC_REAL_16'
extern GFC_REAL_16 erfc_scaled_r16 (GFC_REAL_16);
^
../../../libgfortran/intrinsics/erfc_scaled.c:59:1: warning: parameter names
(without types) in function declaration [enabled by default]
../../../libgf
On Thu, 2013-11-21 at 08:06 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > * config.gcc (SH extra_objs): Add sh_optimize_sett_clrt pass.o.
>
> The usual way would be
>
> * config.gcc (sh[123456789lbe]*-*-* | sh-*-*): Add
> sh_optimize_sett_clrt.o to extra_objs.
>
> OK with tha
> ../../../libgfortran/intrinsics/erfc_scaled.c:59:1: error: unknown type name
> ‘GFC_REAL_16'
I’m really sorry about that, I should have tested on a system without
binary128, that would have caught it.
Attached patch committed as rev. 205193 after checking it on system both with
and without bi
I don't know very much about the problem but willing to study since I
am looking into IVO recently :)
> --- tree-ssa-loop-ivopts.c (revision 204792)
> +++ tree-ssa-loop-ivopts.c (working copy)
> @@ -135,6 +135,8 @@ struct iv
>tree ssa_name; /* The ssa name with the value. */
>
This removes the use of the bogus number_of_exit_cond_executions
function from loop-distribution.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-11-21 Richard Biener
PR tree-optimization/59058
* tree-loop-distribution.c (struct partition
Ping and CC Zdenek with the right email.
Thanks,
bin
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Wednesday, November 06, 2013 5:51 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener; o...@ucw.cz
> S
This fixes the couple of ACATS failures
=== acats tests ===
FAIL: c45531j
FAIL: c45531l
=== acats Summary ===
# of expected passes2318
# of unexpected failures2
introduced by Jeff's latest threading patches. The Tree-SSA tail merging pass
This patch decrements nb_iterations_upper_bound by one after we copied
the loop header. This allows niter + 1 to more often not overflow.
Bootstrapped and tested on x86_64-unknown-linux-gnu, installed to trunk.
Richard.
2013-11-21 Richard Biener
* tree-ssa-loop-ch.c (copy_loop_head
The submission is at http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02007.html
Thanks in advance.
--
Eric Botcazou
This applies some TLC to the vectorizers various niter and related
computes.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-11-21 Richard Biener
* tree-vect-loop-manip.c (vect_build_loop_niters,
vect_generate_tmps_on_preheader): Move ...
On Thu, 21 Nov 2013, Jan Hubicka wrote:
> Hi,
> I am not sure where we converged concerning the fork trick. I am using it in
> my
> tree for months and it does save my waiting time for WPA compilations, so I am
> re-attaching the patch.
>
> Does it seem resonable for mainline?
>
> As for other
FX writes:
> 2013-11-20 Francois-Xavier Coudert
>
> PR libfortran/59227
There is no connection to PR59227
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
2013/11/20 Richard Biener :
> On Wed, Nov 20, 2013 at 10:57 AM, Richard Biener
> wrote:
>> On Tue, Nov 19, 2013 at 9:18 PM, Ilya Enkovich
>> wrote:
>>> 2013/11/19 Jeff Law :
On 11/19/13 05:20, Ilya Enkovich wrote:
>
> 2013/11/19 Richard Biener :
>>
>> On Mon, Nov 18, 2013 at
>Thanks. Vlad may not be available right now, and even if he is, he's
>probably typing one-handed.
>
>So I took care of installing this for you.
>
>Thanks,
>Jeff
Thanks!
Regards,
Robert
On 21/11/13 02:53, Terry Guo wrote:
> BR,
> Terry
>
> 2013-11-21 Terry Guo
>
> * doc/invoke.texi (-mslow-flash-data): Document new option.
> * config/arm/arm.opt (mslow-flash-data): New option.
> * config/arm/arm-protos.h
> (arm_max_const_doub
>
> Why do you need an additional -fparallelism? Wouldn't
> -fwpa=... be a better match, matching -flto=...? As we already
> pass down a -fwpa option to WPA this would make things easier, no?
My plan was to possibly use same option later for parallelizing more parts of
compiler, not only WPA st
On Tue, 5 Nov 2013, Mike Stump wrote:
> On Nov 5, 2013, at 1:45 PM, Oleg Endo wrote:
> > You're right, it's redundant. It should be just
> > /* { dg-do compile } */
> >
> > shouldn't it?
>
> Yup, that's my take.
Or nothing at all, as compile seems to be the default here.
(grep for dg-do-what-de
On Nov 21 2013, FX wrote:
Note: Gradual underflow control is implemented as "not supported by the
processor" (its SUPPORT function returns false, and the GET and SET
procedures abort if you call them), because we probably don't have
targets where it would work (and I don't think people use it
On Thu, 21 Nov 2013, Jan Hubicka wrote:
> >
> > Why do you need an additional -fparallelism? Wouldn't
> > -fwpa=... be a better match, matching -flto=...? As we already
> > pass down a -fwpa option to WPA this would make things easier, no?
>
> My plan was to possibly use same option later for
On Thu, Nov 21, 2013 at 07:43:35AM +1000, Richard Henderson wrote:
> On 11/20/2013 07:44 PM, Jakub Jelinek wrote:
> > On Wed, Nov 20, 2013 at 10:31:38AM +0100, Richard Biener wrote:
> >> Aww ;) Nice improvement. Generally when I see this I always wonder
> >> whether we want to do this kind of stu
> That's a reasonable decision, but it is actually used at least ten times
> as much as everything else put together, possibly a hundred times as much.
I believe we are in pretty different parts of the community. Around me I rarely
see it used, while people check for nans, infinities, and excepti
Hi,
this patch fixes problem with missing dump files with -flto and vectorizer
and also silence error in gcc.dg/20081223-1.c testcase. We ought to error
these even w/o -ffat-lto-objects, I will look into it ASAP.
We need to move these errors from varasm/wrapup into symtab finalization
that is obvi
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
> This patch, relative to trunk and based on work done on the
On Thu, 21 Nov 2013, Jakub Jelinek wrote:
> On Thu, Nov 21, 2013 at 07:43:35AM +1000, Richard Henderson wrote:
> > On 11/20/2013 07:44 PM, Jakub Jelinek wrote:
> > > On Wed, Nov 20, 2013 at 10:31:38AM +0100, Richard Biener wrote:
> > >> Aww ;) Nice improvement. Generally when I see this I always
This moves another fold-const.c folding to the GIMPLE level.
In PR59058 it was noticed we fail to optimize
vect_vec_iv_.16_57 = VIEW_CONVERT_EXPR(vect_vec_iv_.15_55);
vect_b.17_58 = VIEW_CONVERT_EXPR(vect_vec_iv_.16_57);
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
Steven,
Thanks for the feedback. I've committed the original patch as-is, but
I'm happy to improve it with follow up patches.
On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
> On Wed, Nov 20, 2013 at 8:29 PM, Oleg Endo wrote:
> >
> > The attached patch adds another SH specific RTL pass
On Thu, Nov 21, 2013 at 12:18:45PM +0100, Richard Biener wrote:
> > Bootstrap/regtest pending, ok at least for this for the start and can be
> > improved later on?
>
> Ok, this should catch most of the vectorizer cases.
>
> Zero could also be handled for PLUS_EXPR, likewise one for MULT_EXPR.
> I
On Thu, 21 Nov 2013, Jakub Jelinek wrote:
> On Thu, Nov 21, 2013 at 12:18:45PM +0100, Richard Biener wrote:
> > > Bootstrap/regtest pending, ok at least for this for the start and can be
> > > improved later on?
> >
> > Ok, this should catch most of the vectorizer cases.
> >
> > Zero could also
Hi Joseph,
Thanks for the comments I will address these issues and send an updated patch.
Graham
On Thu, Nov 21, 2013 at 12:37:01PM +0100, Richard Biener wrote:
> Oh, indeed. Bah. That case makes the whole stuff quadratic, too ;)
True, O(nelts^2), but largest nelts we have right now is 64 (V64QImode
on -mavx512f).
> For
>
> typedef int vLARGEsi __attribute__((vector_size(1024*1024)));
Th
Hi FX,
some first remarks.
FX wrote:
> I would like to get testing from:
> – a Solaris target (to test config/fpu-sysv.h)
> – an AIX target (to test config/fpu-aix.h)
For AIX, you could ask David Edelsohn for review.
For x87/SSE, you could ask Uros Bizjak for review.
For SysV you could ask
>> --- gcc/testsuite/lib/target-supports.exp(revision 205019)
>> +++ gcc/testsuite/lib/target-supports.exp(working copy)
>> proc add_options_for_ieee { flags } {
> ...
>> +set extra "-fno-unsafe-math-optimizations -frounding-math
>> -fsignaling-nans -fintrinsic-modules-path $specpath/l
On Nov 21, 2013, at 3:58 AM, FX wrote:
>>> --- gcc/testsuite/lib/target-supports.exp (revision 205019)
>>> +++ gcc/testsuite/lib/target-supports.exp (working copy)
>>> proc add_options_for_ieee { flags } {
>> ...
>>> +set extra "-fno-unsafe-math-optimizations -frounding-math
>>> -fsignali
Hello!
> Here’s my patch submission for adding IEEE intrinsic modules (following
> Fortran 2003 and 2008
> standards) to gfortran. It implements the item 1, and part of item 2, of my
> initial plan [1]. All the
> IEEE modules, types, named constants, procedures are defined and fully
> working.
On 20 November 2013 23:57, Cesar Philippidis wrote:
> On 11/20/13, 1:46 PM, Jonathan Wakely wrote:
>> On 20 November 2013 21:44, Jonathan Wakely wrote:
>>> On 29 October 2013 15:37, Cesar Philippidis wrote:
This patch addresses two issues with the libstdc++ testsuite:
* duplicate "
On Thu, Nov 21, 2013 at 10:31 AM, Ilya Enkovich wrote:
> 2013/11/20 Richard Biener :
>> On Wed, Nov 20, 2013 at 10:57 AM, Richard Biener
>> wrote:
>>> On Tue, Nov 19, 2013 at 9:18 PM, Ilya Enkovich
>>> wrote:
2013/11/19 Jeff Law :
> On 11/19/13 05:20, Ilya Enkovich wrote:
>>
>>
On Mon, Nov 18, 2013 at 03:25:52PM -0500, David Malcolm wrote:
> > So is there some reason the GIMPLE_CHECK was left in here rather than
> > doing the downcasting? This happens in other places.
Note that the changes removed tons of checks that IMHO were desirable.
The as_a that replaced those ch
> So what you are doing is basically not only rewriting memory references
> to possibly use TARGET_MEM_REF but also address uses to use
> &TARGET_MEM_REF. I think this is a good thing in general
> (given instructions like x86 lea) and I would not bother distinguishing
> the different kind of uses.
Wei Mi wrote:
>> So what you are doing is basically not only rewriting memory
>references
>> to possibly use TARGET_MEM_REF but also address uses to use
>> &TARGET_MEM_REF. I think this is a good thing in general
>> (given instructions like x86 lea) and I would not bother
>distinguishing
>> the d
I've made a small revision to this patch to handle recursive
invocations of d_expression and d_operator_name, restoring the
previous values of is_expression and is_conversion instead of just
setting them to 0 upon return. I've also added the long test case that
results in a substitution misnumberin
A recent change to the thread discovery code was missing a small, but
important hunk. Namely management of the temporary equivalences.
Amazingly, this didn't cause any bootstrapping problems on x86, but
Zhendong has a good testcase and it may be causing problems on Sparc.
In a nutshell, we
On 11/21/13 15:19, Jakub Jelinek wrote:
On Mon, Nov 18, 2013 at 03:25:52PM -0500, David Malcolm wrote:
So is there some reason the GIMPLE_CHECK was left in here rather than
doing the downcasting? This happens in other places.
Note that the changes removed tons of checks that IMHO were desirab
With my changes for PR 59054, it broke several of the ISA 2.07 tests that I
added due to DImode not being allowed in Altivec/VMX registers. This patch
adjusts these tests to reflect the current code generation. In addition, it
looks like I checked in the test for pr 59054 with the code duplicated
On Thu, 21 Nov 2013, N.M. Maclaren wrote:
> On Nov 21 2013, Joseph S. Myers wrote:
> > On Thu, 21 Nov 2013, FX wrote:
> >
> > > Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
> > > SysV, AIX).
> >
> > Note that glibc libm functions may not work when called in a flush-to-z
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> > Or is that part also required for
> > anything-other-than-ordinary-C-type alignment for the target;
> > say, natural 4-byte alignment of 4-byte-types for targets where
> > alignment is otherwise "packed"; where only 1-byte alignment of
> > the basic ty
Hi Jason,
Please see my responses below. I have also attached a fixed patch and
the Changelog entries are cut and pasted below.
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Thursday, November 21, 2013 1:59 PM
> To: Iyer, Balaji V; gcc-patches@gcc.gn
On Thu, Nov 21, 2013 at 03:24:55PM -0700, Jeff Law wrote:
> On 11/21/13 15:19, Jakub Jelinek wrote:
> >On Mon, Nov 18, 2013 at 03:25:52PM -0500, David Malcolm wrote:
> >>>So is there some reason the GIMPLE_CHECK was left in here rather than
> >>>doing the downcasting? This happens in other places.
I'd like to check in this code from the C11 branch so that it is present
in 4.9.
Its adds a target hook which can be used to override the default
alignment of an atomic type when used with C11's _Atomic qualifier.
There are a couple of ports which have stricter alignment requirements
for an a
The following patch documents the HTM built-in functions specific
to POWER. I bootstrapped and reviewed the gcc.info file and
everything looks good.
Ok for mainline?
Peter
* doc/extend.texi: Document htm builtins.
Index: gcc/doc/extend.texi
On 11/21/2013 05:42 PM, Jakub Jelinek wrote:
On Thu, Nov 21, 2013 at 03:24:55PM -0700, Jeff Law wrote:
On 11/21/13 15:19, Jakub Jelinek wrote:
On Mon, Nov 18, 2013 at 03:25:52PM -0500, David Malcolm wrote:
So is there some reason the GIMPLE_CHECK was left in here rather than
doing the downcast
On 11/21/13 11:17, Andrew MacLeod wrote:
On 11/21/2013 01:15 PM, Andrew MacLeod wrote:
The third patch has the config/* target changes, as well as a few
testcases. I did *not* trim out includes for the targets since I
got caught earlier with targets requiring some files on only some
configur
On Thu, Nov 21, 2013 at 1:01 PM, Richard Biener
wrote:
> Wei Mi wrote:
>>On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
>> wrote:
>>> Wei Mi wrote:
> So what you are doing is basically not only rewriting memory
references
> to possibly use TARGET_MEM_REF but also address uses to us
tree-vectorizer.h wraps all of source_location, LOCATION_LINE,
LOCATION_FILE and UNKNOWN_LOCATION.
The following gets rid of that pointless excercise.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-11-21 Richard Biener
* tree-vectorizer.h (LOC, UNKNOWN_LO
The new option should be able to use Var() in the .opt file rather than
having a variable defined explicitly or any explicit handling code in
c_common_handle_option, and shouldn't need to use UInteger (given the
option has no arguments).
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> I can bootstrap and check this on x86 to make sure it doesnt affect anything,
> and you can fool with it and see if you can get your desired results with your
> port.
Success!
For the record, tested together with the attached patch for the
CRIS ports,
On 11/21/13 11:15, Andrew MacLeod wrote:
The final gimple re-org patch!
These patches move the #includes out of gimple.h and into the .c files
which include gimple.h. They are:
#include "pointer-set.h"
#include "hash-table.h"
#include "vec.h"
#include "ggc.h"
#include "basic-block.h"
#include
On Tue, Nov 19, 2013 at 9:11 PM, Jeff Law wrote:
> On 11/19/13 19:33, David Malcolm wrote:
>>
>>
>> FWIW, it looks like you attached the whitespace cleanup patch again,
>> rather than the one you discuss above.
>>
>> For the archives, it looks like your email is referring to r205074
>> (though tha
On 11/21/2013 03:07 PM, Jeff Law wrote:
On 11/21/13 13:04, Andrew MacLeod wrote:
On 11/21/2013 02:26 PM, Jeff Law wrote:
On 11/21/13 11:15, Andrew MacLeod wrote:
Is there anything in particular one needs to do for plugins? I
thought I
saw a patch somewhere that changed something in the Makef
On 11/21/2013 06:23 PM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
I can bootstrap and check this on x86 to make sure it doesnt affect anything,
and you can fool with it and see if you can get your desired results with your
port.
Success!
For the record, tested togeth
On Thu, Nov 21, 2013 at 8:57 PM, Teresa Johnson wrote:
> There are two problems I am fixing here (see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 for full analysis).
>
> The first is the original ICE in crossjump optimization, which was
> exposed by enabling -freorder-blocks-and-partition w
Hello!
2013-11-21 Uros Bizjak
* config/i386/i386.c (ix86_expand_special_args_builtin): Use
ix86_zero_extend_to_Pmode where appropriate.
(ix86_expand_builtin): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.c
=
On 11/21/2013 05:46 PM, Andrew MacLeod wrote:
I'd like to check in this code from the C11 branch so that it is
present in 4.9.
Its adds a target hook which can be used to override the default
alignment of an atomic type when used with C11's _Atomic qualifier.
There are a couple of ports which
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
> with this/these patches
> at least I'll be able to tell people that _Atomic for C11 works.
Oh right, gcc still doesn't remove target-introduced "manual"
alignment checks (when expanding atomic intrinsics), but at
least gcc makes sure it's aligned on
On Thu, 2013-11-21 at 13:07 -0700, Jeff Law wrote:
> On 11/21/13 13:04, Andrew MacLeod wrote:
> > On 11/21/2013 02:26 PM, Jeff Law wrote:
> >> On 11/21/13 11:15, Andrew MacLeod wrote:
> >>>
> >>> Is there anything in particular one needs to do for plugins? I thought I
> >>> saw a patch somewhere th
"Joseph S. Myers" writes:
> On Wed, 20 Nov 2013, Gaius Mulley wrote:
>
>> Thanks for all the comments regarding the set of patches. Perhaps the
>> statement "use its own linker" is misleading. When gm2 is asked to link
>> a module hello.mod it does the following:
>
> Thanks for the explanation.
Hi,
This patch series fixes aarch64's autovectorization and gcc FE vector extension
programming models for ABI conformance. The ABI states
"Elements in a short vector are numbered such that the lowest numbered element
(element 0) occupies the lowest numbered bit (bit zero) in the vector and
On 11/21/13 04:20, Richard Biener wrote:
This moves another fold-const.c folding to the GIMPLE level.
In PR59058 it was noticed we fail to optimize
Well, you duplicated the optimization, you didn't move it :(
Of course the latter takes a lot more time to verify that nothing regresses.
Anyway,
> Having just looked at the opts.c and tree-ssa-live.c changes, they're fine.
Thanks, I've committed the patch.
-cary
On Nov 21 2013, Uros Bizjak wrote:
Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if
given a bit of help (someone to write the assembly code).
Just set FTZ bit in mxcsr. Please see
libgcc/config/i386/
Hi,
The attached patch swaps around high and low bits of the source operands of
narrow patterns for big-endian so that they end up in the correct order in the
destination.
Tested for aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-11-21 Tejas Belago
On 11/21/13 13:04, Andrew MacLeod wrote:
On 11/21/2013 02:26 PM, Jeff Law wrote:
On 11/21/13 11:15, Andrew MacLeod wrote:
Is there anything in particular one needs to do for plugins? I thought I
saw a patch somewhere that changed something in the Makefile, but don't
know if that is actually re
On Thu, Nov 21, 2013 at 1:19 PM, Uros Bizjak wrote:
>> Here’s my patch submission for adding IEEE intrinsic modules (following
>> Fortran 2003 and 2008
>> standards) to gfortran. It implements the item 1, and part of item 2, of my
>> initial plan [1]. All the
>> IEEE modules, types, named const
On Thu, Nov 21, 2013 at 8:26 AM, Wei Mi wrote:
> Hi,
>
> This patch works on the intrinsic calls handling issue in IVOPT mentioned
> here:
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>
> In find_interesting_uses_stmt, it changes
>
> arg = expr
> __builtin_xxx (arg)
>
> to
>
> arg =
The final gimple re-org patch!
These patches move the #includes out of gimple.h and into the .c files
which include gimple.h. They are:
#include "pointer-set.h"
#include "hash-table.h"
#include "vec.h"
#include "ggc.h"
#include "basic-block.h"
#include "tree-ssa-alias.h"
#include "internal-fn
Mike Stump writes:
> On Nov 20, 2013, at 5:58 AM, Richard Sandiford
> wrote:
>> I've committed a patch upstream to convert TREE_INT_CST_LOW to
>> tree_to_[su]hwi
>> if there is an obvious tree_fits_[su]hwi_p guard.
>
> So, in general, I like putting them on trunk, and then merging them into
> th
Hello!
> 2013-11-15 Ilya Enkovich
>
> * config/i386/i386-builtin-types.def (BND): New.
> (ULONG): New.
> (BND_FTYPE_PCVOID_ULONG): New.
> (VOID_FTYPE_BND_PCVOID): New.
> (VOID_FTYPE_PCVOID_PCVOID_BND): New.
> (BND_FTYPE_PCVOID_PCVOID): New.
> (BND_FTYPE_PCVOID): New.
> (BND_FTYPE_BND_BND): New.
Wei Mi wrote:
>On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
> wrote:
>> Wei Mi wrote:
So what you are doing is basically not only rewriting memory
>>>references
to possibly use TARGET_MEM_REF but also address uses to use
&TARGET_MEM_REF. I think this is a good thing in general
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
> Oh right, gcc still doesn't remove target-introduced "manual"
> alignment checks (when expanding atomic intrinsics), but at
> least gcc makes sure it's aligned on stack, when options doesn't
> say it's aligned. And a.c:plugh2 doesn't seem to perfor
On 11/17/2013 10:19 PM, Iyer, Balaji V wrote:
cp/cp-cilkplus.o \
- cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o \
+ cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o cp/cp-cilk.o \
It seems unnecessary to have both cp-cilk.c and cp-cilkplus.c. Please
combine them.
+ extern tre
On Wed, 20 Nov 2013, Kenneth Zadeck wrote:
> Richi,
>
> We noticed three problems with the place_field on the wide-int branch.They
> come from problems on the trunk. So i assume you want me to fix the trunk
> and push back into the branch. The question is how do you want them fixed?
>
>
Hi,
This patch fixes two issues to allow correct compilation of
gcc.dg/torture/vec-cvt-1.c in little endian mode. The first reverts a
change in three patterns in vector.md. This is from an early patch that
preceded the general fix for vector permutes. As a consequence we ended
up swapping the i
Hello!
>> However, it is used in the form of selecting hard underflow using a
>> compilation option, and not within the program. You certainly DO have
>> targets where it would work, even dynamically within the program, and I
>> think that it could be done even on x86. That isn't the same as it
On Thu, 2013-11-21 at 18:03 -0500, Andrew MacLeod wrote:
> On 11/21/2013 05:42 PM, Jakub Jelinek wrote:
> > On Thu, Nov 21, 2013 at 03:24:55PM -0700, Jeff Law wrote:
> >> On 11/21/13 15:19, Jakub Jelinek wrote:
> >>> On Mon, Nov 18, 2013 at 03:25:52PM -0500, David Malcolm wrote:
> > So is there
Hi,
This patch fixes up the lane access patterns to be symmetric to the order in
which vectors are stored in registers.
Tested for aarch64-none-elf and aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-11-21 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (aa
On Thu, 21 Nov 2013, Cong Hou wrote:
While I added the new define_insn_and_split for vec_merge, a bug is
exposed: in config/i386/sse.md, [ define_expand "xop_vmfrcz2" ]
only takes one input, but the corresponding builtin functions have two
inputs, which are shown in i386.c:
{ OPTION_MASK_ISA_X
On 11/21/13 11:15, Andrew MacLeod wrote:
Is there anything in particular one needs to do for plugins? I thought I
saw a patch somewhere that changed something in the Makefile, but don't
know if that is actually required since I never did that for any of the
others. Any plugin which used gimple
Hello,
after much pondering about the issue we came up with this design to
handle restrict more generally. Without a completely different way of
representing conflicts (or non-conflicts) of memory references we're bound
to somehow encode the necessary information into the points-to set (or in
On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
wrote:
> Wei Mi wrote:
>>> So what you are doing is basically not only rewriting memory
>>references
>>> to possibly use TARGET_MEM_REF but also address uses to use
>>> &TARGET_MEM_REF. I think this is a good thing in general
>>> (given instructio
> On 11/19/2013 02:54 PM, Jan Hubicka wrote:
>
> >The problem is that you have .a library consisting of slim LTO objects and
> >you link
> >with it during configure check without -flto.
>
> On the other hand, many configure checks will never work reliably
> with -flto because they rely heavily o
On Wed, Nov 20, 2013 at 7:17 PM, Joseph S. Myers
wrote:
> On Wed, 20 Nov 2013, Richard Biener wrote:
>
>> I suggest to remove real_sqrt and the only use in simplify-rtx.c instead
>> (or fix it to use MPFR as well - your choice).
>
> This patch removes real_sqrt. (I rather hope that in general lit
On 11/21/13, 5:42 AM, Jonathan Wakely wrote:
> On 20 November 2013 23:57, Cesar Philippidis wrote:
>> On 11/20/13, 1:46 PM, Jonathan Wakely wrote:
>>> On 20 November 2013 21:44, Jonathan Wakely wrote:
On 29 October 2013 15:37, Cesar Philippidis wrote:
> This patch addresses two issues with
On 11/19/2013 02:54 PM, Jan Hubicka wrote:
The problem is that you have .a library consisting of slim LTO objects and you
link
with it during configure check without -flto.
On the other hand, many configure checks will never work reliably with
-flto because they rely heavily on the fact that
- Original Message -
> 1) Can you please split out the forwprop pieces and motivate them
> separately?
Ok, done. The factored out forward-propagation part is nevertheless pretty
strong bound to this patch. And it shares some testsuite adjustment due this.
> 2) How did you decide on pass
Hi,
the patch below enables IRA live-range splitting that later
facilitates shrink-wrapping also work on ppc64. The difference is
that while on x86_64 it was enough to look for single sets from a hard
register to a pseudo in the first BB, on ppc the instructions are more
complicated and can look
This removes the broken function from tree-scalar-evolution.c and
re-implements it inside the now single user (but unfixed). It
also re-shuffles the vectorizer niter code some more to make
the final fix (use # of latch executions throughout) more easy.
Bootstrapped and tested on x86_64-unknown-l
> I moved recalculate_side_effects() from gimple.c to gimplify.c.
> gimplify.c was the primary consumer, and the only other caller was in
> the ada front end. By moving it, the ada front end doesn't need
> gimple.h any more.
Let's eliminate the only use in the Ada front end then, we probably just
Hi,
The attached patch fixes the mov standard pattern name for ABI conformance
for vector modes.
Tested for aarch64-none-elf, aarch64_be-none-elf. OK for trunk?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-11-21 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (*aarch64_simd_mo
On Nov 21 2013, Joseph S. Myers wrote:
On Thu, 21 Nov 2013, FX wrote:
Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
SysV, AIX).
Note that glibc libm functions may not work when called in a flush-to-zero
mode, only in modes that can be established by the functions.
On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz wrote:
> Hello,
>
> after much pondering about the issue we came up with this design to
> handle restrict more generally. Without a completely different way of
> representing conflicts (or non-conflicts) of memory references we're bound
> to somehow
1 - 100 of 159 matches
Mail list logo
