Re: Using C++ in GCC is OK

2010-06-04 Thread Andrew Haley
On 06/03/2010 09:47 PM, Robert Dewar wrote: Andrew Haley wrote: Right, but I didn't think there was any plan to convert en masse to C++ -- just to allow people to use it where appropriate. Apart from anything else, there's always a nonzero probablility of breaking something. It's the

Puzzle about macro MIPS_PROLOGUE_TEMP_REGNUM

2010-06-04 Thread Amker.Cheng
Hi : I found the temp register used for saving registers when expanding prologue is defined by macro MIPS_PROLOGUE_TEMP_REGNUM on mips target, like: #define MIPS_PROLOGUE_TEMP_REGNUM \ (cfun-machine-interrupt_handler_p ? K0_REG_NUM : GP_REG_FIRST + 3) I don't understand why using registers

Re: [x86]: Allow @GOTOFF in non-memory context?

2010-06-04 Thread Rainer Orth
Uros Bizjak ubiz...@gmail.com writes: I'm investigating, which current assemblers are broken, since my assembler from binutils-2.20 happily assembles: addl x...@gotoff(%ebx), %eax in 32bit mode, as well as addq x...@gotpcrel(%rip), %rax in 64bit mode. Looking into gcc install

Re: Using C++ in GCC is OK

2010-06-04 Thread Larry Evans
On 06/03/10 14:39, Steinar Bang wrote: Larry Evans cppljev...@suddenlink.net: claims that switch statements are faster than virtual function calls. That's not really interesting, is it? The overhead and downsides of virtual functions are well known. The upside is the possibility to use

Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Art Haas
Hi. This morning's i386 build fails with the following error: libbackend.a(sol2.o): In function `solaris_output_init_fini': /home/ahaas/gnu/gcc.git/gcc/config/sol2.c:109: undefined reference to `print_operand' /home/ahaas/gnu/gcc.git/gcc/config/sol2.c:116: undefined reference to

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Nathan Froyd
On Fri, Jun 04, 2010 at 01:44:02PM +, Art Haas wrote: This morning's i386 build fails with the following error: libbackend.a(sol2.o): In function `solaris_output_init_fini': /home/ahaas/gnu/gcc.git/gcc/config/sol2.c:109: undefined reference to `print_operand'

Re: Puzzle about macro MIPS_PROLOGUE_TEMP_REGNUM

2010-06-04 Thread Ian Lance Taylor
Amker.Cheng amker.ch...@gmail.com writes: I found the temp register used for saving registers when expanding prologue is defined by macro MIPS_PROLOGUE_TEMP_REGNUM on mips target, like: #define MIPS_PROLOGUE_TEMP_REGNUM \ (cfun-machine-interrupt_handler_p ? K0_REG_NUM : GP_REG_FIRST +

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Ian Lance Taylor
Nathan Froyd froy...@codesourcery.com writes: * config/i386/i386-protos.h (ix86_print_operand): Declare. * config/i386/i386.c (ix86_print_operand): Make non-static. * config/i386/sol2.h (ASM_OUTPUT_CALL): Call ix86_print_operand. * rtl.h (output_operand): Declare.

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Nathan Froyd
On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote: Nathan Froyd froy...@codesourcery.com writes: * config/i386/i386-protos.h (ix86_print_operand): Declare. * config/i386/i386.c (ix86_print_operand): Make non-static. * config/i386/sol2.h (ASM_OUTPUT_CALL): Call

Re: Using C++ in GCC is OK

2010-06-04 Thread Diego Novillo
On Thu, Jun 3, 2010 at 13:42, Andrew Haley a...@redhat.com wrote: I'll turn that into a question: does any GCC maintainer intend to convert working code into C++, with no substantive changes? Not me. Mostly new code and re-engineer only those parts where the value of C++ is a clear advantage.

Re: Using C++ in GCC is OK

