Re: Using C++ in GCC is OK

[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 "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

[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 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?

[Rainer Orth]

Uros Bizjak  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

[Larry Evans]

On 06/03/10 14:39, Steinar Bang wrote:

Larry Evans :



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

[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 
`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  

* 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

[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'
> /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

[Ian Lance Taylor]

"Amker.Cheng"  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

[Ian Lance Taylor]

Nathan Froyd  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

[Nathan Froyd]

On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd  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

[Diego Novillo]

On Thu, Jun 3, 2010 at 13:42, Andrew Haley  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

[Kai Tietz]

Hi,

What's about the "friend"s 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

[Ian Lance Taylor]

Nathan Froyd  writes:

> On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote:
>> Nathan Froyd  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++

[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) 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

[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 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 
, 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

[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 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

[Nathan Froyd]

On Fri, Jun 04, 2010 at 08:32:26AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd  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

[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 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

[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 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?

[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 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

[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 Sections (at 
least as regards inclusion of the GPL in manuals) are 
.
  
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

[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  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++

[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 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

[Joseph S. Myers]

On Tue, 1 Jun 2010, Paolo Bonzini wrote:

> > I think compiler can and should be host independent, like LLVM.
> 
> It is.  Changes to code generation depending on the host are considered to be
> serious bugs, and have been long before LLVM existed.

I'd like that to be the case, but PR 35466 was closed as WONTFIX.  I don't 
know whether the problem there applies to other targets as well, but I'd 
prefer requiring HOST_WIDE_INT to be 64 bits for all hosts and targets 
simply to eliminate the risk of this class of bugs.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Vector indexing patch

[Richard Guenther]

On Fri, Jun 4, 2010 at 6:38 PM, Joseph S. Myers  wrote:
> 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
> , and do not wish

The mark_addressable_vector change was at least semi-ugly.  I think
it is reasonable to require a constant index for register qualified vectors.
And it is reasonable to emit middle-end friendly BIT_FIELD_REFs for
constant indices as well.

Artem is one of our Goole Summer of Code students btw., and I
requested these changes.

Your comment about the ChangeLog entry is valid - Artem, please
look at existing entries in gcc/ChangeLog and follow that style.
Also please keep the existing documentation changes and/or adjust
them accordingly.

Thanks,
Richard.

> 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
>

Re: Using C++ in GCC is OK

[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 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 Q&A 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

[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?  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

[Ian Lance Taylor]

"Joseph S. Myers"  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  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

[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 sparc-sun-solaris2.10

On Fri, Jun 04, 2010 at 08:32:26AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd  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

[Gabriel Dos Reis]

On Fri, Jun 4, 2010 at 3:55 PM, Ian Lance Taylor  wrote:
> "Joseph S. Myers"  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

[Andrew Pinski]

On Tue, Jun 1, 2010 at 12:21 PM, Artem Shinkarov
 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

[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

[Mark Mitchell]

Joseph S. Myers wrote:

> I repeat my request from the RM Q&A 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

[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 situations where seemingly 
simple code does something expensive, right?


Jeff

Re: Using C++ in GCC is OK

[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 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

[Gabriel Dos Reis]

On Fri, Jun 4, 2010 at 7:55 PM, Jeff Law  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?)

[Philipp Thomas]

On Fri, 23 Apr 2010 16:23:29 +0200, Manuel López-Ibáñez
 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

Re: Puzzle about macro MIPS_PROLOGUE_TEMP_REGNUM

[Richard Sandiford]

"Amker.Cheng"  writes:
> 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?

It's not "starting from $3".  It's $3 and nothing else ;-)  It's not
intended to be used as (MIPS_PROLOGUE_TEMP_REGNUM + N).

$3 was chosen because it's a MIPS16 register, and can therefore
be used for both MIPS16 and normal-mode code.  $2 used to be the
static chain register, which left $3 as the only free call-clobbered
MIPS16 register.  I changed the static chain register to $15 to avoid
a clash with the MIPS16 gp-load sequence:

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00622.html

so $2 is probably free now too.

Richard