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
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: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 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 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 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 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 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 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 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,
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
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, 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 Sun, Aug 12, 2012 at 5:27 PM, Diego Novillo dnovi...@google.com wrote:
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
41 matches
Mail list logo