2010-06-04 Thread Kai Tietz
Hi, What's about the friends in C++.. I think it should be forbidden by C++ coding-style, as it is mainly a sign of weak OO design to use them. Kai | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Ian Lance Taylor
Nathan Froyd froy...@codesourcery.com writes: On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote: Nathan Froyd froy...@codesourcery.com writes: * config/i386/i386-protos.h (ix86_print_operand): Declare. * config/i386/i386.c (ix86_print_operand): Make non-static. *

Re: [RFC] Switching implementation language to C++

2010-06-04 Thread Joseph S. Myers
On Mon, 31 May 2010, Basile Starynkevitch wrote: I would even imagine that later, one could configure GCC to have only a C++ front-end, but no more a C one. That probably would be unusual, since many important applications which want to be compiled by GCC (I am thinking of the Linux kernel)

Re: Vector indexing patch

2010-06-04 Thread Joseph S. Myers
On Tue, 1 Jun 2010, Artem Shinkarov wrote: This is a reworked patch of Andrew Pinski Subscripting on vector types in terms of GSoC 2010 [Artjoms Sinkarovs]. We can't consider it without a copyright assignment. The documentation was not changed. May be there could be some more ideas to

Auto-generated cross-references can be distributed under the GPL

2010-06-04 Thread Mark Mitchell
The FSF has approved the inclusion of automatically generated cross-reference information (such as that generated by Doxygen, Synopsis, or JavaDoc) in GCC, using GPLv3 for that documentation, rather than the GFDL. There was no license issue in this regard; the question was a policy question. In

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Nathan Froyd
On Fri, Jun 04, 2010 at 08:32:26AM -0700, Ian Lance Taylor wrote: Nathan Froyd froy...@codesourcery.com writes: Looking at things a little more closely, output_address is exported in output.h. I suppose output_operand should be exported there as well? Yes, put the declaration there, by

Re: Using C++ in GCC is OK

2010-06-04 Thread Joseph S. Myers
On Wed, 2 Jun 2010, Richard Guenther wrote: I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. Agreed. Moving code between bits of the compiler should not mean creating ugly inconsistencies of formatting and

Re: Auto-generated cross-references can be distributed under the GPL

