headers
Diego Novillo | 1 Jul 2011 01:33
Picon
Favicon

Re: [pph] Stream first/weak_object_global_name (issue4641086)

On Thu, Jun 30, 2011 at 16:24, Gabriel Charette <gchare <at> google.com> wrote:
> first/weak_global_object_name are part of the global state.
>
> This seems to be used to produce the assembler names. They are set only once as early as possible in the
parsing; thus we should define it to be whatever it was in the first pph (or even in the C file if it was set
before any pph was even loaded.
>
> I'm not sure exactly what this does, but trying to find a fix for the asm diffs this is the first thing that I
hit in the compiler logic that was different in the good compiler vs the pph compiler. With this fix this bit
of logic is now correct.
> However, this doesn't fix any pph test (nor does it even change any pph asm (I diff'ed the old bad assemblies
(*.s+pph) with the new ones)).

This does not look right to me.  These two symbols are set when
calling notice_global_symbol, which is done during code generation
(you will see it called from cgraph_finalize_function,
cgraph_mark_reachable_node, etc).

You are probably close to the cause of this relative ordering problem,
but streaming these two globals is not the solution.  They both should
be set in the same order by both compilers, but not by forcing them
this way.

One thing that may be happening here is that the order in which we
call cgraph_finalize_function is different in the two compilers.
That's what needs to change.  One thing you could do is set a
breakpoint in notice_global_symbol.  The two compilers should be
calling it in the same order.

Diego.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Merrill | 1 Jul 2011 01:57
Picon
Favicon

C++ PATCH for c++/49569 (ICE with implicitly-declared copy constructor)

If we aren't setting DECL_ARTIFICIAL on the rhs parm of an 
implicitly-declared copy constructor, we need to set DECL_PARM_INDEX for 
the sake of the constexpr expander.

Tested x86_64-pc-linux-gnu, applying to trunk.
Attachment (49569.patch): text/x-patch, 1506 bytes
Permalink | Reply | 0 comments |
headers
Jason Merrill | 1 Jul 2011 01:59
Picon
Favicon

C++ PATCH for c++/49355 (ICE with new T({""}))

The problem here was that stabilize_init called from build_new_1 wasn't 
doing anything to stabilize the elements of a CONSTRUCTOR, so the 
allocator argument wasn't preevaluated, and due to the cleanup for the 
data pointer its cleanup wasn't associated with the CLEANUP_POINT_EXPR, 
leading to a crash.

Tested x86_64-pc-linux-gnu, applying to trunk.
Attachment (49355.patch): text/x-patch, 1406 bytes
Permalink | Reply | 0 comments |
headers
Jason Merrill | 1 Jul 2011 02:01
Picon
Favicon

Re: [PATCH,c++] mark EXPR_PACK_EXPANSION as typed only, v2

On 05/09/2011 07:41 PM, Nathan Froyd wrote:
> I present the patch below.  We have a new function,
> cp_tree_operand_length, and the code has been retrofitted to use it in
> various places.

I've changed iterative_hash_template_arg to use it as well.

Tested x86_64-pc-linux-gnu, applying to trunk.
Attachment (hash-op-length.patch): text/x-patch, 649 bytes
Permalink | Reply | 0 comments |
headers
Jason Merrill | 1 Jul 2011 02:53
Picon
Favicon

C++ PATCH for c++/49387 (strange error with typeid)

Here we were winding up in get_tinfo_decl with a template type that was 
still incomplete because nothing else had required it to be complete. 
So we initially decide to treat it as a class with no bases.  But then 
the process of creating the initializer for the type_info node causes 
the type to be complete, so we generate an initializer for a class with 
bases, which doesn't match the type we already gave it.

Fixed by instantiating the type in get_tinfo_decl.

Tested x86_64-pc-linux-gnu, applying to trunk.
Attachment (49387.patch): text/x-patch, 1196 bytes
Permalink | Reply | 0 comments |
headers
Gabriel Charette | 1 Jul 2011 03:27
Picon
Favicon

Re: [pph] Stream first/weak_object_global_name (issue4641086)

notice_global_symbol is actually called in the parser (before we stream out).

I just confirmed this by setting a break point on the function in the
pph generation of c1varoder.pph and hitting the function twice for the
two variables defined in c1varorder.h

It looks like rtl and assembler_name are set BEFORE we stream out...
so that we would need to stream them (looks like assembler_name is
already streamed, but not rtl...).

Not streaming rtl causes it to be recreated later (which i think might
be the cause of the bad ordering).

Now another problem is that when two pph are generated, they are not
aware of each other (and of their respective
first/weak_global_object_name...) so even if we stream those
variables, their could still be conflicts (and/or asm diffs..)

However, I'm not sure about how make_decl_rtl works, but if it can
regenerate the same rtl we had before (and even potentially solve the
conflicts mentioned in the previous paragraph), we may not need to
actually stream the rtl, we would just need to fix the ordering as the
pph rtl's are being regenerated.

(they are regenerated because DECL_RTL(NODE) either returns
(NODE)->decl_with_rtl.rtl or calls make_decl_rtl(NODE) if it's
NULL...)

If we do this, I think we wanna have the first/weak_object_global_name
set to what it should be by streaming it in from the first pph, to
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.J. Lu | 1 Jul 2011 06:43
Picon

