headers
Jack Howarth | 1 Aug 2009 01:26
Picon

Re: Merging Graphite to trunk

Sebastian,
   Perhaps I missed a discussion of this problem in the thread here, but I
am finding that the current gcc trunk (r150319) compiled against cloog-ppl
0.15.4 on x86_64-apple-darwin10 no longer tolerates -floop-block when
compiling the Polyhedron 2005 benchmarks...

gfortran -ffast-math -funroll-loops -msse3 -O3 -fgraphite-identity -floop-block test_fpu.f90 -o test_fpu
test_fpu.f90: In function ‘test_fpu’:
test_fpu.f90:11:0: sorry, unimplemented: loop blocking not implemented
test_fpu.f90: In function ‘main’:
test_fpu.f90:12:0: sorry, unimplemented: loop blocking not implemented
test_fpu.f90: In function ‘gauss’:
test_fpu.f90:89:0: sorry, unimplemented: loop blocking not implemented
test_fpu.f90:89:0: internal compiler error: in apply_poly_transforms, at graphite-poly.c:255
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

FYI.
         Jack
Permalink | Reply | 1 comment |
headers
Richard Henderson | 1 Aug 2009 01:32
Picon
Favicon

Re: VTA RTL patch review?

On 07/23/2009 12:56 PM, Alexandre Oliva wrote:
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00256.html

Reviewing only vta-patchset-rtl-sched.patch in this message.

> -  val = (sd_lists_size (tmp2, SD_LIST_FORW)
> -        - sd_lists_size (tmp, SD_LIST_FORW));
> +  if (has_debug)
> +    val = (nondebug_dep_list_size (tmp2)
> +          - nondebug_dep_list_size (tmp));
> +  else
> +    val = (sd_lists_size (tmp2, SD_LIST_FORW)
> +          - sd_lists_size (tmp, SD_LIST_FORW));

Since nondebug_dep_list_size includes the has_debug test, don't 
over-complicate the code by replicating that here.  Which also suggests 
that the has_debug local variable in rank_for_schedule should also be 
removed in favour of MAY_HAVE_DEBUG_INSNS.

> +# define SCHED_DEBUG_INSNS_BEFORE_REORDER 1

What's this?  Is there any reason why we'd want this false?

> +/* Convenience predicates.  */
> +#define SCHEDULE_DEBUG_INSN_P(insn) \
> +  (DEBUG_INSN_P (insn) && DEBUG_INSN_SCHED_P (insn))
> +#define BOUNDARY_DEBUG_INSN_P(insn) \
> +  (DEBUG_INSN_P (insn) && !DEBUG_INSN_SCHED_P (insn))

Some expanded commentary would be very helpful here.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Adam Nemet | 1 Aug 2009 02:22

Re: [PATCH 3/4, MIPS] Move clear_upper32* patterns to the and patterns

Richard Henderson writes:
> How about merging all the patterns?  E.g.

I tried working out the details, this is where it stands.  It passes
ext-[4567].c tests from the MIPS testsuite but I haven't done any further
testing.

I still need to think about if we want the operands to be commutative.  Also
why did you use !register_operand rather than memory_operand in and_ext_ok?
(I didn't use B for the constraints because that is a valid prefix.)

Adam

Index: gcc/config/mips/predicates.md
===================================================================
--- gcc.orig/config/mips/predicates.md	2009-07-31 16:56:46.000000000 -0700
+++ gcc/config/mips/predicates.md	2009-07-31 17:14:41.000000000 -0700
 <at>  <at>  -76,6 +76,16  <at>  <at>  (define_predicate "const_0_or_1_operand"
        (ior (match_test "op == CONST0_RTX (GET_MODE (op))")
 	    (match_test "op == CONST1_RTX (GET_MODE (op))"))))

+;; Match the constant low-order bitmask operand in AND that should be
+;; implemented with <d>ext.
+(define_predicate "low_bitmask_operand"
+  (and (match_code "const_int")
+       (match_test "low_bitmask_len (mode, INTVAL (op)) > 16")))
+
+(define_predicate "and_ext_operand"
+  (ior (match_operand 0 "uns_arith_operand")
+       (match_operand 0 "low_bitmask_operand")))
(Continue reading)