2010-06-04 Thread Joseph S. Myers
On Fri, 4 Jun 2010, Mark Mitchell wrote: This explicit permission re. cross-references does not resolve the question of auto-generating parts of GFDL manuals, such as those containing documentation about target hooks or about command-line options. (For target hooks, we might wish to consider

Re: Time to create wwwdocs/htdocs/gcc-4.6?

2010-06-04 Thread Joseph S. Myers
On Thu, 3 Jun 2010, Michael Meissner wrote: You and Richard are correct. I've forgotten that I needed -d on cvs to add directories after using svn for a few years. I recall there were tools to convert cvs to svn (such as cvs2svn), but I haven't used them personally. The issue is not and

Re: GFDL/GPL Issue

2010-06-04 Thread Joseph S. Myers
On Wed, 2 Jun 2010, Mark Mitchell wrote: For API documentation, or, in general, for new manuals, I have no opinion. My guess, though, is that the FSF would want the same invariant sections and such as are on the existing manuals. The standard rules for Cover Texts and inclusion of Invariant

RE: Using C++ in GCC is OK

2010-06-04 Thread Joseph S. Myers
On Wed, 2 Jun 2010, Bingfeng Mei wrote: Converting to C++ is a major change. Does that justify to have a major release (5.0.0)? No. It's not in any way user-visible. In principle I agree with what Zack said in http://gcc.gnu.org/ml/gcc/2004-06/msg00243.html on version numbers; certainly

Re: [RFC] Switching implementation language to C++

2010-06-04 Thread Joseph S. Myers
On Wed, 2 Jun 2010, Richard Guenther wrote: I also notice that all cc1 binaries are dynamically linked against libstdc++ - didn't we want to use -static-libstdc++ and link against the libstdc++ we bootstrap? Yes, that is stated in Ian's slides. There are a series of related configure

Re: Using C++ in GCC is OK

2010-06-04 Thread Joseph S. Myers
On Mon, 31 May 2010, Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Comments welcome. I think the coding style warning

Re: Vector indexing patch

2010-06-04 Thread Joseph S. Myers
On Fri, 4 Jun 2010, Richard Guenther wrote: The mark_addressable_vector change was at least semi-ugly. I think it is reasonable to require a constant index for register qualified vectors. What does the Cell document describing the extension being implemented by the original patch say here?

Re: Using C++ in GCC is OK

2010-06-04 Thread Ian Lance Taylor
Joseph S. Myers jos...@codesourcery.com writes: On Wed, 2 Jun 2010, Bingfeng Mei wrote: Converting to C++ is a major change. Does that justify to have a major release (5.0.0)? No. It's not in any way user-visible. In principle I agree with what Zack said in

RE: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Arthur Haas
Hi. The patch resolves the build failures. Thanks. Art Haas -Original Message- From: Nathan Froyd [mailto:froy...@codesourcery.com] Sent: Friday, June 04, 2010 12:29 PM To: Ian Lance Taylor Cc: Arthur Haas; gcc@gcc.gnu.org Subject: Re: Bootstrap failed for i386-pc-solaris2.10 and

Re: Using C++ in GCC is OK

2010-06-04 Thread Gabriel Dos Reis
On Fri, Jun 4, 2010 at 3:55 PM, Ian Lance Taylor i...@google.com wrote: Joseph S. Myers jos...@codesourcery.com writes: I think we should change the gcc major release to 5 when we change the libstdc++.so major version number to 7. seconded. -- Gaby

Re: Vector indexing patch

2010-06-04 Thread Andrew Pinski
On Tue, Jun 1, 2010 at 12:21 PM, Artem Shinkarov artyom.shinkar...@gmail.com wrote: + error_at (loc, index value is out of bound); That is wrong. The Cell C/C++ language document says out of bounds accesses are undefined (that is at runtime). Thanks, Andrew Pinski

Re: Using C++ in GCC is OK

2010-06-04 Thread Jonathan Wakely
On 4 June 2010 21:55, Ian Lance Taylor wrote: I think we should change the gcc major release to 5 when we change the libstdc++.so major version number to 7. I don't speak for the other libstdc++ maintainers, but I think that's a great idea.

Re: Using C++ in GCC is OK

2010-06-04 Thread Mark Mitchell
Joseph S. Myers wrote: I repeat my request from the RM QA for a guide for reviewers on how to detect hidden overhead in the presence of C++ features. When will a structure/class/union be larger than might be expected in C? When will C++ statements involve runtime overhead that might not

Re: Using C++ in GCC is OK

2010-06-04 Thread Jeff Law
On 06/04/10 18:48, Mark Mitchell wrote: In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. And, in general, we are trying to avoid

Re: Using C++ in GCC is OK

2010-06-04 Thread Mark Mitchell
Jeff Law wrote: In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. And, in general, we are trying to avoid situations where

Re: Using C++ in GCC is OK

2010-06-04 Thread Gabriel Dos Reis
On Fri, Jun 4, 2010 at 7:55 PM, Jeff Law l...@redhat.com wrote: On 06/04/10 18:48, Mark Mitchell wrote:   In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you

Re: Poor internal documentation (was: dragonegg in FSF gcc?)

2010-06-04 Thread Philipp Thomas
On Fri, 23 Apr 2010 16:23:29 +0200, Manuel López-Ibáñez lopeziba...@gmail.com wrote: Great! Go ahead, please. The wiki is easy to edit. Finally I got around to do it. Editing is easy ... kind of :) Creating the Links was easy but I failed do discover how I could actually make them point to

[Bug libfortran/34670] bounds checking for array intrinsics