Re: [PATCH] Handle vectorization of invariant loads (PR46787)

On Thu, Jun 30, 2011 at 8:24 AM, Richard Guenther <rguenther <at> suse.de> wrote:
> On Wed, 29 Jun 2011, Richard Guenther wrote:
>
>>
>> The following patch makes us handle invariant loads during vectorization.
>> Dependence analysis currently isn't clever enough to disambiguate them
>> thus we insert versioning-for-alias checks.  For the testcase hoisting
>> the load is still always possible though, and for a read-after-write
>> dependence it would be possible for the vectorized loop copy as the
>> may-aliasing write is varying by the scalar variable size.
>>
>> The existing code for vectorizing invariant accesses looks very
>> suspicious - it generates a vector load at the scalar address
>> to then just extract the first vector element.  Huh.  IMHO this
>> can be simplified as done, by just re-using the scalar load result.
>> But maybe this code was supposed to deal with something entirely
>> different?
>>
>> This patch gives a 33% speedup to the phoronix himeno testcase
>> if you bump the maximum alias versioning checks we want to insert.
>>
>> I'm currently re-bootstrapping & testing this but an earlier version
>> was ok on x86_64-unknown-linux-gnu.
>
> FYI, I'm testing the following which cures a fallout seen when
> building SPEC2k6 with the committed patch.  It's suboptimal for
> j != 0 though - is there a way to get to the vectorized stmt
> of the j == 0 iteration?
>
> Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kirill Yukhin | 1 Jul 2011 07:36
Picon

Re: C++ PATCH for c++/49418 (lost cv-quals on template parameter type)

Hi Jason,
I've had looked into the problem and I believe, that problem is
somehow connected to FE.
Moreover, it is really look like that it is connected to
array-to-pointer conversion.

I put lots of details in the bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Here is very short description:
C++ code looks like this:
include/base/thread_management.h:
        template <typename PFun, typename C, typename ArgList>
        static inline void do_call (PFun     fun_ptr,
                                    C       &obj,
                                    ArgList &arg_list,
                                    internal::return_value<RT> &ret_val,
                                    const int2type<4> &)
          {
            ret_val.set ((obj.*fun_ptr) (arg_list.template get<0>(),
                                         arg_list.template get<1>(),
                                         arg_list.template get<2>(),
                                         arg_list.template get<3>()));

While after "einline" phase it becomes:
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167199_17 =
MEM[(struct cons &)arg_list_2(D) + 12].head;
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167198_18 =
MEM[(struct cons &)arg_list_2(D) + 8].head;
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167197_19 =
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Guenther | 1 Jul 2011 08:55
Picon

[PATCH] Fix PR49603


This fixes PR49603.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2011-07-01  Richard Guenther  <rguenther <at> suse.de>

	PR tree-optimization/49603
	* tree-vect-stmts.c (vectorizable_load): Remove unnecessary
	assert.

	* gcc.dg/torture/pr49603.c: New testcase.

Index: gcc/tree-vect-stmts.c
===================================================================
--- gcc/tree-vect-stmts.c	(revision 175709)
+++ gcc/tree-vect-stmts.c	(working copy)
 <at>  <at>  -4574,19 +4574,14  <at>  <at>  vectorizable_load (gimple stmt, gimple_s
 	      /* 4. Handle invariant-load.  */
 	      if (inv_p && !bb_vinfo)
 		{
+		  tree vec_inv;
+		  gimple_stmt_iterator gsi2 = *gsi;
 		  gcc_assert (!strided_load);
-		  if (j == 0)
-		    {
-		      tree vec_inv;
-		      gimple_stmt_iterator gsi2 = *gsi;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Guenther | 1 Jul 2011 09:02
Picon

Re: [PATCH, PR 49094] Refrain from creating misaligned accesses in SRA

On Thu, 30 Jun 2011, Martin Jambor wrote:

> Hi,
> 
> On Thu, Jun 30, 2011 at 03:39:55PM +0200, Martin Jambor wrote:
> > Hi,
> > 
> > I had to add a test that the analyzed expression is not an SSA name.
> > This has been approved by Rchi on IRC yesterday.  Thus, I have
> > committed the following as revision 175703 after successful run of c
> > and c++ testsuite on sparc64 (and a bootstrap and test with another
> > patch on x86_64-linux).
> 
> I also tested fortran on sparc64 but missed a regression there
> (gfortran.dg/pr25923.f90).  The problem is that *arg_1(D) is also
> scrutinized, get_object_alignment returns 8 for it and that is
> obviously not enough for SImode required alignment.
> 
> I assume such loads have to be aligned for the mode on strict aligned
> targets and therefore they are OK.  The question is, is that true for
> all MEM_REFs or only for those with zero offset?  Since the original
> problem was that the expander expanded
> 
> MEM[(struct ip *)ip_3 + 7B].s_addr;
> 
> as if it was aligned, I suppose that MEM_REFs are generally fine and
> we can avoid this issue by skipping them just like the SSA_NAMEs.  Is
> my reasoning correct?

Not really.  This just highlights the issue that alignment on
(Continue reading)

Permalink | Reply | 0 comments |

Gmane