headers
Andrew Pinski | 1 May 2007 01:25
Picon

Re: [PATCH] rvalue reference implementation for C++0x

On 4/24/07, Russell Yanofsky <russ <at> yanofsky.org> wrote:
> This is an update of a patch first posted two months ago:
>
> http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01760.html
>
> There was some discussion about it which ended here:
>
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01283.html
>
> The updated patch implements rvalue references entirely in the C++ front
> end instead of modifying middle end code.

How does this interact with vector types and code like (I just fixed
the bug with normal references, I don't want rvalue references to be
broken also):
#define vector __attribute__((__vector_size(16) ))
vector int a(void);
vector int &&b = a();

Thanks,
Andrew Pinski
Permalink | Reply | 1 comment |
headers
H. J. Lu | 1 May 2007 02:47

Re: PATCH: PR target/31344: Bootstrap is broken on i[345]86-linux

On Mon, Apr 30, 2007 at 03:27:50PM -0700, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl <at> lucon.org> writes:
> 
> > On Sun, Apr 29, 2007 at 05:14:05PM -0700, H. J. Lu wrote:
> > > 
> > > emit_single_push_insn calls emit_move_insn to push dfp. emit_move_insn
> > > calls emit_move_via_integer to push dfp via integer, which generates
> > > 
> > > (set (reg/f:SI 67) (pre_dec:SI (reg/f:SI 7 sp)))
> > > 
> > > It leads to an unrecognizable insn error. I am not sure if
> > > emit_move_via_integer properly handles moving from Y to X and X
> > > satifies push_operand.
> > > 
> > > 
> > 
> > Does this patch makes any senses?
> > 
> > 
> > H.J.
> > ----
> > 2007-04-29  H.J. Lu  <hongjiu.lu <at> intel.com>
> > 
> > 	PR target/31344
> > 	* expr.c (emit_move_resolve_push): Move it before ...
> > 	(emit_move_via_integer): This.  Call emit_move_resolve_push to
> > 	replace the push destination with a reference to the stack
> > 	pointer.
> 
> This doesn't make sense to me.  It seems like it will generate worse
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans-Peter Nilsson | 1 May 2007 05:29
Picon
Favicon

In-tree gmp builds broken (was: Re: [1/4] [patch, middle-end] Make mpz_set/get_double_int functions non-static.)

In-tree gmp broke with 124303:124306.

> Date: Sat, 07 Apr 2007 09:23:28 -0700
> From: Brooks Moses <brooks.moses <at> codesourcery.com>

> 2007-04-07  Brooks Moses  <brooks.moses <at> codesourcery.com>
> 
> 	double-int.c (mpz_set_double_int): Moved from
> 	tree-ssa-loop-niter.c.
> 	(mpz_get_double_int): Likewise.
> 	double-int.h: New prototypes for above.