2010-06-04 Thread tkoenig at gcc dot gnu dot org
--- Comment #17 from tkoenig at gcc dot gnu dot org 2010-06-04 06:50 --- Subject: Bug 34670 Author: tkoenig Date: Fri Jun 4 06:50:11 2010 New Revision: 160253 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160253 Log: 2010-06-04 Thomas Koenig tkoe...@gcc.gnu.org PR

[Bug libfortran/34670] bounds checking for array intrinsics

2010-06-04 Thread tkoenig at gcc dot gnu dot org
--- Comment #18 from tkoenig at gcc dot gnu dot org 2010-06-04 06:51 --- Fixed (finally). Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/44156] dot_product / matmul and signed zeros

2010-06-04 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2010-06-04 07:06 --- After the discussion, I think we can close this as WONTFIX. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association

2010-06-04 Thread tkoenig at gcc dot gnu dot org
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-06-04 07:15 --- Can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452

[Bug middle-end/42505] [4.4/4.5/4.6 Regression] loop canonicalization causes a lot of unnecessary temporary variables

2010-06-04 Thread steven at gcc dot gnu dot org
--- Comment #5 from steven at gcc dot gnu dot org 2010-06-04 07:45 --- AFAIU, you can't randomly change signed to unsigned, due to different overflow semantics, which is why IVOPTS doesn't make this change itself. Imagine you enter the loop with count = 0, and with a second counter

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread jakub at gcc dot gnu dot org
--- Comment #30 from jakub at gcc dot gnu dot org 2010-06-04 09:02 --- Created an attachment (id=20833) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20833action=view) rh598310.i.bz2 Another testcase from wine, ./cc1 -m32 -fPIC -fno-strict-aliasing -g -O2 rh598310.i -quiet takes

