Re: Using C++ in GCC is OK
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 where appropriate that is the sneaky detail here :-) You're quite right. Perhaps I should have written where appropriate, in the course of making changes or additions for reasons not related simply to a change of language. Or something. :-) Andrew.
Puzzle about macro MIPS_PROLOGUE_TEMP_REGNUM
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 starting from $3? in my application, I have to save DFmode fpu regs through gpr regs, that is $3,$4 in this case, just like : mfc1 $3, $fpr sw $3, addr mfc1 $4, $fpr+1 sw $4, addr+4 apparently this would crush the argument in $4. Here is question, why don't use $8 for MIPS_PROLOGUE_TEMP_REGNUM like EPILOGUE_TEMP? Or have I done something wrong? So, any clarification? Thanks in advance. -- Best Regards.
Re: [x86]: Allow @GOTOFF in non-memory context?
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 documentation, the lowest mentioned version is 2.13.1. I have no idea, if this version supports above asm, so I would like to ask someone with access to this ancient version if he can test this instruction. Also of interest is support from sun as and darwin assembler for similar instructions. I guess darwin should check something like: addl L_x$non_lazy_ptr-L001$pb(%ecx), %eax Ultimately, I would like to remove checks involving pic_symbolic_operands, but removing them on 64bit would be OK, too. Sun as from Solaris 8 onward (32-bit case) resp. Solaris 10 onward (64-bit case) handle those two cases identically to gas 2.15/2.10. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Using C++ in GCC is OK
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 polymorphism to make frameworks. All kinds of pluggable frameworks. And as polymorphism goes, virtual functions are pretty cheap. Agreed; however, according the the 2nd link I provided: http://lists.boost.org/Archives/boost/2008/01/132074.php apparently speed is more important, and the 1st link: http://sourceforge.net/mailarchive/message.php?msg_name=3f49a9f41003031715g19a23b94p47ccec2251acd55%40mail.gmail.com suggested that the author had experienced problems with using switch vs virtual functions: P.P.S. Yes, the design you are using is a sore spot for me, I was bit with such things many years ago, it is one of my quests to educate people about the better ways now. I'd had some experience with compilers written in c++ that had large switch statements and wondered why the authors hadn't used virtual functions. IOW, I believed as you do; however, OvermindDl1's post caused me some doubt. I even checked clang's code to see if they used switch's or virtual functions and was surprised to learn they used switch's: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Analysis/CFG.cpp (in particular, the CFGBuilder::Visit function). Hence, I figured there must be something I'm missing about the pros and cons of switch's vs virtual functions. -regards, Larry
Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10
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
`print_operand'
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1
The sparc build fails like so:
libbackend.a(targhooks.o): In function `default_print_operand_address':
/export/home/arth/src/gcc.git/gcc/targhooks.c:349: undefined reference to
`output_operand'
/export/home/arth/src/gcc.git/gcc/targhooks.c:349: undefined reference to
`output_operand'
collect2: ld returned 1 exit status
gmake[3]: *** [cc1-dummy] Error 1
This patch is the likely culprit:
2010-06-03 Nathan Froyd froy...@codesourcery.com
* final.c (output_asm_insn): Call
targetm.asm_out.print_operand_punct_valid_p. Update comments.
(output_operand): Call targetm.asm_out.print_operand. Update comments.
(output_address): Call targetm.asm_out.print_operand_address.
Update comments.
* target.h (struct gcc_target): Add print_operand,
print_operand_address, and print_operand_punct_valid_p fields.
{ ... snip ... }
My builds from yesterday morning both completed without problems.
Art Haas
Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10
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'
/home/ahaas/gnu/gcc.git/gcc/config/sol2.c:116: undefined reference to
`print_operand'
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1
The sparc build fails like so:
libbackend.a(targhooks.o): In function `default_print_operand_address':
/export/home/arth/src/gcc.git/gcc/targhooks.c:349: undefined reference to
`output_operand'
/export/home/arth/src/gcc.git/gcc/targhooks.c:349: undefined reference to
`output_operand'
collect2: ld returned 1 exit status
gmake[3]: *** [cc1-dummy] Error 1
Whoops, sorry about that. This patch fixes at least the sparc error
(successfully built a cross to sparc-solaris) and I'm in the process of
building a cross to i686-solaris.
OK to commit if compilation succeeds?
-Nathan
* 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.
* final.c (output_operand): Make non-static.
Index: final.c
===
--- final.c (revision 160266)
+++ final.c (working copy)
@@ -220,7 +220,6 @@ static void output_asm_name (void);
static void output_alternate_entry_point (FILE *, rtx);
static tree get_mem_expr_from_op (rtx, int *);
static void output_asm_operand_names (rtx *, int *, int);
-static void output_operand (rtx, int);
#ifdef LEAF_REGISTERS
static void leaf_renumber_regs (rtx);
#endif
@@ -3478,7 +3477,7 @@ mark_symbol_refs_as_used (rtx x)
The meanings of the letters are machine-dependent and controlled
by TARGET_PRINT_OPERAND. */
-static void
+void
output_operand (rtx x, int code ATTRIBUTE_UNUSED)
{
if (x GET_CODE (x) == SUBREG)
Index: ChangeLog
===
Index: rtl.h
===
--- rtl.h (revision 160266)
+++ rtl.h (working copy)
@@ -2417,6 +2417,7 @@ extern void simplify_using_condition (rt
/* In final.c */
extern unsigned int compute_alignments (void);
extern int asm_str_count (const char *templ);
+extern void output_operand (rtx, int);
struct rtl_hooks
{
Index: config/i386/sol2.h
===
--- config/i386/sol2.h (revision 160266)
+++ config/i386/sol2.h (working copy)
@@ -145,7 +145,7 @@ along with GCC; see the file COPYING3.
do \
{ \
fprintf (FILE, \tcall\t); \
- print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
+ ix86_print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
fprintf (FILE, \n);\
} \
while (0)
Index: config/i386/i386-protos.h
===
--- config/i386/i386-protos.h (revision 160266)
+++ config/i386/i386-protos.h (working copy)
@@ -60,6 +60,7 @@ extern bool legitimate_pic_operand_p (rt
extern int legitimate_pic_address_disp_p (rtx);
extern void print_reg (rtx, int, FILE*);
+extern void ix86_print_operand (FILE *, rtx, int);
extern bool output_addr_const_extra (FILE*, rtx);
extern void split_di (rtx[], int, rtx[], rtx[]);
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 160266)
+++ config/i386/i386.c (working copy)
@@ -11579,7 +11579,7 @@ get_some_local_dynamic_name (void)
; -- print a semicolon (after prefixes due to bug in older gas).
*/
-static void
+void
ix86_print_operand (FILE *file, rtx x, int code)
{
if (code)
Re: Puzzle about macro MIPS_PROLOGUE_TEMP_REGNUM
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 + 3) I don't understand why using registers starting from $3? in my application, I have to save DFmode fpu regs through gpr regs, that is $3,$4 in this case, just like : mfc1 $3, $fpr sw $3, addr mfc1 $4, $fpr+1 sw $4, addr+4 apparently this would crush the argument in $4. Why not use $3 in all cases? Why switch to $4? why don't use $8 for MIPS_PROLOGUE_TEMP_REGNUM like EPILOGUE_TEMP? $8 can hold an argument value. I think $13 would be a possibility, but I don't see anything wrong with $3. Ian
Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10
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. * final.c (output_operand): Make non-static. The changes in config/i386 are OK. I don't understand the point of the changes to rtl.h and final.c. Thanks. Ian
Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10
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 ix86_print_operand. * rtl.h (output_operand): Declare. * final.c (output_operand): Make non-static. The changes in config/i386 are OK. I don't understand the point of the changes to rtl.h and final.c. The changes to rtl.h and final.c are necessary because PRINT_OPERAND* on some platforms freely calls output_operand. But now that PRINT_OPERAND* has been hookized, that call to output_operand no longer appears textually in final.c, but somewhere else (targhooks.c if the port has not done the conversion PRINT_OPERAND* - TARGET_PRINT_OPERAND*, config/$PORT/$PORT.c if the port has), output_operand needs to be exported. Looking at things a little more closely, output_address is exported in output.h. I suppose output_operand should be exported there as well? -Nathan
Re: Using C++ in GCC is OK
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. Diego.
Re: Using C++ in GCC is OK
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
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. * config/i386/sol2.h (ASM_OUTPUT_CALL): Call ix86_print_operand. * rtl.h (output_operand): Declare. * final.c (output_operand): Make non-static. The changes in config/i386 are OK. I don't understand the point of the changes to rtl.h and final.c. The changes to rtl.h and final.c are necessary because PRINT_OPERAND* on some platforms freely calls output_operand. But now that PRINT_OPERAND* has been hookized, that call to output_operand no longer appears textually in final.c, but somewhere else (targhooks.c if the port has not done the conversion PRINT_OPERAND* - TARGET_PRINT_OPERAND*, config/$PORT/$PORT.c if the port has), output_operand needs to be exported. I get it. 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 output_operand_lossage. Thanks. Ian
Re: [RFC] Switching implementation language to C++
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) will continue to exist in C. But I would believe that a future GCC with only a C++ frontend and without a C frontend would be possible, and be able to bootstrap (i.e. make stage3), which is not true today. IIRC, today's GCC (i.e. 4.5) cannot even be configured to have a C++ front-end without having a C front-end. Do we want to change that? I believe it would be a bad idea to change GCC's language-independent runtime libraries (libgcc etc.) and libraries for ObjC, Fortran etc. to use C++. As such, building the C compiler will continue to be required in order to build those libraries. (It should also continue to be possible to build a cross compiler that only supports C - using, of course, pre-installed build-x-build and build-x-host C++ compilers - rather than requiring C++ support to be built for the target; the requirement to build a C++ host-x-target compiler will only apply for native bootstrap.) -- Joseph S. Myers jos...@codesourcery.com
Re: Vector indexing patch
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 implement. The original patch had documentation. You should not make patches worse in the course of reworking or updating them; documentation is required for all patches with user-visible features. The original also had ChangeLog entries following the usual conventions; please make sure to follow the style of existing entries. Since I previously approved the C changes in http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00562.html, and do not wish to duplicate review effort, I am not inclined to review any reworked patch without adequate explanation of what was changed from the approved version and why it needed to be changed. The initial basis should be to make only those changes to the approved patch that are strictly necessary to update it to newer sources or to fix bugs, so that only those clearly identified changes, and any parts not previously reviewed, need to be reviewed this time. -- Joseph S. Myers jos...@codesourcery.com
Auto-generated cross-references can be distributed under the GPL
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 particular: is it OK to have documentation that is not under the GFDL in GCC? Of course, this cross-reference documentation cannot be combined with GFDL documentation to form a single manual. But, if we want to generate/ship internal API documentation, or plugin API documentation, in this form, we can do so. (I understand, of course, that the libstdc++ team has been doing this for some time.) 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 using the permission given above to generate a separate document, though.) I will continue to work on the GPL-GFDL issue as best I can, but my expectation is that getting general permission regarding use of GPL'd code to generate GFDL'd documentation, including the right for downstream recipients to regenerate the documentation, will take a long time. I'm disappointed to see these islands (GPLv2 vs. GPLv3 vs. GFDL) of code and documentation that cannot be combined, but that seems to be the state of the world. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10
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 output_operand_lossage.
This is what I committed.
-Nathan
* 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.
* output.h (output_operand): Declare.
* final.c (output_operand): Make non-static.
Index: final.c
===
--- final.c (revision 160285)
+++ final.c (working copy)
@@ -220,7 +220,6 @@ static void output_asm_name (void);
static void output_alternate_entry_point (FILE *, rtx);
static tree get_mem_expr_from_op (rtx, int *);
static void output_asm_operand_names (rtx *, int *, int);
-static void output_operand (rtx, int);
#ifdef LEAF_REGISTERS
static void leaf_renumber_regs (rtx);
#endif
@@ -3478,7 +3477,7 @@ mark_symbol_refs_as_used (rtx x)
The meanings of the letters are machine-dependent and controlled
by TARGET_PRINT_OPERAND. */
-static void
+void
output_operand (rtx x, int code ATTRIBUTE_UNUSED)
{
if (x GET_CODE (x) == SUBREG)
Index: ChangeLog
===
Index: output.h
===
--- output.h(revision 160285)
+++ output.h(working copy)
@@ -77,6 +77,9 @@ extern rtx final_scan_insn (rtx, FILE *,
subreg of. */
extern rtx alter_subreg (rtx *);
+/* Print an operand using machine-dependent assembler syntax. */
+extern void output_operand (rtx, int);
+
/* Report inconsistency between the assembler template and the operands.
In an `asm', it's the user's fault; otherwise, the compiler's fault. */
extern void output_operand_lossage (const char *, ...) ATTRIBUTE_PRINTF_1;
Index: config/i386/sol2.h
===
--- config/i386/sol2.h (revision 160285)
+++ config/i386/sol2.h (working copy)
@@ -145,7 +145,7 @@ along with GCC; see the file COPYING3.
do \
{ \
fprintf (FILE, \tcall\t); \
- print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
+ ix86_print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
fprintf (FILE, \n);\
} \
while (0)
Index: config/i386/i386-protos.h
===
--- config/i386/i386-protos.h (revision 160285)
+++ config/i386/i386-protos.h (working copy)
@@ -60,6 +60,7 @@ extern bool legitimate_pic_operand_p (rt
extern int legitimate_pic_address_disp_p (rtx);
extern void print_reg (rtx, int, FILE*);
+extern void ix86_print_operand (FILE *, rtx, int);
extern bool output_addr_const_extra (FILE*, rtx);
extern void split_di (rtx[], int, rtx[], rtx[]);
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 160285)
+++ config/i386/i386.c (working copy)
@@ -11579,7 +11579,7 @@ get_some_local_dynamic_name (void)
; -- print a semicolon (after prefixes due to bug in older gas).
*/
-static void
+void
ix86_print_operand (FILE *file, rtx x, int code)
{
if (code)
Re: Using C++ in GCC is OK
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 I can see no good reason to convert existing comments. The same applies to all other aspects of formatting that are meaningful for both C and C++ code (such as the presence or position of whitespace in various cases): keep the existing practice that is usual for C code in GCC and the GNU project rather than adopting something else because it is said to be conventional for C++. -- Joseph S. Myers jos...@codesourcery.com
Re: Auto-generated cross-references can be distributed under the GPL
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 using the permission given above to generate a separate document, though.) A separate document for target hooks would make the documentation substantially worse, since target hooks are often created from target macros (so reusing the GFDL documentation for those macros) and logically should be documented alongside related macros. I will continue to work on the GPL-GFDL issue as best I can, but my expectation is that getting general permission regarding use of GPL'd code to generate GFDL'd documentation, including the right for downstream recipients to regenerate the documentation, will take a long I don't mind the intermediate stage (as in Joern's patch) where the generated GFDL files need to be checked in, as an improvement on the present state, but avoiding the need for them to be checked in while allowing downstream recipients to generate them would still seem to be the desired end state. -- Joseph S. Myers jos...@codesourcery.com
Re: Time to create wwwdocs/htdocs/gcc-4.6?
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 never has been the tools, it is needing someone to convert the post-checkin hooks. -- Joseph S. Myers jos...@codesourcery.com
Re: GFDL/GPL Issue
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 Sections (at least as regards inclusion of the GPL in manuals) are http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Documentation.html. There are various ways in which the GCC manuals do not follow this (e.g. having Cover Texts on manuals the FSF does not print that are only meant to be on printed manuals, or including the GPL in manuals under 400 pages). But getting approval to fix those issues might also require adding the Free Software and Free Manuals invariant section (see comments in PR 13573), which in general those who don't like invariant sections aren't going to like. -- Joseph S. Myers jos...@codesourcery.com
RE: Using C++ in GCC is OK
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 an implementation detail can't justify such a change. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Switching implementation language to C++
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 options --with-host-libstdcxx, --with-stage1-ldflags, --with-stage1-libs, --with-boot-ldflags, --with-boot-libs, which certainly allow you to do as you wish for cross compilers (you only need --with-host-libstdcxx there) and probably for other configurations, but maybe the defaults are currently wrong. There are at least three useful cases for native compilers (link statically, link dynamically, link dynamically with an RPATH using $ORIGIN); the last is probably the trickiest because of getting that $ through a series of levels of shell and make. -- Joseph S. Myers jos...@codesourcery.com
Re: Using C++ in GCC is OK
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 option is an important piece to get in early before many C++ changes are made. I propose GCC 4.1 as the baseline GCC version that should be able to build versions of GCC built as C++. (PPL requires at least 4.0 so anyone building a Graphite-enabled compiler will have a 4.0 or later C++ compiler for the host, and 4.1 was more widely used than 4.0.) In addition to what I said about avoiding any bulk changes to formatting conventions, I think there should be a principle that changes of existing code to use C++ features should generally improve the maintainability and comprehensibility of the code. Conversion to standard C++ features where macros are used to emulate e.g. templates (STL or otherwise) or inheritance is much more desirable than converting qsort calls to std::sort since qsort is a well-understood standard C feature rather than a pile of GCC-specific macros. 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 be expected from equivalent C statements? -- Joseph S. Myers jos...@codesourcery.com
Re: Vector indexing patch
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? Is this implementing the extension more accurately, or deliberately deviating from it? Either may be OK - if properly justified. Artem is one of our Goole Summer of Code students btw., and I requested these changes. Details of the request? Again, I'd like (once the copyright assignment is complete) to understand what changed from the previous patch and why. This patch submission does not make things easy to review; exact URLs for the previous rounds of discussion are helpful when dealing with a patch that has undergone multiple past reviews long ago. (The opposite error is only giving URLs without a self-contained explanation of what the resubmission is about; this submission avoids that particular problem, although the Cell document would still seem to be relevant in understanding the rationale for the patch.) -- Joseph S. Myers jos...@codesourcery.com
Re: Using C++ in GCC is OK
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 http://gcc.gnu.org/ml/gcc/2004-06/msg00243.html on version numbers; certainly an implementation detail can't justify such a change. I think we should change the gcc major release to 5 when we change the libstdc++.so major version number to 7. Ian
RE: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10
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 sparc-sun-solaris2.10
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 output_operand_lossage.
This is what I committed.
-Nathan
* 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.
* output.h (output_operand): Declare.
* final.c (output_operand): Make non-static.
Index: final.c
===
--- final.c (revision 160285)
+++ final.c (working copy)
@@ -220,7 +220,6 @@ static void output_asm_name (void);
static void output_alternate_entry_point (FILE *, rtx);
static tree get_mem_expr_from_op (rtx, int *);
static void output_asm_operand_names (rtx *, int *, int);
-static void output_operand (rtx, int);
#ifdef LEAF_REGISTERS
static void leaf_renumber_regs (rtx);
#endif
@@ -3478,7 +3477,7 @@ mark_symbol_refs_as_used (rtx x)
The meanings of the letters are machine-dependent and controlled
by TARGET_PRINT_OPERAND. */
-static void
+void
output_operand (rtx x, int code ATTRIBUTE_UNUSED)
{
if (x GET_CODE (x) == SUBREG)
Index: ChangeLog
===
Index: output.h
===
--- output.h(revision 160285)
+++ output.h(working copy)
@@ -77,6 +77,9 @@ extern rtx final_scan_insn (rtx, FILE *,
subreg of. */
extern rtx alter_subreg (rtx *);
+/* Print an operand using machine-dependent assembler syntax. */
+extern void output_operand (rtx, int);
+
/* Report inconsistency between the assembler template and the operands.
In an `asm', it's the user's fault; otherwise, the compiler's fault. */
extern void output_operand_lossage (const char *, ...) ATTRIBUTE_PRINTF_1;
Index: config/i386/sol2.h
===
--- config/i386/sol2.h (revision 160285)
+++ config/i386/sol2.h (working copy)
@@ -145,7 +145,7 @@ along with GCC; see the file COPYING3.
do \
{ \
fprintf (FILE, \tcall\t); \
- print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
+ ix86_print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
fprintf (FILE, \n);\
} \
while (0)
Index: config/i386/i386-protos.h
===
--- config/i386/i386-protos.h (revision 160285)
+++ config/i386/i386-protos.h (working copy)
@@ -60,6 +60,7 @@ extern bool legitimate_pic_operand_p (rt
extern int legitimate_pic_address_disp_p (rtx);
extern void print_reg (rtx, int, FILE*);
+extern void ix86_print_operand (FILE *, rtx, int);
extern bool output_addr_const_extra (FILE*, rtx);
extern void split_di (rtx[], int, rtx[], rtx[]);
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 160285)
+++ config/i386/i386.c (working copy)
@@ -11579,7 +11579,7 @@ get_some_local_dynamic_name (void)
; -- print a semicolon (after prefixes due to bug in older gas).
*/
-static void
+void
ix86_print_operand (FILE *file, rtx x, int code)
{
if (code)
Re: Using C++ in GCC is OK
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
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
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
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 be expected from equivalent C statements? I think you're being unnecessarily fearful. A C++ structure/class/union will be larger than the same data structure written in C iff (a) it uses virtual functions, (b) it uses virtual inheritance. The former adds exactly one pointer to the very beginning of the structure, independent of the number of virtual functions, and even if there is (non-virtual) inheritance. The latter is forbidden by Ian's proposed coding standards. So, you do indeed want to avoid virtual functions in small, plentiful objects, as it can make them much bigger. Statements in the C subset of C++ have the same performance they would in C. (I'm sure someone can come up with an exception, but it will be vanishingly rare.) 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 +. But, if you just recompile your C program as C++, it doesn't suddenly get significantly bigger or slower. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
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 situations where seemingly simple code does something expensive, right? Jeff
Re: Using C++ in GCC is OK
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 seemingly simple code does something expensive, right? Right. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
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 have overloaded +. And, in general, we are trying to avoid situations where seemingly simple code does something expensive, right? Yes. I trust reviewers to spot instances where people are being creative with expensive operations. -- Gaby
Re: Poor internal documentation (was: dragonegg in FSF gcc?)
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 other wiki pages. Bonus points if you collect there links to the existing documentation, so anyone wishing to help has the many sources at hand. Maybe I will find the time but I doubt that. Philipp
[Bug libfortran/34670] bounds checking for array intrinsics
--- 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 libfortran/34670 * intrinsics/date_and_time.c: Replace assert with runtime_error when VALUE is too small. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/date_and_time.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug libfortran/34670] bounds checking for array intrinsics
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug fortran/44156] dot_product / matmul and signed zeros
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association
--- 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
--- 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 hidden in func. You will not get the same number of iterations if you change the type of count from int to unsigned int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 here over 7 minutes, again most of the time spent in find_loc_in_1pdv called from intersect_loc_chains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug middle-end/42505] [4.4/4.5/4.6 Regression] loop canonicalization causes a lot of unnecessary temporary variables
--- 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 currently will combine into comparisons only if the result will be a constant, it doesn't treat defs with a single use specially which it could, if the combined constant is in gimple form). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 testcase, intersect_loc_chains in 5159260x cases calls insert_into_intersection in the first loop (i.e. where the recent patch from this PR helps), then calls 320611x find_loc_in_1pdv. Out of these calls, 75537x it returns NULL and the rest of time it returns non-NULL. When it returns non-NULL, it is possible to return non-NULL without recursion 244863x, with one level of find_loc_in_1pdv recursion 205x and with two level recursion 6x. No successful call in this testcase needs deeper recursion. When not limiting the recursion depth, instead just monitoring it, for all cases where find_loc_in_1pdv returned non-NULL the depth at which return node; is used is at most 2 (0 is just find_loc_in_1pdv call with no recursion) and maximum depth ever recursed for the successful calls is 3. I believe the problem of this testcase is not the cases where find_loc_in_1pdv returns non-NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 the right fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
--- 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
--- 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
--- 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 ChangeLog) completed stage1 libs, more testing needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug lto/44408] FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44408
[Bug lto/41584] WHOPR doesn't grok empty units
--- 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 lto/41584 * cgraph.h (struct varpool_node): Add lto_file_data field. * lto-cgraph.c (input_varpool_node): Initialize it. lto/ * lto.c (lto_1_to_1_map): Use the proper file_data for varpool nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/lto-cgraph.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 -fomit-frame-pointer analysis.ii real103m46.642s user96m21.093s sys 0m1.196s $ time g++ -c -g -Os analysis.ii real0m19.345s user0m19.177s sys 0m0.168s $ time g++ -c -Os -fomit-frame-pointer analysis.ii real0m3.747s user0m3.640s sys 0m0.104s numbers above are from the 4.5 branch rev. 159866. trunk is also very slow, but the compile didn't yet finish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 real2m16.789s user2m16.333s sys 0m0.276s Of course not ideal, but much better than those 103 minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning
--- 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 s.a;
}
int
f2 ()
{
S s;
return s.b;
}
void
f3 ()
{
S s;
s.c = 6;// { dg-warning set but not used }
}
int
f4 ()
{
S s;
s.c = 6;
return s.c;
}
Guess we should mark the object through which a static data member is accessed,
because that access already marks the object as TREE_USED, yet it is not a set
of the object. Not sure where to do that though. Calling methods or static
methods apparently is handled already, in both cases build_new_method_call
- build_this - cp_build_unary_op ADDR_EXPR - mark_lvalue_use -
mark_exp_read takes care of it:
// PR c++/44412
// { dg-do compile }
// { dg-options -Wunused }
struct S
{
int foo ();
static int bar ();
};
int S::foo ()
{
return 5;
}
int S::bar ()
{
return 6;
}
int
f1 ()
{
S s;
return s.foo ();
}
int
f2 ()
{
S s;
return s.bar ();
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dodji at gcc dot gnu dot
||org, jason at gcc dot gnu
||dot org
Summary|Another bogus set-but-not- |[4.6 Regression] Another
|used warning|bogus set-but-not-used
||warning
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412
[Bug libstdc++/44413] New: inefficient code for std::string::compare on x86-64
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
cmpq$-2147483648, %r8
cmovge %r8d, %eax
.L2:
[...]
Since compare need only return a value greater, less, or equal to zero, the
code in _S_compare would be more efficient as simple code that just returns -1,
0, or 1 on most targets where difference_type is wider than int.
--
Summary: inefficient code for std::string::compare on x86-64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgohman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
[Bug other/44414] New: hashtab.h functions are undocumented
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 functions are undocumented Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414
[Bug other/44414] hashtab.h functions are undocumented
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414
[Bug libgcj/44415] New: [4.6 regression] gmp multilib support broke bootstrap with static libgmp
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 libgmp: /bin/ksh ../../../libtool --tag=CC --mode=link /vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/xgcc -B/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include-W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/vol/gcc/include -g -O2 -module -version-info 0:0:0 -no-undefined -L/vol/gcc/lib -lgmp -avoid-version -o libjavamath.la -rpath /vol/gcc/lib/gcj-4.6.0-11 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo -lsocket -lnsl libtool: link: /vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/xgcc -B/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include-shared -Wl,-z -Wl,text -Wl,-h -Wl,libjavamath.so -o .libs/libjavamath.so .libs/gnu_java_math_GMP.o ../../../native/jni/classpath/.libs/jcl.o -L/vol/gcc/lib /vol/gcc/lib/libgmp.a -lsocket -lnsl -lc Text relocation remains referenced against symbol offset in file .rodata.str1.4 (section)0x2e /vol/gcc/lib/libgmp.a(lt19-get_str.o) [...] The static libgmp is usually non-PIC, while we need PIC code to link libjavamath.so. It turned out to be remarkably difficult to work around this: * While gcc on Solaris supports -mimpure-text to allow linking of non-PIC code into a shared library, all this does is disable the implicit -z text enabled by gcc -shared. Since libtool passes -z text by itself, this doesn't help. * Sun ld doesn't allow -z text -z textoff, so I had to resort to edititing -z text out of libtool and adding -mimpure-text after the -shared there. To fix this for real, one needs to build a PIC libgmp.a, which at the very least needs to be documented. Apart from that, the patch has a couple of other problems: * The ChangeLog entry belongs into classpath/ChangeLog, not libjava/ChangeLog. * For multilibbed targets, it used to be enough to have libgmp for the default multilib. Now you need libgmp for every multilib, otherwise the facitilies between e.g. 32-bit and 64-bit libjavamath.so differ. * There seems to be no provision to pass in -L and -R flags for the non-default multilibs, and neither libtool nor the libjava/classpath make machinery seem to support automatically looking in e.g. $libdir/amd64 for 64-bit multilibs. It seems this needs considerably more work to be complete and useful. -- Summary: [4.6 regression] gmp multilib support broke bootstrap with static libgmp Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: *-*-solaris2.* GCC host triplet: *-*-solaris2.* GCC target triplet: *-*-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
[Bug rtl-optimization/42502] [4.4/4.5/4.6 Regression] Bad register allocation in a very simple code
--- 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 rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
[Bug rtl-optimization/42500] Unnecessary mov of sp to a register
--- 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 rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
[Bug rtl-optimization/39871] [4.3/4.4/4.5/4.6 regression] Code size increase on ARM due to poor register allocation
--- 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 rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug rtl-optimization/40615] unnecessary CSE
--- 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 rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- 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 Backport from mainline: 2010-05-18 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Add a few checks from rtx_equal_p inline. 2010-05-25 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Guard asserts with ENABLE_CHECKING. (intersect_loc_chains): Walk the s2var's loc_chain together with s1node chain as long as the locations are equal, don't call find_loc_in_1pdv in that case. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp
-- 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
--- 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 CC||ro at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i386-pc-solaris2.11 |i386-pc-solaris2.1[01] Known to fail||4.4.5 4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-06-04 12:53:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug other/44414] hashtab.h functions are undocumented
--- 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 |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414
[Bug middle-end/44382] Slow integer multiply
--- 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);
}
[...@gnu-6 44382]$ gcc -S -O2 x.i
[...@gnu-6 44382]$ cat x.s
.file x.i
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movlc(%rip), %eax
imull b(%rip), %eax
imull d(%rip), %eax
imull e(%rip), %eax
movl%eax, a(%rip)
ret
[...@gnu-6 44382]$ gcc -S -O2 x.i -fno-tree-reassoc
[...@gnu-6 44382]$ cat x.s
.file x.i
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movlb(%rip), %eax
movld(%rip), %edx
imull c(%rip), %eax
imull e(%rip), %edx
imull %edx, %eax
movl%eax, a(%rip)
ret
[...@gnu-6 44382]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug c++/26256] ignores using declaration
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-13 07:21:15 |2010-06-04 13:13:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26256
[Bug middle-end/44382] Slow integer multiply
--- 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
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 include/lac/block_vector.templates.h:19:0, from block_vector.cc:14: include/lac/block_vector.h:227:17: error: 'ptrdiff_t' does not name a type include/lac/block_vector.h:333:38: error: 'difference_type' does not name a type include/lac/block_vector.h:333:38: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:333:54: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:469:9: error: 'difference_type' does not name a type include/lac/block_vector.h:469:9: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:475:9: error: 'difference_type' does not name a type include/lac/block_vector.h:475:9: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:482:36: error: 'difference_type' does not name a type include/lac/block_vector.h:482:36: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:482:53: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:489:36: error: 'difference_type' does not name a type include/lac/block_vector.h:489:36: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:489:53: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:496:39: error: 'difference_type' does not name a type include/lac/block_vector.h:496:39: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:496:56: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:503:39: error: 'difference_type' does not name a type include/lac/block_vector.h:503:39: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:503:56: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:1494:52: error: 'difference_type' does not name a type include/lac/block_vector.h:1494:52: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:1494:68: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:1727:5: error: prototype for 'typename internal::BlockVectorIterators::Iteratornumber, constness::difference_type internal::BlockVectorIterators::Iteratornumber, constness::operator-(const internal::BlockVectorIterators::Iteratornumber, constness) const' does not match any in class 'internal::BlockVectorIterators::Iteratornumber, constness' include/lac/block_vector.h:489:18: error: candidate is: internal::BlockVectorIterators::Iteratornumber, constness internal::BlockVectorIterators::Iteratornumber, constness::operator-(const int) const include/lac/block_vector.h:1741:5: error: prototype for 'typename internal::BlockVectorIterators::Iteratornumber, constness::difference_type internal::BlockVectorIterators::Iteratornumber, constness::operator-(const InverseConstnessIterator) const' does not match any in class 'internal::BlockVectorIterators::Iteratornumber, constness' include/lac/block_vector.h:489:18: error: candidate is: internal::BlockVectorIterators::Iteratornumber, constness internal::BlockVectorIterators::Iteratornumber, constness::operator-(const int) const include/lac/block_vector.h:1756:23: error: 'difference_type' does not name a type include/lac/block_vector.h:1756:23: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:1756:40: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:1781:23: error:
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
-- 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
--- 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 CC||paolo dot carlini at oracle ||dot com 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
--- 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 v3, or qualified with std:: after essentially after including any other c++ header. For sure the c++ standard doesn't warrant more than the above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug libstdc++/44417] New: make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
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 /home/singler/gcc/trunk_1/libstdc++-v3/testsuite/util/testsuite_abi.h:27:0, from /home/singler/gcc/trunk_1/libstdc++-v3/testsuite/util/testsuite_abi.cc:23: /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:371:5: error: 'ptrdiff_t' does not name a type /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:447:23: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:459:18: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:469:26: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:495:18: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:501:26: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:540:18: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:546:26: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:566:4: error: 'ptrdiff_t' has not been declared compiler exited with status 1 Any ideas and/or a workaround? -- Summary: make check-target-libstdc++-v3 fails due to undefined ptrdiff_t Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: singler at kit dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- 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 retry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug middle-end/44382] Slow integer multiply
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning
--- 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
--- 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 defined in the global scope. Maybe on other systems, ptrdiff_t is also declared somewhere else, so the problem does not appear. -- 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
--- 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: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- 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 CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- 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 people using your exact same linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- 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
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- 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 dave.korn.cyg...@gmail.com PR lto/42776 * lib/lto.exp (lto_prune_vis_warns): New function. (lto-link-and-maybe-run): Call it. 2010-05-10 Rainer Orth r...@cebitec.uni-bielefeld.de * lib/lto.exp (lto_prune_vis_warns): Renamed to lto_prune_warns. Log text on entry and exit. Prune Sun ld warnings for common symbols with differing sizes. (lto-link-and-maybe-run): Change caller. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/lib/lto.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug middle-end/44382] Slow integer multiply
--- 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 the binary expressions into a vector of operand_entry_t I think this may always generate slower codes. We may not want to use much more registers. We can limit us to 2 temporaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- 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 work without a recent front end fix applied by Jason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME 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
--- 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 http://www.dealii.org/developer/doxygen/deal.II/block__vector_8h.html -- 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
--- 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
--- 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 c/25880 * c-objc-common.c (c_tree_printer): Handle %V, %v and %#v. * c-format.c (gcc_diag_flag_specs): Add hash. (gcc_cxxdiag_flag_specs): Use gcc_diag_flag_specs directly. (gcc_tdiag_char_table,gcc_cdiag_char_table): Handle %V and %v. * c-pretty-print.c (pp_c_cv_qualifier): Rename as pp_c_cv_qualifiers. Handle qualifiers spelling here. (pp_c_type_qualifier_list): Call the function above. * c-pretty-print.h (pp_c_cv_qualifiers): Declare. * c-typeck.c (handle_warn_cast_qual): Print qualifiers. (WARN_FOR_QUALIFIERS): New macro. (convert_for_assignment): Use it. testsuite/ * gcc.dg/assign-warn-2.c: Update. * gcc.dg/cpp/line3.c: Update. * gcc.dg/c99-array-lval-8.c: Update. * gcc.dg/cast-qual-2.c: Update. * gcc.dg/c99-arraydecl-3.c: Update. * gcc.dg/assign-warn-1.c: Update. * gcc.dg/format/gcc_diag-1.c: Update. Modified: trunk/gcc/ChangeLog trunk/gcc/c-format.c trunk/gcc/c-objc-common.c trunk/gcc/c-pretty-print.c trunk/gcc/c-pretty-print.h trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/assign-warn-1.c trunk/gcc/testsuite/gcc.dg/assign-warn-2.c trunk/gcc/testsuite/gcc.dg/c99-array-lval-8.c trunk/gcc/testsuite/gcc.dg/c99-arraydecl-3.c trunk/gcc/testsuite/gcc.dg/cast-qual-2.c trunk/gcc/testsuite/gcc.dg/cpp/line3.c trunk/gcc/testsuite/gcc.dg/format/gcc_diag-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- 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 backported (together with the typo fix in the configure script obviously). Done: I've run toplevel configure and make configure-gcc on both i386-pc-solaris2.11 (which has the new elf_getshdrstrndx) and i386-pc-solaris2.10 (which only has the non-conformant version of elf_getshstrndx) and got the expected results (and no error in gcc/config.log), so I've check this in. Should we ever receive more information for bootstrap/44079, we can either fix the configure tests or document the required version of elfutils libelf. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug c/25880] improve message of warning for discarding qualifiers
--- 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 that should explicitly print qualifiers, they just need to use %qV, %qv or %q#v to do so. In that case, reopen this PR or open a new one. Patches are also welcome. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c++/44244] Provide -f flags to turn on individual C++0x features
--- 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 them forever. c) c++0x features are spread all over the compiler - this is hard to implement properly as an after-thought. d) The additional checking will slow down the compiler for no significant gain. We are too slow already. * We have too many open PRs, so it is not worth it to keep this open just in case. Sorry about this but I hope you can understand. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- 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 these warnings with recent GCC, so I guess they are bogus. If you find a real (potential) uninitialized use, please reopen this PR and point us to the code. Otherwise, fixing this is not worth the effort of anyone. There is a lot more interesting (and urgently needed) work to do in GCC. I am sure Richard Guenther could have fixed a couple of real bugs in the time it took him to read this PR ;). Thanks for the report anyway. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug web/44269] Search for PR number in mailing lists fails
--- 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: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-04 15:59:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44269
[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
--- 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 changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44172] Compiling never ends
--- 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 |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-04 16:11:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- 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
--- 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 a nice enhancement, yes. -- 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
--- 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
--- 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 at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