(Tsk tsk, doesn't mention the new #include gmp.h.)

> 	tree.c (get_type_static_bounds): Moved from
> 	get_type_bounds in tree-ssa-loop-niter.c.
> 	tree.h: New prototype for above.
> 	tree-ssa-loop-niter.c: Adjust mpz_to_double_int,
> 	get_type_bounds calls.
> 	(mpz_set_double_int): Moved to double-int.c.
> 	(mpz_to_double_int): Moved to double-int.c, renamed to
> 	mpz_get_double_int.
> 	(get_type_bounds): Moved to tree.c, renamed to
> 	get_type_static_bounds.

> Index: double-int.h
> ===================================================================
> --- double-int.h	(revision 123513)
> +++ double-int.h	(working copy)
>  <at>  <at>  -21,6 +21,9  <at>  <at>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Tobias Schlüter | 1 May 2007 05:58
Picon
Favicon

Re: Fix for PR fortran/31732

Thomas Koenig wrote:
>      {
> +      /*
> +	If we hange a single element in the reference, we need to check that
> +	the array has a single element and that we actually reference the
> +	correct element.
> +       */

<nitpicking>should be
  /* If we have a single element in the reference, we need to check that
     the array has a single element and that we actually reference the
     correct element.  */
</nitpicking>

Thanks,
- Tobi
Permalink | Reply | 0 comments |
headers
Brooks Moses | 1 May 2007 06:12

Re: In-tree gmp builds broken (was: Re: [1/4] [patch, middle-end] Make mpz_set/get_double_int functions non-static.)

At 08:29 PM 4/30/2007, Hans-Peter Nilsson wrote:
>In-tree gmp broke with 124303:124306.
>
> > 2007-04-07  Brooks Moses  <brooks.moses <at> codesourcery.com>
> >
> >       double-int.c (mpz_set_double_int): Moved from
> >       tree-ssa-loop-niter.c.
> >       (mpz_get_double_int): Likewise.
> >       double-int.h: New prototypes for above.
>
>(Tsk tsk, doesn't mention the new #include gmp.h.)

Mea culpa.  And this provides quite a clear illustration of why that's 
important; I suspect I shall not forget again!  :)

[...]
>This bit causes in-tree gmp (where you untar gmp sources in the
>tree at the top-level and mv gmp-* gmp) to fail, because
>double-int.h is included in system.h, which is included in
>configure.ac tests, *but without the necessary -I flags to find
>gmp.h which isn't even built at this time*.  Hence all autoconf
>tests that #include "system.h" fail, and erroneous fall-back
>stuff is put in auto-host.h, causing compilation to fail for
>e.g. genmodes.o:
[...]
>Configury people, help!

One possible quick solution would be for me to simply move the functions 
that depend on GMP into some other file that's not included in system.h, so 
as to avoid the symptoms of the problem for now.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Russell Yanofsky | 1 May 2007 06:28

Re: [PATCH] rvalue reference implementation for C++0x

On Mon, 2007-04-30 at 18:51 -0400, Doug Gregor wrote:
> Looking more closely at this, I think Jason is right... the B(A)
> allows us to build a B, but we still need a copy constructor to make a
> copy of the B before binding the reference.

You don't need to make a copy of temporary value before binding a
reference to it. You used to need to check for a copy constructor, but
you don't anymore. In C++0x, compilers are required to do a direct
binding here. That's the point I was making at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01752.html . And there's
more information about this in DR391:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391 . 

>  Now, the compiler is
> permitted to elide the actual copy construction... but the copy
> constructor needs to be there even if the copy construction will be
> elided. I had thought that the rvalue references proposal change this,
> but it did not. This paragraph from N2118 points out explicitly that
> out explicitly:
> 
> -16- When the criteria for elision of a copy operation are met and the
> object to be copied is designated by an lvalue, overload resolution to
> select the constructor for the copy is first performed as if the
> object were designated by an rvalue. If overload resolution fails, or
> if the type of the first parameter of the selected constructor is not
> an rvalue-reference to the object's type (possibly cv-qualified),
> overload resolution is performed again, considering the object as an
> lvalue. [Note: This two-stage overload resolution must be performed
> regardless of whether copy elision will occur. It determines the
> constructor to be called if elision is not performed, and the selected
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russell Yanofsky | 1 May 2007 06:37

Re: [PATCH] rvalue reference implementation for C++0x

On Mon, 2007-04-30 at 16:25 -0700, Andrew Pinski wrote:
> How does this interact with vector types and code like (I just fixed
> the bug with normal references, I don't want rvalue references to be
> broken also):
> #define vector __attribute__((__vector_size(16) ))
> vector int a(void);
> vector int &&b = a();

Rvalue reference type nodes are identical to lvalue reference type
nodes, except rvalue nodes have a new TYPE_REF_IS_RVALUE flag set. Any
code that handles references should affect both types of references the
same way, unless it explicitly checks the TYPE_REF_IS_RVALUE flag.

I can check the bugfix code specifically if you want to point me to it.

--

-- 
-  Russell Yanofsky (PGP ID: 0x5FAA0216)
-  http://russ.yanofsky.org/
--
Permalink | Reply | 0 comments |
headers
Eric Botcazou | 1 May 2007 09:46
Picon

Re: [PATCH] Fix PR30957

> This patch makes MVE to honor signed zero by initializing the variable
> expansions with -zero (instead of +zero).

It's a waste of time if the mode need not support signed zeros so the change 
should be conditionalized on HONOR_SIGNED_ZEROS.  (Of course this means that 
the original problem with mzero6.c won't be solved but, as Andrew said, the 
gcc.c-torture/execute/ieee tests should not be run with -ffast-math).

Zdenek has been CCed but I don't see any message from him.  Zdenek, would it 
exist any other approach to avoiding this small pitfall?

--

-- 
Eric Botcazou
Permalink | Reply | 2 comments |
headers
Zdenek Dvorak | 1 May 2007 10:45
Picon
Favicon

Re: [PATCH] Fix PR30957

Hello,

> > This patch makes MVE to honor signed zero by initializing the variable
> > expansions with -zero (instead of +zero).
> 
> It's a waste of time if the mode need not support signed zeros so the change 
> should be conditionalized on HONOR_SIGNED_ZEROS.  (Of course this means that 
> the original problem with mzero6.c won't be solved but, as Andrew said, the 
> gcc.c-torture/execute/ieee tests should not be run with -ffast-math).
> 
> Zdenek has been CCed but I don't see any message from him.  Zdenek, would it 
> exist any other approach to avoiding this small pitfall?

I do not think so.  (-0) is a neutral element for fp addition, while (+0)
is not, so the initialization should indeed be to -0 (assuming
HONOR_SIGNED_ZEROS).  Actually I already OK'd the patch, but forgot to
cc it to the mailing list.

Zdenek
Permalink | Reply | 1 comment |
headers
Benjamin Kosnik | 1 May 2007 11:20
Picon
Favicon

[v3] testsuite consistency checks


This fixes up the rest of the inconsistencies found when typing "make 
testsuite_files" and looking through the list of files in the libstdc++ 
testsuite.

Changes:
1) correct comment as pointed by Paolo
2) consistent file naming of explicit_instantiation.cc
3) move dr438 checks into class-being-tested requirements directory, as 
done with basic_string.

Sorry for the churn. We're starting to do pretty big transformations 
while testing and it helps if there is only one way to do things.

tested x86/linux

-benjamin
Attachment (p.20070501-1.bz2): application/x-bzip, 1388 bytes
Attachment (p.20070501-2.bz2): application/x-bzip, 3418 bytes
Attachment (p.20070501-3.bz2): application/x-bzip, 1836 bytes
Permalink | Reply | 0 comments |

Gmane