[Bug middle-end/42505] [4.4/4.5/4.6 Regression] loop canonicalization causes a lot of unnecessary temporary variables

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-04 09:08 --- If the result of the conversion is only used in an exit equality test against a constant it can be dropped. This could also happen in a following forwprop run which is our single tree-combiner (though that

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread jakub at gcc dot gnu dot org
--- Comment #31 from jakub at gcc dot gnu dot org 2010-06-04 09:24 --- Created an attachment (id=20834) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20834action=view) limit-depth.patch Quick patch that brings the time down to 1 minute 15 sec. From the callgrind dump on this

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread jakub at gcc dot gnu dot org
--- Comment #32 from jakub at gcc dot gnu dot org 2010-06-04 09:30 --- Created an attachment (id=20835) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20835action=view) hack Hack that shows that the maximum depth is 3 even for the found == NULL cases. Alex tells me on IRC he has

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread aoliva at gcc dot gnu dot org
--- Comment #33 from aoliva at gcc dot gnu dot org 2010-06-04 09:51 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned

[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target

2010-06-04 Thread doko at ubuntu dot com
--- Comment #2 from doko at ubuntu dot com 2010-06-04 09:51 --- having an objdump which supports both the host and the target works around this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847

[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin

2010-06-04 Thread doko at ubuntu dot com
--- Comment #4 from doko at ubuntu dot com 2010-06-04 09:53 --- this is fixed on the trunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread aoliva at gcc dot gnu dot org
--- Comment #34 from aoliva at gcc dot gnu dot org 2010-06-04 10:03 --- Created an attachment (id=20836) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20836action=view) Patch that fixes the bug and verifies recursion is bounded as expected This patch (except for comments and

[Bug lto/44408] FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-04 11:00 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug lto/41584] WHOPR doesn't grok empty units

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-04 11:00 --- Subject: Bug 41584 Author: rguenth Date: Fri Jun 4 11:00:09 2010 New Revision: 160258 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160258 Log: 2010-06-04 Richard Guenther rguent...@suse.de PR

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-06-04 11:03 --- Created an attachment (id=20837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20837action=view) bnc611650 Another testcase from open-office this time, on i?86-linux only. $ time g++ -c -g -Os

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread jakub at gcc dot gnu dot org
--- Comment #36 from jakub at gcc dot gnu dot org 2010-06-04 11:15 --- With Alex' patch with checking guarded with #ifdef ENABLE_CHECKING (currently bootstrapping/regtesting that) I see on x86_64 on the trunk: time ./cc1plus -m32 -quiet -g -Os -fomit-frame-pointer bug-611650_analysis.ii

[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning

2010-06-04 Thread jakub at gcc dot gnu dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-04 12:03 --- More complete testcase: // PR c++/44412 // { dg-do compile } // { dg-options -Wunused } struct S { static const int a = 3; static int b; int c; }; const int S::a; int S::b = 4; int f1 () { S s; return

[Bug libstdc++/44413] New: inefficient code for std::string::compare on x86-64

2010-06-04 Thread dgohman at gmail dot com
This code: #include string int foo(const std::string a, const std::string b) { return a.compare(b); } compiles to code like this on x86-64: [...] subq%rdx, %r8 movl$2147483647, %eax cmpq$2147483647, %r8 jg .L2 movl$-2147483648, %eax

[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association

2010-06-04 Thread burnus at gcc dot gnu dot org
--- Comment #6 from burnus at gcc dot gnu dot org 2010-06-04 12:22 --- Yes, we can CLOSE the bug as FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/44414] New: hashtab.h functions are undocumented

2010-06-04 Thread ro at gcc dot gnu dot org
When I recently needed to use htab_* functions from libiberty's hashtab.h, I found that they are completely undocumented: the comments in the header aren't enough to use them, so I had to look at both the implementation and other uses to figure things out. -- Summary: hashtab.h

[Bug other/44414] hashtab.h functions are undocumented

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-04 12:32 --- libiberty has documentation in source libiberty/hashtab.c. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug libgcj/44415] New: [4.6 regression] gmp multilib support broke bootstrap with static libgmp

2010-06-04 Thread ro at gcc dot gnu dot org
The recent introduction of this patch 2010-05-29 Mike Stump mikest...@comcast.net * configure.ac: Add multilib support for gmp. Proper -I and -L flags for gmp are added. broke bootstrap on i386-pc-solaris2.11 and almost certainly at least all Solaris 2 platforms with a static

[Bug rtl-optimization/42502] [4.4/4.5/4.6 Regression] Bad register allocation in a very simple code

2010-06-04 Thread bernds at gcc dot gnu dot org
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 42502 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR

[Bug rtl-optimization/42500] Unnecessary mov of sp to a register

2010-06-04 Thread bernds at gcc dot gnu dot org
--- Comment #6 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 42500 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR

[Bug rtl-optimization/39871] [4.3/4.4/4.5/4.6 regression] Code size increase on ARM due to poor register allocation

2010-06-04 Thread bernds at gcc dot gnu dot org
--- Comment #24 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 39871 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR

[Bug rtl-optimization/40615] unnecessary CSE

2010-06-04 Thread bernds at gcc dot gnu dot org
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 40615 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-06-04 12:45 --- Subject: Bug 41371 Author: rguenth Date: Fri Jun 4 12:44:41 2010 New Revision: 160261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160261 Log: 2010-06-04 Richard Guenther rguent...@suse.de

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

2010-06-04 Thread rguenth at gcc dot gnu dot org
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

2010-06-04 Thread ro at gcc dot gnu dot org
--- Comment #16 from ro at gcc dot gnu dot org 2010-06-04 12:53 --- Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9. -- ro at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/44414] hashtab.h functions are undocumented

2010-06-04 Thread ro at gcc dot gnu dot org
--- Comment #2 from ro at gcc dot gnu dot org 2010-06-04 12:58 --- This is not proper documentation: most part of libiberty use comments which can be extracted and put into the .texi files, while hashtab.c does not. -- ro at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/44382] Slow integer multiply

2010-06-04 Thread hjl dot tools at gmail dot com
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-04 13:08 --- (In reply to comment #1) Because our tree reassoc doesn't re-associate them. The tree reassoc pass makes it slower: [...@gnu-6 44382]$ cat x.i extern int a, b, c, d, e, f; void foo () { a = (b * c) * (d * e);

[Bug c++/26256] ignores using declaration

2010-06-04 Thread fabien at gcc dot gnu dot org
-- fabien at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot |dot org

[Bug middle-end/44382] Slow integer multiply

2010-06-04 Thread rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-04 13:21 --- Yes, reassoc linearizes instead of building a tree (saves one (or was it two?) registers at best). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382

[Bug middle-end/44416] New: [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread hjl dot tools at gmail dot com
On Linux/x86-64, revision 160243 failed to build 447.dealII in SPEC CPU 2006 at -O2 and -O3: g++ -c -o block_vector.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3 -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 block_vector.cc In file included from

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread hjl dot tools at gmail dot com
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread hjl dot tools at gmail dot com
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-04 13:26 --- It may be caused by revision 160231: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00144.html -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-04 13:42 --- I do not have access to those benchmarks. Whoever has, should check that ptrdiff_t is used properly, either after including cstddef, then it can be used both qualified with std:: and unqualified together with

[Bug libstdc++/44417] New: make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread singler at kit dot edu
make check-target-libstdc++-v3 fails because ptrdiff_t is undefined. std::ptrdiff_t works. Maybe this bug is related to the Linux system run on. I have openSuse 11.1 running. configure --enable-languages=c,c++ --program-suffix=-rep --prefix=$HOME/gcc/install_trunk_1 In file included from

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-04 13:49 --- I can't reproduce this. I booted and tested many times on various linux systems and HJ already reported many succesfull testresults since. Please remove everything from the build dir, gave everything fresh and

[Bug middle-end/44382] Slow integer multiply

2010-06-04 Thread hjl dot tools at gmail dot com
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-04 13:56 --- (In reply to comment #3) Yes, reassoc linearizes instead of building a tree (saves one (or was it two?) registers at best). Should we always build a tree? It may increase register pressure. --

[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning

2010-06-04 Thread jakub at gcc dot gnu dot org
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-04 14:12 --- Created an attachment (id=20838) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20838action=view) gcc46-pr44412.patch Untested patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread singler at kit dot edu
--- Comment #2 from singler at kit dot edu 2010-06-04 14:16 --- I had cleaned the builddir already. Adding #include cstddef solves the problem. The crucial file seems to be lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/stddef.h Only if it is (indirectly) included, ptrdiff_t is

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread singler at kit dot edu
--- Comment #3 from singler at kit dot edu 2010-06-04 14:19 --- Bug 44417 is very likely to have the same cause, but here, we can reproduce it more easily, using the testsuite. *** This bug has been marked as a duplicate of 44417 *** -- singler at kit dot edu changed:

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread singler at kit dot edu
--- Comment #3 from singler at kit dot edu 2010-06-04 14:19 --- *** Bug 44416 has been marked as a duplicate of this bug. *** -- singler at kit dot edu changed: What|Removed |Added

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-04 14:23 --- To be clear: does a normal 'make check' (either from the root of the build dir or from inside the library build dir) work? Because it works here and fo everybody else on the testresult mailing list, also for

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-04 14:28 --- Hey, 44416 is *not* a duplicate! Please re-open it immediately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-04 14:29 --- Not a duplicate, another issue. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

2010-06-04 Thread ro at gcc dot gnu dot org
--- Comment #49 from ro at gcc dot gnu dot org 2010-06-04 14:33 --- Subject: Bug 42776 Author: ro Date: Fri Jun 4 14:32:19 2010 New Revision: 160269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160269 Log: Backport from mainline: 2010-04-27 Dave Korn

[Bug middle-end/44382] Slow integer multiply

2010-06-04 Thread hjl dot tools at gmail dot com
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-04 14:40 --- tree-ssa-reassoc.c has 2. Left linearization of the expression trees, so that (A+B)+(C+D) becomes (((A+B)+C)+D), which is easier for us to rewrite later. During linearization, we place the operands of

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-04 14:52 --- Note that cxxabi.h already includes stddef.h and at that line 371 uses ptrdiff_t unqualified, thus everything is fine. I suspect you simply forgot to update your compiler, because the current library does not

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

2010-06-04 Thread paolo dot carlini at oracle dot com
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-04 14:55 --- Closing. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread jwakely dot gcc at gmail dot com
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-06-04 14:56 --- I don't have the SPEC benchmarks either, but probably deal.II uses ptrdiff_t unqualified, without explicitly including either cstddef or stddef.h

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread jwakely dot gcc at gmail dot com
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-06-04 15:00 --- certainly true for an older version http://ganymed.iwr.uni-heidelberg.de/~deal/5.2.0/doxygen/deal.II/block__vector_8h.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416

[Bug c/25880] improve message of warning for discarding qualifiers

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-04 15:16 --- Subject: Bug 25880 Author: manu Date: Fri Jun 4 15:15:38 2010 New Revision: 160274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160274 Log: 2010-06-04 Manuel López-Ibáñez m...@gcc.gnu.org PR

[Bug lto/40702] lto-elf.c fails to compile on Solaris

2010-06-04 Thread ro at CeBiTec dot Uni-Bielefeld dot DE
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-04 15:21 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-03 13:47 --- The problem seems to have vanished, so eventually the fix can be

[Bug c/25880] improve message of warning for discarding qualifiers

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-04 15:21 --- The infrastructure to enable this has been added in GCC 4.6 and some diagnostics are already making use of it, in particular the one reported here. So I consider this FIXED. If anyone finds particular diagnostics

[Bug c++/44244] Provide -f flags to turn on individual C++0x features

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-04 15:50 --- I am going to close this as WONTFIX for the following reasons: * We do not want this because: a) We have too many options. b) These options would be of very limited and temporary use but we will have to support

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-04 15:56 --- Hi Jay, -Wuninitialized is quite unreliable in old compilers and also we do not know what patches Apple applies to its copy of GCC. This is why -Werror is not used in the first stage of building GCC. We do not see

[Bug web/44269] Search for PR number in mailing lists fails

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-04 15:59 --- Who is in charge of GCC infrastructure (wiki, mailing lists, bugzilla)? I am afraid there is no one, so this is not going to be fixed soon. Meanwhile use Google. -- manu at gcc dot gnu dot org changed:

[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-04 16:03 --- As mentioned in the comments above, there is an easy way to achieve this already without needing to make the compiler more complex and slower. So I will close this as WONTFIX. -- manu at gcc dot gnu dot org

[Bug c++/44172] Compiling never ends

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-04 16:11 --- Please fellow GCC maintainers, after checking that a bug is indeed a bug, please set the status to NEW. What more than 1000 unconfirmed reports! -- manu at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

2010-06-04 Thread jay dot krell at cornell dot edu
--- Comment #5 from jay dot krell at cornell dot edu 2010-06-04 16:20 --- Then don't use when I -disable-bootstrap.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

2010-06-04 Thread manu at gcc dot gnu dot org
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-04 16:22 --- (In reply to comment #5) Then don't use when I -disable-bootstrap.. Do you mean that -Werror is used when you disable-bootstrap? If so, I think that is a bug. Or you mean to not use warnings? I think that would be

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

2010-06-04 Thread jay dot krell at cornell dot edu
--- Comment #7 from jay dot krell at cornell dot edu 2010-06-04 16:30 --- I mean -Wuninitialized. -Werror is already omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

2010-06-04 Thread bangerth at gmail dot com
--- Comment #7 from bangerth at gmail dot com 2010-06-04 16:36 --- As the author of the benchmark I can confirm that we apparently forgot to include the proper header file. So you can call it a defect in 447.dealII. The question is how to deal with this, of course. W. -- bangerth

  1   2   >