Permalink | Reply | 14 comments |
headers
Jason Merrill | 1 Aug 2009 04:25
Picon
Favicon

C++/v3 PATCHes for change in rvalue reference semantics

At the spring C++ meeting, the committee adopted a change (from paper 
N2831) to rvalue reference semantics such that lvalues will no longer 
bind to rvalue references; if you want to pass an lvalue to an rvalue 
reference argument, you need to use std::forward, std::move, or a 
static_cast to rvalue reference type.  This is a safety measure, as with 
the old semantics code that worked properly under C++98 could silently 
start moving data out of your objects in C++0x.

Listing the patches in reverse order of application:

The first patch actually implements that change, as well as the changes 
to forward and move that it requires, and the new rvalue stream 
inserter/extractor also from N2831.

The second patch adds some library uses of move/forward that are now 
necessary, but are correct under the old rules as well, just not necessary.

The third patch fixes direct binding of rvalue references to rvalue 
reference-derived "rvalues", both in implicit conversion and 
static_cast.  This too is correct under the old rules, but wasn't as 
necessary because it used to be handled by the lvalue conversion code.

The last patch isn't necessary for this semantic change, just something 
that's been nagging at me for a while, so I tried fixing it -- many 
places in the compiler use build_address to take the address of 
something while avoiding the errors that cp_build_unary_op gives.  But 
for some reason the comment before build_address said that it did no 
folding at all.  I tried making it fold away &*, and that worked fine. 
Similarly, using TYPE_MAIN_VARIANT to get a cv-unqualified type to use 
on an expression is wrong; we should only do that for type comparison.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kaveh R. GHAZI | 1 Aug 2009 05:05
Picon
Favicon

Re: [RFC PATCH, i386]: Some cleanups involving fprintfs through the source

On Thu, 23 Jul 2009, Joseph S. Myers wrote:

> On Thu, 23 Jul 2009, Uros Bizjak wrote:
>
> > Any comments on this approach?
>
> In the cases where you aren't modifying a format string - where fprintf
> was called with a format not containing '%', for example - GCC should
> already carry out your transformations automatically.  (Transformations
> involving modifying format strings have been discussed in the past, but I
> don't think they have been implemented and they could increase the amount
> of space used by strings in the program so may not unconditionally be a
> good idea for GCC to do automatically.)
>
> This does not mean there is anything wrong with your patch, just that
> parts of it should have no actual effect on the compiler.

I think these changes will have an effect in that the modifications that
Uros is making will enable more use of the unlocked forms of the stdio
calls.  The issue is that there is no fprintf_unlocked, support for it in
system.h notwithstanding.  See:
http://gcc.gnu.org/ml/gcc/2005-08/msg00413.html

Transformations that GCC does on stdio functions will preserve their
"lock"-ness.  Since system.h converts all stdio into the unlocked forms
*if they exist* then the e.g. fputs form will use fputs_unlocked.
Whereas if it started out as a fprintf that got simplified it will use the
locked form of fputs.

The other effect is for changing fputc into putc, in that case the macro
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Pop | 1 Aug 2009 06:50
Picon
Gravatar

Re: Merging Graphite to trunk

On Fri, Jul 31, 2009 at 18:26, Jack Howarth<howarth <at> bromo.med.uc.edu> wrote:
> Sebastian,
>   Perhaps I missed a discussion of this problem in the thread here, but I
> am finding that the current gcc trunk (r150319) compiled against cloog-ppl
> 0.15.4 on x86_64-apple-darwin10 no longer tolerates -floop-block when
> compiling the Polyhedron 2005 benchmarks...
>
> gfortran -ffast-math -funroll-loops -msse3 -O3 -fgraphite-identity -floop-block test_fpu.f90 -o test_fpu
> test_fpu.f90: In function ‘test_fpu’:
> test_fpu.f90:11:0: sorry, unimplemented: loop blocking not implemented

Yes, -floop-block does not work yet, see:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01722.html
we will test the composition of strip-mine and interchange and then enable it.
Until then I would suggest you try -floop-interchange -floop-strip-mine that
should produce the loop blocking.  Note that only -floop-strip-mine was enabled
by default in -O2 in the graphite branch and was tested enough.  I also am
aware of bugs in -floop-strip-mine and in -floop-interchange, but if you find
some problems that ICE or miscompile, please open bug reports and assign
them to spop <at> gcc.gnu.org, I will take care of them.

