On 9/28/12, Gabriel Dos Reis wrote:
> On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz 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 m
On Fri, Sep 28, 2012 at 12:40 PM, Lawrence Crowl wrote:
> On 9/28/12, Michael Matz 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 standard libs convent
On 9/28/12, Michael Matz wrote:
> On Thu, 27 Sep 2012, Lawrence Crowl wrote:
> > > template
> > > struct D : B
> > > {
> > > typedef typename B::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 8:18 AM, Michael Matz 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.
Hi,
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
> > template
> > struct D : B
> > {
> > typedef typename B::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 Thu, Sep 27, 2012 at 1:35 PM, Lawrence Crowl 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 very confusing.
On 9/27/12, Michael Matz 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 t
On Thu, Sep 27, 2012 at 7:12 AM, Michael Matz 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.
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
On Wed, Sep 26, 2012 at 1:09 PM, Lawrence Crowl 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 of the
templat
On 9/26/12, Michael Matz wrote:
> On Tue, 25 Sep 2012, Lawrence Crowl wrote:
> > On 8/15/12, Richard Henderson 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
On Tue, Sep 25, 2012 at 4:30 PM, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson 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
Hi,
On Tue, 25 Sep 2012, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson 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 8/15/12, Richard Henderson 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 been fi
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
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.
> >> >
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=`e
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*) ;;
> *) CFL
Diego Novillo 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".
Committed
On Aug 12, 2012, at 1:15 PM, Diego Novillo wrote:
> + Second, the GCC conding conventions prefer explicit conversion,
Spelling... coding
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 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 a
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
>
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 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 subtre
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 "s/
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 defau
On Tue, Aug 21, 2012 at 3:31 AM, Lawrence Crowl wrote:
> On 8/20/12, H.J. Lu 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 n
On Mon, Aug 20, 2012 at 6:31 PM, Lawrence Crowl wrote:
> On 8/20/12, H.J. Lu 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 n
On 8/20/12, H.J. Lu 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 wrong report?
On Tue, Aug 14, 2012 at 11:59 AM, Diego Novillo 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 can proceed w
On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz wrote:
> On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
>>
>> On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey wrote:
"Gaby" == Gabriel Dos Reis writes:
>>>
>>>
>>> Tom> I asked Keith to resurrect his patch for this.
>
> [snip]
>
>>> I
On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey wrote:
"Gaby" == Gabriel Dos Reis writes:
Tom> I asked Keith to resurrect his patch for this.
[snip]
I hope this will be acceptable all around.
OK, that sounds reasonable.
I have committed a pat
On 8/16/12, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Lawrence Crowl wrote:
> > On 8/15/12, Richard Henderson 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 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 bee
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 been done elsewhere at r190402)
resto
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
> > ! inline int
> > ! pointer_hash::equal (const T *existing,
> > ! const T *candidate)
>
Hi,
I have another "out of curiosity"-type question ;)
On 08/16/2012 11:19 AM, Richard Guenther wrote:
!
! template
! inline int
! pointer_hash::equal (const T *existing,
! const T *candidate)
! {
! return existing == candidate;
}
are these uses in the new cod
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson 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;
>
On Wed, Aug 15, 2012 at 2:58 PM, Lawrence Crowl wrote:
>
> I do not much like _t names either.
Also, names ending in _t are reserved by POSIX if you #include
. Though that may only apply to global names, not to
types defined in classes or namespaces.
Ian
On 8/15/12, Richard Henderson 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 not much
On 8/15/12, Richard Guenther 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 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.
>
> Now as we see the result I'd have prefered a more C++-way instead
> of making the conve
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 Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey wrote:
>> "Gaby" == Gabriel Dos Reis 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 wit
> "Gaby" == Gabriel Dos Reis 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")?
I think on
On Wed, Aug 15, 2012 at 12:53 PM, Tom Tromey wrote:
>> "Diego" == Diego Novillo 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 Ke
> "Diego" == Diego Novillo 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 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
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 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 num
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 fr
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
> c
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 eas
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.
D
> 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 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,
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 a
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
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
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 they
On Wed, 15 Aug 2012, Diego Novillo wrote:
> On 12-08-15 07:59 , Richard Guenther wrote:
>
> > (gdb) call debug_tree (*expr_p)
> >
> > constant 9>
> > (gdb) call debug_tree (0x767fa5e8)
> > Cannot resolve function debug_tree to any overloaded instance
>
> Yeah, in the absence of overloads
On 12-08-15 07:59 , Richard Guenther wrote:
(gdb) call debug_tree (*expr_p)
constant 9>
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any overloaded instance
Yeah, in the absence of overloads this is annoying. Happens with 0, too.
Diego.
On Sun, 12 Aug 2012, Diego Novillo 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 process so that stage 1 alway
On Wed, 15 Aug 2012, Richard Guenther wrote:
> On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek 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
On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek 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, 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_I
On Tue, Aug 14, 2012 at 10:04 AM, Richard Guenther wrote:
> On Mon, 13 Aug 2012, Lawrence Crowl wrote:
>
>> On 8/13/12, Richard Guenther wrote:
>> > Increment/decrement operations did not exist, please do not add
>> > them at this point.
>>
>> Note that I have also added +=, -= and *= operations.
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.
Afte
On 12-08-12 16:04 , Diego Novillo 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 process so that stage 1 always
builds
On 12-08-14 09:19 , Diego Novillo wrote:
+static const char *
+filter_type_name (const char *type_name)
+{
Maybe this function should return const-less char *? The casts to cast
the const away for freeing it look a bit awkward.
Done.
I was too quick. The problem here is that we sometime
On 12-08-14 04:38 , Dodji Seketeli wrote:
Hello Diego,
Just some minor comments.
Diego Novillo 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
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 ... " ?
Don
Hello Diego,
Just some minor comments.
Diego Novillo 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 the individual in
On Mon, 13 Aug 2012, Lawrence Crowl wrote:
> On 8/13/12, Richard Guenther 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 expectati
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 TYPE_POINT
On 8/13/12, Richard Henderson 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 i
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 Mon, Aug 13, 2012 at 5:41 AM, Richard Guenther
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 no point in leaving
On 8/13/12, Richard Guenther 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 allow. Second, it results in
On 8/12/12, Marc Glisse 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
> conventions.
>
> >
On 8/13/12, Gabriel Dos Reis wrote:
> On Aug 13, 2012 Marc Glisse 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_i
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
m
On 12-08-13 05:37 , Richard Guenther wrote:
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo 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
On Mon, Aug 13, 2012 at 5:32 AM, Marc Glisse 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_
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 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
On Sun, Aug 12, 2012 at 11:30 PM, Marc Glisse 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 questions ab
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo 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 process so that s
On 12-08-13 02:51 , Steven Bosscher wrote:
On Mon, Aug 13, 2012 at 2:34 AM, Diego Novillo wrote:
On 12-08-12 16:16 , Steven Bosscher wrote:
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo
wrote:
This patch implements the configuration changes needed to
bootstrap with a C++ compiler by defa
On Mon, Aug 13, 2012 at 2:34 AM, Diego Novillo wrote:
> On 12-08-12 16:16 , Steven Bosscher wrote:
>>
>> On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo
>> wrote:
>>>
>>> This patch implements the configuration changes needed to
>>> bootstrap with a C++ compiler by default.
>>
>>
>> Hi,
>>
>> Is
On Sun, Aug 12, 2012 at 5:27 PM, Diego Novillo wrote:
> On 12-08-12 18:38 , H.J. Lu wrote:
>>
>> On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu wrote:
>>>
>>> On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo
>>> wrote:
I will be sending 6 patches that implement all the changes we
have bee
On 12-08-12 16:40 , Andreas Schwab wrote:
Diego Novillo 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
+#
On 12-08-12 16:56 , Gerald Pfeifer wrote:
On Sun, 12 Aug 2012, Diego Novillo wrote:
ChangeLog
2012-08-12 Diego Novillo
* Makefile.in (CXX_FOR_BUILD): Define.
(BUILD_CXX_FLAGS): Define
(COMPILER_FOR_BUILD): Set to CXX_FOR_BUILD if building with C++.
(LINKER_FO
On 12-08-12 16:16 , Steven Bosscher wrote:
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo 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?
I
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 s
On 12-08-12 18:38 , H.J. Lu wrote:
On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu wrote:
On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo 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
On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu wrote:
> On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo 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 pat
On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo 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 process so that st
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
* hash
1 - 100 of 104 matches
Mail list logo
