Hi,
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
template typename T
struct D : BT
{
typedef typename BT::E E; // element_type
E getme (int index);
}
Inside that struct, lets say we have a field of type E. Do we name
it F or f?
IMHO only for types, not for any other decls.
On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz m...@suse.de wrote:
It is common practice to have
struct Q
{
typedef int E;
E getme (int index);
};
Easy: I wouldn't make a typedef for Q::E that merely is int. The reason
is that it makes knowing what getme really returns harder.
The
On 9/28/12, Michael Matz m...@suse.de wrote:
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
template typename T
struct D : BT
{
typedef typename BT::E E; // element_type
E getme (int index);
}
Inside that struct, lets say we have a field of type E. Do we name
it F or f?
On Fri, Sep 28, 2012 at 12:40 PM, Lawrence Crowl cr...@google.com wrote:
On 9/28/12, Michael Matz m...@suse.de wrote:
I would even prefer 'e' over value_type. It's scoped, the context always
will be clear, no need to be verbose in that name. I find the long names
inelegant, as most of the
On 9/28/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz m...@suse.de wrote:
It is common practice to have
struct Q
{
typedef int E;
E getme (int index);
};
Easy: I wouldn't make a typedef for Q::E that merely is int. The reason
Hi,
On Wed, 26 Sep 2012, Lawrence Crowl wrote:
A lower-case type name indicates to me a non-changing type,
i.e. nothing that depends on a template. In C we only had
such types so we used lower-case names everywhere. With C++
and templates I think we should start using upper case for
On Thu, Sep 27, 2012 at 7:12 AM, Michael Matz m...@suse.de wrote:
(And if they aren't, then again, we did something too
complicated with the switch to C++).
or we are doing something by insisting not to use
standard notation.
On 9/27/12, Michael Matz m...@suse.de wrote:
On Wed, 26 Sep 2012, Lawrence Crowl wrote:
A lower-case type name indicates to me a non-changing type,
i.e. nothing that depends on a template. In C we only had
such types so we used lower-case names everywhere. With C++
and templates I
On Thu, Sep 27, 2012 at 1:35 PM, Lawrence Crowl cr...@google.com wrote:
If we were to follow C++ standard library conventions, we would call
it value_type. That would be my preference. However, if folks
want a shorter name, I'll live with that too. But as it stands,
the current name is
Hi,
On Tue, 25 Sep 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T
On Tue, Sep 25, 2012 at 4:30 PM, Lawrence Crowl cr...@google.com wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef
On 9/26/12, Michael Matz m...@suse.de wrote:
On Tue, 25 Sep 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
On Wed, Sep 26, 2012 at 1:09 PM, Lawrence Crowl cr...@google.com wrote:
The problem is that while T is customary as a template parameter, I
have never seen it used as a typedef name. And that's the situation
that we are in now.
this should be a no-brainer: T should be reserved for the name
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
I've
On Thu, Aug 23, 2012 at 01:54:38PM -0700, Mike Stump wrote:
I think:
# Remove the -O2: for historical reasons, unless bootstrapping we prefer
# optimizations to be activated explicitly by the toplevel.
case $CC in
*/prev-gcc/xgcc*) ;;
*) CFLAGS=`echo
Il 13/09/2012 10:46, Jakub Jelinek ha scritto:
# Remove the -O2: for historical reasons, unless bootstrapping we prefer
# optimizations to be activated explicitly by the toplevel.
case $CC in
*/prev-gcc/xgcc*) ;;
*) CFLAGS=`echo $CFLAGS | sed
On Thu, Sep 13, 2012 at 10:53:23AM +0200, Paolo Bonzini wrote:
Il 13/09/2012 10:46, Jakub Jelinek ha scritto:
# Remove the -O2: for historical reasons, unless bootstrapping we prefer
# optimizations to be activated explicitly by the toplevel.
case
Il 13/09/2012 17:57, Jakub Jelinek ha scritto:
Can we get this change in? The current state is terribly annoying.
Yes, please go ahead.
Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
additionally tested on --disable-bootstrap tree, both by make cc1 inside of
gcc
Diego Novillo dnovi...@google.com writes:
+# Skip all inline functions in tree.h.
+# These are used in accessor macros.
+# Note that this is added at the end because older gdb versions
+# do not understand the 'skip' command.
+skip tree.h
(gdb) skip tree.h
No function found named tree.h.
Il 23/08/2012 22:54, Mike Stump ha scritto:
# Remove the -O2: for historical reasons, unless bootstrapping we prefer
# optimizations to be activated explicitly by the toplevel.
case $CC in
*/prev-gcc/xgcc*) ;;
*) CFLAGS=`echo $CFLAGS | sed
On Aug 24, 2012, at 12:24 AM, Paolo Bonzini wrote:
Agreed, patch is preapproved. This is not really done to aid debugging
though, it is to avoid optimization bugs when compiling stage1.
Ah, but building a non-bootstrap compiler from the top-level builds -O2 and
when built from the gcc
On 2012-08-23 16:54 , Mike Stump wrote:
On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
Other than the bootstrap change, the patches make no functional
changes to the compiler. Everything should build as it does now in
trunk.
In my gcc/Makefile, I see:
CFLAGS = -g CXXFLAGS = -g -O2
Odd.
On Fri, Aug 24, 2012 at 08:30:36AM -0400, Diego Novillo wrote:
On 2012-08-23 16:54 , Mike Stump wrote:
On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
Other than the bootstrap change, the patches make no functional
changes to the compiler. Everything should build as it does now in
trunk.
On 2012-08-24 08:35 , Jakub Jelinek wrote:
You haven't built your compiler with --disable-bootstrap, so you aren't
seeing what Mike is complaining about.
Ah, Mike failed to mention that detail.
Mike, it is unlikely that I will be able to work on a fix before I
leave. It does not look like
On Aug 24, 2012, at 5:35 AM, Jakub Jelinek wrote:
You haven't built your compiler with --disable-bootstrap, so you aren't
seeing what Mike is complaining about.
Actually, I'm not using disable Just a normal cross compile.
On Aug 12, 2012, at 1:15 PM, Diego Novillo wrote:
+ Second, the GCC conding conventions prefer explicit conversion,
Spelling... coding
On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
Other than the bootstrap change, the patches make no functional
changes to the compiler. Everything should build as it does now
in trunk.
In my gcc/Makefile, I see:
CFLAGS = -g
CXXFLAGS = -g -O2
This makes builds in the gcc directory default
On Tue, Aug 21, 2012 at 3:31 AM, Lawrence Crowl cr...@google.com wrote:
On 8/20/12, H.J. Lu hjl.to...@gmail.com wrote:
The C++ merge caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
GCC memory usage is more than doubled from = 3GB to = 10GB.
Is this a known issue?
The two memory
On Tue, Aug 14, 2012 at 11:59 AM, Diego Novillo dnovi...@google.com wrote:
On 12-08-14 09:48 , Diego Novillo wrote:
This merge touches several files, so I'm thinking that the best time is
going to be on Thu 16/Aug around 2:00 GMT.
So, the fixes I needed from Lawrence are already in so we
On 8/20/12, H.J. Lu hjl.to...@gmail.com wrote:
The C++ merge caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
GCC memory usage is more than doubled from = 3GB to = 10GB.
Is this a known issue?
The two memory stat reports show no differences. Are you sure you
didn't splice in the
On Mon, Aug 20, 2012 at 6:31 PM, Lawrence Crowl cr...@google.com wrote:
On 8/20/12, H.J. Lu hjl.to...@gmail.com wrote:
The C++ merge caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
GCC memory usage is more than doubled from = 3GB to = 10GB.
Is this a known issue?
The two memory
On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Tom I asked Keith to resurrect his patch for this.
[snip]
I hope this will be acceptable all around.
OK, that
On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz kei...@redhat.com wrote:
On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Tom I asked Keith to resurrect his
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
Hi,
I have another out of curiosity-type question ;)
On 08/16/2012 11:19 AM, Richard Guenther wrote:
!
! template typename Element
! inline int
! pointer_hashElement::equal (const T *existing,
! const T *candidate)
! {
! return existing == candidate;
}
are
On Thu, 16 Aug 2012, Paolo Carlini wrote:
Hi,
I have another out of curiosity-type question ;)
On 08/16/2012 11:19 AM, Richard Guenther wrote:
!
! template typename Element
! inline int
! pointer_hashElement::equal (const T *existing,
! const T
On 12-08-16 12:50 , Iain Sandoe wrote:
On 14 Aug 2012, at 19:59, Diego Novillo wrote:
After the merge is in, I will send an announcement and request major branch
merges to wait for another 24 hrs to allow testers the chance to pick up this
merge.
The following patch (mimicking what has
On 8/16/12, Richard Guenther rguent...@suse.de wrote:
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than
On Tue, Aug 14, 2012 at 10:04 AM, Richard Guenther rguent...@suse.de wrote:
On Mon, 13 Aug 2012, Lawrence Crowl wrote:
On 8/13/12, Richard Guenther richard.guent...@gmail.com wrote:
Increment/decrement operations did not exist, please do not add
them at this point.
Note that I have also
On Wed, Aug 15, 2012 at 12:28:58PM +0200, Richard Guenther wrote:
the function names make no sense - they should be talking about
host-wide-ints, because that is what they are about. Thus,
/* Conversion functions. */
HOST_WIDE_INT to_signed_hwi () const;
unsigned HOST_WIDE_INT
On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 15, 2012 at 12:28:58PM +0200, Richard Guenther wrote:
the function names make no sense - they should be talking about
host-wide-ints, because that is what they are about. Thus,
/* Conversion functions. */
On Wed, 15 Aug 2012, Richard Guenther wrote:
On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 15, 2012 at 12:28:58PM +0200, Richard Guenther wrote:
the function names make no sense - they should be talking about
host-wide-ints, because that is what they
On 12-08-15 07:59 , Richard Guenther wrote:
(gdb) call debug_tree (*expr_p)
integer_cst 0x7695d7c0 type integer_type 0x767fa5e8 int
constant 9
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any overloaded instance
Yeah, in the absence of overloads this
On Wed, 15 Aug 2012, Diego Novillo wrote:
On 12-08-15 07:59 , Richard Guenther wrote:
(gdb) call debug_tree (*expr_p)
integer_cst 0x7695d7c0 type integer_type 0x767fa5e8 int
constant 9
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any
On 12-08-15 08:18 , Richard Guenther wrote:
0 is fixed if you have recent enough gdb.
(gdb) call debug_tree (0)
as 0 is a null pointer constant.
Oh, cool. Progress.
GDB folks, would it be hard to figure out that there is a single variant
of the called function and trust the user that
On Wed, 15 Aug 2012, Richard Guenther wrote:
On Sun, 12 Aug 2012, Diego Novillo wrote:
This implements a new C++ hash table.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
Diego.
Now as we see the result I'd have prefered a more C++-way instead
of
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
Like the following, only the coverage.c use is converted. I've never
seen template function arguments anywhere and having to repeat them all
over the place is really really ugly (yes, even if only in the
implementation).
This goes with
On Aug 15, 2012, at 4:59 AM, Richard Guenther wrote:
and debugging becomes a nightmare (hello gdb people!)
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any overloaded instance
Inquiring minds want to know if:
macro define debug_tree(A) ((tree)A)
makes the
On Wed, 15 Aug 2012, Michael Matz wrote:
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
Like the following, only the coverage.c use is converted. I've never
seen template function arguments anywhere and having to repeat them all
over the place is really really ugly (yes, even if
This implements the VEC re-write.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
You didn't update the head comment in vec.h though, is that on purpose?
--
Eric Botcazou
On 12-08-15 10:44 , Eric Botcazou wrote:
This implements the VEC re-write.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
You didn't update the head comment in vec.h though, is that on purpose?
Yes. I am updating it now that I'm *really* changing the interface.
On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote:
GDB folks, would it be hard to figure out that there is a single
variant of the called function and trust the user that they are
passing the right pointer value?
It is a needless violation of C++ resolving rules. There are various easy
Hi,
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
It is a needless violation of C++ resolving rules.
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
There are various easy way how to get it working (in .gdbinit or
Hi,
On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
In such case there should be a GDB setting for it as at least from
On 12-08-15 11:44 , Michael Matz wrote:
Hi,
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
It is a needless violation of C++ resolving rules.
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
Agreed. If I'm passing a
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
r~
On Wed, Aug 15, 2012 at 05:49:34PM +0200, Jan Kratochvil wrote:
On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
Diego == Diego Novillo dnovi...@google.com writes:
Diego GDB folks, would it be hard to figure out that there is a single
Diego variant of the called function and trust the user that they are
Diego passing the right pointer value?
I asked Keith to resurrect his patch for this.
Tom
On Wed, Aug 15, 2012 at 12:53 PM, Tom Tromey tro...@redhat.com wrote:
Diego == Diego Novillo dnovi...@google.com writes:
Diego GDB folks, would it be hard to figure out that there is a single
Diego variant of the called function and trust the user that they are
Diego passing the right pointer
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Tom I asked Keith to resurrect his patch for this.
Gaby Since people are concerned about typing rules, would it
Gaby be an option for GDB to allow people to input pointer
Gaby literals with the p suffix (or 0p prefix instead of 0x)?
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Tom I asked Keith to resurrect his patch for this.
Gaby Since people are concerned about typing rules, would it
Gaby be an option for GDB to allow people to
On 08/15/2012 06:00 PM, Diego Novillo wrote:
On the switch to C++ as the build language for GCC ...
Here are my results:
0:30 UTC - using C as the initial build language:
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01329.html
and:
18:40 UTC - using C++ as the initial build language:
On 8/15/12, Richard Guenther rguent...@suse.de wrote:
On Sun, 12 Aug 2012, Diego Novillo wrote:
This implements a new C++ hash table.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
Now as we see the result I'd have prefered a more C++-way instead
of making the
On 8/15/12, Richard Guenther rguent...@suse.de wrote:
On Wed, 15 Aug 2012, Michael Matz wrote:
On Wed, 15 Aug 2012, Richard Guenther wrote:
Like the following, only the coverage.c use is converted.
I've never seen template function arguments anywhere and
having to repeat them all
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
I do
On Wed, Aug 15, 2012 at 2:58 PM, Lawrence Crowl cr...@google.com wrote:
I do not much like _t names either.
Also, names ending in _t are reserved by POSIX if you #include
sys/types.h. Though that may only apply to global names, not to
types defined in classes or namespaces.
Ian
On Mon, 13 Aug 2012, Lawrence Crowl wrote:
On 8/13/12, Richard Guenther richard.guent...@gmail.com wrote:
Increment/decrement operations did not exist, please do not add
them at this point.
Note that I have also added +=, -= and *= operations. Having them
has three advantages. First,
Hello Diego,
Just some minor comments.
Diego Novillo dnovi...@google.com a écrit:
[...]
+@section User-provided marking routines for template types
+When a template type @code{TP} is marked with @code{GTY}, all
+instances of that type are considered user-provided types. This means
+that
On 12-08-14 01:39 , Laurynas Biveinis wrote:
(walk_type): Set D-IN_PTR_FILED when walking a TYPE_POINTER.
FIELD
Done.
+fields is completely handled by user-provided routines. Section
+@ref{User GC} for details on what functions need to be provided.
See Section ... ?
Done.
On 12-08-14 04:38 , Dodji Seketeli wrote:
Hello Diego,
Just some minor comments.
Diego Novillo dnovi...@google.com a écrit:
[...]
+@section User-provided marking routines for template types
+When a template type @code{TP} is marked with @code{GTY}, all
+instances of that type are considered
On 12-08-14 09:48 , Diego Novillo wrote:
This merge touches several files, so I'm thinking that the best time is
going to be on Thu 16/Aug around 2:00 GMT.
So, the fixes I needed from Lawrence are already in so we can proceed
with the merge. I'll commit the merge tonight at ~2:00 GMT.
On Mon, Aug 13, 2012 at 2:34 AM, Diego Novillo dnovi...@google.com wrote:
On 12-08-12 16:16 , Steven Bosscher wrote:
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo dnovi...@google.com
wrote:
This patch implements the configuration changes needed to
bootstrap with a C++ compiler by default.
On 12-08-13 02:51 , Steven Bosscher wrote:
On Mon, Aug 13, 2012 at 2:34 AM, Diego Novillo dnovi...@google.com wrote:
On 12-08-12 16:16 , Steven Bosscher wrote:
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo dnovi...@google.com
wrote:
This patch implements the configuration changes needed
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo dnovi...@google.com wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change the default bootstrap
On Sun, Aug 12, 2012 at 11:30 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 12 Aug 2012, Diego Novillo wrote:
This implements the double_int rewrite.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
Diego.
I am taking it as a chance to ask a couple
On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
+inline double_int
+double_int::operator ++ ()
+{
+ *this + double_int_one;
*this += double_int_one;
would be less confusing.
Do you mean that *this + double_int_one; alone also works, just is
confusing? That would mean
On Mon, 13 Aug 2012, Jakub Jelinek wrote:
On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
+inline double_int
+double_int::operator ++ ()
+{
+ *this + double_int_one;
*this += double_int_one;
would be less confusing.
Do you mean that *this + double_int_one; alone also works,
On Mon, Aug 13, 2012 at 5:32 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 13 Aug 2012, Jakub Jelinek wrote:
On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
+inline double_int
+double_int::operator ++ ()
+{
+ *this + double_int_one;
*this += double_int_one;
would
On 12-08-13 05:37 , Richard Guenther wrote:
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo dnovi...@google.com wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html,
On 12-08-13 05:39 , Richard Guenther wrote:
It's an odd thing that you need to touch code replacing - with . (yes, it's
due to the use of references) but not at the same time convert those places
to the new VEC interface.
Yes. I hated this aspect of the initial conversion. It caused many
On 8/13/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Aug 13, 2012 Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 13 Aug 2012, Jakub Jelinek wrote:
On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
+inline double_int
+double_int::operator ++ ()
+{
On 8/12/12, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 12 Aug 2012, Diego Novillo wrote:
This implements the double_int rewrite.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
I am taking it as a chance to ask a couple questions about the coding
On 8/13/12, Richard Guenther richard.guent...@gmail.com wrote:
Increment/decrement operations did not exist, please do not add
them at this point.
Note that I have also added +=, -= and *= operations. Having them
has three advantages. First, it matches expectations on what
numeric types
On Mon, Aug 13, 2012 at 5:41 AM, Richard Guenther
richard.guent...@gmail.com wrote:
*this += double_int_one;
would be less confusing.
Increment/decrement operations did not exist, please do not add them
at this point.
But they are going to be used when the call-sites are converted.
There is
On 08/13/2012 01:22 PM, Lawrence Crowl wrote:
yes, it is just as confusing and a bug as
2.3 + 1;
is in plain C.
Yes, it is a bug. It's a bit disturbing that it wasn't caught
in bootstrap.
You'll recall that I pointed it out last time around as well.
r~
On 8/13/12, Richard Henderson r...@redhat.com wrote:
On 08/13/2012 01:22 PM, Lawrence Crowl wrote:
yes, it is just as confusing and a bug as
2.3 + 1;
is in plain C.
Yes, it is a bug. It's a bit disturbing that it wasn't caught
in bootstrap.
You'll recall that I pointed it out last
Diego -
I have some relatively minor comments. In general, the these changes
and the adjusted GTY doc intro blurb you sent in the other email are
OK with the minor comments addressed and if no objections from global
maintainers.
(walk_type): Set D-IN_PTR_FILED when walking a
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change the default bootstrap process so that stage 1 always
builds with a C++ compiler.
Other than the
This patch implements the configuration changes needed to
bootstrap with a C++ compiler by default.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
Diego.
ChangeLog
2012-08-12 Diego Novillo dnovi...@google.com
* Makefile.in (CXX_FOR_BUILD): Define.
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo dnovi...@google.com wrote:
This patch implements the configuration changes needed to
bootstrap with a C++ compiler by default.
Hi,
Is it possible to add -fno-rtti to the default CXX_FLAGS, and remove
it if necessary?
Ciao!
Steven
This implements support for calling tree macros from gdb.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
Diego.
2012-08-12 Lawrence Crowl cr...@google.com
* tree.h (tree_check): New.
(TREE_CHECK): Use inline function above instead of __extension__.
Diego Novillo dnovi...@google.com writes:
diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in
index d1ae46d..858e490 100644
--- a/gcc/gdbinit.in
+++ b/gcc/gdbinit.in
@@ -182,6 +182,17 @@ document pbm
Dump the bitmap that is in $ as a comma-separated list of numbers.
end
+# Define some
On Sun, 12 Aug 2012, Diego Novillo wrote:
ChangeLog
2012-08-12 Diego Novillo dnovi...@google.com
* Makefile.in (CXX_FOR_BUILD): Define.
(BUILD_CXX_FLAGS): Define
(COMPILER_FOR_BUILD): Set to CXX_FOR_BUILD if building with C++.
(LINKER_FOR_BUILD): Likewise.
On Sun, 12 Aug 2012, Diego Novillo wrote:
For those who would like to build the conversion, you can either
checkout the branch from SVN
(svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
trunk I have in the git repo (branch dnovillo/cxx-conversion).
The bootstrap changes have
On Sun, 12 Aug 2012, Diego Novillo wrote:
This implements the double_int rewrite.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
Diego.
I am taking it as a chance to ask a couple questions about the coding
conventions.
2012-08-12 Lawrence Crowl
On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change the default bootstrap
On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
On 12-08-12 18:38 , H.J. Lu wrote:
On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As
On 12-08-12 16:57 , Marc Glisse wrote:
other compiler that managed. IBM and Oracle both fail (the comment is
not clear, but I think 12.3 also fails, just not exactly in the same
way), and HP and Intel (to mention just a few) are not listed.
We should fix/workaround failing host C++ compilers
On 12-08-12 16:16 , Steven Bosscher wrote:
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo dnovi...@google.com wrote:
This patch implements the configuration changes needed to
bootstrap with a C++ compiler by default.
Hi,
Is it possible to add -fno-rtti to the default CXX_FLAGS, and remove
1 - 100 of 103 matches
Mail list logo
