Re: [PATCH] Fix up -march=native handling under KVM (PR target/61570)
On Mon, Jun 23, 2014 at 6:29 PM, H.J. Lu wrote: > --- gcc/config/i386/driver-i386.c.jj2014-05-14 14:45:54.0 > +0200 > +++ gcc/config/i386/driver-i386.c 2014-06-20 18:59:57.805006358 > +0200 > @@ -745,6 +745,11 @@ const char *host_detect_local_cpu (int a > /* Assume Core 2. */ > cpu = "core2"; > } > + else if (has_longmode) > + /* Perhaps some emulator? Assume x86-64, otherwise gcc > + -march=native would be unusable for 64-bit > compilations, > + as all the CPUs below are 32-bit only. */ > + cpu = "x86-64"; > else if (has_sse3) > /* It is Core Duo. */ > cpu = "pentium-m"; > > Jakub host_detect_local_cpu guesses the cpu based on the real processors. It doesn't work with emulators due to some conflicts. This isn't the only only place which has the same issue. I prefer something like this. >>> >>> I'm fine with your patch too. Let's wait what Uros (or other i?86 >>> maintainers) pick up. >> >> This looks OK to me. >> >> Thanks, >> Uros. > > This is what I checked in. This version was NOT approved. Please revert it ASAP and proceed with approved version. Uros.
Re: [PATCH, PR61554] ICE during CCP
On 2014/6/23 04:45 PM, Richard Biener wrote:
> On Mon, Jun 23, 2014 at 7:32 AM, Chung-Lin Tang
> wrote:
>> Hi Richard,
>>
>> In this change:
>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01278.html
>>
>> where substitute_and_fold() was changed to use a dom walker, the calls
>> to purge dead EH edges during the walk can alter the dom-tree, and have
>> chaotic results; the testcase in PR 61554 has some blocks traversed
>> twice during the walk, causing the segfault during CCP.
>>
>> The patch records the to-be-purged-for-dead-EH blocks in a similar
>> manner like stmts_to_remove, and processes it after the walk. (another
>> possible method would be using a bitmap to record the BBs + calling
>> gimple_purge_all_dead_eh_edges...)
>
> Oops.
>
>> Bootstrapped and tested on x86_64-linux, is this okay for trunk?
>
> Can you please use a bitmap and use gimple_purge_all_dead_eh_edges
> like tree-ssa-pre.c does?
>
> Also please add the reduced testcase from the PR to the g++.dg/torture
>
> Ok with that changes.
>
> Thanks,
> Richard.
Thanks for the review. Attached is what I committed. Testcase made by
Markus also added.
Thanks,
Chung-Lin
2014-06-24 Chung-Lin Tang
PR tree-optimization/61554
* tree-ssa-propagate.c: Include "bitmap.h".
(substitute_and_fold_dom_walker): Add 'bitmap need_eh_cleanup'
member,
properly update constructor/destructor.
(substitute_and_fold_dom_walker::before_dom_children):
Remove call to gimple_purge_dead_eh_edges, add bb->index to
need_eh_cleaup instead.
(substitute_and_fold): Call gimple_purge_all_dead_eh_edges on
need_eh_cleanup.
Index: tree-ssa-propagate.c
===
--- tree-ssa-propagate.c (revision 211927)
+++ tree-ssa-propagate.c (working copy)
@@ -29,6 +29,7 @@
#include "function.h"
#include "gimple-pretty-print.h"
#include "dumpfile.h"
+#include "bitmap.h"
#include "sbitmap.h"
#include "tree-ssa-alias.h"
#include "internal-fn.h"
@@ -1031,8 +1032,13 @@ class substitute_and_fold_dom_walker : public dom_
fold_fn (fold_fn_), do_dce (do_dce_), something_changed (false)
{
stmts_to_remove.create (0);
+ need_eh_cleanup = BITMAP_ALLOC (NULL);
}
-~substitute_and_fold_dom_walker () { stmts_to_remove.release (); }
+~substitute_and_fold_dom_walker ()
+{
+ stmts_to_remove.release ();
+ BITMAP_FREE (need_eh_cleanup);
+}
virtual void before_dom_children (basic_block);
virtual void after_dom_children (basic_block) {}
@@ -1042,6 +1048,7 @@ class substitute_and_fold_dom_walker : public dom_
bool do_dce;
bool something_changed;
vec stmts_to_remove;
+bitmap need_eh_cleanup;
};
void
@@ -1144,7 +1151,7 @@ substitute_and_fold_dom_walker::before_dom_childre
/* If we cleaned up EH information from the statement,
remove EH edges. */
if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
- gimple_purge_dead_eh_edges (bb);
+ bitmap_set_bit (need_eh_cleanup, bb->index);
if (is_gimple_assign (stmt)
&& (get_gimple_rhs_class (gimple_assign_rhs_code (stmt))
@@ -1235,6 +1242,9 @@ substitute_and_fold (ssa_prop_get_value_fn get_val
}
}
+ if (!bitmap_empty_p (walker.need_eh_cleanup))
+gimple_purge_all_dead_eh_edges (walker.need_eh_cleanup);
+
statistics_counter_event (cfun, "Constants propagated",
prop_stats.num_const_prop);
statistics_counter_event (cfun, "Copies propagated",
Re: Fortran OpenMP UDR fixes, nested handling fixes etc.
Jakub Jelinek wrote:
So, either we need something like the following patch (incremental), or
another possibility for the problem is not do the value.function.name
related change in module.c in the UDR patch, and instead fix up the UDR
combiner/initializer expressions when they are loaded from module
(change "" name to NULL only in the UDR combiner/initializer expressions,
where they shouldn't be resolved yet). Or make sure value.function.name
is set to non-NULL when resolving all intrinsic function calls, rather than
just for a subset of them.
With this patch it seems to pass bootstrap/regtest.
I think your patch looks sufficiently sleek that I would go for it.
Tobias
2014-06-21 Jakub Jelinek
* resolve.c (resolve_function): If value.function.isym is non-NULL,
consider it already resolved.
* module.c (fix_mio_expr): Likewise.
* trans-openmp.c (gfc_trans_omp_array_reduction_or_udr): Don't
initialize value.function.isym.
--- gcc/fortran/resolve.c.jj2014-06-20 23:31:49.0 +0200
+++ gcc/fortran/resolve.c 2014-06-21 20:07:39.708099045 +0200
@@ -2887,7 +2887,8 @@ resolve_function (gfc_expr *expr)
/* See if function is already resolved. */
- if (expr->value.function.name != NULL)
+ if (expr->value.function.name != NULL
+ || expr->value.function.isym != NULL)
{
if (expr->ts.type == BT_UNKNOWN)
expr->ts = sym->ts;
--- gcc/fortran/module.c.jj 2014-06-20 23:31:49.0 +0200
+++ gcc/fortran/module.c2014-06-23 08:53:50.488662314 +0200
@@ -3173,7 +3173,8 @@ fix_mio_expr (gfc_expr *e)
&& !e->symtree->n.sym->attr.dummy)
e->symtree = ns_st;
}
- else if (e->expr_type == EXPR_FUNCTION && e->value.function.name)
+ else if (e->expr_type == EXPR_FUNCTION
+ && (e->value.function.name || e->value.function.isym))
{
gfc_symbol *sym;
--- gcc/fortran/trans-openmp.c.jj 2014-06-20 23:31:49.0 +0200
+++ gcc/fortran/trans-openmp.c 2014-06-23 11:53:02.932495166 +0200
@@ -1417,7 +1417,6 @@ gfc_trans_omp_array_reduction_or_udr (tr
e4->expr_type = EXPR_FUNCTION;
e4->where = where;
e4->symtree = symtree4;
- e4->value.function.isym = gfc_find_function (iname);
e4->value.function.actual = gfc_get_actual_arglist ();
e4->value.function.actual->expr = e3;
e4->value.function.actual->next = gfc_get_actual_arglist ();
[RFC] Making fold-const sane WRT symbol visibilities
Hello,
fold-const contains quite few confused statements that deal with WEAK
visibility and aliases:
static int
simple_operand_p (const_tree exp)
{
/* Strip any conversions that don't change the machine mode. */
STRIP_NOPS (exp);
return (CONSTANT_CLASS_P (exp)
|| TREE_CODE (exp) == SSA_NAME
|| (DECL_P (exp)
&& ! TREE_ADDRESSABLE (exp)
&& ! TREE_THIS_VOLATILE (exp)
&& ! DECL_NONLOCAL (exp)
/* Don't regard global variables as simple. They may be
allocated in ways unknown to the compiler (shared memory,
#pragma weak, etc). */
&& ! TREE_PUBLIC (exp)
&& ! DECL_EXTERNAL (exp)
/* Weakrefs are not safe to be read, since they can be NULL.
They are !TREE_PUBLIC && !DECL_EXTERNAL but still
have DECL_WEAK flag set. */
&& (! VAR_OR_FUNCTION_DECL_P (exp) || ! DECL_WEAK (exp))
/* Loading a static variable is unduly expensive, but global
registers aren't expensive. */
&& (! TREE_STATIC (exp) || DECL_REGISTER (exp;
}
Here I think WEAK is useless, since we already check PUBLIC.
/* If this is an equality comparison of the address of two non-weak,
unaliased symbols neither of which are extern (since we do not
have access to attributes for externs), then we know the result. */
if (TREE_CODE (arg0) == ADDR_EXPR
&& VAR_OR_FUNCTION_DECL_P (TREE_OPERAND (arg0, 0))
&& ! DECL_WEAK (TREE_OPERAND (arg0, 0))
&& ! lookup_attribute ("alias",
DECL_ATTRIBUTES (TREE_OPERAND (arg0, 0)))
&& ! DECL_EXTERNAL (TREE_OPERAND (arg0, 0))
&& TREE_CODE (arg1) == ADDR_EXPR
&& VAR_OR_FUNCTION_DECL_P (TREE_OPERAND (arg1, 0))
&& ! DECL_WEAK (TREE_OPERAND (arg1, 0))
&& ! lookup_attribute ("alias",
DECL_ATTRIBUTES (TREE_OPERAND (arg1, 0)))
&& ! DECL_EXTERNAL (TREE_OPERAND (arg1, 0)))
Here we no longer consstently use alias attribute to do aliases - it should
ask symtab. Moreover it handle just fraction of cases where we can prove
nonequality.
and some others.
This patch attempts to deal with nonzero that is one of basic predicates. I
added
symtab_node::nonzero that I hope is implemented safely and I removed the
fold-const
code (I will cleanup a bit its implementation - at the very end I added the
flag_ checks that makes it osmewhat ugly).
The problem is that I do not think I can safely fold before symtab is
constructed
as shown by the testcase:
extern int a;
t()
{
return &a!=0;
}
extern int a __attribute__ ((weak));
Here we incorrectly fold into true before we see the weak predicate.
The problem is that the patch fails testcases that assume we do such folding at
parsing
time.
./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-1.c (test for excess errors)
./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-2.c (test for excess errors)
./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-3.c (test for excess errors)
./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-4.c (test for excess errors)
Here we accept the source as compile time constant while I think it is not:
int sc = (&sc > 0);
Does it seem resonable to turn those testcases into one testing for error and
live with delaying the folding oppurtunities to early opts? They are now caught
by ccp1 pass usually.
Honza
* cgraph.h (symtab_node): Add method nonzero.
(decl_in_symtab_p): Break out from ...
(symtab_get_node): ... here.
* symtab.c (symtab_node::nonzero): New method.
* fold-const.c: Include cgraph.h
(tree_single_nonzero_warnv_p): Use symtab for symbols.
* testsuite/g++.dg/tree-ssa/nonzero-2.C: New testcase.
* testsuite/g++.dg/tree-ssa/nonzero-1.C: New testcase.
* testsuite/gcc.dg/tree-ssa/nonzero-1.c: New testcase.
Index: cgraph.h
===
--- cgraph.h(revision 211915)
+++ cgraph.h(working copy)
@@ -214,6 +214,9 @@ public:
void set_init_priority (priority_type priority);
priority_type get_init_priority ();
+
+ /* Return true if symbol is known to be nonzero. */
+ bool nonzero ();
};
enum availability
@@ -1068,6 +1077,17 @@ void varpool_remove_initializer (varpool
/* In cgraph.c */
extern void change_decl_assembler_name (tree, tree);
+/* Return true if DECL should have entry in symbol table if used.
+ Those are functions and static & external veriables*/
+
+static bool
+decl_in_symtab_p (const_tree decl)
+{
+ return (TREE_CODE (decl) == FUNCTION_DECL
+ || (TREE_CODE (decl) == VAR_DECL
+ && (TREE_STATIC (decl) || DECL_EXTERNAL (decl;
+}
+
/* Return symbol table node associated with DECL, if any,
and NULL otherwise. */
@@ -1075,12 +1095,7 @@ static inline symtab_node *
sym
Re: [PATCH] Fix for invalid sanitization of trailing byte in __builtin_strlen
On 06/23/2014 10:11 PM, Jeff Law wrote: On 06/23/14 10:55, Maxim Ostapenko wrote: Hi, when I applied this patch (r211846), I made a little mistake in output test patterns. This patch fixes this. Tested on x86_64-unknown-linux-gnu. Ok to commit? OK. jeff Thanks, done in r211927. -Maxim
Re: [patch] change specific int128 -> generic intN
> The changes to dwarf2asm.c, cppbuiltin.c, optabs.c, defaults.h, expr.c, > expmed.c, tree-dfa.c, simplify-rtx.c, lto-object.c, loop-iv.c, varasm.c, > the msp430 back end and some of the stor-layout.c changes don't look like > they should depend on the rest of the patch. I think it would help review > if anything that can reasonably be separated from the main intN support is > posted separately, as a much smaller patch with its own self-contained > rationale (I presume all those changes should work fine without the main > intN support), and then the intN patch only contains things directly > related to intN support. There are basically three types of changes working together here: 1. Changes that remove the "types are powers of two" assumptions throughout gcc. At least, as many as I could find. These could be applied without the intN support, but serve no purpose without it. 2. The intN patch itself. 3. The msp430's changes to use __int20 for size_t, which depends on the above two. I'll split them up but I hope progress on set #2 isn't stalled on bikeshedding set #1, especially since set #1 doesn't solve any problems (or really, change *anything*) on its own.
Re: [patch] change specific int128 -> generic intN
> Since the test on __STRICT_ANSI__ is removed for all other uses, it would > seem consistent to me to remove this one as well. Besides, you are already > testing __GLIBCXX_USE_INT_N_0, which as far as I understand is protected > by !flag_iso (with the exception of size_t). Yup, I'll clean that up. > > -#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_INT128) > > + // Conditionalizing on __STRICT_ANSI__ here will break any port that > > + // uses one of these types for size_t. > > +#if defined(__GLIBCXX_USE_INT_N_0) > > template<> > > -struct __is_integral_helper<__int128> > > +struct __is_integral_helper<__GLIBCXX_TYPE_INT_N_0> > > Since the check for __STRICT_ANSI__ is removed, do we need to add > __extension__ in front of __GLIBCXX_TYPE_INT_N_0 to avoid warning with > -Wsystem-headers? I copied the code from the __int128 case, and it explicitly bypassed -Wsystem-headers... so we don't have that problem. Not sure if we *should* have that problem, but we didn't before... I can only assume that either (1) someone found it too difficult to get __extension__ to work right in all those cases, or (2) it's a bug. Or (3) for some reason they decided to do it that way anyway. I don't know. > That seems complicated. You just need to call emit_support_tinfo_1 on > each of the types (see how fundamentals is used at the end of the > function), no need to put everything in the array. Sure, *now* you tell me that :-) I can do it either way, but it's the same overhead to iterate through the types. Shoving it into the array is a bit more future-proof, but keeping the index in sync is a bit of work if the table ever changes. Your choice ;-)
Re: [PATCH] gcc: fix segfault from calling free on non-malloc'd area
[Re: [PATCH] gcc: fix segfault from calling free on non-malloc'd area] On 23/06/2014 (Mon 14:32) Jeff Law wrote: > On 06/23/14 14:09, Tobias Burnus wrote: > >This patch broke bootstrapping for me on x86-64-gnu-linux: > > > >/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: > >i386 architecture of input file `/usr/lib/crti.o' is incompatible with > >i386:x86-64 output > > > > >If I revert the patch, it works for me. > Reverted. Will have to look deeper. Paul, did you bootstrap with > this patch on the trunk? Hi Jeff, I was using the yocto/oe-core build system, and hence it was creating gcc-cross-initial from its own build system (with ~50 other patches on gcc-4.9.0 baseline) -- so it isn't 100% identical to a manual bootstrapping on trunk. It sounds like Jakub has provided additional details on why this may have broken bootstrap, as the issue appears to be possibly of wider scope than I originally reported. I'll revisit it tomorrow morning, and see what additional details I can provide. Thanks, Paul. -- > > jeff > >
Re: [PATCH 5/5] add libcc1
On Mon, Jun 23, 2014 at 01:09:41PM -0600, Jeff Law wrote: > On 06/20/14 09:33, Tom Tromey wrote: > >>"Trevor" == Trevor Saunders writes: > > > >Trevor> I'm curious, what is the reason you choose not to write this in > >C++11 or > >Trevor> later? Its distributed with gcc, so the only case where you aren't > >Trevor> building with the in tree compiler and libraries is when your cross > >Trevor> compiling gcc, and it doesn't seem particularly important to support > >Trevor> building the plugin or library in that configuration. So istm you > >could > >Trevor> go all the way and assume you are being built with trunk gcc and > >Trevor> libraries. > > > >The plugin has to be ABI compatible with GCC itself, and my > >understanding was that C++11 and "however GCC is built" are not > >necessarily compatible. > Presumably you're referring to the upcoming abi breakage for C++ pair & > list. > > There's ways around that with the ABI tagging we're using, but at least for > now, the safe thing to do for something that must be ABI compatibile with > GCC itself is to stick with C++03 mode. > hrm, I know basically nothing about the upcoming changes, but I would have expected linking c++03 code against c++11 code would be fine especially when the interface doesn't involve any stl. > >Switching to C++11 would be an improvement -- variadic templates would > >simplify the RPC code (with a complicated caveat). So if it is possible > >I am interested. > There'll probably be a day when we can bless C++11 for building GCC itself > and any associated plugins, but we're not at that point right now. > > >Trevor> So can we add C++ stuff to libiberty and allow building > >Trevor> libiberty without it for binutils / gdb, or can we do something > >Trevor> else to avoid this kind of stuff? > > > >One way would be to just make a new top-level directory for a new > >library. > Seems like the easiest solution, at least for now. ugh more autotools, but wfm. > >Thanks. I changed it to do a NULL check. It's nothrow because nothing > >in libcc1 or gdb is prepared for a C++ exception. While I like > >exceptions (gdb uses its own longjmp-based exception system > >extensively), my understanding is that they aren't currently used in > >gcc. > Right. Or if we're using them in GCC, any such use is well buried in > non-critical , not widely known & marginally, if at all, tested code. Well, we build everything or at least everything I've seen with -fno-exceptions, so if something does throw we'll just crash right? istm we certainly write code calling the throwing new with that expectation. Trev > > Jeff >
Re: [PATCH] Introducing SAD (Sum of Absolute Differences) operation to GCC vectorizer.
It has been 8 months since this patch is posted. I have addressed all comments to this patch. The SAD pattern is very useful for some multimedia algorithms like ffmpeg. This patch will greatly improve the performance of such algorithms. Could you please have a look again and check if it is OK for the trunk? If it is necessary I can re-post this patch in a new thread. Thank you! Cong On Tue, Dec 17, 2013 at 10:04 AM, Cong Hou wrote: > > Ping? > > > thanks, > Cong > > > On Mon, Dec 2, 2013 at 5:06 PM, Cong Hou wrote: > > Hi Richard > > > > Could you please take a look at this patch and see if it is ready for > > the trunk? The patch is pasted as a text file here again. > > > > Thank you very much! > > > > > > Cong > > > > > > On Mon, Nov 11, 2013 at 11:25 AM, Cong Hou wrote: > >> Hi James > >> > >> Sorry for the late reply. > >> > >> > >> On Fri, Nov 8, 2013 at 2:55 AM, James Greenhalgh > >> wrote: > On Tue, Nov 5, 2013 at 9:58 AM, Cong Hou wrote: > > Thank you for your detailed explanation. > > > > Once GCC detects a reduction operation, it will automatically > > accumulate all elements in the vector after the loop. In the loop the > > reduction variable is always a vector whose elements are reductions of > > corresponding values from other vectors. Therefore in your case the > > only instruction you need to generate is: > > > > VABAL ops[3], ops[1], ops[2] > > > > It is OK if you accumulate the elements into one in the vector inside > > of the loop (if one instruction can do this), but you have to make > > sure other elements in the vector should remain zero so that the final > > result is correct. > > > > If you are confused about the documentation, check the one for > > udot_prod (just above usad in md.texi), as it has very similar > > behavior as usad. Actually I copied the text from there and did some > > changes. As those two instruction patterns are both for vectorization, > > their behavior should not be difficult to explain. > > > > If you have more questions or think that the documentation is still > > improper please let me know. > >>> > >>> Hi Cong, > >>> > >>> Thanks for your reply. > >>> > >>> I've looked at Dorit's original patch adding WIDEN_SUM_EXPR and > >>> DOT_PROD_EXPR and I see that the same ambiguity exists for > >>> DOT_PROD_EXPR. Can you please add a note in your tree.def > >>> that SAD_EXPR, like DOT_PROD_EXPR can be expanded as either: > >>> > >>> tmp = WIDEN_MINUS_EXPR (arg1, arg2) > >>> tmp2 = ABS_EXPR (tmp) > >>> arg3 = PLUS_EXPR (tmp2, arg3) > >>> > >>> or: > >>> > >>> tmp = WIDEN_MINUS_EXPR (arg1, arg2) > >>> tmp2 = ABS_EXPR (tmp) > >>> arg3 = WIDEN_SUM_EXPR (tmp2, arg3) > >>> > >>> Where WIDEN_MINUS_EXPR is a signed MINUS_EXPR, returning a > >>> a value of the same (widened) type as arg3. > >>> > >> > >> > >> I have added it, although we currently don't have WIDEN_MINUS_EXPR (I > >> mentioned it in tree.def). > >> > >> > >>> Also, while looking for the history of DOT_PROD_EXPR I spotted this > >>> patch: > >>> > >>> [autovect] [patch] detect mult-hi and sad patterns > >>> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01394.html > >>> > >>> I wonder what the reason was for that patch to be dropped? > >>> > >> > >> It has been 8 years.. I have no idea why this patch is not accepted > >> finally. There is even no reply in that thread. But I believe the SAD > >> pattern is very important to be recognized. ARM also provides > >> instructions for it. > >> > >> > >> Thank you for your comment again! > >> > >> > >> thanks, > >> Cong > >> > >> > >> > >>> Thanks, > >>> James > >>>
RE: [PATCH,MIPS] MIPS64r6 support
On Mon, 2014-06-23 at 03:31 -0700, Matthew Fortune wrote:
> > > Recommendations on how to rework the mips.exp logic to cope with this
> > > would be appreciated.
> >
> > Could you give an example of the kind of thing you mean?
>
> You have actually covered the cases I was concerned about below. The
> problem cases are those tests that already have a isa/isa_rev >= ...
>
> > If tests really do need r5 or earlier, we should enforce that in the
> > dg-options. E.g. for conditional moves we should add an isa_rev
> > limit to the existing tests and add new ones with isa_rev>=6.
>
> OK. Steve has actually been working on this in parallel to the
> review and has taken this approach.
>
> > I suppose we'll need a way of specifying an isa_rev range, say
> > "isa_rev=2-5". That should be a fairly localised change though.
>
> There appear to be about 9 tests that are not fixed by educating mips.exp
> about flags which are not supported on R6. Steve has initially dealt with
> these via forbid_cpu=mips.*r6 but I guess it would be cleaner to try and
> support an isa_rev range. I'll see we can club together enough tcl skills
> to write it :-)
Here is a change to mips.exp to support a range for isa or isa_rev.
This takes care of problems like madd-3.c where I can
change 'isa_rev>=1' to 'isa_rev=1-5' but it doesn't seem to help with a
test like movcc-1.c. That currently has 'isa>=4' and I want to add
'isa_rev<=5' but mips.exp does not seem to allow both a isa and an
isa_rev check in the same test. I am not sure if that change could be
easily added, I don't see a clean way to implement it off hand.
Steve Ellcey
sell...@mips.com
2014-06-23 Steve Ellcey
* gcc.target/mips/mips.exp (mips-dg-options): Check for range
of values on isa or isa_rev pseudo-options.
diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
b/gcc/testsuite/gcc.target/mips/mips.exp
index 1c45a77..e28ecb6 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -974,7 +974,21 @@ proc mips-dg-options { args } {
set arch "-march=loongson2f"
}
} else {
- if { ![regexp {^(isa(?:|_rev))(=|<=|>=)([0-9]*)$} \
+ # First check for a range of legal values to isa or isa_rev,
+ # Then check for a minimum, maximum, or exact value requirement.
+ if { [regexp {^(isa(?:|_rev))(=)([0-9]*)[-]([0-9]*)$} \
+ $spec dummy prop relation minvalue maxvalue nocpus] } {
+ set current [mips_arch_info $arch $prop]
+ # Set value so that the code below will force the appropriate
+ # isa or isa_rev setting if it is necessary.
+ if { $current > $maxvalue } {
+ set value $maxvalue
+ } elseif { $current < $minvalue } {
+ set value $minvalue
+ } else {
+ set value $current
+ }
+ } elseif { ![regexp {^(isa(?:|_rev))(=|<=|>=)([0-9]*)$} \
$spec dummy prop relation value nocpus] } {
error "Unrecognized isa specification: $spec"
}
[patch] fix namespaces for std::experimental types
The current Fundamentals TS says any, optional and string_view should
be in an inline namespace called fundamentals_v1.
Tested x86_64-linux, committed to trunk.
commit 3b316b60d21ea224c56bb23a8e1afb06e2277cf8
Author: Jonathan Wakely
Date: Mon Jun 23 21:34:29 2014 +0100
* include/experimental/any (any_v1): Rename namespace to
fundamentals_v1. Change string returned by bad_any_cast::what().
* include/experimental/optional (fundamentals_v1): Add namespace.
* include/experimental/string_view (fundamentals_v1): Likewise.
* testsuite/experimental/any/typedefs.cc: New.
* testsuite/experimental/optional/typedefs.cc: New.
* testsuite/experimental/string_view/typedefs.cc: New.
diff --git a/libstdc++-v3/include/experimental/any b/libstdc++-v3/include/experimental/any
index 1e8d9b2..643fc23 100644
--- a/libstdc++-v3/include/experimental/any
+++ b/libstdc++-v3/include/experimental/any
@@ -47,7 +47,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
namespace experimental
{
-inline namespace any_v1
+inline namespace fundamentals_v1
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -68,7 +68,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
class bad_any_cast : public bad_cast
{
public:
-virtual const char* what() const noexcept { return "bad_any_cast"; }
+virtual const char* what() const noexcept { return "bad any_cast"; }
};
[[gnu::noreturn]] inline void __throw_bad_any_cast()
@@ -604,7 +604,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// @} group any
_GLIBCXX_END_NAMESPACE_VERSION
-} // namespace any_v1
+} // namespace fundamentals_v1
} // namespace experimental
} // namespace std
diff --git a/libstdc++-v3/include/experimental/optional b/libstdc++-v3/include/experimental/optional
index 2a3f29d..c68d7ea 100644
--- a/libstdc++-v3/include/experimental/optional
+++ b/libstdc++-v3/include/experimental/optional
@@ -52,6 +52,8 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
namespace experimental
{
+inline namespace fundamentals_v1
+{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
@@ -797,6 +799,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// @} group optional
_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace fundamentals_v1
}
// [X.Y.12]
diff --git a/libstdc++-v3/include/experimental/string_view b/libstdc++-v3/include/experimental/string_view
index b54c9e8..4b1a107 100644
--- a/libstdc++-v3/include/experimental/string_view
+++ b/libstdc++-v3/include/experimental/string_view
@@ -46,6 +46,8 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
namespace experimental
{
+inline namespace fundamentals_v1
+{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
@@ -582,6 +584,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif
_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace fundamentals_v1
} // namespace experimental
diff --git a/libstdc++-v3/testsuite/experimental/any/typedefs.cc b/libstdc++-v3/testsuite/experimental/any/typedefs.cc
new file mode 100644
index 000..a3f364d
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/any/typedefs.cc
@@ -0,0 +1,30 @@
+// { dg-options "-std=gnu++14" }
+// { dg-do compile }
+
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a moved_to of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[Committed] New testcase for conditional move with conditional compares
Hi,
When looking at the current conditional compare patch, I find that
we don't have a testcase to test that we don't ICE for the case where
we have conditional compares and conditional moves where the moves are
of floating point types.
This patch adds that testcase to the C torture compile test to make
sure we don't ICE (which I think we do currently).
Thanks,
Andrew Pinski
2014-06-23 Andrew Pinski
* gcc.c-torture/compile/20140723-1.c: New testcase.
Index: gcc.c-torture/compile/20140723-1.c
===
--- gcc.c-torture/compile/20140723-1.c (revision 0)
+++ gcc.c-torture/compile/20140723-1.c (revision 0)
@@ -0,0 +1,4 @@
+double f(double a, double b, int c, int d)
+{
+ return (c>10&&d>20)?a:b;
+}
Index: ChangeLog
===
--- ChangeLog (revision 211915)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-06-23 Andrew Pinski
+
+ * gcc.c-torture/compile/20140723-1.c: New testcase.
+
2014-06-23 Marek Polacek
PR c/61553
Re: [PATCH] gcc: fix segfault from calling free on non-malloc'd area
On Mon, Jun 23, 2014 at 02:32:37PM -0600, Jeff Law wrote:
> On 06/23/14 14:09, Tobias Burnus wrote:
> >This patch broke bootstrapping for me on x86-64-gnu-linux:
> >
> >/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> >i386 architecture of input file `/usr/lib/crti.o' is incompatible with
> >i386:x86-64 output
>
> >
> >If I revert the patch, it works for me.
> Reverted. Will have to look deeper. Paul, did you bootstrap with this
> patch on the trunk?
I can see one spot where multilib_os_dir is set to non-malloced string
literal, and at that point we also leak memory.
So, supposedly:
new_multilib_os_dir = XNEWVEC (char, ml_end - q);
memcpy (new_multilib_os_dir, q + 1, ml_end - q - 1);
new_multilib_os_dir[ml_end - q - 1] = '\0';
multilib_os_dir = *new_multilib_os_dir ? new_multilib_os_dir :
".";
should be instead:
if (ml_end - q == 1)
multilib_os_dir = xstrdup (".");
else
{
new_multilib_os_dir = XNEWVEC (char, ml_end - q);
memcpy (new_multilib_os_dir, q + 1, ml_end - q - 1);
new_multilib_os_dir[ml_end - q - 1] = '\0';
multilib_os_dir = new_multilib_os_dir;
}
or so (completely untested). Bet this got broken when the multiarch support
has been added, before that multilib_os_dir has always been malloced.
Alternatively, multilib_os_dir could be set to NULL instead of setting it to
".".
Jakub
Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)
On Mon, 2014-06-23 at 14:54 -0400, David Malcolm wrote:
> FWIW I'm actually working on such a change, or, at least, to make
> instructions be a subclass of rtx_def; presumably this should make it
> easier to make it an entirely separate type, if that's desirable.
>
> Executive summary is that it's still a work in progress, and I'm going
> to be giving a talk about it at Cauldron next month ("A proposal for
> typesafe RTL", currently scheduled for the Sunday at 12.45 in Stream 2).
>
> More detailed version:
> I experimented with this a few months ago, and came up with a 159-patch
> patch series:
> http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v1/
>
> That patch kit builds on x86_64 (and regrtests iirc), and uses a
> separate subclass for insns e.g. in the core basic block class, in the
> scheduler, register allocators, etc, but:
> (A) it only builds on about 70 of the ~200 configurations in
> config-list.mk
> (B) there was a tangled mess of dependencies between the patches
> making it hard to fix (A)
> (C) I went with the rather verbose "rtx_base_insn" name, which in v1
> is a typedef for a pointer to an insn, along with a family of other
> typedefs, which I now realize is frowned upon e.g.:
> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01520.html
> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01632.html
> (D) I was using as_a *methods* rather than just as_a <>, like
> in v1 of my gimple-classes patches:
> (https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00887.html)
>
>
> So I've been reworking it, incorporating feedback from the gimple
> statement classes work; the latest patch series is v7 and can be seen
> here:
> http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v7/
>
> It builds and regrtests on x86_64 on top of r211061 (aka
> dcd5393fd5b3ac53775a5546f3103958b64789bb) and builds on 184 of the
> configurations in config-list.mk; I have patches to fix the remaining
> ones to achieve parity with an unpatched build.
>
> The current class hierarchy looks like this:
> /* Subclasses of rtx_def, using indentation to show the class
>hierarchy, along with the relevant invariant. */
> class rtx_def;
> class rtx_insn; /* (INSN_P (X) || NOTE_P (X)
> || JUMP_TABLE_DATA_P (X) || BARRIER_P (X)
> || LABEL_P (X)) */
> class rtx_real_insn; /* INSN_P (X) */
> class rtx_debug_insn; /* DEBUG_INSN_P (X) */
> class rtx_nonjump_insn;/* NONJUMP_INSN_P (X) */
> class rtx_jump_insn; /* JUMP_P (X) */
> class rtx_call_insn; /* CALL_P (X) */
> class rtx_jump_table_data; /* JUMP_TABLE_DATA_P (X) */
> class rtx_barrier; /* BARRIER_P (X) */
> class rtx_code_label;/* LABEL_P (X) */
> class rtx_note; /* NOTE_P (X) */
>
> and the code now uses "rtx_insn *" in hundreds of places where it would
> previously have used "rtx".
>
> My aim is that it always builds on every config: each patch is
> self-contained. To do this, the initial patches add scaffolding that
> adds some strategically-placed checked downcasts to rtx_insn * (e.g. on
> the result of PREV_INSN/NEXT_INSN). The subsequent patches then use
> these promises in order to strengthen the insn-handling code to work on
> the new subclass. The idea is that the final patches then remove this
> scaffolding, with the core BB types becoming rtx_insn *. The drawback
> of course is that during the process the resulting compiler is much
> slower - until the scaffolding is removed.
>
> v1 of the patch series also added some non-insn subclasses of rtx, for
> EXPR_LIST, INSN_LIST, and for SEQUENCE, allowing rewriting of iterations
> like this (in jump.c:rebuild_jump_labels_1), where "insn" and
> "forced_labels" are INSN_LIST and hence are "rtx_insn_list *":
>
> -for (insn = forced_labels; insn; insn = XEXP (insn, 1))
> - if (LABEL_P (XEXP (insn, 0)))
> - LABEL_NUSES (XEXP (insn, 0))++;
> +for (insn = forced_labels; insn; insn = insn->next ())
> + if (LABEL_P (insn->element ()))
> + LABEL_NUSES (insn->element ())++;
>
> Thoughts?
Personally, I'd like to see usage of standard STL-like iterator usage.
I've proposed something for edge_iterator a while ago, but people don't
seem very fond of it. See also
https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01129.html
Have you also considered passing the new rtx_* types by value or
reference instead of pointer? A long time ago I've quickly put together
a class 'rtxx' which was just a pointer wrapper for the rtx_def*
(basically the same as I proposed for edge_iterator).
I've converted the SH backend code to use it just to see what it would
look like. The conversion itself was pretty straight forward -- just
replace 'rtx' with 'rtxx'. Appropriate conversion
operators/constructors in 'class rtxx' made both interchangeable and
allowed co-existence of both and thus step-by-step conversion of the
code base.
Another advantage
Re: [PATCH] gcc: fix segfault from calling free on non-malloc'd area
On 06/23/14 14:09, Tobias Burnus wrote: This patch broke bootstrapping for me on x86-64-gnu-linux: /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `/usr/lib/crti.o' is incompatible with i386:x86-64 output If I revert the patch, it works for me. Reverted. Will have to look deeper. Paul, did you bootstrap with this patch on the trunk? jeff
Re: [patch] libstdc++/61532 fix make_signed failures
On 23/06/14 19:18 +0100, Jonathan Wakely wrote:
This fixes some more fallout from my make_signed changes and
improves the make_unsigned tests which were already fixed last month.
Tested x86_64-linux and powerpc64-linux, committed to trunk. I'll be
making the same changes on the 4.9 branch shortly.
This is the patch for the 4.9 branch, which combines a fix I forgot to
backport (r210517) with today's fix for PR61532.
Tested x86_64-linux, committed to the 4.9 branch.
commit a00bdfff755b28cb26bf44b87e6accf52bb8008e
Author: Jonathan Wakely
Date: Mon Jun 23 21:07:23 2014 +0100
PR libstdc++/61532
* testsuite/20_util/make_signed/requirements/typedefs-1.cc: Do not
apply the signed specifier to wchar_t.
* testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Do not
apply the unsigned specifier to wchar_t.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc:
Likewise.
diff --git a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc
index e3b84d6..5b094d9 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc
@@ -29,6 +29,7 @@ void test01()
using std::make_signed;
using std::is_same;
using std::is_signed;
+ using std::is_volatile;
// Positive tests.
typedef make_signed::type test2_type;
@@ -53,7 +54,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_signed::type test23_type;
- static_assert( is_same::value,
+ static_assert( is_signed::value
+ && is_volatile::value
+ && sizeof(test23_type) == sizeof(volatile wchar_t),
"make_signed" );
#endif
diff --git a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
index 654b375..3f47dba 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
@@ -30,6 +30,8 @@ void test01()
{
using std::make_signed;
using std::is_same;
+ using std::is_signed;
+ using std::is_volatile;
// Positive tests.
typedef make_signed::type test2_type;
@@ -50,7 +52,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_signed::type test23_type;
- static_assert(is_same::value, "");
+ static_assert(is_signed::value
+ && is_volatile::value
+ && sizeof(test23_type) == sizeof(volatile wchar_t), "");
#endif
typedef make_signed::type test24_type;
diff --git a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
index a893ede..de65504 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
@@ -29,6 +29,7 @@ void test01()
using std::make_unsigned;
using std::is_same;
using std::is_unsigned;
+ using std::is_volatile;
// Positive tests.
typedef make_unsigned::type test2_type;
@@ -49,7 +50,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_unsigned::type test23_type;
- static_assert(is_same::value, "");
+ static_assert(is_unsigned::value
+&& is_volatile::value
+&& sizeof(test23_type) == sizeof(volatile wchar_t), "");
#endif
// Chapter 48, chapter 20. Smallest rank such that new unsigned type
diff --git a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
index 637b0c7..7801dca 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
@@ -30,6 +30,8 @@ void test01()
{
using std::make_unsigned;
using std::is_same;
+ using std::is_unsigned;
+ using std::is_volatile;
// Positive tests.
typedef make_unsigned::type test2_type;
@@ -50,7 +52,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_unsigned::type test23_type;
- static_assert(is_same::value, "");
+ static_assert(is_unsigned::value
+&& is_volatile::value
+&& sizeof(test23_type) == sizeof(volatile wchar_t), "");
#endif
typedef make_unsigned::type test24_type;
Re: calloc = malloc + memset
On Mon, Jun 23, 2014 at 1:21 PM, Andi Kleen wrote: > On Mon, Jun 23, 2014 at 10:14:25PM +0200, Marc Glisse wrote: >> On Mon, 23 Jun 2014, Andi Kleen wrote: >> >> >I would prefer to not do it. >> >> For the sake of micro benchmarks? > > Yes benchmarks are important. But micro-benchmarks are not important. In fact this patch could improve some benchmarks as you no longer thrash your cache. So benchmarks are important but micro-benchmarks are not. Thanks, Andrew > > -Andi
Move DECL_VINDEX and DECL_SAVED_TREE into function_decl
Hi,
this patch makes DECL_VINDEX and DECL_SAVED_TREE to be FUNCTION_DECL only.
This needs to resolve overloading in C++ FE. For namespaces I added new fields
in lang specific annotation and for TEMPLATE_DECL I moved the overload to
UNIT_SIZE that is currently unused.
My incremental plan is to
1) Move DECL_RESULT/DECL_ARGUMENTS into FUNCTION_DECL only. This is easier
than
moving them all to struct function at once, but still need to resolve
(ab)use of those fields in the frontends.
2) Move DECL_SAVED_TREE to struct function (since it is a generic body).
This needs bit more changes on users of DECL_SAVED_TREE to be usre that we
have STRUCT_FUNCTION around and well.
3) Move DECL_RESULT/DECL_ARGUMENTS (if possible - so far I only got
C/C++/Fortran working with this change, but I think I am almost there.
Bootstrapped/regtested x86_64-linux, OK?
* class.c (check_methods, create_vtable_ptr, determine_key_method,
add_vcall_offset_vtbl_entries_1): Guard VINDEX checks by FUNCTION_DECL
check.
* cp-tree.h (lang_decl_ns): Add ns_using and ns_users.
(DECL_NAMESPACE_USING, DECL_NAMESPACE_USERS): Use lang_decl_ns.
(DECL_NAMESPACE_ASSOCIATIONS): Use DECL_INITIAL.
(DECL_TEMPLATE_INSTANTIATIONS): Use DECL_SIZE_UNIT.
* tree.c (find_decls_types_r): Do not check DECL_VINDEX for TYPE_DECL.
* tree.h (DECL_VINDEX, DECL_SAVED_TREE): Restrict to DECL_FUNCTION.
* tree-core.h (tree_decl_non_common): Move saved_tree and vindex...
(tree_function_decl): ... here.
* tree-streamer-out.c (write_ts_decl_non_common_tree_pointers): Move
streaming of vindex to ...
(write_ts_function_decl_tree_pointers): ... here.
* tree-streamer-in.c (lto_input_ts_decl_non_common_tree_pointers):
Do not stream DECL_VINDEX.
(lto_input_ts_function_decl_tree_pointers): Stream it here.
* lto.c (mentions_vars_p_decl_non_common): Move DECL_VINDEX check to ..
(mentions_vars_p_function): ... here.
(compare_tree_sccs_1): Update VINDEX checks.
(lto_fixup_prevailing_decls): Likewise.
Index: cp/class.c
===
--- cp/class.c (revision 211838)
+++ cp/class.c (working copy)
@@ -4356,11 +4356,11 @@ check_methods (tree t)
for (x = TYPE_METHODS (t); x; x = DECL_CHAIN (x))
{
check_for_override (x, t);
- if (DECL_PURE_VIRTUAL_P (x) && ! DECL_VINDEX (x))
+ if (DECL_PURE_VIRTUAL_P (x) && (TREE_CODE (x) != FUNCTION_DECL || !
DECL_VINDEX (x)))
error ("initializer specified for non-virtual method %q+D", x);
/* The name of the field is the original field name
Save this in auxiliary field for later overloading. */
- if (DECL_VINDEX (x))
+ if (TREE_CODE (x) == FUNCTION_DECL && DECL_VINDEX (x))
{
TYPE_POLYMORPHIC_P (t) = 1;
if (DECL_PURE_VIRTUAL_P (x))
@@ -5658,7 +5658,8 @@ create_vtable_ptr (tree t, tree* virtual
/* Collect the virtual functions declared in T. */
for (fn = TYPE_METHODS (t); fn; fn = DECL_CHAIN (fn))
-if (DECL_VINDEX (fn) && !DECL_MAYBE_IN_CHARGE_DESTRUCTOR_P (fn)
+if (TREE_CODE (fn) == FUNCTION_DECL
+ && DECL_VINDEX (fn) && !DECL_MAYBE_IN_CHARGE_DESTRUCTOR_P (fn)
&& TREE_CODE (DECL_VINDEX (fn)) != INTEGER_CST)
{
tree new_virtual = make_node (TREE_LIST);
@@ -6327,7 +6328,8 @@ determine_key_method (tree type)
this function until the end of the translation unit. */
for (method = TYPE_METHODS (type); method != NULL_TREE;
method = DECL_CHAIN (method))
-if (DECL_VINDEX (method) != NULL_TREE
+if (TREE_CODE (method) == FUNCTION_DECL
+ && DECL_VINDEX (method) != NULL_TREE
&& ! DECL_DECLARED_INLINE_P (method)
&& ! DECL_PURE_VIRTUAL_P (method))
{
@@ -9139,7 +9141,7 @@ add_vcall_offset_vtbl_entries_1 (tree bi
for (orig_fn = TYPE_METHODS (BINFO_TYPE (binfo));
orig_fn;
orig_fn = DECL_CHAIN (orig_fn))
-if (DECL_VINDEX (orig_fn))
+if (TREE_CODE (orig_fn) == FUNCTION_DECL && DECL_VINDEX (orig_fn))
add_vcall_offset (orig_fn, binfo, vid);
}
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 211838)
+++ cp/cp-tree.h(working copy)
@@ -2048,6 +2048,8 @@ struct GTY(()) lang_decl_fn {
struct GTY(()) lang_decl_ns {
struct lang_decl_base base;
cp_binding_level *level;
+ tree ns_using;
+ tree ns_users;
};
/* DECL_LANG_SPECIFIC for parameters. */
@@ -2580,16 +2582,16 @@ struct GTY(()) lang_decl {
/* For a NAMESPACE_DECL: the list of using namespace directives
The PURPOSE is the used namespace, the value is the namespace
that is the common ancestor. */
-#define DECL_NAMESPACE_USING(NODE) DECL_VINDEX (NAMESPACE_DECL_CHECK (NODE))
+#define DECL_NAMESPACE_USING(NODE) (LANG_DECL_NS_CHECK (NODE)->ns_using)
/* In a NAMESPACE_DECL,
Re: calloc = malloc + memset
On Mon, Jun 23, 2014 at 10:14:25PM +0200, Marc Glisse wrote: > On Mon, 23 Jun 2014, Andi Kleen wrote: > > >I would prefer to not do it. > > For the sake of micro benchmarks? Yes benchmarks are important. -Andi
Re: [fortran, patch] IEEE intrinsic modules (ping)
On Mon, Jun 23, 2014 at 12:23:39PM -0700, Steve Kargl wrote: > I meant to look this over this weekend. Unfortnately, baseball > and soccer (both daughter and USA vs Portugal) got in the way. > First issue, > > cd gcc4x > patch < ieee_withregenerated_2.diff > ... > -- > |Index: configure.host > |=== > |--- configure.host (revision 211688) > |+++ configure.host (working copy) > -- > File to patch: libgfortran/configure.host > Patching file libgfortran/configure.host using Plan A... > patch: malformed patch at line 939: then > > As I don't have a top-level configure.host, I guessed that > libgfortran/configure.host was the right file. > Ignoring this chunk, one doesn't get very far with building gcc. :( if [ xinfo = xinfo ]; then \ rm -f doc/gfortran.info-*; \ makeinfo --split-size=500 --split-size=500 -I ../../gcc4x/gcc/doc/include -I ../../gcc4x/gcc/fortran \ -o doc/gfortran.info ../../gcc4x/gcc/fortran/gfortran.texi; \ else true; fi ../../gcc4x/gcc/fortran//intrinsic.texi:13399: Prev reference to nonexistent node `IEEE_EXCEPTIONS' (perhaps incorrect sectioning?). ../../gcc4x/gcc/fortran//intrinsic.texi:13372: Next reference to nonexistent node `IEEE_ARITHMETIC' (perhaps incorrect sectioning?). ../../gcc4x/gcc/fortran//intrinsic.texi:13372: Prev reference to nonexistent node `and IEEE_FEATURES' (perhaps incorrect sectioning?). ../../gcc4x/gcc/fortran//intrinsic.texi:13372: `IEEE modules: IEEE_EXCEPTIONS' has no Up field (perhaps incorrect sectioning?). ../../gcc4x/gcc/fortran//intrinsic.texi:13275: Next reference to nonexistent node `IEEE_EXCEPTIONS' (perhaps incorrect sectioning?). ../../gcc4x/gcc/fortran//intrinsic.texi:13158: Menu reference to nonexistent node `IEEE_EXCEPTIONS' (perhaps incorrect sectioning?). ../../gcc4x/gcc/fortran//intrinsic.texi:13372: warning: unreferenced node `IEEE modules: IEEE_EXCEPTIONS'. makeinfo: Removing output file `doc/gfortran.info' due to errors; use --force to preserve. gmake[2]: *** [doc/gfortran.info] Error 1 gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj4x/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x' gmake: *** [all] Error 2 laptop-kargl:kargl[239] pwd -- Steve
Re: calloc = malloc + memset
On Mon, 23 Jun 2014, Andi Kleen wrote: I would prefer to not do it. For the sake of micro benchmarks? I'm not sure it has a lot of benefit. It has a non-zero benefit. If you want to keep it please make sure there is an easy way to turn it off. Any of these flags works: -fdisable-tree-strlen -fno-builtin-malloc -fno-builtin-memset (assuming you wrote 'memset' explicitly in your code) -fno-builtin -ffreestanding -O1 -Os In the code, you can hide that the pointer passed to memset is the one returned by malloc by storing it in a volatile variable, or any other trick to hide from the compiler that we are doing memset(malloc(n),0,n). -- Marc Glisse
Re: [PATCH] gcc: fix segfault from calling free on non-malloc'd area
This patch broke bootstrapping for me on x86-64-gnu-linux:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
i386 architecture of input file `/usr/lib/crti.o' is incompatible with
i386:x86-64 output
If I revert the patch, it works for me.
Tobias
Paul Gortmaker wrote:
We see the following on a 32bit gcc installed on 64 bit host:
Reading symbols from ./i586-pokymllib32-linux-gcc...done.
(gdb) run
Starting program:
x86-pokymllib32-linux/lib32-gcc/4.9.0-r0/image/usr/bin/i586-pokymllib32-linux-gcc
Program received signal SIGSEGV, Segmentation fault.
0xf7e957e0 in free () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt
#0 0xf7e957e0 in free () from /lib/i386-linux-gnu/libc.so.6
#1 0x0804b73c in set_multilib_dir () at gcc-4.9.0/gcc/gcc.c:7827
#2 main (argc=1, argv=0xd504) at gcc-4.9.0/gcc/gcc.c:6688
(gdb)
The problem arises because the check on whether we are using
the internal string "." or an allocated one is reversed.
We should be calling free() when the string is not equal to
the internal "." string.
Signed-off-by: Paul Gortmaker
---
[Found and fixed on gcc-4.9.0 but applies to git/master too]
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6870a840e1b7..a580975a7057 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -7822,7 +7822,7 @@ set_multilib_dir (void)
}
if (multilib_dir == NULL && multilib_os_dir != NULL
- && strcmp (multilib_os_dir, ".") == 0)
+ && strcmp (multilib_os_dir, ".") != 0)
{
free (CONST_CAST (char *, multilib_os_dir));
multilib_os_dir = NULL;
RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
Hi, On Mon, 23 Jun 2014 16:22:13, Eric Botcazou wrote: > >> I noticed that several testcases in the GMP-4.3.2 test suite are failing now >> which did not happen with GCC 4.9.0. I debugged the first one, >> mpz/convert, and found the file mpn/generic/get_str.c was miscompiled. >> >> mpn/get_str.c.132t.dse2: >> pretmp_183 = (sizetype) chars_per_limb_80; >> pretmp_184 = -pretmp_183; >> _23 = chars_per_limb_80 + 4294967295; >> _68 = (sizetype) _23; >> _28 = _68 + pretmp_184; >> >> mpn/get_str.c.133t.forwprop4: >> _28 = 4294967295; >> >> >> That is wrong, because chars_per_limb is unsigned, and it is not zero. >> So the right result should be -1. This makes the loop termination in that >> function fail. > > Can't we compute the right result in this case? 4294967295 is almost -1. > Only if we could somehow rule out that chars_per_limb can be zero. Then we know for sure that unsigned overflow must happen, and the only possible result would be -1. But at this time, both -1 and 4294967295 are possible. What happened before, is this: int i; unsigned int chars_per_limb; i_79 = __gmpn_bases[base_30(D)].chars_per_limb; chars_per_limb_80 = (unsigned int) i_79; so how can we know that chars_per_limb is> 0, here? In this example probably not, only maybe if someone helps us and adds an assertion (chars_per_limb> 0); then we could of course exploit that information Bernd. >> The attached patch fixes these regressions, and because the reasoning >> depends on the TYPE_OVERFLOW_UNDEFINED attribute, a strict overflow warning >> has to be emitted here, at least for widening conversions. > > Saturating, floating-point and fixed-point types are already excluded here, > see the beginning of the function. > > -- > Eric Botcazou
Re: calloc = malloc + memset
On Mon, Jun 23, 2014 at 09:00:02PM +0200, Marc Glisse wrote: > On Mon, 23 Jun 2014, Andi Kleen wrote: > > >FWIW i believe the transformation will break a large variety of micro > >benchmarks. > > > >calloc internally knows that memory fresh from the OS is zeroed. > >But the memory may not be faulted in yet. > > > >memset always faults in the memory. > > > >So if you have some test like > > > > buf = malloc(...) > > memset(buf, ...) > > start = get_time(); > > ... do something with buf > > end = get_time() > > > >Now the times will be completely off because the measured times includes > >the page faults. > > Good point. I guess working around compiler optimizations is part of > the game for micro benchmarks, and their authors would be > disappointed if the compiler didn't mess it up regularly in new and > entertaining ways ;-) I would prefer to not do it. I'm not sure it has a lot of benefit. If you want to keep it please make sure there is an easy way to turn it off. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [fortran, patch] IEEE intrinsic modules (ping)
I meant to look this over this weekend. Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue,
cd gcc4x
patch < ieee_withregenerated_2.diff
...
--
|Index: configure.host
|===
|--- configure.host (revision 211688)
|+++ configure.host (working copy)
--
File to patch: libgfortran/configure.host
Patching file libgfortran/configure.host using Plan A...
patch: malformed patch at line 939: then
As I don't have a top-level configure.host, I guessed that
libgfortran/configure.host was the right file.
All other parts of the patch applied cleanly.
--
steve
On Mon, Jun 23, 2014 at 10:39:30AM +0200, FX wrote:
> ping*2
>
> I understand the size of the patch can be somewhat off-putting, but given its
> nature it?s rather hard to split it further. Moreover, apart from the
> OS-specific bits on the library side, it?s not very difficult. If it is hard
> for anyone to find time to review it in full, may I suggest that it be given
> a lighter review before commit? then while it gets some real exposure from
> users/testers, further review can be performed.
>
> FX
>
>
>
>
> > ping for the IEEE patch.
> >
> > Since last time, I incorporated Uros? comments on the
> > libgfortran/config/fpu-387.h part, and add some documentation to the manual
> > (list of supported targets, and required compilation flags for full IEE
> > support).
> >
> > OK to commit?
> > I?d really like to get this into trunk, so it can get some exposure to iron
> > it out?
> >
> > FX
> >
> >
> >
> >> Hi,
> >>
> >> Last November, I worked on a patch to add the IEEE intrinsic modules to
> >> gfortran (thread starting at
> >> https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html
> >> ). After a round of review, I continued working on it, then didn?t have
> >> time, then development was frozen? Now, I found some time to get back to
> >> it, and here?s a more complete patch. I?ve bootstrapped it and regtested
> >> on:
> >>
> >> ? x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
> >> ? x86_64-linux with tweaked configure.host to force it to use glibc
> >> functions in config/fpu-glibc.h (both 32-bit and 64-bit)
> >>
> >> The current state of the patch: as far as I can tell, nearly full support.
> >> In particular, since my last patch, I?ve added ?saving/restoring FPU state
> >> on procedure entry/exit, when IEEE is used?. This is done in trans-decl.c,
> >> by wrapping each affected function body between calls to the library:
> >>
> >> try
> >>{
> >> _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
> >> /* procedure body goes here */
> >>}
> >> finally
> >>{
> >> _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
> >>}
> >>
> >>
> >>
> >> What?s missing:
> >>
> >> 0. 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). That?s explicitly allowed by the
> >> standard, so it?s not actually ?missing". We can improve on this in the
> >> future, if people can help.
> >>
> >> 1. Documenting the flags necessary for full IEEE compatibility: it seems
> >> that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans? is
> >> good, but I?ll have to check that with the floating-point middle-end
> >> experts. That?s next on my list: documenting our support, and interaction
> >> with compilation flags.
> >>
> >> 2. Your review of the patch!
> >>
> >>
> >> I really think getting IEEE support early in stage 1 will benefit the
> >> compiler, through good testing before release. I?d like to get this in,
> >> but I don?t intend to disappear afterwards? though I?m not stepping back
> >> ?full time? into the team, I will be there to fix IEEE bugs and issues.
> >>
> >> OK to commit?
> >>
> >> FX
>
>
--
Steve
Re: [PATCH] gcc: fix segfault from calling free on non-malloc'd area
On 06/23/14 08:42, Paul Gortmaker wrote:
We see the following on a 32bit gcc installed on 64 bit host:
Reading symbols from ./i586-pokymllib32-linux-gcc...done.
(gdb) run
Starting program:
x86-pokymllib32-linux/lib32-gcc/4.9.0-r0/image/usr/bin/i586-pokymllib32-linux-gcc
Program received signal SIGSEGV, Segmentation fault.
0xf7e957e0 in free () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt
#0 0xf7e957e0 in free () from /lib/i386-linux-gnu/libc.so.6
#1 0x0804b73c in set_multilib_dir () at gcc-4.9.0/gcc/gcc.c:7827
#2 main (argc=1, argv=0xd504) at gcc-4.9.0/gcc/gcc.c:6688
(gdb)
The problem arises because the check on whether we are using
the internal string "." or an allocated one is reversed.
We should be calling free() when the string is not equal to
the internal "." string.
Signed-off-by: Paul Gortmaker
---
[Found and fixed on gcc-4.9.0 but applies to git/master too]
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6870a840e1b7..a580975a7057 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -7822,7 +7822,7 @@ set_multilib_dir (void)
}
if (multilib_dir == NULL && multilib_os_dir != NULL
- && strcmp (multilib_os_dir, ".") == 0)
+ && strcmp (multilib_os_dir, ".") != 0)
{
free (CONST_CAST (char *, multilib_os_dir));
multilib_os_dir = NULL;
Thanks. Installed on the trunk.
jeff
Re: [doc] Remove duplicate -Wmaybe-uninitialized
On 06/22/14 11:30, Marc Glisse wrote: Hello, a trivial patch to remove a duplicated option, you can see the second one 4 lines below in the patch. (the mixed use of single or double spaces in this list is strange) This was included in the bootstrap of another patch. 2014-06-23 Marc Glisse * doc/invoke.texi (Warning Options): Remove duplicated -Wmaybe-uninitialized. Probably falls under the obvious rule. Regardless, this is OK. Thanks, Jeff
Re: [PATCH 5/5] add libcc1
On 06/20/14 09:33, Tom Tromey wrote: "Trevor" == Trevor Saunders writes: Trevor> I'm curious, what is the reason you choose not to write this in C++11 or Trevor> later? Its distributed with gcc, so the only case where you aren't Trevor> building with the in tree compiler and libraries is when your cross Trevor> compiling gcc, and it doesn't seem particularly important to support Trevor> building the plugin or library in that configuration. So istm you could Trevor> go all the way and assume you are being built with trunk gcc and Trevor> libraries. The plugin has to be ABI compatible with GCC itself, and my understanding was that C++11 and "however GCC is built" are not necessarily compatible. Presumably you're referring to the upcoming abi breakage for C++ pair & list. There's ways around that with the ABI tagging we're using, but at least for now, the safe thing to do for something that must be ABI compatibile with GCC itself is to stick with C++03 mode. Switching to C++11 would be an improvement -- variadic templates would simplify the RPC code (with a complicated caveat). So if it is possible I am interested. There'll probably be a day when we can bless C++11 for building GCC itself and any associated plugins, but we're not at that point right now. Trevor> So can we add C++ stuff to libiberty and allow building Trevor> libiberty without it for binutils / gdb, or can we do something Trevor> else to avoid this kind of stuff? One way would be to just make a new top-level directory for a new library. Seems like the easiest solution, at least for now. Thanks. I changed it to do a NULL check. It's nothrow because nothing in libcc1 or gdb is prepared for a C++ exception. While I like exceptions (gdb uses its own longjmp-based exception system extensively), my understanding is that they aren't currently used in gcc. Right. Or if we're using them in GCC, any such use is well buried in non-critical , not widely known & marginally, if at all, tested code. Jeff
Re: [PATCH] Fix 61565 -- cmpelim vs non-call exceptions
On 06/23/2014 08:55 AM, Ramana Radhakrishnan wrote: > Agreed, this is why cmpelim looks interesting for Thumb1. (We may need another > hook or something to disable it in configurations we don't need it in, but you > know ... ) Yeah. Feel free to change targetm.flags_regnum from a variable to a function, when you get around to it. > Except that IT instructions aren't in Thumb1 or indeed v6-m :(. Ah, yes, of course. r~
Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)
On Mon, 2014-06-09 at 20:32 +0100, Richard Sandiford wrote:
> Steven Bosscher writes:
> > On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
> >> The two parts of the loop condition are really handling two different
> >> kinds of block: ones like entry and exit that are completely empty
> >> and normal ones that have at least a block note. There's no real
> >> need to check for null INSNs in normal blocks.
> >
> > Block notes should go away some day, they're just remains of a time
> > when there was no actual CFG in the compiler.
>
> Yeah. I suppose when that happens empty blocks would look just like
> entry and exit as far as these iterators go.
>
> >> Also, refetching NEXT_INSN (BB_END (BB)) for each iteration can be
> >> expensive.
> >> If we're prepared to say that the loop body can't insert instructions
> >> for another block immediately after BB_END,
> >
> > This can happen with "block_label()" if e.g. a new jump is inserted
> > for one reason or another. Not very likely for passes working in
> > cfglayout mode, but post-RA there may be places that need this
> > (splitters, peepholes, machine dependent reorgs, etc.).
> >
> > So even if we're prepared to say what you suggest, I don't think you
> > can easily enforce it.
>
> Probably true. But if we want to allow insertions after BB_END,
> we need to make FOR_BB_INSNS_SAFE handle that for INSN == BB_END too.
>
> The alternative definition:
>
> for (rtx INSN = BB_HEAD (BB), INSN##_cond_ = INSN, INSN##_next_;\
>INSN##_cond_ \
>&& (INSN##_next_ = NEXT_INSN (INSN), \
>INSN##_cond_ = BB_END (BB),\
>true); \
>INSN##_cond_ = (INSN == INSN##_cond_ ? NULL_RTX : (rtx) 1),\
>INSN = INSN##_next_)
>
> works too. It isn't quite as fast, but obviously correctness comes first.
>
> >> It's easier to change these macros if they define the INSN variables
> >> themselves.
> >
> > If you're going to hack these iterators anyway (much appreciated BTW),
> > I suggest to make them similar to the gsi, loop, edge, and bitmap
> > iterators: A new "insn_iterator" structure to hold the variables and
> > static inline functions wrapped in the macros. This will also be
> > helpful if (when) we ever manage to make the type for an insn a
> > non-rtx...
>
> Well, with this and...
>
> >> +/* For iterating over insns in a basic block. The iterator allows the
> >> loop
> >> + body to delete INSN. It also ignores any instructions that the body
> >> + inserts between INSN and the following instruction. */
> >> +#define FOR_BB_INSNS(BB, INSN) \
> >> + for (rtx INSN = BB_HEAD (BB), INSN##_cond_ = INSN, INSN##_next_, \
> >> + INSN##_end_ = INSN ? NEXT_INSN (BB_END (BB)) : NULL_RTX; \
> >> + INSN##_cond_ && (INSN##_next_ = NEXT_INSN (INSN), true); \
> >> + INSN = INSN##_next_,\
> >> + INSN##_cond_ = (INSN != INSN##_end_ ? (rtx) 1 : NULL_RTX))
> >
> > This just makes my eyes hurt...
> >
> >
> > What about cases where a FOR_BB_INSNS is terminated before reaching
> > the end of a basic block, and you need to know at what insn you
> > stopped? Up to now, you could do:
> >
> > rtx insn; basic_block bb;
> > FOR_BB_INSNS (bb, insn)
> > {
> > ... // do stuff
> > if (something) break;
> > }
> > do_something_with (insn);
> >
> > Looks like this is no longer possible with the implementation of
> > FOR_BB_INSNS of your patch.
>
> ...this I suppose it depends where we want to go with these iterators.
> I'm hoping eventually we'll move to C++11, where the natural way of
> writing the loop would be:
>
> for (rtx insn : bb->insns ())
>
> (Or "auto *" instead of "rtx" if you prefer.)
>
> And I think the idiom of having the FOR_* macro define the iterator
> variable is much closer to that than:
>
> rtx insn;
> FOR_BB_INSNS (iter, bb, insn)
>
> would be.
>
> It's true that you can't leave "insn" with a signficant value after
> the loop, but no current code wants to do that. Personally I like
> the fact that loops that do want to set a final value have to make
> that explicit. When the vast majority (currently all) instances of:
>
> FOR_BB_INSNS (bb, insn)
>
> treat "insn" as local to the loop, it's helpful when the exceptions
> are obvious.
>
> I think if anything the patch would make it easier to change the
> type of insns to something other than rtx.
(sorry for the belated response; I was on vacation).
FWIW I'm actually working on such a change, or, at least, to make
instructions be a subclass of rtx_def; presumably this should make it
easier to make it an entirely separate type, if that's desirable.
Executive summary is that it's still a work in progress, and I'm going
to be giving a talk about it at Cauldron next
Re: calloc = malloc + memset
On Mon, 23 Jun 2014, Andi Kleen wrote: FWIW i believe the transformation will break a large variety of micro benchmarks. calloc internally knows that memory fresh from the OS is zeroed. But the memory may not be faulted in yet. memset always faults in the memory. So if you have some test like buf = malloc(...) memset(buf, ...) start = get_time(); ... do something with buf end = get_time() Now the times will be completely off because the measured times includes the page faults. Good point. I guess working around compiler optimizations is part of the game for micro benchmarks, and their authors would be disappointed if the compiler didn't mess it up regularly in new and entertaining ways ;-) -- Marc Glisse
Re: [PATCH] Only transform rotate to rotatert and v.v. if target has both
On 06/22/14 14:58, Segher Boessenkool wrote: Many targets do not have both rotate and rotatert. Of the 47 targets in the tree, 17 have both, 9 have only rotate, 2 have only rotatert, and 19 have neither (this is based on "grep -wil" so it can be slightly off). rs6000 has only rotate, and mips has only rotatert. For such targets simplifying rotate to rotatert and vice versa is not simplifying things at all. rs6000 has already way too many rotate patterns (some days it seems like two thousand, but it is somewhat less in reality still); I would prefer not to double that again. So, this patch makes genrecog define HAVE_rotate and HAVE_rotatert if those RTL codes are mentioned anywhere in the machine description, and then does the transformation in simplify-rtx.c only if both these flags are set. Bootstrapped and tested on powerpc64-linux. Okay to apply? Segher 2014-06-22 Segher Boessenkool gcc/ * genconfig.c (have_rotate_flag, have_rotatert_flag): New variables. (walk_insn_part) : New cases. (main): Conditionally write HAVE_rotate c.q. HAVE_rotatert. * simplify-rtx.c (simplify_binary_operation_1) : Only do the transformation if both HAVE_rotate and HAVE_rotatert. OK. It would be useful if you could add one or more tests to the testsuite to confirm proper behaviour when only one of ROTATE/ROTATERT is defined. jeff
Re: calloc = malloc + memset
On Mon, Jun 23, 2014 at 11:17 AM, Andi Kleen wrote: > Marc Glisse writes: > >> Hello, >> >> this is a stage 1 patch, and I'll ping it then, but if you have >> comments now... > > FWIW i believe the transformation will break a large variety of micro > benchmarks. > > calloc internally knows that memory fresh from the OS is zeroed. > But the memory may not be faulted in yet. > > memset always faults in the memory. > > So if you have some test like > >buf = malloc(...) >memset(buf, ...) >start = get_time(); >... do something with buf >end = get_time() > > Now the times will be completely off because the measured times includes > the page faults. Easy way for these benchmarks to get around this. volatile char *vbuf = (char*)buf; for(i=0;i > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only
Re: [PATCH] Fix for invalid sanitization of trailing byte in __builtin_strlen
On 06/23/14 10:55, Maxim Ostapenko wrote: Hi, when I applied this patch (r211846), I made a little mistake in output test patterns. This patch fixes this. Tested on x86_64-unknown-linux-gnu. Ok to commit? OK. jeff
[Patch, Fortran] Fix a coarray ICE on invalid code
First, the following coarray patches are still awaiting review:
* https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01662.html
* https://gcc.gnu.org/ml/fortran/2014-06/msg00183.html
The attached patch fixes an ICE on invalid code with polymorphic coarrays.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
gcc/fortran/
2014-06-21 Tobias Burnus
* interface.c (check_intents): Fix diagnostic with
coindexed coarrays.
gcc/testsuite/
2014-06-21 Tobias Burnus
* gfortran.dg/coarray_33.f90: New.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 67548c0..b210d18 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3170,17 +3170,26 @@ check_intents (gfc_formal_arglist *f, gfc_actual_arglist *a)
for (;; f = f->next, a = a->next)
{
+ gfc_expr *expr;
+
if (f == NULL && a == NULL)
break;
if (f == NULL || a == NULL)
gfc_internal_error ("check_intents(): List mismatch");
- if (a->expr == NULL || a->expr->expr_type != EXPR_VARIABLE)
+ if (a->expr && a->expr->expr_type == EXPR_FUNCTION
+ && a->expr->value.function.isym
+ && a->expr->value.function.isym->id == GFC_ISYM_CAF_GET)
+ expr = a->expr->value.function.actual->expr;
+ else
+ expr = a->expr;
+
+ if (expr == NULL || expr->expr_type != EXPR_VARIABLE)
continue;
f_intent = f->sym->attr.intent;
- if (gfc_pure (NULL) && gfc_impure_variable (a->expr->symtree->n.sym))
+ if (gfc_pure (NULL) && gfc_impure_variable (expr->symtree->n.sym))
{
if ((f->sym->ts.type == BT_CLASS && f->sym->attr.class_ok
&& CLASS_DATA (f->sym)->attr.class_pointer)
@@ -3188,19 +3197,19 @@ check_intents (gfc_formal_arglist *f, gfc_actual_arglist *a)
{
gfc_error ("Procedure argument at %L is local to a PURE "
"procedure and has the POINTER attribute",
- &a->expr->where);
+ &expr->where);
return false;
}
}
/* Fortran 2008, C1283. */
- if (gfc_pure (NULL) && gfc_is_coindexed (a->expr))
+ if (gfc_pure (NULL) && gfc_is_coindexed (expr))
{
if (f_intent == INTENT_INOUT || f_intent == INTENT_OUT)
{
gfc_error ("Coindexed actual argument at %L in PURE procedure "
"is passed to an INTENT(%s) argument",
- &a->expr->where, gfc_intent_string (f_intent));
+ &expr->where, gfc_intent_string (f_intent));
return false;
}
@@ -3210,18 +3219,18 @@ check_intents (gfc_formal_arglist *f, gfc_actual_arglist *a)
{
gfc_error ("Coindexed actual argument at %L in PURE procedure "
"is passed to a POINTER dummy argument",
- &a->expr->where);
+ &expr->where);
return false;
}
}
/* F2008, Section 12.5.2.4. */
- if (a->expr->ts.type == BT_CLASS && f->sym->ts.type == BT_CLASS
- && gfc_is_coindexed (a->expr))
+ if (expr->ts.type == BT_CLASS && f->sym->ts.type == BT_CLASS
+ && gfc_is_coindexed (expr))
{
gfc_error ("Coindexed polymorphic actual argument at %L is passed "
"polymorphic dummy argument '%s'",
- &a->expr->where, f->sym->name);
+ &expr->where, f->sym->name);
return false;
}
}
diff --git a/gcc/testsuite/gfortran.dg/coarray_33.f90 b/gcc/testsuite/gfortran.dg/coarray_33.f90
new file mode 100644
index 000..9bd87f9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_33.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+type t
+ integer :: x
+end type t
+
+class(t), allocatable :: a[:]
+allocate(t :: a[*])
+a%x = this_image()
+
+call foo(a[i]) ! { dg-error "Coindexed polymorphic actual argument at .1. is passed polymorphic dummy argument" }
+contains
+subroutine foo(y)
+ class(t) :: y
+ print *, y%x
+end subroutine foo
+end
Re: [PATCH] Don't segv on __atomic_store (PR c/61553)
On Mon, Jun 23, 2014 at 04:39:55PM +0200, Marek Polacek wrote:
> --- gcc/testsuite/c-c++-common/pr61553.c
> +++ gcc/testsuite/c-c++-common/pr61553.c
> @@ -0,0 +1,8 @@
> +/* PR c/61553 */
> +/* { dg-do compile } */
> +
> +void
> +foo (char *s)
> +{
> + __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST);
Oops, dg-error disappeared from the final patch. I'm fixing it with
the following.
2014-06-23 Marek Polacek
PR c/61553
* c-c++-common/pr61553.c (foo): Add dg-error.
diff --git gcc/testsuite/c-c++-common/pr61553.c
gcc/testsuite/c-c++-common/pr61553.c
index fa97e94..8a3b699 100644
--- gcc/testsuite/c-c++-common/pr61553.c
+++ gcc/testsuite/c-c++-common/pr61553.c
@@ -4,5 +4,5 @@
void
foo (char *s)
{
- __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST);
+ __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST); /* { dg-error "size
mismatch" } */
}
Marek
Re: calloc = malloc + memset
Marc Glisse writes: > Hello, > > this is a stage 1 patch, and I'll ping it then, but if you have > comments now... FWIW i believe the transformation will break a large variety of micro benchmarks. calloc internally knows that memory fresh from the OS is zeroed. But the memory may not be faulted in yet. memset always faults in the memory. So if you have some test like buf = malloc(...) memset(buf, ...) start = get_time(); ... do something with buf end = get_time() Now the times will be completely off because the measured times includes the page faults. -Andi -- a...@linux.intel.com -- Speaking for myself only
[patch] libstdc++/61532 fix make_signed failures
This fixes some more fallout from my make_signed changes and
improves the make_unsigned tests which were already fixed last month.
Tested x86_64-linux and powerpc64-linux, committed to trunk. I'll be
making the same changes on the 4.9 branch shortly.
commit 43db1e59326da5af1f75a86e37e51f015989b738
Author: Jonathan Wakely
Date: Mon Jun 23 18:30:08 2014 +0100
PR libstdc++/61532
* testsuite/20_util/make_signed/requirements/typedefs-1.cc: Do not
apply the signed specifier to wchar_t.
* testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Check
cv-qualifier and size.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc:
Likewise.
diff --git a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc
index e3b84d6..5b094d9 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc
@@ -29,6 +29,7 @@ void test01()
using std::make_signed;
using std::is_same;
using std::is_signed;
+ using std::is_volatile;
// Positive tests.
typedef make_signed::type test2_type;
@@ -53,7 +54,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_signed::type test23_type;
- static_assert( is_same::value,
+ static_assert( is_signed::value
+ && is_volatile::value
+ && sizeof(test23_type) == sizeof(volatile wchar_t),
"make_signed" );
#endif
diff --git a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
index 654b375..3f47dba 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
@@ -30,6 +30,8 @@ void test01()
{
using std::make_signed;
using std::is_same;
+ using std::is_signed;
+ using std::is_volatile;
// Positive tests.
typedef make_signed::type test2_type;
@@ -50,7 +52,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_signed::type test23_type;
- static_assert(is_same::value, "");
+ static_assert(is_signed::value
+ && is_volatile::value
+ && sizeof(test23_type) == sizeof(volatile wchar_t), "");
#endif
typedef make_signed::type test24_type;
diff --git a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
index d9f13aa..de65504 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
@@ -29,6 +29,7 @@ void test01()
using std::make_unsigned;
using std::is_same;
using std::is_unsigned;
+ using std::is_volatile;
// Positive tests.
typedef make_unsigned::type test2_type;
@@ -49,7 +50,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_unsigned::type test23_type;
- static_assert(is_unsigned::value, "");
+ static_assert(is_unsigned::value
+&& is_volatile::value
+&& sizeof(test23_type) == sizeof(volatile wchar_t), "");
#endif
// Chapter 48, chapter 20. Smallest rank such that new unsigned type
diff --git a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
index 807e2bf..7801dca 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
@@ -31,6 +31,7 @@ void test01()
using std::make_unsigned;
using std::is_same;
using std::is_unsigned;
+ using std::is_volatile;
// Positive tests.
typedef make_unsigned::type test2_type;
@@ -51,7 +52,9 @@ void test01()
#ifdef _GLIBCXX_USE_WCHAR_T
typedef make_unsigned::type test23_type;
- static_assert(is_unsigned::value, "");
+ static_assert(is_unsigned::value
+&& is_volatile::value
+&& sizeof(test23_type) == sizeof(volatile wchar_t), "");
#endif
typedef make_unsigned::type test24_type;
Re: [PATCH][libsanitizer] Cherry-pick r211008 [Was: Re: libsanitizer merge from upstream r208536]
On Mon, Jun 23, 2014 at 07:23:09PM +0200, Paolo Carlini wrote:
> /
> 2014-06-23 Paolo Carlini
>
> * sanitizer_common/sanitizer_common_interceptors.inc:
> Cherry pick upstream r211008.
Sure, thanks.
> Index: sanitizer_common/sanitizer_common_interceptors.inc
> ===
> --- sanitizer_common/sanitizer_common_interceptors.inc(revision
> 211905)
> +++ sanitizer_common/sanitizer_common_interceptors.inc(working copy)
> @@ -1796,7 +1796,7 @@ INTERCEPTOR(int, getsockopt, int sockfd, int level
> INTERCEPTOR(int, accept, int fd, void *addr, unsigned *addrlen) {
>void *ctx;
>COMMON_INTERCEPTOR_ENTER(ctx, accept, fd, addr, addrlen);
> - unsigned addrlen0;
> + unsigned addrlen0 = 0;
>if (addrlen) {
> COMMON_INTERCEPTOR_READ_RANGE(ctx, addrlen, sizeof(*addrlen));
> addrlen0 = *addrlen;
> @@ -1818,7 +1818,7 @@ INTERCEPTOR(int, accept, int fd, void *addr, unsig
> INTERCEPTOR(int, accept4, int fd, void *addr, unsigned *addrlen, int f) {
>void *ctx;
>COMMON_INTERCEPTOR_ENTER(ctx, accept4, fd, addr, addrlen, f);
> - unsigned addrlen0;
> + unsigned addrlen0 = 0;
>if (addrlen) {
> COMMON_INTERCEPTOR_READ_RANGE(ctx, addrlen, sizeof(*addrlen));
> addrlen0 = *addrlen;
Jakub
RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
Hi, On Mon, 23 Jun 2014 19:12:47, Richard Biener wrote: > > On Mon, Jun 23, 2014 at 4:28 PM, Bernd Edlinger > wrote: >> Hi, >> >> On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: >>> >>> On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger >>> wrote: Hi, I noticed that several testcases in the GMP-4.3.2 test suite are failing now which did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and found the file mpn/generic/get_str.c was miscompiled. mpn/get_str.c.132t.dse2: pretmp_183 = (sizetype) chars_per_limb_80; pretmp_184 = -pretmp_183; _23 = chars_per_limb_80 + 4294967295; _68 = (sizetype) _23; _28 = _68 + pretmp_184; mpn/get_str.c.133t.forwprop4: _28 = 4294967295; That is wrong, because chars_per_limb is unsigned, and it is not zero. So the right result should be -1. This makes the loop termination in that function fail. The reason for this is in this check-in: r210807 | ebotcazou | 2014-05-22 16:32:56 +0200 (Thu, 22 May 2014) | 3 lines * tree-ssa-forwprop.c (associate_plusminus): Extend (T)(P + A) - (T)P -> (T)A transformation to integer types. Because it implicitly assumes that integer overflow is not allowed with all types, including unsigned int. >>> >>> Hmm? But the transform is correct if overflow wraps. And it's correct if >>> overflow is undefined as well, as (T)A is always well-defined >>> (implementation >>> defined) if it is a truncation. >>> >> >> we have no problem when the cast from (P + A) to T is a truncation, except if >> the add operation P + A is saturating. > > Ah, we indeed look at an inner operation. > >>> So we match the above an try to transform it to (T)P + (T)A - (T)P. That's >>> wrong if the conversion is extending I think. >>> >> >> Yes, in a way. But OTOH, Eric's test case opt37.adb, fails if we simply punt >> here. >> >> Fortunately, with opt37.adb, P and A are signed 32-bit integers, and T is >> size_t (64 bit) >> and because the overflow of P + A causes undefined behaviour, we can assume >> that >> P + A _did_ not overflow, and therefore the transformation (T)(P + A) == >> (T)P + (T)A >> is correct (but needs a strict overflow warning), and we still can use the >> pattern >> (T)P + (T)A - (T)P -> (T)A in this case. > > Ok, though that is then the only transform that uses strict-overflow > semantics. > >> But we cannot use this transformation, as the attached test case demonstrates >> when P + A is done in unsigned integers, because the result of the addition >> is >> different if it is done in unsigned int with allowed overflow, or in long >> without >> overflow. >> >>> Richard. >>> >>> The attached patch fixes these regressions, and because the reasoning depends on the TYPE_OVERFLOW_UNDEFINED attribute, a strict overflow warning has to be emitted here, at least for widening conversions. Boot-strapped and regression-tested on x86_64-linux-gnu with all languages, including Ada. OK for trunk? >>> >>> + if (!TYPE_SATURATING (TREE_TYPE (a)) >>> >>> this is already tested at the very beginning of the function. >>> >> >> We have done TYPE_SATURATING (TREE_TYPE (rhs1)) that refers to T, >> but I am concerned about the inner addition operation here, >> and if it is done in a saturating way. > > Ok, a valid concern. > >> >>> + && !FLOAT_TYPE_P (TREE_TYPE (a)) >>> + && !FIXED_POINT_TYPE_P (TREE_TYPE (a)) >>> >>> likewise. >> >> Well, maybe this cannot happen, because if we have P + A, computed in float, >> and T an integer type, then probably CONVERT_EXPR_CODE_P (def_code) >> will not match, because def_code is FIX_TRUNC_EXPR in that case? > > Yes. It cannot be a FLOAT_TYPE_P here, similar for fixed-point which > would use FIXED_CONVERT_EXPR. Saturating types don't seem to have > a special conversion tree code. > then this should be an assertion, with a comment why this is supposed to be impossible. >> OTOH it does not hut to check that, becaue A's type may be quite different >> than rhs1's type. >> >>> >>> + || (!POINTER_TYPE_P (TREE_TYPE (p)) >>> + && INTEGRAL_TYPE_P (TREE_TYPE (a)) >>> + && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (a))) >>> >>> INTEGRAL_TYPE_P are always !POINTER_TYPE_P. >>> >>> >> >> We come here, either because P + A is a POINTER_PLUS_EXPR or because P + A >> is a PLUS_EXPR. > > Ah, p vs. a - misread that code. > >> In the first case, P's type is POINTER_TYPE_P and A's type is INTEGRAL_TYPE_P >> so this should not check the TYPE_OVERFLOW_UNDEFINED, but instead >> the POINTER_TYPE_OVERFLOW_UNDEFINED. >> >> Also with undefined pointer wraparound, we can exploit that in the same way >> as with >> signed integers. >> >> But I am concerned, if (T)A is always the same thing as (T)(void*)A. >> I'd say, yes, if TYPE_UNSIGNED (TREE_TYPE (p)) == TYPE_UNSIGNED (TREE_TYPE >> (a)) >> or if A is a constant, and it i
Re: [Patch] Not very subtle fix for pr61510
> On Mon, 23 Jun 2014, James Greenhalgh wrote: > > > > > Hi, > > > > pr61510 is a case where cgraphunit.c::analyze_functions can end up > > dereferencing a NULL pointer. This is, to me, the obvious way to avoid > > dereferencing NULL. > > > > However, I'm not very confident that this isn't just masking some > > horrible and subtle bug, so I'd like some review feedback on the patch. > > > > Tested on aarch64-none-elf, where I was seeing the issue. > > > > OK? > > Obvious in some sense to me, too, but I wonder why we don't have a cgraph > node > for it and what happens if it is created later (and then doesn't > have the flag set)? In that case we won't get the used_as_abstract_origin flag. that will make us to throw away the debug info if we remove it. I guess we simply want graph_get_create_node here. I can prepare patch tonight (after teaching) Honza
Re: Another AIX Bootstrap failure
> The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin with
>
> /opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
> definitions not supported in Mach-O; ignored
>
> I think they should be protected by
>
> /* { dg-require-alias "" } */
I see, the anoying property of dg.exp where we compile the additional sources
separately, too. Will fix that.
Is it really the case that Mach-O have no way of creating alias, even by
putting alternative symbol into the
source as we intend to do for AIX?
Honza
>
> Dominique
[PATCH][libsanitizer] Cherry-pick r211008 [Was: Re: libsanitizer merge from upstream r208536]
Hi,
On 06/16/2014 10:42 AM, Konstantin Serebryany wrote:
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini wrote:
Hi,
On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
In file included from
../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
In function ‘int __interceptor_accept4(int, void*, unsigned int*,
int)’:
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1821:12:
warning: ‘addrlen0’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
unsigned addrlen0;
^
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
In function ‘int __interceptor_accept(int, void*, unsigned int*)’:
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1799:12:
warning: ‘addrlen0’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
unsigned addrlen0;
^
That sounds like a false positive warning:
unsigned addrlen0;
if (addrlen) {
COMMON_INTERCEPTOR_READ_RANGE(ctx, addrlen, sizeof(*addrlen));
addrlen0 = *addrlen;
}
int fd2 = REAL(accept4)(fd, addr, addrlen, f);
if (fd2 >= 0) {
if (fd >= 0) COMMON_INTERCEPTOR_FD_SOCKET_ACCEPT(ctx, fd, fd2);
if (addr && addrlen)
COMMON_INTERCEPTOR_WRITE_RANGE(ctx, addr, Min(*addrlen, addrlen0));
}
(unless the COMMON_INTERCEPTOR* macros do too weird stuff), wonder why the
predicate aware uninit doesn't handle this.
By the way, I'm still seeing the above. Maybe a maintainer can have a look,
double check it's just a false positive a shut it up somehow?
I've "fixed" this in upstream trunk:
http://llvm.org/viewvc/llvm-project?view=revision&revision=211008
This will get into GCC with the next merge; or feel free to cherry pick.
Thus, can I apply the below?
Thanks!
Paolo.
/
2014-06-23 Paolo Carlini
* sanitizer_common/sanitizer_common_interceptors.inc:
Cherry pick upstream r211008.
Index: sanitizer_common/sanitizer_common_interceptors.inc
===
--- sanitizer_common/sanitizer_common_interceptors.inc (revision 211905)
+++ sanitizer_common/sanitizer_common_interceptors.inc (working copy)
@@ -1796,7 +1796,7 @@ INTERCEPTOR(int, getsockopt, int sockfd, int level
INTERCEPTOR(int, accept, int fd, void *addr, unsigned *addrlen) {
void *ctx;
COMMON_INTERCEPTOR_ENTER(ctx, accept, fd, addr, addrlen);
- unsigned addrlen0;
+ unsigned addrlen0 = 0;
if (addrlen) {
COMMON_INTERCEPTOR_READ_RANGE(ctx, addrlen, sizeof(*addrlen));
addrlen0 = *addrlen;
@@ -1818,7 +1818,7 @@ INTERCEPTOR(int, accept, int fd, void *addr, unsig
INTERCEPTOR(int, accept4, int fd, void *addr, unsigned *addrlen, int f) {
void *ctx;
COMMON_INTERCEPTOR_ENTER(ctx, accept4, fd, addr, addrlen, f);
- unsigned addrlen0;
+ unsigned addrlen0 = 0;
if (addrlen) {
COMMON_INTERCEPTOR_READ_RANGE(ctx, addrlen, sizeof(*addrlen));
addrlen0 = *addrlen;
RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
Hi, On Mon, 23 Jun 2014 10:27:59, Jeff Law wrote: > > On 06/22/14 01:14, Bernd Edlinger wrote: >> Hi, >> >> I noticed that several testcases in the GMP-4.3.2 test suite are failing now >> which >> did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and >> found >> the file mpn/generic/get_str.c was miscompiled. > It's interesting you stumbled on this. I've seen this issue come and go > as well in some of my integration testing work with the trunk. > > > Jeff Yes, it will likely come with -m64 and go with -m32. Bernd.
Re: [PATCH] DWARFv5 Emit DW_TAG_atomic_type.
On Mon, 2014-06-23 at 10:31 -0600, Tom Tromey wrote: > > "Mark" == Mark Wielaard writes: > > Mark> The following is just a prototype to try out a new qualifier type tag > Mark> proposed for DWARFv5. There is not even a draft yet of DWARFv5, so this > Mark> is just based on a proposal that might or might not be adopted and/or > Mark> changed http://dwarfstd.org/ShowIssue.php?issue=131112.1 > > Mark> gcc/ChangeLog > > Mark> * dwarf2out.h (enum dw_mod_flag): Add dw_mod_atomic. > Mark> * dwarf2out.c (dw_mod_decl_flags): Handle TYPE_ATOMIC. > Mark> (dw_mod_type_flags): Likewise. > Mark> (dw_mods_to_quals): Likewise. > Mark> (dw_mod_qualified_type): Likewise. > Mark> (modified_type_die): Likewise. > Mark> opts.c (common_handle_option): Accept -gdwarf-5. > > The ChangeLog should mention PR debug/60782 -- I saw you did this in the > "restrict" patch so you probably just weren't aware of this one... Thanks, I wasn't aware there was already a bug for this. I have added myself to the CC, added a comment to the bug pointing at the prototype patch and added the PR reference to the ChangeLog entry and commit message. Cheers, Mark
Re: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
On Mon, Jun 23, 2014 at 4:28 PM, Bernd Edlinger wrote: > Hi, > > On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: >> >> On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger >> wrote: >>> Hi, >>> >>> I noticed that several testcases in the GMP-4.3.2 test suite are failing >>> now which >>> did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and >>> found >>> the file mpn/generic/get_str.c was miscompiled. >>> >>> mpn/get_str.c.132t.dse2: >>> pretmp_183 = (sizetype) chars_per_limb_80; >>> pretmp_184 = -pretmp_183; >>> _23 = chars_per_limb_80 + 4294967295; >>> _68 = (sizetype) _23; >>> _28 = _68 + pretmp_184; >>> >>> mpn/get_str.c.133t.forwprop4: >>> _28 = 4294967295; >>> >>> >>> That is wrong, because chars_per_limb is unsigned, and it is not zero. >>> So the right result should be -1. This makes the loop termination in that >>> function fail. >>> >>> The reason for this is in this check-in: >>> >>> r210807 | ebotcazou | 2014-05-22 16:32:56 +0200 (Thu, 22 May 2014) | 3 lines >>> >>> * tree-ssa-forwprop.c (associate_plusminus): Extend (T)(P + A) - (T)P >>> -> (T)A transformation to integer types. >>> >>> >>> Because it implicitly assumes that integer overflow is not allowed with all >>> types, >>> including unsigned int. >> >> Hmm? But the transform is correct if overflow wraps. And it's correct if >> overflow is undefined as well, as (T)A is always well-defined (implementation >> defined) if it is a truncation. >> > > we have no problem when the cast from (P + A) to T is a truncation, except if > the add operation P + A is saturating. Ah, we indeed look at an inner operation. >> So we match the above an try to transform it to (T)P + (T)A - (T)P. That's >> wrong if the conversion is extending I think. >> > > Yes, in a way. But OTOH, Eric's test case opt37.adb, fails if we simply punt > here. > > Fortunately, with opt37.adb, P and A are signed 32-bit integers, and T is > size_t (64 bit) > and because the overflow of P + A causes undefined behaviour, we can assume > that > P + A _did_ not overflow, and therefore the transformation (T)(P + A) == (T)P > + (T)A > is correct (but needs a strict overflow warning), and we still can use the > pattern > (T)P + (T)A - (T)P -> (T)A in this case. Ok, though that is then the only transform that uses strict-overflow semantics. > But we cannot use this transformation, as the attached test case demonstrates > when P + A is done in unsigned integers, because the result of the addition is > different if it is done in unsigned int with allowed overflow, or in long > without > overflow. > >> Richard. >> >> >>> >>> The attached patch fixes these regressions, and because the reasoning >>> depends >>> on the TYPE_OVERFLOW_UNDEFINED attribute, a strict overflow warning has to >>> be >>> emitted here, at least for widening conversions. >>> >>> >>> Boot-strapped and regression-tested on x86_64-linux-gnu with all languages, >>> including Ada. >>> OK for trunk? >> >> + if (!TYPE_SATURATING (TREE_TYPE (a)) >> >> this is already tested at the very beginning of the function. >> > > We have done TYPE_SATURATING (TREE_TYPE (rhs1)) that refers to T, > but I am concerned about the inner addition operation here, > and if it is done in a saturating way. Ok, a valid concern. > >> + && !FLOAT_TYPE_P (TREE_TYPE (a)) >> + && !FIXED_POINT_TYPE_P (TREE_TYPE (a)) >> >> likewise. > > Well, maybe this cannot happen, because if we have P + A, computed in float, > and T an integer type, then probably CONVERT_EXPR_CODE_P (def_code) > will not match, because def_code is FIX_TRUNC_EXPR in that case? Yes. It cannot be a FLOAT_TYPE_P here, similar for fixed-point which would use FIXED_CONVERT_EXPR. Saturating types don't seem to have a special conversion tree code. > OTOH it does not hut to check that, becaue A's type may be quite different > than rhs1's type. > >> >> + || (!POINTER_TYPE_P (TREE_TYPE (p)) >> + && INTEGRAL_TYPE_P (TREE_TYPE (a)) >> + && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (a))) >> >> INTEGRAL_TYPE_P are always !POINTER_TYPE_P. >> >> > > We come here, either because P + A is a POINTER_PLUS_EXPR or because P + A is > a PLUS_EXPR. Ah, p vs. a - misread that code. > In the first case, P's type is POINTER_TYPE_P and A's type is INTEGRAL_TYPE_P > so this should not check the TYPE_OVERFLOW_UNDEFINED, but instead > the POINTER_TYPE_OVERFLOW_UNDEFINED. > > Also with undefined pointer wraparound, we can exploit that in the same way > as with > signed integers. > > But I am concerned, if (T)A is always the same thing as (T)(void*)A. > I'd say, yes, if TYPE_UNSIGNED (TREE_TYPE (p)) == TYPE_UNSIGNED (TREE_TYPE > (a)) > or if A is a constant, and it is positive. I don't understand this last bit. If p is pointer then a is of unsigned sizetype. sizetypes size doesn't have to match pointer size. Can you re-work the patch to split the case that doesn't exploit the undefined behavior (and thus does not need to warn) and the case that does, adding comments with reasoni
[Patch, Fortran, committed] Fixed one issue with -fcoarray=lib
The issue fixed by the attached test case was that an automatic array
wasn't properly initialized with -fcoarray=lib. As the code is for
explicit-size arrays, it isn't reachable for allocatable coarrays. On
the other hand, for coarrays with SAVE attribute, already the condition
before should be triggered:
else if (sym->attr.codimension && TREE_STATIC (sym->backend_decl))
Thus, removing the condition for good should be fine. (Alternatively,
one could add an "|| !sym->attr.codimension".)
Build and regtested on x86-64-gnu-linux.
Committed as Rev. 211907.
Tobias
gcc/fortran/
2014-06-23 Tobias Burnus
* trans-decl.c (gfc_trans_deferred_vars): Fix handling of
explicit-size arrays with -fcoarray=lib.
gcc/testsuite/
2014-06-23 Tobias Burnus
* gfortran.dg/coarray_32.f90: New.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index f1a18c3..291dd1f 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3870,7 +3870,7 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
NULL_TREE);
continue;
}
- else if (gfc_option.coarray != GFC_FCOARRAY_LIB)
+ else
{
gfc_save_backend_locus (&loc);
gfc_set_backend_locus (&sym->declared_at);
diff --git a/gcc/testsuite/gfortran.dg/coarray_32.f90 b/gcc/testsuite/gfortran.dg/coarray_32.f90
new file mode 100644
index 000..8e6dc54
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_32.f90
@@ -0,0 +1,18 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original -fcoarray=lib" }
+!
+ real, allocatable :: values(:)[:]
+ allocate(values(1024)[*])
+ call laplacian(values)
+contains
+ subroutine laplacian(rhs)
+real, allocatable :: rhs(:)[:]
+real :: local_laplacian(size(rhs))
+local_laplacian=0.
+ end subroutine
+end
+
+! { dg-final { scan-tree-dump-times "ubound.. = " 1 "original" } }
+! { dg-final { scan-tree-dump-times "size.. = " 2 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
+
Re: [PATCH 2/N] allow storing values directly in hash tables
On Fri, Jun 20, 2014 at 12:52 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> this patch allows you to define the type the hash table stores as elements
> instead of the type elements point at by having your hash descriptor define
> the
> type store_values_directly. It turns out trying to implement both cases with
> the same code is really confusing, so I ended up providing one partial
> specialization for each case. Its a lot of coppying, but I'm hoping the next
> patch will get rid of many direct users of hash_table, and the rest can all
> get
> converted to tell the hash table the type entries should have at which point
> the dupplication can be removed.
>
> bootstrapped + regtested without regression on x86_64-unknown-linux-gnu, ok?
Ok. I hope that de-duplication works out.
Thanks,
Richard.
> Trev
>
> gcc/
>
> * hash-table.h: Add a template arg to choose between storing values
> and storing pointers to values, and then provide partial
> specializations for both.
> * tree-browser.c (tree_upper_hasher): Provide the type the hash table
> should store, not the type values should point to.
> * tree-into-ssa.c (var_info_hasher): Likewise.
> * tree-ssa-dom.c (expr_elt_hasher): Likewise.
> * tree-complex.c: Adjust.
> * tree-hasher.h (int_tree_hasher): store int_tree_map in the hash
> table instead of int_tree_map *.
> * tree-parloops.c: Adjust.
> * tree-ssa-reassoc.c (ocount_hasher): Don't lie to hash_map about what
> type is being stored.
> * tree-vectorizer.c: Adjust.
>
> diff --git a/gcc/hash-table.h b/gcc/hash-table.h
> index 41cc19e..22af12f 100644
> --- a/gcc/hash-table.h
> +++ b/gcc/hash-table.h
> @@ -272,19 +272,18 @@ typed_noop_remove ::remove (Type *p
> ATTRIBUTE_UNUSED)
> template
> struct pointer_hash : typed_noop_remove
> {
> - typedef Type value_type;
> - typedef Type compare_type;
> + typedef Type *value_type;
> + typedef Type *compare_type;
> + typedef int store_values_directly;
>
> - static inline hashval_t
> - hash (const value_type *);
> + static inline hashval_t hash (const value_type &);
>
> - static inline int
> - equal (const value_type *existing, const compare_type *candidate);
> + static inline bool equal (const value_type &existing, const compare_type
> &candidate);
> };
>
> template
> inline hashval_t
> -pointer_hash ::hash (const value_type *candidate)
> +pointer_hash ::hash (const value_type &candidate)
> {
>/* This is a really poor hash function, but it is what the current code
> uses,
> so I am reusing it to avoid an additional axis in testing. */
> @@ -292,9 +291,9 @@ pointer_hash ::hash (const value_type *candidate)
> }
>
> template
> -inline int
> -pointer_hash ::equal (const value_type *existing,
> - const compare_type *candidate)
> +inline bool
> +pointer_hash ::equal (const value_type &existing,
> + const compare_type &candidate)
> {
>return existing == candidate;
> }
> @@ -319,10 +318,147 @@ extern unsigned int hash_table_higher_prime_index
> (unsigned long n);
> extern hashval_t hash_table_mod1 (hashval_t hash, unsigned int index);
> extern hashval_t hash_table_mod2 (hashval_t hash, unsigned int index);
>
> +/* The below is some template meta programming to decide if we should use the
> + hash table partial specialization that directly stores value_type instead
> of
> + pointers to value_type. If the Descriptor type defines the type
> + Descriptor::store_values_directly then values are stored directly
> otherwise
> + pointers to them are stored. */
> +template struct notype { typedef void type; };
> +
> +template
> +struct storage_tester
> +{
> + static const bool value = false;
> +};
> +
> +template
> +struct storage_tester +T::store_values_directly>::type>
> +{
> + static const bool value = true;
> +};
> +
> + template
> + struct has_is_deleted
> +{
> + template struct helper {};
> + template static char test (helper *);
> + template static int test (...);
> + static const bool value = sizeof (test (0)) == sizeof (char);
> +};
> +
> +template has_is_deleted::value>
> +struct is_deleted_helper
> +{
> + static inline bool
> + call (Type &v)
> + {
> +return Traits::is_deleted (v);
> + }
> +};
> +
> +template
> +struct is_deleted_helper
> +{
> + static inline bool
> + call (Type *v)
> + {
> +return v == HTAB_DELETED_ENTRY;
> + }
> +};
> +
> + template
> + struct has_is_empty
> +{
> + template struct helper {};
> + template static char test (helper *);
> + template static int test (...);
> + static const bool value = sizeof (test (0)) == sizeof (char);
> +};
> +
> +template has_is_deleted::value>
> +struct is_empty_helper
> +{
> + static inline bool
> + call (Type &v)
> + {
> +return Traits::is_empty (v);
> + }
> +};
> +
> +template
> +struct is_empty_helper
> +{
> + static
Re: [PATCH 3/3] add hash_map class
On Fri, Jun 20, 2014 at 12:52 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> This patch adds a hash_map class so we can consolidate the boiler plate around
> using hash_table as a map, it also allows us to get rid of pointer_map which I
> do in this patch by converting its users to hash_map.
>
> bootstrapped + regtested without regression on x86_64-unknown-linux-gnu, ok?
Ok.
Thanks,
Richard.
> Trev
>
> gcc/
>
> * alloc-pool.c (alloc_pool_hash): Use hash_map instead of hash_table.
> * dominance.c (iterate_fix_dominators): Use hash_map instead of
> pointer_map.
> * hash-map.h: New file.
> * ipa-comdats.c: Use hash_map instead of pointer_map.
> * lto-section-out.c: Adjust.
> * lto-streamer.h: Replace pointer_map with hash_map.
> * symtab.c (verify_symtab): Likewise.
> * tree-ssa-strlen.c (decl_to_stridxlist_htab): Likewise.
> * tree-ssa-uncprop.c (val_ssa_equiv): Likewise.
> * tree-streamer.h: Likewise.
> * tree-streamer.c: Adjust.
> * pointer-set.h: Remove pointer_map.
>
> lto/
>
> * lto.c (canonical_type_hash_cache): Use hash_map instead of
> pointer_map.
>
> diff --git a/gcc/alloc-pool.c b/gcc/alloc-pool.c
> index 49209ee..0d31835 100644
> --- a/gcc/alloc-pool.c
> +++ b/gcc/alloc-pool.c
> @@ -22,6 +22,7 @@ along with GCC; see the file COPYING3. If not see
> #include "system.h"
> #include "alloc-pool.h"
> #include "hash-table.h"
> +#include "hash-map.h"
>
> #define align_eight(x) (((x+7) >> 3) << 3)
>
> @@ -69,7 +70,6 @@ static ALLOC_POOL_ID_TYPE last_id;
> size for that pool. */
> struct alloc_pool_descriptor
> {
> - const char *name;
>/* Number of pools allocated. */
>unsigned long created;
>/* Gross allocated storage. */
> @@ -82,48 +82,17 @@ struct alloc_pool_descriptor
>int elt_size;
> };
>
> -/* Hashtable helpers. */
> -struct alloc_pool_hasher : typed_noop_remove
> -{
> - typedef alloc_pool_descriptor value_type;
> - typedef char compare_type;
> - static inline hashval_t hash (const alloc_pool_descriptor *);
> - static inline bool equal (const value_type *, const compare_type *);
> -};
> -
> -inline hashval_t
> -alloc_pool_hasher::hash (const value_type *d)
> -{
> - return htab_hash_pointer (d->name);
> -}
> -
> -inline bool
> -alloc_pool_hasher::equal (const value_type *d,
> - const compare_type *p2)
> -{
> - return d->name == p2;
> -}
> -
> /* Hashtable mapping alloc_pool names to descriptors. */
> -static hash_table *alloc_pool_hash;
> +static hash_map *alloc_pool_hash;
>
> /* For given name, return descriptor, create new if needed. */
> static struct alloc_pool_descriptor *
> allocate_pool_descriptor (const char *name)
> {
> - struct alloc_pool_descriptor **slot;
> -
>if (!alloc_pool_hash)
> -alloc_pool_hash = new hash_table (10);
> -
> - slot = alloc_pool_hash->find_slot_with_hash (name,
> - htab_hash_pointer (name),
> - INSERT);
> - if (*slot)
> -return *slot;
> - *slot = XCNEW (struct alloc_pool_descriptor);
> - (*slot)->name = name;
> - return *slot;
> +alloc_pool_hash = new hash_map (10);
> +
> + return &alloc_pool_hash->get_or_insert (name);
> }
>
> /* Create a pool of things of size SIZE, with NUM in each block we
> @@ -375,23 +344,22 @@ struct output_info
>unsigned long total_allocated;
> };
>
> -/* Called via hash_table.traverse. Output alloc_pool descriptor pointed out
> by
> +/* Called via hash_map.traverse. Output alloc_pool descriptor pointed out by
> SLOT and update statistics. */
> -int
> -print_alloc_pool_statistics (alloc_pool_descriptor **slot,
> +bool
> +print_alloc_pool_statistics (const char *const &name,
> +const alloc_pool_descriptor &d,
> struct output_info *i)
> {
> - struct alloc_pool_descriptor *d = *slot;
> -
> - if (d->allocated)
> + if (d.allocated)
> {
>fprintf (stderr,
>"%-22s %6d %10lu %10lu(%10lu) %10lu(%10lu) %10lu(%10lu)\n",
> - d->name, d->elt_size, d->created, d->allocated,
> - d->allocated / d->elt_size, d->peak, d->peak / d->elt_size,
> - d->current, d->current / d->elt_size);
> - i->total_allocated += d->allocated;
> - i->total_created += d->created;
> + name, d.elt_size, d.created, d.allocated,
> + d.allocated / d.elt_size, d.peak, d.peak / d.elt_size,
> + d.current, d.current / d.elt_size);
> + i->total_allocated += d.allocated;
> + i->total_created += d.created;
> }
>return 1;
> }
> diff --git a/gcc/dominance.c b/gcc/dominance.c
> index 7adec4f..be0a439 100644
> --- a/gcc/dominance.c
> +++ b/gcc/dominance.c
> @@ -43,6 +43,7 @@
> #include "diagnostic-core.h"
> #include "et-forest.h"
> #include "timevar.h"
> +#include "hash-map.h"
> #inc
Re: [PATCH] Fix for invalid sanitization of trailing byte in __builtin_strlen
Hi,
when I applied this patch (r211846), I made a little mistake in output
test patterns. This patch fixes this.
Tested on x86_64-unknown-linux-gnu.
Ok to commit?
-Maxim
gcc/testsuite/ChangeLog:
2014-06-23 Max Ostapenko
* c-c++-common/asan/strlen-overflow-1.c: Change match patterns.
diff --git a/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c b/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c
index bf6bf66..f58f554 100644
--- a/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c
@@ -26,4 +26,5 @@ int main () {
}
/* { dg-output "READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r)" } */
-/* { dg-output "#0 0x\[0-9a-f\]+ (in _*main (\[^\n\r]*strlen-overflow-1.c:24|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
+/* { dg-output "#0 0x\[0-9a-f\]+ (in _*main (\[^\n\r]*strlen-overflow-1.c:25|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*0x\[0-9a-f\]+ is located 1 bytes inside of global variable" } */
Re: [PATCH] Don't segv on __atomic_store (PR c/61553)
On Mon, 23 Jun 2014, Marek Polacek wrote: > We ICEd on the following testcase since the void type has a NULL > TYPE_SIZE_UNIT. I took Andrew's patch from gcc@ ML and added > a testcase. > > Regtested/bootstrapped on x86_64-linux, ok for trunk? > > 2014-06-23 Marek Polacek > Andrew MacLeod > > PR c/61553 > * c-common.c (get_atomic_generic_size): Don't segfault if the > type doesn't have a size. > > * c-c++-common/pr61553.c: New test. OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH][RFC] Gate loop passes group on number-of-loops > 1, add no-loops group
On Wed, 18 Jun 2014, Jeff Law wrote: > On 06/18/14 04:42, Richard Biener wrote: > > > > The following aims at reducing the number of pointless passes we run > > on functions containing no loops. Those are at least two copyprop > > and one dce pass (two dce passes when vectorization is enabled, > > three dce passes and an additional copyprop pass when any graphite > > optimization is enabled). > > > > Simply gating pass_tree_loop on number_of_loops () > 1 would disable > > basic-block vectorization on loopless functions. Moving > > basic-block vectorization out of pass_tree_loop works to the extent > > that you'd need to move IVOPTs as well as data-ref analysis cannot > > cope with TARGET_MEM_REFs. > > > > So the following introduces a pass_tree_no_loop pass group which > > is enabled whenever the pass_tree_loop group is disabled. > > As followup this would allow to skip cleanup work we do after the loop > > pipeline just to cleanup after it. > > > > Any comments? Does such followup sound realistic or would it be > > better to take the opportunity to move IVOPTs a bit closer to > > RTL expansion and avoid that "pass_tree_no_loop hack"? > Sounds good. I've always believed that each pass should be bubbling back up > some kind of status about what it did/found as well. > > It was more of an RTL issue, but we had a certain commercial testsuite which > created large loopless tests (*) that consumed vast quantities of wall clock > time. I always wanted the RTL loop passes to signal back to toplev.c that no > loops were found, which would in turn be used to say "we really don't need > cse-after-loop and friends". > It's certainly more complex these days, but I'd still like to be able to do > such things. > > Regardless, that's well outside the scope of what you're trying to accomplish. Not really - it's just the start of a series of (possible) patches. I want to cut down the post-loop pass pipeline for functions without loops. But indeed we may want to apply the same trick to RTL. The following is what I ended up applying (ugh, we need a more elegant solution for those dump naming / cleanup issues). Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2014-06-23 Richard Biener * tree-ssa-loop.c (gate_loop): New function. (pass_tree_loop::gate): Call it. (pass_data_tree_no_loop, pass_tree_no_loop, make_pass_tree_no_loop): New. * tree-vectorizer.c: Include tree-scalar-evolution.c (pass_slp_vectorize::execute): Initialize loops and SCEV if required. (pass_slp_vectorize::clone): New method. * timevar.def (TV_TREE_NOLOOP): New. * tree-pass.h (make_pass_tree_no_loop): Declare. * passes.def (pass_tree_no_loop): New pass group with SLP vectorizer. * g++.dg/vect/slp-pr50413.cc: Scan and cleanup appropriate SLP dumps. * g++.dg/vect/slp-pr50819.cc: Likewise. * g++.dg/vect/slp-pr56812.cc: Likewise. * gcc.dg/vect/bb-slp-1.c: Likewise. * gcc.dg/vect/bb-slp-10.c: Likewise. * gcc.dg/vect/bb-slp-11.c: Likewise. * gcc.dg/vect/bb-slp-13.c: Likewise. * gcc.dg/vect/bb-slp-14.c: Likewise. * gcc.dg/vect/bb-slp-15.c: Likewise. * gcc.dg/vect/bb-slp-16.c: Likewise. * gcc.dg/vect/bb-slp-17.c: Likewise. * gcc.dg/vect/bb-slp-18.c: Likewise. * gcc.dg/vect/bb-slp-19.c: Likewise. * gcc.dg/vect/bb-slp-2.c: Likewise. * gcc.dg/vect/bb-slp-20.c: Likewise. * gcc.dg/vect/bb-slp-21.c: Likewise. * gcc.dg/vect/bb-slp-22.c: Likewise. * gcc.dg/vect/bb-slp-23.c: Likewise. * gcc.dg/vect/bb-slp-24.c: Likewise. * gcc.dg/vect/bb-slp-25.c: Likewise. * gcc.dg/vect/bb-slp-26.c: Likewise. * gcc.dg/vect/bb-slp-27.c: Likewise. * gcc.dg/vect/bb-slp-28.c: Likewise. * gcc.dg/vect/bb-slp-29.c: Likewise. * gcc.dg/vect/bb-slp-3.c: Likewise. * gcc.dg/vect/bb-slp-30.c: Likewise. * gcc.dg/vect/bb-slp-31.c: Likewise. * gcc.dg/vect/bb-slp-32.c: Likewise. * gcc.dg/vect/bb-slp-4.c: Likewise. * gcc.dg/vect/bb-slp-5.c: Likewise. * gcc.dg/vect/bb-slp-6.c: Likewise. * gcc.dg/vect/bb-slp-7.c: Likewise. * gcc.dg/vect/bb-slp-8.c: Likewise. * gcc.dg/vect/bb-slp-8a.c: Likewise. * gcc.dg/vect/bb-slp-8b.c: Likewise. * gcc.dg/vect/bb-slp-9.c: Likewise. * gcc.dg/vect/bb-slp-cond-1.c: Likewise. * gcc.dg/vect/bb-slp-pattern-1.c: Likewise. * gcc.dg/vect/bb-slp-pattern-2.c: Likewise. * gcc.dg/vect/fast-math-bb-slp-call-1.c: Likewise. * gcc.dg/vect/fast-math-bb-slp-call-2.c: Likewise. * gcc.dg/vect/fast-math-bb-slp-call-3.c: Likewise. * gcc.dg/vect/no-tree-reassoc-bb-slp-12.c: Likewise. * gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c: Likewise. * gcc.dg/vect/pr26359.c: Likewise. * gcc.dg/vect/costmodel/pp
Re: Another AIX Bootstrap failure
The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin with
/opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
definitions not supported in Mach-O; ignored
I think they should be protected by
/* { dg-require-alias "" } */
Dominique
Re: calloc = malloc + memset
On Mon, Jun 23, 2014 at 6:19 PM, Marc Glisse wrote:
> On Mon, 23 Jun 2014, Richard Biener wrote:
>
>> On June 23, 2014 5:51:30 PM CEST, Marc Glisse
>> wrote:
>>>
>>> On Mon, 23 Jun 2014, Jakub Jelinek wrote:
>>>
Ok for trunk, sorry for the delay.
>>>
>>>
>>> Thanks. Richard has moved the passes a bit since then, but I still have
>>>
>>> exactly one spot where the testsuite is ok :-) I need strlen to be
>>> after
>>> dom (for calloc.C) and before vrp (for several strlenopt-*.c). I'll
>>> commit
>>> it tomorrow if there aren't any comments on the pass placement.
>>
>>
>> But vrp does not run at -O1 - does strlenopt?
>
>
> { OPT_LEVELS_2_PLUS_SPEED_ONLY, OPT_foptimize_strlen, NULL, 1 },
> { OPT_LEVELS_2_PLUS, OPT_ftree_vrp, NULL, 1 },
>
> So that's just a missed optimization at -Os, I guess.
Ok, that's fine (not sure why we restrict all of strilenopt instead of
just those
transforms that are harmful for -Os).
Richard.
> --
> Marc Glisse
Re: [patch i386]: Combine memory and indirect jump
On 06/23/2014 09:22 AM, Jeff Law wrote: > On 06/23/14 08:32, Richard Biener wrote: >> Btw, there is now no DCE after peephole2? Is peephole2 expected to >> cleanup after itself? > There were cases where we wanted to change the insns we would output to fit > into the 4:1:1 issue model of the PPro, but to do so we needed to know what > registers were live/dead so that we could rewrite the insns appropriately. It > didn't fit well into what we could do in the splitters and the old peephole > ran > too late. Dead code wasn't ever really considered. At least that's my > recollection. RTH might recall more. Yes, peep2 was about doing what the old "peep1" rtl->text transformation did, but as an rtl->rtl transformation so we can expose the result to the scheduler. It's expected that all dead code be gone before sched2, so that the scheduler sees exactly what needs to be scheduled, and can bundle insns appropriately. I believe the peep2 pass to also want dead code to be gone, so that it gets an accurate picture of what registers are live or dead at any point. As far as I know, there are no current transformations that create new garbage. r~
Re: [GSoC][match-and-simplify] mark some more operators as commutative
On Mon, Jun 23, 2014 at 4:38 PM, Richard Biener wrote: > On Mon, Jun 23, 2014 at 4:23 PM, Marc Glisse wrote: >> On Mon, 23 Jun 2014, Richard Biener wrote: >> >>> On Mon, Jun 23, 2014 at 3:32 PM, Prathamesh Kulkarni >>> wrote: * match.pd: Mark operators in some bitwise and plus-minus patterns to be commutative. >>> >>> >>> /* A - (A +- B) -> -+ B */ >>> (match_and_simplify >>> - (minus @0 (plus @0 @1)) >>> + (minus @0 (plus:c @0 @1)) >>> (negate @0)) >>> >>> seems pointless >> >> >> Why? a-(a+b) and a-(b+a) are both wanted and don't appear elsewhere in the >> file, no? Should simplify to (negate @1) though. > > Ah, indeed. So here commutation doesn't work because of correctness. Or rather the pattern is broken from the start ... fixed. Richard. > Richard. > >> -- >> Marc Glisse
Re: [Patch] Not very subtle fix for pr61510
On Mon, 23 Jun 2014, James Greenhalgh wrote: > > Hi, > > pr61510 is a case where cgraphunit.c::analyze_functions can end up > dereferencing a NULL pointer. This is, to me, the obvious way to avoid > dereferencing NULL. > > However, I'm not very confident that this isn't just masking some > horrible and subtle bug, so I'd like some review feedback on the patch. > > Tested on aarch64-none-elf, where I was seeing the issue. > > OK? Obvious in some sense to me, too, but I wonder why we don't have a cgraph node for it and what happens if it is created later (and then doesn't have the flag set)? Honza? Richard. > Thanks, > James > > --- > 2014-06-19 James Greenhalgh > > PR regression/61510 > * cgraphunit.c (analyze_functions): Check we have an origin > node before dereferencing it. > -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH] DWARFv5 Emit DW_TAG_atomic_type.
> "Mark" == Mark Wielaard writes: Mark> The following is just a prototype to try out a new qualifier type tag Mark> proposed for DWARFv5. There is not even a draft yet of DWARFv5, so this Mark> is just based on a proposal that might or might not be adopted and/or Mark> changed http://dwarfstd.org/ShowIssue.php?issue=131112.1 Mark> gcc/ChangeLog Mark> * dwarf2out.h (enum dw_mod_flag): Add dw_mod_atomic. Mark> * dwarf2out.c (dw_mod_decl_flags): Handle TYPE_ATOMIC. Mark> (dw_mod_type_flags): Likewise. Mark> (dw_mods_to_quals): Likewise. Mark> (dw_mod_qualified_type): Likewise. Mark> (modified_type_die): Likewise. Mark> opts.c (common_handle_option): Accept -gdwarf-5. The ChangeLog should mention PR debug/60782 -- I saw you did this in the "restrict" patch so you probably just weren't aware of this one... Tom
Re: [PATCH] Fix up -march=native handling under KVM (PR target/61570)
On Sun, Jun 22, 2014 at 11:23 AM, Uros Bizjak wrote:
> On Sat, Jun 21, 2014 at 8:07 PM, Jakub Jelinek wrote:
>
>>> > --- gcc/config/i386/driver-i386.c.jj2014-05-14 14:45:54.0
>>> > +0200
>>> > +++ gcc/config/i386/driver-i386.c 2014-06-20 18:59:57.805006358
>>> > +0200
>>> > @@ -745,6 +745,11 @@ const char *host_detect_local_cpu (int a
>>> > /* Assume Core 2. */
>>> > cpu = "core2";
>>> > }
>>> > + else if (has_longmode)
>>> > + /* Perhaps some emulator? Assume x86-64, otherwise gcc
>>> > + -march=native would be unusable for 64-bit
>>> > compilations,
>>> > + as all the CPUs below are 32-bit only. */
>>> > + cpu = "x86-64";
>>> > else if (has_sse3)
>>> > /* It is Core Duo. */
>>> > cpu = "pentium-m";
>>> >
>>> > Jakub
>>>
>>> host_detect_local_cpu guesses the cpu based on the real processors.
>>> It doesn't work with emulators due to some conflicts. This isn't the
>>> only only place which has the same issue. I prefer something like
>>> this.
>>
>> I'm fine with your patch too. Let's wait what Uros (or other i?86
>> maintainers) pick up.
>
> This looks OK to me.
>
> Thanks,
> Uros.
This is what I checked in.
Thanks.
--
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 211900)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2014-06-23 H.J. Lu
+
+ PR target/61570
+ * config/i386/driver-i386.c (host_detect_local_cpu): Set arch
+ to x86-64 if a 32-bit processor supports SSE2 and 64-bit.
+
2014-06-23 James Greenhalgh
* config/aarch64/aarch64.md (addsi3_aarch64): Set "simd" attr to
Index: config/i386/driver-i386.c
===
--- config/i386/driver-i386.c (revision 211900)
+++ config/i386/driver-i386.c (working copy)
@@ -415,6 +415,7 @@ const char *host_detect_local_cpu (int a
bool arch;
unsigned int l2sizekb = 0;
+ unsigned int arch_64bit = 1;
if (argc < 1)
return NULL;
@@ -656,11 +657,14 @@ const char *host_detect_local_cpu (int a
{
case PROCESSOR_I386:
/* Default. */
+ arch_64bit = 0;
break;
case PROCESSOR_I486:
+ arch_64bit = 0;
cpu = "i486";
break;
case PROCESSOR_PENTIUM:
+ arch_64bit = 0;
if (arch && has_mmx)
cpu = "pentium-mmx";
else
@@ -745,21 +749,25 @@ const char *host_detect_local_cpu (int a
/* Assume Core 2. */
cpu = "core2";
}
- else if (has_sse3)
- /* It is Core Duo. */
- cpu = "pentium-m";
- else if (has_sse2)
- /* It is Pentium M. */
- cpu = "pentium-m";
- else if (has_sse)
- /* It is Pentium III. */
- cpu = "pentium3";
- else if (has_mmx)
- /* It is Pentium II. */
- cpu = "pentium2";
else
- /* Default to Pentium Pro. */
- cpu = "pentiumpro";
+ {
+ arch_64bit = 0;
+ if (has_sse3)
+/* It is Core Duo. */
+cpu = "pentium-m";
+ else if (has_sse2)
+/* It is Pentium M. */
+cpu = "pentium-m";
+ else if (has_sse)
+/* It is Pentium III. */
+cpu = "pentium3";
+ else if (has_mmx)
+/* It is Pentium II. */
+cpu = "pentium2";
+ else
+/* Default to Pentium Pro. */
+cpu = "pentiumpro";
+ }
}
else
/* For -mtune, we default to -mtune=generic. */
@@ -773,21 +781,30 @@ const char *host_detect_local_cpu (int a
if (has_longmode)
cpu = "nocona";
else
-cpu = "prescott";
+{
+ cpu = "prescott";
+ arch_64bit = 0;
+}
}
else
- cpu = "pentium4";
+ {
+ cpu = "pentium4";
+ arch_64bit = 0;
+ }
break;
case PROCESSOR_GEODE:
+ arch_64bit = 0;
cpu = "geode";
break;
case PROCESSOR_K6:
+ arch_64bit = 0;
if (arch && has_3dnow)
cpu = "k6-3";
else
cpu = "k6";
break;
case PROCESSOR_ATHLON:
+ arch_64bit = 0;
if (arch && has_sse)
cpu = "athlon-4";
else
@@ -896,6 +913,10 @@ const char *host_detect_local_cpu (int a
const char *xsavec = has_xsavec ? " -mxsavec" : " -mno-xsavec";
const char *xsaves = has_xsaves ? " -mxsaves" : " -mno-xsaves";
+ /* Assume x86-64 if a 32-bit processor supports SSE2 and 64-bit. */
+ if (arch_64bit == 0 && has_sse2 && has_longmode)
+ cpu = "x86-64";
+
options = concat (options, mmx, mmx3dnow, sse, sse2, sse3, ssse3,
sse4a, cx16, sahf, movbe, aes, sha, pclmul,
popcnt, abm, lwp, fma, fma4, xop, bmi, bmi2,
Re: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
On 06/22/14 01:14, Bernd Edlinger wrote: Hi, I noticed that several testcases in the GMP-4.3.2 test suite are failing now which did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and found the file mpn/generic/get_str.c was miscompiled. It's interesting you stumbled on this. I've seen this issue come and go as well in some of my integration testing work with the trunk. Jeff
Re: [patch i386]: Combine memory and indirect jump
On 06/23/14 08:32, Richard Biener wrote: On Mon, Jun 23, 2014 at 4:13 PM, Richard Henderson wrote: On 06/20/2014 02:59 PM, Kai Tietz wrote: So I suggest following change of passes.def: Index: passes.def === --- passes.def (Revision 211850) +++ passes.def (Arbeitskopie) @@ -384,7 +384,6 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_rtl_dse2); NEXT_PASS (pass_stack_adjustments); NEXT_PASS (pass_jump2); - NEXT_PASS (pass_peephole2); NEXT_PASS (pass_if_after_reload); NEXT_PASS (pass_regrename); NEXT_PASS (pass_cprop_hardreg); @@ -391,6 +390,7 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_fast_rtl_dce); NEXT_PASS (pass_duplicate_computed_gotos); NEXT_PASS (pass_reorder_blocks); + NEXT_PASS (pass_peephole2); NEXT_PASS (pass_branch_target_load_optimize2); NEXT_PASS (pass_leaf_regs); NEXT_PASS (pass_split_before_sched2); Looks good to me. I guess just keep an eye out for bug reports for other ports. Maybe put a comment here because it looks like a random placement to me which would be obvious to revert. peepholing before if-after-reload sounds good anyway. Definitely need a comment on the pass placement. Btw, there is now no DCE after peephole2? Is peephole2 expected to cleanup after itself? There were cases where we wanted to change the insns we would output to fit into the 4:1:1 issue model of the PPro, but to do so we needed to know what registers were live/dead so that we could rewrite the insns appropriately. It didn't fit well into what we could do in the splitters and the old peephole ran too late. Dead code wasn't ever really considered. At least that's my recollection. RTH might recall more. I think it'd be worth an experiment here, but I think that can/should happen independently of Kai's patch. Arguably the scheduler should have all the necessary dataflow information to quickly identify any dead code. Jeff
Re: [PATCH] Trust TREE_ADDRESSABLE
> On June 23, 2014 6:15:10 PM CEST, Jan Hubicka wrote: > >> I don't like this very much. It's fragile and it will be very hard > >to > >> detect bugs caused by it. > >> > >> Please don't spread uses of the DECL_NONALIASED "hack". > >> > >> If we are only concerned about LTO I'd rather have a in_lto_p check > >> in may_be_aliased and trust TREE_ADDRESSABLE there. > > > >I do not like it ether, but I tought it was outcome of the discussion > >to use > >it. > > > >I do not see how in_lto_p helps here, but we probably want to go for > >the > > If we are sure it is correctly set in lto1 it helps. > > >altnerative where ipa-visibility sets TREE_ADDRESSABLE for all external > >variables and then we trust it unconditonally? > > That works for me, too. But at least add a checking assert that > may-be-aliased is not invoked before that. OK, I suppose can check cgraph_state for that (after construction it will be all set). Will prepapre patch tonight. Honza > > Richard. > > > > > >Honza >
[Patch] Not very subtle fix for pr61510
Hi,
pr61510 is a case where cgraphunit.c::analyze_functions can end up
dereferencing a NULL pointer. This is, to me, the obvious way to avoid
dereferencing NULL.
However, I'm not very confident that this isn't just masking some
horrible and subtle bug, so I'd like some review feedback on the patch.
Tested on aarch64-none-elf, where I was seeing the issue.
OK?
Thanks,
James
---
2014-06-19 James Greenhalgh
PR regression/61510
* cgraphunit.c (analyze_functions): Check we have an origin
node before dereferencing it.
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 1b7ab33..82e5a68 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1051,7 +1051,8 @@ analyze_functions (void)
{
struct cgraph_node *origin_node
= cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
- origin_node->used_as_abstract_origin = true;
+ if (origin_node)
+ origin_node->used_as_abstract_origin = true;
}
}
else
Re: calloc = malloc + memset
On Mon, 23 Jun 2014, Richard Biener wrote:
On June 23, 2014 5:51:30 PM CEST, Marc Glisse wrote:
On Mon, 23 Jun 2014, Jakub Jelinek wrote:
Ok for trunk, sorry for the delay.
Thanks. Richard has moved the passes a bit since then, but I still have
exactly one spot where the testsuite is ok :-) I need strlen to be
after
dom (for calloc.C) and before vrp (for several strlenopt-*.c). I'll
commit
it tomorrow if there aren't any comments on the pass placement.
But vrp does not run at -O1 - does strlenopt?
{ OPT_LEVELS_2_PLUS_SPEED_ONLY, OPT_foptimize_strlen, NULL, 1 },
{ OPT_LEVELS_2_PLUS, OPT_ftree_vrp, NULL, 1 },
So that's just a missed optimization at -Os, I guess.
--
Marc Glisse
Re: [PATCH] Trust TREE_ADDRESSABLE
On June 23, 2014 6:15:10 PM CEST, Jan Hubicka wrote: >> I don't like this very much. It's fragile and it will be very hard >to >> detect bugs caused by it. >> >> Please don't spread uses of the DECL_NONALIASED "hack". >> >> If we are only concerned about LTO I'd rather have a in_lto_p check >> in may_be_aliased and trust TREE_ADDRESSABLE there. > >I do not like it ether, but I tought it was outcome of the discussion >to use >it. > >I do not see how in_lto_p helps here, but we probably want to go for >the If we are sure it is correctly set in lto1 it helps. >altnerative where ipa-visibility sets TREE_ADDRESSABLE for all external >variables and then we trust it unconditonally? That works for me, too. But at least add a checking assert that may-be-aliased is not invoked before that. Richard. > >Honza
Re: [PATCH] Trust TREE_ADDRESSABLE
> I don't like this very much. It's fragile and it will be very hard to > detect bugs caused by it. > > Please don't spread uses of the DECL_NONALIASED "hack". > > If we are only concerned about LTO I'd rather have a in_lto_p check > in may_be_aliased and trust TREE_ADDRESSABLE there. I do not like it ether, but I tought it was outcome of the discussion to use it. I do not see how in_lto_p helps here, but we probably want to go for the altnerative where ipa-visibility sets TREE_ADDRESSABLE for all external variables and then we trust it unconditonally? Honza
Re: calloc = malloc + memset
On June 23, 2014 5:51:30 PM CEST, Marc Glisse wrote: >On Mon, 23 Jun 2014, Jakub Jelinek wrote: > >> Ok for trunk, sorry for the delay. > >Thanks. Richard has moved the passes a bit since then, but I still have > >exactly one spot where the testsuite is ok :-) I need strlen to be >after >dom (for calloc.C) and before vrp (for several strlenopt-*.c). I'll >commit >it tomorrow if there aren't any comments on the pass placement. But vrp does not run at -O1 - does strlenopt? >2014-06-24 Marc Glisse > > PR tree-optimization/57742 >gcc/ > * tree-ssa-strlen.c (get_string_length): Ignore malloc. > (handle_builtin_malloc, handle_builtin_memset): New functions. > (strlen_optimize_stmt): Call them. > * passes.def: Move strlen after loop+dom but before vrp. >gcc/testsuite/ > * g++.dg/tree-ssa/calloc.C: New testcase. > * gcc.dg/tree-ssa/calloc-1.c: Likewise. > * gcc.dg/tree-ssa/calloc-2.c: Likewise. > * gcc.dg/strlenopt-9.c: Adapt.
Re: [AArch64] Implement ADD in vector registers for 32-bit scalar values.
On Mon, Jun 23, 2014 at 01:53:28PM +0100, Kyrill Tkachov wrote: > On 19/06/14 14:12, James Greenhalgh wrote: > > diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md > > >index > > >266d7873a5a1b8dbb7f955c3f13cf370920a9c4a..7c5b5a566ebfd907b83b38eed2e214738e7e9bd4 > > > 100644 > > >--- a/gcc/config/aarch64/aarch64.md > > >+++ b/gcc/config/aarch64/aarch64.md > > >@@ -1068,16 +1068,17 @@ (define_expand "add3" > > > > > > (define_insn "*addsi3_aarch64" > > >[(set > > >-(match_operand:SI 0 "register_operand" "=rk,rk,rk") > > >+(match_operand:SI 0 "register_operand" "=rk,rk,w,rk") > > > (plus:SI > > >- (match_operand:SI 1 "register_operand" "%rk,rk,rk") > > >- (match_operand:SI 2 "aarch64_plus_operand" "I,r,J")))] > > >+ (match_operand:SI 1 "register_operand" "%rk,rk,w,rk") > > >+ (match_operand:SI 2 "aarch64_plus_operand" "I,r,w,J")))] > > >"" > > >"@ > > >add\\t%w0, %w1, %2 > > >add\\t%w0, %w1, %w2 > > >+ add\\t%0.2s, %1.2s, %2.2s > > >sub\\t%w0, %w1, #%n2" > > >- [(set_attr "type" "alu_imm,alu_reg,alu_imm")] > > >+ [(set_attr "type" "alu_imm,alu_reg,neon_add,alu_imm")] > > > ) > > > > Minor nit, you should set the "simd" attribute to yes for the added > alternative to make sure it doesn't get selected when !TARGET_SIMD Hi Kyrill, Thanks, you are of course correct. I wouldn't call this a minor nit though, if we were unlucky, it could easily break a kernel build in some subtle and annoying way! Good catch! I've committed the attached as obvious as revision 211899 after testing on aarch64-none-elf. Thanks, James --- gcc/ 2014-06-23 James Greenhalgh * config/aarch64/aarch64.md (addsi3_aarch64): Set "simd" attr to "yes" where needed. diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index 5f5b4ff..8705ee9 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -1167,7 +1167,8 @@ add\\t%w0, %w1, %w2 add\\t%0.2s, %1.2s, %2.2s sub\\t%w0, %w1, #%n2" - [(set_attr "type" "alu_imm,alu_reg,neon_add,alu_imm")] + [(set_attr "type" "alu_imm,alu_reg,neon_add,alu_imm") + (set_attr "simd" "*,*,yes,*")] ) ;; zero_extend version of above
Re: [PATCH] Fix 61565 -- cmpelim vs non-call exceptions
On 23/06/14 15:01, Richard Henderson wrote: On 06/23/2014 02:29 AM, Ramana Radhakrishnan wrote: On 20/06/14 21:28, Richard Henderson wrote: There aren't too many users of the cmpelim pass, and previously they were all small embedded targets without an FPU. I'm a bit surprised that Ramana decided to enable this pass for aarch64, as that target is not so limited as the block comment for the pass describes. Honestly, whatever is being deleted here ought to have been found earlier, either via combine or cse. We ought to find out why any changes are made during this pass for aarch64. Agreed - Going back and looking at my notes I remember seeing a difference in code generation with the elimination of a number of compares that prompted me to turn this on in a number of benchmarks. I don't remember double checking why CSE hadn't removed that at that time. This also probably explains the equivalent patch for ARM and Thumb2 hasn't shown demonstrable differences. Investigating this pass for Thumb1 may be interesting. Isn't it true that thumb1 has only "adds r,r,#i" not "add r,r,#i"? Lack of an addition that doesn't clobber the flags is one of the two reasons why you'd want to enable the cmpelim pass. Agreed, this is why cmpelim looks interesting for Thumb1. (We may need another hook or something to disable it in configurations we don't need it in, but you know ... ) Although for thumb1, can't you achieve a no-clobber addition with an IT block with an "always" condition? Except that IT instructions aren't in Thumb1 or indeed v6-m :(. Seems like a good use for the "addptr" pattern that Andreas Krebbel recently added for s390. That might let you make thumb1 look more like the rest of the arm port and emit separate compare and branch instructions from the start. regards Ramana r~
Re: calloc = malloc + memset
On Mon, 23 Jun 2014, Jakub Jelinek wrote:
Ok for trunk, sorry for the delay.
Thanks. Richard has moved the passes a bit since then, but I still have
exactly one spot where the testsuite is ok :-) I need strlen to be after
dom (for calloc.C) and before vrp (for several strlenopt-*.c). I'll commit
it tomorrow if there aren't any comments on the pass placement.
2014-06-24 Marc Glisse
PR tree-optimization/57742
gcc/
* tree-ssa-strlen.c (get_string_length): Ignore malloc.
(handle_builtin_malloc, handle_builtin_memset): New functions.
(strlen_optimize_stmt): Call them.
* passes.def: Move strlen after loop+dom but before vrp.
gcc/testsuite/
* g++.dg/tree-ssa/calloc.C: New testcase.
* gcc.dg/tree-ssa/calloc-1.c: Likewise.
* gcc.dg/tree-ssa/calloc-2.c: Likewise.
* gcc.dg/strlenopt-9.c: Adapt.
--
Marc GlisseIndex: gcc/passes.def
===
--- gcc/passes.def (revision 211886)
+++ gcc/passes.def (working copy)
@@ -179,21 +179,20 @@ along with GCC; see the file COPYING3.
DOM and erroneous path isolation should be due to degenerate PHI nodes.
So rather than run the full propagators, run a specialized pass which
only examines PHIs to discover const/copy propagation
opportunities. */
NEXT_PASS (pass_phi_only_cprop);
NEXT_PASS (pass_dse);
NEXT_PASS (pass_reassoc);
NEXT_PASS (pass_dce);
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_phiopt);
- NEXT_PASS (pass_strlen);
NEXT_PASS (pass_ccp);
/* After CCP we rewrite no longer addressed locals into SSA
form if possible. */
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_cse_sincos);
NEXT_PASS (pass_optimize_bswap);
NEXT_PASS (pass_split_crit_edges);
NEXT_PASS (pass_pre);
NEXT_PASS (pass_sink_code);
NEXT_PASS (pass_asan);
@@ -232,20 +231,21 @@ along with GCC; see the file COPYING3.
NEXT_PASS (pass_loop_prefetch);
NEXT_PASS (pass_iv_optimize);
NEXT_PASS (pass_lim);
NEXT_PASS (pass_tree_loop_done);
POP_INSERT_PASSES ()
NEXT_PASS (pass_lower_vector_ssa);
NEXT_PASS (pass_cse_reciprocals);
NEXT_PASS (pass_reassoc);
NEXT_PASS (pass_strength_reduction);
NEXT_PASS (pass_dominator);
+ NEXT_PASS (pass_strlen);
NEXT_PASS (pass_vrp);
/* The only const/copy propagation opportunities left after
DOM and VRP should be due to degenerate PHI nodes. So rather than
run the full propagators, run a specialized pass which
only examines PHIs to discover const/copy propagation
opportunities. */
NEXT_PASS (pass_phi_only_cprop);
NEXT_PASS (pass_cd_dce);
NEXT_PASS (pass_tracer);
NEXT_PASS (pass_dse);
Index: gcc/testsuite/g++.dg/tree-ssa/calloc.C
===
--- gcc/testsuite/g++.dg/tree-ssa/calloc.C (revision 0)
+++ gcc/testsuite/g++.dg/tree-ssa/calloc.C (working copy)
@@ -0,0 +1,50 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-optimized" } */
+
+typedef __SIZE_TYPE__ size_t;
+inline void* operator new(size_t, void* p) throw() { return p; }
+
+typedef void (*handler_t)(void);
+extern handler_t get_handle();
+
+inline void* operator new(size_t sz)
+{
+ void *p;
+
+ if (sz == 0)
+sz = 1;
+
+ while ((p = __builtin_malloc (sz)) == 0)
+{
+ handler_t handler = get_handle ();
+ if (! handler)
+throw 42;
+ handler ();
+}
+ return p;
+}
+
+struct vect {
+ int *start, *end;
+ vect(size_t n) {
+start = end = 0;
+if (n > (size_t)-1 / sizeof(int))
+ throw 33;
+if (n != 0)
+ start = static_cast (operator new (n * sizeof(int)));
+end = start + n;
+int *p = start;
+for (size_t l = n; l > 0; --l, ++p)
+ *p = 0;
+ }
+};
+
+void f (void *p, int n)
+{
+ new (p) vect(n);
+}
+
+/* { dg-final { scan-tree-dump-times "calloc" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-not "malloc" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "memset" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/strlenopt-9.c
===
--- gcc/testsuite/gcc.dg/strlenopt-9.c (revision 211886)
+++ gcc/testsuite/gcc.dg/strlenopt-9.c (working copy)
@@ -11,21 +11,21 @@ fn1 (int r)
optimized away. */
return strchr (p, '\0');
}
__attribute__((noinline, noclone)) size_t
fn2 (int r)
{
char *p, q[10];
strcpy (q, "abc");
p = r ? "a" : q;
- /* String length for p varies, therefore strlen below isn't
+ /* String length is constant for both alternatives, and strlen is
optimized away. */
return strlen (p);
}
__attribute__((noinline, noclone)) size_t
fn3 (char *p, int n)
{
int i;
[Patch, AArch64] Restructure arm_neon.h vector types' implementation.
Hi,
Here is a patch that restructures neon builtins to use vector types based on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using gcc's front-end vector extensions. We now move away from
that and use types built internally(e.g. __Int8x8_t). These internal types names
are defined by the AAPCS64 and we build arm_neon.h's public vector types over
these internal types. e.g.
typedef __Int8x8_t int8x8_t;
as opposed to
typedef __builtin_aarch64_simd_qi int8x8_t
__attribute__ ((__vector_size__ (8)));
Impact on mangling:
This patch does away with these builtin scalar types that the vector types were
based on. These were previously used to look up mangling names. We now use the
internal vector type names(e.g. __Int8x8_t) to lookup mangling for the
arm_neon.h-exported vector types. There are a few internal scalar
types(__builtin_aarch64_simd_oi etc.) that is needed to efficiently implement
some NEON Intrinsics. These will be declared in the back-end and registered in
the front-end and aarch64-specific builtin types, but are not user-visible.
These, along with a few scalar __builtin types that aren't user-visible will
have implementation-defined mangling. Because we don't have strong-typing across
all builtins yet, we still have to maintain the old builtin scalar types - they
will be removed once we move over to a strongly-typed builtin system implemented
by the qualifier infrastructure.
Marc Glisse's patch in this thread exposed this issue
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html. I've tested my patch
with the change that his patch introduced, and it seems to work fine -
specifically these two lines:
+ for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
+emit_support_tinfo_1 (TREE_VALUE (t));
Regressed on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
gcc/Changelog
2014-06-23 Tejas Belagod
* config/aarch64/aarch64-builtins.c (aarch64_build_scalar_type): Remove.
(aarch64_scalar_builtin_types, aarch64_simd_type, aarch64_simd_types,
aarch64_mangle_builtin_scalar_type, aarch64_mangle_builtin_vector_type,
aarch64_mangle_builtin_type, aarch64_simd_builtin_std_type,
aarch64_lookup_simd_builtin_type, aarch64_simd_builtin_type,
aarch64_init_simd_builtin_types,
aarch64_init_simd_builtin_scalar_types): New.
(aarch64_init_simd_builtins): Refactor.
(aarch64_fold_builtin): Remove redundant defn.
(aarch64_init_crc32_builtins): Use aarch64_simd_builtin_std_type.
* config/aarch64/aarch64-simd-builtin-types.def: New.
* config/aarch64/t-aarch64: Add aarch64-simd-builtin-types.def
dependency.
* config/aarch64/aarch64-protos.h (aarch64_mangle_builtin_type): Export.
* config/aarch64/aarch64-simd-builtins.def: Remove duplicates.
* config/aarch64/aarch64.c (aarch64_simd_mangle_map): Remove.
(aarch64_mangle_type): Refactor.
* config/aarch64/arm_neon.h: Declare vector types based on internal
type-names.diff --git a/gcc/config/aarch64/aarch64-builtins.c
b/gcc/config/aarch64/aarch64-builtins.c
index a94ef52..1119f33 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -471,256 +471,331 @@ static GTY(()) tree
aarch64_builtin_decls[AARCH64_BUILTIN_MAX];
#define NUM_DREG_TYPES 6
#define NUM_QREG_TYPES 6
-/* Return a tree for a signed or unsigned argument of either
- the mode specified by MODE, or the inner mode of MODE. */
-tree
-aarch64_build_scalar_type (enum machine_mode mode,
- bool unsigned_p,
- bool poly_p)
-{
-#undef INT_TYPES
-#define INT_TYPES \
- AARCH64_TYPE_BUILDER (QI) \
- AARCH64_TYPE_BUILDER (HI) \
- AARCH64_TYPE_BUILDER (SI) \
- AARCH64_TYPE_BUILDER (DI) \
- AARCH64_TYPE_BUILDER (EI) \
- AARCH64_TYPE_BUILDER (OI) \
- AARCH64_TYPE_BUILDER (CI) \
- AARCH64_TYPE_BUILDER (XI) \
- AARCH64_TYPE_BUILDER (TI) \
-
-/* Statically declare all the possible types we might need. */
-#undef AARCH64_TYPE_BUILDER
-#define AARCH64_TYPE_BUILDER(X) \
- static tree X##_aarch64_type_node_p = NULL; \
- static tree X##_aarch64_type_node_s = NULL; \
- static tree X##_aarch64_type_node_u = NULL;
-
- INT_TYPES
-
- static tree float_aarch64_type_node = NULL;
- static tree double_aarch64_type_node = NULL;
-
- gcc_assert (!VECTOR_MODE_P (mode));
-
-/* If we've already initialised this type, don't initialise it again,
- otherwise ask for a new type of the correct size. */
-#undef AARCH64_TYPE_BUILDER
-#define AARCH64_TYPE_BUILDER(X) \
- case X##mode: \
-if (unsigned_p) \
- return (X##_aarch64_type_node_u \
- ? X##_aarch64_type_node_u \
- : X##_aarch64_type_node_u \
- = make_unsigned_type (GET_MODE_PRECISION (mode))); \
-else if (poly_p) \
- return (X##_aarch64_type_node_p \
- ? X##_aarch64_type_no
PR61583, stage2 and stage3 compare failure due to value range loss
This fixes a bootstrap compare failure on current mainline and 4.9
branch configured with --disable-checking, caused by losing value
range info when outputting debug info. Lack of value range info leads
to loop bounds not being calculated, which in turn means a "j < n"
test is not converted to "j != n". Details in the PR.
Bootstrapped and regression tested powerpc64-linux, and committed
with Jakub's approval.
gcc/
PR bootstrap/61583
* tree-vrp.c (remove_range_assertions): Do not set is_unreachable
to zero on debug statements.
gcc/testsuite/
* gcc.dg/pr61583.c: New.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 211886)
+++ gcc/tree-vrp.c (working copy)
@@ -6523,8 +6523,9 @@ remove_range_assertions (void)
}
else
{
+ if (!is_gimple_debug (gsi_stmt (si)))
+ is_unreachable = 0;
gsi_next (&si);
- is_unreachable = 0;
}
}
}
Index: gcc/testsuite/gcc.dg/pr61583.c
===
--- gcc/testsuite/gcc.dg/pr61583.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr61583.c (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcompare-debug" } */
+
+void
+f1 (int n, int b)
+{
+ extern void f2 (int);
+ int j;
+
+ if (b)
+n = 1;
+
+ if (n < 1)
+__builtin_unreachable ();
+
+ for (j = 0; j < n; j++)
+f2 (j);
+}
--
Alan Modra
Australia Development Lab, IBM
Re: [C++ Patch] PR 33101
On 06/22/2014 10:42 AM, Paolo Carlini wrote: I think the below would be most of it. Today, however, I did some archeology, noticed that we would essentially revert to pre-PR9278 behavior (thus, per its audit trail, make again unhappy some people in the template metaprogramming world?!? Was that known to Core when DR577 got resolved?) It seems to me that the metaprogrammers wanted the typedef to be accepted, so this would make them happier. The patch is OK. Jason
Link not working on www.mail-archive.com
Looks like there is a broken link on http://www.mail-archive.com/ftikumt2001@yahoogroups.com/msg00234.html to http://www.cs.cmu.edu/books.html. You might also want to add some of these resources I found useful... http://online.sju.edu/resource/engineering-technology/trends-in-instructional-design-and-elearning-solutions http://thejournal.com/articles/2013/12/13/the-10-biggest-trends-in-ed-tech.aspx Thanks! ~lisa
[PATCH] gcc: fix segfault from calling free on non-malloc'd area
We see the following on a 32bit gcc installed on 64 bit host:
Reading symbols from ./i586-pokymllib32-linux-gcc...done.
(gdb) run
Starting program:
x86-pokymllib32-linux/lib32-gcc/4.9.0-r0/image/usr/bin/i586-pokymllib32-linux-gcc
Program received signal SIGSEGV, Segmentation fault.
0xf7e957e0 in free () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt
#0 0xf7e957e0 in free () from /lib/i386-linux-gnu/libc.so.6
#1 0x0804b73c in set_multilib_dir () at gcc-4.9.0/gcc/gcc.c:7827
#2 main (argc=1, argv=0xd504) at gcc-4.9.0/gcc/gcc.c:6688
(gdb)
The problem arises because the check on whether we are using
the internal string "." or an allocated one is reversed.
We should be calling free() when the string is not equal to
the internal "." string.
Signed-off-by: Paul Gortmaker
---
[Found and fixed on gcc-4.9.0 but applies to git/master too]
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6870a840e1b7..a580975a7057 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -7822,7 +7822,7 @@ set_multilib_dir (void)
}
if (multilib_dir == NULL && multilib_os_dir != NULL
- && strcmp (multilib_os_dir, ".") == 0)
+ && strcmp (multilib_os_dir, ".") != 0)
{
free (CONST_CAST (char *, multilib_os_dir));
multilib_os_dir = NULL;
--
1.9.1
Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests
On 11 June 2014 00:03, Ramana Radhakrishnan wrote: > On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon > wrote: >> This is patch series is a more complete version of the patch I sent >> some time ago: >> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html >> >> I have created a series of patches to help review. The 1st one adds >> some documentation, the common .h files defining helpers used in the >> actual tests, and two real tests (vaba and vld1) to show how the >> various macros are used. >> >> The next patches add other tests (grouped when they use a common >> framework). >> >> Looking at the .exp file, you'll notice that the tests are performed twice: >> * once using c-torture-execute to make sure they execute correctly >> under various levels of optimization. In this case dejagnu >> directives embedded in each .c test file are ignored. >> >> * once using gcc-dg-runtest, which enables compiling with various >> optimization levels and scanning the generated assembly for some >> code sequences. Currently, only the vadd test contains some >> scan-assembler-times directives, as an example. We can add such >> directives to other tests later. > >> >> Regarding the results of these tests on target >> arm-none-linux-gnueabihf, note that: >> * vclz tests currently fail at optimization levels starting with -O1 >> * vqadd test fails when compiled with -Os >> * vadd scan-assembler fails for vadd.i64 (because the compiler uses >> core registers instead of Neon ones. Not sure if this should be >> considered as a bug or if the test should be changed) >> * this gives 1164 PASS and 18 FAIL >> > > I am a bit ambivalent between getting folks to add scan-assembler > tests here and worrying between this and getting the behaviour > correct. Additionally if you add the complexity of scanning for > aarch64 as well this starts getting messy. > > At this point I'm going to wait to see if any of the testsuite > maintainers step in and comment and if not I'll start looking at this > properly early next week. > > regards > Ramana > Hi Ramana, Did you have time to look at this patch series? Thanks > >> I have not looked at the results in detail on other arm* and aarch64* >> targets, but there are some other failures. >> >> I have many more tests to convert (currently 40 done, 96 remain), and >> my plan is to work on the rest once this set has been accepted. >> >> As of the ChangeLog entry, this patch only adds new files in >> testsuite/gcc.target/arm/neon-intrinsics (which is new too). >> >> OK for trunk? >> >> Thanks, >> >> Christophe. >> >> Christophe Lyon (22): >> Neon intrinsics execution tests initial framework. >> Add unary operators: vabs and vneg. >> Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub. >> Add comparison operators: vceq, vcge, vcgt, vcle and vclt. >> Add comparison operators with floating-point operands: vcage, vcagt, >> vcale and cvalt. >> Add unary saturating operators: vqabs and vqneg. >> Add binary saturating operators: vqadd, vqsub. >> Add vabal tests. >> Add vabd tests. >> Add vabdl tests. >> Add vaddhn tests. >> Add vaddl tests. >> Add vaddw tests. >> Add vbsl tests. >> Add vclz tests. >> Add vdup and vmov tests. >> Add vld1_dup tests. >> Add vld2/vld3/vld4 tests. >> Add vld2_lane, vld3_lane and vld4_lane tests. >> Add vmul tests. >> Add vshl tests. >> Add vuzp and vzip tests.
Re: [C/C++ PATCH] Add -Wlogical-not-parentheses (PR c/49706)
On Mon, 23 Jun 2014, Marek Polacek wrote: > I think the latter is better, incidentally, g++ doesn't warn either. > The following one liner makes cc1 behave as cc1plus. Thanks for the > report. > > Regtested/bootstrapped on x86_64. Joseph, is this ok? > > 2014-06-23 Marek Polacek > > * c-typeck.c (parser_build_binary_op): Don't call > warn_logical_not_parentheses if the RHS is TRUTH_NOT_EXPR. > > * c-c++-common/pr49706-2.c: New test. OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fix arrays in rtx.u + add minor rtx verification
On Mon, Jun 23, 2014 at 4:25 PM, Richard Henderson wrote:
> On 06/20/2014 01:42 PM, Marek Polacek wrote:
>> 2014-06-20 Marek Polacek
>>
>> * genpreds.c (verify_rtx_codes): New function.
>> (main): Call it.
>> * rtl.h (RTX_FLD_WIDTH, RTX_HWINT_WIDTH): Define.
>> (struct rtx_def): Use them.
>
> Looks pretty good. Just a few nits.
>
>> +static void
>> +verify_rtx_codes (void)
>> +{
>> + unsigned int i, j;
>> +
>> + for (i = 0; i < NUM_RTX_CODE; i++)
>> +if (strchr (GET_RTX_FORMAT (i), 'w') == NULL)
>> + {
>> + if (strlen (GET_RTX_FORMAT (i)) > RTX_FLD_WIDTH)
>> + internal_error ("%s format %s longer than RTX_FLD_WIDTH %d\n",
>> + GET_RTX_NAME (i), GET_RTX_FORMAT (i),
>> + (int) RTX_FLD_WIDTH);
>> + }
>> +else
>> + {
>> + const size_t len = strlen (GET_RTX_FORMAT (i));
>
> The strlen result is used in both arms of the if. Tidier to hoist it, I
> think.
>
>> + for (j = 0; j < len; j++)
>> + if (GET_RTX_FORMAT (i)[j] != 'w')
>> + internal_error ("%s format %s should contain only w, but "
>> + "has %c\n", GET_RTX_NAME (i), GET_RTX_FORMAT (i),
>> + GET_RTX_FORMAT (i)[j]);
>
> The loop is strspn. Perhaps tidier as
>
> const size_t spn = strspn(GET_RTX_FORMAT (i), "w");
> if (spn != len)
> internal_error (...);
Note that RTX_HWINT_WIDTH is wrong because of CONST_WIDE_INT.
Also I don't like increasing the array sizes - this is wrong in the same
way as [1] is.
Can we instead refactor expmed.c to avoid allocating rtx_def directly?
Like by using rtx in init_expmed_rtl and allocating from an obstack
(or not care and GC-allocate anyway).
Richard.
>
> r~
>
[PATCH] Don't segv on __atomic_store (PR c/61553)
We ICEd on the following testcase since the void type has a NULL
TYPE_SIZE_UNIT. I took Andrew's patch from gcc@ ML and added
a testcase.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-06-23 Marek Polacek
Andrew MacLeod
PR c/61553
* c-common.c (get_atomic_generic_size): Don't segfault if the
type doesn't have a size.
* c-c++-common/pr61553.c: New test.
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 077263e..087f036 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -10471,7 +10471,8 @@ get_atomic_generic_size (location_t loc, tree function,
function);
return 0;
}
- size = tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (type)));
+ tree type_size = TYPE_SIZE_UNIT (TREE_TYPE (type));
+ size = type_size ? tree_to_uhwi (type_size) : 0;
if (size != size_0)
{
error_at (loc, "size mismatch in argument %d of %qE", x + 1,
diff --git gcc/testsuite/c-c++-common/pr61553.c
gcc/testsuite/c-c++-common/pr61553.c
index e69de29..fa97e94 100644
--- gcc/testsuite/c-c++-common/pr61553.c
+++ gcc/testsuite/c-c++-common/pr61553.c
@@ -0,0 +1,8 @@
+/* PR c/61553 */
+/* { dg-do compile } */
+
+void
+foo (char *s)
+{
+ __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST);
+}
Marek
Re: [GSoC][match-and-simplify] mark some more operators as commutative
On Mon, Jun 23, 2014 at 4:23 PM, Marc Glisse wrote: > On Mon, 23 Jun 2014, Richard Biener wrote: > >> On Mon, Jun 23, 2014 at 3:32 PM, Prathamesh Kulkarni >> wrote: >>> >>> * match.pd: Mark operators in some bitwise and plus-minus >>> patterns to be commutative. >> >> >> /* A - (A +- B) -> -+ B */ >> (match_and_simplify >> - (minus @0 (plus @0 @1)) >> + (minus @0 (plus:c @0 @1)) >> (negate @0)) >> >> seems pointless > > > Why? a-(a+b) and a-(b+a) are both wanted and don't appear elsewhere in the > file, no? Should simplify to (negate @1) though. Ah, indeed. So here commutation doesn't work because of correctness. Richard. > -- > Marc Glisse
Re: [GSoC][match-and-simplify] Remove gen_gimple_match_fail
On Mon, Jun 23, 2014 at 3:43 PM, Prathamesh Kulkarni wrote: > * genmatch.c (gen_gimple_match_fail): Remove. > (expr::gen_gimple_transform): Remove call to gen_gimple_match_fail. > Change fprintf (f, "if (!res)") to fprintf (f, "if (!res) return > false;\n") Thanks, committed. Richard. > Thanks and Regards, > Prathamesh
Re: [patch i386]: Combine memory and indirect jump
On Mon, Jun 23, 2014 at 4:13 PM, Richard Henderson wrote: > On 06/20/2014 02:59 PM, Kai Tietz wrote: >> So I suggest following change of passes.def: >> >> Index: passes.def >> === >> --- passes.def (Revision 211850) >> +++ passes.def (Arbeitskopie) >> @@ -384,7 +384,6 @@ along with GCC; see the file COPYING3. If not see >> NEXT_PASS (pass_rtl_dse2); >> NEXT_PASS (pass_stack_adjustments); >> NEXT_PASS (pass_jump2); >> - NEXT_PASS (pass_peephole2); >> NEXT_PASS (pass_if_after_reload); >> NEXT_PASS (pass_regrename); >> NEXT_PASS (pass_cprop_hardreg); >> @@ -391,6 +390,7 @@ along with GCC; see the file COPYING3. If not see >> NEXT_PASS (pass_fast_rtl_dce); >> NEXT_PASS (pass_duplicate_computed_gotos); >> NEXT_PASS (pass_reorder_blocks); >> + NEXT_PASS (pass_peephole2); >> NEXT_PASS (pass_branch_target_load_optimize2); >> NEXT_PASS (pass_leaf_regs); >> NEXT_PASS (pass_split_before_sched2); > > Looks good to me. I guess just keep an eye out for bug reports for other > ports. Maybe put a comment here because it looks like a random placement to me which would be obvious to revert. peepholing before if-after-reload sounds good anyway. Did you test effect on code-generation of this change on other targets? Btw, there is now no DCE after peephole2? Is peephole2 expected to cleanup after itself? Richard. > > r~
[AArch64] Implement some vca*_f[32,64] intrinsics
Hi all,
This patch implements some absolute compare intrinsics in arm_neon.h.
Execution tests are added.
Tested aarch64-none-elf, aarch64_be-none-elf, bootstrapped on aarch64 linux
Ok for trunk?
2014-06-23 Kyrylo Tkachov
* config/aarch64/arm_neon.h (vcage_f64): New intrinsic.
(vcagt_f64): Likewise.
(vcale_f64): Likewise.
(vcaled_f64): Likewise.
(vcales_f32): Likewise.
(vcalt_f64): Likewise.
(vcaltd_f64): Likewise.
(vcalts_f32): Likewise.
2014-06-23 Kyrylo Tkachov
* gcc.target/aarch64/simd/vcage_f64.c: New test.
* gcc.target/aarch64/simd/vcagt_f64.c: Likewise.
* gcc.target/aarch64/simd/vcale_f64.c: Likewise.
* gcc.target/aarch64/simd/vcaled_f64.c: Likewise.
* gcc.target/aarch64/simd/vcales_f32.c: Likewise.
* gcc.target/aarch64/simd/vcalt_f64.c: Likewise.
* gcc.target/aarch64/simd/vcaltd_f64.c: Likewise.
* gcc.target/aarch64/simd/vcalts_f32.c: Likewise.commit f87169afe8bd853b4aa5ab3ed5e270de0cb95461
Author: Kyrylo Tkachov
Date: Thu Jun 19 09:37:54 2014 +0100
[AArch64] Implement vc* intrinsics
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 0ff6996..8fa469a 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -13823,6 +13823,12 @@ vaesimcq_u8 (uint8x16_t data)
/* vcage */
+__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
+vcage_f64 (float64x1_t __a, float64x1_t __b)
+{
+ return vabs_f64 (__a) >= vabs_f64 (__b);
+}
+
__extension__ static __inline uint32_t __attribute__ ((__always_inline__))
vcages_f32 (float32_t __a, float32_t __b)
{
@@ -13867,6 +13873,12 @@ vcagt_f32 (float32x2_t __a, float32x2_t __b)
return vabs_f32 (__a) > vabs_f32 (__b);
}
+__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
+vcagt_f64 (float64x1_t __a, float64x1_t __b)
+{
+ return vabs_f64 (__a) > vabs_f64 (__b);
+}
+
__extension__ static __inline uint32x4_t __attribute__ ((__always_inline__))
vcagtq_f32 (float32x4_t __a, float32x4_t __b)
{
@@ -13893,6 +13905,24 @@ vcale_f32 (float32x2_t __a, float32x2_t __b)
return vabs_f32 (__a) <= vabs_f32 (__b);
}
+__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
+vcale_f64 (float64x1_t __a, float64x1_t __b)
+{
+ return vabs_f64 (__a) <= vabs_f64 (__b);
+}
+
+__extension__ static __inline uint64_t __attribute__ ((__always_inline__))
+vcaled_f64 (float64_t __a, float64_t __b)
+{
+ return __builtin_fabs (__a) <= __builtin_fabs (__b) ? -1 : 0;
+}
+
+__extension__ static __inline uint32_t __attribute__ ((__always_inline__))
+vcales_f32 (float32_t __a, float32_t __b)
+{
+ return __builtin_fabsf (__a) <= __builtin_fabsf (__b) ? -1 : 0;
+}
+
__extension__ static __inline uint32x4_t __attribute__ ((__always_inline__))
vcaleq_f32 (float32x4_t __a, float32x4_t __b)
{
@@ -13913,6 +13943,18 @@ vcalt_f32 (float32x2_t __a, float32x2_t __b)
return vabs_f32 (__a) < vabs_f32 (__b);
}
+__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
+vcalt_f64 (float64x1_t __a, float64x1_t __b)
+{
+ return vabs_f64 (__a) < vabs_f64 (__b);
+}
+
+__extension__ static __inline uint64_t __attribute__ ((__always_inline__))
+vcaltd_f64 (float64_t __a, float64_t __b)
+{
+ return __builtin_fabs (__a) < __builtin_fabs (__b) ? -1 : 0;
+}
+
__extension__ static __inline uint32x4_t __attribute__ ((__always_inline__))
vcaltq_f32 (float32x4_t __a, float32x4_t __b)
{
@@ -13925,6 +13967,12 @@ vcaltq_f64 (float64x2_t __a, float64x2_t __b)
return vabsq_f64 (__a) < vabsq_f64 (__b);
}
+__extension__ static __inline uint32_t __attribute__ ((__always_inline__))
+vcalts_f32 (float32_t __a, float32_t __b)
+{
+ return __builtin_fabsf (__a) < __builtin_fabsf (__b) ? -1 : 0;
+}
+
/* vceq - vector. */
__extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/vcage_f64.c b/gcc/testsuite/gcc.target/aarch64/simd/vcage_f64.c
new file mode 100644
index 000..67dc8ae
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/simd/vcage_f64.c
@@ -0,0 +1,42 @@
+/* Test the vcage_f64 AArch64 SIMD intrinsic. */
+
+/* { dg-do run } */
+/* { dg-options "-save-temps -O3" } */
+
+#include "arm_neon.h"
+#include
+
+#define SIZE 6
+
+extern void abort (void);
+
+volatile float64_t in[SIZE] = { -10.4, -3.14, 0.0, 1.5, 5.3, 532.3 };
+
+int
+main (void)
+{
+ uint64_t expected;
+ uint64_t actual;
+ float64x1_t arg1, arg2;
+ int i, j;
+
+ for (i = 0; i < SIZE; ++i)
+ for (j = 0; j < SIZE; ++j)
+ {
+expected = __builtin_fabs (in[i]) >= __builtin_fabs (in[j]) ? -1 : 0;
+arg1 = (float64x1_t) { in[i] };
+arg2 = (float64x1_t) { in[j] };
+actual = vget_lane_u64 (vcage_f64 (arg1, arg2), 0);
+
+if (actual != expected)
+ {
+fprintf (stderr, "Expected: %ld, got %ld\n", expected, actual);
+abort ();
+ }
+ }
+
+ return 0;
+
RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
Hi, On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: > > On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger > wrote: >> Hi, >> >> I noticed that several testcases in the GMP-4.3.2 test suite are failing now >> which >> did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and >> found >> the file mpn/generic/get_str.c was miscompiled. >> >> mpn/get_str.c.132t.dse2: >> pretmp_183 = (sizetype) chars_per_limb_80; >> pretmp_184 = -pretmp_183; >> _23 = chars_per_limb_80 + 4294967295; >> _68 = (sizetype) _23; >> _28 = _68 + pretmp_184; >> >> mpn/get_str.c.133t.forwprop4: >> _28 = 4294967295; >> >> >> That is wrong, because chars_per_limb is unsigned, and it is not zero. >> So the right result should be -1. This makes the loop termination in that >> function fail. >> >> The reason for this is in this check-in: >> >> r210807 | ebotcazou | 2014-05-22 16:32:56 +0200 (Thu, 22 May 2014) | 3 lines >> >> * tree-ssa-forwprop.c (associate_plusminus): Extend (T)(P + A) - (T)P >> -> (T)A transformation to integer types. >> >> >> Because it implicitly assumes that integer overflow is not allowed with all >> types, >> including unsigned int. > > Hmm? But the transform is correct if overflow wraps. And it's correct if > overflow is undefined as well, as (T)A is always well-defined (implementation > defined) if it is a truncation. > we have no problem when the cast from (P + A) to T is a truncation, except if the add operation P + A is saturating. > So we match the above an try to transform it to (T)P + (T)A - (T)P. That's > wrong if the conversion is extending I think. > Yes, in a way. But OTOH, Eric's test case opt37.adb, fails if we simply punt here. Fortunately, with opt37.adb, P and A are signed 32-bit integers, and T is size_t (64 bit) and because the overflow of P + A causes undefined behaviour, we can assume that P + A _did_ not overflow, and therefore the transformation (T)(P + A) == (T)P + (T)A is correct (but needs a strict overflow warning), and we still can use the pattern (T)P + (T)A - (T)P -> (T)A in this case. But we cannot use this transformation, as the attached test case demonstrates when P + A is done in unsigned integers, because the result of the addition is different if it is done in unsigned int with allowed overflow, or in long without overflow. > Richard. > > >> >> The attached patch fixes these regressions, and because the reasoning depends >> on the TYPE_OVERFLOW_UNDEFINED attribute, a strict overflow warning has to be >> emitted here, at least for widening conversions. >> >> >> Boot-strapped and regression-tested on x86_64-linux-gnu with all languages, >> including Ada. >> OK for trunk? > > + if (!TYPE_SATURATING (TREE_TYPE (a)) > > this is already tested at the very beginning of the function. > We have done TYPE_SATURATING (TREE_TYPE (rhs1)) that refers to T, but I am concerned about the inner addition operation here, and if it is done in a saturating way. > + && !FLOAT_TYPE_P (TREE_TYPE (a)) > + && !FIXED_POINT_TYPE_P (TREE_TYPE (a)) > > likewise. Well, maybe this cannot happen, because if we have P + A, computed in float, and T an integer type, then probably CONVERT_EXPR_CODE_P (def_code) will not match, because def_code is FIX_TRUNC_EXPR in that case? OTOH it does not hut to check that, becaue A's type may be quite different than rhs1's type. > > + || (!POINTER_TYPE_P (TREE_TYPE (p)) > + && INTEGRAL_TYPE_P (TREE_TYPE (a)) > + && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (a))) > > INTEGRAL_TYPE_P are always !POINTER_TYPE_P. > > We come here, either because P + A is a POINTER_PLUS_EXPR or because P + A is a PLUS_EXPR. In the first case, P's type is POINTER_TYPE_P and A's type is INTEGRAL_TYPE_P so this should not check the TYPE_OVERFLOW_UNDEFINED, but instead the POINTER_TYPE_OVERFLOW_UNDEFINED. Also with undefined pointer wraparound, we can exploit that in the same way as with signed integers. But I am concerned, if (T)A is always the same thing as (T)(void*)A. I'd say, yes, if TYPE_UNSIGNED (TREE_TYPE (p)) == TYPE_UNSIGNED (TREE_TYPE (a)) or if A is a constant, and it is positive. Thanks Bernd.
Re: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P -> (T)A
> I noticed that several testcases in the GMP-4.3.2 test suite are failing now > which did not happen with GCC 4.9.0. I debugged the first one, > mpz/convert, and found the file mpn/generic/get_str.c was miscompiled. > > mpn/get_str.c.132t.dse2: > pretmp_183 = (sizetype) chars_per_limb_80; > pretmp_184 = -pretmp_183; > _23 = chars_per_limb_80 + 4294967295; > _68 = (sizetype) _23; > _28 = _68 + pretmp_184; > > mpn/get_str.c.133t.forwprop4: > _28 = 4294967295; > > > That is wrong, because chars_per_limb is unsigned, and it is not zero. > So the right result should be -1. This makes the loop termination in that > function fail. Can't we compute the right result in this case? 4294967295 is almost -1. > The attached patch fixes these regressions, and because the reasoning > depends on the TYPE_OVERFLOW_UNDEFINED attribute, a strict overflow warning > has to be emitted here, at least for widening conversions. Saturating, floating-point and fixed-point types are already excluded here, see the beginning of the function. -- Eric Botcazou
Re: [PATCH] Fix arrays in rtx.u + add minor rtx verification
On 06/20/2014 01:42 PM, Marek Polacek wrote:
> 2014-06-20 Marek Polacek
>
> * genpreds.c (verify_rtx_codes): New function.
> (main): Call it.
> * rtl.h (RTX_FLD_WIDTH, RTX_HWINT_WIDTH): Define.
> (struct rtx_def): Use them.
Looks pretty good. Just a few nits.
> +static void
> +verify_rtx_codes (void)
> +{
> + unsigned int i, j;
> +
> + for (i = 0; i < NUM_RTX_CODE; i++)
> +if (strchr (GET_RTX_FORMAT (i), 'w') == NULL)
> + {
> + if (strlen (GET_RTX_FORMAT (i)) > RTX_FLD_WIDTH)
> + internal_error ("%s format %s longer than RTX_FLD_WIDTH %d\n",
> + GET_RTX_NAME (i), GET_RTX_FORMAT (i),
> + (int) RTX_FLD_WIDTH);
> + }
> +else
> + {
> + const size_t len = strlen (GET_RTX_FORMAT (i));
The strlen result is used in both arms of the if. Tidier to hoist it, I think.
> + for (j = 0; j < len; j++)
> + if (GET_RTX_FORMAT (i)[j] != 'w')
> + internal_error ("%s format %s should contain only w, but "
> + "has %c\n", GET_RTX_NAME (i), GET_RTX_FORMAT (i),
> + GET_RTX_FORMAT (i)[j]);
The loop is strspn. Perhaps tidier as
const size_t spn = strspn(GET_RTX_FORMAT (i), "w");
if (spn != len)
internal_error (...);
r~
Re: [GSoC][match-and-simplify] mark some more operators as commutative
On Mon, 23 Jun 2014, Richard Biener wrote: On Mon, Jun 23, 2014 at 3:32 PM, Prathamesh Kulkarni wrote: * match.pd: Mark operators in some bitwise and plus-minus patterns to be commutative. /* A - (A +- B) -> -+ B */ (match_and_simplify - (minus @0 (plus @0 @1)) + (minus @0 (plus:c @0 @1)) (negate @0)) seems pointless Why? a-(a+b) and a-(b+a) are both wanted and don't appear elsewhere in the file, no? Should simplify to (negate @1) though. -- Marc Glisse
Re: [patch i386]: Combine memory and indirect jump
On 06/20/2014 02:59 PM, Kai Tietz wrote: > So I suggest following change of passes.def: > > Index: passes.def > === > --- passes.def (Revision 211850) > +++ passes.def (Arbeitskopie) > @@ -384,7 +384,6 @@ along with GCC; see the file COPYING3. If not see > NEXT_PASS (pass_rtl_dse2); > NEXT_PASS (pass_stack_adjustments); > NEXT_PASS (pass_jump2); > - NEXT_PASS (pass_peephole2); > NEXT_PASS (pass_if_after_reload); > NEXT_PASS (pass_regrename); > NEXT_PASS (pass_cprop_hardreg); > @@ -391,6 +390,7 @@ along with GCC; see the file COPYING3. If not see > NEXT_PASS (pass_fast_rtl_dce); > NEXT_PASS (pass_duplicate_computed_gotos); > NEXT_PASS (pass_reorder_blocks); > + NEXT_PASS (pass_peephole2); > NEXT_PASS (pass_branch_target_load_optimize2); > NEXT_PASS (pass_leaf_regs); > NEXT_PASS (pass_split_before_sched2); Looks good to me. I guess just keep an eye out for bug reports for other ports. r~
Re: [GSoC][match-and-simplify] mark some more operators as commutative
On Mon, Jun 23, 2014 at 3:32 PM, Prathamesh Kulkarni wrote: > * match.pd: Mark operators in some bitwise and plus-minus > patterns to be commutative. /* A - (A +- B) -> -+ B */ (match_and_simplify - (minus @0 (plus @0 @1)) + (minus @0 (plus:c @0 @1)) (negate @0)) seems pointless /* ~x & ~y -> ~(x | y) */ (match_and_simplify - (bit_and (bit_not @0) (bit_not @1)) + (bit_and:c (bit_not @0) (bit_not @1)) if (INTEGRAL_TYPE_P (TREE_TYPE (@0))) (bit_not (bit_ior @0 @1))) likewise. I have removed the pointless ones and committed the patch. Richard. > Thanks and Regards, > Prathamesh
Re: [PATCH] Fix 61565 -- cmpelim vs non-call exceptions
On 06/23/2014 02:29 AM, Ramana Radhakrishnan wrote: > > > On 20/06/14 21:28, Richard Henderson wrote: >> There aren't too many users of the cmpelim pass, and previously they were all >> small embedded targets without an FPU. >> >> I'm a bit surprised that Ramana decided to enable this pass for aarch64, as >> that target is not so limited as the block comment for the pass describes. >> Honestly, whatever is being deleted here ought to have been found earlier, >> either via combine or cse. We ought to find out why any changes are made >> during this pass for aarch64. > > Agreed - Going back and looking at my notes I remember seeing a difference in > code generation with the elimination of a number of compares that prompted me > to turn this on in a number of benchmarks. I don't remember double checking > why > CSE hadn't removed that at that time. This also probably explains the > equivalent patch for ARM and Thumb2 hasn't shown demonstrable differences. > > Investigating this pass for Thumb1 may be interesting. Isn't it true that thumb1 has only "adds r,r,#i" not "add r,r,#i"? Lack of an addition that doesn't clobber the flags is one of the two reasons why you'd want to enable the cmpelim pass. Although for thumb1, can't you achieve a no-clobber addition with an IT block with an "always" condition? Seems like a good use for the "addptr" pattern that Andreas Krebbel recently added for s390. That might let you make thumb1 look more like the rest of the arm port and emit separate compare and branch instructions from the start. r~
[GSoC][match-and-simplify] Remove gen_gimple_match_fail
* genmatch.c (gen_gimple_match_fail): Remove.
(expr::gen_gimple_transform): Remove call to gen_gimple_match_fail.
Change fprintf (f, "if (!res)") to fprintf (f, "if (!res) return false;\n")
Thanks and Regards,
Prathamesh
Index: gcc/genmatch.c
===
--- gcc/genmatch.c (revision 211893)
+++ gcc/genmatch.c (working copy)
@@ -452,15 +452,6 @@ commutate (operand *op)
/* Code gen off the AST. */
-static void
-gen_gimple_match_fail (FILE *f, const char *label)
-{
- if (!label)
-fprintf (f, "return NULL_TREE;\n");
- else
-fprintf (f, "goto %s;\n", label);
-}
-
void
expr::gen_gimple_transform (FILE *f, const char *label, const char *dest)
{
@@ -481,8 +472,7 @@ expr::gen_gimple_transform (FILE *f, con
for (unsigned i = 0; i < ops.length (); ++i)
fprintf (f, ", ops[%u]", i);
fprintf (f, ", seq, valueize);\n");
- fprintf (f, " if (!res) ");
- gen_gimple_match_fail (f, label);
+ fprintf (f, " if (!res) return false;\n");
fprintf (f, "}\n");
fprintf (f, " else\n");
fprintf (f, "res = gimple_build (seq, UNKNOWN_LOCATION, %s, "
Re: [GSoC] Addition of ISL AST generation to Graphite
> It seems the patch1/patch2 files you attach have the Content-Type:
> application/octet-stream. This makes it impossible to view them inline.
> Could you send them as text files? Just calling them patch1.patch or
> patch1.txt should make this work.
Yes, sure.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 9ac9b67..49b7bc6 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -109,7 +109,7 @@ value_max (mpz_t res, mpz_t v1, mpz_t v2)
/* This flag is set when an error occurred during the translation of
CLAST to Gimple. */
-static bool gloog_error;
+static bool graphite_regenerate_error;
/* Verifies properties that GRAPHITE should maintain during translation. */
@@ -363,7 +363,7 @@ max_precision_type (tree type1, tree type2)
if (precision > BITS_PER_WORD)
{
- gloog_error = true;
+ graphite_regenerate_error = true;
return integer_type_node;
}
@@ -373,7 +373,7 @@ max_precision_type (tree type1, tree type2)
if (!type)
{
- gloog_error = true;
+ graphite_regenerate_error = true;
return integer_type_node;
}
@@ -456,7 +456,7 @@ clast_to_gcc_expression (tree type, struct clast_expr *e,
ivs_params_p ip)
if (!POINTER_TYPE_P (type))
return fold_build2 (MULT_EXPR, type, cst, name);
- gloog_error = true;
+ graphite_regenerate_error = true;
return cst;
}
}
@@ -535,7 +535,7 @@ type_for_interval (mpz_t bound_one, mpz_t bound_two)
if (precision > BITS_PER_WORD)
{
- gloog_error = true;
+ graphite_regenerate_error = true;
return integer_type_node;
}
@@ -558,7 +558,7 @@ type_for_interval (mpz_t bound_one, mpz_t bound_two)
if (!type)
{
- gloog_error = true;
+ graphite_regenerate_error = true;
return integer_type_node;
}
@@ -1112,7 +1112,7 @@ translate_clast_user (struct clast_user_stmt *stmt, edge
next_e,
build_iv_mapping (iv_map, stmt, ip);
next_e = copy_bb_and_scalar_dependences (GBB_BB (gbb), ip->region,
- next_e, iv_map, &gloog_error);
+ next_e, iv_map,
&graphite_regenerate_error);
iv_map.release ();
new_bb = next_e->src;
@@ -1488,7 +1488,7 @@ build_cloog_union_domain (scop_p scop, int
nb_scattering_dims)
return union_domain;
}
-/* Return the options that will be used in GLOOG. */
+/* Return the options that will be used in graphite_regenerate_ast_cloog. */
static CloogOptions *
set_cloog_options (void)
@@ -1503,7 +1503,7 @@ set_cloog_options (void)
/* Enable complex equality spreading: removes dummy statements
(assignments) in the generated code which repeats the
substitution equations for statements. This is useless for
- GLooG. */
+ graphite_regenerate_ast_cloog. */
options->esp = 1;
/* Silence CLooG to avoid failing tests due to debug output to stderr. */
@@ -1663,7 +1663,7 @@ debug_generated_program (scop_p scop)
*/
bool
-gloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
+graphite_regenerate_ast_cloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
{
auto_vec newivs;
loop_p context_loop;
@@ -1674,7 +1674,7 @@ gloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
struct ivs_params ip;
timevar_push (TV_GRAPHITE_CODE_GEN);
- gloog_error = false;
+ graphite_regenerate_error = false;
params_index.create (10);
@@ -1714,7 +1714,7 @@ gloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
recompute_all_dominators ();
graphite_verify ();
- if (gloog_error)
+ if (graphite_regenerate_error)
set_ifsese_condition (if_region, integer_zero_node);
free (if_region->true_region);
@@ -1739,6 +1739,6 @@ gloog (scop_p scop, bb_pbb_htab_type bb_pbb_mapping)
num_no_dependency);
}
- return !gloog_error;
+ return !graphite_regenerate_error;
}
#endif
diff --git a/gcc/graphite-clast-to-gimple.h b/gcc/graphite-clast-to-gimple.h
index fc5a679..615cae8 100644
--- a/gcc/graphite-clast-to-gimple.h
+++ b/gcc/graphite-clast-to-gimple.h
@@ -21,6 +21,8 @@ along with GCC; see the file COPYING3. If not see
#ifndef GCC_GRAPHITE_CLAST_TO_GIMPLE_H
#define GCC_GRAPHITE_CLAST_TO_GIMPLE_H
+#include "graphite-htab.h"
+
extern CloogState *cloog_state;
/* Data structure for CLooG program representation. */
@@ -30,14 +32,7 @@ struct cloog_prog_clast {
struct clast_stmt *stmt;
};
-/* Stores BB's related PBB. */
-
-struct bb_pbb_def
-{
- basic_block bb;
- poly_bb_p pbb;
-};
-
+extern bool graphite_regenerate_ast_cloog (scop_p, bb_pbb_htab_type);
extern void debug_clast_stmt (struct clast_stmt *);
extern void print_clast_stmt (FILE *, struct clast_stmt *);
diff --git a/gcc/graphite-htab.h b/gcc/graphite-htab.h
index d67dd0c..9f31fac 100644
--- a/gcc/graphite-htab.h
+++ b/gcc/graphite-htab.h
@@ -22,7 +22,14 @@ along
RE: [PATCH] Change default for --param allow-...-data-races to off
Hi Martin, >> >> Well actually, I am not sure if we ever wanted to have a race condition here. >> Have you seen any impact of --param allow-store-data-races on any benchmark? > > It's trivially to write one. The only pass that checks the param is > tree loop invariant motion and it does that when it applies store-motion. > Register pressure increase is increased by a factor of two. > > So I'd agree that we might want to disable this again for -Ofast. > > As nothing tests for the PACKED variants nor for the LOAD variant > I'd rather remove those. Claiming we don't create races for those > when you disable it via the param is simply not true. > > Thanks, > Richard. > OK, please go ahead with your patch. Thanks Bernd.
[GSoC][match-and-simplify] mark some more operators as commutative
* match.pd: Mark operators in some bitwise and plus-minus
patterns to be commutative.
Thanks and Regards,
Prathamesh
Index: gcc/match.pd
===
--- gcc/match.pd (revision 211893)
+++ gcc/match.pd (working copy)
@@ -138,7 +138,7 @@ along with GCC; see the file COPYING3.
(minus (plus @0 @1) @1)
@0)
(match_and_simplify
- (plus (minus @0 @1) @1)
+ (plus:c (minus @0 @1) @1)
@0)
/* (CST +- A) +- CST -> CST' +- A. */
/* match_and_simplify handles constant folding for us so we can
@@ -176,7 +176,7 @@ along with GCC; see the file COPYING3.
/* A - (A +- B) -> -+ B */
(match_and_simplify
- (minus @0 (plus @0 @1))
+ (minus @0 (plus:c @0 @1))
(negate @0))
(match_and_simplify
@@ -285,25 +285,25 @@ along with GCC; see the file COPYING3.
/* x & ~x -> 0 */
(match_and_simplify
- (bit_and @0 (bit_not @0))
+ (bit_and:c @0 (bit_not @0))
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
{ build_int_cst (type, 0); })
/* ~x & ~y -> ~(x | y) */
(match_and_simplify
- (bit_and (bit_not @0) (bit_not @1))
+ (bit_and:c (bit_not @0) (bit_not @1))
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
(bit_not (bit_ior @0 @1)))
/* ~x | ~y -> ~(x & y) */
(match_and_simplify
- (bit_ior (bit_not @0) (bit_not @1))
+ (bit_ior:c (bit_not @0) (bit_not @1))
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
(bit_not (bit_and @0 @1)))
/* x & (~x | y) -> y & x */
(match_and_simplify
- (bit_and @0 (bit_ior (bit_not @0) @1))
+ (bit_and:c @0 (bit_ior:c (bit_not @0) @1))
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
(bit_and @1 @0))
@@ -320,25 +320,25 @@ along with GCC; see the file COPYING3.
/* (x | y) & x -> x */
(match_and_simplify
- (bit_and (bit_ior @0 @1) @0)
+ (bit_and:c (bit_ior:c @0 @1) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
@0)
/* (x & y) | x -> x */
(match_and_simplify
- (bit_ior (bit_and @0 @1) @0)
+ (bit_ior:c (bit_and:c @0 @1) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
@0)
/* (~x | y) & x -> x & y */
(match_and_simplify
- (bit_and (bit_ior (bit_not @0) @1) @0)
+ (bit_and:c (bit_ior:c (bit_not @0) @1) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
(bit_and @0 @1))
/* (~x & y) | x -> x | y */
(match_and_simplify
- (bit_ior (bit_and (bit_not @0) @1) @0)
+ (bit_ior:c (bit_and:c (bit_not @0) @1) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
(bit_ior @0 @1))
@@ -350,7 +350,7 @@ along with GCC; see the file COPYING3.
/* ((a & b) & ~a) -> 0 */
(match_and_simplify
- (bit_and (bit_and @0 @1) (bit_not @0))
+ (bit_and:c (bit_and:c @0 @1) (bit_not @0))
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
{ build_int_cst (type, 0); })
[PATCH][match-and-simplify] Remove now dead code
This removes the non-DT matching code.
Committed.
Richard.
2014-06-23 Richard Biener
* genmatch.c (operand::gen_gimple_match): Remove.
(predicate::gen_gimple_match): Likewise.
(expr::gen_gimple_match): Likewise.
(c_expr::gen_gimple_match): Likewise.
(capture::gen_gimple_match): Likewise.
(write_nary_simplifiers): Remove.
Index: gcc/genmatch.c
===
--- gcc/genmatch.c (revision 211891)
+++ gcc/genmatch.c (working copy)
@@ -204,7 +204,6 @@ struct operand {
enum op_type { OP_PREDICATE, OP_EXPR, OP_CAPTURE, OP_C_EXPR };
operand (enum op_type type_) : type (type_) {}
enum op_type type;
- virtual void gen_gimple_match (FILE *f, const char *, const char * = NULL) =
0;
virtual void gen_gimple_transform (FILE *f, const char *, const char *) = 0;
};
@@ -212,7 +211,6 @@ struct predicate : public operand
{
predicate (const char *ident_) : operand (OP_PREDICATE), ident (ident_) {}
const char *ident;
- virtual void gen_gimple_match (FILE *f, const char *, const char *);
virtual void gen_gimple_transform (FILE *, const char *, const char *) {
gcc_unreachable (); }
};
@@ -230,7 +228,6 @@ struct expr : public operand
void append_op (operand *op) { ops.safe_push (op); }
e_operation *operation;
vec ops;
- virtual void gen_gimple_match (FILE *f, const char *, const char *);
virtual void gen_gimple_transform (FILE *f, const char *, const char *);
};
@@ -243,7 +240,6 @@ struct c_expr : public operand
vec code;
unsigned nr_stmts;
char *fname;
- virtual void gen_gimple_match (FILE *, const char *, const char *) {
gcc_unreachable (); }
virtual void gen_gimple_transform (FILE *f, const char *, const char *);
};
@@ -253,7 +249,6 @@ struct capture : public operand
: operand (OP_CAPTURE), where (where_), what (what_) {}
const char *where;
operand *what;
- virtual void gen_gimple_match (FILE *f, const char *, const char *);
virtual void gen_gimple_transform (FILE *f, const char *, const char *);
};
@@ -467,145 +462,6 @@ gen_gimple_match_fail (FILE *f, const ch
}
void
-predicate::gen_gimple_match (FILE *f, const char *op, const char *label)
-{
- fprintf (f, "if (!%s (%s)) ", ident, op);
- gen_gimple_match_fail (f, label);
-}
-
-void
-expr::gen_gimple_match (FILE *f, const char *name, const char *label)
-{
- if (operation->op->kind == id_base::CODE)
-{
- operator_id *op = static_cast (operation->op);
- /* The GIMPLE variant. */
- fprintf (f, "if (TREE_CODE (%s) == SSA_NAME)\n", name);
- fprintf (f, " {\n");
- fprintf (f, "gimple def_stmt = SSA_NAME_DEF_STMT (%s);\n", name);
- fprintf (f, "if (!is_gimple_assign (def_stmt)\n");
- if (op->code == NOP_EXPR
- || op->code == CONVERT_EXPR)
- fprintf (f, "|| !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code
(def_stmt))) ");
- else
- fprintf (f, "|| gimple_assign_rhs_code (def_stmt) != %s) ",
op->id);
- gen_gimple_match_fail (f, label);
- if (op->code == REALPART_EXPR
- || op->code == IMAGPART_EXPR
- || op->code == VIEW_CONVERT_EXPR
- || op->code == BIT_FIELD_REF)
- {
- fprintf (f, "tree rhs = gimple_assign_rhs1 (def_stmt);\n");
- for (unsigned i = 0; i < ops.length (); ++i)
- {
- fprintf (f, " {\n");
- fprintf (f, " tree op = TREE_OPERAND (rhs, %d);\n", i);
- fprintf (f, " if (valueize && TREE_CODE (op) == SSA_NAME)\n");
- fprintf (f, " {\n");
- fprintf (f, " op = valueize (op);\n");
- fprintf (f, " if (!op) ");
- gen_gimple_match_fail (f, label);
- fprintf (f, " }\n");
- ops[i]->gen_gimple_match (f, "op", label);
- fprintf (f, " }\n");
- }
- }
- else
- {
- for (unsigned i = 0; i < ops.length (); ++i)
- {
- fprintf (f, " {\n");
- fprintf (f, " tree op = gimple_assign_rhs%d (def_stmt);\n", i
+ 1);
- fprintf (f, " if (valueize && TREE_CODE (op) == SSA_NAME)\n");
- fprintf (f, " {\n");
- fprintf (f, " op = valueize (op);\n");
- fprintf (f, " if (!op) ");
- gen_gimple_match_fail (f, label);
- fprintf (f, " }\n");
- ops[i]->gen_gimple_match (f, "op", label);
- fprintf (f, " }\n");
- }
- }
- fprintf (f, " }\n");
- /* The GENERIC variant. */
- fprintf (f, "else if (TREE_CODE (%s) == %s)\n", name, op->id);
- fprintf (f, " {\n");
- for (unsigned i = 0; i < ops.length (); ++i)
- {
- fprintf (f, " {\n");
- fprintf (f, " tree op_ = %s;\n", name);
- fprintf (f, " tree op = TREE_OPERAND (op_, %d);\n", i);
-
Re: [AArch64] Implement ADD in vector registers for 32-bit scalar values.
Hi James, On 19/06/14 14:12, James Greenhalgh wrote: diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md >index 266d7873a5a1b8dbb7f955c3f13cf370920a9c4a..7c5b5a566ebfd907b83b38eed2e214738e7e9bd4 100644 >--- a/gcc/config/aarch64/aarch64.md >+++ b/gcc/config/aarch64/aarch64.md >@@ -1068,16 +1068,17 @@ (define_expand "add3" > > (define_insn "*addsi3_aarch64" >[(set >-(match_operand:SI 0 "register_operand" "=rk,rk,rk") >+(match_operand:SI 0 "register_operand" "=rk,rk,w,rk") > (plus:SI >- (match_operand:SI 1 "register_operand" "%rk,rk,rk") >- (match_operand:SI 2 "aarch64_plus_operand" "I,r,J")))] >+ (match_operand:SI 1 "register_operand" "%rk,rk,w,rk") >+ (match_operand:SI 2 "aarch64_plus_operand" "I,r,w,J")))] >"" >"@ >add\\t%w0, %w1, %2 >add\\t%w0, %w1, %w2 >+ add\\t%0.2s, %1.2s, %2.2s >sub\\t%w0, %w1, #%n2" >- [(set_attr "type" "alu_imm,alu_reg,alu_imm")] >+ [(set_attr "type" "alu_imm,alu_reg,neon_add,alu_imm")] > ) > Minor nit, you should set the "simd" attribute to yes for the added alternative to make sure it doesn't get selected when !TARGET_SIMD Thanks, Kyrill
Re: [GSoC] Addition of ISL AST generation to Graphite
Thank you for the review! -- Cheers, Roman Gareev ChangeLog_entry1 Description: Binary data ChangeLog_entry2 Description: Binary data patch1 Description: Binary data patch2 Description: Binary data
Re: [PATCH, PR 61540] Do not ICE on impossible devirtualization
On Thu, Jun 19, 2014 at 12:49:55PM +0100, Martin Jambor wrote:
> Hi,
>
> On Wed, Jun 18, 2014 at 06:12:34PM +0200, Bernhard Reutner-Fischer wrote:
> > On 18 June 2014 10:24:16 Martin Jambor wrote:
> >
> > >@@ -3002,10 +3014,8 @@ try_make_edge_direct_virtual_call (struct
> > >cgraph_edge *ie,
> > >
> > > if (target)
> > > {
> > >-#ifdef ENABLE_CHECKING
> > >- gcc_assert (possible_polymorphic_call_target_p
> > >- (ie, cgraph_get_node (target)));
> > >-#endif
> > >+ if (!possible_polymorphic_call_target_p (ie, cgraph_get_node
> > >(target)))
> > >+ return ipa_make_edge_direct_to_target (ie, target);
> > > return ipa_make_edge_direct_to_target (ie, target);
> > > }
> >
> > The above looks odd. You return the same thing both conditionally
> > and unconditionally?
> >
>
> You are obviously right, apparently I was too tired to attempt to work
> that night. Thanks, for spotting it. The following patch has this
> corrected and it also passes bootstrap and testing on x86_64-linux on
> both the trunk and the 4.9 branch. OK for both?
>
> Thanks,
>
> Martin
Hi Martin,
This new test fails for test variants with -fPIC. ( trunk and gcc-4_9-branch )
I've confirmed this on ARM, AArch64 and x86_64.
FAIL: g++.dg/ipa/pr61540.C -std=gnu++11 scan-ipa-dump cp "Type inconsident
devirtualization"
FAIL: g++.dg/ipa/pr61540.C -std=gnu++1y scan-ipa-dump cp "Type inconsident
devirtualization"
FAIL: g++.dg/ipa/pr61540.C -std=gnu++98 scan-ipa-dump cp "Type inconsident
devirtualization"
I don't understand enough of this area to be more helpful, but I've
attached the relevant dump and the generated assembly for x86_64 for this
command:
./cc1plus ../../src/gcc/gcc/testsuite/g++.dg/ipa/pr61540.C -fmessage-length=0
-std=gnu++98 -O3 -fno-early-inlining -fdump-ipa-cp -o foo.s -fPIC
Let me know if you need any patches testing, or if there is anything else
I can help with.
Thanks,
James
.file "pr61540.C"
.section
.text.unlikely._ZN3top4topfEv,"axG",@progbits,_ZN3top4topfEv,comdat
.align 2
.LCOLDB0:
.section
.text._ZN3top4topfEv,"axG",@progbits,_ZN3top4topfEv,comdat
.LHOTB0:
.align 2
.p2align 4,,15
.weak _ZN3top4topfEv
.type _ZN3top4topfEv, @function
_ZN3top4topfEv:
.LFB3:
.cfi_startproc
rep; ret
.cfi_endproc
.LFE3:
.size _ZN3top4topfEv, .-_ZN3top4topfEv
.section
.text.unlikely._ZN3top4topfEv,"axG",@progbits,_ZN3top4topfEv,comdat
.LCOLDE0:
.section
.text._ZN3top4topfEv,"axG",@progbits,_ZN3top4topfEv,comdat
.LHOTE0:
.section
.text.unlikely._ZN12intermediate4topfEv,"axG",@progbits,_ZN12intermediate4topfEv,comdat
.align 2
.LCOLDB1:
.section
.text._ZN12intermediate4topfEv,"axG",@progbits,_ZN12intermediate4topfEv,comdat
.LHOTB1:
.align 2
.p2align 4,,15
.weak _ZN12intermediate4topfEv
.type _ZN12intermediate4topfEv, @function
_ZN12intermediate4topfEv:
.LFB4:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
.LFE4:
.size _ZN12intermediate4topfEv, .-_ZN12intermediate4topfEv
.section
.text.unlikely._ZN12intermediate4topfEv,"axG",@progbits,_ZN12intermediate4topfEv,comdat
.LCOLDE1:
.section
.text._ZN12intermediate4topfEv,"axG",@progbits,_ZN12intermediate4topfEv,comdat
.LHOTE1:
.section.text.unlikely,"ax",@progbits
.LCOLDB2:
.text
.LHOTB2:
.p2align 4,,15
.globl _Z4testR3top
.type _Z4testR3top, @function
_Z4testR3top:
.LFB6:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movq(%rdi), %rax
movq(%rax), %rax
cmpq_ZN3top4topfEv@GOTPCREL(%rip), %rax
jne .L7
.L4:
movq_ZTV6child2@GOTPCREL(%rip), %rax
movq%rsp, %rdi
addq$16, %rax
movq%rax, (%rsp)
call_Z4testR3top@PLT
addq$24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L7:
.cfi_restore_state
call*%rax
jmp .L4
.cfi_endproc
.LFE6:
.size _Z4testR3top, .-_Z4testR3top
.section.text.unlikely
.LCOLDE2:
.text
.LHOTE2:
.section.text.unlikely
.LCOLDB3:
.section.text.startup,"ax",@progbits
.LHOTB3:
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB16:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movq_ZTV6child1@GOTPCREL(%rip), %rax
movq%rsp, %rdi
addq$16, %rax
movq%rax, (%rsp)
call_Z4testR3top@PLT
xorl%eax, %eax
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE16:
.size main, .-main
.section
Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook
On 2 May 2014 10:04, Kugan wrote:
> Thanks for spotting it. Here is the updated patch that changes it to
> ARM_FE_*.
> +2014-05-02 Kugan Vivekanandarajah
> +
> + * config/arm/arm.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New define.
> + (arm_builtins) : Add ARM_BUILTIN_GET_FPSCR and ARM_BUILTIN_SET_FPSCR.
> + (bdesc_2arg) : Add description for builtins __builtins_arm_set_fpscr
> + and __builtins_arm_get_fpscr.
s/__builtins/__builtin/g
> + (arm_init_builtins) : Initialize builtins __builtins_arm_set_fpscr and
> + __builtins_arm_get_fpscr.
s/__builtins/__builtin/g
This doesn't match the code, which initializes builtins "...ldfscr"
and "...stfscr" (with no "p" in "fscr").
> + (arm_expand_builtin) : Expand builtins __builtins_arm_set_fpscr and
> + __builtins_arm_ldfpscr.
s/__builtins/__builtin/g
Did you mean "and __builtin_arm_get_fpscr"?
> +#define FP_BUILTIN(L, U) \
> + {0, CODE_FOR_##L, "__builtin_arm_"#L, ARM_BUILTIN_##U, \
> + UNKNOWN, 0},
> +
> + FP_BUILTIN (set_fpscr, GET_FPSCR)
> + FP_BUILTIN (get_fpscr, SET_FPSCR)
> +#undef FP_BUILTIN
This looks like a typo: you have mapped set->GET and get->SET.
Jay.