Thanks for testing Graphite,
Sebastian
Permalink | Reply | 0 comments |
headers
Dave Korn | 1 Aug 2009 08:50

Re: Merging Graphite to trunk

Jack Howarth wrote:
> On Thu, Jul 30, 2009 at 11:58:55PM -0500, Sebastian Pop wrote:
>> On Thu, Jul 30, 2009 at 22:59, Jack Howarth<howarth <at> bromo.med.uc.edu> wrote:
>>> Sebastian,
>>>   On x86_64-apple-darwin10, gcc trunk is failing to bootstrap
>>> at r150304 with the failure...
>> [...]
>>> /sw/include/cloog/ppl_backend.h:178:6: error: using 'polyhedron' as both a typedef and a tag is
invalid in C++
>> This has been fixed by Ian in CLooG-PPL.  The minimal version required
>> to bootstrap GCC4.5 is CLooG-PPL-0.15.4.  Please update to
>> ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.4.tar.gz
>>
>> Sebastian
> 
> Sebastian,
>    Shouldn't configure be patched to test for cloog >= 0.15.4 in gcc trunk?
>                     Jack

  Shouldn't some kind of announcement be made?

    cheers,
      DaveK
Permalink | Reply | 0 comments |
headers
Paolo Bonzini | 1 Aug 2009 13:39
Picon
Gravatar

Re: [PATCH] gimplify-unit-at-a-time (final)

On 07/07/2009 05:30 PM, Richard Guenther wrote:
> +     "diagnose_omp_blocks",		/* name */

I think this should be "*diagnose_omp_blocks".

 > +     "warn_unused_result",		/* name */

Same.

 > +   /* This must also call cgraph_finalize_compilation_unit and
 > +      cgraph_optimize.  */

I don't think so, since cgraph_optimize is static. :-)  (It should call 
c_f_c_u only).

Thanks!

Paolo
Permalink | Reply | 1 comment |
headers
Richard Guenther | 1 Aug 2009 15:06
Picon

Re: Merging Graphite to trunk

On Fri, 31 Jul 2009, Sebastian Pop wrote:

> On Fri, Jul 31, 2009 at 07:56, Jack Howarth<howarth <at> bromo.med.uc.edu> wrote:
> > On Thu, Jul 30, 2009 at 11:58:55PM -0500, Sebastian Pop wrote:
> >> On Thu, Jul 30, 2009 at 22:59, Jack Howarth<howarth <at> bromo.med.uc.edu> wrote:
> >> > Sebastian,
> >> >   On x86_64-apple-darwin10, gcc trunk is failing to bootstrap
> >> > at r150304 with the failure...
> >> [...]
> >> > /sw/include/cloog/ppl_backend.h:178:6: error: using 'polyhedron' as both a typedef and a tag is
invalid in C++
> >>
> >> This has been fixed by Ian in CLooG-PPL.  The minimal version required
> >> to bootstrap GCC4.5 is CLooG-PPL-0.15.4.  Please update to
> >> ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.4.tar.gz
> >>
> >> Sebastian
> >
> > Sebastian,
> >   Shouldn't configure be patched to test for cloog >= 0.15.4 in gcc trunk?
> 
> Yes, this is correct, we should test for the revision number as well.
> Here is the patch, but that would necessitate a new CLooG-PPL revision.

It seems to work fine for me with the old version, so please do not
lock us out.

Thx.
Richard.
Permalink | Reply | 0 comments |
headers
Richard Guenther | 1 Aug 2009 15:06
Picon

Re: Merging Graphite to trunk

On Fri, 31 Jul 2009, Sebastian Pop wrote:

> On Fri, Jul 31, 2009 at 12:41, Richard Guenther<rguenther <at> suse.de> wrote:
> >> What about renaming -fgraphite-force-parallel into -floop-parallelize-all?
> >> We could have -floop-parallelize for the version with cost model.
> >> These would be consistent with the flag names of the other loop transforms
> >> exposed from Graphite.
> >
> > Certainly better than -fgraphite-force-parallel.
> 
> Done like this.  Okay for trunk after regstrap?

Yes.  Thanks,
Richard.
Permalink | Reply | 0 comments |

Gmane