Right now jump threads from within a loop which cross the loop header,
then terminate within the loop are ignored as this may create
irreducible loops.
This patch gets the CFG/SSA updating code in good enough shape to handle
the case that the embedded guys care about. ie, the coremark FSA/F
Just something I noticed while looking at a problem tonight. We
threaded all the way back to the start of a jump threading path because
we didn't mark both blocks on the starting edge.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
Jeff
* t
PING.
Hi, there is a patch at
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01353.html which slipped away.
Thanks,
bin
On Fri, Nov 22, 2013 at 3:52 AM, H.J. Lu wrote:
> Silvermont supports POPCNT. This patch enables POPCNT for Silvermont.
> I also documented POPCNT for corei7, corei7-avx, core-avx-i, core-avx2 and
> slm. Since POPCNT is enabled with -msse4.2, this patch doesn't change
> code generation. It jus
On Tue, Nov 19, 2013 at 01:15:54PM +0100, Richard Biener wrote:
> On Mon, Nov 18, 2013 at 10:08 PM, Trevor Saunders
> wrote:
> > On Mon, Nov 18, 2013 at 10:03:53PM +0100, Marc Glisse wrote:
> >> On Mon, 18 Nov 2013, Trevor Saunders wrote:
> >>
> >> >This patch adds a class auto_vec which releases
Ping!
-Original Message-
From: Gopalasubramanian, Ganesh
Sent: Thursday, November 21, 2013 10:35 AM
To: 'H.J. Lu'
Cc: gcc-patches@gcc.gnu.org; Uros Bizjak (ubiz...@gmail.com); Richard Guenther
(richard.guent...@gmail.com);
borntrae...@de.ibm.com; Jakub Jelinek (ja...@redhat.com)
Subjec
On 11/21/2013 01:24 PM, Joseph S. Myers wrote:
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).
Good point
Hi,
This patch injects a condition into the instrumented code for edge
counter update. The counter value will not be updated after reaching
value 1.
The feature is under a new parameter --param=coverage-exec_once.
Default is disabled and setting to 1 to enable.
This extra check usually slows the
gcc/cp
* call.c (build_integral_nontype_arg_conv): Remove use of
EXPR_LOC_OR_HERE macro.
(convert_like_real): Likewise.
(convert_arg_to_ellipsis): Likewise.
(build_cxx_call): Likewise.
(perform_implicit_conversion_flags): Likewise.
(initialize
gcc/
* input.h (input_line): Remove.
(input_filename): Likewise.
(in_system_header): Likewise.
* tree.h (EXPR_LOC_OR_HERE): Remove.
---
gcc/input.h | 3 ---
gcc/tree.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/gcc/input.h b/gcc/input.h
index 8fdc7b2..55
gcc/
* builtins.c (c_strlen): Remove use of EXPR_LOC_OR_HERE macro.
* gimplify.c (internal_get_tmp_var): Likewise.
EXPR_LOC_OR_HERE macro.
(shortcut_cond_expr): Likewise.
* tree-diagnostic.c (diagnostic_report_current_function): Remove
use of input_fi
gcc/fortran
* trans.c (trans_runtime_error_vararg): Remove use of input_line
macro.
---
gcc/fortran/trans.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 204cbff..7805b57 100644
--- a/gcc/fortran/trans.c
+++ b/gc
gcc/
* config/bfin/bfin.c (output_file_start): Remove use of
input_filename macro.
---
gcc/config/bfin/bfin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index d7af939..6fdf153 100644
--- a/gcc/config/bfin/bfin
gcc/c
* c-decl.c (define_label, shadow_tag_warned)
(check_bitfield_type_and_width, grokdeclarator, grokparms,
store_parm_decls_newstyle, store_parm_decls_oldstyle)
(declspecs_add_type): Remove use of in_system_header macro.
* c-parser.c (c_parser_unary_expre
gcc/c-family
* c-common.c (unsafe_conversion_p): Remove use of
EXPR_LOC_OR_HERE macro.
(conversion_warning): Likewise.
(warnings_for_convert_and_check): Likewise.
(warn_for_collisions_1): Likewise.
(shorten_compare): Likewise, and remove use of in_sy
gcc/ada
* gcc-interface/utils2.c (build_call_raise): Remove use of
input_line macro.
(build_call_raise_range): Likewise.
(build_call_raise_column): Likewise.
---
gcc/ada/gcc-interface/utils2.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
gcc/java
* class.c (maybe_layout_super_class): Update comment.
* decl.c (java_add_stmt): Remove use of input_filename macro.
* jcf-parse.c (set_source_filename): Remove use of
input_filename macro.
(parse_class_file): Remove use of input_line and input_filena
The following patch series eliminates the following macros that
implicitly use input_location:
input.h:
#define input_line LOCATION_LINE (input_location)
#define input_filename LOCATION_FILE (input_location)
#define in_system_header (in_system_header_at (input_location))
#define E
On Thu, Nov 21, 2013 at 5:28 PM, Michael Meissner
wrote:
> 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
> look
David,
Here comes the inevitable followup.. I broke backwards compatibility
when adding an extra field to ffi_cif. I'd like to import again from
upstream, where I've already fixed the problem.
https://sourceware.org/ml/libffi-discuss/2013/msg00220.html
Actually, it's not a straight import becau
Hi,
Silvermont supports POPCNT. This patch enables POPCNT for Silvermont.
I also documented POPCNT for corei7, corei7-avx, core-avx-i, core-avx2 and
slm. Since POPCNT is enabled with -msse4.2, this patch doesn't change
code generation. It just makes it clear. OK to install?
Thanks.
H.J.
On Thu, Nov 21, 2013 at 7:27 PM, Bill Schmidt
wrote:
> 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
Richi,
Here is the patch. As you can see, i chose the unsigned option.
It was bootstrapped and tested on x86 with all languages including ada.
Ok to commit?
kenny
2013-11-21 zad...@naturalbridge.com
* store-layout.c
(place-field): Fix hwi test and accessor mismatch.
On 11/21/2013
On Thu, Nov 21, 2013 at 4:39 PM, Marc Glisse wrote:
> 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 ha
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
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 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 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
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
> Having just looked at the opts.c and tree-ssa-live.c changes, they're fine.
Thanks, I've committed the patch.
-cary
On Thu, Nov 21, 2013 at 3:31 PM, Steven Bosscher wrote:
> 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, w
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 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
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 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
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, 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/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, 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
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
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.
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
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 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
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
> 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
>> Let me rebase the
>> patch, kick off a bootstrap and regression tests, and I think I can be
>> ready to submit it if there are no objections.
>
> Here's the rebased patch. I'm running the bootstrap and regression tests now.
The bootstrap passed with no new regressions. Do I need approval for
th
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 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 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 11/21/13 13:53, Cary Coutant wrote:
Let me rebase the
patch, kick off a bootstrap and regression tests, and I think I can be
ready to submit it if there are no objections.
Here's the rebased patch. I'm running the bootstrap and regression tests now.
The bootstrap passed with no new regress
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
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
On Thu, 2013-11-21 at 16:13 -0500, David Edelsohn wrote:
> On Thu, Nov 21, 2013 at 3:41 PM, Peter Bergner wrote:
> > * doc/extend.texi: Document htm builtins.
>
> LGTM.
Thanks, committed as revision 205233.
Peter
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 which was
conservatively preventing some upstream block combining
On 11/21/2013 06:05 AM, Hans-Peter Nilsson wrote:
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.
Support
On Thu, Nov 21, 2013 at 3:41 PM, Peter Bergner wrote:
> 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.
Hi,
This patch adds C implementation for intrinsics matching:
vmov[q]_n_f[32,64]
vmov[q]_n_[u,s,p][8,16]
vmov[q]_n_[u,s][32,64]
Regression tests for those intrinsics added.
Full regression test ran with no regressions. Tested with Big Endian.
Any objections?
Thanks,
Alex
2013-11-21 Alex Vel
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
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/
On Nov 21 2013, FX wrote:
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 n
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, 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 =
On Wed, Nov 20, 2013 at 7:54 PM, Jeff Law wrote:
> On 11/20/13 03:02, Richard Biener wrote:
>>
>>
>> Note that this, the intrusiveness of the feature and the questionable
>> gain makes me question whether GCC should have support for this
>> feature (and whether we really should rush this in this l
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!
>> 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 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 Thu, Nov 21, 2013 at 7:05 AM, Xinliang David Li wrote:
> Would it be sufficient to
>
> 1) get rid of the 'may_increase_size' parameter' in all the unroll
> interfaces (basically make it true for O2); and
> 2) set MAX_COMPLETELY_PEELED_INSNS parameter to be a smaller value for
> O2? -- this make
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
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/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
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 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 required since I never did that for any of t
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
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.
On Thu, Nov 21, 2013 at 3:04 PM, 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
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 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 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
- 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
> I think most of these are because in the past (yes I have fixed that!!)
> all 'sizetype' constants were sign-extended (and the signedness,
> that is, TYPE_UNSIGNED (sizetype), was frontend dependend (ugh) and
> then later true, thus unsigned).
>
> So I think all _SIZE stuff should check fits_uhw
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
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 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 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
On 11/21/13 11:16, Andrew MacLeod wrote:
On 11/21/2013 01:15 PM, Andrew MacLeod wrote:
The second patch has the language front end changes. its only the
${language}-gimplify.c files which now actually require gimple.h
itself (yay). I also trimmed out the #includes which were introduced
but no
On 11/21/2013 11:32 AM, Joseph S. Myers wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
I'm trying to avoid ABI breakage of course. I'd rather not have
to ask people not to use _Atomic with 4.9 for CRIS ports using
official releases or have ABI breakage with the next release.
Maybe there's o
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> > I'm trying to avoid ABI breakage of course. I'd rather not have
> > to ask people not to use _Atomic with 4.9 for CRIS ports using
> > official releases or have ABI breakage with the next release.
> > Maybe there's one other port in the same situatio
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 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 Thu, Nov 21, 2013 at 2:12 PM, N.M. Maclaren wrote:
> 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 ass
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
Since there is already the __divtf3@GCC_3.0 compatibility alias in
libgcc we need to attach an explicit symbol version to the real __divtf3
in order to get it exported. This fixes the unversioned reference in
libgfortran.so, and fixes the failure of gfortran.dg/erf_3.F90. Tested
on ia64-suse-linu
Hi,
this is the required forward-propagation part for the type-demotion pass as
separate patch.
This patch is sharing some adjustments in testsuite due new optimization of
type-casts on shift-operations.
This patch tries to generate the "normal" form (TYPE) (X shift-op Y) out of the
"denormal"
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.
If any argument to a function is subn
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
> 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.
Michael,
Thanks for working to improve this feature.
I think that testing on a few more targets would be advisable because
other targets may expose problems caused by the effects of
optimizations exposed by better "restrict" implementation.
Thanks, David
Thanks for the comments.
Regards,
Wei.
On Thu, Nov 21, 2013 at 12:48 AM, Bin.Cheng wrote:
> 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 c
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
1 - 100 of 159 matches
Mail list logo
