Re: C++ diagnostics: Use quoting flag q (7/n)

"Giovanni Bajo" <giovannibajo <at> libero.it> writes:

| Gabriel Dos Reis wrote:
| 
| > This is assumed to finish the conversion of the C++ front-end to use
| > the newly recommended quotation marks.  
| 
| Looks like you forgot cp/cvt.c.

Fixed with this.

Bootstrapped on an i686-pc-linux-gnu.

-- Gaby

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/ChangeLog,v
retrieving revision 1.4467
diff -p -r1.4467 ChangeLog
*** ChangeLog	1 Nov 2004 00:07:07 -0000	1.4467
--- ChangeLog	1 Nov 2004 00:11:00 -0000
***************
*** 1,3 ****
--- 1,10 ----
+ 2004-10-31  Gabriel Dos Reis  <gdr <at> integrable-solutions.net>
+ 
+ 	Convert diagnostics to use quoting flag q 8/n
+ 	* cvt.c (cp_convert_to_pointer, warn_ref_binding, 
+ 	convert_to_reference, ocp_convert, convert_to_void 

C++ PATCH: PR 15172

PR c++/15172 was a serious wrong-code regression in G++; an aggregate
initializer could result in a bitwise copy not permitted by the
standard.  As a consequence, the address at which an object was
constructed and the address at which it was destroyed could be
different.

The front-end was generating a CONSTRUCTOR containing a TARGET_EXPR,
which seems like a reasonable representation of the initializer, but
expand_expr was generating the CONSTRUCTOR as a separate object on the
stack and then copying it into the destination location.  RTH wrote
code to split out the non-constant bits of the initializer as runtime
code, but, probably due to a misleading comment in the front end, it
was not being used.  I activated this code all the time.

Tested on i686-pc-linux-gnu, applied on the 3.4 branch and on the
mainline.  The regression did not appear on the mainline, but there is
no reason not to make the same simplification to the code.

--
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com

2004-10-31  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/15172
	* typeck2.c (store_init_value): Use split_nonconstant_init even
	for types that require construction.
	

[RFA:] Fix PR rtl-optimization/17933: parallel set destinations unhandled by dead_or_set_regno_p.

PR rtl-optimization/17933 is an abort on hppa64-hp-hpux11.11 at -O2 for
a detected inconsistency in the number of REG_DEAD notes before and after
the first scheduling pass (which doesn't rearrange anything in this case).
The problem is not otherwise related to scheduling.  The number of
REG_DEAD notes change on one particular insn.  Before scheduling:

(call_insn 18 17 19 0 (parallel [
            (set (parallel:BLK [
                        (expr_list:REG_DEP_TRUE (reg:DI 28 %r28)
                            (const_int 0 [0x0]))
                    ])
                (call (mem:SI (reg:DI 28 %r28) [0 S4 A32])
                    (const_int 64 [0x40])))
            (clobber (reg:DI 2 %r2))
            (clobber (reg:DI 4 %r4))
            (use (reg:DI 27 %r27))
            (use (reg/f:DI 29 %r29))
            (use (const_int 1 [0x1]))
        ]) 263 {call_val_reg_64bit} (insn_list:REG_DEP_TRUE 17 (insn_list:REG_DEP_TRUE 16
(insn_list:REG_DEP_TRUE 13 (nil))))
    (expr_list:REG_UNUSED (reg:DI 4 %r4)
        (expr_list:REG_UNUSED (reg:DI 2 %r2)
            (expr_list:REG_UNUSED (reg:DI 28 %r28)
                (expr_list:REG_DEAD (reg:DI 28 %r28)
                    (expr_list:REG_UNUSED (reg:DI 28 %r28)
                        (expr_list:REG_UNUSED (reg:DI 2 %r2)
                            (expr_list:REG_UNUSED (reg:DI 4 %r4)
                                (expr_list:REG_DEAD (reg:DI 27 %r27)
                                    (expr_list:REG_DEAD (reg/f:DI 29 %r29)
                                        (expr_list:REG_DEAD (reg:SI 26 %r26)

Re: [RFA:] Fix PR rtl-optimization/17933: parallel set destinations unhandled by dead_or_set_regno_p.

On Sun, 31 Oct 2004, Hans-Peter Nilsson wrote:

> The PR is for hppa64-hp-hpux11.11, which I do
> not have access to.  I need access to one, or have someone else to
> bootstrap and make check there.  (Unfortunately I see no such system among
> Hewlett-Packard's testdrive systems; their installed gcc-3.4.2 on
> hppa2.0w-hp-hpux11.11 does not expose the bug.)

s/3.4.2/3.4.1/

Hmm, who could be the "zack" in the "Configured with:" output? 

brgds, H-P

[RFA:] gdbinit.in: macros for dumping BB and bitmap.

These were of help when investigating PR rtl-optimization/17933
and I remember I did something similar to pbb at an earlier
occasion.

	* gdbinit.in (pbb, pbm): New macros.

Index: gdbinit.in
===================================================================
RCS file: /mnt/auto/localgcccvs/gcc/gcc/gdbinit.in,v
retrieving revision 1.8
diff -u -p -r1.8 gdbinit.in
--- gdbinit.in	2 Aug 2004 19:36:57 -0000	1.8
+++ gdbinit.in	31 Oct 2004 00:56:59 -0000
 <at>  <at>  -113,6 +113,22  <at>  <at>  In cc1plus, print the current binding st
 including the global binding level.
 end

+define pbb
+set dump_bb ($, stderr, 0)
+end
+
+document pbb
+Dump the basic block that is in $, including rtx.
+end
+
+define pbm
+set bitmap_print (stderr, $, "", "\n")
+end
+
+document pbm

PATCH: Update README.SCO

The FSF has asked that we update README.SCO as indicated beneath my
signature.

Applied on the 3.4 and mainline branches.  (However, this change will
be not be in the 3.4.3 prerelease, which is presently being spun.)

--
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com

2004-10-31  Mark Mitchell  <mark <at> codesourcery.com>

	* README.SCO: Update per FSF instructions.

====================================================================

The GCC team has been urged to drop support for SCO Unix from GCC, as
a protest against SCO's irresponsible aggression against free software
and GNU/Linux.  We have decided to take no action at this time, as we
no longer believe that SCO is a serious threat.

For more on the FSF's position regarding SCO's attacks on free
software, please read:

  http://www.gnu.org/philosophy/sco/sco.html

Re: Fix PR 16728

Here's the test. If necessary, this can just be dg-do run linux.

tested x86/linux

2004-10-31  Benjamin Kosnik  <bkoz <at> redhat.com>

	PR c++/16728
	* testsuite/23_containers/set/modifiers/16728.cc: New.

Index: testsuite/23_containers/set/modifiers/16728.cc
===================================================================
RCS file: testsuite/23_containers/set/modifiers/16728.cc
diff -N testsuite/23_containers/set/modifiers/16728.cc
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/23_containers/set/modifiers/16728.cc	31 Oct 2004 21:32:00 -0000
***************
*** 0 ****
--- 1,96 ----
+ // Copyright (C) 2004 Free Software Foundation, Inc.
+ //
+ // This file is part of the GNU ISO C++ Library.  This library is free
+ // software; you can redistribute it and/or modify it under the
+ // terms of the GNU General Public License as published by the
+ // Free Software Foundation; either version 2, or (at your option)
+ // any later version.
+ 
+ // This library is distributed in the hope that it will be useful,

Re: [Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

More work to speed up 15524.  I was rather puzzled that "expand" was
being charged with 30% of the compilation time.  I originally thought
there was some lameness in the switch statement expanders.  However,
it turned out I was totally wrong.

The culprit is actually the code to record the number of iterations
of each loop.  We never pushed a timevar for that pass and thus the
time was charged to whatever was on the top of the timevar stack
(which happens to be TV_EXPAND).

The code to record the number of loop iterations was being rather
dumb.  It basically did something like:

foreach loop
  foreach block
     if block is in loop
        code

Clearly the problem is second loop -- it's walking *all* the blocks
and testing for loop membership.  Ouch.

It's far more efficient to use get_loop_body (which does a DFS walk 
starting at the beginning of the loop to the end of the loop).  To
give you some idea here's some data:

The original time without my patch is:

 expand                :  54.55 (30%) usr   0.03 ( 4%) sys  55.21 (30%)
 TOTAL                 : 181.76             0.85           185.17

Re: GCC 's quoting typographic conventions

Robert Dewar wrote:
> Paul Schlie wrote:
> 
>> Re: http://gcc.gnu.org/ml/gcc/2004-10/msg01263.html
>>     http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02679.html
>>
>> I suspect the strongest argument in favor GCC simply utilizing plane old
>> ASCII typographical " and ' quote delimiter characters when possible, is
>> that GCC is first and foremost a development tool, generating text which
>> just as likely to be consumed by other tools as read my humans.
>>
>> Therefore GCC should arguably adopt the conventions most friendly to that
>> purpose; where although it may be enabled to make its output 
>> typographically
>> prettier, doing at the risk of potentially complicating it's 
>> subsequent use
>> likely isn't a good decision. As opposed to a text processing tool who's
>> purpose is to generate ideally human friendly text, such as intended for
>> documentation for example.
> 
> 
> To me, this is a very strong argument, given that the argument on the
> other side is really nothing more than a relatively unimportant aesthetic
> concern (and that aesthetic may well be overridden in practice by strange
> results in environments that do not handle the extended character set).

Glad to hear that.  I'll second/third/whatever it.

Begin typographical is for some other tool.

Re: [Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

On Sun, 31 Oct 2004, Jeffrey A Law wrote:

>
> More work to speed up 15524.  I was rather puzzled that "expand" was
> being charged with 30% of the compilation time.  I originally thought
> there was some lameness in the switch statement expanders.  However,
> it turned out I was totally wrong.
>
> The culprit is actually the code to record the number of iterations
> of each loop.  We never pushed a timevar for that pass and thus the
> time was charged to whatever was on the top of the timevar stack
> (which happens to be TV_EXPAND).
>
> The code to record the number of loop iterations was being rather
> dumb.  It basically did something like:
>
> foreach loop
>  foreach block
>     if block is in loop
>        code
>
>
> Clearly the problem is second loop -- it's walking *all* the blocks
> and testing for loop membership.  Ouch.

I actually had fixed this as part of my last patch, but was waiting till 
monday to commit it.