Re: [Patch, libfortran] PR51825 - Fortran runtime error: Cannot match namelist object name
Hi Tilo,
I have now committed your two patches.
* PR 48618 - Negative unit number in OPEN(...) is sometimes allowed (as
Rev. 196805)
which was approved here:
http://thread.gmane.org/gmane.comp.gcc.fortran/40435/focus=40455 (It's
not in the gcc.gnu.org/ml/fortran as the server didn't record the mails
at that point)
* This patch (as Rev. 196806)
Congratulation to the committal of your first two patches - and thanks
again for your work.
Two remarks:
Tilo Schwarz wrote:
2013-03-07 Tilo Schwarz
PR libfortran/51825
* io/list_read.c (nml_read_obj): Don't end the component loop on a
nested derived type, but continue with the next loop iteration.
(nml_get_obj_data): Don't move the first_nl pointer further in the
list if a qualifier was found.
* gcc/testsuite/gfortran.dg/namelist_77.f90: New.
* gcc/testsuite/gfortran.dg/namelist_78.f90: New.
The change log ends up in two files: libgfortran/ChangeLog and
gcc/testsuite/ChangeLog. File names are relative to those files. Hence,
I removed "gcc/testsuite/" before committal.
+++ b/gcc/testsuite/gfortran.dg/namelist_77.f90
@@ -0,0 +1,48 @@
+! { dg-do run }
+! PR 51825 - Fortran runtime error: Cannot match namelist object name
+! Test case derived from PR.
...
+++ b/gcc/testsuite/gfortran.dg/namelist_78.f90
@@ -0,0 +1,32 @@
+! { dg-do run }
+! Test case regarding namelist problems with derived types
It is useful to quickly see from which bug/problem report the test case
came from. Thus, I added "PR libfortran/51825". (Using PR 51825 is also
fine; btw. there is no need to add a full link to Bugzilla as the PR
number is sufficient.)
Tobias
Re: [Ada, RFC patch] Fortran Interface: Update comment, add some of the Star/Kind type definitions
Arnaud Charlet wrote: So Tobias: you can go ahead and commit these changes, assuming a clean build/test for Ada. I did a successful bootstrap (true all languages (all+ada+go+Obj-c(++))) and "make check-ada" without any failures on x86-64-gnu-linux. Committed as Rev. 196814. Thanks for the review! Tobias
[PATCH] Fix PR56661
This fixes PR56661 - we were value-numbering two call results
the same even though function attributes tell us that they are
required to return a distinct value (and this property is exploited
by alias analysis). Simply don't do that (as opposed to trying to
fix things up).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2013-03-20 Richard Biener
PR tree-optimization/56661
* tree-ssa-sccvn.c (visit_use): Only value-number calls if
the result does not have to be distinct.
* gcc.dg/torture/pr56661.c: New testcase.
Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c(revision 196808)
--- gcc/tree-ssa-sccvn.c(working copy)
*** visit_use (tree use)
*** 3506,3513
We can value number 2 calls to the same function with the
same vuse and the same operands which are not subsequent
the same, because there is no code in the program that can
!compare the 2 values. */
! || gimple_vdef (stmt)))
changed = visit_reference_op_call (lhs, stmt);
else
changed = defs_to_varying (stmt);
--- 3506,3518
We can value number 2 calls to the same function with the
same vuse and the same operands which are not subsequent
the same, because there is no code in the program that can
!compare the 2 values... */
! || (gimple_vdef (stmt)
! /* ... unless the call returns a pointer which does
!not alias with anything else. In which case the
!information that the values are distinct are encoded
!in the IL. */
! && !(gimple_call_return_flags (stmt) & ERF_NOALIAS
changed = visit_reference_op_call (lhs, stmt);
else
changed = defs_to_varying (stmt);
Index: gcc/testsuite/gcc.dg/torture/pr56661.c
===
*** gcc/testsuite/gcc.dg/torture/pr56661.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr56661.c (working copy)
***
*** 0
--- 1,46
+ /* { dg-do run } */
+
+ __attribute__((noinline, noclone)) void
+ bar (int *b)
+ {
+ b[0] = b[1] = b[2] = 1;
+ }
+
+ __attribute__((noinline, noclone)) int
+ baz (int x)
+ {
+ if (x != 1)
+ __builtin_abort ();
+ }
+
+ void
+ foo (int x)
+ {
+ if (x == 0)
+ {
+ int *b = __builtin_malloc (3 * sizeof (int));
+ while (b[0])
+ ;
+ }
+ else if (x == 1)
+ {
+ int i, j;
+ int *b = __builtin_malloc (3 * sizeof (int));
+ for (i = 0; i < 2; i++)
+ {
+ bar (b);
+ for (j = 0; j < 3; ++j)
+ baz (b[j]);
+ baz (b[0]);
+ }
+ }
+ }
+
+ int
+ main ()
+ {
+ int x = 1;
+ asm volatile ("" : "+r" (x));
+ foo (x);
+ return 0;
+ }
[wwwdocs,committed] Add gomp-4_0-branch to svn.html
Committed after approval by Jakub. Tobias Index: svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.180 diff -u -r1.180 svn.html --- svn.html 19 Feb 2013 21:21:26 - 1.180 +++ svn.html 20 Mar 2013 10:32:39 - @@ -189,6 +189,11 @@ the http://gcc.gnu.org/wiki/GimpleFrontEnd";>GIMPLE Front End page for details. + gomp-4_0-branch + The purpose of this branch is to update the OpenMP support to version + 4.0. This branch is mantained by Jakub Jelinek. Patches should be marked + with the tag [gomp4] in the subject line. + ra-improvements This branch aims to implement several improvements to the current register allocator. Examples include implementing a
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Tue, Mar 19, 2013 at 6:30 PM, Andi Kleen wrote: > On Tue, Mar 19, 2013 at 05:10:22PM +0100, Jakub Jelinek wrote: >> On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote: >> > > Using __always_inline as the name of the macro is a bad idea, glibc >> > > headers use that macro already. Just use something else in public >> > > headers >> > > that aren't part of glibc. >> > >> > That's why I had the ifdef, but ok. I'll use __force_inline then. >> >> I'd say Jonathan's _GLIBCXX_ALWAYS_INLINE would be better. >> >> BTW, have you verified always_inline works fine for -O0? > > I did some simple tests and it seemed to work. > > But thanks for the counter example. > >> >> with -O0 -mhle doesn't result in xacquire, guess for !optimize >> get_memmodel would need to look through chain of SSA_NAMEs if SSA_NAME >> (that can appear because of inlining), looking for INTEGER_CSTs. > > interesting. so need more fixes. i'll look into that. Is there > already a convenient helper for it? Not without using information created by TER which is disabled for this case because of different line information. If TER would not be disabled for this reason it would already work automagically. Eventually we can relax this restriction for constants that are only fed through temporaries ... > There was an alternative approach of using a template, but I suppose > that would have the same problem. Possibly yes, but I guess the frontend substitutes without going through an extra temporary (if all arguments are template parameters!) Richard. > > -Andi
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Wed, Mar 20, 2013 at 11:38:03AM +0100, Richard Biener wrote:
> Not without using information created by TER which is disabled for this
> case because of different line information. If TER would not be disabled
> for this reason it would already work automagically.
Would relaxing that in TER for constants help in the case of:
static inline __attribute__((always_inline)) ...
foo (..., int m = __ATOMIC_SEQ_CST)
{
if (something)
bar ();
else
baz ();
__atomic_test_and_set (&x, m);
}
void
test ()
{
foo (..., __ATOMIC_HLE_ACQUIRE | __ATOMIC_SEQ_CST);
}
though? I'd think as the temp = 0x10005; would be in a different bb, TER
wouldn't do anything here, for -O1 of course CCP or similar would propagate
that, but for -O0 we'd still have to walk the chain of SSA_NAMEs.
Jakub
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Wed, Mar 20, 2013 at 11:46 AM, Jakub Jelinek wrote:
> On Wed, Mar 20, 2013 at 11:38:03AM +0100, Richard Biener wrote:
>> Not without using information created by TER which is disabled for this
>> case because of different line information. If TER would not be disabled
>> for this reason it would already work automagically.
>
> Would relaxing that in TER for constants help in the case of:
> static inline __attribute__((always_inline)) ...
> foo (..., int m = __ATOMIC_SEQ_CST)
> {
> if (something)
> bar ();
> else
> baz ();
> __atomic_test_and_set (&x, m);
> }
>
> void
> test ()
> {
> foo (..., __ATOMIC_HLE_ACQUIRE | __ATOMIC_SEQ_CST);
> }
> though? I'd think as the temp = 0x10005; would be in a different bb, TER
> wouldn't do anything here, for -O1 of course CCP or similar would propagate
> that, but for -O0 we'd still have to walk the chain of SSA_NAMEs.
True. I was for a long time thinking of running a CCP pass at -O0 ...
and only restrict what we sustitute into (builtin arguments and asm operands).
Walking the SSA def chain would also be possible - preferably from
cfgexpand.c when we process the stmt. But you'll eventually lose
debug info like for
int i = 1;
__builtin_foo (i);
when we then never expand the SSA name def i_2 = 1 because we are
never visiting its use ...
Richard.
> Jakub
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Wed, Mar 20, 2013 at 12:20:27PM +0100, Richard Biener wrote: > Walking the SSA def chain would also be possible - preferably from > cfgexpand.c when we process the stmt. But you'll eventually lose > debug info like for > > int i = 1; > __builtin_foo (i); > > when we then never expand the SSA name def i_2 = 1 because we are > never visiting its use ... If i is a user variable, then for -O0 we'd better create a memory slot for it and expand the i = 1 store as store to that memory location. Jakub
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Wed, Mar 20, 2013 at 12:24 PM, Jakub Jelinek wrote: > On Wed, Mar 20, 2013 at 12:20:27PM +0100, Richard Biener wrote: >> Walking the SSA def chain would also be possible - preferably from >> cfgexpand.c when we process the stmt. But you'll eventually lose >> debug info like for >> >> int i = 1; >> __builtin_foo (i); >> >> when we then never expand the SSA name def i_2 = 1 because we are >> never visiting its use ... > > If i is a user variable, then for -O0 we'd better create a memory slot for > it and expand the i = 1 store as store to that memory location. Ok, we seem to do that... Richard. > Jakub
Re: [testsuite] Don't XFAIL gfortran.dg/do_1.f90 (PR fortran/54932)
Tobias Burnus writes: > Rainer Orth wrote: >> As discussed in PR fortran/54932, the gfortran.dg/do_1.f90 execution >> tests recently stated to XPASS at all optimization levels, adding lots >> of testsuite noise. The following patch removes the xfail, allowing all >> tests to pass. >> >> Tested with the appropriate runtest invocations on >> x86_64-unknown-linux-gnu, i386-pc-solaris2.11, and >> sparc-sun-solaris2.11. Ok for mainline and 4.8 branch? > > Removing the xfail is okay. However, I wonder whether it would be better to > leave a reference to the PR in case the failure pops up again. As the code > is ill-defined, the failures might pop up in the future and the reference > can help with analysis. I prefer to leave the PR reference removed. If the failure crops up again, it's a simple matter of looking at the ChangeLog, svn annotate, or bugzilla to discover the bug, if not, we keep the obsolete comment forever. > OK - as is or with an updated reference to the PR. – For the branch, it is > the RMs' call when it can be committed. Jakub, Richard? > Please wait with the committal until GCC's web mail archive works again for > gcc-cvs. Done. Thanks. Rainer >> 2013-03-19 Rainer Orth >> >> PR fortran/54932 >> * gfortran.dg/do_1.f90: Don't xfail. -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [4.7, go] Backport godump.c patch
Rainer Orth writes: > Ian Lance Taylor writes: > >> On Thu, Mar 14, 2013 at 9:53 AM, Rainer Orth wrote: >> >>> I found that this patch >>> >>> 2012-12-04 Ian Lance Taylor >>> * godump.c (find_dummy_types): Output a dummy type if we couldn't >>> output the real type. >>> >>> fixes the problem, so I'd like to backport it. >>> >>> i386-pc-solaris2.11 bootstrap still running, ok for 4.7 branch if it >>> passes? >> >> It's fine with me though I guess it needs to be approved by a release >> branch manager. > > Ok, Cc'ed. The i386-pc-solaris2.11 bootstrap now completed > successfully, and I've also bootstrapped on x86_64-unknown-linux-gnu to > make sure nothing breaks. > > While the patch doesn't fix a regression, it does fix a bootstrap > failure and has been on mainline for 3 1/2 months, so seems pretty > safe. It's been almost a week with no word from the RMs if this is appropriate for the 4.7 branch. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [4.7, go] Backport godump.c patch
On Wed, 20 Mar 2013, Rainer Orth wrote: > Rainer Orth writes: > > > Ian Lance Taylor writes: > > > >> On Thu, Mar 14, 2013 at 9:53 AM, Rainer Orth wrote: > >> > >>> I found that this patch > >>> > >>> 2012-12-04 Ian Lance Taylor > >>> * godump.c (find_dummy_types): Output a dummy type if we couldn't > >>> output the real type. > >>> > >>> fixes the problem, so I'd like to backport it. > >>> > >>> i386-pc-solaris2.11 bootstrap still running, ok for 4.7 branch if it > >>> passes? > >> > >> It's fine with me though I guess it needs to be approved by a release > >> branch manager. > > > > Ok, Cc'ed. The i386-pc-solaris2.11 bootstrap now completed > > successfully, and I've also bootstrapped on x86_64-unknown-linux-gnu to > > make sure nothing breaks. > > > > While the patch doesn't fix a regression, it does fix a bootstrap > > failure and has been on mainline for 3 1/2 months, so seems pretty > > safe. > > It's been almost a week with no word from the RMs if this is appropriate > for the 4.7 branch. RMs don't care for GO. Richard. > Thanks. > Rainer > > -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: [PATCH] Improve debug info for various cases where we drop location info on the floor (PR debug/55608)
On Fri, Dec 07, 2012 at 11:36:24AM -0800, Cary Coutant wrote: > > This patch adds DW_AT_const_value or DW_AT_location for unused static vars > > (thus, not really modified and their DECL_INITIAL can be used for > > location/constant value info), and optimizes various cases using > > DW_OP_GNU_implicit_pointer (e.g. DW_OP_addr DW_OP_stack_value > > where symbol is either an optimized away static var (but with DW_AT_location > > or DW_AT_const_value on it's DIE), which would be otherwise dropped > > to avoid referencing non-existent symbol, can be replaced with > > DW_OP_GNU_implicit_pointer to that DIE. Or, if symbol above is a constant > > string > > literal, we can create DW_TAG_dwarf_procedure with DW_AT_location > > DW_OP_implicit_value (and, surprisingly, GDB handles that out of the box). > > > > In cc1plus .debug_loc grew with this by about 3% and .debug_info grew by > > 0.25%, in libstdc++ the changes were in the noise. > > Based on my reading of PR 55608, this isn't really a regression, and > it's definitely not a regression from 4.7 to 4.8. While the patch > looks OK to me, the size increase in .debug_loc and the scope of the > change suggest that this would be more appropriate for when Stage 1 > reopens. Now that Stage 1 reopened, is this ok for 4.9? Jakub
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
It looks like this message didn't go through; if you get this multiple times I apologize. I've been having issues so I don't trust that it sent correctly :/ On 19-Mar-13 03:04, Maxim Kuvyrkov wrote: Will commit to trunk once the server is up. Regarding 4.8, we should've really tried to work it out earlier. If you want to pursue backport to 4.8, please attach the log of PPA system rejecting the package The error is: == Finished at 20130318-0642 Build needed 00:14:20, 804796k disk space Function `__gthread_get_tsd_data' implicitly converted to pointer at /build/buildd/gcc-powerpc-wrs-vxworks-4.8.0+0svn196132/libgcc/config/vxlib-tls.c:164 Our automated build log filter detected the problem(s) above that will likely cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. This is often due to a missing function prototype definition. Since use of implicitly converted pointers is always fatal to the application on ia64, they are errors. Please correct them for your next upload. == This problem does not apply on the target (powerpc-wrs-vxworks), where sizeof(int*) == sizeof(int(*)()) == sizeof(int) == 4. However, the build system's filters are too stupid to realize this. Because the warning is spurious really the fact that the automated build system rejects the package is a bug on the build system's part. However, doing it the Right Way is so _easy_... (fwiw, I don't quite understand which launchpad you are referring to). I am referring to https://launchpad.net/ubuntu/+ppas Thanks for your help. Robert Mason
[PATCH] Rename DECL_DEBUG_EXPR_IS_FROM to DECL_HAS_DEBUG_EXPR_P
As discussed previously on IRC this patch does the renaming from
the confusing DECL_DEBUG_EXPR_IS_FROM to DECL_HAS_DEBUG_EXPR_P
which matches DECL_HAS_VALUE_EXPR_P (and it's behavior).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Ok if it passes?
Thanks,
Richard.
2013-03-20 Richard Biener
* tree.h (DECL_DEBUG_EXPR_IS_FROM): Rename to ...
(DECL_HAS_DEBUG_EXPR_P): ... this. Guard properly.
* dwarf2out.c (add_var_loc_to_decl): Use DECL_HAS_DEBUG_EXPR_P
instead of DECL_DEBUG_EXPR_IS_FROM.
* gimplify.c (gimplify_modify_expr): Likewise.
* tree-cfg.c (verify_expr_location_1): Likewise.
* tree-complex.c (create_one_component_var): Likewise.
* tree-inline.c (add_local_variables): Likewise.
* tree-sra.c (create_access_replacement): Likewise.
* tree-ssa-live.c (clear_unused_block_pointer_1): Likewise.
(clear_unused_block_pointer): Likewise.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Likewise.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.
* var-tracking.c (var_debug_decl): Likewise.
(track_expr_p): Likewise.
* tree-diagnostic.c (default_tree_printer): Use DECL_HAS_DEBUG_EXPR_P
instead of DECL_DEBUG_EXPR_IS_FROM. Guard properly.
c/
* c-objc-common.c (c_tree_printer): Use DECL_HAS_DEBUG_EXPR_P
instead of DECL_DEBUG_EXPR_IS_FROM. Guard properly.
cp/
* error.c (cp_printer): Use DECL_HAS_DEBUG_EXPR_P instead of
DECL_DEBUG_EXPR_IS_FROM. Guard properly.
Index: trunk/gcc/c/c-objc-common.c
===
*** trunk.orig/gcc/c/c-objc-common.c2013-01-11 10:54:27.0 +0100
--- trunk/gcc/c/c-objc-common.c 2013-03-20 13:45:50.493148334 +0100
*** c_tree_printer (pretty_printer *pp, text
*** 112,118
switch (*spec)
{
case 'D':
! if (DECL_DEBUG_EXPR_IS_FROM (t) && DECL_DEBUG_EXPR (t))
{
t = DECL_DEBUG_EXPR (t);
if (!DECL_P (t))
--- 112,118
switch (*spec)
{
case 'D':
! if (TREE_CODE (t) == VAR_DECL && DECL_HAS_DEBUG_EXPR_P (t))
{
t = DECL_DEBUG_EXPR (t);
if (!DECL_P (t))
Index: trunk/gcc/cp/error.c
===
*** trunk.orig/gcc/cp/error.c 2013-03-18 09:55:06.0 +0100
--- trunk/gcc/cp/error.c2013-03-20 13:46:12.833394584 +0100
*** cp_printer (pretty_printer *pp, text_inf
*** 3283,3290
case 'D':
{
tree temp = next_tree;
! if (DECL_P (temp)
! && DECL_DEBUG_EXPR_IS_FROM (temp) && DECL_DEBUG_EXPR (temp))
{
temp = DECL_DEBUG_EXPR (temp);
if (!DECL_P (temp))
--- 3283,3290
case 'D':
{
tree temp = next_tree;
! if (TREE_CODE (temp) == VAR_DECL
! && DECL_HAS_DEBUG_EXPR_P (temp))
{
temp = DECL_DEBUG_EXPR (temp);
if (!DECL_P (temp))
Index: trunk/gcc/dwarf2out.c
===
*** trunk.orig/gcc/dwarf2out.c 2013-03-18 09:55:07.0 +0100
--- trunk/gcc/dwarf2out.c 2013-03-20 13:42:10.108689198 +0100
*** add_var_loc_to_decl (tree decl, rtx loc_
*** 5020,5026
struct var_loc_node *loc = NULL;
HOST_WIDE_INT bitsize = -1, bitpos = -1;
! if (DECL_DEBUG_EXPR_IS_FROM (decl))
{
tree realdecl = DECL_DEBUG_EXPR (decl);
if (realdecl
--- 5020,5026
struct var_loc_node *loc = NULL;
HOST_WIDE_INT bitsize = -1, bitpos = -1;
! if (DECL_HAS_DEBUG_EXPR_P (decl))
{
tree realdecl = DECL_DEBUG_EXPR (decl);
if (realdecl
Index: trunk/gcc/gimplify.c
===
*** trunk.orig/gcc/gimplify.c 2013-02-13 11:54:28.0 +0100
--- trunk/gcc/gimplify.c2013-03-20 13:42:29.761908693 +0100
*** gimplify_modify_expr (tree *expr_p, gimp
*** 4947,4953
if (!DECL_NAME (*from_p) && DECL_NAME (*to_p))
DECL_NAME (*from_p)
= create_tmp_var_name (IDENTIFIER_POINTER (DECL_NAME (*to_p)));
! DECL_DEBUG_EXPR_IS_FROM (*from_p) = 1;
SET_DECL_DEBUG_EXPR (*from_p, *to_p);
}
--- 4947,4953
if (!DECL_NAME (*from_p) && DECL_NAME (*to_p))
DECL_NAME (*from_p)
= create_tmp_var_name (IDENTIFIER_POINTER (DECL_NAME (*to_p)));
! DECL_HAS_DEBUG_EXPR_P (*from_p) = 1;
SET_DECL_DEBUG_EXPR (*from_p, *to_p);
}
Index: trunk/gcc/tree-cfg.c
===
*** trunk.orig/gcc/tree-cfg.c 2013-03-19 16:35:23.0 +0100
--- trunk/gcc/tree-cfg.c2013-03-20 13:42:33.816953991 +0100
*** verify_expr_location_1 (tree *tp, int *w
*** 4544,4550
struc
Re: [PATCH] Rename DECL_DEBUG_EXPR_IS_FROM to DECL_HAS_DEBUG_EXPR_P
On Wed, Mar 20, 2013 at 01:57:40PM +0100, Richard Biener wrote: > As discussed previously on IRC this patch does the renaming from > the confusing DECL_DEBUG_EXPR_IS_FROM to DECL_HAS_DEBUG_EXPR_P > which matches DECL_HAS_VALUE_EXPR_P (and it's behavior). Not sure if we actually guarantee that if DECL_HAS_DEBUG_EXPR_P, then it has non-NULL DECL_DEBUG_EXPR. I'm worried about copy_node somewhere copying a decl together with DECL_HAS_DEBUG_EXPR_P bit, but not adding anything into the hash table, or about LTO. Otherwise it looks good. Jakub
Re: [PATCH] Rename DECL_DEBUG_EXPR_IS_FROM to DECL_HAS_DEBUG_EXPR_P
On Wed, 20 Mar 2013, Jakub Jelinek wrote: > On Wed, Mar 20, 2013 at 01:57:40PM +0100, Richard Biener wrote: > > As discussed previously on IRC this patch does the renaming from > > the confusing DECL_DEBUG_EXPR_IS_FROM to DECL_HAS_DEBUG_EXPR_P > > which matches DECL_HAS_VALUE_EXPR_P (and it's behavior). > > Not sure if we actually guarantee that if DECL_HAS_DEBUG_EXPR_P, then > it has non-NULL DECL_DEBUG_EXPR. I'm worried about copy_node somewhere > copying a decl together with DECL_HAS_DEBUG_EXPR_P bit, but not adding > anything into the hash table, or about LTO. There are uses that do not guard against DECL_DEBUG_EXPR returning NULL so I thought requiring that when DECL_HAS_DEBUG_EXPR_P is set is good and consistent. > Otherwise it looks good. I'll take that as ok if it ends up working ;) Richard.
[PATCH] Incorporate INLINE_HINT_array_index in IPA-CP heuristics
Hi,
either it was added very late or I simply missed it in last stage1,
but currently IPA-CP does not use INLINE_HINT_array_index in any way.
This patch incorporates it to heuristics computations. I chose the
bonus value to simply be slightly smaller than the bonuses for known
strides and sizes, I plan to re-examine them once we have better
aggregate jump functions and we start getting these hints in real
Fortran benchmarks.
Bootstrapped and tested on x86_64-linux. OK for trunk?
Thanks,
Martin
2013-01-21 Martin Jambor
* params.def (PARAM_IPA_CP_ARRAY_INDEX_HINT_BONUS): New parameter.
* ipa-cp.c (hint_time_bonus): Add abonus for known array indices.
Index: src/gcc/ipa-cp.c
===
--- src.orig/gcc/ipa-cp.c
+++ src/gcc/ipa-cp.c
@@ -1606,9 +1606,12 @@ devirtualization_time_bonus (struct cgra
static int
hint_time_bonus (inline_hints hints)
{
+ int result = 0;
if (hints & (INLINE_HINT_loop_iterations | INLINE_HINT_loop_stride))
-return PARAM_VALUE (PARAM_IPA_CP_LOOP_HINT_BONUS);
- return 0;
+result += PARAM_VALUE (PARAM_IPA_CP_LOOP_HINT_BONUS);
+ if (hints & INLINE_HINT_array_index)
+result += PARAM_VALUE (PARAM_IPA_CP_ARRAY_INDEX_HINT_BONUS);
+ return result;
}
/* Return true if cloning NODE is a good idea, given the estimated TIME_BENEFIT
Index: src/gcc/params.def
===
--- src.orig/gcc/params.def
+++ src/gcc/params.def
@@ -919,6 +919,12 @@ DEFPARAM (PARAM_IPA_CP_LOOP_HINT_BONUS,
"bounds or strides known.",
64, 0, 0)
+DEFPARAM (PARAM_IPA_CP_ARRAY_INDEX_HINT_BONUS,
+ "ipa-cp-array-index-hint-bonus",
+ "Compile-time bonus IPA-CP assigns to candidates which make an array "
+ "index known.",
+ 48, 0, 0)
+
/* WHOPR partitioning configuration. */
DEFPARAM (PARAM_LTO_PARTITIONS,
[PATCH] Verify DECL_DEBUG/VALUE_EXPR have no associated blocks
This adds verification and simplifies clear_unused_block_pointer
accordingly (as previously discussed).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2013-03-20 Richard Biener
* tree-cfg.c (verify_expr_no_block): New function.
(verify_expr_location_1): Verify that neither DECL_DEBUG_EXPR
nor DECL_VALUE_EXPR have locations with associated blocks.
* tree-ssa-live.c (clear_unused_block_pointer_1): Remove.
(clear_unused_block_pointer): Remove code dealing with
blocks in DECL_DEBUG_EXPR locations.
Index: trunk/gcc/tree-cfg.c
===
*** trunk.orig/gcc/tree-cfg.c 2013-03-20 14:13:26.0 +0100
--- trunk/gcc/tree-cfg.c2013-03-20 14:17:36.152250539 +0100
*** verify_location (pointer_set_t *blocks,
*** 4536,4541
--- 4536,4559
return false;
}
+ /* Called via walk_tree. Verify that expressions have no blocks. */
+
+ static tree
+ verify_expr_no_block (tree *tp, int *walk_subtrees, void *)
+ {
+ if (!EXPR_P (*tp))
+ {
+ *walk_subtrees = false;
+ return NULL;
+ }
+
+ location_t loc = EXPR_LOCATION (*tp);
+ if (LOCATION_BLOCK (loc) != NULL)
+ return *tp;
+
+ return NULL;
+ }
+
/* Called via walk_tree. Verify locations of expressions. */
static tree
*** verify_expr_location_1 (tree *tp, int *w
*** 4547,4553
&& DECL_HAS_DEBUG_EXPR_P (*tp))
{
tree t = DECL_DEBUG_EXPR (*tp);
! tree addr = walk_tree (&t, verify_expr_location_1, blocks, NULL);
if (addr)
return addr;
}
--- 4565,4581
&& DECL_HAS_DEBUG_EXPR_P (*tp))
{
tree t = DECL_DEBUG_EXPR (*tp);
! tree addr = walk_tree (&t, verify_expr_no_block, NULL, NULL);
! if (addr)
! return addr;
! }
! if ((TREE_CODE (*tp) == VAR_DECL
!|| TREE_CODE (*tp) == PARM_DECL
!|| TREE_CODE (*tp) == RESULT_DECL)
! && DECL_HAS_VALUE_EXPR_P (*tp))
! {
! tree t = DECL_VALUE_EXPR (*tp);
! tree addr = walk_tree (&t, verify_expr_no_block, NULL, NULL);
if (addr)
return addr;
}
Index: trunk/gcc/tree-ssa-live.c
===
*** trunk.orig/gcc/tree-ssa-live.c 2013-03-20 14:13:26.0 +0100
--- trunk/gcc/tree-ssa-live.c 2013-03-20 14:15:21.630755347 +0100
*** clear_unused_block_pointer_1 (tree *tp,
*** 620,630
if (EXPR_P (*tp) && TREE_BLOCK (*tp)
&& !TREE_USED (TREE_BLOCK (*tp)))
TREE_SET_BLOCK (*tp, NULL);
- if (TREE_CODE (*tp) == VAR_DECL && DECL_HAS_DEBUG_EXPR_P (*tp))
- {
- tree debug_expr = DECL_DEBUG_EXPR (*tp);
- walk_tree (&debug_expr, clear_unused_block_pointer_1, NULL, NULL);
- }
return NULL_TREE;
}
--- 620,625
*** clear_unused_block_pointer (void)
*** 636,650
{
basic_block bb;
gimple_stmt_iterator gsi;
- tree t;
- unsigned i;
-
- FOR_EACH_LOCAL_DECL (cfun, i, t)
- if (TREE_CODE (t) == VAR_DECL && DECL_HAS_DEBUG_EXPR_P (t))
- {
- tree debug_expr = DECL_DEBUG_EXPR (t);
- walk_tree (&debug_expr, clear_unused_block_pointer_1, NULL, NULL);
- }
FOR_EACH_BB (bb)
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
--- 631,636
[PATCH] Sync copy_tree_body_r with remap_gimple_op_r
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Next I'll merge the two functions.
Richard.
2013-03-20 Richard Biener
* tree-inline.c (copy_tree_body_r): Sync MEM_REF code with
remap_gimple_op_r.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 196808)
+++ gcc/tree-inline.c (working copy)
@@ -1092,22 +1092,22 @@ copy_tree_body_r (tree *tp, int *walk_su
}
else if (TREE_CODE (*tp) == MEM_REF)
{
- /* We need to re-canonicalize MEM_REFs from inline substitutions
-that can happen when a pointer argument is an ADDR_EXPR. */
- tree decl = TREE_OPERAND (*tp, 0);
- tree *n;
+ tree ptr = TREE_OPERAND (*tp, 0);
+ tree type = remap_type (TREE_TYPE (*tp), id);
+ tree old = *tp;
- n = (tree *) pointer_map_contains (id->decl_map, decl);
- if (n)
- {
- tree old = *tp;
- *tp = fold_build2 (MEM_REF, TREE_TYPE (*tp),
-unshare_expr (*n), TREE_OPERAND (*tp, 1));
- TREE_THIS_VOLATILE (*tp) = TREE_THIS_VOLATILE (old);
- TREE_NO_WARNING (*tp) = TREE_NO_WARNING (old);
- *walk_subtrees = 0;
- return NULL;
- }
+ /* We need to re-canonicalize MEM_REFs from inline substitutions
+that can happen when a pointer argument is an ADDR_EXPR.
+Recurse here manually to allow that. */
+ walk_tree (&ptr, copy_tree_body_r, data, NULL);
+ *tp = fold_build2 (MEM_REF, type,
+ptr, TREE_OPERAND (*tp, 1));
+ TREE_THIS_NOTRAP (*tp) = TREE_THIS_NOTRAP (old);
+ TREE_THIS_VOLATILE (*tp) = TREE_THIS_VOLATILE (old);
+ TREE_SIDE_EFFECTS (*tp) = TREE_SIDE_EFFECTS (old);
+ TREE_NO_WARNING (*tp) = TREE_NO_WARNING (old);
+ *walk_subtrees = 0;
+ return NULL;
}
/* Here is the "usual case". Copy this tree node, and then
Re: [PATCH] Fix PR56605
Eric, thanks -- fixed in trunk. Looks like I've missed the window for 4.8.0. Is this OK for backport once 4.8 opens up again? (Copying Richi/Jakub as well.) Thanks, Bill On Mon, 2013-03-18 at 17:31 +0100, Eric Botcazou wrote: > > 2013-03-13 Bill Schmidt > > Steven Bosscher > > > > PR rtl-optimization/56605 > > * loop-iv.c (implies_p): Handle equal RTXs and subregs. > > > > gcc/testsuite: > > > > 2013-03-13 Bill Schmidt wschm...@linux.vnet.ibm.com> > > > > PR rtl-optimization/56605 > > * gcc.target/powerpc/pr56605.c: New. > > OK, thanks. >
Re: [PATCH] Fix PR56605
On Wed, Mar 20, 2013 at 08:45:16AM -0500, Bill Schmidt wrote: > Eric, thanks -- fixed in trunk. Looks like I've missed the window for > 4.8.0. Is this OK for backport once 4.8 opens up again? (Copying > Richi/Jakub as well.) Not for 4.8.0 (this isn't a wrong-code, just missed-optimization, right?), but guess for 4.8.1 it might be ok if it doesn't cause any issues on the trunk for a few weeks. > On Mon, 2013-03-18 at 17:31 +0100, Eric Botcazou wrote: > > > 2013-03-13 Bill Schmidt > > > Steven Bosscher > > > > > > PR rtl-optimization/56605 > > > * loop-iv.c (implies_p): Handle equal RTXs and subregs. > > > > > > gcc/testsuite: > > > > > > 2013-03-13 Bill Schmidt wschm...@linux.vnet.ibm.com> > > > > > > PR rtl-optimization/56605 > > > * gcc.target/powerpc/pr56605.c: New. > > > > OK, thanks. Jakub
Re: [PATCH] Fix PR56605
On Wed, 2013-03-20 at 14:50 +0100, Jakub Jelinek wrote: > On Wed, Mar 20, 2013 at 08:45:16AM -0500, Bill Schmidt wrote: > > Eric, thanks -- fixed in trunk. Looks like I've missed the window for > > 4.8.0. Is this OK for backport once 4.8 opens up again? (Copying > > Richi/Jakub as well.) > > Not for 4.8.0 (this isn't a wrong-code, just missed-optimization, right?), > but guess for 4.8.1 it might be ok if it doesn't cause any issues on the > trunk for a few weeks. Correct, just missed optimization. OK, I'll revisit it for 4.8 sometime next month. Thanks! Bill > > > On Mon, 2013-03-18 at 17:31 +0100, Eric Botcazou wrote: > > > > 2013-03-13 Bill Schmidt > > > > Steven Bosscher > > > > > > > > PR rtl-optimization/56605 > > > > * loop-iv.c (implies_p): Handle equal RTXs and subregs. > > > > > > > > gcc/testsuite: > > > > > > > > 2013-03-13 Bill Schmidt wschm...@linux.vnet.ibm.com> > > > > > > > > PR rtl-optimization/56605 > > > > * gcc.target/powerpc/pr56605.c: New. > > > > > > OK, thanks. > > Jakub >
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On Tue, 19 Mar 2013, Richard Henderson wrote:
On 03/19/2013 08:47 AM, Marc Glisse wrote:
(define_insn_and_split "avx__"
[(set (match_operand:AVX256MODE2P 0 "nonimmediate_operand" "=x,m")
- (unspec:AVX256MODE2P
- [(match_operand: 1 "nonimmediate_operand" "xm,x")]
- UNSPEC_CAST))]
+ (subreg:AVX256MODE2P
+ (match_operand: 1 "nonimmediate_operand" "xm,x") 0))]
"TARGET_AVX"
"#"
"&& reload_completed"
[(const_int 0)]
I'm not fond of this, primarily because I believe the pattern should
not exist at all.
Sure, removing it would be even better.
One of the following is true:
(1) reload needs working around (thus all the reload_completed nonsense)
or
(2) the entire pattern is useless and would be subsumed by mov
or
(3) the entire pattern is useless and is *already* subsumed by
mov, since mov is earlier in the md file, making this
pattern dead code.
We need something to expand _mm256_castpd128_pd256 to. I tried making it a
define_expand (with the subreg pattern, and keeping the {} part intact),
but that gives check_rtl errors in lra. I then tried to remove the REG_P
condition and use simplify_gen_subreg or gen_lowpart, but the first one
gives unrecognizable insn at -O0 (same as removing the {} part completely)
(it seems happier at -O1), while the second ICEs (gen_lowpart_common
returns 0) for any -Ox except -O0. As must be obvious from this paragraph,
I just tried a few random bad ideas... and when none worked I posted the
minimal patch that worked.
Do you at least agree that vector-vector subregs make sense, or is that
part wrong as well?
--
Marc Glisse
Re: [PATCH] Incorporate INLINE_HINT_array_index in IPA-CP heuristics
> Hi, > > either it was added very late or I simply missed it in last stage1, > but currently IPA-CP does not use INLINE_HINT_array_index in any way. > This patch incorporates it to heuristics computations. I chose the > bonus value to simply be slightly smaller than the bonuses for known > strides and sizes, I plan to re-examine them once we have better > aggregate jump functions and we start getting these hints in real > Fortran benchmarks. > > Bootstrapped and tested on x86_64-linux. OK for trunk? OK, Thanks! Honza
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On 03/20/2013 08:00 AM, Marc Glisse wrote: > Do you at least agree that vector-vector subregs make sense, or is that part > wrong as well? You mean a V4SImode subreg of a V8SImode register, not just same-size casting? It makes logical sense, but I'm fairly sure you'll need a lot more surgery throughout the compiler to make that happen. I'm curious how a define_expand can fail in LRA, but your define_insn succeeds? Is the failure because of ix86_cannot_change_mode_class? Because that hook fairly well defines what subregs are valid. And if that says it isn't valid, then even having a define_insn that uses such is wrong. r~
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On Wed, Mar 20, 2013 at 4:13 PM, Richard Henderson wrote: > On 03/20/2013 08:00 AM, Marc Glisse wrote: >> Do you at least agree that vector-vector subregs make sense, or is that part >> wrong as well? > > You mean a V4SImode subreg of a V8SImode register, not just same-size casting? > It makes logical sense, but I'm fairly sure you'll need a lot more surgery > throughout the compiler to make that happen. > > I'm curious how a define_expand can fail in LRA, but your define_insn > succeeds? > Is the failure because of ix86_cannot_change_mode_class? Because that hook > fairly well defines what subregs are valid. And if that says it isn't valid, > then even having a define_insn that uses such is wrong. Don't we have vec_select to get a V4SImode out of a V8SImode? So you only need a define_insn that special-cases the subreg-like ones? Richard. > > r~
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On Wed, 20 Mar 2013, Richard Henderson wrote: On 03/20/2013 08:00 AM, Marc Glisse wrote: Do you at least agree that vector-vector subregs make sense, or is that part wrong as well? You mean a V4SImode subreg of a V8SImode register, not just same-size casting? I am mostly interested in the reverse, a paradoxical subreg, since vec_select can only model one direction (and only rvalues, but that's a different question). It makes logical sense, but I'm fairly sure you'll need a lot more surgery throughout the compiler to make that happen. I'm curious how a define_expand can fail in LRA, but your define_insn succeeds? Total guesswork: I think it is related to that REG_P protected code, and the reload_complete test. With the define_insn_and_split, we keep the insn until after reload and only do the subreg magic then. With a define_expand, we end up writing to reg 60 as a V2DF and reading it as a V4DF, and since it isn't a hard register, that causes a problem. Is the failure because of ix86_cannot_change_mode_class? Because that hook fairly well defines what subregs are valid. And if that says it isn't valid, then even having a define_insn that uses such is wrong. A quick look at ix86_cannot_change_mode_class seems to indicate that it does not mind such paradoxical subregs. -- Marc Glisse
[PATCH] Speedup tree LIM some more
The following splits out a core idea out of the patch series
fixing up LIM. For the testcase in PR39326 it get's us from
tree loop invariant motion: 560.00 (78%) usr
TOTAL : 721.06
to
tree loop invariant motion: 109.44 (40%) usr
TOTAL : 274.15
by choosing a different (than "random") order we assign mem-ref IDs
to memory references. The idea is to assign adjacent IDs to memory
references in a loop, it's siblings and then its parents. Inside
a loop the ordering is still random but that shouldn't matter.
Bootstrap and testing on x86_64-unknown-linux-gnu pending.
A patch dropping the two cache bitmaps for alias queries makes it
even faster (that cache has only a hit-rate of around 5%, quite
expensive for its quadratic memory use...)
tree loop invariant motion: 60.58 (27%) usr
TOTAL : 222.37
but that definitely needs more testing (this testcase is really
bitmap memory bound in LIM).
(still trying to order changes to LIM in
best-and-least-dangerous-for-backporting order)
Richard.
2013-03-20 Richard Biener
PR tree-optimization/39326
* tree-ssa-loop-im.c (bb_loop_postorder): New global static.
(sort_bbs_in_loop_postorder_cmp): New function.
(gather_mem_refs_in_loops): Assign mem-ref IDs in loop
postorder.
Index: gcc/tree-ssa-loop-im.c
===
*** gcc/tree-ssa-loop-im.c (revision 196828)
--- gcc/tree-ssa-loop-im.c (working copy)
*** gather_mem_refs_stmt (struct loop *loop,
*** 1622,1648
return;
}
/* Gathers memory references in loops. */
static void
gather_mem_refs_in_loops (void)
{
gimple_stmt_iterator bsi;
! basic_block bb;
struct loop *loop;
loop_iterator li;
bitmap lrefs, alrefs, alrefso;
FOR_EACH_BB (bb)
! {
! loop = bb->loop_father;
! if (loop == current_loops->tree_root)
! continue;
for (bsi = gsi_start_bb (bb); !gsi_end_p (bsi); gsi_next (&bsi))
! gather_mem_refs_stmt (loop, gsi_stmt (bsi));
}
/* Propagate the information about accessed memory references up
the loop hierarchy. */
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
--- 1622,1683
return;
}
+ static unsigned *bb_loop_postorder;
+
+ /* qsort sort function to sort blocks after their loop fathers postorder. */
+
+ static int
+ sort_bbs_in_loop_postorder_cmp (const void *bb1_, const void *bb2_)
+ {
+ basic_block bb1 = *(basic_block *)const_cast(bb1_);
+ basic_block bb2 = *(basic_block *)const_cast(bb2_);
+ struct loop *loop1 = bb1->loop_father;
+ struct loop *loop2 = bb2->loop_father;
+ if (loop1->num == loop2->num)
+ return 0;
+ return bb_loop_postorder[loop1->num] < bb_loop_postorder[loop2->num] ? -1 :
1;
+ }
+
/* Gathers memory references in loops. */
static void
gather_mem_refs_in_loops (void)
{
gimple_stmt_iterator bsi;
! basic_block bb, *bbs;
struct loop *loop;
loop_iterator li;
bitmap lrefs, alrefs, alrefso;
+ unsigned i, n;
+ /* Initialize bb_loop_postorder with a mapping from loop->num to
+ its postorder index. */
+ i = 0;
+ bb_loop_postorder = XNEWVEC (unsigned, number_of_loops ());
+ FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
+ bb_loop_postorder[loop->num] = i++;
+ /* Collect all basic-blocks in loops and sort them after their
+ loops postorder. */
+ i = 0;
+ bbs = XNEWVEC (basic_block, n_basic_blocks - NUM_FIXED_BLOCKS);
FOR_EACH_BB (bb)
! if (bb->loop_father != current_loops->tree_root)
! bbs[i++] = bb;
! n = i;
! qsort (bbs, n, sizeof (basic_block), sort_bbs_in_loop_postorder_cmp);
! free (bb_loop_postorder);
+ /* Visit blocks in loop postorder and assign mem-ref IDs in that order.
+ That results in better locality for all the bitmaps. */
+ for (i = 0; i < n; ++i)
+ {
+ basic_block bb = bbs[i];
for (bsi = gsi_start_bb (bb); !gsi_end_p (bsi); gsi_next (&bsi))
! gather_mem_refs_stmt (bb->loop_father, gsi_stmt (bsi));
}
+ free (bbs);
+
/* Propagate the information about accessed memory references up
the loop hierarchy. */
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On Wed, Mar 20, 2013 at 4:29 PM, Marc Glisse wrote: > On Wed, 20 Mar 2013, Richard Henderson wrote: > >> On 03/20/2013 08:00 AM, Marc Glisse wrote: >>> >>> Do you at least agree that vector-vector subregs make sense, or is that >>> part >>> wrong as well? >> >> >> You mean a V4SImode subreg of a V8SImode register, not just same-size >> casting? > > > I am mostly interested in the reverse, a paradoxical subreg, since > vec_select can only model one direction (and only rvalues, but that's a > different question). vec_duplicate? Honestly, what semantics should _mm256_castpd128_pd256 have if it is supposed to cast a v2df to a v4df? Or what use? Richard.
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On Wed, 20 Mar 2013, Richard Biener wrote: On Wed, Mar 20, 2013 at 4:29 PM, Marc Glisse wrote: On Wed, 20 Mar 2013, Richard Henderson wrote: On 03/20/2013 08:00 AM, Marc Glisse wrote: Do you at least agree that vector-vector subregs make sense, or is that part wrong as well? You mean a V4SImode subreg of a V8SImode register, not just same-size casting? I am mostly interested in the reverse, a paradoxical subreg, since vec_select can only model one direction (and only rvalues, but that's a different question). vec_duplicate? There is already some of that in various places, and there may be even more vec_merge+vec_duplicate patterns soon, but you want to make sure you don't actually do the duplication. Honestly, what semantics should _mm256_castpd128_pd256 have if it is supposed to cast a v2df to a v4df? NOP. We don't care what is in the high part of the vector. Or what use? Many vector operations are defined as taking 2 vectors and merging them somehow. I didn't check if this case works, but for instance if you want to copy a V2DF to the bottom part of a V4DF using Intel's intrinsics, you will probably have to cast the V2DF to a V4DF and then use an intrinsic that takes 2 V4DF. (there are many issues with those intrinsics, but we don't control them) -- Marc Glisse
Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
On 03/20/13 10:30, Aldy Hernandez wrote:
I have found some little nits that I will point out in a reply to this
message.
Joseph, folks, et al... How does this look?
Thanks.
Balaji:
+void
+array_notation_init_builtins (void)
+{
+ tree func_type = NULL_TREE;
+ tree new_func = NULL_TREE;
+ func_type = build_function_type_list (integer_type_node, ptr_type_node,
+ NULL_TREE);
+ new_func = build_fn_decl ("__sec_reduce_add", func_type);
+ mark_cold (new_func);
+ new_func = lang_hooks.decls.pushdecl (new_func);
etc
etc
All these builtins need to be documented in doc/.
+load_lib gcc-dg.exp
+
+dg-init
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] " -fcilkplus" " "
+dg-finish
+
+dg-init
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] " -O0 -fcilkplus" " "
+dg-finish
+
+dg-init
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] " -O1 -fcilkplus" " "
+dg-finish
etc
etc
Can't you do all these dg-runtest's within one pair of
dg-init/dg-finish? Similarly for the other .exp files.
As I'd mentioned, you have .exp files named compile.exp and execute.exp
which seem to be causing ambiguity problems in parallel checks (make
check -jN). For some reason, with this patch, the rest of dg.exp fails
to run after Cilkplus' compile/execute.exp runs. Renaming these to
something less generic does the trick. Do you mind prefixing all the
.exp's with "cilkplus_" or something similar?
[Perhaps someone can pontificate as to what the actual problem is here
and describe it. Dejagnu is a mystery to me.]
diff --git a/gcc/testsuite/gcc.dg/cilk-plus/array_notation/errors/errors.exp
b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/errors/errors.exp
new file mode 100644
index 000..6d7604b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/errors/errors.exp
@@ -0,0 +1,65 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+
+# This program 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 of the License, or
+# (at your option) any later version.
+#
+# This program 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 copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
Re: [Patch, microblaze]: Add atomic builtin implementation
On 03/18/2013 05:48 AM, David Holsgrove wrote: > * gcc/config/microblaze/sync.md: New file. > * gcc/config/microblaze/microblaze.md: Add UNSPEC_SYNC_CAS, >UNSPEC_SYNC_XCHG and include sync.md. > * gcc/config/microblaze/microblaze.c: Add print_operand 'y'. > * gcc/config/microblaze/constraints.md: Add memory_contraint >'Q' which is a single register. Do not add new __sync implementations. Use the __atomic builtins. r~
[PATCH, AArch64] Make MOVK output operand 2 in hex
MOVK should not be generated with a negative immediate, which
the assembler rightfully rejects.
This patch makes MOVK output its 2nd operand in hex instead.
Tested on bare-metal and linux.
OK for trunk?
Cheers,
Ian
2013-03-20 Ian Bolton
gcc/
* config/aarch64/aarch64.c (aarch64_print_operand): New
format specifier for printing a constant in hex.
* config/aarch64/aarch64.md (insv_imm): Use the X
format specifier for printing second operand.
testsuite/
* gcc.target/aarch64/movk.c: New test.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1404a70..5e51630 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3365,6 +3365,16 @@ aarch64_print_operand (FILE *f, rtx x, char code)
REGNO (x) - V0_REGNUM + (code - 'S'));
break;
+case 'X':
+ /* Print integer constant in hex. */
+ if (GET_CODE (x) != CONST_INT)
+ {
+ output_operand_lossage ("invalid operand for '%%%c'", code);
+ return;
+ }
+ asm_fprintf (f, "0x%x", UINTVAL (x));
+ break;
+
case 'w':
case 'x':
/* Print a general register name or the zero register (32-bit or
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 40e66db..9c89413 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -850,8 +850,8 @@
(match_operand:GPI 2 "const_int_operand" "n"))]
"INTVAL (operands[1]) < GET_MODE_BITSIZE (mode)
&& INTVAL (operands[1]) % 16 == 0
- && INTVAL (operands[2]) <= 0x"
- "movk\\t%0, %2, lsl %1"
+ && UINTVAL (operands[2]) <= 0x"
+ "movk\\t%0, %X2, lsl %1"
[(set_attr "v8type" "movk")
(set_attr "mode" "")]
)
diff --git a/gcc/testsuite/gcc.target/aarch64/movk.c
b/gcc/testsuite/gcc.target/aarch64/movk.c
new file mode 100644
index 000..e4b2209
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/movk.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps -fno-inline" } */
+
+extern void abort (void);
+
+long long int
+dummy_number_generator ()
+{
+ /* { dg-final { scan-assembler "movk\tx\[0-9\]+, 0xefff, lsl 16" } } */
+ /* { dg-final { scan-assembler "movk\tx\[0-9\]+, 0xc4cc, lsl 32" } } */
+ /* { dg-final { scan-assembler "movk\tx\[0-9\]+, 0xfffe, lsl 48" } } */
+ return -346565474575675;
+}
+
+int
+main (void)
+{
+
+ long long int num = dummy_number_generator ();
+ if (num > 0)
+abort ();
+
+ /* { dg-final { scan-assembler "movk\tx\[0-9\]+, 0x4667, lsl 16" } } */
+ /* { dg-final { scan-assembler "movk\tx\[0-9\]+, 0x7a3d, lsl 32" } } */
+ if (num / 69313094915135 != -5)
+abort ();
+
+ return 0;
+}
+
+/* { dg-final { cleanup-saved-temps } } */
Re: PATCH: PR target/56560: [4.6/4.7 regression] vzeroupper clobbers argument with AVX
On Mon, Mar 18, 2013 at 6:51 PM, H.J. Lu wrote: > ix86_function_arg sets cfun->machine->callee_pass_avx256_p from the > current argument. It clears callee_pass_avx256_p when ix86_function_arg > is called to generate a library call to passs an argument. This patch > adds callee_pass_avx256_p and callee_return_avx256_p to ix86_args to store > the AVX info in CUM and copy it to cfun->machine->callee_pass_avx256_p > when ix86_function_arg is called immediately before the call instruction > is emitted. OK for 4.7 branch? > > 2013-03-18 H.J. Lu > > PR target/56560 > * config/i386/i386.c (init_cumulative_args): Also set > cum->callee_return_avx256_p. > (ix86_function_arg): Set cum->callee_pass_avx256_p. Set > cfun->machine->callee_pass_avx256_p only when MODE == VOIDmode. > > * config/i386/i386.h (ix86_args): Add callee_pass_avx256_p and > callee_return_avx256_p. > > gcc/ > > 2013-03-18 H.J. Lu > > PR target/56560 > * gcc.target/i386/pr56560.c: New file. OK for branches, but I didn't check all state transitions (and I don't like this approach anyway)... Please also add the testcase to the trunk, and to 4.8 branch when it reopens. Thanks, Uros.
RE: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.
> From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: 15 March 2013 13:06 > On Fri, Mar 15, 2013 at 08:00:50AM -0500, Gabriel Dos Reis wrote: > > On Fri, Mar 15, 2013 at 3:51 AM, Richard Biener > > wrote: > > > On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse > wrote: > > >> On Thu, 14 Mar 2013, Jakub Jelinek wrote: > > >> > > >>> I wonder if it wouldn't be better to fold the target builtins > only later > > >>> on > > >>> (e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or > if we have > > >>> any predicate that is set starting with gimplification or so)). > > >>> Having all the FEs have to deal with myriads of weird tree codes > etc. > > >>> isn't > > >>> IMHO desirable. > > >> > > >> > > >> Wouldn't that prevent from using those builtins in constant > expressions? > > >> That seems undesirable. Maybe an alternative could be to push some > of the > > >> functionality from potential_constant_expression_1 to the middle- > end? > > > > > > True, but is that bad? > > > > > > If we want to delay such folding then please don't do it with a > magic flag > > > but instead do the folding only via fold_stmt - that is, add a new > target hook > > > that folds a gimple call. I bet we have only a very limited set of > target call > > > foldings, so transitioning them all to fold gimple calls would be > easy. > > > > upon reflection, I think we don't want to delay. the C++ front-end > > needs to know (while type checking) whether a certain operation > > can be evaluated at compile time and possibly get the value of the > > operation. > > If all arguments to the target builtin constant, then it better not be > folded into REDUC_PLUS_EXPR, but instead just some constant. That is > just > fine. If all arguments to the target builtin aren't constant, then it > won't > be a constant expression anyway, there is no point in showing all those > weird tree codes to the FE. So based on this argument, while a front-end may not need to implement all the weird tree codes it should at least have a sensible default case for an tree code which it doesn't understand. That would suggest the correct fix would be to change potential_constant_expression_1 to simply return false if it encounters a tree it doesn't know about, rather than the current gcc_unreachable (). The argument would be; if we found an unexpected tree code then it must have been introduced by folding. If it was a constant, folding would have returned the constant not the expression. So it must not be a constant. Is that be sensible? It certainly seems like someone intended to explicitly enumerate all the possible cases and ensure that they were correctly handled. I have some other patches kicking around which will fold to REDUC_MAX_EXPR, which will be another unhandled tree code. The approach of adding a case in potential_constant_expression_1 each time a shiny new tree code appears just feels wrong. James
Re: [PATCH] Improve debug info for various cases where we drop location info on the floor (PR debug/55608)
> Now that Stage 1 reopened, is this ok for 4.9?
Looks OK to me; I just had a few comments on the code readability.
> + if (lookup_decl_die (decl))
> +return rtl;
> +
> + len = TREE_STRING_LENGTH (t);
> + vec_safe_push (used_rtx_array, rtl);
> + ref = new_die (DW_TAG_dwarf_procedure, comp_unit_die (), decl);
> + array = (unsigned char *) ggc_alloc_atomic (len);
> + memcpy (array, TREE_STRING_POINTER (t), len);
> + l = new_loc_descr (DW_OP_implicit_value, len, 0);
> + l->dw_loc_oprnd2.val_class = dw_val_class_vec;
> + l->dw_loc_oprnd2.v.val_vec.length = len;
> + l->dw_loc_oprnd2.v.val_vec.elt_size = 1;
> + l->dw_loc_oprnd2.v.val_vec.array = array;
> + add_AT_loc (ref, DW_AT_location, l);
> + equate_decl_number_to_die (decl, ref);
> + return rtl;
This is just a suggestion -- rewrite the above as:
if (!lookup_decl_die (decl))
{
...
}
return rtl;
This makes it more clear that you're actually returning the same thing
in either case, and that the creation of the dwarf procedure is just
a side effect. When I read through this the first time, I was expecting
the fall-through path to return something different just because of the
structure.
> - for (; loc; loc = loc->dw_loc_next)
> + bool start_of_dw_expr = true;
> + for (; loc; start_of_dw_expr = (loc->dw_loc_opc == DW_OP_piece
> + || loc->dw_loc_opc == DW_OP_bit_piece),
> + loc = loc->dw_loc_next)
Another suggestion to make this a little less unwieldy:
for (dw_loc_descr_ref prev = NULL; loc; prev = loc, loc = loc->dw_loc_next)
...
if ((prev == NULL
|| prev->dw_loc_opc == DW_OP_piece
|| prev->dw_loc_opc == DW_OP_bit_piece)
&& loc->dw_loc_next
&& loc->dw_loc_next->dw_loc_opc == DW_OP_stack_value
&& !dwarf_strict)
{
...
}
Can you replace the { ... } with a function call? And a comment about
what you're doing here.
> + if (l != NULL
> + && l->dw_loc_next == NULL
> + && l->dw_loc_opc == DW_OP_addr
> + && GET_CODE (l->dw_loc_oprnd1.v.val_addr) == SYMBOL_REF
> + && SYMBOL_REF_DECL (l->dw_loc_oprnd1.v.val_addr)
> + && a->dw_attr == DW_AT_location)
> + {
> + ...
> + }
Likewise here.
-cary
Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.
On Wed, Mar 20, 2013 at 1:03 PM, James Greenhalgh wrote: > Is that be sensible? It certainly seems like someone intended to > explicitly enumerate all the possible cases and ensure that they were > correctly handled. That someone would be me. We need to catch loudly any front-end tree code, e.g. ASTs, object we may have missed, as opposed to silently ignoring them with possible miscompilation and pray that someone might be sufficiently pissed off and report it as a bug. What is wrong isn't that the front-end inserts internal coverage check; rather it is the fact that we don't have enough separation between front-end asts and middle-end stuff. The convenience of adding a middle-end optimization (which this essentially is) should not trump correctness of the implementation of standard semantics. -- Gaby
Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.
On 03/20/2013 02:03 PM, James Greenhalgh wrote: The argument would be; if we found an unexpected tree code then it must have been introduced by folding. If it was a constant, folding would have returned the constant not the expression. So it must not be a constant. Unless the operands involve calls to constexpr functions, which aren't folded by fold. Jason
[PATCH, i386]: Emit insn template of move insn depending on insn type attribute
Hello!
The patch changes move insn patterns to output insn template depending
on their type attribute, not which_alternative.
2013-03-20 Uros Bizjak
* config/i386/i386.md (*movoi_internal_avx): Emit insn template
depending on type attribute.
(*movti_internal): Ditto.
(*movtf_internal): Ditto.
(*movxf_internal): Ditto.
(*movdf_internal): Ditto.
(*movsf_internal): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline.
Uros.
Index: i386.md
===
--- i386.md (revision 196837)
+++ i386.md (working copy)
@@ -1758,12 +1758,12 @@
(match_operand:OI 1 "vector_move_operand" "C ,xm,x"))]
"TARGET_AVX && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
- switch (which_alternative)
+ switch (get_attr_type (insn))
{
-case 0:
+case TYPE_SSELOG1:
return standard_sse_constant_opcode (insn, operands[1]);
-case 1:
-case 2:
+
+case TYPE_SSEMOV:
if (misaligned_operand (operands[0], OImode)
|| misaligned_operand (operands[1], OImode))
{
@@ -1779,6 +1779,7 @@
else
return "vmovdqa\t{%1, %0|%0, %1}";
}
+
default:
gcc_unreachable ();
}
@@ -1800,15 +1801,15 @@
"(TARGET_64BIT || TARGET_SSE)
&& !(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
- switch (which_alternative)
+ switch (get_attr_type (insn))
{
-case 0:
-case 1:
+case TYPE_MULTI:
return "#";
-case 2:
+
+case TYPE_SSELOG1:
return standard_sse_constant_opcode (insn, operands[1]);
-case 3:
-case 4:
+
+case TYPE_SSEMOV:
/* TDmode values are passed as TImode on the stack. Moving them
to stack may result in unaligned memory access. */
if (misaligned_operand (operands[0], TImode)
@@ -1826,12 +1827,13 @@
else
return "%vmovdqa\t{%1, %0|%0, %1}";
}
+
default:
gcc_unreachable ();
}
}
[(set_attr "isa" "x64,x64,*,*,*")
- (set_attr "type" "*,*,sselog1,ssemov,ssemov")
+ (set_attr "type" "multi,multi,sselog1,ssemov,ssemov")
(set (attr "prefix")
(if_then_else (eq_attr "type" "sselog1,ssemov")
(const_string "maybe_vex")
@@ -1914,7 +1916,7 @@
case TYPE_LEA:
return "lea{q}\t{%E1, %0|%0, %E1}";
-default:
+case TYPE_IMOV:
gcc_assert (!flag_pic || LEGITIMATE_PIC_OPERAND_P (operands[1]));
if (get_attr_mode (insn) == MODE_SI)
return "mov{l}\t{%k1, %k0|%k0, %k1}";
@@ -1924,6 +1926,9 @@
return "lea{q}\t{%E1, %0|%0, %E1}";
else
return "mov{q}\t{%1, %0|%0, %1}";
+
+default:
+ gcc_unreachable ();
}
}
[(set (attr "isa")
@@ -2018,14 +2023,18 @@
case TYPE_SSEMOV:
switch (get_attr_mode (insn))
{
+ case MODE_SI:
+ return "%vmovd\t{%1, %0|%0, %1}";
case MODE_TI:
return "%vmovdqa\t{%1, %0|%0, %1}";
+
case MODE_V4SF:
return "%vmovaps\t{%1, %0|%0, %1}";
- case MODE_SI:
- return "%vmovd\t{%1, %0|%0, %1}";
+
case MODE_SF:
- return "%vmovss\t{%1, %0|%0, %1}";
+ gcc_assert (!TARGET_AVX);
+ return "movss\t{%1, %0|%0, %1}";
+
default:
gcc_unreachable ();
}
@@ -2041,12 +2050,15 @@
case TYPE_LEA:
return "lea{l}\t{%E1, %0|%0, %E1}";
-default:
+case TYPE_IMOV:
gcc_assert (!flag_pic || LEGITIMATE_PIC_OPERAND_P (operands[1]));
if (ix86_use_lea_for_mov (insn, operands))
return "lea{l}\t{%E1, %0|%0, %E1}";
else
return "mov{l}\t{%1, %0|%0, %1}";
+
+default:
+ gcc_unreachable ();
}
}
[(set (attr "type")
@@ -2631,12 +2643,12 @@
|| (!TARGET_MEMORY_MISMATCH_STALL
&& memory_operand (operands[0], TFmode)))"
{
- switch (which_alternative)
+ switch (get_attr_type (insn))
{
-case 0:
+case TYPE_SSELOG1:
return standard_sse_constant_opcode (insn, operands[1]);
-case 1:
-case 2:
+
+case TYPE_SSEMOV:
/* Handle misaligned load/store since we
don't have movmisaligntf pattern. */
if (misaligned_operand (operands[0], TFmode)
@@ -2655,8 +2667,7 @@
return "%vmovdqa\t{%1, %0|%0, %1}";
}
-case 3:
-case 4:
+case TYPE_MULTI:
return "#";
default:
@@ -2664,7 +2675,7 @@
}
}
[(set_attr "isa" "*,*,*,x64,x64")
- (set_attr "type" "sselog1,ssemov,ssemov,*,*")
+ (set_attr "type" "sselog1,ssemov,ssemov,multi,multi")
(set (attr "prefix")
(if_then_else (eq_attr "type" "sselog1,ssemov")
(const_string "maybe_vex")
@@ -2701,18 +2712,14 @@
|| (!TARGET_MEMORY_MISMATCH_STALL
&& memory_operand (operands[0], XFmode)))"
{
- switch (which_alternative)
+ switch (get_attr_type (insn))
{
-case 0:
-case 1:
+case TYPE_FMOV:
+ if (which_alternative == 2)
+
RE: FW: [PATCH] [MIPS] microMIPS gcc support
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Tuesday, March 19, 2013 4:38 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
>
> "Moore, Catherine" writes:
> >> -Original Message-
> >> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> >> Sent: Tuesday, March 19, 2013 3:26 PM
> >> To: Moore, Catherine
> >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
> >>
> >> "Moore, Catherine" writes:
> >> >> >> -Original Message-
> >> >> >> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> >> >> >> Sent: Tuesday, March 05, 2013 4:06 PM
> >> >> >> To: Moore, Catherine
> >> >> >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> >> >> >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support:
> >> >> >>
> >> >> >> We have a few internal-only undocumented constraints that
> >> >> >> aren't used much, so we should be able to move them to the "Y"
> >> >> >> space
> >> instead.
> >> >> >> The patch below does this for "T" and "U". Then we could use "U"
> >> >> >> for new, longer constraints.
> >> >> >>
> >> >> >>
> >> >> >> U
> >> >> >>
> >> >> >> where is:
> >> >> >>
> >> >> >> s for signed
> >> >> >> u for unsigned
> >> >> >> d for decremented unsigned (-1 ... N)
> >> >> >> i for incremented unsigned (1 ... N)
> >> >> >>
> >> >> >> where is:
> >> >> >>
> >> >> >> b for "byte" (*1)
> >> >> >> h for "halfwords" (*2)
> >> >> >> w for "words" (*4)
> >> >> >> d for "doublewords" (*8) -- useful for 64-bit MIPS16 but probably
> not
> >> >> >> needed for 32-bit microMIPS
> >> >> >>
> >> >> >> and where is the number of bits. and
> >> >> >> could be replaced with an ad-hoc two-letter combination for special
> cases.
> >> >> >> E.g. "Uas9" ("add stack") for ADDISUP.
> >> >> >>
> >> >> >> Just a suggestion though. I'm not saying these names are
> >> >> >> totally intuitive or anything, but they should at least be
> >> >> >> better than arbitrary
> >> >> letters.
> >> >> >>
> >> >> >> Also, could be two digits if necessary, or we could just
> >> >> >> use hex
> >> >> digits.
> >> >> >
> >> >> > I extended this proposal a bit by:
> >> >> > 1. Adding a e for encoded. The constraint will start
> >> >> > with Ue, when the operand is an encoded value.
> >> >> > 2. I decided to use two digits for .
> >> >> > 3. The ad-hoc combination is used for anything else.
> >> >>
> >> >> First of all, thanks for coming up with a counter-suggestion. I'm
> >> >> hopeless at naming things, so I was hoping there would be at least
> >> >> some
> >> pushback.
> >> >>
> >> >> "e" for "encoded" sounds good. I'm less keen on the mixture of
> >> >> single- and double-digit widths though (single digit for some
> >> >> "Ue"s, double digits for other "U"s.) I think we should either:
> >> >>
> >> >> (a) use the same number of digits for all "U" constraints. That leaves
> >> >> one character for the "Ue" type, which isn't as mnemonic, but is in
> >> >> line with what we do elsewhere.
> >> >>
> >> >> (b) avoid digits in the "Ue" forms and just have an ad-hoc letter
> >> combination.
> >>
> >> FWIW, as far as this point goes, the patch still has "Uea4".
> >>
> >> >> > +/* Return true if X is a legitimate address that conforms to
> >> >> > +the
> >> >> requirements
> >> >> > + for any of the short microMIPS LOAD or STORE instructions
> >> >> > + except
> >> LWSP
> >> >> > + or SWSP. */
> >> >> > +
> >> >> > +bool
> >> >> > +umips_address_p (rtx x, bool load, enum machine_mode mode) {
> >> >> > +
> >> >> > + struct mips_address_info addr;
> >> >> > + bool ok = mips_classify_address (&addr, x, mode, false)
> >> >> > + && addr.type == ADDRESS_REG
> >> >> > + && M16_REG_P (REGNO (addr.reg))
> >> >> > + && CONST_INT_P (addr.offset);
> >> >> > +
> >> >> > + if (!ok)
> >> >> > +return false;
> >> >> > +
> >> >> > + if (mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
> >> >> > + || mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 1))
> >> >> > +return true;
> >> >> > +
> >> >> > + if (load && IN_RANGE (INTVAL (addr.offset), -1, 14))
> >> >> > +return true;
> >> >> > +
> >> >> > + if (!load && IN_RANGE (INTVAL (addr.offset), 0, 15))
> >> >> > +return true;
> >> >> > +
> >> >> > + return false;
> >> >> > +
> >> >> > +}
> >> >>
> >> >> No blank lines after "{" and before "}".
> >> >>
> >> >> More importantly, what cases are these range tests covering?
> >> >> Both binutils and qemu seem to think that LW and SW need offsets
> >> >> that exactly match:
> >> >>
> >> >> mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
> >> >>
> >> >
> >> > Those range tests are for the LBU16 and SB16 instructions. LBU16
> >> > supports offsets from -1 to 14 (encodes -1 as 15) while the SB16
> >> > insn supports offsets from 0-15.
> >>
> >> They need to u
Re: [PATCH] Fix vectorizer fallout
The gfortran testsuite on PowerPC now produces a number of new ICEs when vectorization is enabled: /tmp/20130320/gcc/testsuite/gfortran/../../gfortran -B/tmp/20130320/gcc/testsuite/gfortran/../../ -B/tmp/20130320/powerpc-ibm-aix7.1.0.0/./libgfortran/ /nasfarm/dje/src/src/gcc/testsuite/gfortran.fortran-torture/execute/scalarize2.f90 -fno-diagnostics-show-caret -w -O2 -ftree-vectorize -maltivec /nasfarm/dje/src/src/gcc/testsuite/gfortran.fortran-torture/execute/scalarize2.f90: In function 'main': /nasfarm/dje/src/src/gcc/testsuite/gfortran.fortran-torture/execute/scalarize2.f90:23:0: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:1008 similarly for nasfarm/dje/src/src/gcc/testsuite/gfortran.dg/vect/vect-2.f90: In function 'foo': /nasfarm/dje/src/src/gcc/testsuite/gfortran.dg/vect/vect-2.f90:4:0: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:1008 - David
[Patch, Fortran, OOP] PR 56500: "IMPLICIT CLASS(...)" wrongly rejected
Hi all, here is a simple patch which fixes some problems with IMPLICT CLASS(...) statements. Actually that's not a feature I would seriously recommend anyone to use, but the Fortran standard allows it, so I guess we should better support it ;) The short patch attached here replaces all previous draft patches in the PR and simultaneously fixes both comment 0 and 1. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2013-03-20 Janus Weil PR fortran/56500 * symbol.c (gfc_set_default_type): Build class container for IMPLICIT CLASS. 2013-03-20 Janus Weil PR fortran/56500 * gfortran.dg/implicit_class_1.f90: New. pr56500_v4.diff Description: Binary data implicit_class_1.f90 Description: Binary data
Re: FW: [PATCH] [MIPS] microMIPS gcc support
"Moore, Catherine" writes:
> Index: gcc/config/mips/constraints.md
> ===
> --- gcc/config/mips/constraints.md(revision 196638)
> +++ gcc/config/mips/constraints.md(working copy)
> @@ -43,6 +43,9 @@
> (define_register_constraint "b" "ALL_REGS"
>"@internal")
>
> +(define_register_constraint "u" "M16_REGS"
> + "@internal")
> +
> ;; MIPS16 code always calls through a MIPS16 register; see
> mips_emit_call_insn
> ;; for details.
> (define_register_constraint "c" "TARGET_MIPS16 ? M16_REGS
> @@ -170,6 +173,41 @@
>(and (match_operand 0 "call_insn_operand")
> (match_test "CONSTANT_P (op)")))
>
> +(define_constraint "Udb7"
> + "@internal
> + A decremented unsigned constant of 7 bits."
> + (match_operand 0 "db7_operand"))
> +
> +(define_constraint "Uea4"
> + "@internal
> + A microMIPS encoded ADDIUR2 immediate operand."
> + (match_operand 0 "addiur2_operand"))
I'm still wary of having digits for some "Ue"s and not others,
especially because (as I understand it) ADDIUR2 takes a 3-bit rather
than 4-bit operand. How about "Ueau" here (= add of "u" register).
For consistency...
> +(define_constraint "Ueim"
> + "@internal
> + A microMIPS encoded ADDIUSP operand."
> + (match_operand 0 "addiusp_operand" ""))
...this could be "Ueas" (= add of stack register). Redundant "".
> +(define_constraint "Uesp"
> + "@internal
> + A microMIPS encoded ADDIUR1SP operand."
> + (match_operand 0 "addiur1sp_operand" ""))
This is "6 bits zero extended and shifted left twice", so the constraint
should be "Uuw6" and the predicate should be "uw6_operand". Redundant "".
> +(define_memory_constraint "ZS"
> + "@internal
> + A microMIPS memory operand for use with the LWSP/SWSP insns."
> + (and (match_code "mem")
> + (match_operand 0 "umips_lwsp_swsp_operand")))
> +
> +(define_memory_constraint "ZT"
> + "@internal
> + A microMIPS memory operand for use with the various LOAD insns."
> + (and (match_code "mem")
> + (match_operand 0 "umips_load_operand")))
> +
> +(define_memory_constraint "ZU"
> + "@internal
> + A microMIPS memory operand for use with the various STORE insns."
> + (and (match_code "mem")
> + (match_operand 0 "umips_store_operand")))
As I mentioned before, we need a separate predicate and constraint for
each range. We can't have things like:
> + /* For the LBU16 insn. */
> + if (load && db4_operand (addr.offset, mode))
> +return true;
> +
> + /* For the SB16 insn. */
> + if (!load && ub4_operand (addr.offset, mode))
> +return true;
> +
> + /* For SH16, LHU16, SW16 and LW16 insns. */
> + return uw4_operand (addr.offset, mode)
> + || uh4_operand (addr.offset, mode);
because this allows SH16 to be ub4_operand, uw4_operand or uh4_operand,
and so on. There needs to be one predicate/constraint pair for ub4_operands,
one for db4_operands, one for uw4_operands and one for uh4_operands.
Please use the function I suggested in my previous reply, in which the
offset predicate is passed in as a function pointer.
> @@ -1131,14 +1151,19 @@
>"")
>
> (define_insn "*add3"
> - [(set (match_operand:GPR 0 "register_operand" "=d,d")
> - (plus:GPR (match_operand:GPR 1 "register_operand" "d,d")
> - (match_operand:GPR 2 "arith_operand" "d,Q")))]
> + [(set (match_operand:GPR 0 "register_operand" "=!u,d,!u,!ks,d,d,d")
> + (plus:GPR (match_operand:GPR 1 "register_operand" "!u,d,!u,0,!ks,!ks,d")
> + (match_operand:GPR 2 "arith_operand"
> "!u,d,Uea4,Usb3,Ueim,Uesp,Q")))]
Hmm, not sure about these alternatives. Two have the form d/ks/U...
(the last two) and I'm not sure which instruction Usb3 corresponds to.
My guess from the manual would be:
[(set (match_operand:GPR 0 "register_operand" "=!u,d,!u,!u,!ks,!d,d")
(plus:GPR (match_operand:GPR 1 "register_operand" "!u,d,!u,!ks,!ks,0,d")
(match_operand:GPR 2 "arith_operand"
"!u,d,Ueau,Uuw6,Ueas,Usb4,Q")))]
> @@ -1347,12 +1372,13 @@
> (set_attr "mode" "")])
>
> (define_insn "sub3"
> - [(set (match_operand:GPR 0 "register_operand" "=d")
> - (minus:GPR (match_operand:GPR 1 "register_operand" "d")
> -(match_operand:GPR 2 "register_operand" "d")))]
> + [(set (match_operand:GPR 0 "register_operand" "=!u,d")
> + (minus:GPR (match_operand:GPR 1 "register_operand" "!u,d")
> +(match_operand:GPR 2 "register_operand" "!u,d")))]
>""
> - "subu\t%0,%1,%2"
> +{ return "subu\t%0,%1,%2"; }
The change to the last line shouldn't be needed. (Plain "..."
is better than { return ""; } where possible, because the
generator doesn't need to create a separate output function.)
> @@ -2878,9 +2905,9 @@
> ;; register =op1 x
>
> (define_insn "*and3"
> - [(set (match_operand:GPR 0 "register_operand" "=d,d,d,d,d,d,d")
> - (and:GPR (match_operand:GPR 1 "nonimmediate_operand" "o,o,W,d,
[cilkplus-merge] test for side effects
I have found some little nits that I will point out in a reply to this
message.
Balaji:
In Joseph's review on October 19, 2012
(http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01838.html) he mentioned:
Say expr1 through expr9 are expressions with side effects, and you have:
expr1[expr2:expr3:expr4] = expr5[expr6:expr7:expr8] + expr9;
The spec says "However, in such a statement, a sub-expression with rank
zero is evaluated only once." - that is, each of the nine expressions is
evaluated once. I don't see any calls to save_expr to ensure these
semantics, or any testcases that verify that they are adhered to.
If I understand Joseph's comment, this is still broken on the branch.
For example, in the example below:
array[func1() + 11 : func2() + 22 : func3() + 33] = 666;
...the function calls should only be called once, yet currently we generate:
D.1739 = 0;
:
D.1769 = func2 ();
D.1770 = D.1769 + 22;
if (D.1739 < D.1770) goto ; else goto ;
:
D.1771 = func1 ();<-- BOO HISS
D.1772 = D.1771 + 11;
D.1773 = func3 ();<-- BOO HISS
D.1774 = D.1773 + 33;
D.1775 = D.1739 * D.1774;
D.1776 = D.1772 + D.1775;
array[D.1776] = 666;
D.1739 = D.1739 + 1;
goto ;
:
As you can see, func1() and func3() are being called repeatedly within
the loop.
I am adding the attached execute test to the harness. If my
understanding is correct, this test should pass.
Joseph, please let me know if I misunderstood things in some way.
Committed to cilkplus-merge branch.
commit 4447dcf380a08f74bf5b91fd84d7013cbbb34ee8
Author: Aldy Hernandez
Date: Wed Mar 20 16:47:02 2013 -0500
Add new test to verify that the array index, limit, and stride are
only evaluated once.
diff --git
a/gcc/testsuite/gcc.dg/cilk-plus/array_notation/execute/side-effects-1.c
b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/execute/side-effects-1.c
new file mode 100644
index 000..1845862
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/execute/side-effects-1.c
@@ -0,0 +1,23 @@
+/* Test that the array index, limit, and stride are evaluated only
+ once. */
+
+int array[1000];
+
+int func1_times = 0;
+int func2_times = 0;
+int func3_times = 0;
+int func1() { func1_times++; return 0; }
+int func2() { func2_times++; return 0; }
+int func3() { func3_times++; return 0; }
+
+int main()
+{
+ array[func1() + 11 : func2() + 22 : func3() + 33] = 666;
+
+ if (func1_times != 1
+ || func2_times != 1
+ || func3_times != 1)
+abort();
+
+ return 0;
+}
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
Thanks for the prompt review! On Tue, Mar 19, 2013 at 7:30 PM, Tobias Burnus wrote: > Am 19.03.2013 13:15, schrieb Janne Blomqvist: > >> now that the Fortran frontend is C++ we can use the primitive bool >> type instead of inventing our own. > > > Well, C99's "bool" (_Bool) was already used before. Yes; the patch is an attempt to clean out some old junk from the days when the frontend was supposedly C89. > The advantage of FAILURE > and SUCCESS is that they immediately make clear whether some call was > successful or not. "true" and "false" don't. I think the difference is marginal at best, overshadowed by the fact that true/false are built-in language literals that everyone is familiar with. It's not like you're going to return false if the call is successful (unless the function is named is_something_broken() or such). > Thus, one should consider whether some procedures should be renamed to make > clear that true is successful and false is not. Certainly, however, I think that issue exists regardless of whether the return value is gfc_try or bool. > For instance, > if (gfc_notify_standard (...) == FAILURE) > return MATCH_ERROR; > becomes with your patch: > if (gfc_notify_standard (...) == false) > return MATCH_ERROR; > > I think a more logical expression would be > if (gfc_notify_standard (...)) > return MATCH_ERROR; > which removes the "== false" but also swaps true/false for the return value. > > There are probably some more cases. Without such a clean up, I fear that the > code will become less readable than it is currently. While I think such > changes can be done as follow up, I think committing the gfc_try -> bool > patch only makes sense if you commit yourself to do such a cleanup. I think it should be relatively straightforward to do a further cleanup patch which would make the usage more idiomatic C/C++, i.e. transformations like x == true -> x x == false -> !x x != true -> !x x != false -> x where "x" is some boolean expression. > > Tobias > > PS: Generally, please wait with committals until GCC's web mail archive > works again for gcc-cvs. That will hopefully be soon. > > >> 2013-03-19 Janne Blomqvist >> >> * gfortran.h: Remove enum gfc_try, replace gfc_try with bool type. >> * arith.c: Replace gfc_try with bool type. >> * array.c: Likewise. >> * check.c: Likewise. >> * class.c: Likewise. >> * cpp.c: Likewise. >> * cpp.h: Likewise. >> * data.c: Likewise. >> * data.h: Likewise. >> * decl.c: Likewise. >> * error.c: Likewise. >> * expr.c: Likewise. >> * f95-lang.c: Likewise. >> * interface.c: Likewise. >> * intrinsic.c: Likewise. >> * intrinsic.h: Likewise. >> * io.c: Likewise. >> * match.c: Likewise. >> * match.h: Likewise. >> * module.c: Likewise. >> * openmp.c: Likewise. >> * parse.c: Likewise. >> * parse.h: Likewise. >> * primary.c: Likewise. >> * resolve.c: Likewise. >> * scanner.c: Likewise. >> * simplify.c: Likewise. >> * symbol.c: Likewise. >> * trans-intrinsic.c: Likewise. >> * trans-openmp.c: Likewise. >> * trans-stmt.c: Likewise. >> * trans-types.c: Likewise. -- Janne Blomqvist
RE: FW: [PATCH] [MIPS] microMIPS gcc support
Hi Richard, I'm sorry for wasting your time. I accidentally posted an older version of the patch earlier this afternoon. This is the version that I meant to post and is hopefully a lot closer to what you are looking for. I named some of the predicates/constraints differently than your current suggestions, but hopefully they will be OK. Thanks, Catherine > -Original Message- > From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > Sent: Wednesday, March 20, 2013 5:48 PM > To: Moore, Catherine > Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej > Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support > > "Moore, Catherine" writes: > > Index: gcc/config/mips/constraints.md > > > == > = > > --- gcc/config/mips/constraints.md (revision 196638) > > +++ gcc/config/mips/constraints.md (working copy) > > @@ -43,6 +43,9 @@ > > (define_register_constraint "b" "ALL_REGS" > >"@internal") > > > > +(define_register_constraint "u" "M16_REGS" > > + "@internal") > > + > > ;; MIPS16 code always calls through a MIPS16 register; see > > mips_emit_call_insn ;; for details. > > (define_register_constraint "c" "TARGET_MIPS16 ? M16_REGS @@ -170,6 > > +173,41 @@ > >(and (match_operand 0 "call_insn_operand") > > (match_test "CONSTANT_P (op)"))) > > > > +(define_constraint "Udb7" > > + "@internal > > + A decremented unsigned constant of 7 bits." > > + (match_operand 0 "db7_operand")) > > + > > +(define_constraint "Uea4" > > + "@internal > > + A microMIPS encoded ADDIUR2 immediate operand." > > + (match_operand 0 "addiur2_operand")) > > I'm still wary of having digits for some "Ue"s and not others, especially > because (as I understand it) ADDIUR2 takes a 3-bit rather than 4-bit operand. > How about "Ueau" here (= add of "u" register). > For consistency... > > > +(define_constraint "Ueim" > > + "@internal > > + A microMIPS encoded ADDIUSP operand." > > + (match_operand 0 "addiusp_operand" "")) > > ...this could be "Ueas" (= add of stack register). Redundant "". > > > +(define_constraint "Uesp" > > + "@internal > > + A microMIPS encoded ADDIUR1SP operand." > > + (match_operand 0 "addiur1sp_operand" "")) > > This is "6 bits zero extended and shifted left twice", so the constraint > should > be "Uuw6" and the predicate should be "uw6_operand". Redundant "". > > > +(define_memory_constraint "ZS" > > + "@internal > > + A microMIPS memory operand for use with the LWSP/SWSP insns." > > + (and (match_code "mem") > > + (match_operand 0 "umips_lwsp_swsp_operand"))) > > + > > +(define_memory_constraint "ZT" > > + "@internal > > + A microMIPS memory operand for use with the various LOAD insns." > > + (and (match_code "mem") > > + (match_operand 0 "umips_load_operand"))) > > + > > +(define_memory_constraint "ZU" > > + "@internal > > + A microMIPS memory operand for use with the various STORE insns." > > + (and (match_code "mem") > > + (match_operand 0 "umips_store_operand"))) > > As I mentioned before, we need a separate predicate and constraint for each > range. We can't have things like: > > > + /* For the LBU16 insn. */ > > + if (load && db4_operand (addr.offset, mode)) > > +return true; > > + > > + /* For the SB16 insn. */ > > + if (!load && ub4_operand (addr.offset, mode)) > > +return true; > > + > > + /* For SH16, LHU16, SW16 and LW16 insns. */ return uw4_operand > > + (addr.offset, mode) > > + || uh4_operand (addr.offset, mode); > > because this allows SH16 to be ub4_operand, uw4_operand or uh4_operand, > and so on. There needs to be one predicate/constraint pair for > ub4_operands, one for db4_operands, one for uw4_operands and one for > uh4_operands. > > Please use the function I suggested in my previous reply, in which the offset > predicate is passed in as a function pointer. > > > @@ -1131,14 +1151,19 @@ > >"") > > > > (define_insn "*add3" > > - [(set (match_operand:GPR 0 "register_operand" "=d,d") > > - (plus:GPR (match_operand:GPR 1 "register_operand" "d,d") > > - (match_operand:GPR 2 "arith_operand" "d,Q")))] > > + [(set (match_operand:GPR 0 "register_operand" "=!u,d,!u,!ks,d,d,d") > > + (plus:GPR (match_operand:GPR 1 "register_operand" > "!u,d,!u,0,!ks,!ks,d") > > + (match_operand:GPR 2 "arith_operand" > > +"!u,d,Uea4,Usb3,Ueim,Uesp,Q")))] > > Hmm, not sure about these alternatives. Two have the form d/ks/U... > (the last two) and I'm not sure which instruction Usb3 corresponds to. > > My guess from the manual would be: > > [(set (match_operand:GPR 0 "register_operand" "=!u,d,!u,!u,!ks,!d,d") > (plus:GPR (match_operand:GPR 1 "register_operand" > "!u,d,!u,!ks,!ks,0,d") > (match_operand:GPR 2 "arith_operand" >"!u,d,Ueau,Uuw6,Ueas,Usb4,Q")))] > > > @@ -1347,12 +1372,13 @@ > > (set_attr "mode" "")]) > > > > (define_insn "sub3" > > - [(set (match_operand:GPR 0
RE: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
HI Aldy, Joseph et al.,
Attached, please find a fixed patch. Please see my responses to Aldy's
questions below:
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, March 20, 2013 12:33 PM
> To: Joseph S. Myers
> Cc: Iyer, Balaji V; gcc-patches
> Subject: Re: [patch] cilkplus array notation for C (clean, independent
> patchset,
> take 1)
>
> On 03/20/13 10:30, Aldy Hernandez wrote:
> >
> > I have found some little nits that I will point out in a reply to this
> > message.
> >
> > Joseph, folks, et al... How does this look?
> >
> > Thanks.
>
> Balaji:
>
> > +void
> > +array_notation_init_builtins (void)
> > +{
> > + tree func_type = NULL_TREE;
> > + tree new_func = NULL_TREE;
> > + func_type = build_function_type_list (integer_type_node, ptr_type_node,
> > + NULL_TREE);
> > + new_func = build_fn_decl ("__sec_reduce_add", func_type);
> > + mark_cold (new_func);
> > + new_func = lang_hooks.decls.pushdecl (new_func);
> etc
> etc
>
> All these builtins need to be documented in doc/.
DONE!
>
> > +load_lib gcc-dg.exp
> > +
> > +dg-init
> > +dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] " -fcilkplus" " "
> > +dg-finish
> > +
> > +dg-init
> > +dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] " -O0
> > -fcilkplus" " "
> > +dg-finish
> > +
> > +dg-init
> > +dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] " -O1
> > -fcilkplus" " "
> > +dg-finish
> etc
> etc
>
> Can't you do all these dg-runtest's within one pair of dg-init/dg-finish?
> Similarly
> for the other .exp files.
The reason why I did these is so that we can easily isolate the errors to one
run if necessary. I fixed them as you requested.
>
> As I'd mentioned, you have .exp files named compile.exp and execute.exp which
> seem to be causing ambiguity problems in parallel checks (make check -jN).
> For
> some reason, with this patch, the rest of dg.exp fails to run after Cilkplus'
> compile/execute.exp runs. Renaming these to something less generic does the
> trick. Do you mind prefixing all the .exp's with "cilkplus_" or something
> similar?
FIXED! I added the "cilkplus_AN_c_" prefix to everything, where "an" stands for
Array Notation . This way it won't interfere with the future Cilk Plus patches'
test case.
>
> [Perhaps someone can pontificate as to what the actual problem is here and
> describe it. Dejagnu is a mystery to me.]
>
> > diff --git
> > a/gcc/testsuite/gcc.dg/cilk-plus/array_notation/errors/errors.exp
> > b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/errors/errors.exp
> > new file mode 100644
> > index 000..6d7604b
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/errors/errors.exp
> > @@ -0,0 +1,65 @@
> > +# Copyright (C) 2013 Free Software Foundation, Inc.
> > +
> > +# This program 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 of the
> > +License, or # (at your option) any later version.
> > +#
> > +# This program 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 copy of the GNU General Public License #
> > +along with GCC; see the file COPYING3. If not see #
> > +
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 20/03/2013, at 1:35 AM, rbmj wrote: > On 19-Mar-13 03:04, Maxim Kuvyrkov wrote: >> >> Will commit to trunk once the server is up. The patch is now committed. >> >> Regarding 4.8, we should've really tried to work it out earlier. If you >> want to pursue backport to 4.8, please attach the log of PPA system >> rejecting the package > > The error is: > > == > Finished at 20130318-0642 > Build needed 00:14:20, 804796k disk space > Function `__gthread_get_tsd_data' implicitly converted to pointer at > /build/buildd/gcc-powerpc-wrs-vxworks-4.8.0+0svn196132/libgcc/config/vxlib-tls.c:164 > > > > Our automated build log filter detected the problem(s) above that will > likely cause your package to segfault on architectures where the size of > a pointer is greater than the size of an integer, such as ia64 and amd64. > > This is often due to a missing function prototype definition. > > Since use of implicitly converted pointers is always fatal to the application > on ia64, they are errors. Please correct them for your next upload. > == > > This problem does not apply on the target (powerpc-wrs-vxworks), where > sizeof(int*) == sizeof(int(*)()) == sizeof(int) == 4. However, the build > system's filters are too stupid to realize this. Because the warning is > spurious really the fact that the automated build system rejects the package > is a bug on the build system's part. However, doing it the Right Way is so > _easy_... Richard, As release manager, do you have any objections to backporting this patch to 4.8 branch? It affects only VxWorks targets and it is quite harmless (the patch fixes a compilation warning during building GCC for VxWorks targets). Thanks, -- Maxim Kuvyrkov KugelWorks gthread.patch Description: Binary data
[committed] TILE-Gx: add atomic test and set pattern
This patch adds an atomic test and set pattern on tilegx. Without
this pattern, libatomic currently fails to build on tilegx. Do I need
permission to backport this to the 4.8 branch?
Thanks,
Walter
* config/tilegx/sync.md (atomic_test_and_set): New pattern.
Index: gcc/config/tilegx/sync.md
===
--- gcc/config/tilegx/sync.md (revision 196804)
+++ gcc/config/tilegx/sync.md (working copy)
@@ -162,3 +162,49 @@
tilegx_post_atomic_barrier (model);
DONE;
})
+
+
+(define_expand "atomic_test_and_set"
+ [(match_operand:QI 0 "register_operand" "") ;; bool output
+ (match_operand:QI 1 "nonautoincmem_operand" "+U");; memory
+ (match_operand:SI 2 "const_int_operand" "")] ;; model
+ ""
+{
+ rtx addr, aligned_addr, aligned_mem, offset, word, shmt;
+ rtx tmp0, tmp1;
+ rtx result = operands[0];
+ rtx mem = operands[1];
+ enum memmodel model = (enum memmodel) INTVAL (operands[2]);
+
+ addr = force_reg (Pmode, XEXP (mem, 0));
+
+ aligned_addr = gen_reg_rtx (Pmode);
+ emit_move_insn (aligned_addr, gen_rtx_AND (Pmode, addr, GEN_INT (-8)));
+
+ aligned_mem = change_address (mem, DImode, aligned_addr);
+ set_mem_alias_set (aligned_mem, 0);
+
+ offset = gen_reg_rtx (DImode);
+ emit_move_insn (offset, gen_rtx_AND (DImode, gen_lowpart (DImode, addr),
+ GEN_INT (7)));
+
+ tmp0 = gen_reg_rtx (DImode);
+ emit_move_insn (tmp0, GEN_INT (1));
+
+ shmt = gen_reg_rtx (DImode);
+ emit_move_insn (shmt, gen_rtx_ASHIFT (DImode, offset, GEN_INT (3)));
+
+ word = gen_reg_rtx (DImode);
+ emit_move_insn (word, gen_rtx_ASHIFT (DImode, tmp0,
+gen_lowpart (SImode, shmt)));
+
+ tmp1 = gen_reg_rtx (DImode);
+ tilegx_pre_atomic_barrier (model);
+ emit_insn (gen_atomic_fetch_or_baredi (tmp1, aligned_mem, word));
+ tilegx_post_atomic_barrier (model);
+
+ emit_move_insn (gen_lowpart (DImode, result),
+ gen_rtx_LSHIFTRT (DImode, tmp1,
+gen_lowpart (SImode, shmt)));
+ DONE;
+})
Re: C++ PATCH for c++/17232 (abstract class, array and sfinae)
On 03/17/2013 04:33 PM, Jason Merrill wrote:
On 03/16/2013 03:38 PM, Jason Merrill wrote:
In SFINAE context, we need to instantiate a class so that we can tell
whether or not is abstract. Doing this in non-SFINAE context caused
problems, so I've made it conditional.
But it still causes problems, such as PR 56642. So I've reverted the
complete_type change for now.
This patch fixes 56642 properly; forcing the type to be complete can
cause a function decl instantiation to cause its own instantiation
again, so we need to deal with that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f6585cdd1828608c4052ac06b80c89ce86da120f
Author: Jason Merrill
Date: Mon Mar 18 00:25:34 2013 -0400
PR c++/17232
PR c++/56642
* pt.c (tsubst_decl): Check return value of register_specialization.
* typeck2.c (abstract_virtuals_error_sfinae): Re-apply complete_type
change.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4274479..531d860 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10285,7 +10285,13 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
DECL_TEMPLATE_INFO (r)
= build_template_info (gen_tmpl, argvec);
SET_DECL_IMPLICIT_INSTANTIATION (r);
- register_specialization (r, gen_tmpl, argvec, false, hash);
+
+ tree new_r
+ = register_specialization (r, gen_tmpl, argvec, false, hash);
+ if (new_r != r)
+ /* We instantiated this while substituting into
+ the type earlier (template/friend54.C). */
+ RETURN (new_r);
/* We're not supposed to instantiate default arguments
until they are called, for a template. But, for a
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 24b5593..3bac67c 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -265,6 +265,10 @@ abstract_virtuals_error_sfinae (tree decl, tree type, abstract_class_use use,
return 0;
type = TYPE_MAIN_VARIANT (type);
+ /* In SFINAE context, force instantiation. */
+ if (!(complain & tf_error))
+complete_type (type);
+
/* If the type is incomplete, we register it within a hash table,
so that we can check again once it is completed. This makes sense
only for objects for which we have a declaration or at least a
diff --git a/gcc/testsuite/g++.dg/template/abstract-dr337.C b/gcc/testsuite/g++.dg/template/abstract-dr337.C
index 4f66c1c..6905262 100644
--- a/gcc/testsuite/g++.dg/template/abstract-dr337.C
+++ b/gcc/testsuite/g++.dg/template/abstract-dr337.C
@@ -6,8 +6,8 @@ class A {
};
template
-void g(T (*a)[1]) {} // { dg-error "abstract" "" { xfail *-*-* } }
+void g(T (*a)[1]) {} // { dg-error "abstract" "" }
int main() {
- g >(0); // { dg-error "no matching function" "" { xfail *-*-* } }
+ g >(0); // { dg-error "no matching function" }
}
diff --git a/gcc/testsuite/g++.dg/template/friend54.C b/gcc/testsuite/g++.dg/template/friend54.C
new file mode 100644
index 000..ead7a72
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/friend54.C
@@ -0,0 +1,18 @@
+// PR c++/56642
+
+template struct A;
+
+template
+A f(T*) { return A(); }
+
+template
+struct A
+{
+ friend A f(T*);
+};
+
+int main()
+{
+ int *p = 0;
+ f(p);
+}
Re: C++ PATCH for c++/17232 (abstract class, array and sfinae)
And this is a robustness change that I ended up not needing, but still
makes sense.
commit 3099f644d5427e1db3b4041ca4ed779ef213b6a0
Author: Jason Merrill
Date: Tue Mar 19 11:34:46 2013 -0400
* pt.c (retrieve_specialization): Handle null tmpl argument.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 531d860..d56ffed 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1009,6 +1009,9 @@ optimize_specialization_lookup_p (tree tmpl)
static tree
retrieve_specialization (tree tmpl, tree args, hashval_t hash)
{
+ if (tmpl == NULL_TREE)
+return NULL_TREE;
+
if (args == error_mark_node)
return NULL_TREE;
C++ PATCH to use the same anonymous namespace name on all targets
Previous attempts to build the compiler as C++ had problems with stage
comparison due to anonymous namespaces having random names. This was
necessary in the past because of string comparison of type_info names on
targets that didn't support unification of the nodes for address
comparison, but when we switched to doing string comparison on GNU/Linux
as well, we changed it so that we do address comparison for types in the
anonymous namespace, so we don't need a randomized name anymore.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 95fed08c94d20b03994248b5ffa3e5d41a4aff7d
Author: Jason Merrill
Date: Tue Mar 19 10:11:18 2013 -0400
* name-lookup.c (get_anonymous_namespace_name): Never use
get_file_function_name.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 2a47331..7084a53 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -69,14 +69,12 @@ get_anonymous_namespace_name (void)
{
if (!anonymous_namespace_name)
{
- /* The anonymous namespace has to have a unique name
- if typeinfo objects are being compared by name. */
- if (! flag_weak || ! SUPPORTS_ONE_ONLY)
- anonymous_namespace_name = get_file_function_name ("N");
- else
- /* The demangler expects anonymous namespaces to be called
- something starting with '_GLOBAL__N_'. */
- anonymous_namespace_name = get_identifier ("_GLOBAL__N_1");
+ /* We used to use get_file_function_name here, but that isn't
+ necessary now that anonymous namespace typeinfos
+ are !TREE_PUBLIC, and thus compared by address. */
+ /* The demangler expects anonymous namespaces to be called
+ something starting with '_GLOBAL__N_'. */
+ anonymous_namespace_name = get_identifier ("_GLOBAL__N_1");
}
return anonymous_namespace_name;
}
diff --git a/gcc/testsuite/g++.dg/eh/anon1.C b/gcc/testsuite/g++.dg/eh/anon1.C
new file mode 100644
index 000..2a5ef4b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/anon1.C
@@ -0,0 +1,26 @@
+// Test that the anonymous namespace isn't mangled with random characters,
+// but also doesn't get mixed up with an anonymous namespace in another
+// translation unit.
+
+// { dg-do run }
+// { dg-additional-sources "anon1a.cc" }
+
+namespace {
+ struct A
+ {
+virtual void f();
+ };
+
+ void A::f() { }
+}
+
+extern void g();
+
+int main()
+{
+ try {
+try {
+ g();
+} catch (A) { __builtin_abort(); }
+ } catch (...) { }
+}
diff --git a/gcc/testsuite/g++.dg/eh/anon1a.cc b/gcc/testsuite/g++.dg/eh/anon1a.cc
new file mode 100644
index 000..ba161ac
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/anon1a.cc
@@ -0,0 +1,10 @@
+namespace {
+ struct A
+ {
+virtual void f();
+ };
+
+ void A::f() { }
+}
+
+void g() { throw A(); }
diff --git a/gcc/testsuite/g++.dg/eh/anon2.C b/gcc/testsuite/g++.dg/eh/anon2.C
new file mode 100644
index 000..9ff9ee3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/anon2.C
@@ -0,0 +1,24 @@
+// Test that the anonymous namespace isn't mangled with random characters,
+// but also doesn't get mixed up with an anonymous namespace in another
+// translation unit.
+// { dg-final { scan-assembler "\\*N12_GLOBAL__N_11AE" } }
+
+namespace {
+ struct A
+ {
+virtual void f();
+ };
+
+ void A::f() { }
+}
+
+extern void g();
+
+int main()
+{
+ try {
+try {
+ g();
+} catch (A) { __builtin_abort(); }
+ } catch (...) { }
+}
C++ PATCH for c++/54532 (constexpr ptrmem)
While a class is still being defined, we don't know the offsets of the
members, so a pointer-to-member expression can't be lowered to an
integer, it needs to stay as a PTRMEM_CST. But it's still a constant as
far as the language is concerned, so we need to allow it and then lower
it when the class is complete.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit c41c286c3b13d1d1b3831fab38497146bd0c2f8b
Author: Jason Merrill
Date: Fri Feb 15 16:25:27 2013 -0500
PR c++/54532
* expr.c (cplus_expand_constant): Do nothing if the class is
incomplete.
* semantics.c (reduced_constant_expression_p): Allow PTRMEM_CST.
* typeck2.c (store_init_value): Use reduced_constant_expression_p.
* decl.c (maybe_register_incomplete_var): Handle PTRMEM_CST.
(complete_vars): Likewise.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index facaae7..4ccb541 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14018,7 +14018,10 @@ grokmethod (cp_decl_specifier_seq *declspecs,
/* VAR is a VAR_DECL. If its type is incomplete, remember VAR so that
- we can lay it out later, when and if its type becomes complete. */
+ we can lay it out later, when and if its type becomes complete.
+
+ Also handle constexpr pointer to member variables where the initializer
+ is an unlowered PTRMEM_CST because the class isn't complete yet. */
void
maybe_register_incomplete_var (tree var)
@@ -14043,6 +14046,15 @@ maybe_register_incomplete_var (tree var)
incomplete_var iv = {var, inner_type};
vec_safe_push (incomplete_vars, iv);
}
+ else if (TYPE_PTRMEM_P (inner_type)
+ && DECL_INITIAL (var)
+ && TREE_CODE (DECL_INITIAL (var)) == PTRMEM_CST)
+ {
+ tree context = TYPE_PTRMEM_CLASS_TYPE (inner_type);
+ gcc_assert (TYPE_BEING_DEFINED (context));
+ incomplete_var iv = {var, context};
+ vec_safe_push (incomplete_vars, iv);
+ }
}
}
@@ -14062,10 +14074,17 @@ complete_vars (tree type)
{
tree var = iv->decl;
tree type = TREE_TYPE (var);
- /* Complete the type of the variable. The VAR_DECL itself
- will be laid out in expand_expr. */
- complete_type (type);
- cp_apply_type_quals_to_decl (cp_type_quals (type), var);
+
+ if (TYPE_PTRMEM_P (type))
+ DECL_INITIAL (var) = cplus_expand_constant (DECL_INITIAL (var));
+ else
+ {
+ /* Complete the type of the variable. The VAR_DECL itself
+ will be laid out in expand_expr. */
+ complete_type (type);
+ cp_apply_type_quals_to_decl (cp_type_quals (type), var);
+ }
+
/* Remove this entry from the list. */
incomplete_vars->unordered_remove (ix);
}
diff --git a/gcc/cp/expr.c b/gcc/cp/expr.c
index ffd18ca..f15b049 100644
--- a/gcc/cp/expr.c
+++ b/gcc/cp/expr.c
@@ -43,6 +43,10 @@ cplus_expand_constant (tree cst)
/* Find the member. */
member = PTRMEM_CST_MEMBER (cst);
+ /* We can't lower this until the class is complete. */
+ if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
+ return cst;
+
if (TREE_CODE (member) == FIELD_DECL)
{
/* Find the offset for the field. */
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 5143e4b..3691d86 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6838,6 +6838,9 @@ cxx_eval_call_expression (const constexpr_call *old_call, tree t,
bool
reduced_constant_expression_p (tree t)
{
+ if (TREE_CODE (t) == PTRMEM_CST)
+/* Even if we can't lower this yet, it's constant. */
+return true;
/* FIXME are we calling this too much? */
return initializer_constant_valid_p (t, TREE_TYPE (t)) != NULL_TREE;
}
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 3bac67c..6ef46a1 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -792,7 +792,7 @@ store_init_value (tree decl, tree init, vec** cleanups, int flags)
will perform the dynamic initialization. */
if (value != error_mark_node
&& (TREE_SIDE_EFFECTS (value)
- || ! initializer_constant_valid_p (value, TREE_TYPE (value
+ || ! reduced_constant_expression_p (value)))
{
if (TREE_CODE (type) == ARRAY_TYPE
&& TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (type)))
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-static11.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-static11.C
new file mode 100644
index 000..91cc25a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-static11.C
@@ -0,0 +1,14 @@
+// PR c++/54532
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert(X,#X)
+
+struct A {
+ int i;
+ constexpr static int A::*p = &A::i;
+};
+
+constexpr A a = { 42 };
+SA(a.*A::p == 42);
+
+constexpr int A::* A::p;
Re: C++ PATCH for c++/54359 ('this' in trailing-return-type with out-of-class method defn)
On 03/17/2013 11:45 PM, Jason Merrill wrote:
This patch caused c++/56639: when within a function we were trying to
parse something that could be either a declaration or an expression, we
went to set current_class_ptr and failed the assertion that it wasn't
already set. We could save and restore the value
...and now this PR comes along that shows that we really do need to save
and restore the value.
Tested x86_64-pc-linux-gnu, applying to trunk, and branches later.
commit e60c343e7913ad2ff194c95391d6dd8fc479ce88
Author: Jason Merrill
Date: Wed Mar 20 22:51:38 2013 -0400
PR c++/56646
* parser.c (cp_parser_late_return_type_opt): Save and restore
current_class_ptr/ref.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 23fe3f3..e04d3ce 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17056,17 +17056,21 @@ cp_parser_late_return_type_opt (cp_parser* parser, cp_cv_quals quals)
/* Consume the ->. */
cp_lexer_consume_token (parser->lexer);
+ tree save_ccp = current_class_ptr;
+ tree save_ccr = current_class_ref;
if (quals >= 0)
{
/* DR 1207: 'this' is in scope in the trailing return type. */
- gcc_assert (current_class_ptr == NULL_TREE);
inject_this_parameter (current_class_type, quals);
}
type = cp_parser_trailing_type_id (parser);
if (quals >= 0)
-current_class_ptr = current_class_ref = NULL_TREE;
+{
+ current_class_ptr = save_ccp;
+ current_class_ref = save_ccr;
+}
return type;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/trailing9.C b/gcc/testsuite/g++.dg/cpp0x/trailing9.C
new file mode 100644
index 000..d7895b3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/trailing9.C
@@ -0,0 +1,12 @@
+// PR c++/56646
+// { dg-require-effective-target c++11 }
+
+struct A {
+ void f();
+};
+
+void A::f() {
+ struct B {
+auto g() -> void { }
+ };
+}
Record missing equivalence
This was something I spotted while looking at why certain redundant
conditionals were not eliminated. In particular this affects the
compiler's ability to eliminate a variety of gimple checking tests.
Consider an equality comparison
if (a == 10)
true arm
else
else arm
We obviously want to record an equivalence so that we can replace uses
of "a" in the true arm with "10".
Now consider if "a" was set by a widening type conversion.
a = (int) z; /* Assume Z is a narrower type */
if (a == 10)
true arm
else
else arm
We'd really like to also record an equivalence for "z" in the true arm
so that uses of "z" can be replaced with "10". We restrict this to
widening conversions where the constant is equal in both the original
and widened type.
That's precisely what this patch does. When we're going to record an
equivalence from an equality comparison between an SSA_NAME and a
constant, we look to see if the SSA_NAME was set from widening
conversion and verify the constant is the same in both the original and
widened type. When true, we record the additional equivalence.
As I mentioned, this ultimately allows us to discover more redundant
conditionals for gimple checking and eliminate them.
The included testcase is drastically simplified and merely tests for
whether or not we record & propagate the additional equivalence. It
does not show the eliminated tests.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
commit 4c7d3ee54cf7035b247c685a68968d0a60b01601
Author: Jeff Law
Date: Wed Mar 20 22:39:13 2013 -0600
* tree-ssa-dom.c (record_equivalences_from_incoming_edge): Record
addititional equivalences for equality comparisons between an SSA_NAME
and a constant where the SSA_NAME was set from a widening conversion.
* g++.dg/tree-ssa/ssa-dom.C: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5ecdc8f..5f93edd 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2013-03-20 Jeff Law
+
+ * tree-ssa-dom.c (record_equivalences_from_incoming_edge): Record
+ addititional equivalences for equality comparisons between an SSA_NAME
+ and a constant where the SSA_NAME was set from a widening conversion.
+
2013-03-20 Walter Lee
* config/tilegx/sync.md (atomic_test_and_set): New pattern.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 93d02bb..99a366d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-03-20 Jeff Law
+
+ * g++.dg/tree-ssa/ssa-dom.C: New test.
+
+
2013-03-20 Michael Meissner
* gcc.target/powerpc/mmfpgpr.c: New test.
diff --git a/gcc/testsuite/g++.dg/tree-ssa/ssa-dom.C
b/gcc/testsuite/g++.dg/tree-ssa/ssa-dom.C
new file mode 100644
index 000..5f63865
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/ssa-dom.C
@@ -0,0 +1,104 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dom1" } */
+
+typedef long unsigned int size_t;
+extern void abort (void) __attribute__ ((__noreturn__));
+union tree_node;
+typedef union tree_node *tree;
+union gimple_statement_d;
+typedef union gimple_statement_d *gimple;
+typedef const union gimple_statement_d *const_gimple;
+
+enum gimple_code
+{
+ GIMPLE_RETURN = 10,
+};
+
+
+
+
+
+struct gimple_statement_base
+{
+
+
+ enum gimple_code code:8;
+};
+
+
+enum gimple_statement_structure_enum
+{
+ xyz
+};
+
+
+
+
+
+
+union gimple_statement_d
+{
+ struct gimple_statement_base gsbase;
+};
+
+
+
+
+
+extern size_t const gimple_ops_offset_[];
+
+
+extern enum gimple_statement_structure_enum const gss_for_code_[];
+
+
+static inline enum gimple_code
+gimple_code (const_gimple g)
+{
+ return g->gsbase.code;
+}
+
+
+
+
+static inline enum gimple_statement_structure_enum
+gss_for_code (enum gimple_code code)
+{
+ return gss_for_code_[code];
+}
+
+
+
+
+static inline enum gimple_statement_structure_enum
+gimple_statement_structure (gimple gs)
+{
+ return gss_for_code (gimple_code (gs));
+}
+
+
+static inline tree *
+gimple_ops (gimple gs)
+{
+ size_t off;
+ off = gimple_ops_offset_[gimple_statement_structure (gs)];
+ return (tree *) ((char *) gs + off);
+}
+
+
+static inline void
+gimple_set_op (gimple gs, unsigned i, tree op)
+{
+ gimple_ops (gs)[i] = op;
+}
+
+void
+gimple_return_set_retval (gimple gs, tree retval)
+{
+ const_gimple __gs = (gs);
+ if (gimple_code (__gs) != (GIMPLE_RETURN))
+abort ();
+ gimple_set_op (gs, 0, retval);
+}
+/* { dg-final { scan-tree-dump-times "gss_for_code_.10." 1 "dom1"} } */
+/* { dg-final { cleanup-tree-dump "dom1" } } */
+
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index e8b1551..57b814c 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -1135,6 +1135,33 @@ record_equivalences_from_incoming_edge (basic_block bb)
if (lhs)
record_equality (lhs, rhs);
+ /* If LHS is an SSA_NAME and RHS is a constant and LHS was set
+
Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
On 03/20/2013 10:33 AM, Aldy Hernandez wrote: As I'd mentioned, you have .exp files named compile.exp and execute.exp which seem to be causing ambiguity problems in parallel checks (make check -jN). For some reason, with this patch, the rest of dg.exp fails to run after Cilkplus' compile/execute.exp runs. Renaming these to something less generic does the trick. Do you mind prefixing all the .exp's with "cilkplus_" or something similar? [Perhaps someone can pontificate as to what the actual problem is here and describe it. Dejagnu is a mystery to me.] I doubt it's anything really related to dejagnu and is more related to how the "make check" target is constructed in gcc/Makefile.in. It's brutally ugly. I recently had to swap in some dejagnu/tcl basics; and I did everything possible to forget it as soon as possible. I'd really forgotten how much I hated writing tcl code. Jeff
Re: C++ PATCH to use the same anonymous namespace name on all targets
Jason Merrill writes: | Previous attempts to build the compiler as C++ had problems with stage | comparison due to anonymous namespaces having random names. This was | necessary in the past because of string comparison of type_info names | on targets that didn't support unification of the nodes for address | comparison, but when we switched to doing string comparison on | GNU/Linux as well, we changed it so that we do address comparison for | types in the anonymous namespace, so we don't need a randomized name | anymore. Excellent! Many thanks, -- Gaby
Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
On Wed, Mar 20, 2013 at 11:30:58PM -0600, Jeff Law wrote: > On 03/20/2013 10:33 AM, Aldy Hernandez wrote: > >As I'd mentioned, you have .exp files named compile.exp and execute.exp > >which seem to be causing ambiguity problems in parallel checks (make > >check -jN). For some reason, with this patch, the rest of dg.exp fails > >to run after Cilkplus' compile/execute.exp runs. Renaming these to > >something less generic does the trick. Do you mind prefixing all the > >.exp's with "cilkplus_" or something similar? Renaming is desirable anyway, people who run make check-gcc execute.exp=something don't expect to run also some subset of cilk+ tests. The Makefile runs some execute.exp=2* and similar when parallelized, see check_gcc_parallelize in gcc/Makefile.in. Anyway, have you tested that without parallelization make check doesn't skip some tests? Often when a new *.exp file say sets some globals and never resets them, this could affect following *.exp files. Jakub
[PATCH, ARM][1 of 2] Add epilogue dwarf info for shrink-wrap
Hi, When shrink-wrap is enabled, the "returns" from simple-return path and normal return path can be merged. The code is like: tst ... / \ | push ... | ... | pop ... \ / bx lr If the dwarf info after "pop ..." is incorrect, the dwarf checks will fail at dwarf2cfi.c: function maybe_record_trace_start. /* We ought to have the same state incoming to a given trace no matter how we arrive at the trace. Anything else means we've got some kind of optimization error. */ gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row)); The patch is to add epilogue dwarf info to make sure: Before "bx lr", * All registers saved in stack had been "restored". * .cfi_def_cfa_offset 0 * .cfi_def_cfa_register is sp even if frame_pointer_needed Boot strapped and no make check regression. Is it OK? Thanks! -Zhenqiang ChangeLog: 2013-03-21 Zhenqiang Chen * config/arm/arm.c (arm_add_cfa_adjust_cfa_note): New added. (arm_emit_multi_reg_pop): Add REG_CFA_ADJUST_CFA notes. (arm_emit_vfp_multi_reg_pop): Likewise. (thumb2_emit_ldrd_pop): Likewise. (arm_expand_epilogue): Add misc REG_CFA notes. (arm_unwind_emit): Skip REG_CFA_ADJUST_CFA and REG_CFA_RESTORE. 1-add-dwarf-info-on-epilogue.patch Description: Binary data
