[committed] Fix up can_vec_perm_p call in vector division lowering (PR tree-optimization/53645)
Hi!
As reported by Uros, the new testcase now fails with -mno-sse4.
The problem is that can_vec_perm_p tests different permutation from what
is actually expanded in the even/odd case (hi/lo is correct).
The permutation is always done after VCE to the narrower type.
Fixed thusly, committed as obvious.
2012-07-02 Jakub Jelinek ja...@redhat.com
PR tree-optimization/53645
* tree-vect-generic.c (expand_vector_divmod): Use TYPE_MODE (type)
instead of TYPE_MODE (wider_type) as can_vec_perm_p argument.
--- gcc/tree-vect-generic.c.jj 2012-06-29 21:39:32.0 +0200
+++ gcc/tree-vect-generic.c 2012-07-02 08:39:08.318530872 +0200
@@ -768,7 +768,7 @@ expand_vector_divmod (gimple_stmt_iterat
{
for (i = 0; i nunits; i++)
sel[i] = !BYTES_BIG_ENDIAN + (i ~1) + ((i 1) ? nunits : 0);
- if (!can_vec_perm_p (TYPE_MODE (wider_type), false, sel))
+ if (!can_vec_perm_p (TYPE_MODE (type), false, sel))
decl_e = decl_o = NULL_TREE;
}
else
Jakub
PR53818 - Allow -finit-local-zero with -fno-automatic for result variables
For some reasons, result variables are walked twice. With
-finit-local-zero their value gets set to 0, either via an inserted
assignment or by adding a initialization (sym-value).
With -fno-automatic sym-value is also set for result variables, which
later leads to an error. With the patch, that code path is skipped and
an assignment is done. (As the code path is taken twice, twp assignments
are done. I couldn't quickly see why the result variable is resolved twice.)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-07-02 Tobias Burnus bur...@net-b.de
PR fortran/53818
* resolve.c (apply_default_init_local): Don't create an
initializer for a result variable.
2012-07-02 Tobias Burnus bur...@net-b.de
PR fortran/53818
* gfortran.dg/init_flag_11.f90: New.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 0434e08..c7f14a2 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -10269,7 +10328,7 @@ apply_default_init_local (gfc_symbol *sym)
entry, so we just add a static initializer. Note that automatic variables
are stack allocated even with -fno-automatic. */
if (sym-attr.save || sym-ns-save_all
- || (gfc_option.flag_max_stack_var_size == 0
+ || (gfc_option.flag_max_stack_var_size == 0 !sym-attr.result
(!sym-attr.dimension || !is_non_constant_shape_array (sym
{
/* Don't clobber an existing initializer! */
--- /dev/null 2012-06-30 08:05:14.091716208 +0200
+++ gcc/gcc/testsuite/gfortran.dg/init_flag_11.f90 2012-07-02 08:58:54.0 +0200
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-flags -finit-local-zero -fno-automatic
+!
+! PR fortran/53818
+!
+! Contributed by John Moyard
+!
+logical function testing(date1, date2) result(test)
+ integer date1, date2
+ test = ( (date1 date2) .or. ( date1==date2 ))
+end function testing
Re: RFA: MEP: Fix use of delete_insn.
Hi DJ,
We have this at the top of the loop, so I don't think it matters:
next = NEXT_INSN (insn);
if (GET_CODE (insn) != INSN)
continue;
Good point.
However, I think an insn will be skipped if we use NEXT. Perhaps we
want PREV? Or the loop might need to be altered to account for this
potential skipping.
Hmm, I think that just using the NEXT_INSN at the head of the loop
should work. As far as I can tell from looking at the code in
mep_reorg_remove() we are never going to delete an insn that might
involve removing more than one real insn, so we do not have to worry
about side effects. Hence I would suggest the following alternative patch.
OK to apply ?
Cheers
Nick
Index: gcc/config/mep/mep.c
===
--- gcc/config/mep/mep.c(revision 189108)
+++ gcc/config/mep/mep.c(working copy)
@@ -5096,7 +5096,7 @@
follow, where))
{
count ++;
- next = delete_insn (insn);
+ delete_insn (insn);
if (dump_file)
{
fprintf (dump_file, \n- Success! new insn:\n\n);
GCC 4.5 branch is closed now
The GCC 4.5.4 release has been tagged and is being created right now. The 4.5 branch is thus now closed. We have now two actively maintained releases as planned, 4.6.x and 4.7.x. Richard.
Re: [testsuite] don't use lto plugin if it doesn't work
On Jun 29, 2012, Mike Stump mikest...@comcast.net wrote: First, let get to the heart of the matter. That is the behavior of compiler. That's a distraction in the context of a patch to improve a feature that's already present in the testsuite machinery, isn't it? I have no objection to discussing this other topic you want to bring forth, but for reasons already stated and restated I don't think it precludes the proposed patch and the improvements to testsuite result reporting it brings about. Do you think it works perfectly and needs no changing in this area I think the compiler is working just fine. It is told at build time whether or not to expect a linker with plugin support at run time, and behaves accordingly. Configure detects that based on linker version, which is in line with various other binutils feature tests we have in place, so I don't see that the test *needs* changing. If it were to change in such a way that, in a “native cross” build scenario, it failed to detect plugin support that is actually available on the equivalent linker one would find on the configured host=target run time platform, I'd be inclined to regard that as a regression and a bug. My take was, the compiler should not try and use the plugin that won't work, and that this should be a static config bit built up from the usual config time methods for the host system. Do you agree, if not why, and what is your take? I agree with that. Indeed, it seems like a restatement of what I just wrote above, unless one thinks configure should assume the user lied in the given triplets. Because, really, we *are* lying to configure when we say we're building a i686-linux-gnu native natively when the build system is actually a x86_64-linux-gnu with some wrapper scripts that approximate i686-linux-gnu. If we tell configure we're building a compiler for an i686-linux-gnu system, configure should listen to us, rather than second-guess us. And if we fail to provide it with an environment that is sufficiently close to what we asked for, it's entirely our own fault, rather than configure's fault for not realizing we were cheating and compensating for our lies. Now, of course, none of this goes against an ability to explicitly specify whether or not to build a plugin, or to expect it to work with the linker-for-target on host. But I don't think we should change the current default detection for the sake of the i686-native-on-x86_64 scenario, for it really is the best we can do in such a native-but-not-quite scenario, for we can't possibly test properties of the actual native linker if what's available at build time is some other linker. What we *can* and *should* do, IMHO, is to improve the test machinery, so that if we happen to test a toolchain built for i686 on a non-i686 system whose linker fails to load the i686 plugin, we don't waste time testing stuff the testsuite itself has already detected as nonfunctional, and we avoid the thousands of failures that would ensue. Another thing we may want to do documentat how to test GCC in such fake-native settings, so that people can refer to it and save duplicate effort and avoid inconsistent results. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [testsuite] don't use lto plugin if it doesn't work
On Mon, Jul 2, 2012 at 1:06 PM, Alexandre Oliva aol...@redhat.com wrote: On Jun 29, 2012, Mike Stump mikest...@comcast.net wrote: First, let get to the heart of the matter. That is the behavior of compiler. That's a distraction in the context of a patch to improve a feature that's already present in the testsuite machinery, isn't it? I have no objection to discussing this other topic you want to bring forth, but for reasons already stated and restated I don't think it precludes the proposed patch and the improvements to testsuite result reporting it brings about. Do you think it works perfectly and needs no changing in this area I think the compiler is working just fine. It is told at build time whether or not to expect a linker with plugin support at run time, and behaves accordingly. Configure detects that based on linker version, which is in line with various other binutils feature tests we have in place, so I don't see that the test *needs* changing. If it were to change in such a way that, in a “native cross” build scenario, it failed to detect plugin support that is actually available on the equivalent linker one would find on the configured host=target run time platform, I'd be inclined to regard that as a regression and a bug. My take was, the compiler should not try and use the plugin that won't work, and that this should be a static config bit built up from the usual config time methods for the host system. Do you agree, if not why, and what is your take? I agree with that. Indeed, it seems like a restatement of what I just wrote above, unless one thinks configure should assume the user lied in the given triplets. Because, really, we *are* lying to configure when we say we're building a i686-linux-gnu native natively when the build system is actually a x86_64-linux-gnu with some wrapper scripts that approximate i686-linux-gnu. If we tell configure we're building a compiler for an i686-linux-gnu system, configure should listen to us, rather than second-guess us. And if we fail to provide it with an environment that is sufficiently close to what we asked for, it's entirely our own fault, rather than configure's fault for not realizing we were cheating and compensating for our lies. Now, of course, none of this goes against an ability to explicitly specify whether or not to build a plugin, or to expect it to work with the linker-for-target on host. But I don't think we should change the current default detection for the sake of the i686-native-on-x86_64 scenario, for it really is the best we can do in such a native-but-not-quite scenario, for we can't possibly test properties of the actual native linker if what's available at build time is some other linker. What we *can* and *should* do, IMHO, is to improve the test machinery, so that if we happen to test a toolchain built for i686 on a non-i686 system whose linker fails to load the i686 plugin, we don't waste time testing stuff the testsuite itself has already detected as nonfunctional, and we avoid the thousands of failures that would ensue. If you consider what happens if we break the lto-plugin so that it fails loading or crashes the linker, then it's clear that we _do_ want to see this effect in the testsuite as FAIL. Merely making tests UNSUPPORTED in this case is not what we want ... Another thing we may want to do documentat how to test GCC in such fake-native settings, so that people can refer to it and save duplicate effort and avoid inconsistent results. ... which means that maybe we should not encourage such settings at all. Richard. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [graphite] RFC: Add ISL variants of remaining PPL things
Hi Tobi,
On Fri, 29 Jun 2012, Tobias Grosser wrote:
+static isl_constraint *
+build_linearized_memory_access (isl_map *map, poly_dr_p pdr)
+{
+}
The function itself looks correct. However, I would personally have returned
an isl_map instead of an isl_constraint.
As you noticed I modelled all my isl code after the existing PPL code
(which returned an expression here, turned into a conflict in the caller).
I couldn't learn the polyhedral basics, PPL basics, isl basics _and_ the
correct isl idioms on one weekend :) So many thanks for the hints.
A map {A[i,j] - [200 * i]} is probably a nicer way to represent a
transformation from the higher level array type to an actual memory
reference.
Hmm. This ignores the 'j' input dimension. Can I also have a map ala
{A[i,j] - [200 * i + j]}? I don't directly see how, as for that I'd need
at least another dimension (the 'L' in the callers map).
+pdr_stride_in_loop (mpz_t stride, graphite_dim_t depth, poly_dr_p pdr)
+{
+ poly_bb_p pbb = PDR_PBB (pdr);
+ isl_map *map;
+ isl_set *set;
+ isl_aff *aff;
+ isl_space *dc;
+ isl_constraint *lma, *c;
+ isl_int islstride;
+ enum isl_lp_result lpres;
+ graphite_dim_t time_depth;
+ unsigned offset, nt;
+ unsigned i;
+ /* pdr-accesses:[P1..nb_param,I1..nb_domain]-[a,S1..nb_subscript]
+ ??? [P] not used for PDRs?
+ pdr-extent: [a,S1..nb_subscript]
+ pbb-domain: [P1..nb_param,I1..nb_domain]
+ pbb-transformed: [P1..nb_param,I1..nb_domain]-[T1..Tnb_sctr]
+ [T] includes local vars (currently unused)
+
+ First we create [P,I] - [T,a,S]. */
+
+ map = isl_map_flat_range_product (isl_map_copy (pbb-transformed),
+ isl_map_copy (pdr-accesses));
+ /* Add a dimension for L: [P,I] - [T,a,S,L].*/
+ map = isl_map_add_dims (map, isl_dim_out, 1);
+ /* Build a constraint for lma[S] - L == 0, effectively calculating
+ L in terms of subscripts. */
+ lma = build_linearized_memory_access (map, pdr);
+ /* And add it to the map, so we now have:
+ [P,I] - [T,a,S,L] : lma([S]) == L. */
+ map = isl_map_add_constraint (map, lma);
+
+ /* Then we create [P,I,P',I'] - [T,a,S,L,T',a',S',L']. */
+ map = isl_map_flat_product (map, isl_map_copy (map));
Your analysis is here a 1:1 mapping from PPL to isl. That works, but is
probably not the nicest/conceptually cleanest way to implement this. In
general, in isl we try to avoid adding/removing individual dimensions
explicitly.
Yeah, I noticed that, but didn't know how to get around adding the L
dimension (I at least used flat_product for creating the X' dimensions
instead of explicit dimension insertions and moving).
The canonical way to express such transformations is to create a
new map and to apply this map on the set/map you want to modify. For this
algorithm, I would start with the pdr-accesses map and 'apply'
pbb-transformed to map the original iteration space into the scattering
space.
Let's see if I understand: So, we have [PI]-[aS] (Params, Iteration
domain, alias set, Subscript) as accesses, and we have [PI]-[T]
(Transformed) as the scattering. Indeed what I ideally wanted to have is
a [T]-[aS] mapping, but I couldn't see how to construct such. So you're
saying that I can apply the PI-T to the domain of PI-aS, and that gives
me the T-aS? Probably I was confused by the functional syntax (the -),
as in normal functions you can't simply apply a function to a functions
domain and expect to get anything sensible out of that. I see that in
your code you reverse the scattering first (T-PI), IIRC that's one thing
I also tried, but I got stuck somewhere.
I would than apply the isl_map calculated by
build_linearized_memory_access to map the array to the actual data
location accessed. Now you create a map 'scattering-scattering' that
maps from one scattering time point to the next. And apply the map
'scattering-memory' on both the range and the domain. You will end up
with a map memory - memory.
Yeah. If my above understanding is correct the path is clear.
Here you can use the deltas function to give you the distances. ;-)
I couldn't figure out from isls user manual what exactly the delta
functions do :) From the description above I think I understand now. Let
me experiment a bit more.
You can have a look in Polly, where I implement a similar calculation:
http://repo.or.cz/w/polly-mirror.git/blob/HEAD:/lib/Analysis/ScopInfo.cpp#l390
The games you play with projecting out some dimensions are related to
which dimension you want to calculate the stride, right? (As you always
calculate the next scatterting to have n+1 in the last dimension, not an
arbitrary one).
+print_isl_map (FILE *f, isl_map *map)
If this is the
case, you can either use isl_set_dump(set), isl_map_dump(map), ..
There functions weren't documented. Thanks. But I need a file
Re: [PATCH] Move Graphite to upstream cloog 0.17.0
On Wed, 27 Jun 2012, Diego Novillo wrote: On Fri, Jun 22, 2012 at 9:16 AM, Richard Guenther rguent...@suse.de wrote: This bumps the requirement to enable Graphite to using cloog 0.17.0 which is the last release from upstream. The patch removes the support for the legacy cloog versions, too. I am bootstrapping and testing this now with cloog 0.17.0 built against the upstream ISL 0.10 version. If this ends up being approved I will put the cloog 0.17.0 tarball in the infrastructure directory. Bootstrap and regtest pending on x86_64-unknown-linux-gnu. Ok for trunk (for the build parts)? The build parts look fine. I have installed this first patch now, with the followup to move from PPL to ISL in GCC itself scheduled after a re-bootstrap test later. I am also installing the following update to changes.html. Thanks, Richard. 2012-07-02 Richard Guenther rguent...@suse.de * gcc-4.8/changes.html: Mention new build requirements for Graphite. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.1 diff -r1.1 changes.html 15d14 !-- 17d15 -- 18a17,22 pTo enable the Graphite framework for loop optimizations you now need CLooG version 0.17.0 and ISL version 0.10. Both can be obtained from the a href=ftp://gcc.gnu.org/pub/gcc/infrastructure/;GCC infrastructure/a directory. The installation manual contains more information about requirements to build GCC./p
Re: [PATCH] Move Graphite from using PPL over to ISL
On Thu, 28 Jun 2012, Diego Novillo wrote: On 12-06-27 11:06 , Richard Guenther wrote: 2012-06-27 Richard Guenther rguent...@suse.de Michael Matz m...@suse.de Tobias Grosser tob...@grosser.es Sebastian Pop seb...@gmail.com config/ * cloog.m4: Set up to work against ISL only. * isl.m4: New file. * Makefile.def: Add ISL host module, remove PPL host module. Adjust ClooG host module to use the proper ISL. * Makefile.tpl: Pass ISL include flags instead of PPL ones. * configure.ac: Include config/isl.m4. Add ISL host library, remove PPL. Remove PPL configury, add ISL configury, adjust ClooG configury. * Makefile.in: Regenerated. * configure: Likewise. gcc/ * Makefile.in: Remove PPL flags in favor of ISL ones. (BACKENDLIBS): Remove PPL libs. (INCLUDES): Remove PPL includes in favor of ISL ones. (graphite-clast-to-gimple.o): Remove graphite-dependences.h and graphite-cloog-compat.h dependencies. (graphite-dependences.o): Likewise. (graphite-poly.o): Likewise. * configure.ac: Declare ISL vars instead of PPL ones. * configure: Regenerated. * doc/install.texi: Replace PPL requirement documentation with ISL one. * graphite-blocking.c: Remove PPL code, add ISL equivalent. * graphite-clast-to-gimple.c: Likewise. * graphite-dependences.c: Likewise. * graphite-interchange.c: Likewise. * graphite-poly.h: Likewise. * graphite-poly.c: Likewise. * graphite-sese-to-poly.c: Likewise. * graphite.c: Likewise. * graphite-scop-detection.c: Re-arrange includes. * graphite-cloog-util.c: Remove. * graphite-cloog-util.h: Likewise. * graphite-ppl.h: Likewise. * graphite-ppl.c: Likewise. * graphite-dependences.h: Likewise. libgomp/ * testsuite/libgomp.graphite/force-parallel-4.c: Adjust. * testsuite/libgomp.graphite/force-parallel-5.c: Likewise. * testsuite/libgomp.graphite/force-parallel-7.c: Likewise. * testsuite/libgomp.graphite/force-parallel-8.c: Likewise. OK. Committed. Richard.
New Russian PO file for 'gcc' (version 4.7.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Russian team of translators. The file is available at: http://translationproject.org/latest/gcc/ru.po (This file, 'gcc-4.7.1.ru.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
New Russian PO file for 'gcc' (version 4.7.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Russian team of translators. The file is available at: http://translationproject.org/latest/gcc/ru.po (This file, 'gcc-4.7.1.ru.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [PR52983] eliminate autoinc from debug_insn locs
On Jun 13, 2012, Alexandre Oliva aol...@redhat.com wrote:
On May 3, 2012, Alexandre Oliva aol...@redhat.com wrote:
Here are the 3 patches that, together, are equivalent to the one posted
before, except for the visibility of cleanup_auto_inc_dec.
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00300.html
Ping²?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/52983
* valtrack.h, valtrack.c: New.
* Makefile.in (VALTRACK_H): New.
(OBJS): Add valtrack.o.
(valtrack.o): New.
(cselib.o, dce.o, df-problems.o, combine.o): Add VALTRACK_H.
* combine.c: Include valtrack.h.
(make_compound_operation): Publish.
(cleanup_auto_inc_dec): Move to valtrack.c.
(struct rtx_subst_pair, propagate_for_debug_subst): Likewise.
(propagate_for_debug): Likewise. Add this_basic_block parameter.
Adjust all callers.
* cselib.c: Include valtrack.h.
* dce.c: Likewise.
* df-problems.c: Likewise.
(dead_debug_init, dead_debug_reset_uses): Move to valtrack.c.
(dead_debug_finish, dead_debug_add): Likewise.
(dead_debug_insert_temp): Likewise.
* df.h (struct dead_debug_use): Move to valtrack.h.
(struct dead_debug, enum debug_temp_where): Likewise.
(dead_debug_init, dead_debug_reset_uses): Move to valtrack.h.
(dead_debug_finish, dead_debug_add): Likewise.
(dead_debug_insert_temp): Likewise.
* rtl.h (make_compound_operation): Declare.
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/52983
* valtrack.c (cleanup_auto_inc_dec): Implement unconditionally,
falling back to copy_rtx on non-autoinc machines.
(propagate_for_debug_subst): Always use cleanup_auto_inc_dec.
Ugh, the 3rd patch was a mistaken repeat of the 1st. Here is the 3rd
patch I was supposed to have posted, that completes the fix.
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/52983
* valtrack.c (dead_debug_insert_temp): Use cleanup_auto_inc_dec.
Index: gcc/valtrack.c
===
--- gcc/valtrack.c.orig 2012-05-03 15:44:47.934692987 -0300
+++ gcc/valtrack.c 2012-05-03 15:44:52.540628548 -0300
@@ -385,7 +385,7 @@ dead_debug_insert_temp (struct dead_debu
breg = NULL;
/* Cool, it's the same REG, we can use SRC. */
else if (dest == reg)
- breg = copy_rtx (src);
+ breg = cleanup_auto_inc_dec (src, VOIDmode);
else if (REG_P (dest))
{
/* Hmm... Something's fishy, we should be setting REG here. */
@@ -394,7 +394,8 @@ dead_debug_insert_temp (struct dead_debu
/* Ok, it's the same (hardware) REG, but with a different
mode, so SUBREG it. */
else
- breg = lowpart_subreg (GET_MODE (reg), copy_rtx (src),
+ breg = lowpart_subreg (GET_MODE (reg),
+ cleanup_auto_inc_dec (src, VOIDmode),
GET_MODE (dest));
}
else if (GET_CODE (dest) == SUBREG)
@@ -415,7 +416,8 @@ dead_debug_insert_temp (struct dead_debu
breg = NULL;
/* Yay, we can use SRC, just adjust its mode. */
else
- breg = lowpart_subreg (GET_MODE (reg), copy_rtx (src),
+ breg = lowpart_subreg (GET_MODE (reg),
+ cleanup_auto_inc_dec (src, VOIDmode),
GET_MODE (dest));
}
/* Oh well, we're out of luck. */
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: Allow use of ranges in copyright notices
On Jun 30, 2012, David Edelsohn dje@gmail.com wrote: IBM's policy specifies a comma: first year, last year and not a dash range. But this notation already means something else in our source tree. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [PATCH] Move Graphite from using PPL over to ISL
On Mon, Jul 02, 2012 at 01:43:56PM +0200, Richard Guenther wrote:
On Thu, 28 Jun 2012, Diego Novillo wrote:
On 12-06-27 11:06 , Richard Guenther wrote:
2012-06-27 Richard Guenther rguent...@suse.de
Michael Matz m...@suse.de
Tobias Grosser tob...@grosser.es
Sebastian Pop seb...@gmail.com
config/
* cloog.m4: Set up to work against ISL only.
* isl.m4: New file.
* Makefile.def: Add ISL host module, remove PPL host module.
Adjust ClooG host module to use the proper ISL.
* Makefile.tpl: Pass ISL include flags instead of PPL ones.
* configure.ac: Include config/isl.m4. Add ISL host library,
remove PPL. Remove PPL configury, add ISL configury, adjust
ClooG configury.
* Makefile.in: Regenerated.
* configure: Likewise.
gcc/
* Makefile.in: Remove PPL flags in favor of ISL ones.
(BACKENDLIBS): Remove PPL libs.
(INCLUDES): Remove PPL includes in favor of ISL ones.
(graphite-clast-to-gimple.o): Remove graphite-dependences.h and
graphite-cloog-compat.h dependencies.
(graphite-dependences.o): Likewise.
(graphite-poly.o): Likewise.
* configure.ac: Declare ISL vars instead of PPL ones.
* configure: Regenerated.
* doc/install.texi: Replace PPL requirement documentation
with ISL one.
* graphite-blocking.c: Remove PPL code, add ISL equivalent.
* graphite-clast-to-gimple.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-interchange.c: Likewise.
* graphite-poly.h: Likewise.
* graphite-poly.c: Likewise.
* graphite-sese-to-poly.c: Likewise.
* graphite.c: Likewise.
* graphite-scop-detection.c: Re-arrange includes.
* graphite-cloog-util.c: Remove.
* graphite-cloog-util.h: Likewise.
* graphite-ppl.h: Likewise.
* graphite-ppl.c: Likewise.
* graphite-dependences.h: Likewise.
libgomp/
* testsuite/libgomp.graphite/force-parallel-4.c: Adjust.
* testsuite/libgomp.graphite/force-parallel-5.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-7.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-8.c: Likewise.
OK.
Committed.
Richard.
Richard,
At r189157, with isl 0.10 and cloog.org 0.17.0 installed from the
infrastructure
directory, I am seeing a configure failure with...
$ ../gcc-4.8-20120702/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
of...
configure:5697: checking for version 0.10 of ISL
configure:5725: gcc -o conftest -g -O2 -I/sw/include -I/sw/include
-I/sw/include-L/sw/lib -lisl -lisl conftest.c 5
conftest.c:15:11: error: expected ';' at end of declaration
int main()
^
;
1 error generated.
configure:5725: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| #define LT_OBJDIR .libs/
| /* end confdefs.h. */
| #include isl/version.h
|#include string.h
| int
| main ()
| {
| int main()
|{
| if (strncmp (isl_version (), isl-0.10, strlen (isl-0.10)) != 0)
|return 1;
| return 0;
|}
| ;
| return 0;
| }
configure:5735: result: no
configure:5769: error: Unable to find a usable ISL. See config.log for details.
Re: Allow use of ranges in copyright notices
On 7/2/2012 8:35 AM, Alexandre Oliva wrote: On Jun 30, 2012, David Edelsohn dje@gmail.com wrote: IBM's policy specifies a comma: first year, last year and not a dash range. But this notation already means something else in our source tree. I think using the dash is preferable, and is a VERY widely used notation, used by all major software companies I deal with!
Re: [PATCH] Move Graphite from using PPL over to ISL
On Mon, Jul 02, 2012 at 09:37:20AM -0400, Jack Howarth wrote:
On Mon, Jul 02, 2012 at 01:43:56PM +0200, Richard Guenther wrote:
On Thu, 28 Jun 2012, Diego Novillo wrote:
On 12-06-27 11:06 , Richard Guenther wrote:
2012-06-27 Richard Guenther rguent...@suse.de
Michael Matz m...@suse.de
Tobias Grosser tob...@grosser.es
Sebastian Pop seb...@gmail.com
config/
* cloog.m4: Set up to work against ISL only.
* isl.m4: New file.
* Makefile.def: Add ISL host module, remove PPL host module.
Adjust ClooG host module to use the proper ISL.
* Makefile.tpl: Pass ISL include flags instead of PPL ones.
* configure.ac: Include config/isl.m4. Add ISL host library,
remove PPL. Remove PPL configury, add ISL configury, adjust
ClooG configury.
* Makefile.in: Regenerated.
* configure: Likewise.
gcc/
* Makefile.in: Remove PPL flags in favor of ISL ones.
(BACKENDLIBS): Remove PPL libs.
(INCLUDES): Remove PPL includes in favor of ISL ones.
(graphite-clast-to-gimple.o): Remove graphite-dependences.h and
graphite-cloog-compat.h dependencies.
(graphite-dependences.o): Likewise.
(graphite-poly.o): Likewise.
* configure.ac: Declare ISL vars instead of PPL ones.
* configure: Regenerated.
* doc/install.texi: Replace PPL requirement documentation
with ISL one.
* graphite-blocking.c: Remove PPL code, add ISL equivalent.
* graphite-clast-to-gimple.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-interchange.c: Likewise.
* graphite-poly.h: Likewise.
* graphite-poly.c: Likewise.
* graphite-sese-to-poly.c: Likewise.
* graphite.c: Likewise.
* graphite-scop-detection.c: Re-arrange includes.
* graphite-cloog-util.c: Remove.
* graphite-cloog-util.h: Likewise.
* graphite-ppl.h: Likewise.
* graphite-ppl.c: Likewise.
* graphite-dependences.h: Likewise.
libgomp/
* testsuite/libgomp.graphite/force-parallel-4.c: Adjust.
* testsuite/libgomp.graphite/force-parallel-5.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-7.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-8.c: Likewise.
OK.
Committed.
Richard.
Richard,
At r189157, with isl 0.10 and cloog.org 0.17.0 installed from the
infrastructure
directory, I am seeing a configure failure with...
$ ../gcc-4.8-20120702/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
of...
configure:5697: checking for version 0.10 of ISL
configure:5725: gcc -o conftest -g -O2 -I/sw/include -I/sw/include
-I/sw/include-L/sw/lib -lisl -lisl conftest.c 5
conftest.c:15:11: error: expected ';' at end of declaration
int main()
^
;
1 error generated.
configure:5725: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| #define LT_OBJDIR .libs/
| /* end confdefs.h. */
| #include isl/version.h
|#include string.h
| int
| main ()
| {
| int main()
|{
| if (strncmp (isl_version (), isl-0.10, strlen (isl-0.10)) != 0)
|return 1;
| return 0;
|}
| ;
| return 0;
| }
configure:5735: result: no
configure:5769: error: Unable to find a usable ISL. See config.log for
details.
Richard,
Regenerating the top-level configure with 'autoconf -I. -I./config' at
r189157 doesn't resolve the issue.
Jack
Re: [PATCH] Move Graphite from using PPL over to ISL
On Mon, 2 Jul 2012, Jack Howarth wrote:
On Mon, Jul 02, 2012 at 09:37:20AM -0400, Jack Howarth wrote:
On Mon, Jul 02, 2012 at 01:43:56PM +0200, Richard Guenther wrote:
On Thu, 28 Jun 2012, Diego Novillo wrote:
On 12-06-27 11:06 , Richard Guenther wrote:
2012-06-27 Richard Guenther rguent...@suse.de
Michael Matz m...@suse.de
Tobias Grosser tob...@grosser.es
Sebastian Pop seb...@gmail.com
config/
* cloog.m4: Set up to work against ISL only.
* isl.m4: New file.
* Makefile.def: Add ISL host module, remove PPL host module.
Adjust ClooG host module to use the proper ISL.
* Makefile.tpl: Pass ISL include flags instead of PPL ones.
* configure.ac: Include config/isl.m4. Add ISL host library,
remove PPL. Remove PPL configury, add ISL configury, adjust
ClooG configury.
* Makefile.in: Regenerated.
* configure: Likewise.
gcc/
* Makefile.in: Remove PPL flags in favor of ISL ones.
(BACKENDLIBS): Remove PPL libs.
(INCLUDES): Remove PPL includes in favor of ISL ones.
(graphite-clast-to-gimple.o): Remove graphite-dependences.h and
graphite-cloog-compat.h dependencies.
(graphite-dependences.o): Likewise.
(graphite-poly.o): Likewise.
* configure.ac: Declare ISL vars instead of PPL ones.
* configure: Regenerated.
* doc/install.texi: Replace PPL requirement documentation
with ISL one.
* graphite-blocking.c: Remove PPL code, add ISL equivalent.
* graphite-clast-to-gimple.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-interchange.c: Likewise.
* graphite-poly.h: Likewise.
* graphite-poly.c: Likewise.
* graphite-sese-to-poly.c: Likewise.
* graphite.c: Likewise.
* graphite-scop-detection.c: Re-arrange includes.
* graphite-cloog-util.c: Remove.
* graphite-cloog-util.h: Likewise.
* graphite-ppl.h: Likewise.
* graphite-ppl.c: Likewise.
* graphite-dependences.h: Likewise.
libgomp/
* testsuite/libgomp.graphite/force-parallel-4.c: Adjust.
* testsuite/libgomp.graphite/force-parallel-5.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-7.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-8.c: Likewise.
OK.
Committed.
Richard.
Richard,
At r189157, with isl 0.10 and cloog.org 0.17.0 installed from the
infrastructure
directory, I am seeing a configure failure with...
$ ../gcc-4.8-20120702/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
of...
configure:5697: checking for version 0.10 of ISL
configure:5725: gcc -o conftest -g -O2 -I/sw/include -I/sw/include
-I/sw/include-L/sw/lib -lisl -lisl conftest.c 5
conftest.c:15:11: error: expected ';' at end of declaration
int main()
^
;
1 error generated.
configure:5725: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| #define LT_OBJDIR .libs/
| /* end confdefs.h. */
| #include isl/version.h
|#include string.h
| int
| main ()
| {
| int main()
|{
| if (strncmp (isl_version (), isl-0.10, strlen (isl-0.10)) != 0)
|return 1;
| return 0;
|}
| ;
| return 0;
| }
configure:5735: result: no
configure:5769: error: Unable to find a usable ISL. See config.log for
details.
Richard,
Regenerating the top-level configure with 'autoconf -I. -I./config' at
r189157 doesn't resolve the issue.
Yeah, I see the issue ;) Still my host compilers happily accept
int main() { int main () {} } and do not error:
configure:5697: checking for version 0.10 of ISL
configure:5725: gcc -o conftest -g -lisl -lisl conftest.c 5
configure:5725: $? = 0
configure:5725: ./conftest
configure:5725: $? = 0
configure:5735: result: yes
I'll test a fix.
Thanks,
Richard.
Re: [PATCH] Move Graphite from using PPL over to ISL
On Mon, 2 Jul 2012, Richard Guenther wrote:
On Mon, 2 Jul 2012, Jack Howarth wrote:
On Mon, Jul 02, 2012 at 09:37:20AM -0400, Jack Howarth wrote:
On Mon, Jul 02, 2012 at 01:43:56PM +0200, Richard Guenther wrote:
On Thu, 28 Jun 2012, Diego Novillo wrote:
On 12-06-27 11:06 , Richard Guenther wrote:
2012-06-27 Richard Guenther rguent...@suse.de
Michael Matz m...@suse.de
Tobias Grosser tob...@grosser.es
Sebastian Pop seb...@gmail.com
config/
* cloog.m4: Set up to work against ISL only.
* isl.m4: New file.
* Makefile.def: Add ISL host module, remove PPL host module.
Adjust ClooG host module to use the proper ISL.
* Makefile.tpl: Pass ISL include flags instead of PPL ones.
* configure.ac: Include config/isl.m4. Add ISL host library,
remove PPL. Remove PPL configury, add ISL configury, adjust
ClooG configury.
* Makefile.in: Regenerated.
* configure: Likewise.
gcc/
* Makefile.in: Remove PPL flags in favor of ISL ones.
(BACKENDLIBS): Remove PPL libs.
(INCLUDES): Remove PPL includes in favor of ISL ones.
(graphite-clast-to-gimple.o): Remove graphite-dependences.h and
graphite-cloog-compat.h dependencies.
(graphite-dependences.o): Likewise.
(graphite-poly.o): Likewise.
* configure.ac: Declare ISL vars instead of PPL ones.
* configure: Regenerated.
* doc/install.texi: Replace PPL requirement documentation
with ISL one.
* graphite-blocking.c: Remove PPL code, add ISL equivalent.
* graphite-clast-to-gimple.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-interchange.c: Likewise.
* graphite-poly.h: Likewise.
* graphite-poly.c: Likewise.
* graphite-sese-to-poly.c: Likewise.
* graphite.c: Likewise.
* graphite-scop-detection.c: Re-arrange includes.
* graphite-cloog-util.c: Remove.
* graphite-cloog-util.h: Likewise.
* graphite-ppl.h: Likewise.
* graphite-ppl.c: Likewise.
* graphite-dependences.h: Likewise.
libgomp/
* testsuite/libgomp.graphite/force-parallel-4.c: Adjust.
* testsuite/libgomp.graphite/force-parallel-5.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-7.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-8.c: Likewise.
OK.
Committed.
Richard.
Richard,
At r189157, with isl 0.10 and cloog.org 0.17.0 installed from the
infrastructure
directory, I am seeing a configure failure with...
$ ../gcc-4.8-20120702/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
of...
configure:5697: checking for version 0.10 of ISL
configure:5725: gcc -o conftest -g -O2 -I/sw/include -I/sw/include
-I/sw/include-L/sw/lib -lisl -lisl conftest.c 5
conftest.c:15:11: error: expected ';' at end of declaration
int main()
^
;
1 error generated.
configure:5725: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| #define LT_OBJDIR .libs/
| /* end confdefs.h. */
| #include isl/version.h
|#include string.h
| int
| main ()
| {
| int main()
|{
| if (strncmp (isl_version (), isl-0.10, strlen (isl-0.10)) != 0)
|return 1;
| return 0;
|}
| ;
| return 0;
| }
configure:5735: result: no
configure:5769: error: Unable to find a usable ISL. See config.log for
details.
Richard,
Regenerating the top-level configure with 'autoconf -I. -I./config' at
r189157 doesn't resolve the issue.
Yeah, I see the issue ;) Still my host compilers happily accept
int main() { int main () {} } and do not error:
configure:5697: checking for version 0.10 of ISL
configure:5725: gcc -o conftest -g -lisl -lisl conftest.c 5
configure:5725: $? = 0
configure:5725: ./conftest
configure:5725: $? = 0
configure:5735: result: yes
I'll test a fix.
Like so.
Richard.
2012-07-02 Richard Guenther rguent...@suse.de
config/
* isl.m4 (_ISL_CHECK_CT_PROG): Omit main function header/footer.
Fix version test.
* configure
Re: Allow use of ranges in copyright notices
Robert Dewar de...@adacore.com writes: On 7/2/2012 8:35 AM, Alexandre Oliva wrote: On Jun 30, 2012, David Edelsohn dje@gmail.com wrote: IBM's policy specifies a comma: first year, last year and not a dash range. But this notation already means something else in our source tree. I think using the dash is preferable, and is a VERY widely used notation, used by all major software companies I deal with! Also the dash notation has been vetted by FSF lawyers (and accordingly is used by other GNU projects that pay a lot of attention to getting the legal details right, like Emacs). -miles -- Politeness, n. The most acceptable hypocrisy.
Re: Allow use of ranges in copyright notices
On Mon, 2 Jul 2012, Robert Dewar wrote: On 7/2/2012 8:35 AM, Alexandre Oliva wrote: On Jun 30, 2012, David Edelsohn dje@gmail.com wrote: IBM's policy specifies a comma: first year, last year and not a dash range. But this notation already means something else in our source tree. I think using the dash is preferable, and is a VERY widely used notation, used by all major software companies I deal with! And as a GNU project there isn't a choice between using IBM convention and GNU convention - only about which of the GNU options we use. The simplest is first-year-2012 (for any value of first-year 1987 or later) and so I am proposing we move to that (make this change to README to allow it, allow converting files when 2012 is added to the copyright years, as is now done in glibc, allow a bulk conversion if anyone wishes to do one). -- Joseph S. Myers jos...@codesourcery.com
Re: [patch] Move lowering of switches to bit tests to GIMPLE
On Sun, Jul 1, 2012 at 11:58 AM, Richard Guenther richard.guent...@gmail.com wrote: On Sat, Jun 30, 2012 at 12:29 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, This patch moves the emit_case_bit_tests method of switch lowering from 'expand' to a GIMPLE pass. Initially, I planned to move all switch lowering to something other than a casesi or tablejump to GIMPLE, but this is more involved than I anticipated. My plan was (and still is, but for later) to do the switch lowering using a divide-and-conquer approach: Parts of a switch may be best expanded as bit-tests, other parts maybe as a decision tree, and yet others as casesi/tablejump (the code in stmt.c uses only one of these approaches per GIMPLE_SWITCH). Also I wanted to use profile information in the lowering decision making (using Freescale's patch as a basis). But I need to come up with a way to handle the SJLJ dispatch table issue. I'll continue to work on all of the above, and I hope I can finish everything I planned to work on for GCC 4.8. But to make sure I don't miss the GCC 4.8 stage1 deadline, I'm proposing this for trunk now. Bootstrappedtested on powerpc64-unknown-linux-gnu - several times in fact, over the past few months. Bootstrappedtested on x86_64-unknown-linux-gnu. Also builttested on various powerpc64 X embedded targets. OK for trunk? This is ok. Hello, It turns out that I had a code generation bug in the transformation all along, but it only triggered since the straight-line strength reduction pass was introduced. This also showed up in a switchconv test case that should have failed, but passed. So I fixed the test case also, in this new patch. Fixed patch attached, which I tested in the same way as before. I'll commit this later this week, assuming your approval still stands. Ciao! Steven move_switch_as_case_bit_tests_to_GIMPLE_v2.diff Description: Binary data
Re: [graphite] RFC: Add ISL variants of remaining PPL things
On 07/02/2012 01:32 PM, Michael Matz wrote:
Hi Tobi,
On Fri, 29 Jun 2012, Tobias Grosser wrote:
+static isl_constraint *
+build_linearized_memory_access (isl_map *map, poly_dr_p pdr)
+{
+}
The function itself looks correct. However, I would personally have returned
an isl_map instead of an isl_constraint.
As you noticed I modelled all my isl code after the existing PPL code
(which returned an expression here, turned into a conflict in the caller).
I couldn't learn the polyhedral basics, PPL basics, isl basics _and_ the
correct isl idioms on one weekend :) So many thanks for the hints.
No worries, I believe a direct translation is a good start. we can
improve later on that.
A map {A[i,j] - [200 * i]} is probably a nicer way to represent a
transformation from the higher level array type to an actual memory
reference.
Hmm. This ignores the 'j' input dimension. Can I also have a map ala
{A[i,j] - [200 * i + j]}? I don't directly see how, as for that I'd need
at least another dimension (the 'L' in the callers map).
Yes, you can have this: A[i,j] - [200 * i + j]}
It is basically a pretty printing of:
{A[i,j] - [o]: o = 200 * i + j}
The canonical way to express such transformations is to create a
new map and to apply this map on the set/map you want to modify. For this
algorithm, I would start with the pdr-accesses map and 'apply'
pbb-transformed to map the original iteration space into the scattering
space.
Let's see if I understand: So, we have [PI]-[aS] (Params, Iteration
domain, alias set, Subscript) as accesses, and we have [PI]-[T]
(Transformed) as the scattering. Indeed what I ideally wanted to have is
a [T]-[aS] mapping, but I couldn't see how to construct such. So you're
saying that I can apply the PI-T to the domain of PI-aS, and that gives
me the T-aS?
You start with a [P] - {[I] - [aS]} as accesses and a [P] - {[I] -
[T]}. To get [P] - {[T] - [aS]} you do the following:
isl_map *Accesses = [P] - {[I] - [aS]}
isl_map *Scattering = [P] - {[I] - [T]}
isl_map *TimeToAccess = isl_map_apply_domain(Accesses, Scattering)
isl_map_dump(TimeToAccess);
$ [P] { [T]-[aS] }
Probably I was confused by the functional syntax (the -),
as in normal functions you can't simply apply a function to a functions
domain and expect to get anything sensible out of that.
No, all those are relations. Reverse and combine them works in general
very well.
I see that in
your code you reverse the scattering first (T-PI), IIRC that's one thing
I also tried, but I got stuck somewhere.
I don't think reversing is necessary in your case. As the input space of
the scattering, which is [I], matches the domain of the access map. So
you can directly use isl_map_apply_domain.
I would than apply the isl_map calculated by
build_linearized_memory_access to map the array to the actual data
location accessed. Now you create a map 'scattering-scattering' that
maps from one scattering time point to the next. And apply the map
'scattering-memory' on both the range and the domain. You will end up
with a map memory - memory.
Yeah. If my above understanding is correct the path is clear.
I believe it is.
Here you can use the deltas function to give you the distances. ;-)
I couldn't figure out from isls user manual what exactly the delta
functions do :) From the description above I think I understand now. Let
me experiment a bit more.
The delta function calculates the following:
Input: {[a1, a2, a3] - [b1, b2, b3]: constraints between a and b }
Output {[x1, x2, x3] exists a1, a2, a3, b1, b2, b3 : x1 = b1 - a1 and x2
= b2 - a2 and x3 = b3 - a3 and constraints between a and b }
So basically it calculates the distances between each possible pair of
input and output values.
You can have a look in Polly, where I implement a similar calculation:
http://repo.or.cz/w/polly-mirror.git/blob/HEAD:/lib/Analysis/ScopInfo.cpp#l390
The games you play with projecting out some dimensions are related to
which dimension you want to calculate the stride, right? (As you always
calculate the next scatterting to have n+1 in the last dimension, not an
arbitrary one).
I always calculate the stride in the last dimension. This is less
general as what you are trying to calculate. The projecting out of
dimensions is just needed due to the ugly CLooG interface, which gives
me a mixture or scattering and domain dimensions. You should need it in gcc.
+print_isl_map (FILE *f, isl_map *map)
If this is the
case, you can either use isl_set_dump(set), isl_map_dump(map), ..
There functions weren't documented. Thanks. But I need a file argument
anyway as the plan is to use them also for debug dumps.
OK.
+ /* Even shorter and more correct method: map the iteration domain
+ through the current scatter, and work on the resulting set. */
+ isl_set_free (lbset);
+ lbset = isl_set_apply (isl_set_copy (pbb-domain),
+isl_map_copy (pbb-transformed));
+
Re: [graphite] RFC: Add ISL variants of remaining PPL things
On 07/02/2012 01:32 PM, Michael Matz wrote: +++ b/gcc/graphite.c @@ -253,6 +253,8 @@ graphite_finalize (bool need_cfg_cleanup_p) print_loops (dump_file, 3); } +isl_ctx *the_isl_ctx; Why are you creating a global ctx here? For the printer, before I was aware of the fact that of course all isl objects know about their context. Ah, I forgot. Can you commit a patch, that removes the_isl_ctx from graphite? Tobi
Re: Allow use of ranges in copyright notices
On Mon, Jul 2, 2012 at 10:17 AM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 2 Jul 2012, Robert Dewar wrote: On 7/2/2012 8:35 AM, Alexandre Oliva wrote: On Jun 30, 2012, David Edelsohn dje@gmail.com wrote: IBM's policy specifies a comma: first year, last year and not a dash range. But this notation already means something else in our source tree. I think using the dash is preferable, and is a VERY widely used notation, used by all major software companies I deal with! And as a GNU project there isn't a choice between using IBM convention and GNU convention - only about which of the GNU options we use. The simplest is first-year-2012 (for any value of first-year 1987 or later) and so I am proposing we move to that (make this change to README to allow it, allow converting files when 2012 is added to the copyright years, as is now done in glibc, allow a bulk conversion if anyone wishes to do one). Joseph, You are misunderstanding the point of my message. I mentioned the comma convention for worldwide legal precedence and acceptance, not because it is an IBM convention. There was a similar discussion many years ago. The dash format is widely used, but the comma format has better legal clarity and definition in worldwide copyright litigation, at least many years ago. - David
Re: Allow use of ranges in copyright notices
On Mon, 2 Jul 2012, David Edelsohn wrote: There was a similar discussion many years ago. The dash format is widely used, but the comma format has better legal clarity and definition in worldwide copyright litigation, at least many years ago. Maybe questions about the meanings of the dash format are why the GNU instructions require a statement in a README file about the use of that notation. -- Joseph S. Myers jos...@codesourcery.com
MAINTAINERS: add myself as testsuite maintainer
Mike Stump says he got word that I am reinstated as a testsuite maintainer so I added myself to the MAINTAINERS file (with, I now see, a typo in the ChangeLog). 2012-07-02 Janis Johnson jani...@codesourcery.com * MAINTAINERS (Various Mainterers): Add myself as testsuite maintainer. Index: MAINTAINERS === --- MAINTAINERS (revision 189165) +++ MAINTAINERS (revision 189166) @@ -249,6 +249,7 @@ loop infrastructure Zdenek Dvorak ook@u OpenMP Jakub Jelinek ja...@redhat.com testsuite Rainer Orth r...@cebitec.uni-bielefeld.de testsuite Mike Stump mikest...@comcast.net +testsuite Janis Johnson jani...@codesourcery.com register allocationVladimir Makarovvmaka...@redhat.com Note that individuals who maintain parts of the compiler need approval to
[PATCH 2/3] Incorporate aggregate jump functions into inlining analysis
Hi,
this patch uses the aggregate jump functions created by a previous
patch to determine benefits of inlining a particular call graph edge.
It does so by fairly straightforward way. It a flag to struct
condition to specify it is actually an aggregate value at an offset,
also newly stored in the structures. Functions which build the
predicates specifying under which conditions CFG edges will be taken
or individual statements are actually executed, then simply also look
whether a value comes from an aggregate passed to us in a parameter
(either by value or reference) and if so, create appropriate
conditions. Later on, predicates are evaluated as before, we only
also look at aggregate contents of the jump function of the edge we
are considering to inline when evaluating the predicates, and also
remap the offsets of the jump functions when remapping over an
ancestor jump function.
The patch passes bootstrap and testing on x86_64-linux. Also, this
patch alone makes us inline the function bar in testcase of PR 48636
in comment #4.
Thanks for all comments and suggestions,
Martin
2012-06-29 Martin Jambor mjam...@suse.cz
PR fortran/48636
* ipa-inline.h (condition): New fields offset and agg_contents.
* ipa-inline-analysis.c (add_condition): Also store agg_contents and
offset .
(dump_condition): Also dump aggregate conditions.
(evaluate_conditions_for_known_args): Also handle aggregate
conditions. New parameter known_aggs.
(evaluate_properties_for_edge): Gather known aggregate contents.
(inline_node_duplication_hook): Pass NULL known_aggs to
evaluate_conditions_for_known_args.
(unmodified_parm): Split into unmodified_parm and unmodified_parm_1.
(unmodified_parm_or_parm_agg_item): New function.
(set_cond_stmt_execution_predicate): Handle values passed in
aggregates.
(set_switch_stmt_execution_predicate): Likewise.
(will_be_nonconstant_predicate): Likewise.
(estimate_edge_devirt_benefit): Pass new parameter known_aggs to
ipa_get_indirect_edge_target.
(estimate_calls_size_and_time): New parameter known_aggs, pass it
recrsively to itself and to estimate_edge_devirt_benefit.
(estimate_node_size_and_time): New vector known_aggs, pass it o
functions which need it.
(remap_predicate): New parameter offset_map, use it to remap aggregate
conditions.
(remap_edge_summaries): New parameter offset_map, pass it recursively
to itself and to remap_predicate.
(inline_merge_summary): Also create and populate vector offset_map.
(do_estimate_edge_time): New vector of known aggregate contents,
passed to functions which need it.
(inline_read_section): Stream new fields of condition.
(inline_write_summary): Likewise.
* ipa-cp.c (ipa_get_indirect_edge_target): Also examine the aggregate
contents. Let all local callers pass NULL for known_aggs.
* testsuite/gfortran.dg/pr48636.f90: New test.
Index: src/gcc/ipa-inline.h
===
--- src.orig/gcc/ipa-inline.h
+++ src/gcc/ipa-inline.h
@@ -28,9 +28,11 @@ along with GCC; see the file COPYING3.
typedef struct GTY(()) condition
{
+HOST_WIDE_INT offset;
tree val;
int operand_num;
enum tree_code code;
+bool agg_contents;
} condition;
DEF_VEC_O (condition);
Index: src/gcc/ipa-inline-analysis.c
===
--- src.orig/gcc/ipa-inline-analysis.c
+++ src/gcc/ipa-inline-analysis.c
@@ -209,17 +209,21 @@ not_inlined_predicate (void)
static struct predicate
add_condition (struct inline_summary *summary, int operand_num,
+ bool agg_contents, HOST_WIDE_INT offset,
enum tree_code code, tree val)
{
int i;
struct condition *c;
struct condition new_cond;
+ gcc_checking_assert (operand_num = 0);
for (i = 0; VEC_iterate (condition, summary-conds, i, c); i++)
{
if (c-operand_num == operand_num
c-code == code
- c-val == val)
+ c-val == val
+ c-agg_contents == agg_contents
+ (!agg_contents || c-offset == offset))
return single_cond_predicate (i + predicate_first_dynamic_condition);
}
/* Too many conditions. Give up and return constant true. */
@@ -229,6 +233,8 @@ add_condition (struct inline_summary *su
new_cond.operand_num = operand_num;
new_cond.code = code;
new_cond.val = val;
+ new_cond.agg_contents = agg_contents;
+ new_cond.offset = offset;
VEC_safe_push (condition, gc, summary-conds, new_cond);
return single_cond_predicate (i + predicate_first_dynamic_condition);
}
@@ -520,6 +526,8 @@ dump_condition (FILE *f, conditions cond
c = VEC_index (condition, conditions,
cond - predicate_first_dynamic_condition);
Re: RFA: MEP: Fix use of delete_insn.
My concern is more about calling NEXT_INSN on a deleted insn. If
that's guaranteed to be reliable, I'm OK with it.
Alternately, call NEXT_INSN at the top of the loop, but save the value
until the *next* iteration of the loop, so we can delete the insn and
not have to call NEXT_INSN on it after being deleted.
next_insn = get_insns ();
while (next_insn)
{
insn = next_insn;
next_insn = NEXT_INSN (insn);
. . .
}
Of course, *that* assumes that we never delete more than just the one
insn we're processing. In that case, though, we could still just
update next_insn so the next loop gets the right one.
So pick whichever solution is more future-proof and go for it :-)
Re: [testsuite] don't use lto plugin if it doesn't work
On Jul 2, 2012, at 4:06 AM, Alexandre Oliva wrote: On Jun 29, 2012, Mike Stump mikest...@comcast.net wrote: First, let get to the heart of the matter. That is the behavior of compiler. That's a distraction in the context of a patch to improve a feature that's already present in the testsuite machinery, isn't it? Without having a compiler to test, there is little reason to have a testsuite. The behavior of the compiler is what drives the testsuite?! The testsuite doesn't exist to test other than the behavior of the compiler we would like to see. By defining the behavior of the compiler we'd like to see, we define exactly what we want to test. If we can't agree on the compiler, then by definition, we can't agree on the testsuite. So, first things first, we have to resolve the features in the compiler, so that we know in what direction we are traveling. If you disagree, you'd have to enlighten me what purpose the testsuite serves. I'm happy to listen. I have no objection to discussing this other topic you want to bring forth, but for reasons already stated and restated I don't think it precludes the proposed patch and the improvements to testsuite result reporting it brings about. If the testsuite can paper over configuration bits that are wrong, and re-adjust the compiler, but, the compiler can't, then you wind up with testsuite results that don't reflect the expected runtime behavior of the compiler. The testsuite tries to reproduce the environment that the compiler will see when the user uses it, so as to as faithfully as it can test the compiler, as the user will see it. It is an obligation for the user to provide the environment the compiler is to be used in to the compiler during build and test. Do you think it works perfectly and needs no changing in this area I think the compiler is working just fine. Ah, then I'd leave you and Jakub to sort out if the linker should use the plugin by default when the plugin just isn't going to work... I think he preferred to fix the compiler to not enable the plugin by default in this case. This why agreement on the behavior of the compiler is critical. It is told at build time whether or not to expect a linker with plugin support at run time, and behaves accordingly. Configure detects that based on linker version, which is in line with various other binutils feature tests we have in place, so I don't see that the test *needs* changing. Validating the the linker 64-bitness matches the plugin 64-bitness in addition to validating the version number. If it were to change in such a way that, in a “native cross” build scenario, it failed to detect plugin support that is actually available on the equivalent linker one would find on the configured host=target run time platform, I'd be inclined to regard that as a regression and a bug. If I understand what you just said, I disagree. The environment provided to configure, is the final environment, it is what is actually available, it is the one from which to make all decisions. If the user doesn't like that, then the user is free to more faithfully provide the environment. My take was, the compiler should not try and use the plugin that won't work, and that this should be a static config bit built up from the usual config time methods for the host system. Do you agree, if not why, and what is your take? I agree with that. Odd. So, does the compiler enable by default the plug-in when it can know that the plug-in isn't going to work? I thought the entire point was that the compiler was using the plug-in and that plug-in wasn't working? Indeed, it seems like a restatement of what I just wrote above, unless one thinks configure should assume the user lied in the given triplets. Because, really, we *are* lying to configure when we say we're building a i686-linux-gnu native natively when the build system is actually a x86_64-linux-gnu with some wrapper scripts that approximate i686-linux-gnu. If we tell configure we're building a compiler for an i686-linux-gnu system, configure should listen to us, rather than second-guess us. And if we fail to provide it with an environment that is sufficiently close to what we asked for, it's entirely our own fault, rather than configure's fault for not realizing we were cheating and compensating for our lies. Jakub said disable by default, and I'm just going along with that as a given. Since I agree with his position as well, I'd find it hard to argue against it. If you want other than that, you'd have find support for that position. gcc builds for the environment provided. Sorry if you don't agree with that. The reason why we do this is, gcc takes as gospel what you say. If you say you have a 64-bit linker, then, you have a 64-bit linker. If you say you have a 32-bit linker, then you have a 32-bit linker. When you say you have a 64-bit linker, it isn't going to assume that
C++/c-common PATCH for c++/53524 (bogus warning about enum mismatch in ?:)
While a C++ enumeration is being defined, the enumerators have the types
of their initializers, rather than the enumeration type itself. As a
result, if two enumerators are initialized from two other enumerations,
and then the two are used in a ?: to initialize a third, we end up with
mismatched enumeration types, leading to a warning. Since the actual
expression involves two elements of the same enumeration, we would like
to avoid the warning.
Accomplishing this involves some significant changes to the C++ front
end's handling of enumerators. First, we set their DECL_CONTEXT to the
enumeration type rather than the enclosing context, and then adjust
other code accordingly. Second, we keep the CONST_DECLs around until
decay_conversion time, which also requires some adjustment.
The c-common change is to deal with this; it seems appropriate to call
default_conversion on attribute arguments in/under the
handle_*_attribute function since only that function knows what it wants
to do with the arguments.
Tested x86_64-pc-linux-gnu, applying to trunk. This is a 4.7 regression
as well, but it's a minor issue and too large a change for a release branch.
commit 03858f56c3456cddfbce1fbc9ce31a022d9bb376
Author: Jason Merrill ja...@redhat.com
Date: Fri Jun 29 12:17:41 2012 -0400
PR c++/53524
gcc/cp/
* call.c (build_conditional_expr_1): Don't warn about comparison of
two enumerators before their enumeration is complete.
(build_new_op_1): Call decay_conversion before warn_logical_operator.
* decl.c (build_enumerator): Set DECL_CONTEXT of an enumerator to
its enumeration.
* decl2.c (mark_used): Call used_types_insert for enums.
* semantics.c (finish_id_expression): Don't decay CONST_DECL.
(finish_member_declaration): Don't change DECL_CONTEXT of enumerators.
* class.c (check_field_decls): Don't change DECL_CONTEXT of enums.
* typeck.c (convert_for_assignment): Don't decay CONST_DECL.
(build_class_member_access_expr): Look through unscoped enums.
* search.c (context_for_name_lookup): Look through unscoped enums.
* pt.c (tsubst_copy_and_build): Don't decay CONST_DECL.
(tsubst_copy): Use DECL_CONTEXT to find the enumeration.
* tree.c (decl_linkage): Likewise.
* cvt.c (ocp_convert): Check decayed expr for enum range warning.
gcc/c-family/
* c-common.c (get_priority): Call default_conversion.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 61d7567..2a528e2 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -6587,11 +6587,12 @@ get_priority (tree args, bool is_destructor)
}
arg = TREE_VALUE (args);
+ arg = default_conversion (arg);
if (!host_integerp (arg, /*pos=*/0)
|| !INTEGRAL_TYPE_P (TREE_TYPE (arg)))
goto invalid;
- pri = tree_low_cst (TREE_VALUE (args), /*pos=*/0);
+ pri = tree_low_cst (arg, /*pos=*/0);
if (pri 0 || pri MAX_INIT_PRIORITY)
goto invalid;
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 09965b3..72394f4 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4365,6 +4365,7 @@ build_conditional_expr_1 (tree arg1, tree arg2, tree arg3,
struct z_candidate *candidates = 0;
struct z_candidate *cand;
void *p;
+ tree orig_arg2, orig_arg3;
/* As a G++ extension, the second argument to the conditional can be
omitted. (So that `a ? : c' is roughly equivalent to `a ? a :
@@ -4404,6 +4405,8 @@ build_conditional_expr_1 (tree arg1, tree arg2, tree arg3,
array-to-pointer (_conv.array_), and function-to-pointer
(_conv.func_) standard conversions are performed on the second
and third operands. */
+ orig_arg2 = arg2;
+ orig_arg3 = arg3;
arg2_type = unlowered_expr_type (arg2);
arg3_type = unlowered_expr_type (arg3);
if (VOID_TYPE_P (arg2_type) || VOID_TYPE_P (arg3_type))
@@ -4701,7 +4704,12 @@ build_conditional_expr_1 (tree arg1, tree arg2, tree arg3,
if (TREE_CODE (arg2_type) == ENUMERAL_TYPE
TREE_CODE (arg3_type) == ENUMERAL_TYPE)
{
- if (complain tf_warning)
+ if (TREE_CODE (orig_arg2) == CONST_DECL
+ TREE_CODE (orig_arg3) == CONST_DECL
+ DECL_CONTEXT (orig_arg2) == DECL_CONTEXT (orig_arg3))
+ /* Two enumerators from the same enumeration can have different
+ types when the enumeration is still being defined. */;
+ else if (complain tf_warning)
warning (OPT_Wenum_compare,
enumeral mismatch in conditional expression: %qT vs %qT,
arg2_type, arg3_type);
@@ -5221,16 +5229,20 @@ build_new_op_1 (location_t loc, enum tree_code code, int flags, tree arg1,
if (arg2)
{
+ conv = cand-convs[1];
+ if (conv-kind == ck_ref_bind)
+ conv = next_conversion (conv);
+ else
+ arg2 = decay_conversion (arg2, complain);
+
/* We need to call warn_logical_operator before
- converting arg2 to a boolean_type. */
+ converting arg2 to
C++ PATCH for c++/53821 (multiply defined lambda member functions)
It seems that since my change to avoid push_to_top_level for
instantiating lambdas, the code in maybe_add_lambda_conv_op for handling
function context activates and does the wrong thing. I don't remember
why I added the code that sets DECL_INTERFACE_KNOWN, but it doesn't seem
to be needed.
This patch restores the old behavior for the testcase. While looking at
it I notice that the op() itself is incorrectly emitted as a local
function rather than COMDAT, but that will wait for another patch.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 45299163c2e02cde76e8b5bb8c2ecf11bda0b616
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 2 13:53:05 2012 -0400
PR c++/53821
* semantics.c (maybe_add_lambda_conv_op): Don't set
DECL_INTERFACE_KNOWN.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index f1a94c1..8e37ebb 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9336,8 +9336,6 @@ maybe_add_lambda_conv_op (tree type)
DECL_NOT_REALLY_EXTERN (fn) = 1;
DECL_DECLARED_INLINE_P (fn) = 1;
DECL_ARGUMENTS (fn) = build_this_parm (fntype, TYPE_QUAL_CONST);
- if (nested)
-DECL_INTERFACE_KNOWN (fn) = 1;
add_method (type, fn, NULL_TREE);
@@ -9368,8 +9366,6 @@ maybe_add_lambda_conv_op (tree type)
DECL_ARGUMENTS (fn) = copy_list (DECL_CHAIN (DECL_ARGUMENTS (callop)));
for (arg = DECL_ARGUMENTS (fn); arg; arg = DECL_CHAIN (arg))
DECL_CONTEXT (arg) = fn;
- if (nested)
-DECL_INTERFACE_KNOWN (fn) = 1;
add_method (type, fn, NULL_TREE);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template6.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template6.C
new file mode 100644
index 000..5e85619
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template6.C
@@ -0,0 +1,14 @@
+// PR c++/53821
+// { dg-final { scan-assembler-not _ZZ1fIvEvvENKUlvE_cvPFvvEEv } }
+// { dg-do compile { target c++11 } }
+
+template class T void f()
+{
+ auto g = []{};
+ g();
+}
+
+int main()
+{
+ fvoid();
+}
Re: [C++ RFC / Patch] PR 51213 (access control under SFINAE)
On 06/15/2012 10:27 AM, Paolo Carlini wrote: The problem is that with the patch applied we get errors of the no matching function type, instead of access control errors. I suppose this is expected, right?!? Yes, but when we're printing the candidates we need to give an access control error to explain why the candidate isn't viable. The second pair is more subtle: FAIL: g++.dg/template/friend13.C -std=c++11 (test for excess errors) FAIL: g++.dg/template/friend15.C -std=c++98 (test for excess errors) FAIL: g++.dg/template/friend15.C -std=c++11 (test for excess errors) friend13 seems well-formed to me. friend15 seems ill-formed since friends are no longer injected into the enclosing namespace, only found by argument-dependent lookup. I don't see anything offhand that would cause these changes. I'll look deeper. added to the template at parsing time. Let's get those and perfom the acces checks then. */ perform the access +enforce_access (tree basetype_path, tree decl, tree diag_decl, + bool complain) Let's use tsubst_flags_t for complain parms even if all we really need is a boolean value, to help with readability. Jason
[SH] PR 53568 - some bswap32 test cases
Hello,
The attached patch adds a few bswap32 test cases for SH.
Tested against rev 189175 with
make -k check RUNTESTFLAGS=sh.exp=pr53568-1.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}
to make sure that the test case passes.
Cheers,
Oleg
testsuite/ChangeLog:
PR target/53568
* gcc.target/sh/pr53568-1.c: New.
Index: gcc/testsuite/gcc.target/sh/pr53568-1.c
===
--- gcc/testsuite/gcc.target/sh/pr53568-1.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr53568-1.c (revision 0)
@@ -0,0 +1,82 @@
+/* Check that the bswap32 pattern is generated as swap.b and swap.w
+ instructions. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O2 } */
+/* { dg-skip-if { sh*-*-* } { -m5*} { } } */
+/* { dg-final { scan-assembler-times swap.w 7 } } */
+/* { dg-final { scan-assembler-times swap.b 16 } } */
+/* { dg-final { scan-assembler-times extu.w 2 } } */
+/* { dg-final { scan-assembler-times mov 1 } } */
+/* { dg-final { scan-assembler-not {shll8|shlr8|shld|shad} } } */
+
+int
+test_func_00 (int a)
+{
+ /* 1x swap.w
+ 2x swap.b */
+ return __builtin_bswap32 (a);
+}
+
+unsigned int
+test_func_01 (unsigned int a)
+{
+ /* 1x swap.w
+ 2x swap.b */
+ return __builtin_bswap32 (a);
+}
+
+int
+test_func_02 (int a)
+{
+ /* 1x swap.w
+ 2x swap.b */
+ return (((a 0) 0xFF) 24)
+ | (((a 8) 0xFF) 16)
+ | (((a 16) 0xFF) 8)
+ | (((a 24) 0xFF) 0);
+}
+
+unsigned int
+test_func_03 (unsigned int a)
+{
+ /* 1x swap.w
+ 2x swap.b */
+ return (((a 0) 0xFF) 24)
+ | (((a 8) 0xFF) 16)
+ | (((a 16) 0xFF) 8)
+ | (((a 24) 0xFF) 0);
+}
+
+int
+test_func_04 (int a)
+{
+ /* 1x swap.b
+ 1x extu.w */
+ return __builtin_bswap32 (a) 16;
+}
+
+unsigned short
+test_func_05 (unsigned short a)
+{
+ /* 1x swap.b
+ 1x extu.w */
+ return __builtin_bswap32 (a) 16;
+}
+
+long long
+test_func_06 (long long a)
+{
+ /* 2x swap.w
+ 4x swap.b */
+ return __builtin_bswap64 (a);
+}
+
+long long
+test_func_07 (long long a)
+{
+ /* 1x swap.w
+ 2x swap.b
+ 1x mov #0,Rn */
+ return __builtin_bswap64 (a) 32;
+}
+
Re: RFA: Speedup expand_used_vars by 30 times (PR38474)
On May 26, 2012, at 8:03 PM, Michael Matz wrote: --- PR middle-end/38474 * cfgexpand.c (struct stack_var): Add slot_type member. (add_stack_var): Initialize it. (add_alias_set_conflicts): Remove. (merge_stack_vars_p, more_specific_type): New functions. (nonconflicting_type): New static data. (union_stack_vars): Use more_specific_type to update slot_type. (partition_stack_vars): Call merge_stack_vars_p ... So this patch seems to have killed 'RUNTESTFLAGS=dg.exp=class_array_3.f03' check-fortran for me. Any insight? Unfortunately the bug I think manifests as generated code in the fortran runtime libraries, so I need to go track down the code. Also, git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@188667 seems to not match this patch, nor any other patch I can find, but it is the closest match.
[PATCH 3/3] Compute predicates for phi node results in ipa-inline-analysis.c
Hi,
this third patch is basically a proof-of-concept aiming at alleviating
the following code found in Fortran functions when they look at the
contents of array descriptors:
bb 2:
stride.156_7 = strain_tensor_6(D)-dim[0].stride;
if (stride.156_7 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
bb 4:
# stride.156_4 = PHI stride.156_7(3), 1(2)
and stride.156_4 is then used for other computations. Currently we
compute a predicate for SSA name stride.156_7 but the PHI node stops
us from having one for stride.156_4 and those computed from it.
This patch looks at phi nodes, and if its pairs of predecessors have
the same nearest common dominator, and the condition there is known to
be described by a predicate (computed either by
set_cond_stmt_execution_predicate or,
set_switch_stmt_execution_predicate, we depend on knowing how exactly
they behave), we use the parameter and offset from the predicate
condition and create one for the PHI node result, provided the
arguments of a phi node allow that, of course.
I hacked this together one evening a some timw ago and I expect to
talk with Honza about how we can perhaps access information abut edges
properly, nevertheless the patch passes bootstrap and testing on
x86_64.
On current trunk, I need to pass -finline-limit=204 to cut down
execution time of fatigue2 polyhedron benchmark from 155 seconds to 91
seconds. With the patch, I only need -finline-limit=166. So there's
still quite some way to go but something along these lines can be part
of it.
Thanks for all comments and suggestions,
Martin
2012-05-30 Martin Jambor mjam...@suse.cz
* ipa-inline-analysis.c (known_phi_condition_for_bb): New function.
(predicate_for_phi_result): Likewise.
(estimate_function_body_sizes): Use the above two functions.
(inline_analyze_function): Calculate and free dominance info.
Index: src/gcc/ipa-inline-analysis.c
===
--- src.orig/gcc/ipa-inline-analysis.c
+++ src/gcc/ipa-inline-analysis.c
@@ -1954,6 +1954,96 @@ param_change_prob (gimple stmt, int i)
return REG_BR_PROB_BASE;
}
+/* For basic block BB, find if all pairs of its predecesors have a common
+ dominator and if that dominator ends with a simple condition. If so, return
+ TRUE and stor pointer to *C. */
+
+static bool
+known_phi_condition_for_bb (struct inline_summary *info, basic_block bb,
+ struct condition **c)
+{
+ edge_iterator ei;
+ edge e;
+ basic_block computed_dom = NULL;
+ basic_block prev = NULL;
+
+ FOR_EACH_EDGE (e, ei, bb-preds)
+{
+ if (prev)
+ {
+ basic_block dom = nearest_common_dominator (CDI_DOMINATORS, prev,
+ e-src);
+ if (!computed_dom)
+ computed_dom = dom;
+ else if (dom != computed_dom)
+ return false;
+
+ }
+ prev = e-src;
+}
+
+ if (!computed_dom)
+return false;
+
+ FOR_EACH_EDGE (e, ei, computed_dom-succs)
+if (e-aux)
+ {
+ struct predicate *p;
+ int i;
+ p = (struct predicate *) e-aux;
+
+ if (p-clause[0] == 0 || p-clause[1] != 0)
+ return false;
+ for (i = 0 ; i NUM_CONDITIONS; i++)
+ if (((1 i) p-clause[0]) == p-clause[0])
+ break;
+ if (i == NUM_CONDITIONS || i predicate_first_dynamic_condition)
+ return false;
+
+ *c = VEC_index (condition, info-conds,
+ i - predicate_first_dynamic_condition);
+ return true;
+ }
+ return false;
+}
+
+/* Given a PHI statement STMT in a function described by inline properties INFO
+ and in a basic lock whose predecesors in CFG is selected according to a
+ parameter (and potentially offset) stored in condition *C, store a predicate
+ for the result of the PHI statement into NONCONSTANT_NAMES, if possible. */
+
+static void
+predicate_for_phi_result (struct inline_summary *info, gimple stmt,
+ struct condition *c,
+ VEC (predicate_t, heap) *nonconstant_names)
+{
+ struct predicate p;
+ unsigned i;
+
+ for (i = 0; i gimple_phi_num_args (stmt); i++)
+{
+ tree arg = gimple_phi_arg (stmt, i)-def;
+ if (!is_gimple_min_invariant (arg))
+ {
+ gcc_assert (TREE_CODE (arg) == SSA_NAME);
+ if (true_predicate_p (VEC_index (predicate_t, nonconstant_names,
+ SSA_NAME_VERSION (arg
+ return;
+ }
+}
+
+ p = add_condition (info, c-operand_num, c-agg_contents, c-offset,
+CHANGED, NULL);
+ if (dump_file (dump_flags TDF_DETAILS))
+{
+ fprintf (dump_file, );
+ print_gimple_stmt (dump_file, stmt, 0, 0);
+ fprintf (dump_file, \t\tphi predicate: );
+ dump_predicate (dump_file, info-conds, p);
+}
+ VEC_replace (predicate_t, nonconstant_names,
+
Re: [SH] PR 53568 - some bswap32 test cases
Oleg Endo oleg.e...@t-online.de wrote:
The attached patch adds a few bswap32 test cases for SH.
Tested against rev 189175 with
make -k check RUNTESTFLAGS=sh.exp=pr53568-1.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}
to make sure that the test case passes.
OK.
Regards,
kaz
[SH] Remove XFAIL from packed1.C test case
Hello,
The test case g++.dg/other/packed1.C does not fail on SH.
Is it OK to remove SH from the xfail list there?
Tested with
make -k check RUNTESTFLAGS=dg.exp=packed1.C --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}
to confirm that the test case passes.
Cheers,
Oleg
testsuite/ChangeLog:
* g++.dg/other/packed1.C: Remove SH from xfail list.
Index: gcc/testsuite/g++.dg/other/packed1.C
===
--- gcc/testsuite/g++.dg/other/packed1.C (revision 189180)
+++ gcc/testsuite/g++.dg/other/packed1.C (working copy)
@@ -1,4 +1,4 @@
-// { dg-do run { xfail sh-*-* lm32-*-* } }
+// { dg-do run { xfail lm32-*-* } }
// NMS:2003-04-21 this fails on strict aligned architectures again,
// the patch was reverted because it broke something more important.
Re: New option to turn off stack reuse for temporaries
I extended the patch a little so that the option can be used to set
multiple stack reuse levels: -fstack-reuse=[all|name_vars|none]
all: enable stack reuse for all local vars (named vars and compiler
generated temporaries) which live in memory;
name_vars: enable stack reuse only for user declared local vars with names;
none: disable stack reuse completely.
Note the patch still chooses to suppress clobber statement generation
instead of just ignoring them in stack layout. This has the additional
advantage of allowing more aggressive code motion when stack use is
disabled.
The documentation will be updated when the patch is agreed upon.
thanks,
David
On Thu, Jun 28, 2012 at 10:43 PM, Xinliang David Li davi...@google.com wrote:
(re-post in plain text)
Moving this to cfgexpand time is simple and it can also be extended to
handle scoped variables. However Jakub raised a good point about this
being too late as stack space overlay is not the only way to cause
trouble when the lifetime of a stack object is extended beyond the
clobber stmt.
thanks,
David
On Tue, Jun 26, 2012 at 1:28 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li davi...@google.com
wrote:
Are there any more concerns about this patch? If not, I'd like to check it
in.
No - the fact that the flag is C++ specific but in common.opt is odd enough
and -ftemp-reuse-stack sounds very very generic - which in fact it is not,
it's a no-op in C. Is there a more formal phrase for the temporary kind that
is affected? For me temp is synonymous to auto so I'd have expected
the switch to turn off stack slot sharing for
{
int a[5];
}
{
int a[5];
}
but that is not what it does. So - a little kludgy but probably more to what
I'd like it to be would be to move the option to c-family/c.opt enabled only
for C++ and Obj-C++ and export it to the middle-end via a new langhook
(the gimplifier code should be in Frontend code that lowers to GENERIC
really and the WITH_CLEANUP_EXPR code should be C++ frontend specific ...).
Thanks,
Richard.
thanks,
David
On Fri, Jun 22, 2012 at 8:51 AM, Xinliang David Li davi...@google.com
wrote:
On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill ja...@redhat.com wrote:
On 06/22/2012 01:30 AM, Richard Guenther wrote:
What other issues? It enables more potential code motion, but on the
other hand, causes more conservative stack reuse. As far I can tell,
the handling of temporaries is added independently after the clobber
for scoped variables are introduced. This option can be used to
restore the older behavior (in handling temps).
Well, it does not really restore the old behavior (if you mean before
adding
CLOBBERS, not before the single patch that might have used those for
gimplifying WITH_CLEANUP_EXPR). You say it disables stack-slot sharing
for those decls but it also does other things via side-effects of no
longer
emitting the CLOBBER. I say it's better to disable the stack-slot
sharing.
The patch exactly restores the behavior of temporaries from before my
change
to add CLOBBERs for temporaries. The primary effect of that change was
to
provide stack-slot sharing, but if there are other effects they are
probably
desirable as well, since the broken code depended on the old behavior.
So you see it as workaround option, like -fno-strict-aliasing, rather than
debugging aid?
It can be used for both purposes -- if the violations are as pervasive
as strict-aliasing cases (which looks like so).
thanks,
David
Richard.
Jason
reuse-stack.p
Description: Binary data
Re: [SH] Remove XFAIL from packed1.C test case
Oleg Endo oleg.e...@t-online.de wrote: The test case g++.dg/other/packed1.C does not fail on SH. Is it OK to remove SH from the xfail list there? OK. Regards, kaz
C++ PATCH for c++/53816 (ICE with local reference in template)
resolves_to_fixed_type_p has caused a lot of ICEs in templates over the
years because it wants to look inside the DECL_INITIAL of variables with
non-constant initializers which are still in pre-tsubst form. Checking
processing_template_decl to prevent this isn't strong enough, because
fold_non_dependent_expr clears processing_template_decl in order to do
its tsubst folding. But instead we can test whether the current
function is not completely instantiated.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7 (more conservative
version).
commit 6eaedcae2947349c61f4129f0112a2d510949c46
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 2 16:44:12 2012 -0400
PR c++/53816
* class.c (resolves_to_fixed_type_p): Check uses_template_parms
(current_function_decl) instead of processing_template_decl.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 264258c..e70e674 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -6521,7 +6521,10 @@ resolves_to_fixed_type_p (tree instance, int* nonnull)
int cdtorp = 0;
tree fixed;
- if (processing_template_decl)
+ /* processing_template_decl can be false in a template if we're in
+ fold_non_dependent_expr, but we still want to suppress this check. */
+ if (current_function_decl
+ uses_template_parms (current_function_decl))
{
/* In a template we only care about the type of the result. */
if (nonnull)
diff --git a/gcc/testsuite/g++.dg/template/ref6.C b/gcc/testsuite/g++.dg/template/ref6.C
new file mode 100644
index 000..2e1254a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ref6.C
@@ -0,0 +1,15 @@
+// PR c++/53816
+
+template typename T
+struct S { int v () const; };
+template typename T
+struct V : public ST {};
+struct U
+{
+ Vint v;
+ templatetypename T
+ struct W
+ {
+W (U const x) { Vint const v = x.v; v.v(); }
+ };
+};
commit a4d190b1380fe956f7758994e7de27366dbcc0bb
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 2 16:44:12 2012 -0400
PR c++/53816
* class.c (resolves_to_fixed_type_p): Check uses_template_parms
(current_function_decl) instead of processing_template_decl.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 503a01e..633bff3 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -6479,7 +6479,11 @@ resolves_to_fixed_type_p (tree instance, int* nonnull)
int cdtorp = 0;
tree fixed;
- if (processing_template_decl)
+ /* processing_template_decl can be false in a template if we're in
+ fold_non_dependent_expr, but we still want to suppress this check. */
+ if (processing_template_decl
+ || (current_function_decl
+ uses_template_parms (current_function_decl)))
{
/* In a template we only care about the type of the result. */
if (nonnull)
diff --git a/gcc/testsuite/g++.dg/template/ref6.C b/gcc/testsuite/g++.dg/template/ref6.C
new file mode 100644
index 000..2e1254a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ref6.C
@@ -0,0 +1,15 @@
+// PR c++/53816
+
+template typename T
+struct S { int v () const; };
+template typename T
+struct V : public ST {};
+struct U
+{
+ Vint v;
+ templatetypename T
+ struct W
+ {
+W (U const x) { Vint const v = x.v; v.v(); }
+ };
+};
C++ PATCH for c++/53788 (accepts-invalid with call to method in decltype)
The diagnostic for calling a non-static member function without an
associated object depends on the form of the dummy object built by
build_dummy_object. If we wrap it in a NON_DEPENDENT_EXPR, then
is_dummy_object doesn't recognize it any more. So don't wrap it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 66f75d714661171ff026b8ccf3d99ce9a4d536e2
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 2 17:06:33 2012 -0400
PR c++/53788
* pt.c (build_non_dependent_expr): Don't wrap a dummy object.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f8f416a..563a1ad 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20215,6 +20215,10 @@ build_non_dependent_expr (tree expr)
if (BRACE_ENCLOSED_INITIALIZER_P (expr))
return expr;
+ /* Don't wrap a dummy object, we need to be able to test for it. */
+ if (is_dummy_object (expr))
+return expr;
+
if (TREE_CODE (expr) == COND_EXPR)
return build3 (COND_EXPR,
TREE_TYPE (expr),
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype39.C b/gcc/testsuite/g++.dg/cpp0x/decltype39.C
new file mode 100644
index 000..4676d2d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype39.C
@@ -0,0 +1,19 @@
+// PR c++/53788
+// { dg-do compile { target c++11 } }
+
+struct t { static const bool value = true; };
+struct f { static const bool value = false; };
+
+templatetypename T
+struct has_static {
+ templatetypename X
+ static t check(X*, decltype(T::fun())* = 0); // { dg-error without object }
+ static f check(...);
+
+ typedef decltype(check((T*)(0))) ret;
+ static const bool value = ret::value;
+};
+
+struct test { int fun() { return 0; } };
+
+bool b = has_statictest::value;
diff --git a/gcc/testsuite/g++.dg/diagnostic/method1.C b/gcc/testsuite/g++.dg/diagnostic/method1.C
index 4a78104..0e7c580 100644
--- a/gcc/testsuite/g++.dg/diagnostic/method1.C
+++ b/gcc/testsuite/g++.dg/diagnostic/method1.C
@@ -10,7 +10,7 @@ template class T
void
bar ()
{
- A::foo ().anything; // { dg-error request for member }
+ A::foo ().anything; // { dg-error without object }
}
void
@@ -18,5 +18,3 @@ baz ()
{
bar int ();
}
-
-// { dg-prune-output without object }
[PATCH, 4.6] Unsupported c++-11 selector in nullptr28.C
This patch fixes a selector fault in the new g++.dg/cpp0x/nullptr28.C test
by changing the c++-11 target selector to the equivalent options. The
test itself was backported from trunk in r188953 to fix PR52988.
Tested on x86_64-linux. The ERROR changes to a PASS.
OK for 4.6?
-- Michael
gcc/testsuite/
2012-07-03 Michael Hope michael.h...@linaro.org
PR c++/53814
* g++.dg/cpp0x/nullptr28.C: Change selector for explicit
options.
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
index 05fbe57..4cc790d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
@@ -1,4 +1,5 @@
-// { dg-do run { target c++11 } }
+// { dg-do run }
+// { dg-options -std=c++0x -pedantic-errors }
typedef decltype(nullptr) nullptr_t;
Re: [PATCH, 4.6] Unsupported c++-11 selector in nullptr28.C
On Tue, Jul 03, 2012 at 04:09:18PM +1200, Michael Hope wrote:
This patch fixes a selector fault in the new g++.dg/cpp0x/nullptr28.C test
by changing the c++-11 target selector to the equivalent options. The
test itself was backported from trunk in r188953 to fix PR52988.
Tested on x86_64-linux. The ERROR changes to a PASS.
OK for 4.6?
Okay.
2012-07-03 Michael Hope michael.h...@linaro.org
PR c++/53814
* g++.dg/cpp0x/nullptr28.C: Change selector for explicit
options.
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
index 05fbe57..4cc790d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
@@ -1,4 +1,5 @@
-// { dg-do run { target c++11 } }
+// { dg-do run }
+// { dg-options -std=c++0x -pedantic-errors }
typedef decltype(nullptr) nullptr_t;
Jakub
C++ PATCH for c++/53619 (wrong base conversion in lambda)
My change in 4.8 to use 'auto' for the return type of a lambda caused
uses_template_parms (current_function_decl) to return true, causing us
to skip the real adjustment to the base address. Fixed by looking at
DECL_TI_ARGS instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7b3981302f5c25d7e800adc884690850585cb756
Author: Jason Merrill ja...@redhat.com
Date: Tue Jul 3 00:00:40 2012 -0400
PR c++/53619
* pt.c (in_template_function): New.
* cp-tree.h: Declare it.
* class.c (build_base_path, resolves_to_fixed_type_p): Use it.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index e70e674..0d4a40d 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -325,8 +325,7 @@ build_base_path (enum tree_code code,
up properly yet, and the value doesn't matter there either; we're just
interested in the result of overload resolution. */
if (cp_unevaluated_operand != 0
- || (current_function_decl
- uses_template_parms (current_function_decl)))
+ || in_template_function ())
{
expr = build_nop (ptr_target_type, expr);
if (!want_pointer)
@@ -6523,8 +6522,7 @@ resolves_to_fixed_type_p (tree instance, int* nonnull)
/* processing_template_decl can be false in a template if we're in
fold_non_dependent_expr, but we still want to suppress this check. */
- if (current_function_decl
- uses_template_parms (current_function_decl))
+ if (in_template_function ())
{
/* In a template we only care about the type of the result. */
if (nonnull)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a4b7ae3..41ca83c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5330,6 +5330,7 @@ extern tree lookup_template_class (tree, tree, tree, tree,
extern tree lookup_template_function (tree, tree);
extern int uses_template_parms (tree);
extern int uses_template_parms_level (tree, int);
+extern bool in_template_function (void);
extern tree instantiate_class_template (tree);
extern tree instantiate_template (tree, tree, tsubst_flags_t);
extern int fn_type_unification (tree, tree, tree,
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d385ea7..f618fa5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8027,6 +8027,23 @@ uses_template_parms (tree t)
return dependent_p;
}
+/* Returns true iff current_function_decl is an incompletely instantiated
+ template. Useful instead of processing_template_decl because the latter
+ is set to 0 during fold_non_dependent_expr. */
+
+bool
+in_template_function (void)
+{
+ tree fn = current_function_decl;
+ bool ret;
+ ++processing_template_decl;
+ ret = (fn DECL_LANG_SPECIFIC (fn)
+ DECL_TEMPLATE_INFO (fn)
+ any_dependent_template_arguments_p (DECL_TI_ARGS (fn)));
+ --processing_template_decl;
+ return ret;
+}
+
/* Returns true if T depends on any template parameter with level LEVEL. */
int
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this5.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this5.C
new file mode 100644
index 000..8974641
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this5.C
@@ -0,0 +1,22 @@
+// PR c++/53619
+// { dg-do run { target c++11 } }
+
+struct C {
+ int x;
+};
+struct B {
+ int q;
+};
+struct A : public B , C {
+ void foo();
+};
+
+void A::foo() {
+ auto k = [this]() {return (void *)(x);};
+ if (k() != (void*)x)
+__builtin_abort();
+}
+
+int main(int l, char **) {
+ A a; a.foo();
+}
C++ PATCH for c++/53783 (wrong error on nested lambda)
A nested lambda in a template was complaining about use of an 'auto'
function before its return type was deduced; this was because we were
using tsubst_copy to instantiate LAMBDA_EXPR_EXTRA_SCOPE, i.e. treating
it as an expression, which results in calling mark_used. Fixed by using
tsubst instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 35f50b80cc3aad10bb7ce825ff37df57d4d46450
Author: Jason Merrill ja...@redhat.com
Date: Mon Jul 2 23:42:41 2012 -0400
PR c++/53783
* pt.c (tsubst_copy_and_build) [LAMBDA_EXPR]: Use tsubst
for LAMBDA_EXPR_EXTRA_SCOPE.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 563a1ad..d385ea7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14401,7 +14401,7 @@ tsubst_copy_and_build (tree t,
LAMBDA_EXPR_DISCRIMINATOR (r)
= (LAMBDA_EXPR_DISCRIMINATOR (t));
LAMBDA_EXPR_EXTRA_SCOPE (r)
- = RECUR (LAMBDA_EXPR_EXTRA_SCOPE (t));
+ = tsubst (LAMBDA_EXPR_EXTRA_SCOPE (t), args, complain, in_decl);
LAMBDA_EXPR_RETURN_TYPE (r)
= tsubst (LAMBDA_EXPR_RETURN_TYPE (t), args, complain, in_decl);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template7.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template7.C
new file mode 100644
index 000..5b098d0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template7.C
@@ -0,0 +1,5 @@
+// PR c++/53783
+// { dg-do compile { target c++11 } }
+
+template class T void foo() { [] { [] {}; }; }
+int main() { foovoid(); }
