Unreviewed patches

Unreviewed patches

[Jerry Quinn]

Hi all.  I had posted the following documentation patches a little
while ago, but they haven't been reviewed.  I was hoping to get them
into 3.3 as well as mainline.


http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00867.html
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00866.html
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00863.html
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00860.html
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00859.html


Thanks,
Jerry Quinn

Unreviewed patches

[Rainer Orth]

Three patches have remained unreviewed for a week or more:

	c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as
        https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html

This one may even be obvious.

	testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-bit Solaris/x86
        https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643771.html

        testsuite: i386: Fix gcc.target/i386/avx512vl-stv-rotatedi-1.c on 32-bit Solaris/x86
        https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643774.html

Those two require an x86 maintainer.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Uros Bizjak]

On Wed, Jan 31, 2024 at 3:04 PM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Three patches have remained unreviewed for a week or more:
>
>         c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as
>         https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html
>
> This one may even be obvious.
>
>         testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-bit Solaris/x86
>         https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643771.html
>
>         testsuite: i386: Fix gcc.target/i386/avx512vl-stv-rotatedi-1.c on 32-bit Solaris/x86
>         https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643774.html
>
> Those two require an x86 maintainer.

OK for x86 patches, I'd say that these two fall under Solaris
maintainership (if not obvious, after all).

Thanks,
Uros.

Re: Unreviewed patches

[Rainer Orth]

Hi Uros,

> On Wed, Jan 31, 2024 at 3:04 PM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>>
>> Three patches have remained unreviewed for a week or more:
>>
>>         c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as
>>         https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html
>>
>> This one may even be obvious.

I do claim that now and have installed the patch.

>>         testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-bit Solaris/x86
>>         https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643771.html
>>
>>         testsuite: i386: Fix gcc.target/i386/avx512vl-stv-rotatedi-1.c on
>> 32-bit Solaris/x86
>>         https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643774.html
>>
>> Those two require an x86 maintainer.
>
> OK for x86 patches, I'd say that these two fall under Solaris
> maintainership (if not obvious, after all).

I've always been careful when touching files that affect non-Solaris
targets, in case a maintainer sees a better solution or finds fault with
mine.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Unreviewed patches

[Rainer Orth]

The following patches have remained unreviewed for a week or more:

	[build] Support --sysroot with Solaris ld
        https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02342.html

This needs a build maintainer unless one considers it obvious.

	Support $SYSROOT for = in -I etc.
        https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00011.html

This needs a cpp or C maintainer.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Jeff Law]

On 06/08/2017 04:08 AM, Rainer Orth wrote:
> The following patches have remained unreviewed for a week or more:
> 
> 	[build] Support --sysroot with Solaris ld
>         https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02342.html
> 
> This needs a build maintainer unless one considers it obvious.
> 
> 	Support $SYSROOT for = in -I etc.
>         https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00011.html
> 
> This needs a cpp or C maintainer.
OK for both.  Sorry for the long wait.

jeff

Unreviewed patches

[Rainer Orth]

The following patches have remained unreviewed for a week:

	[gotools, libcc1] Update copyright dates
        https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02307.html

Richard already approved the update-copyright.py changes, but the actual
effects on gotools and libcc1 require either maintainer or release
manager approval, I believe.

	[build] Handle gas/gld --compress-debug-sections=type
	https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02325.html

This one needs a build maintainer.

Thanks.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Gerald Pfeifer]

On Mon, 6 Jun 2016, Rainer Orth wrote:
> The following patches have remained unreviewed for a week:
> 
> 	[gotools, libcc1] Update copyright dates
>         https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02307.html
> 
> Richard already approved the update-copyright.py changes, but the actual
> effects on gotools and libcc1 require either maintainer or release
> manager approval, I believe.

I think applying those updates is a direct consequence of updating
the update-copyright.py script and you can just go ahead.

Gerald

Re: Unreviewed patches

[Rainer Orth]

Hi Gerald,

> On Mon, 6 Jun 2016, Rainer Orth wrote:
>> The following patches have remained unreviewed for a week:
>> 
>> 	[gotools, libcc1] Update copyright dates
>>         https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02307.html
>> 
>> Richard already approved the update-copyright.py changes, but the actual
>> effects on gotools and libcc1 require either maintainer or release
>> manager approval, I believe.
>
> I think applying those updates is a direct consequence of updating
> the update-copyright.py script and you can just go ahead.

done now.  I'd just hoped to get word from the RMs what to do about
default_dirs in the script so the same doesn't happen again next year.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Jeff Law]

On 06/06/2016 02:16 AM, Rainer Orth wrote:
> The following patches have remained unreviewed for a week:
>
> 	[gotools, libcc1] Update copyright dates
>         https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02307.html
Everything bug the gotools changes are OK.  THe master bits for gotools 
is outside of GCC.  Probably best to contact Ian for getting these updated.

>
> Richard already approved the update-copyright.py changes, but the actual
> effects on gotools and libcc1 require either maintainer or release
> manager approval, I believe.
>
> 	[build] Handle gas/gld --compress-debug-sections=type
> 	https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02325.html
>
> This one needs a build maintainer.
This is OK for the trunk.

jeff

Re: Unreviewed patches

[Rainer Orth]

Hi Jeff,

> On 06/06/2016 02:16 AM, Rainer Orth wrote:
>> The following patches have remained unreviewed for a week:
>>
>> 	[gotools, libcc1] Update copyright dates
>>         https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02307.html
> Everything bug the gotools changes are OK.  THe master bits for gotools is
> outside of GCC.  Probably best to contact Ian for getting these updated.

I'd already installed the complete patch, based on 

	https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00407.html

Since update-copyright.py only updates files with FSF copyright notices,
which are local to the gcc tree, I hope this should be safe.

>> Richard already approved the update-copyright.py changes, but the actual
>> effects on gotools and libcc1 require either maintainer or release
>> manager approval, I believe.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Unreviewed patches

[Rainer Orth]

The following patches have remained unreviewed for a week:

	[testsuite] Skip gcc.c-torture/execute/960321-1.c on Solaris 2/x64 with Sun as
        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00205.html

	[build] Avoid objdump error in gcc_cv_ld_eh_gc_sections test
        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00118.html

	[testsuite, lto] Prune Sun ld size mismatch warnings
        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00202.htm

Given that we don't have a testsuite maintainer right now (couldn't
Janis review patches even without a copyright assignment in place?), the
testsuite ones probably need a global reviewer.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Paolo Bonzini]

On 05/10/2010 11:57 AM, Rainer Orth wrote:
> 	[build] Avoid objdump error in gcc_cv_ld_eh_gc_sections test
>          http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00118.html

This one is okay.

> 	[testsuite] Skip gcc.c-torture/execute/960321-1.c on Solaris 2/x64 with Sun as
>         http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00205.html

Don't you have to test x86_64-*-solaris2* too here, since there is this 
in config.guess:

i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
   ...
                 SUN_ARCH="x86_64"
   ...
   echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`

?

> 	[testsuite, lto] Prune Sun ld size mismatch warnings
>         http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00202.html

This one is LTO-specific, maybe Richard can approve it?

Paolo

Re: Unreviewed patches

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

> On 05/10/2010 11:57 AM, Rainer Orth wrote:
>> 	[build] Avoid objdump error in gcc_cv_ld_eh_gc_sections test
>>          http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00118.html
>
> This one is okay.

Thanks.

>> 	[testsuite] Skip gcc.c-torture/execute/960321-1.c on Solaris 2/x64 with Sun as
>>         http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00205.html
>
> Don't you have to test x86_64-*-solaris2* too here, since there is this in
> config.guess:
>
> i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
>   ...
>                 SUN_ARCH="x86_64"
>   ...
>   echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
>
> ?

No, there's no x86_64-*-solaris2* configuration in gcc, cf. PR
bootstrap/39150.  config.guess only detects this if run with a compiler
that produces 64-bit objects by default (e.g. CC='gcc -m64'), and
neither gcc nor cc do.  The Solaris 10+ GCC configurations are
multilibbed, with 32-bit as the default, thus i?86-*-solaris2*.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Paolo Bonzini]

On 05/10/2010 01:33 PM, Rainer Orth wrote:
>>> 	[testsuite] Skip gcc.c-torture/execute/960321-1.c on Solaris 2/x64 with Sun as
>>>          http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00205.html
>>
>> Don't you have to test x86_64-*-solaris2* too here, since there is this in
>> config.guess:
>>
>> i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
>>    ...
>>                  SUN_ARCH="x86_64"
>>    ...
>>    echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
>>
>> ?
>
> No, there's no x86_64-*-solaris2* configuration in gcc, cf. PR
> bootstrap/39150.  config.guess only detects this if run with a compiler
> that produces 64-bit objects by default (e.g. CC='gcc -m64'), and
> neither gcc nor cc do.  The Solaris 10+ GCC configurations are
> multilibbed, with 32-bit as the default, thus i?86-*-solaris2*.

The testsuite can be run on an installed compiler, so there _is_ the 
possibility of running on x86_64-*-solaris2*.  For a one line change, it 
seems worthwhile to do it.

Anyway, that's just my humble opinion; I'll let Janis or whoever else 
approves the patch decides.

Paolo

Re: Unreviewed patches

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

> The testsuite can be run on an installed compiler, so there _is_ the
> possibility of running on x86_64-*-solaris2*.  For a one line change, it
> seems worthwhile to do it.

I don't think this makes sense: this would be the only place in the
whole testsuite (all of GCC, in fact) that knew about and dealt with
such a configuration.  If there ever would be real x86_64-*-solaris2*
support, things will be different, but until then I'd like to keep
things as is.

> Anyway, that's just my humble opinion; I'll let Janis or whoever else
> approves the patch decides.

Ok.  Let's hope someone does :-)

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Richard Guenther]

On Mon, May 10, 2010 at 1:22 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 05/10/2010 11:57 AM, Rainer Orth wrote:
>>
>>        [build] Avoid objdump error in gcc_cv_ld_eh_gc_sections test
>>         http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00118.html
>
> This one is okay.
>
>>        [testsuite] Skip gcc.c-torture/execute/960321-1.c on Solaris 2/x64
>> with Sun as
>>        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00205.html
>
> Don't you have to test x86_64-*-solaris2* too here, since there is this in
> config.guess:
>
> i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
>  ...
>                SUN_ARCH="x86_64"
>  ...
>  echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
>
> ?
>
>>        [testsuite, lto] Prune Sun ld size mismatch warnings
>>        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00202.html
>
> This one is LTO-specific, maybe Richard can approve it?

That one is ok for trunk.

Thanks,
Richard.

> Paolo
>

Re: Unreviewed patches

[Rainer Orth]

Richard Guenther <richard.guenther@gmail.com> writes:

>>>        [testsuite, lto] Prune Sun ld size mismatch warnings
>>>        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00202.html
>>
>> This one is LTO-specific, maybe Richard can approve it?
>
> That one is ok for trunk.

Thanks.  How about the 4.5 branch after a couple of days on mainline?
The patch considerably reduces testsuite noise there.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Richard Guenther]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 513 bytes --]

On Mon, 10 May 2010, Rainer Orth wrote:

> Richard Guenther <richard.guenther@gmail.com> writes:
> 
> >>>        [testsuite, lto] Prune Sun ld size mismatch warnings
> >>>        http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00202.html
> >>
> >> This one is LTO-specific, maybe Richard can approve it?
> >
> > That one is ok for trunk.
> 
> Thanks.  How about the 4.5 branch after a couple of days on mainline?
> The patch considerably reduces testsuite noise there.

Yes.

Thanks,
Richard.

Unreviewed patches

[Rainer Orth]

A couple of my patches have remained unreviewed for some time.  I've
Cc'ed the appropriate maintainers to get attention:

	PATCH: Avoid use of CFI unless gas creates read-only 64-bit .eh_frame sections on Solaris/x86
        http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01300.html

This one needs a build maintainer.  Without it, EH on 64-bit Solaris
11/x86 is completely broken.

	PATCH: Cause gnatlink in gnat.dg to call correct gcc
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00989.html

This one needs probably both an Ada and a testsuite maintainer.

	PATCH: Properly mark 64-bit .eh_frame section on x86 as type unwind
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00991.html

An libffi and/or x86 maintainer are required for this one.

	PATCH: Fix 64-bit Solaris 2/x86 IE TLS code sequence
	http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00993.html

This requires an i386/x864-64 maintainer, though the current patch is
incomplete.

	PATCH: Fix Solaris 11/x86 MD_FALLBACK_FRAME_STATE_FOR
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00994.html

I can formally install this one on my own, but would like to have an
i386/x86-64 maintainer to have a look if it makes sense.

	PATCH: Support TLS with Sun as on Solaris 2/x86
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00999.html

Again, stuff for an i386 maintainer.

	PATCH: Support Sun symbol versioning in libgomp
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01003.html

Something for a libgomp maintainer to look at.

	PATCH: Support Sun symbol versioning in libssp
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01005.html

There's no listed maintainer for libssp, unfortunately.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Janis Johnson]

On Mon, 2010-03-01 at 17:07 +0100, Rainer Orth wrote:
> A couple of my patches have remained unreviewed for some time.  I've
> Cc'ed the appropriate maintainers to get attention:


> 	PATCH: Cause gnatlink in gnat.dg to call correct gcc
>         http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00989.html
> 
> This one needs probably both an Ada and a testsuite maintainer.

It looks OK to me but I'm not familiar with the GNAT tests and would
prefer to have an Ada maintainer look at it, particularly Eric who
wrote gnat.exp.

Janis

Re: Unreviewed patches

[Paolo Bonzini]

On 03/01/2010 05:07 PM, Rainer Orth wrote:
> 	PATCH: Avoid use of CFI unless gas creates read-only 64-bit .eh_frame sections on Solaris/x86
>          http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01300.html
>
> This one needs a build maintainer.  Without it, EH on 64-bit Solaris
> 11/x86 is completely broken.

You can approve that yourself since you're a Solaris maintainer. 
However, please sort out with Eric what to do before committing it.

Paolo

Re: Unreviewed patches

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

> On 03/01/2010 05:07 PM, Rainer Orth wrote:
>> 	PATCH: Avoid use of CFI unless gas creates read-only 64-bit .eh_frame sections on Solaris/x86
>>          http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01300.html
>>
>> This one needs a build maintainer.  Without it, EH on 64-bit Solaris
>> 11/x86 is completely broken.
>
> You can approve that yourself since you're a Solaris maintainer. However,
> please sort out with Eric what to do before committing it.

I thought configury changes were still required to be approved by a
build maintainer, unless they are completely obvious.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Paolo Bonzini]

On 03/01/2010 06:32 PM, Rainer Orth wrote:
> I thought configury changes were still required to be approved by a
> build maintainer, unless they are completely obvious.

As long as it is "obviously no change on non-Solaris, and the logic is 
not spread all over the configure.ac file", I am fine with it (instead, 
a _bad_ example of this are the recent x86 default arch patches).  Just 
give a couple of days for people to look at it, and/or put a [build] tag 
in the subject.

Paolo

Re: Unreviewed patches

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

> On 03/01/2010 06:32 PM, Rainer Orth wrote:
>> I thought configury changes were still required to be approved by a
>> build maintainer, unless they are completely obvious.
>
> As long as it is "obviously no change on non-Solaris, and the logic is not
> spread all over the configure.ac file", I am fine with it (instead, a _bad_
> example of this are the recent x86 default arch patches).  Just give a
> couple of days for people to look at it, and/or put a [build] tag in the
> subject.

Fine, will do.  This will help a lot in the future, since I've got a
couple of gcc/configure.ac patches coming to detect Solaris 2 features
or quirks.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patches

[Eric Botcazou]

> You can approve that yourself since you're a Solaris maintainer.
> However, please sort out with Eric what to do before committing it.

We already sorted this out so no objections by me.

-- 
Eric Botcazou

Unreviewed patches

[Rainer Orth]

The following patches have remained unreviewed for a week or more:

	PATCH: Fix several Ada testing problems on IRIX (PR ada/32547)
        http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00594.html

        only the gnat-dg.exp chunk hasn't been reviewed yet

	PATCH: Avoid use of CFI unless gas creates read-only 64-bit .eh_frame sections on Solaris/x86
        http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01300.html

        PATCH: XFAIL objc/execute/forward-1.m on IRIX, Solaris 2 and Tru64 UNIX (PR libobjc/36610)
        http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01239.html

        PATCH: XFAIL gcc.dg/cpp/_Pragma6.c on IRIX and Tru64 UNIX
        http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01310.html

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Unreviewed patches

[Jakub Jelinek]

Hi!

- __builtin_va_{start,end,copy} optimization on typedef char *va_list
  targets - PR middle-end/20983
  P2 regression since ADDRESSOF removal
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00895.html

- recognize some common rotate patterns in folder - PR middle-end/29749
  P2 regression
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01112.html

- the generic part of Fortran debuginfo patch for
  deferred/assumed-size/assumed-shape arrays - PR fortran/22244
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00888.html
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00903.html

- C+ variadic templates unification fix - PR c++/32565, c++/33943
  P2 regressions
  Wonder if for the patch as is would be desirable to be committed
  as an incremental improvement and leave Doug/Jason to do the rest,
  or if it is better to wait for a full fix for all variadic
  unification issues
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01002.html

- RFC OpenMP omp_get_{thread_num,num_threads} optimization
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01068.html

	Jakub

Re: Unreviewed patches

[Richard Guenther]

On Nov 27, 2007 10:46 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> - recognize some common rotate patterns in folder - PR middle-end/29749
>   P2 regression
>   http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01112.html

This is ok.

Thanks,
Richard.

Unreviewed patches

[Jakub Jelinek]

Hi!

- PR middle-end/33335
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00266.html
  - fix PCH related miscompilations introduced with optabs initialization
    speedup changes; P1

- PR middle-end/23848
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00155.html
  - optimize unneeded stack saves/restores with VLAs; P2

- -fsched-stalled-insns documentation fix
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00066.html

- PR bootstrap/30589 mingw fixincludes hack
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00092.html
  - this doesn't need review yet, but actually someone with access to mingw
    or at least M$Win to test it; P1

	Jakub

Re: Unreviewed patches

[Danny Smith]

On Nov 14, 2007 4:41 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Nov 13, 2007 at 08:54:16AM +1300, Danny Smith wrote:
> > > - PR bootstrap/30589 mingw fixincludes hack
> > >   http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00092.html
> > >   - this doesn't need review yet, but actually someone with access to mingw
> > >     or at least M$Win to test it; P1
>
> Thanks for trying.
>
> > I am not been able to get your patch to work on mingw  bootstrap.
>
> > Then I get lots of error messages
> >
> > FS error 2 (No such file or directory) reopening
> > 'c++/4.3.0/parallel/settings.h' as stdin
more errors of same

Hi,

Even with your foward-slashify patch I still cannot get the fixincl
machinery to run on mingw32 host. Note that mingw uses the two-process
fix and has never really been tested on mingw before. I suppose using
libiberty's pex routines to run the subrocess rather than system() would
be the way to go to avoid the system() shell nastiness, but....

Even if it were fixed for mingw32 host, it would not be much use anyway:
mingw32 does not put its runtime headers in the system include dir since
Windows does not really have a system root. Instead the runtime header
are installed into the local include dir which is located relative to
EXEC_PREFIX. The local dir takes precedence over the gcc compiler
libdir, so fixincluding a header there has no real effect.

The good news is that your patch does work and fixes the problem for a
mingw-targeted cross compiler. I have tested successfully with
i386-linux host and with cygwin host. IMO this is enough to justify
downgrading priority from P1 to P3

One nit.  The machine_name fix wrongly modifies a
#ifndef _stdcall
to
#ifndef  __stdcall__

in the w32api file windef.h

This addition to your patch prevents the wrong fix
Index: inclhack.def
===================================================================
--- inclhack.def	(revision 130248)
+++ inclhack.def	(working copy)
@@ -2504,6 +2504,7 @@
     hackname  = machine_name;
     c_test    = machine_name;
     c_fix     = machine_name;
+    bypass    = "_stdcall";

     test_text = "/* MACH_DIFF: */\n"
     "#if defined( i386 ) || defined( sparc ) || defined( vax )"

After that I get:

Applying machine_name             to w32api/ddk/ndis.h
Fixed:  w32api/ddk/ndis.h  <<< this is a useful fix from "i386" to "__i386__"
Quoted includes in w32api/ddk/ndis.h
Applying io_quotes_def            to w32api/ddk/usb.h
Applying io_quotes_def            to w32api/oleauto.h
Applying io_quotes_def            to w32api/wininet.h
Applying io_quotes_def            to w32api/winnt.h
Applying io_quotes_def            to w32api/winsock.h
Applying io_quotes_def            to w32api/winsock2.h
Applying io_quotes_use            to w32api/winsock2.h
Applying mingw_crt_inline         to _mingw.h
Fixed:  _mingw.h


Danny

Unreviewed patches

[Jakub Jelinek]

Hi!

-Dinhibit_libc fix for emutls.c compilation
  http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00094.html

IA64 dataflow merge caused regressions
  P1 PR target/32337
  http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00629.html

  P1 PR target/32338
  http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01569.html

Fortran debuginfo improvement
  http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00851.html

PowerPC32 libgcc.a(tramp.o) fix
  http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01307.html

dwarf2out ICE fix with vector CONSTRUCTOR
  P1 PR debug/32914
  http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01254.html

check_explicit_specialization regression
  P1 PR c++/32596, c++/32400
  http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00954.html
  the suggested change to copy it unconditionally doesn't work
  see http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01117.html

	Jakub

Re: Unreviewed patches

[Jason Merrill]

Jakub Jelinek wrote:
> dwarf2out ICE fix with vector CONSTRUCTOR
>   P1 PR debug/32914
>   http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01254.html

OK.  I'd use a goto rather than a flag here, but that's a matter of taste.

Jason

Unreviewed patches

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00016.html
gomp C++ FE diagnostics fix

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00942.html
match more valid NRV candidates in dest_safe_for_nrv_p,
previously pessimized by PR25505

	Jakub

Re: Unreviewed patches

[Richard Guenther]

On 6/20/07, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00016.html
> gomp C++ FE diagnostics fix
>
> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00942.html
> match more valid NRV candidates in dest_safe_for_nrv_p,
> previously pessimized by PR25505

This one is ok for mainline after the freeze.

Thanks,
Richard.

Re: Unreviewed patches

[Mark Mitchell]

Jakub Jelinek wrote:

> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00016.html
> gomp C++ FE diagnostics fix

OK now if a regression, after lockdown if not.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Unreviewed patches

[Jakub Jelinek]

Hi!

- PR preprocessor/29612
  libcpp fix for -Wno-system-headers on preprocessed sources
  http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00472.html

- powerpc64 libffi unwind info fix
  http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01680.html

	Jakub

Unreviewed patches

[Adam Nemet]

Can someone please review these.

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00281.html

  This fixes a bug in the truncation-simplification code.  Whether we
  need the code being fixed at all is not clear.  If truncation is a
  no-op, in theory, we should not need to check high-order bits.  But
  anyway the code in its current form is obviously incorrect.

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01366.html

  New target-hook: mode_rep_extended.

Thanks,
Adam

Unreviewed patches

[Jakub Jelinek]

Hi!

- debuginfo fix for static variables in inline functions (4.1 regression)
  http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00103.html
  Verified today on s390x-redhat-linux that the second testcase still
  fails without the patch, works with the patch and bootstrapped/regtested
  it

- C++ diagnostic fix - PR c++/21983, 3.4/4.0/4.1 regression
  http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00285.html
  Bootstrapped/regtested on 7 linux arches again yesterday

	Jakub

Re: Unreviewed patches

[Mark Mitchell]

Jakub Jelinek wrote:

> - C++ diagnostic fix - PR c++/21983, 3.4/4.0/4.1 regression
>   http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00285.html
>   Bootstrapped/regtested on 7 linux arches again yesterday

This is OK, for 4.1, and for 4.0.3, after the branch reopens.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Unreviewed patches

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Jakub Jelinek wrote:
| 
| > - C++ diagnostic fix - PR c++/21983, 3.4/4.0/4.1 regression
| >   http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00285.html
| >   Bootstrapped/regtested on 7 linux arches again yesterday
| 
| This is OK, for 4.1, and for 4.0.3, after the branch reopens.

Same for 3.4.x.

-- Gaby

Unreviewed patches

[Kaveh R. Ghazi]

Here are some unreviewed patches from previous weeks:

[PATCH]: Add builtins [v]asprintf and [v]dprintf
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00165.html

[PATCH]: Add some missing format attributes
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02646.html

[PATCH]: Add even more format attributes
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02647.html

[PATCH]: Add some noreturn attributes
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02119.html

Would someone please review them?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Unreviewed patches

[Richard Kenner]

    I think if the expectation doesn't match the specification, the
    expectation is wrong.  There's no reason whatsoever to expect SImode
    to be anywhere close to 32 bits.

You mean other than about 20 years of history?

With the exception of some DSPs which were always perceived as "oddballs",
everybody "knew" that SImode was 32 bits, more or less.

Re: Unreviewed patches

[Alexandre Oliva]

On Mar 30, 2005, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     I think if the expectation doesn't match the specification, the
>     expectation is wrong.  There's no reason whatsoever to expect SImode
>     to be anywhere close to 32 bits.

> You mean other than about 20 years of history?

> With the exception of some DSPs which were always perceived as "oddballs",
> everybody "knew" that SImode was 32 bits, more or less.

I can understand that many people assumed as much and took that as
gospel, but that's not what the docs say, and that's not what GCC is
supposed to assume.  I don't see that it makes much sense to start
from a word and optionally go down to smaller addressable units.  It
makes far more sense to start with the smallest addressable unit and
go up from that.

Sure enough, calling that QImode or SImode or XYZmode makes little
difference, but since there are locations that do want to be able to
perform address computations using the minimum addressable unit size
as the unit, it makes sense to have such a unit be fixed.  I'm not
sure we could easily remove the assumption that QImode is the right
mode to access every addressable unit individually as easily as we
could fix any bugs introduced by mis-assumptions on a fixed,
well-known width for SImode.

Besides, I don't think it makes sense to impose any fixed widths for
any modes.  The current model has got us quite well up to this point,
why break it now?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Unreviewed patches

[Richard Sandiford]

Alexandre Oliva <aoliva@redhat.com> writes:
> Besides, I don't think it makes sense to impose any fixed widths for
> any modes.  The current model has got us quite well up to this point,
> why break it now?

Exactly!  The follow-ups seemed to imply that c4x was being awkward here
and that it's easy to forget GET_MODE_BITSIZE (SImode) might not be 32.
Well, maybe it is sometimes, but:

  (a) Remember that out of the two places I'm patching, one was flagged
      as wrong as soon as it went in.  It was just never corrected.

  (b) The ivopts code seems to assume that GET_MODE_BITSIZE (SImode) ==
      INT_TYPE_SIZE ("SI = Single Integer"?).  So it looks like there are
      at least three different assumptions about SImode means.  For once,
      the docs and the majority of the code seem to agree on what the
      "right" one is.

  (c) Doing it right doesn't need more code.  The fixes we're talking
      about here are one-liners.  It's just a question of using a
      different interface (lang_hooks.type_for_size instead of a
      variable reference).

Richard

Re: Unreviewed patches

[Paul Schlie]

> Zack Weinberg <zack at codesourcery dot com>
>> Alexandre Oliva <aoliva@redhat.com> writes:
>>> I'm also of the opinion that the c4x port is wrong in making QImode
>>> be 32 bits wide; that it should instead leave SImode at its usual
>>> size and not use QI or HI modes at all.
>>
>> This doesn't make sense.  BITS_PER_UNIT defines the minimal-sized
>> addressable unit, and AFAIK that's 32 bits for c4x.  QImode is, by
>> definition, an integer type whose width is BITS_PER_UNIT.
>
> The problem is that there are conflicting definitions here.  SImode is
> currently defined (by specification) as the integer type whose width
> is 4*BITS_PER_UNIT, but it is also defined (by expectation) as the
> integer type whose width is as near to 32 bits as is possible.  One of
> these things has to give, and I'm of the belief that it is less
> trouble to change the specification than the expectations.

For good or bad, GCC is heavily biased toward assuming that QI == 8 bits,
and that HI, SI, and DI modes are corresponding multiples of that basic
presumption; therefore the c4x port should likely define BITS_PER_UNIT =
SIZE_OF_CHAR = SIZE_OF_SHORT = SIZE_OF_INT == 32 == SImode, and
correspondingly UNITS_PER_WORD = 1. (As there seem no upside to choosing
otherwise, other than asking for headaches, from the best I can tell.)

If helpful, I've already submitted a patch for review which eliminates
libgcc2.h's inappropriate attempt to determine the type mode sizes for
various targets based on definitions of BITS_PER_UNIT and UNITS_PER_WORD,
and instead determine type mode requirements based upon a targets defined
type sizes directly. (presuming the above relationships, just as the bulk
of GCC does)

Re: Unreviewed patches

[Alexandre Oliva]

On Mar 29, 2005, Paul Schlie <schlie@comcast.net> wrote:

>> Zack Weinberg <zack at codesourcery dot com>
>>> Alexandre Oliva <aoliva@redhat.com> writes:
>>>> I'm also of the opinion that the c4x port is wrong in making QImode
>>>> be 32 bits wide; that it should instead leave SImode at its usual
>>>> size and not use QI or HI modes at all.
>>> 
>>> This doesn't make sense.  BITS_PER_UNIT defines the minimal-sized
>>> addressable unit, and AFAIK that's 32 bits for c4x.  QImode is, by
>>> definition, an integer type whose width is BITS_PER_UNIT.
>> 
>> The problem is that there are conflicting definitions here.  SImode is
>> currently defined (by specification) as the integer type whose width
>> is 4*BITS_PER_UNIT, but it is also defined (by expectation) as the
>> integer type whose width is as near to 32 bits as is possible.  One of
>> these things has to give, and I'm of the belief that it is less
>> trouble to change the specification than the expectations.

> For good or bad, GCC is heavily biased toward assuming that QI == 8 bits,

Where?

> and that HI, SI, and DI modes are corresponding multiples of that basic
> presumption

This is correct, per specification.

> therefore the c4x port should likely define BITS_PER_UNIT =
> SIZE_OF_CHAR = SIZE_OF_SHORT = SIZE_OF_INT == 32 == SImode, and
> correspondingly UNITS_PER_WORD = 1.

So what would HImode and QImode mean under these conditions?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Unreviewed patches

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:
> On Mar 29, 2005, Paul Schlie <schlie@comcast.net> wrote:
...
>> therefore the c4x port should likely define BITS_PER_UNIT =
>> SIZE_OF_CHAR = SIZE_OF_SHORT = SIZE_OF_INT == 32 == SImode, and
>> correspondingly UNITS_PER_WORD = 1.

Exactly what I had in mind.

> So what would HImode and QImode mean under these conditions?

There would be no HI nor QI mode on such a target.

zw

Re: Unreviewed patches

[Paul Schlie]

>> For good or bad, GCC is heavily biased toward assuming that QI == 8 bits,
> 
> Where?

- all float/double == SF/DF == 32/64 and correspondingly sized integer
  counterparts are presumed to be SI/DI 32/64 mode, correspondingly by
  implication QI/HI == 8/16, etc.

>> and that HI, SI, and DI modes are corresponding multiples of that basic
>> presumption
> 
> This is correct, per specification.
> 
>> therefore the c4x port should likely define BITS_PER_UNIT =
>> SIZE_OF_CHAR = SIZE_OF_SHORT = SIZE_OF_INT == 32 == SImode, and
>> correspondingly UNITS_PER_WORD = 1.
> 
> So what would HImode and QImode mean under these conditions?

- nothing unless the c4x implementation choose to emulate char and short
  via QI and HI mode designated operations, likely by loading then selecting
  the appropriate sub-mode data, and merging when storing into memory, etc.

Re: Unreviewed patches

[Paul Schlie]

>> Alexandre Oliva <aoliva@redhat.com> writes:
>> So what would HImode and QImode mean under these conditions?
> 
> - nothing unless the c4x implementation choose to emulate char and short
>   via QI and HI mode designated operations, likely by loading then selecting
>   the appropriate sub-mode data, and merging when storing into memory, etc.

just as 8 bit targets for example tend to not designate SI mode == 8 bits
(although that would be the target's natural "single" word size, and use
DI/TI modes for wider 16/32 bit types); but instead emulate wider types
(int, long, float, etc.) using HI/SI/etc. modes as desired as if they were
wider machines to preserve the SI mode ~ 32 ~ 4 bytes presumption (for good
or bad?)

Unreviewed patches

[Richard Sandiford]

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01840.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01849.html
Remove uses of *intSI_type_node from middle-end.  I later
discovered that this is PR 19537.

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01834.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01835.html
Add support for a MaskExists .opt flag.

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01882.html
Use .opt files for the c4x port.  Needs the two MaskExists
patches above.

Richard

Re: Unreviewed patches

[Zack Weinberg]

Richard Sandiford <rsandifo@redhat.com> writes:

> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01840.html
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01849.html
> Remove uses of *intSI_type_node from middle-end.  I later
> discovered that this is PR 19537.

These appear to be the right thing but I'm not very familiar either
with these parts of the compiler, or with the issues.  I'm also of the
opinion that the c4x port is wrong in making QImode be 32 bits wide;
that it should instead leave SImode at its usual size and not use QI
or HI modes at all.  However, I suspect that brings along its own set
of problems, and you're certainly not on the hook to make the c4x port
perfect...

> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01834.html

This is OK.

> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01835.html
> Add support for a MaskExists .opt flag.

It would be cleaner, I think, to make opth-gen.awk aware that it has
already emitted MASK_ and TARGET_ macros for a particular Mask() name,
and not do it again.  Is that feasible?

> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01882.html
> Use .opt files for the c4x port.  Needs the two MaskExists
> patches above.

This is OK modulo the above concern.

zw

Re: Unreviewed patches

[Alexandre Oliva]

On Mar 29, 2005, Zack Weinberg <zack@codesourcery.com> wrote:

> Richard Sandiford <rsandifo@redhat.com> writes:
>> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01840.html
>> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01849.html
>> Remove uses of *intSI_type_node from middle-end.  I later
>> discovered that this is PR 19537.

> I'm also of the opinion that the c4x port is wrong in making QImode
> be 32 bits wide; that it should instead leave SImode at its usual
> size and not use QI or HI modes at all.

This doesn't make sense.  BITS_PER_UNIT defines the minimal-sized
addressable unit, and AFAIK that's 32 bits for c4x.  QImode is, by
definition, an integer type whose width is BITS_PER_UNIT.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Unreviewed patches

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

>> I'm also of the opinion that the c4x port is wrong in making QImode
>> be 32 bits wide; that it should instead leave SImode at its usual
>> size and not use QI or HI modes at all.
>
> This doesn't make sense.  BITS_PER_UNIT defines the minimal-sized
> addressable unit, and AFAIK that's 32 bits for c4x.  QImode is, by
> definition, an integer type whose width is BITS_PER_UNIT.

The problem is that there are conflicting definitions here.  SImode is
currently defined (by specification) as the integer type whose width
is 4*BITS_PER_UNIT, but it is also defined (by expectation) as the
integer type whose width is as near to 32 bits as is possible.  One of
these things has to give, and I'm of the belief that it is less
trouble to change the specification than the expectations.

zw

Re: Unreviewed patches

[Alexandre Oliva]

On Mar 29, 2005, Zack Weinberg <zack@codesourcery.com> wrote:

> The problem is that there are conflicting definitions here.  SImode is
> currently defined (by specification) as the integer type whose width
> is 4*BITS_PER_UNIT, but it is also defined (by expectation) as the
> integer type whose width is as near to 32 bits as is possible.

I think if the expectation doesn't match the specification, the
expectation is wrong.  There's no reason whatsoever to expect SImode
to be anywhere close to 32 bits.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Unreviewed patches

[Richard Sandiford]

Zack Weinberg <zack@codesourcery.com> writes:
>> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01835.html
>> Add support for a MaskExists .opt flag.
>
> It would be cleaner, I think, to make opth-gen.awk aware that it has
> already emitted MASK_ and TARGET_ macros for a particular Mask() name,
> and not do it again.  Is that feasible?

It is, but:

   (a) MaskExists has the extra flexibility of allowing the mask to be
       defined elsewhere (in a target.h file, for instance).  Maybe not
       something we want to encourage but...

   (b) It provides a bit of typo protection.  At the moment, if you
       accidentally use Mask(FOO) instead of InverseMask(FOO) for a
       negative option, you'll get a redefinition warning-error.  You
       won't if the script decides for itself when MASK_ and TARGET_
       macros are needed.

   (c) it's more consistent with Var/VarExists.  I'd rather not have two
       conventions on the go: one where the script decides automatically
       and one where it doesn't.

(a) and (b) are pretty weak justifications, I admit.  (c) is my main
reason.  FWIW, I might come back and look for ways in which the
verbosity of the option flags can be reduced, and which the scripts
can do more error checking, but I'd rather do that once the basic
switch-over is complete.  I'll then have a better idea of what to do.

OTOH, if MaskExists really isn't acceptable as-is, just shout,
and I'll try to do what you suggest.

Richard

Re: Unreviewed patches

[Zack Weinberg]

Richard Sandiford <rsandifo@redhat.com> writes:

>    (a) MaskExists has the extra flexibility of allowing the mask to be
>        defined elsewhere (in a target.h file, for instance).  Maybe not
>        something we want to encourage but...
>
>    (c) it's more consistent with Var/VarExists.  I'd rather not have two
>        conventions on the go: one where the script decides automatically
>        and one where it doesn't.

These kinda go together.  VarExists is around because people need the
ability to declare those variables elsewhere.  We haven't seen a need
to do the same with masks, so I'd call YAGNI on your (c)...

>    (b) It provides a bit of typo protection.  At the moment, if you
>        accidentally use Mask(FOO) instead of InverseMask(FOO) for a
>        negative option, you'll get a redefinition warning-error.  You
>        won't if the script decides for itself when MASK_ and TARGET_
>        macros are needed.

... however, I think this is a pretty compelling argument, especially
since we don't have that much in the way of explicit testing that the
command line options do what they are supposed to do.

So go ahead with your patch as is.

BTW, something I noticed while testing the ia64 conversion for RTH --
if the last entry in the last file passed to opt-gather.awk is missing
its trailing blank line, nothing bad happens.  However, if the last
entry in any other file is missing its trailing blank line, then that
option and the first option in the next file get mangled together.
Could you look into that?  (I don't know if it's possible to fix;
awk's multiple-input-file handling may not be flexible enough.)

zw

Re: Unreviewed patches

[Richard Sandiford]

Zack Weinberg <zack@codesourcery.com> writes:
> BTW, something I noticed while testing the ia64 conversion for RTH --
> if the last entry in the last file passed to opt-gather.awk is missing
> its trailing blank line, nothing bad happens.  However, if the last
> entry in any other file is missing its trailing blank line, then that
> option and the first option in the next file get mangled together.

Ugh, thanks for the info, I hadn't come across that.  Hopefully it
shouldn't matter much now though.  The convention seems to be to add
copyright notices to each .opt file (at least, Kazu added some to the
early .opt target files and I've been sheepishly following that since).
The copyright banner includes blank lines, so we should be OK.

Richard

Re: Unreviewed patches

[Kai Henningsen]

zack@codesourcery.com (Zack Weinberg)  wrote on 29.03.05 in <877jjpmzw7.fsf@codesourcery.com>:

> BTW, something I noticed while testing the ia64 conversion for RTH --
> if the last entry in the last file passed to opt-gather.awk is missing
> its trailing blank line, nothing bad happens.  However, if the last
> entry in any other file is missing its trailing blank line, then that
> option and the first option in the next file get mangled together.
> Could you look into that?  (I don't know if it's possible to fix;
> awk's multiple-input-file handling may not be flexible enough.)

You could always concatenate the files before feeding them to awk. That,  
of course, loses any reference to the original file in messages unless you  
then insert something like the cpp line comments and look for them in awk;  
but the point is, it's then easy to just insert a blank line between any  
two files.

Somewhat uglier would be to have a file consisting of just a blank line  
and insert that on the command line between any two other files.

Or, of course, awk might be able to DTRT.


Incidentally - one other solution that occurs to me is to have an ending  
comment at the bottom of each source file, that tells you it has to be  
preceded by at least one blank line. Makes it harder to produce the  
problem in the first place.

MfG Kai

Unreviewed patches

[Jakub Jelinek]

- PR c++/19406 (HEAD)
  Fix dwarf2out ICE when cp_emit_debug_info_for_using a FIELD_DECL from
  TYPE_DECL_SUPPRESS_DEBUG aggregate
  http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01115.html

- PR rtl-optimization/16104 (3.4, HEAD)
  Handle different mode size conversions involving vectors in convert_move
  http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00726.html

- PR c/18946 (HEAD)
  Fix C ICE on invalid
  http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01328.html

- PR c/19342 (HEAD)
  Fix ICE in common_type
  http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01218.html

	Jakub

Unreviewed patches

[Kaz Kojima]

Hi,

These patches are waiting for review by global or appropriate
middle-end maintainers.

Fix mode switching for functions returning values
(Joern's patch to fix PR target/16482):
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01477.html

Fix PR target/18511:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01290.html

Regards,
	kaz

Unreviewed patches

[Eric Botcazou]

Hi,

EH-compatible -ffunction-sections:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Fix PR rtl-optimization/16028 (reload inheritance)
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01647.html

Prettify assembly output on SPARC (part #2)
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00925.html

Fix PR rtl-optimization/16294
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01167.html

Thanks in advance.

-- 
Eric Botcazou

Re: Unreviewed patches

[Zack Weinberg]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> EH-compatible -ffunction-sections:
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

I think it would be cleaner to handle this with ELF section groups.
H.J. Lu has, I believe, completed binutils support.

Also I'd like to see testing with C++ as well as Ada.

> Fix PR rtl-optimization/16028 (reload inheritance)
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01647.html

I'm not qualified to review reload patches, sorry.

> Prettify assembly output on SPARC (part #2)
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00925.html

This *would* be an OK except for the concerns you raise with regard to
final_scan_insn, hppa, and sh, which confuse the issue.  I cannot tell
if there is a problem.  If there is, please send a patch to fix it,
and then respin this patch.  If there is not, or if there is but your
patch can be proven not to make it worse, please explain.

> Fix PR rtl-optimization/16294
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01167.html

already approved elsewhere.

zw

Re: Unreviewed patches

[Eric Botcazou]

> I think it would be cleaner to handle this with ELF section groups.
> H.J. Lu has, I believe, completed binutils support.

Yes, this could work too.  The binutils support for my patch was installed 
before H.J.'s patches IIRC.

> Also I'd like to see testing with C++ as well as Ada.

I did test C++ on x86 Linux.  Not sure if this is sufficient.

> > Prettify assembly output on SPARC (part #2)
> > http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00925.html
>
> This *would* be an OK except for the concerns you raise with regard to
> final_scan_insn, hppa, and sh, which confuse the issue.  I cannot tell
> if there is a problem.  If there is, please send a patch to fix it,
> and then respin this patch.  If there is not, or if there is but your
> patch can be proven not to make it worse, please explain.

As Dave privately pointed out, I was wrong for PA: the insns are not emitted 
in delay slots, so passing 0 to final_scan_insn is just fine.  So the only 
(potentially) problematic case is SH passing 1 to final_scan_insn while not 
in delay slots.  I think it's safe to turn it to 0 (the only effect is to  
allow peepholes to be invoked on the insn if 'optimize' is non-zero), in 
which case the patch would be:

Index: config/sh/sh.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sh/sh.c,v
retrieving revision 1.282
diff -u -p -r1.282 sh.c
--- config/sh/sh.c      14 Jul 2004 21:19:37 -0000      1.282
+++ config/sh/sh.c      17 Jul 2004 18:34:06 -0000
@@ -1210,7 +1210,7 @@ output_movedouble (rtx insn ATTRIBUTE_UN
 static void
 print_slot (rtx insn)
 {
-  final_scan_insn (XVECEXP (insn, 0, 1), asm_out_file, optimize, 0, 1, 
NULL);
+  final_scan_insn (XVECEXP (insn, 0, 1), asm_out_file, optimize, 0, 0, 
NULL);

   INSN_DELETED_P (XVECEXP (insn, 0, 1)) = 1;
 }

But a confirmation from Joern would be nice.

> > Fix PR rtl-optimization/16294
> > http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01167.html
>
> already approved elsewhere.

OK.


Thanks for the review.

-- 
Eric Botcazou

Re: Unreviewed patches

[Zack Weinberg]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

>> Also I'd like to see testing with C++ as well as Ada.
>
> I did test C++ on x86 Linux.  Not sure if this is sufficient.

Can you do similar measurements to the ones you did for Ada programs,
please?  After reworking for section groups.

>> This *would* be an OK except for the concerns you raise with regard
>> to final_scan_insn, hppa, and sh, which confuse the issue.  I
>> cannot tell if there is a problem.  If there is, please send a
>> patch to fix it, and then respin this patch.  If there is not, or
>> if there is but your patch can be proven not to make it worse,
>> please explain.
>
> As Dave privately pointed out, I was wrong for PA: the insns are not
> emitted in delay slots, so passing 0 to final_scan_insn is just
> fine.  So the only (potentially) problematic case is SH passing 1 to
> final_scan_insn while not in delay slots.  I think it's safe to turn
> it to 0 (the only effect is to allow peepholes to be invoked on the
> insn if 'optimize' is non-zero), in which case the patch would be:
>
> Index: config/sh/sh.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/sh/sh.c,v
> retrieving revision 1.282
> diff -u -p -r1.282 sh.c
> --- config/sh/sh.c      14 Jul 2004 21:19:37 -0000      1.282
> +++ config/sh/sh.c      17 Jul 2004 18:34:06 -0000
> @@ -1210,7 +1210,7 @@ output_movedouble (rtx insn ATTRIBUTE_UN
>  static void
>  print_slot (rtx insn)
>  {
> -  final_scan_insn (XVECEXP (insn, 0, 1), asm_out_file, optimize, 0, 1, 
> NULL);
> +  final_scan_insn (XVECEXP (insn, 0, 1), asm_out_file, optimize, 0, 0, 
> NULL);
>
>    INSN_DELETED_P (XVECEXP (insn, 0, 1)) = 1;
>  }
>
> But a confirmation from Joern would be nice.

I believe that there is an SH emulator in the gdb tree, which would
allow you to test this.

zw

Re: Unreviewed patches

[Eric Botcazou]

> I believe that there is an SH emulator in the gdb tree, which would
> allow you to test this.

Ouch!  I'm not sure the ratio benefit/cost is very appealing.

-- 
Eric Botcazou

Re: Unreviewed patches

[Zack Weinberg]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

>> I believe that there is an SH emulator in the gdb tree, which would
>> allow you to test this.
>
> Ouch!  I'm not sure the ratio benefit/cost is very appealing.

That's up to you - but I'm not about to approve the patch without
test results, a comment from the SH maintainers, or ideally both.

zw

Re: Unreviewed patches

[Eric Botcazou]

> That's up to you - but I'm not about to approve the patch without
> test results, a comment from the SH maintainers, or ideally both.

I understand.  Thanks again for spending a bit of your time on my patches.

-- 
Eric Botcazou

Re: Unreviewed patches

[Joern Rennecke]

> 
> > I believe that there is an SH emulator in the gdb tree, which would
> > allow you to test this.
> 
> Ouch!  I'm not sure the ratio benefit/cost is very appealing.

You can use the gdb simulator stand-alone, whne you build all-sim in
the unified tree, it is built as sim/sh/run.
This simulator has adequate performance; is actually used for the
automated SH regression tests.

However, I can tell you now just from looking at the code that
your proposed change is both unsafe and inappropriate.
print_slot is used in some places to actually emit a delay slot insn -
there using 0 would be inappropriate - and in other places it is used
to emit the delay slot insn before the jump, there it would be unsafe
to do peepholes.

Re: Unreviewed patches

[Eric Botcazou]

> However, I can tell you now just from looking at the code that
> your proposed change is both unsafe and inappropriate.
> print_slot is used in some places to actually emit a delay slot insn -
> there using 0 would be inappropriate - and in other places it is used
> to emit the delay slot insn before the jump, there it would be unsafe
> to do peepholes.

Ok, thanks for the clarification.  Any plan to get rid of those annoying
peepholes in the near future? ;-)

--
Eric Botcazou

Re: Unreviewed patches

[Joern Rennecke]

> 
> > However, I can tell you now just from looking at the code that
> > your proposed change is both unsafe and inappropriate.
> > print_slot is used in some places to actually emit a delay slot insn -
> > there using 0 would be inappropriate - and in other places it is used
> > to emit the delay slot insn before the jump, there it would be unsafe
> > to do peepholes.
> 
> Ok, thanks for the clarification.  Any plan to get rid of those annoying
> peepholes in the near future? ;-)

No.  They actually have their place, some things you want to do after
scheduling and/or branch shortening.  Unless you want to add another
peephole2 pass and a way to check global variables which pass you are in,
of course.

Why don't you add another parameter to final_scan_insn?

Re: Unreviewed patches

[Eric Botcazou]

> Why don't you add another parameter to final_scan_insn?

The initial idea was to penalize as little as possible the other platforms
(without delay slots), so adding yet another unused parameter seemed to be
overkill.

--
Eric Botcazou

Re: Unreviewed patches

[Joern Rennecke]

> 
> > Why don't you add another parameter to final_scan_insn?
> 
> The initial idea was to penalize as little as possible the other platforms
> (without delay slots), so adding yet another unused parameter seemed to be
> overkill.

How about a flags parameter then?  Or if you want to go for absolute
minimum overhead, you can use a ternary value, i.e.

greater than zero: apply peepholes.
zero: don't apply peepholes.
less than zero: in delay slot, don't apply peepholes.

Re: Unreviewed patches

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

> How about a flags parameter then?  Or if you want to go for absolute
> minimum overhead, you can use a ternary value, i.e.
>
> greater than zero: apply peepholes.
> zero: don't apply peepholes.

Thanks for the tip.  And, since I don't want to deal with those peculiar 
back-ends anymore :-), I simply added a new state numbered 2 to 
the 'nopeepholes' parameter (after checking that every call to 
final_scan_insn currently uses 0 or 1).

Is this ok with you, Zack (after the usual testing of course)?  Or do you 
want me to add "#if DELAY_SLOTS/#endif" pairs?


2004-09-03  Eric Botcazou  <ebotcazou@libertysurf.fr>

        * final.c (output_in_slot): New global variable.
        (final_scan_insn): Add new state '2' to the 'nopeepholes' parameter.
        Pass 2 as 'nopeepholes' to self for insns in a SEQUENCE.  Set
	'output_in_slot' before invoking output_asm_insn.
        (output_asm_insn): Add a space after the tab if 'output_in_slot'
        is set.
	* config/sparc/sparc.c (output_return): Pass 2 as 'nopeepholes' to
	final_scan_insn.
	(output_sibcall): Likewise.


-- 
Eric Botcazou

[-- Attachment #2: sparc_prettify-2b.diff --]
[-- Type: text/x-diff, Size: 3705 bytes --]

Index: final.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/final.c,v
retrieving revision 1.332
diff -u -p -r1.332 final.c
--- final.c	25 Aug 2004 08:20:08 -0000	1.332
+++ final.c	3 Sep 2004 12:40:58 -0000
@@ -200,6 +200,10 @@ static int app_on;
 
 rtx final_sequence;
 
+/* True if we are outputting insns in a delay slot.  This is used to prettify
+   the assembly output.  */
+static bool output_in_slot;
+
 #ifdef ASSEMBLER_DIALECT
 
 /* Number of the assembler dialect to use, starting at 0.  */
@@ -1663,8 +1667,11 @@ scan_ahead_for_unlikely_executed_note (r
    is the insn being scanned.
    Value returned is the next insn to be scanned.
 
-   NOPEEPHOLES is the flag to disallow peephole processing (currently
-   used for within delayed branch sequence output).
+   NOPEEPHOLES is used to disallow peephole processing:
+    - 0: peepholes are allowed,
+    - 1: peepholes are not allowed,
+    - 2: peepholes are not allowed and we are in the
+         slot of a delayed branch.
 
    SEEN is used to track the end of the prologue, for emitting
    debug information.  We force the emission of a line note after
@@ -1674,8 +1681,7 @@ scan_ahead_for_unlikely_executed_note (r
 
 rtx
 final_scan_insn (rtx insn, FILE *file, int optimize ATTRIBUTE_UNUSED,
-		 int prescan, int nopeepholes ATTRIBUTE_UNUSED,
-		 int *seen)
+		 int prescan, int nopeepholes, int *seen)
 {
 #ifdef HAVE_cc0
   rtx set;
@@ -2195,7 +2201,7 @@ final_scan_insn (rtx insn, FILE *file, i
 		/* We loop in case any instruction in a delay slot gets
 		   split.  */
 		do
-		  insn = final_scan_insn (insn, file, 0, prescan, 1, seen);
+		  insn = final_scan_insn (insn, file, 0, prescan, 2, seen);
 		while (insn != next);
 	      }
 #ifdef DBR_OUTPUT_SEQEND
@@ -2527,7 +2533,9 @@ final_scan_insn (rtx insn, FILE *file, i
 #endif
 
 	/* Output assembler code from the template.  */
+	output_in_slot = (nopeepholes > 1);
 	output_asm_insn (template, recog_data.operand);
+	output_in_slot = false;
 
 	/* If necessary, report the effect that the instruction has on
 	   the unwind info.   We've already done this for delay slots
@@ -2988,6 +2996,8 @@ output_asm_insn (const char *template, r
   memset (opoutput, 0, sizeof opoutput);
   p = template;
   putc ('\t', asm_out_file);
+  if (output_in_slot)
+    putc (' ', asm_out_file);
 
 #ifdef ASM_OUTPUT_OPCODE
   ASM_OUTPUT_OPCODE (asm_out_file, p);
Index: config/sparc/sparc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sparc/sparc.c,v
retrieving revision 1.329
diff -u -p -r1.329 sparc.c
--- config/sparc/sparc.c	18 Aug 2004 21:08:34 -0000	1.329
+++ config/sparc/sparc.c	3 Sep 2004 12:41:20 -0000
@@ -4707,7 +4707,7 @@ output_return (rtx insn)
 	  if (! delay)
 	    abort ();
 
-	  final_scan_insn (delay, asm_out_file, 1, 0, 1, NULL);
+	  final_scan_insn (delay, asm_out_file, 1, 0, 2, NULL);
 	  PATTERN (delay) = gen_blockage ();
 	  INSN_CODE (delay) = -1;
 	}
@@ -4756,7 +4756,7 @@ output_return (rtx insn)
 	      epilogue_renumber (&pat, 0);
 	      fprintf (asm_out_file, "\treturn\t%%i7+%d\n",
 		       sparc_skip_caller_unimp ? 12 : 8);
-	      final_scan_insn (delay, asm_out_file, 1, 0, 1, NULL);
+	      final_scan_insn (delay, asm_out_file, 1, 0, 2, NULL);
 	    }
 	  else
 	    {
@@ -4817,7 +4817,7 @@ output_sibcall (rtx insn, rtx call_opera
 
 	  output_asm_insn ("sethi\t%%hi(%a0), %%g1", operands);
 	  output_asm_insn ("jmp\t%%g1 + %%lo(%a0)", operands);
-	  final_scan_insn (delay, asm_out_file, 1, 0, 1, NULL);
+	  final_scan_insn (delay, asm_out_file, 1, 0, 2, NULL);
 
 	  PATTERN (delay) = gen_blockage ();
 	  INSN_CODE (delay) = -1;

Re: Unreviewed patches

[Zack Weinberg]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

>> How about a flags parameter then?  Or if you want to go for absolute
>> minimum overhead, you can use a ternary value, i.e.
>>
>> greater than zero: apply peepholes.
>> zero: don't apply peepholes.
>
> Thanks for the tip.  And, since I don't want to deal with those peculiar 
> back-ends anymore :-), I simply added a new state numbered 2 to 
> the 'nopeepholes' parameter (after checking that every call to 
> final_scan_insn currently uses 0 or 1).
>
> Is this ok with you, Zack (after the usual testing of course)?  Or do you 
> want me to add "#if DELAY_SLOTS/#endif" pairs?

This is OK with me.

zw

Unreviewed patches

[Eric Botcazou]

Hi,

EH-compatible -ffunction-sections:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Fix PR target/15082 (makefile machinery)
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00173.html

Thanks in advance.

-- 
Eric Botcazou

Re: Unreviewed patches

[Alexandre Oliva]

On Jun 19, 2004, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

> Fix PR target/15082 (makefile machinery)
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00173.html

Sorry for having missed the patch at first.

I'm afraid it is not correct. 

When building a cross compiler to a hosted OS, you have two options:

- use --with-headers/--with-libs (deprecated), and these will copy
  stuff to sys-include and lib, or

- use --with-sysroot, and make sure the sysroot already contains a
  copy/link/whatever of the relevant bits of relevant headers,
  libraries and object files you expect to find in the root filesystem
  or the target OS.


In either case, the goal is to not touch the install tree during
compilation.  Sure enough, --with-headers/libs do touch the install
tree, but they were broken by design, which is just one of the reasons
for the switch to --with-sysroot.

This is why we no longer run recursively invoke the
install-gcc-tooldir target from stmp-fixinc, and instead just print a
warning.

One thing we could do to improve this significantly, however, is to
take advantage of the fact that we no longer need to use
${gcc_tooldir} for pathnames to be relocated correctly if you move the
install tree after installation.  I'd be quite happy to review and
hopefully approve a change to configure.ac that changed the default
setting of CROSS_SYSTEM_HEADER_DIR to look more like the definition in
the --with-sysroot case, and a corresponding change in Makefile.in
such that we not fail when compiling for embedded targets that don't
have a root filesystem.  Would you give that a try?

Thanks,

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Unreviewed patches

[Eric Botcazou]

> When building a cross compiler to a hosted OS, you have two options:
>
> - use --with-headers/--with-libs (deprecated), and these will copy
>   stuff to sys-include and lib, or
>
> - use --with-sysroot, and make sure the sysroot already contains a
>   copy/link/whatever of the relevant bits of relevant headers,
>   libraries and object files you expect to find in the root filesystem
>   or the target OS.
>
>
> In either case, the goal is to not touch the install tree during
> compilation.  Sure enough, --with-headers/libs do touch the install
> tree, but they were broken by design, which is just one of the reasons
> for the switch to --with-sysroot.
>
> This is why we no longer run recursively invoke the
> install-gcc-tooldir target from stmp-fixinc, and instead just print a
> warning.

Thanks for the review and the clarification.

> One thing we could do to improve this significantly, however, is to
> take advantage of the fact that we no longer need to use
> ${gcc_tooldir} for pathnames to be relocated correctly if you move the
> install tree after installation.  I'd be quite happy to review and
> hopefully approve a change to configure.ac that changed the default
> setting of CROSS_SYSTEM_HEADER_DIR to look more like the definition in
> the --with-sysroot case, and a corresponding change in Makefile.in
> such that we not fail when compiling for embedded targets that don't
> have a root filesystem.  Would you give that a try?

Unfortunately, I know next to nothing about the makefile/configure machinery 
and have very little interest in building complete cross-toolchains for the 
time being.  I only cared about the PR because the original patch was 
modifying a file in config/sparc and thought it was not correct either.

I'm going to add a link to your suggestion in the PR audit trail.

-- 
Eric Botcazou

Unreviewed patches

[Eric Botcazou]

Hi,

Clarify description of -static-libgcc:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01712.html

EH-compatible -ffunction-sections:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Fix ACATS failure on i586:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01779.html

Fix PR target/15082:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00173.html

Fix ACATS failures on SPARC:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00286.html

Thanks in advance.

-- 
Eric Botcazou

Re: Unreviewed patches

[Roger Sayle]

On Mon, 31 May 2004, Eric Botcazou wrote:
> Clarify description of -static-libgcc:
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01712.html

This is OK.


> Fix ACATS failure on i586:
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01779.html

This is OK for mainline.


> Fix ACATS failures on SPARC:
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00286.html

This is OK for mainline.


Are these ACATS failures 3.4.x regressions?  If so, you might
want to ask Mark about backporting these patches for gcc 3.4.1
after they've been on mainline for a few days without problems.


Roger
--

Re: Unreviewed patches

[Eric Botcazou]

> Are these ACATS failures 3.4.x regressions?  If so, you might
> want to ask Mark about backporting these patches for gcc 3.4.1
> after they've been on mainline for a few days without problems.

No, I don't think they qualify as regressions.  And don't count on me to put 
a reload patch on a release branch! :-)

Thanks for this review and your time.

-- 
Eric Botcazou

Unreviewed patches

[Eric Botcazou]

Hi,

Clarify description of -static-libgcc:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01712.html

EH-compatible -ffunction-sections:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Fix ACATS failure on i586:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01779.html

Fix PR target/15082:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00173.html

Fix ACATS failures on SPARC:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00286.html

Thanks in advance.

-- 
Eric Botcazou

Unreviewed patches

[Eric Botcazou]

Hi,

Clarify description of -static-libgcc:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01712.html

EH-compatible -ffunction-sections:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Fix ACATS failure on i586:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01779.html

Fix PR optimization/11841:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01895.html

Fix PR target/15082:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00173.html

Fix ACATS failures on SPARC:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00286.html

Thanks in advance.

-- 
Eric Botcazou

unreviewed patches

[Caroline Tice]

The following patches still need to be reviewed:

New optimization, partitioning hot/cold basic  blocks     (It did pass 
all the tests...)
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

Clean up driver processing for IMA
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02101.html

Thanks!

-- Caroline Tice
ctice@apple.com

Re: unreviewed patches

[Zack Weinberg]

Caroline Tice <ctice@apple.com> writes:

> The following patches still need to be reviewed:
>
> New optimization, partitioning hot/cold basic  blocks     (It did pass
> all the tests...)
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

People raised a *lot* of concerns about this and it's not clear to me
that they were all adequately addressed.

> Clean up driver processing for IMA
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02101.html

This one is OK; however, please (as a followup) check into the
interaction with the Java front end, which has similar capabilities.

zw

Re: unreviewed patches

[Caroline Tice]

On Apr 3, 2004, at 1:03 PM, Zack Weinberg wrote:

> Caroline Tice <ctice@apple.com> writes:
>
>> The following patches still need to be reviewed:
>>
>> New optimization, partitioning hot/cold basic  blocks     (It did pass
>> all the tests...)
>> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>
>
> People raised a *lot* of concerns about this and it's not clear to me
> that they were all adequately addressed.
>
>

I have made a very serious attempt to address everybody's concerns, and 
was under
the impression that I had done so.  If I have missed something, I 
apologize  and would
appreciate your pointing it (them?) out to me.  Thanks!

-- Caroline Tice
ctice@apple.com

Re: unreviewed patches

[Caroline Tice]

On Apr 3, 2004, at 1:03 PM, Zack Weinberg wrote:

> Caroline Tice <ctice@apple.com> writes:
>
>> The following patches still need to be reviewed:
>>
>> New optimization, partitioning hot/cold basic  blocks     (It did pass
>> all the tests...)
>> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>
>
> People raised a *lot* of concerns about this and it's not clear to me
> that they were all adequately addressed.
>
>

I have made a very serious attempt to address everybody's concerns, and 
was under
the impression that I had done so.  If I have missed something, I 
apologize  and would
appreciate your pointing it (them?) out to me.  Thanks!

-- Caroline Tice
ctice@apple.com

Re: unreviewed patches

[Caroline Tice]

On Apr 3, 2004, at 1:03 PM, Zack Weinberg wrote:

> Caroline Tice <ctice@apple.com> writes:
>
>> The following patches still need to be reviewed:
>>
>> New optimization, partitioning hot/cold basic  blocks     (It did pass
>> all the tests...)
>> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>
>
> People raised a *lot* of concerns about this and it's not clear to me
> that they were all adequately addressed.
>
>

I have made a very serious attempt to address everybody's concerns, and 
was under
the impression that I had done so.  If I have missed something, I 
apologize  and would
appreciate your pointing it (them?) out to me.  Thanks!

-- Caroline Tice
ctice@apple.com

Re: unreviewed patches

[Zack Weinberg]

Caroline Tice <ctice@apple.com> writes:

> The following patches still need to be reviewed:
>
> New optimization, partitioning hot/cold basic  blocks     (It did pass
> all the tests...)
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

People raised a *lot* of concerns about this and it's not clear to me
that they were all adequately addressed.

> Clean up driver processing for IMA
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02101.html

This one is OK; however, please (as a followup) check into the
interaction with the Java front end, which has similar capabilities.

zw

Re: unreviewed patches

[Zack Weinberg]

Caroline Tice <ctice@apple.com> writes:

> The following patches still need to be reviewed:
>
> New optimization, partitioning hot/cold basic  blocks     (It did pass
> all the tests...)
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

People raised a *lot* of concerns about this and it's not clear to me
that they were all adequately addressed.

> Clean up driver processing for IMA
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02101.html

This one is OK; however, please (as a followup) check into the
interaction with the Java front end, which has similar capabilities.

zw

unreviewed patches

[Caroline Tice]

The following patches still need to be reviewed:

New optimization, partitioning hot/cold basic  blocks     (It did pass 
all the tests...)
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

Clean up driver processing for IMA
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02101.html

Thanks!

-- Caroline Tice
ctice@apple.com

Re: unreviewed patches

[Geoff Keating]

Caroline Tice <ctice@apple.com> writes:

> The following patches still need to be reviewed:
> 
> New optimization, partitioning hot/cold basic  blocks     (It did pass
> all the tests...)
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

This is OK.  I believe all the comments were addressed.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: unreviewed patches

[Geoff Keating]

Caroline Tice <ctice@apple.com> writes:

> The following patches still need to be reviewed:
> 
> New optimization, partitioning hot/cold basic  blocks     (It did pass
> all the tests...)
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

This is OK.  I believe all the comments were addressed.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

unreviewed patches

[Caroline Tice]

The following patches still need to be reviewed:

New optimization, partitioning hot/cold basic  blocks     (It did pass 
all the tests...)
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01318.html>

Clean up driver processing for IMA
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02101.html

Thanks!

-- Caroline Tice
ctice@apple.com

Unreviewed patches

[Ulrich Weigand]

[PATCH] Bad code due to reload inheritance bug
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01932.html

[PATCH] Fix PR 14262 breakage on Darwin
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02048.html

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Unreviewed patches

[Gábor Lóki]

Hi,

the following patches hasn't been reviewed in depth for some time:

(2003-02) - PATCH: new peephole2 in arm.md (PR9663)
       new peephole2 pattern added for extending move and compare
       parallelization
      http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00204.html

(2004-02) - [patch] adding more crossjumping cleanup in toplev.c
       insert more cleanup_cfg to get smaller cfg
     http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02098.html

(2004-03) - [patch] function inlining when optimize for size (PR11830)
     http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01350.html

(2004-03) - [patch] Local factoring algorithms
       merge identical rtl insns by moving them to a point that pre-
       or post-dominates all occurrences
     http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01907.html

(2004-03) - [PATCH] Sequence abstraction
       mimic a call/return mechanism to merge identical sequences of RTL
     http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01921.html

Regards,
   GĂĄbor LĂłki

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these?

[patch] Remove flow_preorder_transversal_compute.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02324.html

Zack reviewed the above once and suggested me to look for places where
this function should be used.  Well, AFAIK, it was added as a part of
John Wehle's Value Range Propagation patch, but VRP never made it into
the repository even though several helper functions did, so this patch
should be OK.

[patch] postreload.c: Teach move2add how to handle single_set.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02613.html

Thanks,

Kazu Hirata

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these?

[patch] Remove flow_preorder_transversal_compute.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02324.html

Zack reviewed the above once and suggested me to look for places where
this function should be used.  Well, AFAIK, it was added as a part of
John Wehle's Value Range Propagation patch, but VRP never made it into
the repository even though several helper functions did, so this patch
should be OK.

[patch] postreload.c: Teach move2add how to handle single_set.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02613.html

Thanks,

Kazu Hirata

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these?

Improvements
------------

[patch] postreload.c: Minor memory saving in move2add.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01907.html

Cleanups
--------

[patch] Remove c_expand_deferred_function().
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01846.html

[patch] Remove FINAL_REG_PARM_STACK_SPACE and MAYBE_REG_PARM_STACK_SPACE.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02123.html

[patch] Remove three unused functions in optabs.c.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01858.html

[patch] Remove validate_replace_src().
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01811.html

[patch] Remove expand_start_case_dummy.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01808.html

[patch] Remove is_pending_size().
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01809.html

[patch] Remove apply_args_register_offset().
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02323.html

[patch] Remove flow_preorder_transversal_compute.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02324.html

[patch] Remove flow_loops_update.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02325.html

Thanks,

Kazu Hirata

Re: Unreviewed patches

[Zack Weinberg]

Kazu Hirata <kazu@cs.umass.edu> writes:

> Hi,
>
> Could somebody review these?
>
> Improvements
> ------------
>
> [patch] postreload.c: Minor memory saving in move2add.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01907.html
>
> Cleanups
> --------
>
> [patch] Remove c_expand_deferred_function().
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01846.html
>
> [patch] Remove FINAL_REG_PARM_STACK_SPACE and MAYBE_REG_PARM_STACK_SPACE.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02123.html
>
> [patch] Remove validate_replace_src().
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01811.html
>
> [patch] Remove is_pending_size().
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01809.html
>
> [patch] Remove apply_args_register_offset().
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02323.html
>

These are all OK.

> [patch] Remove expand_start_case_dummy.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01808.html

Ok; please check whether any of the other case-statement handling is
now dead.

> [patch] Remove three unused functions in optabs.c.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01858.html
>
> [patch] Remove flow_preorder_transversal_compute.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02324.html
>
> [patch] Remove flow_loops_update.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02325.html
>

Please investigate whether there are any places that ought to be using
these functions but aren't.

zw

Re: Unreviewed patches

[Kazu Hirata]

Hi Zack,

> > Could somebody review these?
> 
> These are all OK.

Thanks.

> > [patch] Remove expand_start_case_dummy.
> > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01808.html
> 
> Ok; please check whether any of the other case-statement handling is
> now dead.

There are some functions in this area that are only called from
Fortran and Java front-ends.  I'll come back here after tree-ssa
merge.

> > [patch] Remove three unused functions in optabs.c.
> > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01858.html

I can't comment on this right away.

> > [patch] Remove flow_preorder_transversal_compute.
> > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02324.html

This one was added as a part of John Wehle's Value Range Propagation
patch.  AFAIK, VRP never made it into the repository even though
several helper functions did, some of which are in rtlanal.c, so IMHO
this patch should be OK.

> > [patch] Remove flow_loops_update.
> > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02325.html

One thing I can say is that this seems to be unused since day one.

Kazu Hirata

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these patches?

Improvements
------------

[patch] function.c: Move USE as far down as possible.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00144.html

Internationalization
--------------------

[patch] Allow translation of the copyright symbol. (take 3)
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01277.html

Testsuite fixes
---------------

[patch] Enable 20040130-1.c and 961203-1.c only when __INT_MAX__>= 2147483647L.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00881.html

Cleanup
-------

[patch] loop.c: Remove #if 0'ed all_sets_invariant_p().
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00705.html

[patch] Remove commented-out/useless definitions of CASE_VECTOR_PC_RELATIVE.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00625.html

[patch] emit-rtl.c: Remove 3 unused functions.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00697.html

[patch] *hooks.[ch]: Remove unused generic hooks.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00698.html

[patch] mcore: Remove ASM_OUTPUT_EXTERNAL.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01357.html
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02610.html
This one is partially reviewed, but no decision has been made.

Thanks,

Kazu Hirata

Re: Unreviewed patches

[Jim Wilson]

Kazu Hirata wrote:
> [patch] loop.c: Remove #if 0'ed all_sets_invariant_p().
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00705.html

OK.

> [patch] Remove commented-out/useless definitions of CASE_VECTOR_PC_RELATIVE.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00625.html

OK.  There is a typo in the ChangeLog entry CASE_PC_RELATIVE -> 
CASE_VECTOR_PC_RELATIVE.

> [patch] emit-rtl.c: Remove 3 unused functions.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00697.html

OK.

> [patch] *hooks.[ch]: Remove unused generic hooks.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00698.html

OK.

> [patch] mcore: Remove ASM_OUTPUT_EXTERNAL.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01357.html
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02610.html
> This one is partially reviewed, but no decision has been made.

That was my partial review, and Nick didn't comment on it.  This is OK, 
but you must also delete the orphaned comment, as it is no longer of any 
use, and is confusing if you leave it in.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Unreviewed patches

[Jim Wilson]

Kazu Hirata wrote:
> [patch] loop.c: Remove #if 0'ed all_sets_invariant_p().
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00705.html

OK.

> [patch] Remove commented-out/useless definitions of CASE_VECTOR_PC_RELATIVE.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00625.html

OK.  There is a typo in the ChangeLog entry CASE_PC_RELATIVE -> 
CASE_VECTOR_PC_RELATIVE.

> [patch] emit-rtl.c: Remove 3 unused functions.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00697.html

OK.

> [patch] *hooks.[ch]: Remove unused generic hooks.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00698.html

OK.

> [patch] mcore: Remove ASM_OUTPUT_EXTERNAL.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01357.html
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02610.html
> This one is partially reviewed, but no decision has been made.

That was my partial review, and Nick didn't comment on it.  This is OK, 
but you must also delete the orphaned comment, as it is no longer of any 
use, and is confusing if you leave it in.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Unreviewed patches

[Jim Wilson]

Kazu Hirata wrote:
> [patch] function.c: Move USE as far down as possible.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00144.html

There can be more than one USE.  Note that diddle_function_return 
handles PARALLEL, in which case multiple USEs are emitted.  For 
instance, build a mipsisa64-elf target, and compile a function that 
returns complex float.

Maybe we should verify that this is a return reg?  In the simple case, 
you can check REG_FUNCTION_VALUE_P, but that doesn't work when the 
return value is a PARALLEL.  We could use FUNCTION_VALUE_REGNO_P.  This 
check is probably not important.

You check for a register in the USE.  I wonder if anything else can 
appear here, like a SUBREG, or a STRICT_LOW_PART.  It seems unlikely, 
but if it does happen, then a USE insn does not get moved.  This is 
probably not important.

When scanning insns, you only special case JUMP_INSNS.  You should 
probably also special case other things like CODE_LABEL, CALL_INSN.  We 
shouldn't make assumptions about what might appear here.  Maybe just 
modify the code to check for GET_CODE (insn) != INSN instead of GET_CODE 
(insn) == JUMP_INSN?

Instead of using delete_insn/emit_insn_before, you should use 
reorder_insns.  See the other examples in the same function that move 
instructions around.

Long term, I think it is better to try to eliminate these 
end-of-function USE markers than to try to add more special purpose code 
for them.

Another issue, why does a USE inhibit peephole2 optimization anyways? 
There seems to be no reason for it to do so.  You could try modifying 
the peephole2 optimizer to ignore USE insns.

> [patch] Allow translation of the copyright symbol. (take 3)
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01277.html

OK.

> [patch] Enable 20040130-1.c and 961203-1.c only when __INT_MAX__>= 2147483647L.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00881.html

OK.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Unreviewed patches

[Jim Wilson]

Kazu Hirata wrote:
> [patch] function.c: Move USE as far down as possible.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00144.html

There can be more than one USE.  Note that diddle_function_return 
handles PARALLEL, in which case multiple USEs are emitted.  For 
instance, build a mipsisa64-elf target, and compile a function that 
returns complex float.

Maybe we should verify that this is a return reg?  In the simple case, 
you can check REG_FUNCTION_VALUE_P, but that doesn't work when the 
return value is a PARALLEL.  We could use FUNCTION_VALUE_REGNO_P.  This 
check is probably not important.

You check for a register in the USE.  I wonder if anything else can 
appear here, like a SUBREG, or a STRICT_LOW_PART.  It seems unlikely, 
but if it does happen, then a USE insn does not get moved.  This is 
probably not important.

When scanning insns, you only special case JUMP_INSNS.  You should 
probably also special case other things like CODE_LABEL, CALL_INSN.  We 
shouldn't make assumptions about what might appear here.  Maybe just 
modify the code to check for GET_CODE (insn) != INSN instead of GET_CODE 
(insn) == JUMP_INSN?

Instead of using delete_insn/emit_insn_before, you should use 
reorder_insns.  See the other examples in the same function that move 
instructions around.

Long term, I think it is better to try to eliminate these 
end-of-function USE markers than to try to add more special purpose code 
for them.

Another issue, why does a USE inhibit peephole2 optimization anyways? 
There seems to be no reason for it to do so.  You could try modifying 
the peephole2 optimizer to ignore USE insns.

> [patch] Allow translation of the copyright symbol. (take 3)
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01277.html

OK.

> [patch] Enable 20040130-1.c and 961203-1.c only when __INT_MAX__>= 2147483647L.
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00881.html

OK.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these patches?

Improvements
------------

[patch] function.c: Move USE as far down as possible.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00144.html

Internationalization
--------------------

[patch] Allow translation of the copyright symbol. (take 3)
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01277.html

Testsuite fixes
---------------

[patch] Enable 20040130-1.c and 961203-1.c only when __INT_MAX__>= 2147483647L.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00881.html

Cleanup
-------

[patch] loop.c: Remove #if 0'ed all_sets_invariant_p().
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00705.html

[patch] Remove commented-out/useless definitions of CASE_VECTOR_PC_RELATIVE.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00625.html

[patch] emit-rtl.c: Remove 3 unused functions.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00697.html

[patch] *hooks.[ch]: Remove unused generic hooks.
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00698.html

[patch] mcore: Remove ASM_OUTPUT_EXTERNAL.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01357.html
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02610.html
This one is partially reviewed, but no decision has been made.

Thanks,

Kazu Hirata

Unreviewed patches

[Ulrich Weigand]

Hello,

the following patches are still unreviewed:

[PATCH] Fix PR debug/11816
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03172.html

[PATCH] Minor loop optimizer enhancement
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03170.html

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Unreviewed patches

[Ulrich Weigand]

Hello,

the following patches are still unreviewed:

[PATCH] Fix PR debug/11816
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03172.html

[PATCH] Minor loop optimizer enhancement
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03170.html

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these?

[patch] arc: Hookize some macros. (part 2)
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03225.html

[patch] fr30: Hookize some target macros. (part 2)
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03230.html

[patch] frv: Hookize TARGET_SETUP_INCOMING_VARARGS.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03253.html

[patch] Fix dangerous implementations of *_return_in_memory.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03500.html

[patch] reload1.c: Improve register elimination.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03252.html

Thanks,

Kazu Hirata

Re: Unreviewed patches

[Roger Sayle]

On Thu, 5 Feb 2004, Kazu Hirata wrote:
> [patch] arc: Hookize some macros. (part 2)
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03225.html
Ok

> [patch] fr30: Hookize some target macros. (part 2)
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03230.html
Ok

> [patch] frv: Hookize TARGET_SETUP_INCOMING_VARARGS.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03253.html
Ok

> [patch] Fix dangerous implementations of *_return_in_memory.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03500.html
Ok

As always, port maintainers that are unhappy with these approvals
should feel free to revert the changes to their backends.


> [patch] reload1.c: Improve register elimination.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03252.html

Ok.  Eventually, I think reload may need to call simplify_rtx after
some of the changes that it makes (such as replacing a pseudo with
const0_rtx).  However that's a different patch for another day...


Thanks.

Roger
--

Re: Unreviewed patches

[Roger Sayle]

On Thu, 5 Feb 2004, Kazu Hirata wrote:
> [patch] arc: Hookize some macros. (part 2)
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03225.html
Ok

> [patch] fr30: Hookize some target macros. (part 2)
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03230.html
Ok

> [patch] frv: Hookize TARGET_SETUP_INCOMING_VARARGS.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03253.html
Ok

> [patch] Fix dangerous implementations of *_return_in_memory.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03500.html
Ok

As always, port maintainers that are unhappy with these approvals
should feel free to revert the changes to their backends.


> [patch] reload1.c: Improve register elimination.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03252.html

Ok.  Eventually, I think reload may need to call simplify_rtx after
some of the changes that it makes (such as replacing a pseudo with
const0_rtx).  However that's a different patch for another day...


Thanks.

Roger
--

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these?

[patch] arc: Hookize some macros. (part 2)
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03225.html

[patch] fr30: Hookize some target macros. (part 2)
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03230.html

[patch] frv: Hookize TARGET_SETUP_INCOMING_VARARGS.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03253.html

[patch] Fix dangerous implementations of *_return_in_memory.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03500.html

[patch] reload1.c: Improve register elimination.
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03252.html

Thanks,

Kazu Hirata

Unreviewed patches

[Roger Sayle]

Its only been a week, but they were submitted last month :>

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02694.html
PR middle-end/13696: Don't call convert from fold

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02805.html
PR target/9348: RTL expansion bug for widening multiply


Roger
--
"Two pings, Vasily!"

Unreviewed patches

[Roger Sayle]

Its only been a week, but they were submitted last month :>

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02694.html
PR middle-end/13696: Don't call convert from fold

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02805.html
PR target/9348: RTL expansion bug for widening multiply


Roger
--
"Two pings, Vasily!"

Unreviewed patches

[Dan Nicolaescu]

I have 3 patches for mainline for improving the stats collection for
memory allocation. All the code the patches add is disabled by
default, so they should be safe at this point. 

The patch at:
 http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01339.html  

adds a configure flag to define GATHER_STATISTICS. Currently one has
to hack config.h to do that.. 

http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00407.html

adds some more details to the memory allocation stats

http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02058.html

prints details about RTX allocations


Please check the patches in if approved, I don't have commit access. 
I can provide up to date versions. 

Re: Unreviewed patches

[Jim Wilson]

Dan Nicolaescu wrote:
> I have 3 patches for mainline for improving the stats collection for
> memory allocation. All the code the patches add is disabled by
> default, so they should be safe at this point. 

>  http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01339.html  
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00407.html
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02058.html

OK.  I checked them in.  They do appear to be harmless, and provide 
better memory tracking statistics.

I tested this with an i686-linux bootstrap and make check to be sure.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Unreviewed patches

[Joern Rennecke]

http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02022.html

2003-11-25  J"orn Rennecke <joern.rennecke@superh.com>

        * loop.c (loop_invariant_p): Amend comment about where new registers
        might come from.


http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01299.html

2003-09-02  J"orn Rennecke <joern.rennecke@superh.com>

        * reload.c (reg_overlap_mentioned_for_reload_p):
        When looking at a PLUS in X, avoid spuriously returning nonzero
        when IN is a REG or another simple PLUS, or a MEM containing one.

See also http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01912.html
why the fixed bug is a regression.

Re: Unreviewed patches

[Zack Weinberg]

Joern Rennecke <amylaar@cs.tu-berlin.de> writes:

> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02022.html
>
> 2003-11-25  J"orn Rennecke <joern.rennecke@superh.com>
>
>         * loop.c (loop_invariant_p): Amend comment about where new registers
>         might come from.

OK.

> http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01299.html
>
> 2003-09-02  J"orn Rennecke <joern.rennecke@superh.com>
>
>         * reload.c (reg_overlap_mentioned_for_reload_p):
>         When looking at a PLUS in X, avoid spuriously returning nonzero
>         when IN is a REG or another simple PLUS, or a MEM containing one.
>
> See also http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01912.html
> why the fixed bug is a regression.

This is also OK.  Thank you for the detailed explanation of the
change.  (Should you handle MINUS as well as PLUS this way?)

zw

Re: Unreviewed patches

[Zack Weinberg]

Joern Rennecke <amylaar@cs.tu-berlin.de> writes:

> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02022.html
>
> 2003-11-25  J"orn Rennecke <joern.rennecke@superh.com>
>
>         * loop.c (loop_invariant_p): Amend comment about where new registers
>         might come from.

OK.

> http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01299.html
>
> 2003-09-02  J"orn Rennecke <joern.rennecke@superh.com>
>
>         * reload.c (reg_overlap_mentioned_for_reload_p):
>         When looking at a PLUS in X, avoid spuriously returning nonzero
>         when IN is a REG or another simple PLUS, or a MEM containing one.
>
> See also http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01912.html
> why the fixed bug is a regression.

This is also OK.  Thank you for the detailed explanation of the
change.  (Should you handle MINUS as well as PLUS this way?)

zw

Unreviewed patches

[Eric Botcazou]

PR target/6466 (SPARC64):
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01808.html

PR middle-end/8028, 9890, 11151, 12210, 12503, 12692 (builtin_apply):
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00897.html

PR target/12900 (reg-stack):
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00342.html

PR optimization/13041 (2.6.0-test9 kernel on i386):
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01629.html

XFAIL infrastructure for dg-compat:
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00945.html


Thanks in advance.

-- 
Eric Botcazou

Re: Unreviewed patches

[David S. Miller]

On Wed, 26 Nov 2003 08:35:48 +0100
Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01808.html

I approve this patch.

Re: Unreviewed patches

[Roger Sayle]

Hi Eric,

On Wed, 26 Nov 2003, Eric Botcazou wrote:
> PR middle-end/8028, 9890, 11151, 12210, 12503, 12692 (builtin_apply):
> http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00897.html
>

This is Ok.


> PR target/12900 (reg-stack):
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00342.html
>

This is OK.


> PR optimization/13041 (2.6.0-test9 kernel on i386):
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01629.html
>

And this is OK.

Once these have on mainline for a few days without problems,
you should ask Gabriel for permission to back-port the last
two to the gcc-3_3-branch.

Many thanks.


Roger
--

Re: Unreviewed patches

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

[...]

| Once these have on mainline for a few days without problems,
| you should ask Gabriel for permission to back-port the last
| two to the gcc-3_3-branch.

Pre-approved.  

Thanks!

-- Gaby

Re: Unreviewed patches

[Eric Botcazou]

> Hi Eric,

Hello Roger,

> > PR middle-end/8028, 9890, 11151, 12210, 12503, 12692 (builtin_apply):
> > http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00897.html
>
> This is Ok.
>
> > PR target/12900 (reg-stack):
> > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00342.html
>
> This is OK.
>
> > PR optimization/13041 (2.6.0-test9 kernel on i386):
> > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01629.html
>
> And this is OK.

There was a TIA in the original message but I have to thank you again for 
this big review :-)

> Once these have on mainline for a few days without problems,
> you should ask Gabriel for permission to back-port the last
> two to the gcc-3_3-branch.

Agreed.

-- 
Eric Botcazou

Re: Unreviewed patches

[Janis Johnson]

On Wed, Nov 26, 2003 at 08:35:48AM +0100, Eric Botcazou wrote:
> 
> XFAIL infrastructure for dg-compat:
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00945.html

As the author of these tests, this looks good to me, but I don't have
authority to approve it.  See also this small fix to the dg-compat
tests:

 http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01114.html 

Janis

Re: Unreviewed patches

[Jim Wilson]

Janis Johnson wrote:
> As the author of these tests, this looks good to me, but I don't have
> authority to approve it.  See also this small fix to the dg-compat
> tests:
> 
>  http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01114.html 

OK.

You should have the authority to approve patches to the compat testsuite 
soon.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Unreviewed patches

[Richard Sandiford]

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00657.html
Support n32 & n64 structure return conventions.  This needs a new
target hook to control the padding of the return value.

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00841.html
Take addressing modes into account when deciding whether to force
constants into memory.

  [ wrt the second, symbols seem to be forced into memory quite often in
    real-world programs.  E.g. emacs now has a single relocation against
    stdout, generated for a call to fprintf().  It needed no relocations
    for 3.3.

    Since the emacs unexec code doesn't handle mips relocs properly,
    this shows up a user-visible regression.  An emacs bug, perhaps,
    but still... ]

Unreviewed patches

[David Edelsohn]

Don't copy-prop into middle of libcalls
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00765.html

Apply adjust_priority to all insns
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00520.html

GCSE redundant load after store
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00514.html

Stabs example
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02807.html

C++ friend improvements
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00783.html

Loop ivs
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01174.html

Unreviewed patches

[Kazu Hirata]

Hi,

Could someone review these patches?

[patch] Clean up FUNCTION_ARG_PADDING.
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00128.html

[patch] combine.c: Convert (ne (and (lshiftrt (xor X CST) Y) 1) 0) into (eq (and (lshiftrt X Y) 1) 0). (take 3)
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01315.html

Thanks,

Kazu Hirata

Re: Unreviewed patches

[Jim Wilson]

Kazu Hirata wrote:
> [patch] Clean up FUNCTION_ARG_PADDING.
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00128.html

Playing with FUNCTION_ARG_PADDING is very dangerous.  You could easily 
break an ABI, and not realize it until well after a release. 
Eliminating the duplicate definitions is a good idea though, and the 
patch does seem reasonably safe.

I don't really see the point of making FUNCTION_ARG_PADDING into a 
function though.  None of the other related macros in this file are 
functions.  Why not just rename it to DEFAULT_FUNCTION_ARG_PADDING, and 
then make that the default definition of FUNCTION_ARG_PADDING?

> [patch] combine.c: Convert (ne (and (lshiftrt (xor X CST) Y) 1) 0) into (eq (and (lshiftrt X Y) 1) 0). (take 3)
> http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01315.html

  1 << INTVAL (shift_count))))

This part can fail.  You want to use (HOST_WIDE_INT) 1 instead of just 
1, and you need to verify that the shift_mode is smaller than or equal 
to the size of HOST_WIDE_INT.  See similar examples in simplify_shift_const.

If handling XOR here makes sense, then does it also make sense in the 
similar code immediately above?
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Unreviewed patches

[Kazu Hirata]

Hi Jim,

> If handling XOR here makes sense, then does it also make sense in the 
> similar code immediately above?

No.  I just compiled a bunch of files.  The following comes close but
the second argument of xor is not a constant, so I can't safely remove
xor.

(ne (and:SI (xor:SI (reg:SI)
		    (reg:SI))
	    (const_int 1))
    (const_int 0))

Kazu Hirata

Unreviewed patches

[Kazu Hirata]

Hi,

Could someone review these patches?

[patch] Clean up FUNCTION_ARG_PADDING.
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00128.html

[patch] combine.c: Convert (ne (and (lshiftrt (xor X CST) Y) 1) 0)into (eq (and (lshiftrt X Y) 1) 0). (take 3)
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01315.html

Thanks,

Kazu Hirata

Re: Unreviewed patches

[Roger Sayle]

Zack Weinberg <zack@codesourcery.com> writes:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> > My math builtins patches have been in the queue for over a week.
>
> These three ... are approved.  The others I am not thinking clearly
> enough to review, sorry.

If its any help, they all look technically sound to me.
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00309.html
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00398.html
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00449.html


> I am a little suspicious of mathfn_built_in's apparent propensity to
> change the function the user called.  If I write
>
>  double x, y;
>  x = some_number;
>  y = sqrtf(x);

> I might in fact have _wanted_ the truncation to float.  Now, your
> patch does not change that behavior, so it is fine, but I want to
> raise the concern anyway.

Fear not, the logic for this optimization, on line 158 of convert.c,
only changes the math library function call to a lower precision,
when the extra precision would be cast away anyway.  GCC will leave
your example above unchanged.

Given (outermode)op((opmode)x), where x has mode innermode, we change
the mode of the operation to min(opmode, max(innermode, outermode)).
In the example above this is min(float, max(double, double)) which is
float, i.e. sqrtf will still be called.

For its intended target:

   float x, y;
   y = sqrt(x)

we perform the operation in min(double, max(float, float)) which is
float, so we'll call sqrtf.

And for another example:

  float x;
  double y;
  y = sqrt(x);

we perform the operation in min(double, max(float,double)) which is
double, so again we preserve the user's original call.

Basically, if a user calls a math function that will obviously
truncate the result, Jan's optimization should leave it unchanged.


Roger
--

Re: Unreviewed patches

[Kaveh R. Ghazi]

 > From: Roger Sayle <roger@eyesopen.com>
 > 
 > Zack Weinberg <zack@codesourcery.com> writes:
 > > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
 > > > My math builtins patches have been in the queue for over a week.
 > >
 > > These three ... are approved.  The others I am not thinking clearly
 > > enough to review, sorry.
 > 
 > If its any help, they all look technically sound to me.
 > http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00309.html
 > http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00398.html
 > http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00449.html

Thank you Roger.  Zack - perhaps after a good night's rest and with
Roger's second opinion, you'd like to reconsider?  I'd be happy to
clear up any points of confusion.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Unreviewed patches

[Kaveh R. Ghazi]

My math builtins patches have been in the queue for over a week.  I
know we usually wait a little longer before pinging the list, but it's
getting hard to sort out stuff while I have these patches waiting in
the queue.  If there's a problem reviewing any (e.g. the first one is
a little big), I can split them up, but please do let me know what the
problem is (if any) so I can address it.


Patch for more math builtins
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00309.html
This is a large addition of many new math builtin decls


Patch for gamma, bessel and error function math builtins 
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00398.html


Patch for math builtins (taking pointer arguments)
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00449.html


The next batch haven't been waiting as long, but if I could clear my
backlog it would help.


Patch to delete protoize.c:substr()
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00609.html

Patch to simplify builtins.c:mathfn_built_in() [take 2]
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00725.html

Patch to fix string-opt-9.c "regression" with builtin strcat
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00769.html

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Unreviewed patches

[Zack Weinberg]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> My math builtins patches have been in the queue for over a week.  I
> know we usually wait a little longer before pinging the list, but it's
> getting hard to sort out stuff while I have these patches waiting in
> the queue.  If there's a problem reviewing any (e.g. the first one is
> a little big), I can split them up, but please do let me know what the
> problem is (if any) so I can address it.

These three

> Patch to delete protoize.c:substr()
> http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00609.html
>
> Patch to simplify builtins.c:mathfn_built_in() [take 2]
> http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00725.html
>
> Patch to fix string-opt-9.c "regression" with builtin strcat
> http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00769.html

are approved.  The others I am not thinking clearly enough to review,
sorry.

I am a little suspicious of mathfn_built_in's apparent propensity to
change the function the user called.  If I write

  double x, y;
  x = some_number;
  y = sqrtf(x);

I might in fact have _wanted_ the truncation to float.  Now, your
patch does not change that behavior, so it is fine, but I want to
raise the concern anyway.

zw

Unreviewed patches

[David Edelsohn]

stabs example
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02807.html

incorrect test in is_friend
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01740.html

fix access calculation inside accessible_p
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01973.html

dbra patch
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01355.html

CQI argument shifting
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02150.html

PR 9862
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01286.html

loop ivs
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01174.html

loop unswitching
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02139.html

bitmap speedup
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01812.html

optimize sqrt without native sqrt instruction
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02012.html

Unreviewed patches

[Zdenek Dvorak]

Hello,

some patches that seem to be forgotten (and I like enough to cry for
them :-) :

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02505.html
	-- improves store motion to do also dead store elimination

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02953.html
	-- reading of value profiles. Honza Hubicka agreed with this
	   patch, but he cannot aprove it as it also touches some
	   parts outside profiling

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02132.html
	-- simplified pattern matching

http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01174.html
	-- patch for optimization/10080

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02418.html
	-- the previous list of unreviewed patches; of that only
	   df.c speedups were discussed :-(

Zdenek

Re: Unreviewed patches

[Richard Henderson]

On Mon, Jul 21, 2003 at 09:27:31PM +0200, Zdenek Dvorak wrote:
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02505.html
> 	-- improves store motion to do also dead store elimination

I think this patch is very reasonable.  Approved.

Do you find that this completely subsumes the current 
dead-store elimination?  I.e. if you annotate the flow.c
code, how many hits does it find?

If none, we can delete the code in flow.c, I think.
That may well speed up the compiler a bit.

> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02953.html
> 	-- reading of value profiles. Honza Hubicka agreed with this
> 	   patch, but he cannot aprove it as it also touches some
> 	   parts outside profiling

I guess this is ok.

> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02132.html
> 	-- simplified pattern matching

I don't know what to do with this.  I am sympathetic to the goals,
but I'm not really fond of a new language.  I'm going to say no to
this for 3.4; we can revisit it later.


r~

Re: Unreviewed patches

[Zdenek Dvorak]

Hello,

> > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02505.html
> > 	-- improves store motion to do also dead store elimination
> 
> I think this patch is very reasonable.  Approved.
> 
> Do you find that this completely subsumes the current 
> dead-store elimination?  I.e. if you annotate the flow.c
> code, how many hits does it find?

it does not subsume it completely (in fact it is almost orthogonal,
as it takes care of globally dead stores, while flow.c concerns locally
dead ones).  More precisely:

1) It does not do the removal in the last block.  I have an improved version
   of the patch that also splits the edges to exit, thus achieving the
   removal there as well (it also fixes another small bug in the patch).
   I will test it and send it tomorrow.
2) flow.c uses the fact that write can be killed by a write to the
   same address but in wider mode
3) store motion will only kill available dead stores, i.e. the stores
   local to a basic block and read, nontrivially stored or having
   address modified later in it are not removed

2) and 3) could only be handled by a mechanism similar to the one in
flow.c, so it does not seem feasible to me to get rid of it.

Zdenek

Re: Unreviewed patches

[Jan Hubicka]

> On Mon, Jul 21, 2003 at 09:27:31PM +0200, Zdenek Dvorak wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02505.html
> > 	-- improves store motion to do also dead store elimination
> 
> I think this patch is very reasonable.  Approved.
> 
> Do you find that this completely subsumes the current 
> dead-store elimination?  I.e. if you annotate the flow.c
> code, how many hits does it find?
> 
> If none, we can delete the code in flow.c, I think.
> That may well speed up the compiler a bit.
I think the code is somewhat active after reload that is good source of
redundant and dead stores.
It would be cool to be able to do store motion post-reload.  We would
get shring-wrapping almost for free.
Should not be that dificult to implement - one only needs to compute
transparency matrix for registers and combine it with the transparency
for stores, right?

Honza

Re: Unreviewed patches

[Richard Henderson]

On Mon, Jul 21, 2003 at 09:27:31PM +0200, Zdenek Dvorak wrote:
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01174.html
> 	-- patch for optimization/10080

This part of variable_initial_value looks broken.

+ 	  /* If we know that the initial value is indeed in range of
+ 	     the inner mode, record the fact even in case the value itself
+ 	     is useless.  */
+ 	  if ((GET_CODE (val) == SIGN_EXTEND
+ 	       || GET_CODE (val) == ZERO_EXTEND)
+ 	      && GET_MODE (XEXP (val, 0)) == inner_mode)
+ 	    ret = gen_rtx_fmt_e (GET_CODE (val),
+ 				 GET_MODE (var),
+ 				 gen_rtx_fmt_ei (SUBREG,
+ 						 inner_mode,
+ 						 var, 0));

I think at minimum you should be using simplify_gen_subreg
et all.  I notice to that you *do* do the correct thing later
in count_loop_iterations.

I didn't see anything else glaring.


r~

Re: Unreviewed patches

[Zdenek Dvorak]

Hello,

> On Mon, Jul 21, 2003 at 09:27:31PM +0200, Zdenek Dvorak wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01174.html
> > 	-- patch for optimization/10080
> 
> This part of variable_initial_value looks broken.
> 
> + 	  /* If we know that the initial value is indeed in range of
> + 	     the inner mode, record the fact even in case the value itself
> + 	     is useless.  */
> + 	  if ((GET_CODE (val) == SIGN_EXTEND
> + 	       || GET_CODE (val) == ZERO_EXTEND)
> + 	      && GET_MODE (XEXP (val, 0)) == inner_mode)
> + 	    ret = gen_rtx_fmt_e (GET_CODE (val),
> + 				 GET_MODE (var),
> + 				 gen_rtx_fmt_ei (SUBREG,
> + 						 inner_mode,
> + 						 var, 0));
> 
> I think at minimum you should be using simplify_gen_subreg
> et all.
>
> I notice to that you *do* do the correct thing later
> in count_loop_iterations.

Why is this incorrect? I just want to record here that the register var
is equal to extend (subreg (var)).

Zdenek

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these patches?

[patch] Clean up FUNCTION_ARG_PADDING.
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00128.html

[patch] i386.c: Fix for PR 10795.
  the patch itself
    http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00908.html
  the description of the patch
    http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01169.html

Thanks,

Kazu Hirata

Unreviewed patches

[Joern Rennecke]

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01418.html

2003-05-15  J"orn Rennecke <joern.rennecke@superh.com>

	* gcc.dg/asm-names.c (ymain): Make it weak.

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02055.html

2003-05-23  J"orn Rennecke <joern.rennecke@superh.com>

	* c-pragma.h (HANDLE_PRAGMA_WEAK): Always define to SUPPORTS_WEAK.

Re: Unreviewed patches

[Jim Wilson]

Joern Rennecke wrote:
> 	* gcc.dg/asm-names.c (ymain): Make it weak.

OK.

> 	* c-pragma.h (HANDLE_PRAGMA_WEAK): Always define to SUPPORTS_WEAK.

OK.

Jim

Unreviewed patches

[Kazu Hirata]

Hi,

Could someone review any of these?

[patch] reload1.c: Move reload_cse_reg and its friends to postreload.c.
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01850.html

[patch] reload1.c: A very tiny speedup.
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02224.html

[patch] execute/simd-4.c: Enable only when sizeof(int) == 4.
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02298.html

[patch] avr: Remove -mrtl.
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02384.html

[patch] expr.c: Fix the failure of gcc.dg/compat/scalar-by-value-4.
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02553.html

[patch] jump.c: Remove an unused function.
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02595.html

[patch] explow.c: Remove an unused function, find_next_ref().
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02614.html

Thanks,

Kazu Hirata

Re: Unreviewed patches

[Jim Wilson]

Kazu Hirata wrote:
> [patch] reload1.c: Move reload_cse_reg and its friends to postreload.c.
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01850.html

OK.

> [patch] reload1.c: A very tiny speedup.
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02224.html

OK.

> [patch] execute/simd-4.c: Enable only when sizeof(int) == 4.
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02298.html

Adding all of that preprocessor stuff doesn't seem like a good solution. 
  Isn't there any other way to solve the problem, like adding sizeof 
tests?  I will defer on this for now.

The message doesn't make it clear why the test fails, and hence doesn't 
make it clear why we can't use something simpler like a sizeof test.

> [patch] avr: Remove -mrtl.
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02384.html

OK.

> [patch] expr.c: Fix the failure of gcc.dg/compat/scalar-by-value-4.
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02553.html
> 
> [patch] jump.c: Remove an unused function.
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02595.html
> 
> [patch] explow.c: Remove an unused function, find_next_ref().
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02614.html

I haven't gotten this far in my backlog yet.  These were all posted in 
the last 4 days, so I will defer them for now.

Jim

Unreviewed Patches

[Dara Hazeghi]

Hello,

this patch to fix PR 10270 (small problem with
gccbug):
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02245.html

and this patch to fix PR 5620 (issue with stat() on
win32):
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01261.html

have been unreviewed for over two weeks. Would
somebody mind looking at them? Thanks,

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Unreviewed Patches

[Geoff Keating]

Dara Hazeghi <dhazeghi@yahoo.com> writes:

> Hello,
> 
> this patch to fix PR 10270 (small problem with
> gccbug):
> http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02245.html

This is OK.

> and this patch to fix PR 5620 (issue with stat() on
> win32):
> http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01261.html

As well as Joseph's comment,
<http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01270.html>,
the file i386/x-mingw32 seems to be missing from the diff.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Unreviewed Patches

[Dara Hazeghi]

--- Geoff Keating <geoffk@geoffk.org> wrote:
> Dara Hazeghi <dhazeghi@yahoo.com> writes:
> 
> > Hello,
> > 
> > this patch to fix PR 10270 (small problem with
> > gccbug):
> >
>
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02245.html
> 
> This is OK.

Thanks. As neither I, nor the submitter have cvs
access, could you commit this? Thanks.
> 
> > and this patch to fix PR 5620 (issue with stat()
> on
> > win32):
> >
>
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01261.html
> 
> As well as Joseph's comment,
>
<http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01270.html>,
> the file i386/x-mingw32 seems to be missing from the
> diff.

Thanks. Danny, would you mind having a look at this?

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Unreviewed Patches

[Gerald Pfeifer]

On Mon, 16 Jun 2003, Dara Hazeghi wrote:
> Thanks. As neither I, nor the submitter have cvs
> access, could you commit this? Thanks.

Given that you already have Bugzilla access, at this point I think
you should ask for CVS write access as well.

The form is at http://gcc.gnu.org/cvswrite.html and I guess you can
specifiy either Geoff or me as your "sponsor".

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Unreviewed Patches

[Dara Hazeghi]

> Given that you already have Bugzilla access, at this
> point I think
> you should ask for CVS write access as well.
> 
> The form is at http://gcc.gnu.org/cvswrite.html and
> I guess you can
> specifiy either Geoff or me as your "sponsor".

Thanks! However, currently my copyright paperwork
hasn't made it through, so I think this should
probably wait. Geoff since you approved this
(http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02245.html)
would you mind checking it in? Thanks again,

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Unreviewed Patches

[Geoff Keating]

> X-Original-To: geoffk@foam.wonderslug.com
> Date: Wed, 18 Jun 2003 17:47:58 -0700 (PDT)
> From: Dara Hazeghi <dhazeghi@yahoo.com>
> Cc: Geoff Keating <geoffk@geoffk.org>
> X-OriginalArrivalTime: 19 Jun 2003 00:51:39.0843 (UTC) FILETIME=[F1A18130:01C335FC]
> 
> > Given that you already have Bugzilla access, at this
> > point I think
> > you should ask for CVS write access as well.
> > 
> > The form is at http://gcc.gnu.org/cvswrite.html and
> > I guess you can
> > specifiy either Geoff or me as your "sponsor".
> 
> Thanks! However, currently my copyright paperwork
> hasn't made it through, so I think this should
> probably wait. Geoff since you approved this
> (http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02245.html)
> would you mind checking it in? Thanks again,

I think it'd be better wait until your copyright paperwork is done...

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Unreviewed Patches

[Dara Hazeghi]

--- Geoff Keating <geoffk@geoffk.org> wrote:
> > X-Original-To: geoffk@foam.wonderslug.com
> > Date: Wed, 18 Jun 2003 17:47:58 -0700 (PDT)
> > From: Dara Hazeghi <dhazeghi@yahoo.com>
> > Cc: Geoff Keating <geoffk@geoffk.org>
> > X-OriginalArrivalTime: 19 Jun 2003 00:51:39.0843
> (UTC) FILETIME=[F1A18130:01C335FC]
> > 
> > > Given that you already have Bugzilla access, at
> this
> > > point I think
> > > you should ask for CVS write access as well.
> > > 
> > > The form is at http://gcc.gnu.org/cvswrite.html
> and
> > > I guess you can
> > > specifiy either Geoff or me as your "sponsor".
> > 
> > Thanks! However, currently my copyright paperwork
> > hasn't made it through, so I think this should
> > probably wait. Geoff since you approved this
> >
>
(http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02245.html)
> > would you mind checking it in? Thanks again,
> 
> I think it'd be better wait until your copyright
> paperwork is done...

Fine by me, but keep in mind that I didn't write the
patch either :-) I had assumed it fit under the
category of small enough to accept without paperwork,
so I'm not sure how my assignment would change the
situation...

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Unreviewed patches

[Joern Rennecke]

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00349.html

Fri Feb 21 21:02:01 2003  Stephen Clarke <stephen.clarke@superh.com>
                          J"orn Rennecke <joern.rennecke@superh.com>

        * late-loop.c: New file.
        * Makefile.in (OBJS): Include late-loop.o
        (late-loop.o): Add dependencies.
        * flags.h (flag_optimize_target_registers): Declare.
        (flag_optimize_target_registers_2): Likewise.
        * hooks.c (hook_reg_class_void_no_regs): New function.
        (hook_bool_bool_false): Likewise.
        * hooks.h (hook_reg_class_void_no_regs, hook_bool_bool_false): Declare.
        * rtl.h (target_registers_optimize): Declare.
        * target-def.h (TARGET_OPTIMIZE_TARGET_REGISTER_CLASS): Define.
        (TARGET_OPTIMIZE_TARGET_REGISTER_CALLEE_SAVED): Likewise.
        (TARGET_INITIALIZER): Include these.
        * target.h (struct gcc_target): Add optimize_target_register_class
        and optimize_target_register_callee_saved members.
        * toplev.c (enum dump_file_index): Add DFI_targetregs.
        (dump_file) Add "tars" entry.
        (flag_optimize_target_registers): New variable.
        (flag_optimize_target_registers_2): Likewise.
        (lang_independent_options): Add entries for new options.
        (rest_of_compilation): Call target_registers_optimize.
        * doc/tm.texi (TARGET_OPTIMIZE_TARGET_REGISTER_CLASS): Document.
        (TARGET_OPTIMIZE_TARGET_REGISTER_CALLEE_SAVED): Likewise.
        * doc/invoke.texi: Document -foptimize-target-registers and
        -foptimize-target-registers-2.

        * sh.c (shmedia_space_reserved_for_target_registers): New variable.
        (sh_target_reg_class): New function.
        (sh_optimize_target_register_callee_saved): Likwise.
        (shmedia_target_regs_stack_space): Likewise.
        (shmedia_reserve_space_for_target_registers_p): Likewise.
        (shmedia_target_regs_stack_adjust): Likewise.
        (TARGET_OPTIMIZE_TARGET_REGISTER_CLASS): Override.
        (TARGET_OPTIMIZE_TARGET_REGISTER_CALLEE_SAVED): Likewise.
        (calc_live_regs): If flag_optimize_target_registers_2 and
        TARGET_SAVE_ALL_TARGET_REGS is enabled, and we have space reserved
        for target registers, make sure that we save all target registers.
        (sh_expand_prologue, sh_expand_epilogue): Take target register
        optimizations into account.  Collapse stack adjustments if that
        is beneficial.
        (initial_elimination_offset): Reserve space for target registers
        if necessary.
        * sh.h (SAVE_ALL_TR_BIT, TARGET_SAVE_ALL_TARGET_REGS): Define.
        (OPTIMIZATION_OPTIONS): Enable flag_optimize_target_registers.

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01418.html

2003-05-15  J"orn Rennecke <joern.rennecke@superh.com>

        * gcc.dg/asm-names.c (ymain): Make it weak.

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02055.html

2003-05-23  J"orn Rennecke <joern.rennecke@superh.com>

        * c-pragma.h (HANDLE_PRAGMA_WEAK): Always define to SUPPORTS_WEAK.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: Unreviewed patches

[Richard Henderson]

On Mon, Jun 02, 2003 at 12:40:40PM -0400, Jakub Jelinek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02262.html

Ok.


r~

Unreviewed patches

[Zdenek Dvorak]

Hello,

there are my patches from last few months that I consider important:

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01285.html
  splits log links creation from flow.c. Richard Henderson asked
  for reasons for this patch, but I did not recieve a response for
  mail in that they were provided
  (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01316.html).

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01222.html
  a fix for a bug in parameter passing on ia64. Not really sure
  whether a correct one, comments welcome

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00328.html
  a fix for REG_EQUAL/EQUIV notes invalidated by a store motion

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00645.html
  a fix for addressofs in notes that are incorrectly handled due to
  one of my previous patches

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01542.html
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01569.html
  patches to speed up df.c functions

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01812.html
  a patch to speed up bitmap.c functions (and in effect again df.c ones)

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02139.html
  a small improvement to loop unswitching that makes it work on powerpc

Zdenek

Re: Unreviewed patches

[Michael Hayes]

Zdenek Dvorak writes:

 > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01542.html

It seems like this patch foundered since the speedup required further
substantiating.  Do you have any further measurements to support your
claims for this patch?

 > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01569.html

Again this patch foundered due to the impasse between the original
author and yourself and the lack of a maintainer to moderate.  More
supporting evidence would have helped.  May I suggest that we
enapsulate the fibonacci heap and simple heap implementations behind a
generic heap interface.  We could then select the best implementation
at run-time.

Michael.

Re: Unreviewed patches

[Daniel Berlin]

On Sun, 1 Jun 2003, Michael Hayes wrote:

> Zdenek Dvorak writes:
>
>  > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01542.html
>
> It seems like this patch foundered since the speedup required further
> substantiating.  Do you have any further measurements to support your
> claims for this patch?
He does.
I'm for the patch, i wasn't thinking in terms of 0.07 seconds.
>
>  > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01569.html
>
> Again this patch foundered due to the impasse between the original
> author and yourself and the lack of a maintainer to moderate.  More
> supporting evidence would have helped.
This one i have more of a problem with.
I really doubt that everyone else who uses a fibheap is wrong.
It *should* be faster, and if it *really* matters, i can do it.
I just don't see it as that big a deal when nothing currently really uses
the stuff.

Re: Unreviewed patches

[Zdenek Dvorak]

Hello,

> >  > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01569.html
> >
> > Again this patch foundered due to the impasse between the original
> > author and yourself and the lack of a maintainer to moderate.  More
> > supporting evidence would have helped.
> This one i have more of a problem with.
> I really doubt that everyone else who uses a fibheap is wrong.
> It *should* be faster, and if it *really* matters, i can do it.
> I just don't see it as that big a deal when nothing currently really uses
> the stuff.

the webizer does, as well as my new induction variable detection on rtl
level; this is why I am concerned about the speed of df functions.

Considering the fibheap stuff -- IMHO in general the more complicated
structures have larger multiplicative constants than the equivalent simpler
structures (the O(1) insert for fibheaps does not really matter, as you
pull everything from the queue anyway).  The fibheaps lose mostly due
to being forced to manipulate a complicated structure consisting from
multiple levels of double-linked lists, while the simple heaps have
no such overhead. This of course does not say that our implementation
cannot be faster, just that I doubt it can beat the simple heaps.

For why then fibheaps are so often used -- they are pretty flexible and
support wide range of operations that the normal heaps do not or
require to add similar overhead to support them. In many applications
this is much more important than their speed (as it usually should be
majorized by processing times for elements anyway).

Zdenek

Re: Unreviewed patches

[Daniel Berlin]

On Tuesday, June 3, 2003, at 03:49  AM, Zdenek Dvorak wrote:

> Hello,
>
>>>> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01569.html
>>>
>>> Again this patch foundered due to the impasse between the original
>>> author and yourself and the lack of a maintainer to moderate.  More
>>> supporting evidence would have helped.
>> This one i have more of a problem with.
>> I really doubt that everyone else who uses a fibheap is wrong.
>> It *should* be faster, and if it *really* matters, i can do it.
>> I just don't see it as that big a deal when nothing currently really 
>> uses
>> the stuff.
>
> the webizer does, as well as my new induction variable detection on rtl
> level; this is why I am concerned about the speed of df functions.
Where can i find this stuff?  When I can access it, i'm happy to 
profile and speed up.

>
> Considering the fibheap stuff -- IMHO in general the more complicated
> structures have larger multiplicative constants than the equivalent 
> simpler
> structures (the O(1) insert for fibheaps does not really matter, as you
> pull everything from the queue anyway).  The fibheaps lose mostly due
> to being forced to manipulate a complicated structure consisting from
> multiple levels of double-linked lists, while the simple heaps have
> no such overhead. This of course does not say that our implementation
> cannot be faster, just that I doubt it can beat the simple heaps.
>
Which is where i believe you are dead wrong.

> For why then fibheaps are so often used -- they are pretty flexible and
> support wide range of operations that the normal heaps do not or
> require to add similar overhead to support them.

They are often used as priority queues where there is no need to 
decrement a key quickly.
They are widely regarded as *faster* as a priority queue structure than 
normal heaps.
I have a hard time believing you are correct, and every piece of 
published material i can find (including my textbook from design and 
analysis of efficient algorithms, for that matter) is wrong.
I find it much more likely to be an implementation problem on my part.

>
> Zdenek
>

Re: Unreviewed patches

[Zdenek Dvorak]

Hello,

> >>>Again this patch foundered due to the impasse between the original
> >>>author and yourself and the lack of a maintainer to moderate.  More
> >>>supporting evidence would have helped.
> >>This one i have more of a problem with.
> >>I really doubt that everyone else who uses a fibheap is wrong.
> >>It *should* be faster, and if it *really* matters, i can do it.
> >>I just don't see it as that big a deal when nothing currently really 
> >>uses
> >>the stuff.
> >
> >the webizer does, as well as my new induction variable detection on rtl
> >level; this is why I am concerned about the speed of df functions.
> Where can i find this stuff?  When I can access it, i'm happy to 
> profile and speed up.

on rtlopt-branch.

> >Considering the fibheap stuff -- IMHO in general the more complicated
> >structures have larger multiplicative constants than the equivalent 
> >simpler
> >structures (the O(1) insert for fibheaps does not really matter, as you
> >pull everything from the queue anyway).  The fibheaps lose mostly due
> >to being forced to manipulate a complicated structure consisting from
> >multiple levels of double-linked lists, while the simple heaps have
> >no such overhead. This of course does not say that our implementation
> >cannot be faster, just that I doubt it can beat the simple heaps.
> >
> Which is where i believe you are dead wrong.
> 
> >For why then fibheaps are so often used -- they are pretty flexible and
> >support wide range of operations that the normal heaps do not or
> >require to add similar overhead to support them.
> 
> They are often used as priority queues where there is no need to 
> decrement a key quickly.
> They are widely regarded as *faster* as a priority queue structure than 
> normal heaps.
> I have a hard time believing you are correct, and every piece of 
> published material i can find (including my textbook from design and 
> analysis of efficient algorithms, for that matter) is wrong.

can you send me a reference please? I was searching a web just now and
found nothing except the following citation (from a not really reliable
source) claiming that

"Fibonacci heaps are asymptotically the best priority queues known: They
perform all heap operations in O(log n) time, some even in amortized
constant time. However, in practise they are "known" (by the
theoreticians) to be inferior eg.  to d-heaps because their internal
maintenance is relatively involved. Performance tests (with random data)
indicated that they are indeed a bit slower but not too much (at least
for many elements)."

Zdenek

Re: Unreviewed patches

[Daniel Berlin]

>
> can you send me a reference please? I was searching a web just now and
> found nothing except the following citation (from a not really reliable
> source) claiming that


Cormen, T., C. Leiserson, and R. Rivest. Introduction to Algorithms.
Cambridge, MA: MIT Press, 1990.


Fredman, M. and Tarjan, R. "Fibonacci Heaps and Their Uses in Improved
Network Optimization Algorithms." Journal of the Association for Computing
Machinery, vol. 34, no. 3, July 1987.
^^^^^^^
Never reviewed this paper, actually, so don't know if it has actual
performance results.

From another web page on using f-heaps:
"The big surprise, though, is that the F-heap is even competitive on
regular heap algorithms like heap sorting. The test programs generate
random test data and compare the output against qsort() to make sure the
heap is operating correctly. To determine the overall time complexity, you
can compare the time for 2048-element and 1024-element data sets. If the
process is O(n log), the ratio should be 2.2 to 1. The test program
averages a ratio of 2.17 for a binary heap and 2.07 for a Fibonacci heap.
The decreased ratio is due to the fact that more of the F-heap operations
execute in linear time, including the Insert() and DecreaseKey()
operations. In addition, the Fibonacci heap test runs about 15 percent
faster than the binary heap test. Even if you remove the DecreaseKey()
operation from the test, the Fibonacci heap is still over 10 percent
faster. For algorithms like Dijkstra's, the difference can be two to ten
times faster on a 1024-vertex graph.
"

Note, 10% faster even without the decreasekey usage.

I'm not near a computer i can get to the rest of the references easily,
i'll get you other reliable sources when i get home.

I *really* think it's an implementation problem. There are a few ways to
do various operations on the fibheap, and i just chose the simplest one,
rather than speed testing anything.

 >
> "Fibonacci heaps are asymptotically the best priority queues known: They
> perform all heap operations in O(log n) time, some even in amortized
> constant time. However, in practise they are "known" (by the
> theoreticians) to be inferior eg.  to d-heaps because their internal
> maintenance is relatively involved. Performance tests (with random data)
> indicated that they are indeed a bit slower but not too much (at least
> for many elements)."
>
> Zdenek
>

Re: Unreviewed patches

[Zdenek Dvorak]

Hello,

[snip references]

> I'm not near a computer i can get to the rest of the references easily,
> i'll get you other reliable sources when i get home.
> 
> I *really* think it's an implementation problem. There are a few ways to
> do various operations on the fibheap, and i just chose the simplest one,
> rather than speed testing anything.

you insired me to do some more searching. My feelings after looking at
few papers:

Nobody really considers Fibonacci heaps for use as worklist, because
they have the extra overhead in order to support decrease_key operation
that is not needed.  If we remove this from Fibonacci heaps, we end up
with lazy binomial heap.  Unfortunately I have found no comparison that
would take lazy binomial heaps into account, but the (non-lazy) binomial
heaps indeed outperform ordinary heaps, especially on small sizes.

Anyway I have looked at your implementation of Fibonacci heaps and made
some improvements to it; it seems fast enough for my purposes with the
attached patch.

Zdenek

	* fibheap.c (fibnode_insert_after, fibheap_ins_root, fibheap_rem_root,
	fibheap_link): Made inline.
	(fibheap_consolidate): Speed up.

Index: fibheap.c
===================================================================
RCS file: /cvs/gcc/gcc/libiberty/fibheap.c,v
retrieving revision 1.4.26.1
diff -c -3 -p -r1.4.26.1 fibheap.c
*** fibheap.c	16 Oct 2002 16:09:14 -0000	1.4.26.1
--- fibheap.c	8 Jun 2003 13:41:24 -0000
*************** fibheap_comp_data (heap, key, data, b)
*** 101,106 ****
--- 101,139 ----
    return fibheap_compare (heap, &a, b);
  }
  
+ /* Insert node B after node A.  */
+ static inline void
+ fibnode_insert_after (a, b)
+      fibnode_t a;
+      fibnode_t b;
+ {
+   b->left = a;
+   b->right = a->right;
+   a->right->left = b;
+   a->right = b;
+ }
+ 
+ /* Insert NODE into the root list of HEAP.  */
+ static inline void
+ fibheap_ins_root (heap, node)
+      fibheap_t heap;
+      fibnode_t node;
+ {
+   /* If the heap is currently empty, the new node becomes the singleton
+      circular root list.  */
+   if (heap->root == NULL)
+     {
+       heap->root = node;
+       node->left = node;
+       node->right = node;
+       return;
+     }
+ 
+   /* Otherwise, insert it in the circular root list between the root
+      and it's right node.  */
+   fibnode_insert_after (heap->root, node);
+ }
+ 
  /* Insert DATA, with priority KEY, into HEAP.  */
  fibnode_t
  fibheap_insert (heap, key, data)
*************** fibheap_empty (heap)
*** 307,312 ****
--- 340,362 ----
    return heap->nodes == 0;
  }
  
+ /* Remove NODE from the rootlist of HEAP.  */
+ static inline void
+ fibheap_rem_root (heap, node)
+      fibheap_t heap;
+      fibnode_t node;
+ {
+   if (node->left == node)
+     heap->root = NULL;
+   else
+     {
+       node->right->left = node->left;
+       node->left->right = node->right;
+       heap->root = node->left;
+     }
+ }
+ 
+ 
  /* Extract the minimum node of the heap.  */
  static fibnode_t
  fibheap_extr_min_node (heap)
*************** fibheap_extr_min_node (heap)
*** 344,441 ****
    return ret;
  }
  
- /* Insert NODE into the root list of HEAP.  */
- static void
- fibheap_ins_root (heap, node)
-      fibheap_t heap;
-      fibnode_t node;
- {
-   /* If the heap is currently empty, the new node becomes the singleton
-      circular root list.  */
-   if (heap->root == NULL)
-     {
-       heap->root = node;
-       node->left = node;
-       node->right = node;
-       return;
-     }
- 
-   /* Otherwise, insert it in the circular root list between the root
-      and it's right node.  */
-   fibnode_insert_after (heap->root, node);
- }
- 
- /* Remove NODE from the rootlist of HEAP.  */
- static void
- fibheap_rem_root (heap, node)
-      fibheap_t heap;
-      fibnode_t node;
- {
-   if (node->left == node)
-     heap->root = NULL;
-   else
-     heap->root = fibnode_remove (node);
- }
- 
- /* Consolidate the heap.  */
- static void
- fibheap_consolidate (heap)
-      fibheap_t heap;
- {
-   fibnode_t a[1 + 8 * sizeof (long)];
-   fibnode_t w;
-   fibnode_t y;
-   fibnode_t x;
-   int i;
-   int d;
-   int D;
- 
-   D = 1 + 8 * sizeof (long);
- 
-   memset (a, 0, sizeof (fibnode_t) * D);
- 
-   while ((w = heap->root) != NULL)
-     {
-       x = w;
-       fibheap_rem_root (heap, w);
-       d = x->degree;
-       while (a[d] != NULL)
- 	{
- 	  y = a[d];
- 	  if (fibheap_compare (heap, x, y) > 0)
- 	    {
- 	      fibnode_t temp;
- 	      temp = x;
- 	      x = y;
- 	      y = temp;
- 	    }
- 	  fibheap_link (heap, y, x);
- 	  a[d] = NULL;
- 	  d++;
- 	}
-       a[d] = x;
-     }
-   heap->min = NULL;
-   for (i = 0; i < D; i++)
-     if (a[i] != NULL)
-       {
- 	fibheap_ins_root (heap, a[i]);
- 	if (heap->min == NULL || fibheap_compare (heap, a[i], heap->min) < 0)
- 	  heap->min = a[i];
-       }
- }
- 
  /* Make NODE a child of PARENT.  */
! static void
  fibheap_link (heap, node, parent)
       fibheap_t heap ATTRIBUTE_UNUSED;
       fibnode_t node;
       fibnode_t parent;
  {
    if (parent->child == NULL)
!     parent->child = node;
    else
!     fibnode_insert_before (parent->child, node);
    node->parent = parent;
    parent->degree++;
    node->mark = 0;
--- 394,413 ----
    return ret;
  }
  
  /* Make NODE a child of PARENT.  */
! static inline void
  fibheap_link (heap, node, parent)
       fibheap_t heap ATTRIBUTE_UNUSED;
       fibnode_t node;
       fibnode_t parent;
  {
    if (parent->child == NULL)
!     {
!       parent->child = node;
!       node->left = node->right = node;
!     }
    else
!     fibnode_insert_after (parent->child, node);
    node->parent = parent;
    parent->degree++;
    node->mark = 0;
*************** fibheap_cascading_cut (heap, y)
*** 477,503 ****
      }
  }
  
- static void
- fibnode_insert_after (a, b)
-      fibnode_t a;
-      fibnode_t b;
- {
-   if (a == a->right)
-     {
-       a->right = b;
-       a->left = b;
-       b->right = a;
-       b->left = a;
-     }
-   else
-     {
-       b->right = a->right;
-       a->right->left = b;
-       a->right = b;
-       b->left = a;
-     }
- }
- 
  static fibnode_t
  fibnode_remove (node)
       fibnode_t node;
--- 449,454 ----
*************** fibnode_remove (node)
*** 520,523 ****
--- 471,531 ----
    node->right = node;
  
    return ret;
+ }
+ 
+ /* Consolidate the heap.  */
+ static void
+ fibheap_consolidate (heap)
+      fibheap_t heap;
+ {
+   /* This array is always kept zeroed.  */
+   static fibnode_t a[1 + 8 * sizeof (long)]; 
+   fibnode_t w;
+   fibnode_t y;
+   fibnode_t x;
+   fibnode_t minimal;
+   int i;
+   int d;
+   int D = 0;  /* Last non-zero element in a.  */
+ 
+   while ((w = heap->root) != NULL)
+     {
+       x = w;
+       fibheap_rem_root (heap, w);
+       d = x->degree;
+       while (a[d] != NULL)
+ 	{
+ 	  y = a[d];
+ 	  if (fibheap_compare (heap, x, y) > 0)
+ 	    {
+ 	      fibnode_t temp;
+ 	      temp = x;
+ 	      x = y;
+ 	      y = temp;
+ 	    }
+ 	  fibheap_link (heap, y, x);
+ 	  a[d] = NULL;
+ 	  d++;
+ 	}
+       a[d] = x;
+       if (d >= D)
+ 	D = d + 1;
+     }
+ 
+   i = D - 1;
+   minimal = a[i];
+   fibheap_ins_root (heap, a[i]);
+   a[i] = NULL;
+   while (i--)
+     {
+       x = a[i];
+       if (x != NULL)
+ 	{
+ 	  fibheap_ins_root (heap, x);
+ 	  if (fibheap_compare (heap, x, minimal) < 0)
+ 	    minimal = x;
+ 	  a[i] = NULL;
+ 	}
+     }
+   heap->min = minimal;
  }

Re: Unreviewed patches

[Daniel Berlin]

On Sunday, June 8, 2003, at 09:56  AM, Zdenek Dvorak wrote:

> Hello,
>
> [snip references]
>
>> I'm not near a computer i can get to the rest of the references 
>> easily,
>> i'll get you other reliable sources when i get home.
>>
>> I *really* think it's an implementation problem. There are a few ways 
>> to
>> do various operations on the fibheap, and i just chose the simplest 
>> one,
>> rather than speed testing anything.
>
> you insired me to do some more searching. My feelings after looking at
> few papers:
>
> Nobody really considers Fibonacci heaps for use as worklist, because
> they have the extra overhead in order to support decrease_key operation
> that is not needed.

Well, we use it as a priority queue, not a strict worklist.
We insert the blocks back in in the right order.
Technically, if we used them in an optimization which can modify the 
CFG, we could quite possibly need the decrease key operation in order 
to keep the ordering right.


>   If we remove this from Fibonacci heaps, we end up
> with lazy binomial heap.  Unfortunately I have found no comparison that
> would take lazy binomial heaps into account, but the (non-lazy) 
> binomial
> heaps indeed outperform ordinary heaps, especially on small sizes.
Non-surprising, to be honest.

>
> Anyway I have looked at your implementation of Fibonacci heaps and made
> some improvements to it; it seems fast enough for my purposes with the
> attached patch.
>
Thanks, I really appreciate you trying to work with this on me.

> Zdenek
>
> 	* fibheap.c (fibnode_insert_after, fibheap_ins_root, fibheap_rem_root,
> 	fibheap_link): Made inline.

Just a note here:
You did actually change what fibheap_insert_after does, and what 
fibheap_link does (IE you didn't just inline them).
You might want to note that in the changelog.

unreviewed patches

[Alan Modra]

Fix cse related fail of pure-1.c on powerpc64-linux
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02371.html

add_sysrooted_prefix
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01608.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: unreviewed patches

[Alan Modra]

Ping.

On Wed, Apr 09, 2003 at 12:29:44PM +0930, Alan Modra wrote:
> Fix cse related fail of pure-1.c on powerpc64-linux
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02371.html

Hey!  Two lines of added code.  Should be easy for someone who knows
cse.c to review.

> add_sysrooted_prefix
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01608.html

Perhaps I should have explained why I want this one in, although it
should stand alone just as a code clean-up.  It's needed for the
following to work, because STANDARD_STARTFILE_PREFIX is defined
as $(unlibsubdir), which is ../../.. relative to $libsubdir.

	* config/rs6000/linux64.h (STARTFILE_PREFIX_SPEC): Use
	STANDARD_STARTFILE_PREFIX.

Index: gcc/config/rs6000/linux64.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/linux64.h,v
retrieving revision 1.35
diff -u -p -r1.35 linux64.h
--- gcc/config/rs6000/linux64.h	18 Mar 2003 02:28:46 -0000	1.35
+++ gcc/config/rs6000/linux64.h	18 Mar 2003 07:08:58 -0000
@@ -209,7 +209,7 @@ Boston, MA 02111-1307, USA.  */
   %{!dynamic-linker:-dynamic-linker /lib64/ld64.so.1}}}"
 
 #ifdef NATIVE_CROSS
-#define STARTFILE_PREFIX_SPEC "/usr/local/lib64/ /lib64/ /usr/lib64/"
+#define STARTFILE_PREFIX_SPEC STANDARD_STARTFILE_PREFIX " /lib64/ /usr/lib64/"
 #endif
 
 #undef  STARTFILE_LINUX_SPEC


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: unreviewed patches

[Alexandre Oliva]

On Apr 17, 2003, Alan Modra <amodra@bigpond.net.au> wrote:

>> add_sysrooted_prefix
>> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01608.html

> Perhaps I should have explained why I want this one in, although it
> should stand alone just as a code clean-up.

Actually, I don't like the removal of the arguments.  Even though
they're unused now, they might be useful some day, and they make the
calls to add_prefix interchangeable with those to
add_sysrooted_prefix.  I don't care all that strongly about keeping
them as they are, but I'm pretty the odds of the feature you want
getting it will increase if you split them up :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: unreviewed patches

[Alan Modra]

On Tue, May 06, 2003 at 03:21:39AM -0300, Alexandre Oliva wrote:
> On Apr 17, 2003, Alan Modra <amodra@bigpond.net.au> wrote:
> 
> >> add_sysrooted_prefix
> >> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01608.html
> 
> > Perhaps I should have explained why I want this one in, although it
> > should stand alone just as a code clean-up.
> 
> Actually, I don't like the removal of the arguments.  Even though
> they're unused now, they might be useful some day, and they make the
> calls to add_prefix interchangeable with those to
> add_sysrooted_prefix.  I don't care all that strongly about keeping
> them as they are, but I'm pretty the odds of the feature you want
> getting it will increase if you split them up :-)

Thanks for commenting.  A post in the thread should be as good as
a nag from me, maybe better.  :)  As far as the arg removal goes,
I still think it's better to not pass args around unnecessarily,
but I'll quite happily commit a patch without that change.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Unreviewed patches

[Roger Sayle]

ping?

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00069.html
REG_EQUAL notes vs. libcalls

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00824.html
REG_EQUAL notes on cond_jumps

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01396.html
Remove DECL_BUILT_IN_NONANSI

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01527.html
PR 10011: Introduce gcse_constant_p


Roger
--

Unreviewed patches

[Roger Sayle]

The following patch has been unreviewed for over a week:

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00069.html
REG_EQUAL notes vs. libcalls

and although it hasn't been a full week yet, this patch

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00496.html
Fix specs processing (take 2)

fixes a serious recent regression on the SH targets.

Very many thanks in advance,

Roger
--

Unreviewed patches

[Zdenek Dvorak]

Hello,

a few of my patches got (mostly) silently ignored last month; this is a bit
unpleasant as some of them won't be suitable for stage 2 and the other
ones block my further work. Could you please have a look at some of
them please?

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00604.html
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00675.html
  -- rtlopt branch merge patches

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01238.html
  wrong new files atached here, fixed by
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01262.html
  -- foundation for toplevel driver cleanup

the less important ones:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02059.html
  -- fix for latent bug in liveness analysis
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01655.html
  -- fix for ugly code generated for small array initializers
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01285.html
  -- split log links creation from flow.c

Zdenek Dvorak

Re: Unreviewed patches

[Zack Weinberg]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:

> Hello,
>
> a few of my patches got (mostly) silently ignored last month; this is a bit
> unpleasant as some of them won't be suitable for stage 2 and the other
> ones block my further work. Could you please have a look at some of
> them please?
>
> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00604.html
> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00675.html
>   -- rtlopt branch merge patches

Too big and hairy for me.  You might want to run the gcov stuff by
Nathan Sidwell, he wrote most of the current implementation.

> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01238.html
>   wrong new files atached here, fixed by
> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01262.html
>   -- foundation for toplevel driver cleanup

I feel that this is still trying to do too much at once.  Suggested
plan of attack:

Patch 0, rip all the dump-file code out of toplev.c into its own
file, call it rtl-dump.c.

Patch 1..n, one optimizer pass at a time, either modify the existing
entry point from toplev.c (preferred) or create a new entry point (if
the existing interface is needed elsewhere) to match a restricted
signature [bool (*)(void) suggested, where the return value means
'changed something'].  Push all the surrounding paraphernalia from
rest_of_compilation -- timevar pushes and pops, dump file handling,
etc -- down into the entry point function.  The entry point functions
should go in the same file as the rest of the pass, not in a separate
file.

Patch n+1 then introduces passes.def and converts rest_of_compilation
to a loop over a vector of function pointers.

> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02059.html
>   -- fix for latent bug in liveness analysis

This looks like a problem worth fixing, but (a) it's not obvious to me
why we are starting from nonempty sets in the first place, (b) it's
not obvious why your fallback strategy is guaranteed to terminate, and
(c) I'd like to see a test case that triggers nontermination.


> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01655.html
>   -- fix for ugly code generated for small array initializers

Feels like papering over the underlying problem; however, the
underlying problem is probably that we have ADDRESSOF in the first
place...  I'd like a reaction from someone better familiar with the
issues here.

> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01285.html
>   -- split log links creation from flow.c

Looks to *me* like a good cleanup.  But, since Richard objected, I
would rather hear what he thought of your response to his objection.

(create_log_links is only ever called with NULL parameter -- why is
that parameter present?)

zw

Re: Unreviewed patches

[Zdenek Dvorak]

Hello,

> > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01238.html
> >   wrong new files atached here, fixed by
> > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01262.html
> >   -- foundation for toplevel driver cleanup
> 
> I feel that this is still trying to do too much at once.  Suggested
> plan of attack:
> 
> Patch 0, rip all the dump-file code out of toplev.c into its own
> file, call it rtl-dump.c.
> 
> Patch 1..n, one optimizer pass at a time, either modify the existing
> entry point from toplev.c (preferred) or create a new entry point (if
> the existing interface is needed elsewhere) to match a restricted
> signature [bool (*)(void) suggested, where the return value means
> 'changed something'].  Push all the surrounding paraphernalia from
> rest_of_compilation -- timevar pushes and pops, dump file handling,
> etc -- down into the entry point function.  The entry point functions
> should go in the same file as the rest of the pass, not in a separate
> file.
> 
> Patch n+1 then introduces passes.def and converts rest_of_compilation
> to a loop over a vector of function pointers.

I don't like this idea too much:
1) I don't think I am able to create *that* much clean solution in one
   pass.
2) thus I would prefer to have all driver functions in one file so
   that they will be easier to access during following incremental
   updates.

I may split this patch somewhat like you suggest at point 2 (not exactly happy about
it, as it will require me to do about 30 trivial patches, but will do if
you insist).

> > http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02059.html
> >   -- fix for latent bug in liveness analysis
> 
> This looks like a problem worth fixing, but (a) it's not obvious to me
> why we are starting from nonempty sets in the first place,

because it is faster than to compute it always from scratch.

> (b) it's
> not obvious why your fallback strategy is guaranteed to terminate,

see the proof in the comment I have added to calculate_global_regs_live.

> and
> (c) I'd like to see a test case that triggers nontermination.

actually I am not aware of any just now. It have bitten me already
several times, and fixing it (by improving local updating of liveness
info) took me quite some time. Yes, probably this patch is not strictly
neccessary, but unless we are able to prove the current algorithm
always terminates on inputs we give to it, I would prefer to have
it corrected.

> > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01655.html
> >   -- fix for ugly code generated for small array initializers
> 
> Feels like papering over the underlying problem; however, the
> underlying problem is probably that we have ADDRESSOF in the first
> place...  I'd like a reaction from someone better familiar with the
> issues here.

me too.

> > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01285.html
> >   -- split log links creation from flow.c
> 
> Looks to *me* like a good cleanup.  But, since Richard objected, I
> would rather hear what he thought of your response to his objection.
> 
> (create_log_links is only ever called with NULL parameter -- why is
> that parameter present?)

because it might come in handy in future if we decided that we want/need
to update just some of log links (not quite probable).

Zdenek

Unreviewed patches

[Kazu Hirata]

Hi,

If somebody could review these patches, that would be greatly
appreciated.

[RFA] sim/h8300/h8300.c: Fix the handling of bxor.
http://sources.redhat.com/ml/gdb-patches/2003-01/msg00328.html

[RFA] sim/h8300/compile.c: Fix the handling of extu.w.
http://sources.redhat.com/ml/gdb-patches/2002-12/msg00685.html

[RFA] Fix the spurious failures on H8/300 port.
http://sources.redhat.com/ml/gdb-patches/2002-12/msg00450.html

Kazu Hirata

Re: Unreviewed patches

[Kazu Hirata]

Hi,

> If somebody could review these patches, that would be greatly
> appreciated.

I'm sorry.  I sent the message to a wrong list.

Kazu Hirata

Unreviewed patches

[Jerry Quinn]

http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00860.html
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00866.html

Original versions were OK'd by Geoff Keating, but updated patches
haven't been signed off.

Jerry Quinn

Unreviewed patches

[David Edelsohn]

	Below is my partial list of unreviewed patches submitted by others
over the past month...

David


Regrename:
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00036.html

NO-OP MOVE dump output:
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01362.html

GCC 3.2.2 PR backports:
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01162.html

sibcall failure:
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00305.html

MS bitfields:
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01171.html

REGNO_DECL cleanup:
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01202.html

dead unchanging mem stores:
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01164.html

Re: Unreviewed patches

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> sibcall failure:
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00305.html

This is OK except the change to the comment in function.h;
the old comment is correct and is what the patch now implements.
You can just commit it without that chunk.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Unreviewed patches

[Dale Johannesen]

On Wednesday, January 8, 2003, at 02:53  PM, David Edelsohn wrote:
> sibcall failure:
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00305.html

Actually there are 2 different sibcall patches, this is the other one.
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01310.html
The diffs there include a version of the other sibcall patch (above)
which is different from what Geoff finally accepted; I'll fix that.

Unreviewed patches

[Hans-Peter Nilsson]

[RFA:] docs: FUNCTION_ARG_CALLEE_COPIES vs. FUNCTION_ARG_PASS_BY_REFERENCE.
<URL:http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00634.html>.

[RFA:] lib/prune.exp: Prune more warnings for unimplemented -fpic/-fPIC
<URL:http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01593.html>.

brgds, H-P

Re: Unreviewed patches

[Geoff Keating]

Hans-Peter Nilsson <hp@bitrange.com> writes:

> [RFA:] lib/prune.exp: Prune more warnings for unimplemented -fpic/-fPIC
> <URL:http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01593.html>.

The warning for the case when only one is not supported would have
better grammar if it read

"warning: -fpic is not supported"

If you could change the regexp to match this, the patch is OK.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Unreviewed patches

[Hans-Peter Nilsson]

On 19 Nov 2002, Geoff Keating wrote:
> The warning for the case when only one is not supported would have
> better grammar if it read
>
> "warning: -fpic is not supported"
>
> If you could change the regexp to match this, the patch is OK.

Thanks for the review.

It's both -fpic and -fPIC anyway for all cases I know of (it
should be, anyway), it's just printed only for the specified
option.  This is what I'll commit once I get a chance to test
it.

	* lib/prune.exp: Prune more -fpic/-fPIC warnings.

Index: prune.exp
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/lib/prune.exp,v
retrieving revision 1.8
diff -p -c -r1.8 prune.exp
*** prune.exp	2 Oct 2002 20:01:38 -0000	1.8
--- prune.exp	20 Nov 2002 13:02:35 -0000
*************** proc prune_gcc_output { text } {
*** 24,31 ****
      regsub -all "(^|\n)collect2: ld returned \[^\n\]*" $text "" text
      regsub -all "(^|\n)Please submit.*instructions\[^\n\]*" $text "" text

!     # Ignore harmless -fpic warnings on cygwin.
      regsub -all "(^|\n)\[^\n\]*: warning: -f(pic|PIC) ignored for target\[^\n\]*" $text "" text

      # It would be nice to avoid passing anything to gcc that would cause it to
      # issue these messages (since ignoring them seems like a hack on our part),
--- 24,32 ----
      regsub -all "(^|\n)collect2: ld returned \[^\n\]*" $text "" text
      regsub -all "(^|\n)Please submit.*instructions\[^\n\]*" $text "" text

!     # Ignore harmless -fpic warnings.
      regsub -all "(^|\n)\[^\n\]*: warning: -f(pic|PIC) ignored for target\[^\n\]*" $text "" text
+     regsub -all "(^|\n)\[^\n\]*: warning: -f(pic|PIC)( and -fpic are| is)? not supported\[^\n\]*" $text "" text

      # It would be nice to avoid passing anything to gcc that would cause it to
      # issue these messages (since ignoring them seems like a hack on our part),

brgds, H-P

Unreviewed patches

[Jason R Thorpe]

Spec functions:

	http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00135.html

...with a quote from my original request for approval:

 --- snip ---

Now, my dilemma -- I was hoping for something simple enough that could go
into 3.3 at this stage (and the 3.2 branch) that would address the issue
outlined in my original message ([1]).  However, the result ended up being
a bit more complicated ... so I'm worried that, if approved, it would only
be for 3.4-b-i-b.
 
Bootstrapped/regtested on mainline with alpha-netbsd.

 --- snip ---



Duff's device testcases, one showing a regression relative to 2.95.3:

	http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00254.html



Testcase from PR optimization/8492:

	http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00469.html

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Unreviewed patches

[Joern Rennecke]

Thu Jul 11 11:39:11 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* simplify-rtx.x (simplify_subreg): When constructing a CONST_VECTOR
	from individual subregs, check that each subreg has been generated
	sucessfully.

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00667.html


Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* recog.c (asm_operand_ok): Allow float CONST_VECTORs for 'F'.
	(constrain_operands): Likewise.
	* regclass.c (record_reg_classes): Likewise.
	* reload.c (find_reloads): Likewise.

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00664.html


Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>

gcc:
	* reload.c (find_reloads_toplev): Use simplify_gen_subreg.
	* simplify-rtx.c (simplify_subreg): When converting to a non-int
	mode, try to convert to an integer mode of matching size first.

gcc/testsuite:
	* gcc.c-torture/compile/simd-4.c: New test.

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00662.html



-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed patches

[Geoff Keating]

Joern Rennecke <joern.rennecke@superh.com> writes:

> Thu Jul 11 11:39:11 2002  J"orn Rennecke <joern.rennecke@superh.com>
> 
> 	* simplify-rtx.x (simplify_subreg): When constructing a CONST_VECTOR
> 	from individual subregs, check that each subreg has been generated
> 	sucessfully.
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00667.html

This is OK.

> Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>
> 
> 	* recog.c (asm_operand_ok): Allow float CONST_VECTORs for 'F'.
> 	(constrain_operands): Likewise.
> 	* regclass.c (record_reg_classes): Likewise.
> 	* reload.c (find_reloads): Likewise.
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00664.html

I'm a bit worried that this might change the semantics of an existing port.
Are there any current ports that use 'F' and allow any mode?

Also, it needs a documentation change.

> 
> Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>
> 
> gcc:
> 	* reload.c (find_reloads_toplev): Use simplify_gen_subreg.
> 	* simplify-rtx.c (simplify_subreg): When converting to a non-int
> 	mode, try to convert to an integer mode of matching size first.
> 
> gcc/testsuite:
> 	* gcc.c-torture/compile/simd-4.c: New test.
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00662.html

That's clever, let's try it.  OK to commit.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Unreviewed patches

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

Geoff Keating wrote:
> 
> Joern Rennecke <joern.rennecke@superh.com> writes:
> 
> > Thu Jul 11 11:39:11 2002  J"orn Rennecke <joern.rennecke@superh.com>
> >
> >       * simplify-rtx.x (simplify_subreg): When constructing a CONST_VECTOR
> >       from individual subregs, check that each subreg has been generated
> >       sucessfully.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00667.html
> 
> This is OK.
> >
> > Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>
> >
> > gcc:
> >       * reload.c (find_reloads_toplev): Use simplify_gen_subreg.
> >       * simplify-rtx.c (simplify_subreg): When converting to a non-int
> >       mode, try to convert to an integer mode of matching size first.
> >
> > gcc/testsuite:
> >       * gcc.c-torture/compile/simd-4.c: New test.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00662.html
> 
> That's clever, let's try it.  OK to commit.

Thanks, commmitted.

> > Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>
> >
> >       * recog.c (asm_operand_ok): Allow float CONST_VECTORs for 'F'.
> >       (constrain_operands): Likewise.
> >       * regclass.c (record_reg_classes): Likewise.
> >       * reload.c (find_reloads): Likewise.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00664.html
> 
> I'm a bit worried that this might change the semantics of an existing port.
> Are there any current ports that use 'F' and allow any mode?

This would only be relevant if an instruction that has a CONST_VECTOR
source is recognized first, i.e. allowed by the predicates.  All my
change is likely to do in such an circumstance is to change a reload
failure into recognizing an alternative that might not be what the author
intended (but then, it might be).
Well, unless you have an instruction where the 'F' alternative is
supposed to match only for non-vector modes, and some other alternatives
are used for vector modes.  I suppose such a construct would come into
the category 'you deserve whatever you get'.
	
> Also, it needs a documentation change.

I've added two words to md.texi in the appended patch.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

[-- Attachment #2: simd-fix-11-2 --]
[-- Type: text/plain, Size: 3523 bytes --]

Tue Jul 23 21:13:27 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* recog.c (asm_operand_ok): Allow float CONST_VECTORs for 'F'.
	(constrain_operands): Likewise.
	* regclass.c (record_reg_classes): Likewise.
	* reload.c (find_reloads): Likewise.
	* doc/md.texi: Likewise.

Index: recog.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/recog.c,v
retrieving revision 1.160
diff -p -r1.160 recog.c
*** recog.c	28 Jun 2002 15:43:53 -0000	1.160
--- recog.c	12 Jul 2002 02:57:14 -0000
*************** asm_operand_ok (op, constraint)
*** 1730,1736 ****
  
  	case 'E':
  	case 'F':
! 	  if (GET_CODE (op) == CONST_DOUBLE)
  	    return 1;
  	  break;
  
--- 1730,1738 ----
  
  	case 'E':
  	case 'F':
! 	  if (GET_CODE (op) == CONST_DOUBLE
! 	      || (GET_CODE (op) == CONST_VECTOR
! 		  && GET_MODE_CLASS (GET_MODE (op)) == MODE_VECTOR_FLOAT))
  	    return 1;
  	  break;
  
*************** constrain_operands (strict)
*** 2498,2504 ****
  
  	      case 'E':
  	      case 'F':
! 		if (GET_CODE (op) == CONST_DOUBLE)
  		  win = 1;
  		break;
  
--- 2500,2508 ----
  
  	      case 'E':
  	      case 'F':
! 		if (GET_CODE (op) == CONST_DOUBLE
! 		    || (GET_CODE (op) == CONST_VECTOR
! 			&& GET_MODE_CLASS (GET_MODE (op)) == MODE_VECTOR_FLOAT))
  		  win = 1;
  		break;
  
Index: regclass.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/regclass.c,v
retrieving revision 1.152
diff -p -r1.152 regclass.c
*** regclass.c	16 Jun 2002 21:52:39 -0000	1.152
--- regclass.c	12 Jul 2002 02:57:15 -0000
*************** record_reg_classes (n_alts, n_ops, ops, 
*** 1635,1641 ****
  
  	      case 'E':
  	      case 'F':
! 		if (GET_CODE (op) == CONST_DOUBLE)
  		  win = 1;
  		break;
  
--- 1635,1644 ----
  
  	      case 'E':
  	      case 'F':
! 		if (GET_CODE (op) == CONST_DOUBLE
! 		    || (GET_CODE (op) == CONST_VECTOR
! 			&& (GET_MODE_CLASS (GET_MODE (op))
! 			    == MODE_VECTOR_FLOAT)))
  		  win = 1;
  		break;
  
Index: reload.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.185
diff -p -r1.185 reload.c
*** reload.c	14 Jun 2002 01:41:53 -0000	1.185
--- reload.c	12 Jul 2002 02:57:15 -0000
*************** find_reloads (insn, replace, ind_levels,
*** 3142,3148 ****
  
  	      case 'E':
  	      case 'F':
! 		if (GET_CODE (operand) == CONST_DOUBLE)
  		  win = 1;
  		break;
  
--- 3142,3151 ----
  
  	      case 'E':
  	      case 'F':
! 		if (GET_CODE (operand) == CONST_DOUBLE
! 		    || (GET_CODE (operand) == CONST_VECTOR
! 			&& (GET_MODE_CLASS (GET_MODE (operand))
! 			    == MODE_VECTOR_FLOAT)))
  		  win = 1;
  		break;
  
Index: doc/md.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/md.texi,v
retrieving revision 1.44
diff -p -r1.44 md.texi
*** doc/md.texi	30 Jun 2002 19:27:48 -0000	1.44
--- doc/md.texi	23 Jul 2002 20:12:40 -0000
*************** that of the host machine (on which the c
*** 845,852 ****
  
  @cindex @samp{F} in constraint
  @item @samp{F}
! An immediate floating operand (expression code @code{const_double}) is
! allowed.
  
  @cindex @samp{G} in constraint
  @cindex @samp{H} in constraint
--- 845,852 ----
  
  @cindex @samp{F} in constraint
  @item @samp{F}
! An immediate floating operand (expression code @code{const_double} or
! @code{const_vector}) is allowed.
  
  @cindex @samp{G} in constraint
  @cindex @samp{H} in constraint

Re: Unreviewed patches

[Geoff Keating]

> Date: Tue, 23 Jul 2002 21:20:21 +0100
> From: Joern Rennecke <joern.rennecke@superh.com>

> > > Mon Jul 15 12:32:59 2002  J"orn Rennecke <joern.rennecke@superh.com>
> > >
> > >       * recog.c (asm_operand_ok): Allow float CONST_VECTORs for 'F'.
> > >       (constrain_operands): Likewise.
> > >       * regclass.c (record_reg_classes): Likewise.
> > >       * reload.c (find_reloads): Likewise.
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00664.html
> > 
> > I'm a bit worried that this might change the semantics of an existing port.
> > Are there any current ports that use 'F' and allow any mode?
> 
> This would only be relevant if an instruction that has a CONST_VECTOR
> source is recognized first, i.e. allowed by the predicates.  All my
> change is likely to do in such an circumstance is to change a reload
> failure into recognizing an alternative that might not be what the author
> intended (but then, it might be).
> Well, unless you have an instruction where the 'F' alternative is
> supposed to match only for non-vector modes, and some other alternatives
> are used for vector modes.  I suppose such a construct would come into
> the category 'you deserve whatever you get'.

That makes sense.

> > Also, it needs a documentation change.
> 
> I've added two words to md.texi in the appended patch.

Thank you!  The patch is OK.

> -- 
> --------------------------
> SuperH
> 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
> T:+44 1454 462330
> --------------EDDA08344DE673F2D3767AD6
> Content-Type: text/plain; charset=us-ascii;
>  name="simd-fix-11-2"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="simd-fix-11-2"
> 
> Tue Jul 23 21:13:27 2002  J"orn Rennecke <joern.rennecke@superh.com>
> 
> 	* recog.c (asm_operand_ok): Allow float CONST_VECTORs for 'F'.
> 	(constrain_operands): Likewise.
> 	* regclass.c (record_reg_classes): Likewise.
> 	* reload.c (find_reloads): Likewise.
> 	* doc/md.texi: Likewise.
-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Unreviewed patches

[Dan Nicolaescu]

A simple one:
http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01136.html
  print-tree.c:print_node does not print the "restrict" qualifier. 


char* restrict should not be put in alias set 0

one proposal to fix that is here:
http://gcc.gnu.org/ml/gcc/2002-05/msg00924.html

and the old one:
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00274.html

Any suggestions for a better way to do this? 

Unreviewed patches

[Joern Rennecke]

Tue Jun 18 15:56:43 2002  J"orn Rennecke <joern.rennecke@superh.com>

* loop.c (prescan_loop): If FUNCTION_ARG_PASS_BY_REFERENCE is
        defined, take CALL_INSN_FUNCTION_USAGE of const / pure functions
        into account.
        (insert_loop_mem): Likewise.

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01502.html


Fri Jun 28 13:04:33 2002  J"orn Rennecke <joern.rennecke@superh.com>

* hwint.c (define HOST_WIDE_INT_PRINT_DEC_C): New define.
        * genrecog.c (write_switch, write_cond): Use it.
        * genemit.c (gen_exp): Likewise.


http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02224.html


Sun Jul  7 17:47:56 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* optabs.c (expand_vector_unop): Don't expand using sub_optab
	if we got the wrong mode.

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00328.html


-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed patches

[Richard Henderson]

On Mon, Jul 15, 2002 at 01:21:53PM +0100, Joern Rennecke wrote:
> * hwint.c (define HOST_WIDE_INT_PRINT_DEC_C): New define.
>         * genrecog.c (write_switch, write_cond): Use it.
>         * genemit.c (gen_exp): Likewise.
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02224.html

Ok.


r~

Re: Unreviewed patches

[Richard Henderson]

On Mon, Jul 15, 2002 at 01:21:53PM +0100, Joern Rennecke wrote:
> Sun Jul  7 17:47:56 2002  J"orn Rennecke <joern.rennecke@superh.com>
> 
> 	* optabs.c (expand_vector_unop): Don't expand using sub_optab
> 	if we got the wrong mode.
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00328.html

Ok.


r~

Re: Unreviewed patches

[Richard Henderson]

On Mon, Jul 15, 2002 at 01:21:53PM +0100, Joern Rennecke wrote:
> * loop.c (prescan_loop): If FUNCTION_ARG_PASS_BY_REFERENCE is
>         defined, take CALL_INSN_FUNCTION_USAGE of const / pure functions
>         into account.
>         (insert_loop_mem): Likewise.
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01502.html

This was supposed to be taken care of in calls.c be
eliminating the const/pure tag:

calls.c:1276
              *ecf_flags &= ~(ECF_CONST | ECF_PURE | ECF_LIBCALL_BLOCK);

It's likely that this needs to be moved a bit to catch the
other cases under the FUNCTION_ARG_PASS_BY_REFERENCE check.


r~

unreviewed patches

[Paul Koning]

2002-06-07	Paul Koning	<pkoning@equallogic.com>

	* real.c (REAL_WORDS_BIG_ENDIAN): Make 1 for DEC.
	(LARGEST_EXPONENT_IS_NORMAL): Ditto.
	(VAX_HALFWORD_ORDER): Define (1 for DEC VAX, 0 otherwise).
	(TARGET_G_FLOAT): Default to 0 if not defined.
	(ieeetoe): New, common routine to convert target format floats 
	to internal form.
	(e24toe, e53toe): Change to use ieeetoe, distinguish DEC
	vs. others.
	(e113toe): Change to use ieeetoe.

2002-05-30  Roman Lechtchinsky  <rl@cs.tu-berlin.de>

* real.c (REAL_WORDS_BIG_ENDIAN): Make sure it is 0 for DEC and 1 for
	IBM.
	(e53toe): Assume IEEE if non of DEC, IBM and C4X is defined.
	(e64toe): Remove special cases for DEC and IBM. Remove support for
	ARM_EXTENDED_IEEE_FORMAT.
	(e24toe): Remove special cases for DEC.
	(significand_size): Simplify. Indent.
	(ieee_format, ieee_24, ieee_53, ieee_64, ieee_113): New.
	(etoieee, toieee): New.
	(etoe113, toe113, etoe64, toe64, etoe53, toe53, etoe24, toe24): Use
	etoieee and toieee for IEEE arithmetic.

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00645.html

	paul

Unreviewed patches

[Joern Rennecke]

Tue Jun 18 15:56:43 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* loop.c (prescan_loop): If FUNCTION_ARG_PASS_BY_REFERENCE is
        defined, take CALL_INSN_FUNCTION_USAGE of const / pure functions
        into account.
        (insert_loop_mem): Likewise.

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01502.html


Thu Jun 27 00:01:17 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* optabs.c (expand_vector_binop): Don't store using a SUBREG smaller
        than UNITS_PER_WORD, unless this is little endian and the first unit
        in this word.  Let extract_bit_field decide how to load an element.
        Force arguments to matching mode.
        (expand_vector_unop): Likewise.
        * simplify-rtx.c (simplify_subreg): Don't assume that all vectors
        consist of word_mode elements.

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02174.html


Fri Jun 28 13:04:33 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* hwint.c (define HOST_WIDE_INT_PRINT_DEC_C): New define.
        * genrecog.c (write_switch, write_cond): Use it.
        * genemit.c (gen_exp): Likewise.


http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02224.html

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed patches

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > On Thu, Mar 07, 2002 at 11:30:18PM -0500, Kaveh R. Ghazi wrote:
 > >  > 1. Patch to const-ify tree_code_{type,name,length}
 > >  > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02395.html
 > 
 > This one's been put in, right?

Yup, thanks anyway.

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Global Services

Unreviewed patches

[Kaveh R. Ghazi]

 > From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu> 
 > Date: Mon, 7 Jan 2002 22:24:07 -0500 (EST) 
 > 
 > I'd appreciate it if someone would please review the following.
 > 
 > 1. Patch to const-ify tree_code_{type,name,length}
 > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02395.html
 > 
 > 2. Patch to const-ify *debug_hooks + add missing debug.o dependency
 > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00046.html
 > 
 > I've since bootstrapped #1 with ada enabled in case that was a
 > concern.  Their both pretty tame stuff (especially #2.)
 > 
 > Ok to install (either now or after 3.1 is branched?)

These two are still awaiting review.  Would someone please take a
look?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Global Services

Re: Unreviewed patches

[Richard Henderson]

On Thu, Mar 07, 2002 at 11:30:18PM -0500, Kaveh R. Ghazi wrote:
>  > 1. Patch to const-ify tree_code_{type,name,length}
>  > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02395.html

This one's been put in, right?

>  > 2. Patch to const-ify *debug_hooks + add missing debug.o dependency
>  > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00046.html

Ok.


r~

Re: Unreviewed patches

[Kaveh R. Ghazi]

 > From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu> 
 > Date: Mon, 7 Jan 2002 22:24:07 -0500 (EST) 
 > 
 > I'd appreciate it if someone would please review the following.
 > 
 > 1. Patch to const-ify tree_code_{type,name,length}
 > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02395.html
 > 
 > 2. Patch to const-ify *debug_hooks + add missing debug.o dependency
 > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00046.html
 > 
 > I've since bootstrapped #1 with ada enabled in case that was a
 > concern.  Their both pretty tame stuff (especially #2.)
 > 
 > Ok to install (either now or after 3.1 is branched?)

These two are still awaiting review.  Would someone please take a
look?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Global Services

Unreviewed patches

[Billinghurst, David (CRTS)]

Some unreviewed patches:

Fixes for PRs

PR 5588 Fix setting of LD_LIBRARY*_PATH in g++, g77 and objc testsuites 
http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00208.html


Warning patrol

gcc: http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00444.html
java: builtins.c part of http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00445.html


g++ testsuite fix

http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01937.html

RE: Unreviewed patches

[Billinghurst, David (CRTS)]

Thanks. It is also OK on irix6.5.  

I will check it in shortly, and watch to see if anyone else notices :-)

-----Original Message-----
From: Stan Shebs [mailto:shebs@apple.com]
Sent: Sunday, 17 February 2002 5:07 
To: Billinghurst, David (CRTS)
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Unreviewed patches


"Billinghurst, David (CRTS)" wrote:
> 
> PR 4582 Fix total failure of objc on cygwin (regression from 3.0)
> http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00578.html

This is OK, thanks.  I tried it out on my Linux machine and it
worked fine, that was my one bit of doubt.

Stan

Unreviewed patches

[Billinghurst, David (CRTS)]

Here are a few unreviewed patches.  Be nice to get them looked at before the 3.1 branch

Fixes for PRs that I consider important

PR 5588 Fix setting of LD_LIBRARY*_PATH in G++, g77 and objc testsuites 
http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00208.html

PR 4582 Fix total failure of objc on cygwin (regression from 3.0)
http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00578.html


Warning patrol

gcc: http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00444.html
java: builtins.c part of http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00445.html


Small testsuite fixes

http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01937.html


Major fortran testsuite additions (perhaps for 3.2)

http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00475.html

Re: Unreviewed patches

[Toon Moene]

"Billinghurst, David (CRTS)" wrote:

> Major fortran testsuite additions (perhaps for 3.2)
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00475.html

Seems like a good idea to postpone them until the 3.1 branch has been
made (next week).  Otherwise, we'll (potentially) have to explain or fix
some new FAILures :-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Unreviewed patches

[Toon Moene]

Over a month ago, I wrote:

> "Billinghurst, David (CRTS)" wrote:

> > Major fortran testsuite additions (perhaps for 3.2)
> >
> > http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00475.html
> 
> Seems like a good idea to postpone them until the 3.1 branch has been
> made (next week).  Otherwise, we'll (potentially) have to explain or fix
> some new FAILures :-)

As the 3.1 branch has been created, now is a good time to add these
tests to the main line.

Thanks !

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Unreviewed patches

[Stan Shebs]

"Billinghurst, David (CRTS)" wrote:
> 
> PR 4582 Fix total failure of objc on cygwin (regression from 3.0)
> http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00578.html

This is OK, thanks.  I tried it out on my Linux machine and it
worked fine, that was my one bit of doubt.

Stan

Unreviewed patches

[Roger Sayle]

The following patches are still awaiting review.  I believe the first
two fixes are candidates for GCC 3.1, whilst the remaining five from
last year can probably wait until after the freeze, but are listed
below for completeness. (They predate the freeze so are elligible for
3.1 if a reviewer thinks any of them are suitable).


http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01470.html
Fix host_integerp, the cause of array indexing problems (PR c/4389).

http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00145.html
Avoid emitting stack adjustments of zero bytes.


http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01628.html
Pure and const attributes for builtins.

http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01845.html
Preserve builtin attributes in C/C++.

http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01723.html
Specify pure and const attributes using builtin-attrs.def.

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00296.html
Support "nothrow" function attribute.

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00297.html
C++ builtins go in both std and global namespaces.


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Unreviewed patches

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

| http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00297.html
| C++ builtins go in both std and global namespaces.

This patch (at least, as described) makes wrong assumptions.
For example, <string.h> declares std::strlen and ::strlen whereas
<cstring> declares only std::strlen.  A name 'foo' declared by <xxx.h>
behave as if it were declared

    namespace std
    {
       // 'foo' declaration goes here
    }

    using std::foo;

The same should apply to builtins.  And I think builtin names should
begin with a double underscore.  Why do you want to remove them?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: Unreviewed patches

[Joseph S. Myers]

On 1 Feb 2002, Gabriel Dos Reis wrote:

> The same should apply to builtins.  And I think builtin names should
> begin with a double underscore.  Why do you want to remove them?

I think the C++ front end is correct just to declare the __builtin names
(flag_no_builtin always set to 1) and require the headers to make
appropriate definitions that use the built-in functions.

__builtin names may be predeclared by the compiler.  All others should
need to be declared explicitly - for C++, by the standard headers, though
in C it is OK for programs to declare some standard functions themselves
(and C90 allows implicit declarations).  Such functions should be treated
as undeclared until they are declared by a header or the program, at which
point, for C only (since for C++ it must be the headers declaring the
functions) it may be decided that the function declared can be built-in.

See my outline at
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01783.html
which discusses a possible direction for cleaning up handling of built-in 
functions and attributes along those lines.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patches

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On 1 Feb 2002, Gabriel Dos Reis wrote:
| 
| > The same should apply to builtins.  And I think builtin names should
| > begin with a double underscore.  Why do you want to remove them?
| 
| I think the C++ front end is correct just to declare the __builtin names
| (flag_no_builtin always set to 1) and require the headers to make
| appropriate definitions that use the built-in functions.
| 
| __builtin names may be predeclared by the compiler. 

Just to clarify my previous message, I think __builtin_xxx can (and
should) be predeclared by the front-end.  At the same time I
completely agree with:

| All others should
| need to be declared explicitly - for C++, by the standard headers, though
| in C it is OK for programs to declare some standard functions themselves
| (and C90 allows implicit declarations).  Such functions should be treated
| as undeclared until they are declared by a header or the program, at which
| point, for C only (since for C++ it must be the headers declaring the
| functions) it may be decided that the function declared can be built-in.

-- Gaby

Re: Unreviewed patches

[Roger Sayle]

Hi Joseph and Gaby,
> > The same should apply to builtins.  And I think builtin names should
> > begin with a double underscore.  Why do you want to remove them?
>
> I think the C++ front end is correct just to declare the __builtin names
> (flag_no_builtin always set to 1) and require the headers to make
> appropriate definitions that use the built-in functions.
>
> __builtin names may be predeclared by the compiler.  All others should
> need to be declared explicitly - for C++, by the standard headers, though
> in C it is OK for programs to declare some standard functions themselves
> (and C90 allows implicit declarations).  Such functions should be treated
> as undeclared until they are declared by a header or the program, at which
> point, for C only (since for C++ it must be the headers declaring the
> functions) it may be decided that the function declared can be built-in.
>
> See my outline at http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01783.html
> which discusses a possible direction for cleaning up handling of built-in
> functions and attributes along those lines.

I see this patch, adding builtins to both std and global namespaces, and
several of the others concerning attributes of builtin functions as the
necessary first steps towards implementing Joseph's outline for how
builtins should be handled in the C and C++ front-ends.

The first misunderstanding that needs to be cleared up is that GCC
builtin function does not need to be predeclared.  I completely agree
that for the C++ front-end to make use of an "intrinsic" function, it
needs to be explicitly prototyped, typically by a system header.  Use
of a builtin function without a prototype should result in a compiler
error or warning in both the C and C++ front-ends.  Similarly, it should
be possible to use a builtin identifier in a different context provided
that a prototype hasn't been encountered, "int strlen;".

I believe that the correct way to do this is to correctly honor the
DECL_ANTICIPATED flag on the declaration.  In the C++ front-end,
if builtins were re-enabled, the forms of builtins with names that
start with two underscores are predeclarerd, but the names without
the underscores are registered in the symbol table, but marked as
"anticipated" (DECL_ANTICIPATED(decl) = 1).  My interpretation is
that these identifiers are flagged for special treatment once a
suitable definition or prototype is encountered, but should behave as
undeclared until then.


As I explained http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01723.html
this mechanism of "anticipating" rather than predeclaring identifiers
in the symbol table is dramtically more efficient than trying to recognize
a "special" identifier by other means each time an identifier is
encountered.


Once implemented correctly, DECL_ANTICIPATED, should also be able to
replace both "special_function_p" and in "nothrow_lib_fn_p", as all of
the functions in the standard C library should be anticipated with their
correct function attributes, including "nothrow".  This would then allow
builtins to be re-enabled resulting in nice performance increase for C++
code.


But getting back to that particular patch at hand, both ::strlen and
std::strlen will need to be anticipated in this new scheme.  And both
functions should then be marked "pure" and "nothrow".  Currently
the C front end will optimize "strlen(ptr) > 0". Eventually I would
hope that C++ should be able to optimize both "::strlen(ptr) > 0" and
"std::strlen(ptr) > 0" provided the function has been defined by the
system header.


If you'd like me to explain any more of the intermediate steps in the
planned vision of builtins in the C/C++ front-ends, I'm more than happy
to share, but I've been waiting until after the freeze before continuing
this series of patches.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Unreviewed patches

[Joseph S. Myers]

On Fri, 1 Feb 2002, Roger Sayle wrote:

> "anticipated" (DECL_ANTICIPATED(decl) = 1).  My interpretation is
> that these identifiers are flagged for special treatment once a
> suitable definition or prototype is encountered, but should behave as
> undeclared until then.

Then the first step must be not any of these patches (except for attribute
nothrow, which is probably independent of the rest and fairly safe), but
making this work properly.  For example, if, in C, a call llabs(0) is
encountered with no declaration of llabs, the compiler treats it as a
built-in function.  This is wrong; the call implicitly declares it as int
llabs(), which is not compatible with the built-in function type, and
calls that with an int (not long long) argument.  Such decls must do no 
more than storing information about a possible built-in function 
conveniently in the symbol table; in no way do they declare it, just 
provide information to associate with a declaration.  (In the case where 
the function declared incompatibly is a standard one, e.g. llabs in C99 
mode, there should be a warning on redeclaration.)

> But getting back to that particular patch at hand, both ::strlen and
> std::strlen will need to be anticipated in this new scheme.  And both

No, they need to be inline functions in the C++ headers that call
__builtin_strlen.  For C++ we control the standard headers (and only the
headers, not explicit declarations by users, can be used to access the
functions) so can readily do this.  Given them inline in the headers, we
don't then need the compiler to make them built-in.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patches

[Roger Sayle]

> > But getting back to that particular patch at hand, both ::strlen and
> > std::strlen will need to be anticipated in this new scheme.  And both
>
> No, they need to be inline functions in the C++ headers that call
> __builtin_strlen.  For C++ we control the standard headers (and only the
> headers, not explicit declarations by users, can be used to access the
> functions) so can readily do this.  Given them inline in the headers,
> we don't then need the compiler to make them built-in.

No.  I'd like to agree with you, but your vision of a world where g++
controlled the system headers and defined all the standard C library
functions as C++ inline functions calling __builtin_ versions is almost
science fiction.  Including <string.h> on most g++ platforms includes the
system /usr/include/string.h, (i.e. the one shared with the native system
compiler) which often doesn't contain a complete set of GCC function
attribute extensions, and in order to work with C compilers, often isn't
a C++ inline function wrapper.


To point out some of the flaws in both your and Gaby's arguments,
consider the following simple source file:

#include <string.h>

int foo () { return ::strlen("Hello world"); }
int bar () { return std::strlen("Hello world"); }

When compiled using g++ v3.1 on both i686-pc-cygwin and i686-pc-linux-gnu
(redhat 7.2),  bar gives a warning message that strlen is undeclared in
namespace std (sorry Gaby), and the resulting foo contains an explicit
call to "strlen".  In an ideal world, and with the gcc compiler, the
function is evaluated to the constant 11 at compile time.

Admittedly, your vision of the future could be made to work with clever
things done with fixincludes on all platforms, to add #ifdef checks for
g++ and redefine all standard library  functions as inline calls to the
__builtin variants, but I think you'll agree that fixing it in the
compiler in a method similar to how its handled in the C front end would
be preferable.  Certainly in the 3.2 or 3.3 timeframe, even for glibc
platforms.

Feel free to both approve my patches and submit the necessary fixinclude
magic, they're not mutually exclusive.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Unreviewed patches

[Joseph S. Myers]

On Fri, 1 Feb 2002, Roger Sayle wrote:

> No.  I'd like to agree with you, but your vision of a world where g++
> controlled the system headers and defined all the standard C library
> functions as C++ inline functions calling __builtin_ versions is almost
> science fiction.  Including <string.h> on most g++ platforms includes the
> system /usr/include/string.h, (i.e. the one shared with the native system
> compiler) which often doesn't contain a complete set of GCC function
> attribute extensions, and in order to work with C compilers, often isn't
> a C++ inline function wrapper.

The idea of c_shadow is ISTR to fix the problems associated with
<string.h> including the system header.  Eventually it is supposed to be
the case that the system C headers aren't directly included unless they
are ready for the C++ standard (which some are to some extent, e.g.
Solaris), since C and C++ have different requirements for some headers.

http://www.cantrip.org/cheaders.html

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patches

[Roger Sayle]

> The idea of c_shadow is ISTR to fix the problems associated with
> <string.h> including the system header.  Eventually it is supposed to be
> the case that the system C headers aren't directly included unless they
> are ready for the C++ standard (which some are to some extent, e.g.
> Solaris), since C and C++ have different requirements for some headers.
>
> http://www.cantrip.org/cheaders.html

I do appreciate that the draft proposal described in that URL would
solve many of these issues.  But from the copyrights, its been nearly
four years in the preparation and still isn't widely adopted.  And
to quote Gabriel Dos Reis from my most recent patch to the c_shadow
headers (from http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02519.html)

>> Currently, the shadowed headers are in unfortunate states on all
>> platforms (I believe) :-(


I also doubt even Solaris' C++ ready string.h contains the necessary g++
extern inline size_t std::strlen(const char*s) {return __builtin_strlen(s);}
or even just a fully decorated g++ function prototype such as
extern "C" size_t strlen(const char*) __attribute__((pure,nothrow));
Even mainline CVS' libstdc++[v3] doesn't mention __builtin_strlen,
and makes no use of pure or const attributes!


Whilst back in the here and now, the inability of g++ 3.x to evaluate
std::strlen("Hello world") at compile time is actually a regression from
v2.95.3.


It is not unusual for bugs in GCC to be fixed independently by several
patches.  And indeed if c_shadow does eventually resolve this issue, I'll
not object to some of my patches being reverted.  Indeed either solution
will remove the need for special_function_p, nothrow_lib_fn_p and
insert_default_attributes, so many of the cleanups should remain.
My approach would also decrease the divergence between the C and C++
front-ends (comptypes etc), which I would have thought was a good thing.


Is there an alternative fix that anyone's actively working on for 3.2?

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Unreviewed patches

[Joseph S. Myers]

On Fri, 1 Feb 2002, Roger Sayle wrote:

> My approach would also decrease the divergence between the C and C++
> front-ends (comptypes etc), which I would have thought was a good thing.

A lot of the functionality of your changes, such as this, can be done
without reverting the previous decision about built-in functions in C++.
Start with making anticipated decls work properly; I explained the
problem.  (Probably, normal lookups for a decl in the symbol table should
simply never return such decls; a special option should be needed, that
would only be passed when looking to see whether a particular function,
now declared, can be treated as built in.)  You might need to do the
common comptypes interface with flags first, so that the checks for
whether types are sufficiently compatible can be done cleanly.

The nothrow attribute patch is also independent of this, and I hope
someone will review it.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patches

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| The nothrow attribute patch is also independent of this, and I hope
| someone will review it.

Certainly!

Thanks,

-- Gaby

Re: Unreviewed patches

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

| I also doubt even Solaris' C++ ready string.h contains the necessary g++
| extern inline size_t std::strlen(const char*s) {return __builtin_strlen(s);}
| or even just a fully decorated g++ function prototype such as
| extern "C" size_t strlen(const char*) __attribute__((pure,nothrow));

It was reported that because Solaris' <string.h> is ready  for C++, it
defeats solutions we've devised.

| Whilst back in the here and now, the inability of g++ 3.x to evaluate
| std::strlen("Hello world") at compile time is actually a regression from
| v2.95.3.

The library shipped with GCC-2.95.x was not conformant; I can't see
how one can speak of regession.

| It is not unusual for bugs in GCC to be fixed independently by several
| patches. 


Nobody is saying the problem should not fixed by severral patches.
What I'm saying is this:  Give a detailed plan of the articulation of
patches, how they interact with the library expectations and how they
interact with C++ requirements and we can all examinate your patches.
The issue is too sensible to let patches in without a good
understanding of them.

-- Gaby

Re: Unreviewed patches

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

| > > But getting back to that particular patch at hand, both ::strlen and
| > > std::strlen will need to be anticipated in this new scheme.  And both
| >
| > No, they need to be inline functions in the C++ headers that call
| > __builtin_strlen.  For C++ we control the standard headers (and only the
| > headers, not explicit declarations by users, can be used to access the
| > functions) so can readily do this.  Given them inline in the headers,
| > we don't then need the compiler to make them built-in.
| 
| No.  I'd like to agree with you, but your vision of a world where g++
| controlled the system headers and defined all the standard C library
| functions as C++ inline functions calling __builtin_ versions is almost
| science fiction.

It is only science fiction if you think the library is correctly
implemented; and it is not.  That is a known issue.  Any work on the
compiler front-end in that regard should be coordinated with the
library folks, and note done in isolation, i.e. not complicated the
issue further.


|  Including <string.h> on most g++ platforms includes the
| system /usr/include/string.h, (i.e. the one shared with the native system
| compiler) which often doesn't contain a complete set of GCC function
| attribute extensions, and in order to work with C compilers, often isn't
| a C++ inline function wrapper.

That is a known issue.  It is also known that on a systems where we
can control the system C-header (e.g. Glibc-systems), the Glibc folks
will cooperate with us and mke the appropriatte declarations in the
appropriate headers.  Patching, in isolation, the front-end to do
something not fully understood, not in accordance with the library
folks expectations, isn't something I call a fix.


| To point out some of the flaws in both your and Gaby's arguments,
| consider the following simple source file:
| 
| #include <string.h>
| 
| int foo () { return ::strlen("Hello world"); }
| int bar () { return std::strlen("Hello world"); }
| 
| When compiled using g++ v3.1 on both i686-pc-cygwin and i686-pc-linux-gnu
| (redhat 7.2),  bar gives a warning message that strlen is undeclared in
| namespace std (sorry Gaby), and the resulting foo contains an explicit
| call to "strlen".

That is a flaw neither in my arguments, nor in Joseph's.  What I
described is the standard requirement.  That, in its actual form, it
is not implemented is a serious issue we've considered in the past and
still considering.  That is what makes me nervous about your insisting
getting your patch in the tree, while it doesn't meet our expectations.

-- Gaby

Unreviewed patches

[Kazu Hirata]

Hi,

Could somebody review these patches?

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02499.html
  Fix dump file names in invoke.texi.

http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00279.html
  Remove a suspicious checking in rtlanal.c.  

Thanks,

Kazu Hirata

Unreviewed patches

[Kaveh R. Ghazi]

I'd appreciate it if someone would please review the following.

1. Patch to const-ify tree_code_{type,name,length}
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02395.html

2. Patch to const-ify *debug_hooks + add missing debug.o dependency
http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00046.html

I've since bootstrapped #1 with ada enabled in case that was a
concern.  Their both pretty tame stuff (especially #2.)

Ok to install (either now or after 3.1 is branched?)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Global Services

Unreviewed patches

[Kaveh R. Ghazi]

I'd appreciate it if someone would please review the following.

		Thanks,
		--Kaveh


The non-cpp portions of this patch to utilize hex_p & hex_value in
gcc.  (The cpp portions already were reviewed.):
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00595.html

Get nextstep platforms compiling:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00831.html

Eliminate "traditional C rejects the 'u' suffix" warnings:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01273.html

Perform builtin optimizations on "unlocked" stdio:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01886.html

Fix traditional C "const" problem when building the g77 driver:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01999.html

Fix macro redefinition warnings on various cross targets:
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00107.html

Fix signed/unsigned warnings in definitions of ASM_OUTPUT_ASCII:
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00110.html

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Unreviewed patches

[Richard Henderson]

On Sat, Dec 08, 2001 at 09:01:11AM -0500, Kaveh R. Ghazi wrote:
> The non-cpp portions of this patch to utilize hex_p & hex_value in
> gcc.  (The cpp portions already were reviewed.):
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00595.html

Ok.

> Get nextstep platforms compiling:
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00831.html

Ok.

> Eliminate "traditional C rejects the 'u' suffix" warnings:
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01273.html

Ok.
 
> Fix traditional C "const" problem when building the g77 driver:
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01999.html

Ok.

> Fix macro redefinition warnings on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00107.html

Ok.

> Fix signed/unsigned warnings in definitions of ASM_OUTPUT_ASCII:
> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00110.html

I guess this is ok.  I'd prefer we made this a target hook
and eliminated duplicate implementations...


r~

Unreviewed patches

[Roger Sayle]

The following patches from last month are still awaiting approval.
The first one in particular fixes a high priority PR and a regression
from v3.0.x.

Resolve issues with builtin sqrt and __builtin_fsqrt.
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01328.html

Optimize builtin memset with length zero.
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01599.html

Pure and const attributes for builtins.
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01628.html

Preserve builtin attributes in C/C++.
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01845.html

Specify pure and const attributes using builtin-attrs.def.
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01723.html


Additionally, I'd also really appreciate it if the reviewer could
look into accepting the following two related patches.  I'm working
on improving GCC's builtin processing and keeping tracking of these
outstanding patches could complicate the review of future changes.
[For what its worth, they both look good to me.]

Kaveh Ghazi's patch for builtin unlocked stdio.
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01886.html

Tom Tromey's patch for builtins in the Java front-end.
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00033.html


Many thanks in advance,

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-438-3470

Unreviewed patches

[Jakub Jelinek]

http://gcc.gnu.org/ml/gcc-patches/2001-11/msg02089.html
        - In C lay out array declarations of incomplete structures once
          they the structure type is completed
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01280.html
        - EH ICE due to instantiation - only testcase in the patch,
          the suggested fix is to revert
          http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01278.html
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00752.html
        - comment typo
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
        - fix endless loop with bogus C array initializer
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
        - fix ICE handling anonymous union on Alpha/Sparc/...
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
        - fix store motion (although Dan Berlin claims
          store motion should be disabled altogether ATM,
          IMHO this patch should be applied nevertheless)
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01547.html
        - testcase where I'd appreciate note whether the
          testcase is valid or not

	Jakub

Re: Unreviewed patches

[Gerald Pfeifer]

On Mon, 3 Dec 2001, Jakub Jelinek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00752.html
>         - comment typo

I'm not a native speaker either ;-), but this patch definitely
is correct (so you can install it under the obvious rule).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Unreviewed patches

[Kaveh R. Ghazi]

I would appreciate it greatly if someone would review the following
patches.

		Thanks,
		--Kaveh

The non-cpp portions of this patch to utilize hex_p & hex_value in
gcc.  (The cpp portions already were reviewed.):
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00595.html

Get nextstep platforms compiling:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00831.html

Eliminate "traditional C rejects the 'u' suffix" warnings:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01273.html

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Unreviewed patches

[Kaveh R. Ghazi]

I would appreciate it greatly if someone would review the following
patches.

		Thanks,
		--Kaveh

The non-cpp portions of this patch to utilize hex_p & hex_value in
gcc.  (The cpp portions already were reviewed.):
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00595.html

Get nextstep platforms compiling:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00831.html

Eliminate "traditional C rejects the 'u' suffix" warnings:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01273.html

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Unreviewed patches

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > > Get x86-dgux to compile (only posted yesterday, but it supercedes a
 > > much older patch):
 > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00029.html
 > 
 > The whole output_options thing is redundant with print_switch_values
 > from toplev.c.  The only thing that looks relevant anymore is
 > 
 >   output_file_directive (file, main_input_filename);
 >   fprintf (file, "\t.version\t\"01.01\"\n");                    \
 >   /* Switch to the data section so that the coffsem symbol
 >      isn't in the text section.  */
 >   data_section ();
 > 
 > which can just as well be moved directly into the ASM_FILE_START
 > macro and avoid the extra .c file entirely.
 > r~


Tested by cross-compiling cc1 to i386-dg-dgux.  Ok?




2001-11-09  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* config.gcc (i[34567]86-dg-dgux*): Don't set `out_file'.

	* i386/dgux.h (ASM_FILE_START): Set to the meaningful portions
	of dgux.c:output_file_start().

	* i386/dgux.c: Delete file.

diff -rup orig/egcs-CVS20011109/gcc/config.gcc egcs-CVS20011109/gcc/config.gcc
--- orig/egcs-CVS20011109/gcc/config.gcc	Fri Nov  9 18:14:12 2001
+++ egcs-CVS20011109/gcc/config.gcc	Fri Nov  9 18:29:51 2001
@@ -1442,7 +1442,6 @@ i[34567]86-*-interix*)
 	;;
 i[34567]86-dg-dgux*)
 	xm_defines=POSIX
-	out_file=i386/dgux.c
 	tm_file="${tm_file} i386/att.h elfos.h svr4.h i386/sysv4.h i386/dgux.h"
 	tmake_file=i386/t-dgux
 	xmake_file=i386/x-dgux
diff -rup orig/egcs-CVS20011109/gcc/config/i386/dgux.h egcs-CVS20011109/gcc/config/i386/dgux.h
--- orig/egcs-CVS20011109/gcc/config/i386/dgux.h	Fri Oct 19 19:17:59 2001
+++ egcs-CVS20011109/gcc/config/i386/dgux.h	Fri Nov  9 18:33:23 2001
@@ -81,11 +81,15 @@ Boston, MA 02111-1307, USA.  */
 #undef  PREFERRED_DEBUGGING_TYPE
 #define PREFERRED_DEBUGGING_TYPE DWARF_DEBUG
 
-/* Override svr[34].h.  */
+/* Override svr[34].h.  Switch to the data section so that the coffsem
+   symbol isn't in the text section.  */
 #undef	ASM_FILE_START
 #define ASM_FILE_START(FILE) \
-  output_file_start (FILE, f_options, ARRAY_SIZE (f_options), \
-		     W_options, ARRAY_SIZE (W_options))
+  do { \
+    output_file_directive (FILE, main_input_filename); \
+    fprintf (FILE, "\t.version\t\"01.01\"\n"); \
+    data_section (); \
+  } while (0)
 
 /* ix86 abi specified type for wchar_t */
 

Re: Unreviewed patches

[Richard Henderson]

On Fri, Nov 09, 2001 at 07:02:39PM -0500, Kaveh R. Ghazi wrote:
> 	* config.gcc (i[34567]86-dg-dgux*): Don't set `out_file'.
> 	* i386/dgux.h (ASM_FILE_START): Set to the meaningful portions
> 	of dgux.c:output_file_start().
> 	* i386/dgux.c: Delete file.

Ok.


r~

Re: Unreviewed patches

[Richard Henderson]

On Fri, Nov 09, 2001 at 07:02:39PM -0500, Kaveh R. Ghazi wrote:
> 	* config.gcc (i[34567]86-dg-dgux*): Don't set `out_file'.
> 	* i386/dgux.h (ASM_FILE_START): Set to the meaningful portions
> 	of dgux.c:output_file_start().
> 	* i386/dgux.c: Delete file.

Ok.


r~

Re: Unreviewed patches

[Richard Henderson]

On Fri, Nov 09, 2001 at 07:02:39PM -0500, Kaveh R. Ghazi wrote:
> 	* config.gcc (i[34567]86-dg-dgux*): Don't set `out_file'.
> 	* i386/dgux.h (ASM_FILE_START): Set to the meaningful portions
> 	of dgux.c:output_file_start().
> 	* i386/dgux.c: Delete file.

Ok.


r~

Re: Unreviewed patches

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > > Get x86-dgux to compile (only posted yesterday, but it supercedes a
 > > much older patch):
 > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00029.html
 > 
 > The whole output_options thing is redundant with print_switch_values
 > from toplev.c.  The only thing that looks relevant anymore is
 > 
 >   output_file_directive (file, main_input_filename);
 >   fprintf (file, "\t.version\t\"01.01\"\n");                    \
 >   /* Switch to the data section so that the coffsem symbol
 >      isn't in the text section.  */
 >   data_section ();
 > 
 > which can just as well be moved directly into the ASM_FILE_START
 > macro and avoid the extra .c file entirely.
 > r~


Tested by cross-compiling cc1 to i386-dg-dgux.  Ok?




2001-11-09  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* config.gcc (i[34567]86-dg-dgux*): Don't set `out_file'.

	* i386/dgux.h (ASM_FILE_START): Set to the meaningful portions
	of dgux.c:output_file_start().

	* i386/dgux.c: Delete file.

diff -rup orig/egcs-CVS20011109/gcc/config.gcc egcs-CVS20011109/gcc/config.gcc
--- orig/egcs-CVS20011109/gcc/config.gcc	Fri Nov  9 18:14:12 2001
+++ egcs-CVS20011109/gcc/config.gcc	Fri Nov  9 18:29:51 2001
@@ -1442,7 +1442,6 @@ i[34567]86-*-interix*)
 	;;
 i[34567]86-dg-dgux*)
 	xm_defines=POSIX
-	out_file=i386/dgux.c
 	tm_file="${tm_file} i386/att.h elfos.h svr4.h i386/sysv4.h i386/dgux.h"
 	tmake_file=i386/t-dgux
 	xmake_file=i386/x-dgux
diff -rup orig/egcs-CVS20011109/gcc/config/i386/dgux.h egcs-CVS20011109/gcc/config/i386/dgux.h
--- orig/egcs-CVS20011109/gcc/config/i386/dgux.h	Fri Oct 19 19:17:59 2001
+++ egcs-CVS20011109/gcc/config/i386/dgux.h	Fri Nov  9 18:33:23 2001
@@ -81,11 +81,15 @@ Boston, MA 02111-1307, USA.  */
 #undef  PREFERRED_DEBUGGING_TYPE
 #define PREFERRED_DEBUGGING_TYPE DWARF_DEBUG
 
-/* Override svr[34].h.  */
+/* Override svr[34].h.  Switch to the data section so that the coffsem
+   symbol isn't in the text section.  */
 #undef	ASM_FILE_START
 #define ASM_FILE_START(FILE) \
-  output_file_start (FILE, f_options, ARRAY_SIZE (f_options), \
-		     W_options, ARRAY_SIZE (W_options))
+  do { \
+    output_file_directive (FILE, main_input_filename); \
+    fprintf (FILE, "\t.version\t\"01.01\"\n"); \
+    data_section (); \
+  } while (0)
 
 /* ix86 abi specified type for wchar_t */
 

Re: Unreviewed patches

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > > Get x86-dgux to compile (only posted yesterday, but it supercedes a
 > > much older patch):
 > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00029.html
 > 
 > The whole output_options thing is redundant with print_switch_values
 > from toplev.c.  The only thing that looks relevant anymore is
 > 
 >   output_file_directive (file, main_input_filename);
 >   fprintf (file, "\t.version\t\"01.01\"\n");                    \
 >   /* Switch to the data section so that the coffsem symbol
 >      isn't in the text section.  */
 >   data_section ();
 > 
 > which can just as well be moved directly into the ASM_FILE_START
 > macro and avoid the extra .c file entirely.
 > r~


Tested by cross-compiling cc1 to i386-dg-dgux.  Ok?




2001-11-09  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* config.gcc (i[34567]86-dg-dgux*): Don't set `out_file'.

	* i386/dgux.h (ASM_FILE_START): Set to the meaningful portions
	of dgux.c:output_file_start().

	* i386/dgux.c: Delete file.

diff -rup orig/egcs-CVS20011109/gcc/config.gcc egcs-CVS20011109/gcc/config.gcc
--- orig/egcs-CVS20011109/gcc/config.gcc	Fri Nov  9 18:14:12 2001
+++ egcs-CVS20011109/gcc/config.gcc	Fri Nov  9 18:29:51 2001
@@ -1442,7 +1442,6 @@ i[34567]86-*-interix*)
 	;;
 i[34567]86-dg-dgux*)
 	xm_defines=POSIX
-	out_file=i386/dgux.c
 	tm_file="${tm_file} i386/att.h elfos.h svr4.h i386/sysv4.h i386/dgux.h"
 	tmake_file=i386/t-dgux
 	xmake_file=i386/x-dgux
diff -rup orig/egcs-CVS20011109/gcc/config/i386/dgux.h egcs-CVS20011109/gcc/config/i386/dgux.h
--- orig/egcs-CVS20011109/gcc/config/i386/dgux.h	Fri Oct 19 19:17:59 2001
+++ egcs-CVS20011109/gcc/config/i386/dgux.h	Fri Nov  9 18:33:23 2001
@@ -81,11 +81,15 @@ Boston, MA 02111-1307, USA.  */
 #undef  PREFERRED_DEBUGGING_TYPE
 #define PREFERRED_DEBUGGING_TYPE DWARF_DEBUG
 
-/* Override svr[34].h.  */
+/* Override svr[34].h.  Switch to the data section so that the coffsem
+   symbol isn't in the text section.  */
 #undef	ASM_FILE_START
 #define ASM_FILE_START(FILE) \
-  output_file_start (FILE, f_options, ARRAY_SIZE (f_options), \
-		     W_options, ARRAY_SIZE (W_options))
+  do { \
+    output_file_directive (FILE, main_input_filename); \
+    fprintf (FILE, "\t.version\t\"01.01\"\n"); \
+    data_section (); \
+  } while (0)
 
 /* ix86 abi specified type for wchar_t */
 

Re: Unreviewed patches

[Richard Henderson]

On Fri, Nov 02, 2001 at 11:43:27AM -0500, Kaveh R. Ghazi wrote:
> Fix a warning from cp/class.c:
> http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01396.html

Ok.

> Fix warnings on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01066.html

Ok.

> Another set of warning fixes on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01188.html

Ok.

> Get hppa1.1-unknown-rtems to compile:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01509.html

Ok.

> Fix warnings from /intl directory:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01567.html

Ok.

> Get x86-dgux to compile (only posted yesterday, but it supercedes a
> much older patch):
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00029.html

The whole output_options thing is redundant with print_switch_values
from toplev.c.  The only thing that looks relevant anymore is

  output_file_directive (file, main_input_filename);
  fprintf (file, "\t.version\t\"01.01\"\n");                    \
  /* Switch to the data section so that the coffsem symbol
     isn't in the text section.  */
  data_section ();

which can just as well be moved directly into the ASM_FILE_START
macro and avoid the extra .c file entirely.


r~

Re: Unreviewed patches

[Richard Henderson]

On Fri, Nov 02, 2001 at 11:43:27AM -0500, Kaveh R. Ghazi wrote:
> Fix a warning from cp/class.c:
> http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01396.html

Ok.

> Fix warnings on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01066.html

Ok.

> Another set of warning fixes on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01188.html

Ok.

> Get hppa1.1-unknown-rtems to compile:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01509.html

Ok.

> Fix warnings from /intl directory:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01567.html

Ok.

> Get x86-dgux to compile (only posted yesterday, but it supercedes a
> much older patch):
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00029.html

The whole output_options thing is redundant with print_switch_values
from toplev.c.  The only thing that looks relevant anymore is

  output_file_directive (file, main_input_filename);
  fprintf (file, "\t.version\t\"01.01\"\n");                    \
  /* Switch to the data section so that the coffsem symbol
     isn't in the text section.  */
  data_section ();

which can just as well be moved directly into the ASM_FILE_START
macro and avoid the extra .c file entirely.


r~

Re: Unreviewed patches

[Richard Henderson]

On Fri, Nov 02, 2001 at 11:43:27AM -0500, Kaveh R. Ghazi wrote:
> Fix a warning from cp/class.c:
> http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01396.html

Ok.

> Fix warnings on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01066.html

Ok.

> Another set of warning fixes on various cross targets:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01188.html

Ok.

> Get hppa1.1-unknown-rtems to compile:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01509.html

Ok.

> Fix warnings from /intl directory:
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01567.html

Ok.

> Get x86-dgux to compile (only posted yesterday, but it supercedes a
> much older patch):
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00029.html

The whole output_options thing is redundant with print_switch_values
from toplev.c.  The only thing that looks relevant anymore is

  output_file_directive (file, main_input_filename);
  fprintf (file, "\t.version\t\"01.01\"\n");                    \
  /* Switch to the data section so that the coffsem symbol
     isn't in the text section.  */
  data_section ();

which can just as well be moved directly into the ASM_FILE_START
macro and avoid the extra .c file entirely.


r~

Unreviewed patches

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
	- fix endless loop with bogus C array initializer
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
	- fix ICE handling anonymous union on Alpha/Sparc/...
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
	- fix store motion (although Dan Berlin claims
	store motion should be disabled altogether ATM,
	IMHO this patch should be applied nevertheless)
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01547.html
	- testcase where I'd appreciate note whether the
	testcase is valid or not

	Jakub

Re: Unreviewed patches

[Daniel Berlin]

On Mon, 12 Nov 2001, Jakub Jelinek wrote:

> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
> 	- fix endless loop with bogus C array initializer
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
> 	- fix ICE handling anonymous union on Alpha/Sparc/...
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
> 	- fix store motion (although Dan Berlin claims
> 	store motion should be disabled altogether ATM,
> 	IMHO this patch should be applied nevertheless)

I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.

The list of problems with store motion, off the top of my head:
1. store_ops_ok returns the opposite value it should (IE 0 when should
be 1, 1 when  should be 0) for registers.
2. Constant calls are not handled properly.
3. memory that can alias anything is not handled properly (it doesn't
notice that stores that alias anything kill your current store, as well as
loads from memory that alias anything)
These are just the bugs off the top of my head, while trying to pay
attention in criminal law class.

--Dan

Re: Unreviewed patches

[Andreas Jaeger]

Daniel Berlin <dan@cgsoftware.com> writes:

> On Mon, 12 Nov 2001, Jakub Jelinek wrote:
>
>> Hi!
>>
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
>> 	- fix endless loop with bogus C array initializer
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
>> 	- fix ICE handling anonymous union on Alpha/Sparc/...
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
>> 	- fix store motion (although Dan Berlin claims
>> 	store motion should be disabled altogether ATM,
>> 	IMHO this patch should be applied nevertheless)
>
> I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.
>
> The list of problems with store motion, off the top of my head:
> 1. store_ops_ok returns the opposite value it should (IE 0 when should
> be 1, 1 when  should be 0) for registers.
> 2. Constant calls are not handled properly.
> 3. memory that can alias anything is not handled properly (it doesn't
> notice that stores that alias anything kill your current store, as well as
> loads from memory that alias anything)
> These are just the bugs off the top of my head, while trying to pay
> attention in criminal law class.

Since the issues with store-motion come up every other month: Is it
appropriate to create a bug report mentioning this article?  This way
the problem might not get lost... (I prefer actually a fix;-)

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Unreviewed patches

[Andreas Jaeger]

Daniel Berlin <dan@cgsoftware.com> writes:

> On Mon, 12 Nov 2001, Jakub Jelinek wrote:
>
>> Hi!
>>
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
>> 	- fix endless loop with bogus C array initializer
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
>> 	- fix ICE handling anonymous union on Alpha/Sparc/...
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
>> 	- fix store motion (although Dan Berlin claims
>> 	store motion should be disabled altogether ATM,
>> 	IMHO this patch should be applied nevertheless)
>
> I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.
>
> The list of problems with store motion, off the top of my head:
> 1. store_ops_ok returns the opposite value it should (IE 0 when should
> be 1, 1 when  should be 0) for registers.
> 2. Constant calls are not handled properly.
> 3. memory that can alias anything is not handled properly (it doesn't
> notice that stores that alias anything kill your current store, as well as
> loads from memory that alias anything)
> These are just the bugs off the top of my head, while trying to pay
> attention in criminal law class.

Since the issues with store-motion come up every other month: Is it
appropriate to create a bug report mentioning this article?  This way
the problem might not get lost... (I prefer actually a fix;-)

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Unreviewed patches

[Andreas Jaeger]

Daniel Berlin <dan@cgsoftware.com> writes:

> On Mon, 12 Nov 2001, Jakub Jelinek wrote:
>
>> Hi!
>>
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
>> 	- fix endless loop with bogus C array initializer
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
>> 	- fix ICE handling anonymous union on Alpha/Sparc/...
>> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
>> 	- fix store motion (although Dan Berlin claims
>> 	store motion should be disabled altogether ATM,
>> 	IMHO this patch should be applied nevertheless)
>
> I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.
>
> The list of problems with store motion, off the top of my head:
> 1. store_ops_ok returns the opposite value it should (IE 0 when should
> be 1, 1 when  should be 0) for registers.
> 2. Constant calls are not handled properly.
> 3. memory that can alias anything is not handled properly (it doesn't
> notice that stores that alias anything kill your current store, as well as
> loads from memory that alias anything)
> These are just the bugs off the top of my head, while trying to pay
> attention in criminal law class.

Since the issues with store-motion come up every other month: Is it
appropriate to create a bug report mentioning this article?  This way
the problem might not get lost... (I prefer actually a fix;-)

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Unreviewed patches

[Daniel Berlin]

On Mon, 12 Nov 2001, Jakub Jelinek wrote:

> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
> 	- fix endless loop with bogus C array initializer
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
> 	- fix ICE handling anonymous union on Alpha/Sparc/...
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
> 	- fix store motion (although Dan Berlin claims
> 	store motion should be disabled altogether ATM,
> 	IMHO this patch should be applied nevertheless)

I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.

The list of problems with store motion, off the top of my head:
1. store_ops_ok returns the opposite value it should (IE 0 when should
be 1, 1 when  should be 0) for registers.
2. Constant calls are not handled properly.
3. memory that can alias anything is not handled properly (it doesn't
notice that stores that alias anything kill your current store, as well as
loads from memory that alias anything)
These are just the bugs off the top of my head, while trying to pay
attention in criminal law class.

--Dan

Re: Unreviewed patches

[Daniel Berlin]

On Mon, 12 Nov 2001, Jakub Jelinek wrote:

> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
> 	- fix endless loop with bogus C array initializer
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
> 	- fix ICE handling anonymous union on Alpha/Sparc/...
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
> 	- fix store motion (although Dan Berlin claims
> 	store motion should be disabled altogether ATM,
> 	IMHO this patch should be applied nevertheless)

I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.

The list of problems with store motion, off the top of my head:
1. store_ops_ok returns the opposite value it should (IE 0 when should
be 1, 1 when  should be 0) for registers.
2. Constant calls are not handled properly.
3. memory that can alias anything is not handled properly (it doesn't
notice that stores that alias anything kill your current store, as well as
loads from memory that alias anything)
These are just the bugs off the top of my head, while trying to pay
attention in criminal law class.

--Dan

Re: Unreviewed patches

[Daniel Berlin]

On Mon, 12 Nov 2001, Jakub Jelinek wrote:

> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
> 	- fix endless loop with bogus C array initializer
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
> 	- fix ICE handling anonymous union on Alpha/Sparc/...
> http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
> 	- fix store motion (although Dan Berlin claims
> 	store motion should be disabled altogether ATM,
> 	IMHO this patch should be applied nevertheless)

I agree, BTW, as it's *part* of a correct fix, but nowhere near complete.

The list of problems with store motion, off the top of my head:
1. store_ops_ok returns the opposite value it should (IE 0 when should
be 1, 1 when  should be 0) for registers.
2. Constant calls are not handled properly.
3. memory that can alias anything is not handled properly (it doesn't
notice that stores that alias anything kill your current store, as well as
loads from memory that alias anything)
These are just the bugs off the top of my head, while trying to pay
attention in criminal law class.

--Dan

Unreviewed patches

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
	- fix endless loop with bogus C array initializer
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
	- fix ICE handling anonymous union on Alpha/Sparc/...
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
	- fix store motion (although Dan Berlin claims
	store motion should be disabled altogether ATM,
	IMHO this patch should be applied nevertheless)
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01547.html
	- testcase where I'd appreciate note whether the
	testcase is valid or not

	Jakub

Unreviewed patches

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
	- fix endless loop with bogus C array initializer
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
	- fix ICE handling anonymous union on Alpha/Sparc/...
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
	- fix store motion (although Dan Berlin claims
	store motion should be disabled altogether ATM,
	IMHO this patch should be applied nevertheless)
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01547.html
	- testcase where I'd appreciate note whether the
	testcase is valid or not

	Jakub

Unreviewed patches

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
	- fix endless loop with bogus C array initializer
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
	- fix ICE handling anonymous union on Alpha/Sparc/...
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
	- fix store motion (although Dan Berlin claims
	store motion should be disabled altogether ATM,
	IMHO this patch should be applied nevertheless)
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01547.html
	- testcase where I'd appreciate note whether the
	testcase is valid or not

	Jakub

Unreviewed patches

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01300.html
	- fix endless loop with bogus C array initializer
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00898.html
	- fix ICE handling anonymous union on Alpha/Sparc/...
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01218.html
	- fix store motion (although Dan Berlin claims
	store motion should be disabled altogether ATM,
	IMHO this patch should be applied nevertheless)
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01547.html
	- testcase where I'd appreciate note whether the
	testcase is valid or not

	Jakub

Unreviewed patches

[Kaveh R. Ghazi]

The following patches still await a review.

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01396.html

For this one, two of the three warnings were already fixed by someone
else, just the minor combine.c change is still relevant. :-)
http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01784.html

Also:
http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00016.html

and:
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00338.html

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Unreviewed patches

[Daniel Berlin]

I have some followup patches to these unreviewed patches that use
ebitmaps in other places, and the iterative dataflow functions in
other places, in order to simplify and speed up the code.

All of the patches listed were bootstrapped on x86 and powerpc, in
addition, all but the last were, i believe (please correct me if i'm
wrong michael) bootstrapped on x86, after being applied to the
new-regalloc branch, by Michael Matz.

There have also been recently introduced things that would benefit
from the alloc-pool, such as the changes Jan just made that end up
creating a free list of edges, and obstack_alloc'ing them, in order to
increase efficiency.

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01686.html
http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01699.html
http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01722.html

If someone wants to make a go at replacing regsets with ebitmaps, feel
free. Since i'm busy with law school, i've tried to cut myself down to
80 projects instead of a billion, and since tree serialization/PCH is more
important than regset replacement, ....

--Dan
-- 
"I want to get a tatoo of myself on my entire body, only 2"
taller.
"-Steven Wright

Unreviewed patches

[Roman Lechtchinsky]

The following patches have been submitted quite some time ago and haven't
been reviewed:

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01167.html
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00013.html

They are necessary for the Cray T3E port (which I'm going to resubmit next
week). I have bootstrapped and regtested them on sparc-sun-solaris2.8 to
make sure they still don't break anything.

Bye

Roman

Re: Unreviewed patches

[Richard Henderson]

On Fri, Sep 07, 2001 at 05:33:18PM +0200, Roman Lechtchinsky wrote:
> http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00013.html

Applied.


r~

Re: Unreviewed patches

[Richard Henderson]

On Fri, Sep 07, 2001 at 05:33:18PM +0200, Roman Lechtchinsky wrote:
> http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01167.html

Ok.


r~

Unreviewed patches

[Roman Zippel]

Hi,

The following patches are still unreviewed:

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01589.html
fixes different code depending on '-g'

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01184.html
fixes an access to freed memory

Patches are bootstrapped and regression tested on i686-linux and
m68k-linux.

bye, Roman

Unreviewed patches

[Kazu Hirata]

Hi,

These are all h8300-related patches.  I would greatly appreciate if
someone could review these patches.

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00897.html
  Optimize logical operations by specifying tighter length and cc0.

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01530.html
  Fix float-unsigned long conversion.

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00573.html
  Clean up shift insn generation.

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00720.html
  Don't push the stack pointer.

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00568.html
  Do not use -fpic on gcc.c-torture/compile/981006-1.c.

Thanks,

Kazu Hirata

Unreviewed patches

[Roman Zippel]

Hi,

The following patches are still unreviewed:

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01266.html
fixes miscompile of __udivdi3 (libgcc2.c) on linux-m68k

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01397.html
fixes gcc.c-torture/execute/930126-1.c on m68k

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01589.html
fixes different code depending on '-g'

I verified that all described bugs still exists in the branch and trunk.
Patches are tested on linux-i686 and linux-m68k.
The second patch does only apply to the branch and I forgot to mention
that '-O3' is needed to trigger the bug.

bye, Roman

Unreviewed patches

[Daniel Berlin]

DWARF 2.1 namespace support:
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00291.html

Small modification of that patch
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00303.html

--Dan
-- 
"When I was little, my grandfather used to make me stand in a
closet for five minutes without moving.  He said it was elevator
practice.
"-Steven Wright

Unreviewed patches

[Toshi Morita]

My unreviewed patches:

Fix obviously broken code in gcc 3.0 branch:

http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01516.html

force_to_mode bugfix:

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01267.html

Toshi

unreviewed patches

[DJ Delorie]

12 Jun 2001 - http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00858.html
	simplify-rtx.c (simplify_subreg): Always simplify concats.
	(I've been running/testing with this internally since then)

11 Jun 2001 - http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00736.html
	emit-rtl.c (operand_subword_force): Prevent recursion.
	(we may no longer need this)

Unreviewed patches

[Daniel Berlin]

.debug_macinfo support for dwarf2:
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01679.html

(It would be nice if Neil or Zack could also take a look at this,
since I raninto some problems with the line number variable not being
correct, unless i explicitly reget the line number. I suspect this is
affect debug info in other cases as well).

Fill in the ssa_uses array:
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00416.html

-- 
"One time a cop pulled me over for running a stop sign.  He said,
"Didn't you see the stop sign?"  I said, "Yeah, but I don't
believe everything I read."
"-Steven Wright

Re: Unreviewed patches

[Neil Booth]

Daniel Berlin wrote:-

> .debug_macinfo support for dwarf2:
> http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01679.html
> 
> (It would be nice if Neil or Zack could also take a look at this,
> since I raninto some problems with the line number variable not being
> correct, unless i explicitly reget the line number. I suspect this is
> affect debug info in other cases as well).

Hmm.  It appears that the buffer being passed to debug_define is not
what the comment above it claims it should be, and that you've added
an extra parameter for that reason.

In "#define macname foo" the comment claims it should be passed
"macname foo", but we were passing just "foo".

I think you should change cpp_macro_definition() to prefix the macro
name, i.e. to pass "foo bar".  You'd need to update cppmain.c for
that, which is pretty agnostic either way.  It'd clean up your
interfaces (I can't believe that dwarfout{,2}_define() both work after
your changes, since the former doesn't have the macro name) and remove
your temporary buffer allocation and copying in dwarf2out_define to
concatenate the two.

Neil.

Re: Unreviewed patches

[Neil Booth]

neil wrote:-

> name, i.e. to pass "foo bar".  You'd need to update cppmain.c for
		     ^^^^^^^^^
                     "macname foo"

That's what comes from editing you mail after you've written it.

Neil.

Re: Unreviewed patches

[Neil Booth]

Daniel Berlin wrote:-

> (It would be nice if Neil or Zack could also take a look at this,
> since I raninto some problems with the line number variable not being
> correct, unless i explicitly reget the line number. I suspect this is
> affect debug info in other cases as well).

b.t.w. your non-use of lineno is correct; the old code was buggy.

Neil.

Unreviewed patches

[Kazu Hirata]

Hi,

Could someone review these patches?

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00365.html
  Duplicate entries break float<->long conversion in h8300 port.

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01051.html
  Fixes a comment typo.  Looks almost obvious, but I am not familiar
  with expr.c.

Thanks,

kazu Hirata

unreviewed patches

[DJ Delorie]

http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01713.html

	This is a new C++ testcase that demonstrates a regression
	since 2.95.*; the C++ people need to verify its validity and
	approve it's inclusion in the testsuite.

http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01388.html

	This is an RFC for handling .exe extensions better.  It's
	being backported to the 2.95 branch, but I haven't gotten
	enough feedback and/or approval to apply it to the head or to
	3.0.

http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01743.html

	This is a bug in global.c that shows up testing m68k.

Re: Unreviewed patches

[Benjamin Kosnik]

> Re: 3.0 20010305 (prerelease) gen-num-limits.cc compile failure on
> alpha-dec-osf4.0e
>
>        http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00281.html
>
> While the inclhack.def fix to disable a bad fixinclude change on Tru64
> UNIX has been installed, the initial port of libstdc++ V3 to that OS
> hasn't been commented on yet.

...because you don't really include it in the patch. There's nothing
in the os/tru64 folder.

please re-submit this patch, including all files.

-benjamin

Re: Unreviewed patches

[Rainer Orth]

Benjamin Kosnik <bkoz@redhat.com> writes:

> > Re: 3.0 20010305 (prerelease) gen-num-limits.cc compile failure on
> > alpha-dec-osf4.0e
> >
> >        http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00281.html
> >
> > While the inclhack.def fix to disable a bad fixinclude change on Tru64
> > UNIX has been installed, the initial port of libstdc++ V3 to that OS
> > hasn't been commented on yet.
> 
> ...because you don't really include it in the patch. There's nothing
> in the os/tru64 folder.

sure I did.  I've just re-checked the archived submission above, and
there's a separate osf.tar.gz attached, containing the config/os/osf
subdirectory mentioned in the configure.target patch.  I've used an osf
subdirectory to match the configure triplet alpha-dec-osf5.1.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Unreviewed patches

[Rainer Orth]

The following patches have not been reviewed for about a month:

[Tru64 UNIX V5.1] Use old assembler to allow bootstrapping

	http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01448.html

This is required to bootstrap on Tru64 UNIX V5.1.

[Tru64 UNIX V5.1] gcc testsuite fixes

	http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01715.html

Consensus seems to have been reached that this is the right way to fix the
problem, but nobody acked it.

[Solaris 8] libobjc and objc test patches

	http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00125.html

These patches are required to successfully link and test Objective C
programs on Solaris.

Re: cpplib: Dump __GXX_WEAK__ and __STDC__ with -dM

	http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00301.html

This was the final patch to disable fixing __STDC__==0 tests on systems
that define STDC_0_IN_SYSTEM_HEADERS, though no full consensus seems to
have been reached not to completely drop the latter.

Re: 3.0 20010305 (prerelease) gen-num-limits.cc compile failure on alpha-dec-osf4.0e

	http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00281.html

While the inclhack.def fix to disable a bad fixinclude change on Tru64 UNIX
has been installed, the initial port of libstdc++ V3 to that OS hasn't been
commented on yet.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: Unreviewed patches

[Ovidiu Predescu]

On Mon, 2 Apr 2001 22:40:02 +0200 (MEST), Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:

> The following patches have not been reviewed for about a month:
> 
> [...]
> 
> [Solaris 8] libobjc and objc test patches
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00125.html
> 
> These patches are required to successfully link and test Objective C
> programs on Solaris.

The patches look OK. However can you explain why is this needed?

Index: gcc/objc/objc-act.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/objc/objc-act.c,v
retrieving revision 1.66.2.1
diff -u -p -r1.66.2.1 objc-act.c
--- objc-act.c  2001/02/16 09:19:08     1.66.2.1
+++ objc-act.c  2001/03/02 23:08:30
@@ -8237,7 +8237,9 @@ finish_objc ()
 
   for (chain = cls_ref_chain; chain; chain = TREE_CHAIN (chain))
     {
+#if 0
       handle_class_ref (chain);
+#endif
       if (TREE_PURPOSE (chain))
        generate_classref_translation_entry (chain);
     }


Thanks,
Ovidiu

Re: Unreviewed patches

[Ovidiu Predescu]

Oops, sorry, I read the message you point to, looked at the source
again, and it looks like the patch is correct.

Thanks,
Ovidiu

On Mon, 02 Apr 2001 14:26:08 -0700, Ovidiu Predescu <ovidiu@cup.hp.com> wrote:

> On Mon, 2 Apr 2001 22:40:02 +0200 (MEST), Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:
> 
> > The following patches have not been reviewed for about a month:
> > 
> > [...]
> > 
> > [Solaris 8] libobjc and objc test patches
> > 
> > 	http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00125.html
> > 
> > These patches are required to successfully link and test Objective C
> > programs on Solaris.
> 
> The patches look OK. However can you explain why is this needed?
> 
> Index: gcc/objc/objc-act.c
> ===================================================================
> RCS file: /cvs/gcc/egcs/gcc/objc/objc-act.c,v
> retrieving revision 1.66.2.1
> diff -u -p -r1.66.2.1 objc-act.c
> --- objc-act.c  2001/02/16 09:19:08     1.66.2.1
> +++ objc-act.c  2001/03/02 23:08:30
> @@ -8237,7 +8237,9 @@ finish_objc ()
>  
>    for (chain = cls_ref_chain; chain; chain = TREE_CHAIN (chain))
>      {
> +#if 0
>        handle_class_ref (chain);
> +#endif
>        if (TREE_PURPOSE (chain))
>         generate_classref_translation_entry (chain);
>      }
> 
> 
> Thanks,
> Ovidiu
> 

Re: Unreviewed patches

[Rainer Orth]

Ovidiu,

> Oops, sorry, I read the message you point to, looked at the source
> again, and it looks like the patch is correct.

it certainly worked for me on Solaris 8 when I last bootstrapped, and
didn't do any harm on Tru64 UNIX V4.0F or V5.1 either.  Unfortunately, last
night's bootstrap on Solaris 8 fails to execute most Objective C tests with
the following error:

	objc runtime: cannot find class Object

I haven't yet investigated if this is related to this patch.

Besides, there's a report by Nicola Pero

	http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00199.html

that the patch breaks the bycopy-3 test on i686-pc-gnu-linux.  I've no way
to try this myself, but probably someone who knows both Objective C and the
details of PIC code generation ought to look at the problem before applying
this part of my patch.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: Unreviewed patches

[Stan Shebs]

Rainer Orth wrote:
> 
> [Solaris 8] libobjc and objc test patches
> 
>         http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00125.html
> 
> These patches are required to successfully link and test Objective C
> programs on Solaris.

In objc-act.c, you've commented out the only call to handle_class_ref,
so in theory the definition could be removed also, *but* I'm pretty sure
OS X needs this.  However, Apple's version of this function is mostly
rewritten, and I've haven't studied it enough to know what should be
generic and what should be controlled by flag_next_runtime.  So the
#if 0 is fine as a bandaid for now, but please don't remove the function
yet.

Stan

Re: Unreviewed patches

[Richard Henderson]

On Mon, Apr 02, 2001 at 10:40:02PM +0200, Rainer Orth wrote:
> [Tru64 UNIX V5.1] Use old assembler to allow bootstrapping
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01448.html

This probably isn't the best of ideas, using the old assembler.
I understand that one of my co-workers discovered that the
assembler was, for some reason, running the output through ld.
Try adding "-c" instead and see if that works for you.

> [Tru64 UNIX V5.1] gcc testsuite fixes
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01715.html

Applied.


r~

Re: Unreviewed patches

[Rainer Orth]

Richard Henderson writes:
> On Mon, Apr 02, 2001 at 10:40:02PM +0200, Rainer Orth wrote:
> > [Tru64 UNIX V5.1] Use old assembler to allow bootstrapping
> > 
> > 	http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01448.html
> 
> This probably isn't the best of ideas, using the old assembler.

True, especially since the -oldas option is (deliberately?) undocumented
and Compaq would like to get rid of the old assembler in the relatively
near future.  On the other hand, there's currently no viable alternative.

> I understand that one of my co-workers discovered that the
> assembler was, for some reason, running the output through ld.
> Try adding "-c" instead and see if that works for you.

This is not what I've found: I've managed to reduce the problem with the
new assembler (adu) to the following minimal testcase:

http://groups.google.com/groups?th=42335b97ee51a80e&rnum=4&seld=918991391&ic=1

I've learned from Compaq engineers that this is due to an optimization in
adu: it doesn't emit empty sections at all, thus loosing the $Ltext0 label
mips-tfile relied on.  Compaq has agreed that this optimization isn't
important and provided me with a fixed version of adu which doesn't do
this.  I'm currently testing it with considerable success, but there are
still problems to figure out before it's ready for prime time.  Besides, I
may not redistribute it, so there's the need for a workaround until this
assembler is a completely functional replacement for as -oldas and becomes
publicly available, which may take a while, give the usual speed of vendors
to integrate patches into their public patch kits.  So I suggest to
integrate the patch for now as is, to allow others to bootstrap on Tru64
5.1 from the CVS sources.  Once the remaining issues are dealt with and the
new adu becomes generally available, I will happily provide another patch
to get rid of the current hack and documentation how to obtain the fixed
assembler.

> > [Tru64 UNIX V5.1] gcc testsuite fixes
> > 
> > 	http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01715.html
> 
> Applied.

Thanks.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

gcc-3.0 branch digest_init

[Alan Modra]

digest_init was calling initializer_constant_valid_p with an expression
that violated icvp's assumption that VALUE has been folded as much as
possible.

testcase:

$ cat consinit.i
extern void _text;
static unsigned long x = (unsigned long) &_text - 0x10000000L - 1;

$ gcc_new/gcc/xgcc -v -S consinit.i
[snip]
GNU C version 3.0 20010315 (prerelease) (hppa-linux)
        compiled by GNU C version 2.95.2 19991024 (release).
consinit.i:2: warning: initializer element is not computable at load time
consinit.i:2: Internal error: Segmentation fault

Possible fix:
	* c-typeck.c (digest_init): Fold init expression.

--- gcc/c-typeck.c~	Fri Mar 16 09:57:01 2001
+++ gcc/c-typeck.c	Sat Mar 17 16:44:32 2001
@@ -4662,7 +4662,7 @@ digest_init (type, init, require_constan
      int require_constant, constructor_constant;
 {
   enum tree_code code = TREE_CODE (type);
-  tree inside_init = init;
+  tree inside_init = fold (init);
 
   if (type == error_mark_node
       || init == error_mark_node

Alan Modra
-- 
Linuxcare

Unreviewed patches

[Alan Modra]

http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01412.html
http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01242.html

On the second one, can I at least commit the testcase in
gcc/testsuite/gcc.c-torture/compile so it doesn't get swept under the rug?

Alan Modra
-- 
Linuxcare

Re: Unreviewed patches

[Geoff Keating]

Alan Modra <alan@linuxcare.com.au> writes:

> http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01412.html

This is OK.

> http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01242.html
> 
> On the second one, can I at least commit the testcase in
> gcc/testsuite/gcc.c-torture/compile so it doesn't get swept under the rug?

This is also OK.  Please commit the testcase too.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Unreviewed patches

[Jakub Jelinek]

Hi!

Can someone please review following patches?

ia32 ICE testcase - not fixed yet
	http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00594.html

unrolling fix - fixes loop-7.c failures, verified in today's CVS
	http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01698.html

C designated initializers
	http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00402.html
(as this last one no longer applies cleanly, I've updated the patch
to current CVS, bootstrapped with it and regression tested on
i386-redhat-linux, the updated patch is below):

2001-01-12  Jakub Jelinek  <jakub@redhat.com>

	* c-typeck.c (store_init_value): Don't require constant initializer
	elements with -pedantic -std=c99.
	(digest_init): Change error about non-constant initializer elements
	into pedwarn.
	(constructor_range_end): Remove.
	(constructor_incremental, designator_depth,
	designator_errorneous): New variables.
	(struct constructor_stack): Remove range_end, add incremental.
	(struct constructor_range_stack, constructor_range_stack): New.
	(struct initializer_stack): Add constructor_range_stack.
	(finish_init): Set it.
	(start_init): Likewise.  require_constant_elements for non-static
	trees only if not flag_isoc99.
	(really_start_incremental_init): Remove constructor_range_end, add
	constructor_incremental.
	(pop_init_level): Likewise.
	(push_init_level): Likewise.  If implicit and the subobject had some
	value set already, preinitialize the level with it.
	Warn about missing braces only if not pushing due to designators.
	(set_designator, push_range_stack): New functions.
	(set_init_label): Use them.
	(set_init_index): Likewise.  Remove constructor_range_end.
	Error if designator index is outside of array bounds.
	(add_pending_init): Compare values of purpose index trees, not the
	trees themselves.  Allow overwriting of already initialized element.
	Issue a warning if it had side-effects.
	(set_nonincremental_init, set_nonincremental_init_from_string): New
	functions.
	(pending_init_member): Rename to...
	(find_init_member): ...this function.  Call set_nonincremental_init
	if necessary.  Compare values of purpose index trees, not the trees
	themselves.  Return the actual value, not just non-zero if something
	is found.
	(output_init_element): Remove checks for duplicates.
	If field has zero size, only check the initializer for correctness.
	Call set_nonincremental_init if necessary.  Push RECORD/ARRAY into AVL
	if constructor_incremental is zero.  Change error about initializers
	not computable at load time into pedwarn.
	(output_pending_init_elements): Compare bit positions, not
	FIELD_DECLs to take into account zero-sized fields.
	(process_init_element): Use constructor_range_stack to fill all
	ranges in the designator lists from current level up.
	* extend.texi: Update documentation for labeled elements.

	* gcc.c-torture/execute/20000801-3.x: Remove.
	* gcc.dg/c90-init-1.c: New test.
	* gcc.dg/c99-init-1.c: New test.
	* gcc.dg/c99-init-2.c: New test.
	* gcc.dg/gnu99-init-1.c: New test.

--- gcc/c-typeck.c.jj	Sun Jan  7 12:30:03 2001
+++ gcc/c-typeck.c	Fri Jan 12 18:42:37 2001
@@ -76,8 +76,12 @@ static void warning_init		PARAMS ((const
 static tree digest_init			PARAMS ((tree, tree, int, int));
 static void output_init_element		PARAMS ((tree, tree, tree, int));
 static void output_pending_init_elements PARAMS ((int));
+static int set_designator		PARAMS ((int));
+static void push_range_stack		PARAMS ((tree));
 static void add_pending_init		PARAMS ((tree, tree));
-static int pending_init_member		PARAMS ((tree));
+static void set_nonincremental_init	PARAMS ((void));
+static void set_nonincremental_init_from_string	PARAMS ((tree));
+static tree find_init_member		PARAMS ((tree));
 \f
 /* Do `exp = require_complete_type (exp);' to make sure exp
    does not have an incomplete type.  (That includes void types.)  */
@@ -4410,7 +4414,7 @@ store_init_value (decl, init)
   /* Digest the specified initializer into an expression.  */
 
   value = digest_init (type, init, TREE_STATIC (decl),
-		       TREE_STATIC (decl) || pedantic);
+		       TREE_STATIC (decl) || (pedantic && !flag_isoc99));
 
   /* Store the expression if valid; else report error.  */
 
@@ -4769,10 +4773,7 @@ digest_init (type, init, require_constan
 	}
       else if (require_constant
 	       && initializer_constant_valid_p (inside_init, TREE_TYPE (inside_init)) == 0)
-	{
-	  error_init ("initializer element is not computable at load time");
-	  inside_init = error_mark_node;
-	}
+	pedwarn ("initializer element is not computable at load time");
 
       return inside_init;
     }
@@ -4868,11 +4869,6 @@ static tree constructor_fields;
    at which to store the next element we get.  */
 static tree constructor_index;
 
-/* For an ARRAY_TYPE, this is the end index of the range
-   to initialize with the next element, or NULL in the ordinary case
-   where the element is used just once.  */
-static tree constructor_range_end;
-
 /* For an ARRAY_TYPE, this is the maximum index.  */
 static tree constructor_max_index;
 
@@ -4892,6 +4888,10 @@ static tree constructor_bit_index;
    most recent first).  */
 static tree constructor_elements;
 
+/* 1 if constructor should be incrementally stored into a constructor chain,
+   0 if all the elements should be kept in AVL tree.  */
+static int constructor_incremental;
+
 /* 1 if so far this constructor's elements are all compile-time constants.  */
 static int constructor_constant;
 
@@ -4943,6 +4943,12 @@ static const char *constructor_asmspec;
 /* Nonzero if this is an initializer for a top-level decl.  */
 static int constructor_top_level;
 
+/* Nesting depth of designator list.  */
+static int designator_depth;
+
+/* Nonzero if there were diagnosed errors in this designator list.  */
+static int designator_errorneous;
+
 \f
 /* This stack has a level for each implicit or explicit level of
    structuring in the initializer, including the outermost one.  It
@@ -4954,7 +4960,6 @@ struct constructor_stack
   tree type;
   tree fields;
   tree index;
-  tree range_end;
   tree max_index;
   tree unfilled_index;
   tree unfilled_fields;
@@ -4971,10 +4976,26 @@ struct constructor_stack
   char implicit;
   char erroneous;
   char outer;
+  char incremental;
 };
 
 struct constructor_stack *constructor_stack;
 
+/* This stack represents designators from some range designator up to
+   the last designator in the list.  */
+
+struct constructor_range_stack
+{
+  struct constructor_range_stack *next, *prev;
+  struct constructor_stack *stack;
+  tree range_start;
+  tree index;
+  tree range_end;
+  tree fields;
+};
+
+struct constructor_range_stack *constructor_range_stack;
+
 /* This stack records separate initializers that are nested.
    Nested initializers can't happen in ANSI C, but GNU C allows them
    in cases like { ... (struct foo) { ... } ... }.  */
@@ -4985,6 +5006,7 @@ struct initializer_stack
   tree decl;
   const char *asmspec;
   struct constructor_stack *constructor_stack;
+  struct constructor_range_stack *constructor_range_stack;
   tree elements;
   struct spelling *spelling;
   struct spelling *spelling_base;
@@ -5018,6 +5040,7 @@ start_init (decl, asmspec_tree, top_leve
   p->require_constant_value = require_constant_value;
   p->require_constant_elements = require_constant_elements;
   p->constructor_stack = constructor_stack;
+  p->constructor_range_stack = constructor_range_stack;
   p->elements = constructor_elements;
   p->spelling = spelling;
   p->spelling_base = spelling_base;
@@ -5036,7 +5059,7 @@ start_init (decl, asmspec_tree, top_leve
     {
       require_constant_value = TREE_STATIC (decl);
       require_constant_elements
-	= ((TREE_STATIC (decl) || pedantic)
+	= ((TREE_STATIC (decl) || (pedantic && !flag_isoc99))
 	   /* For a scalar, you can always use any value to initialize,
 	      even within braces.  */
 	   && (TREE_CODE (TREE_TYPE (decl)) == ARRAY_TYPE
@@ -5053,6 +5076,7 @@ start_init (decl, asmspec_tree, top_leve
     }
 
   constructor_stack = 0;
+  constructor_range_stack = 0;
 
   missing_braces_mentioned = 0;
 
@@ -5083,12 +5107,16 @@ finish_init ()
       free (q);
     }
 
+  if (constructor_range_stack)
+    abort ();
+
   /* Pop back to the data of the outer initializer (if any).  */
   constructor_decl = p->decl;
   constructor_asmspec = p->asmspec;
   require_constant_value = p->require_constant_value;
   require_constant_elements = p->require_constant_elements;
   constructor_stack = p->constructor_stack;
+  constructor_range_stack = p->constructor_range_stack;
   constructor_elements = p->elements;
   spelling = p->spelling;
   spelling_base = p->spelling_base;
@@ -5119,7 +5147,6 @@ really_start_incremental_init (type)
   p->type = constructor_type;
   p->fields = constructor_fields;
   p->index = constructor_index;
-  p->range_end = constructor_range_end;
   p->max_index = constructor_max_index;
   p->unfilled_index = constructor_unfilled_index;
   p->unfilled_fields = constructor_unfilled_fields;
@@ -5133,6 +5160,7 @@ really_start_incremental_init (type)
   p->replacement_value = 0;
   p->implicit = 0;
   p->outer = 0;
+  p->incremental = constructor_incremental;
   p->next = 0;
   constructor_stack = p;
 
@@ -5142,6 +5170,9 @@ really_start_incremental_init (type)
   constructor_elements = 0;
   constructor_pending_elts = 0;
   constructor_type = type;
+  constructor_incremental = 1;
+  designator_depth = 0;
+  designator_errorneous = 0;
 
   if (TREE_CODE (constructor_type) == RECORD_TYPE
       || TREE_CODE (constructor_type) == UNION_TYPE)
@@ -5157,7 +5188,6 @@ really_start_incremental_init (type)
     }
   else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
     {
-      constructor_range_end = 0;
       if (TYPE_DOMAIN (constructor_type))
 	{
 	  constructor_max_index
@@ -5187,13 +5217,14 @@ really_start_incremental_init (type)
 /* Push down into a subobject, for initialization.
    If this is for an explicit set of braces, IMPLICIT is 0.
    If it is because the next element belongs at a lower level,
-   IMPLICIT is 1.  */
+   IMPLICIT is 1 (or 2 if the push is because of designator list).  */
 
 void
 push_init_level (implicit)
      int implicit;
 {
   struct constructor_stack *p;
+  tree value = NULL_TREE;
 
   /* If we've exhausted any levels that didn't have braces,
      pop them now.  */
@@ -5210,11 +5241,22 @@ push_init_level (implicit)
 	break;
     }
 
+  /* Unless this is an explicit brace, we need to preserve previous
+     content if any.  */
+  if (implicit)
+    {
+      if ((TREE_CODE (constructor_type) == RECORD_TYPE
+	   || TREE_CODE (constructor_type) == UNION_TYPE)
+	  && constructor_fields)
+	value = find_init_member (constructor_fields);
+      else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
+	value = find_init_member (constructor_index);
+    }
+
   p = (struct constructor_stack *) xmalloc (sizeof (struct constructor_stack));
   p->type = constructor_type;
   p->fields = constructor_fields;
   p->index = constructor_index;
-  p->range_end = constructor_range_end;
   p->max_index = constructor_max_index;
   p->unfilled_index = constructor_unfilled_index;
   p->unfilled_fields = constructor_unfilled_fields;
@@ -5228,6 +5270,7 @@ push_init_level (implicit)
   p->replacement_value = 0;
   p->implicit = implicit;
   p->outer = 0;
+  p->incremental = constructor_incremental;
   p->next = constructor_stack;
   constructor_stack = p;
 
@@ -5235,7 +5278,13 @@ push_init_level (implicit)
   constructor_simple = 1;
   constructor_depth = SPELLING_DEPTH ();
   constructor_elements = 0;
+  constructor_incremental = 1;
   constructor_pending_elts = 0;
+  if (!implicit)
+    {
+      designator_depth = 0;
+      designator_errorneous = 0;
+    }
 
   /* Don't die if an entire brace-pair level is superfluous
      in the containing level.  */
@@ -5269,7 +5318,18 @@ push_init_level (implicit)
       return;
     }
 
-  if (implicit && warn_missing_braces && !missing_braces_mentioned)
+  if (value && TREE_CODE (value) == CONSTRUCTOR)
+    {
+      constructor_constant = TREE_CONSTANT (value);
+      constructor_simple = TREE_STATIC (value);
+      constructor_elements = TREE_OPERAND (value, 1);
+      if (constructor_elements
+	  && (TREE_CODE (constructor_type) == RECORD_TYPE
+	      || TREE_CODE (constructor_type) == ARRAY_TYPE))
+	set_nonincremental_init ();
+    }
+
+  if (implicit == 1 && warn_missing_braces && !missing_braces_mentioned)
     {
       missing_braces_mentioned = 1;
       warning_init ("missing braces around initializer");
@@ -5289,7 +5349,6 @@ push_init_level (implicit)
     }
   else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
     {
-      constructor_range_end = 0;
       if (TYPE_DOMAIN (constructor_type))
 	{
 	  constructor_max_index
@@ -5307,6 +5366,13 @@ push_init_level (implicit)
 	constructor_index = bitsize_zero_node;
 
       constructor_unfilled_index = constructor_index;
+      if (value && TREE_CODE (value) == STRING_CST)
+	{
+	  /* We need to split the char/wchar array into individual
+	     characters, so that we don't have to special case it
+	     everywhere.  */
+	  set_nonincremental_init_from_string (value);
+	}
     }
   else
     {
@@ -5363,7 +5429,7 @@ pop_init_level (implicit)
 	  else if (pedantic)
 	    pedwarn_init ("initialization of a flexible array member");
 
-          /* We have already issued an error message for the existance
+	  /* We have already issued an error message for the existance
 	     of a flexible array member not at the end of the structure.
 	     Discard the initializer so that we do not abort later.  */
 	  if (TREE_CHAIN (constructor_fields) != NULL_TREE)
@@ -5373,7 +5439,7 @@ pop_init_level (implicit)
 	{
 	  warning_init ("deprecated initialization of zero-length array");
 
-          /* We must be initializing the last member of a top-level struct.  */
+	  /* We must be initializing the last member of a top-level struct.  */
 	  if (TREE_CHAIN (constructor_fields) != NULL_TREE)
 	    {
 	      error_init ("initialization of zero-length array before end of structure");
@@ -5391,21 +5457,22 @@ pop_init_level (implicit)
       && TREE_CODE (constructor_type) == RECORD_TYPE
       && constructor_unfilled_fields)
     {
-      /* Do not warn for flexible array members or zero-length arrays.  */
-      while (constructor_unfilled_fields
-	     && (! DECL_SIZE (constructor_unfilled_fields)
-		 || integer_zerop (DECL_SIZE (constructor_unfilled_fields))))
-	constructor_unfilled_fields = TREE_CHAIN (constructor_unfilled_fields);
+	/* Do not warn for flexible array members or zero-length arrays.  */
+	while (constructor_unfilled_fields
+	       && (! DECL_SIZE (constructor_unfilled_fields)
+		   || integer_zerop (DECL_SIZE (constructor_unfilled_fields))))
+	  constructor_unfilled_fields = TREE_CHAIN (constructor_unfilled_fields);
 
-      if (constructor_unfilled_fields)
-	{
-	  push_member_name (constructor_unfilled_fields);
-	  warning_init ("missing initializer");
-	  RESTORE_SPELLING_DEPTH (constructor_depth);
-	}
+	if (constructor_unfilled_fields)
+	  {
+	    push_member_name (constructor_unfilled_fields);
+	    warning_init ("missing initializer");
+	    RESTORE_SPELLING_DEPTH (constructor_depth);
+	  }
     }
 
   /* Now output all pending elements.  */
+  constructor_incremental = 1;
   output_pending_init_elements (1);
 
   /* Pad out the end of the structure.  */
@@ -5423,7 +5490,8 @@ pop_init_level (implicit)
 	 the element, after verifying there is just one.  */
       if (constructor_elements == 0)
 	{
-	  error_init ("empty scalar initializer");
+	  if (!constructor_erroneous)
+	    error_init ("empty scalar initializer");
 	  constructor = error_mark_node;
 	}
       else if (TREE_CHAIN (constructor_elements) != 0)
@@ -5452,7 +5520,6 @@ pop_init_level (implicit)
   constructor_type = p->type;
   constructor_fields = p->fields;
   constructor_index = p->index;
-  constructor_range_end = p->range_end;
   constructor_max_index = p->max_index;
   constructor_unfilled_index = p->unfilled_index;
   constructor_unfilled_fields = p->unfilled_fields;
@@ -5461,6 +5528,7 @@ pop_init_level (implicit)
   constructor_constant = p->constant;
   constructor_simple = p->simple;
   constructor_erroneous = p->erroneous;
+  constructor_incremental = p->incremental;
   constructor_pending_elts = p->pending_elts;
   constructor_depth = p->depth;
   RESTORE_SPELLING_DEPTH (constructor_depth);
@@ -5477,6 +5545,97 @@ pop_init_level (implicit)
   return constructor;
 }
 
+/* Common handling for both array range and field name designators.
+   ARRAY argument is non-zero for array ranges.  Returns zero for success.  */
+
+static int
+set_designator (array)
+     int array;
+{
+  tree subtype;
+  enum tree_code subcode;
+
+  /* Don't die if an entire brace-pair level is superfluous
+     in the containing level.  */
+  if (constructor_type == 0)
+    return 1;
+
+  /* If there were errors in this designator list already, bail out silently.  */
+  if (designator_errorneous)
+    return 1;
+
+  if (!designator_depth)
+    {
+      if (constructor_range_stack)
+	abort ();
+
+      /* Designator list starts at the level of closest explicit
+	 braces.  */
+      while (constructor_stack->implicit)
+	process_init_element (pop_init_level (1));
+      return 0;
+    }
+
+  if (constructor_no_implicit)
+    {
+      error_init ("initialization designators may not nest");
+      return 1;
+    }
+
+  if (TREE_CODE (constructor_type) == RECORD_TYPE
+      || TREE_CODE (constructor_type) == UNION_TYPE)
+    {
+      subtype = TREE_TYPE (constructor_fields);
+      if (subtype != error_mark_node)
+	subtype = TYPE_MAIN_VARIANT (subtype);
+    }
+  else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
+    {
+      subtype = TYPE_MAIN_VARIANT (TREE_TYPE (constructor_type));
+    }
+  else
+    abort ();
+
+  subcode = TREE_CODE (subtype);
+  if (array && subcode != ARRAY_TYPE)
+    {
+      error_init ("array index in non-array initializer");
+      return 1;
+    }
+  else if (!array && subcode != RECORD_TYPE && subcode != UNION_TYPE)
+    {
+      error_init ("field name not in record or union initializer");
+      return 1;
+    }
+
+  push_init_level (2);
+  return 0;
+}
+
+/* If there are range designators in designator list, push a new designator
+   to constructor_range_stack.  RANGE_END is end of such stack range or
+   NULL_TREE if there is no range designator at this level.  */
+
+static void
+push_range_stack (range_end)
+     tree range_end;
+{
+  struct constructor_range_stack *p;
+
+  p = (struct constructor_range_stack *)
+      ggc_alloc (sizeof (struct constructor_range_stack));
+  p->prev = constructor_range_stack;
+  p->next = 0;
+  p->fields = constructor_fields;
+  p->range_start = constructor_index;
+  p->index = constructor_index;
+  p->stack = constructor_stack;
+  p->range_end = range_end;
+  if (constructor_range_stack)
+    constructor_range_stack->next = p;
+  constructor_range_stack = p;
+}
+
 /* Within an array initializer, specify the next index to be initialized.
    FIRST is that index.  If LAST is nonzero, then initialize a range
    of indices, running from FIRST through LAST.  */
@@ -5485,6 +5644,11 @@ void
 set_init_index (first, last)
      tree first, last;
 {
+  if (set_designator (1))
+    return;
+
+  designator_errorneous = 1;
+
   while ((TREE_CODE (first) == NOP_EXPR
 	  || TREE_CODE (first) == CONVERT_EXPR
 	  || TREE_CODE (first) == NON_LVALUE_EXPR)
@@ -5504,18 +5668,34 @@ set_init_index (first, last)
     error_init ("nonconstant array index in initializer");
   else if (last != 0 && TREE_CODE (last) != INTEGER_CST)
     error_init ("nonconstant array index in initializer");
-  else if (! constructor_unfilled_index)
+  else if (TREE_CODE (constructor_type) != ARRAY_TYPE)
     error_init ("array index in non-array initializer");
-  else if (tree_int_cst_lt (first, constructor_unfilled_index))
-    error_init ("duplicate array index in initializer");
+  else if (constructor_max_index
+	   && tree_int_cst_lt (constructor_max_index, first))
+    error_init ("array index in initializer exceeds array bounds");
   else
     {
       constructor_index = convert (bitsizetype, first);
 
       if (last != 0 && tree_int_cst_lt (last, first))
-	error_init ("empty index range in initializer");
-      else
-	constructor_range_end = last ? convert (bitsizetype, last) : 0;
+	{
+	  error_init ("empty index range in initializer");
+	  last = 0;
+	}
+      else if (last)
+	{
+	  last = convert (bitsizetype, last);
+	  if (constructor_max_index != 0
+	      && tree_int_cst_lt (constructor_max_index, last))
+	    {
+	      error_init ("array index range in initializer exceeds array bounds");
+	      last = 0;
+	    }
+	}
+      designator_depth++;
+      designator_errorneous = 0;
+      if (constructor_range_stack || last)
+	push_range_stack (last);
     }
 }
 
@@ -5526,18 +5706,22 @@ set_init_label (fieldname)
      tree fieldname;
 {
   tree tail;
-  int passed = 0;
 
-  /* Don't die if an entire brace-pair level is superfluous
-     in the containing level.  */
-  if (constructor_type == 0)
+  if (set_designator (0))
     return;
 
+  designator_errorneous = 1;
+
+  if (TREE_CODE (constructor_type) != RECORD_TYPE
+      && TREE_CODE (constructor_type) != UNION_TYPE)
+    {
+      error_init ("field name not in record or union initializer");
+      return;
+    }
+    
   for (tail = TYPE_FIELDS (constructor_type); tail;
        tail = TREE_CHAIN (tail))
     {
-      if (tail == constructor_unfilled_fields)
-	passed = 1;
       if (DECL_NAME (tail) == fieldname)
 	break;
     }
@@ -5545,11 +5729,14 @@ set_init_label (fieldname)
   if (tail == 0)
     error ("unknown field `%s' specified in initializer",
 	   IDENTIFIER_POINTER (fieldname));
-  else if (!passed)
-    error ("field `%s' already initialized",
-	   IDENTIFIER_POINTER (fieldname));
   else
-    constructor_fields = tail;
+    {
+      constructor_fields = tail;
+      designator_depth++;
+      designator_errorneous = 0;
+      if (constructor_range_stack)
+	push_range_stack (NULL_TREE);
+    }
 }
 \f
 /* Add a new initializer to the tree of pending initializers.  PURPOSE
@@ -5572,24 +5759,36 @@ add_pending_init (purpose, value)
 	  p = *q;
 	  if (tree_int_cst_lt (purpose, p->purpose))
 	    q = &p->left;
-	  else if (p->purpose != purpose)
+	  else if (tree_int_cst_lt (p->purpose, purpose))
 	    q = &p->right;
 	  else
-	    abort ();
+	    {
+	      if (TREE_SIDE_EFFECTS (p->value))
+		warning_init ("initialized field with side-effects overwritten");
+	      p->value = value;
+	      return;
+	    }
 	}
     }
   else
     {
+      tree bitpos;
+
+      bitpos = bit_position (purpose);
       while (*q != NULL)
 	{
 	  p = *q;
-	  if (tree_int_cst_lt (bit_position (purpose),
-			       bit_position (p->purpose)))
+	  if (tree_int_cst_lt (bitpos, bit_position (p->purpose)))
 	    q = &p->left;
 	  else if (p->purpose != purpose)
 	    q = &p->right;
 	  else
-	    abort ();
+	    {
+	      if (TREE_SIDE_EFFECTS (p->value))
+		warning_init ("initialized field with side-effects overwritten");
+	      p->value = value;
+	      return;
+	    }
 	}
     }
 
@@ -5758,41 +5957,178 @@ add_pending_init (purpose, value)
     }
 }
 
-/* Return nonzero if FIELD is equal to the index of a pending initializer.  */
+/* Build AVL tree from a sorted chain.  */
 
-static int
-pending_init_member (field)
+static void
+set_nonincremental_init ()
+{
+  tree chain;
+
+  if (TREE_CODE (constructor_type) != RECORD_TYPE
+      && TREE_CODE (constructor_type) != ARRAY_TYPE)
+    return;
+
+  for (chain = constructor_elements; chain; chain = TREE_CHAIN (chain))
+    add_pending_init (TREE_PURPOSE (chain), TREE_VALUE (chain));
+  constructor_elements = 0;
+  if (TREE_CODE (constructor_type) == RECORD_TYPE)
+    {
+      constructor_unfilled_fields = TYPE_FIELDS (constructor_type);
+      /* Skip any nameless bit fields at the beginning.  */
+      while (constructor_unfilled_fields != 0
+	     && DECL_C_BIT_FIELD (constructor_unfilled_fields)
+	     && DECL_NAME (constructor_unfilled_fields) == 0)
+	constructor_unfilled_fields = TREE_CHAIN (constructor_unfilled_fields);
+      
+    }
+  else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
+    {
+      if (TYPE_DOMAIN (constructor_type))
+	constructor_unfilled_index
+	    = convert (bitsizetype,
+		       TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
+      else
+	constructor_unfilled_index = bitsize_zero_node;
+    }
+  constructor_incremental = 0;
+}
+
+/* Build AVL tree from a string constant.  */
+
+static void
+set_nonincremental_init_from_string (str)
+     tree str;
+{
+  tree value, purpose, type;
+  HOST_WIDE_INT val[2];
+  const char *p, *end;
+  int byte, wchar_bytes, charwidth, bitpos;
+
+  if (TREE_CODE (constructor_type) != ARRAY_TYPE)
+    abort ();
+
+  if (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (str)))
+      == TYPE_PRECISION (char_type_node))
+    wchar_bytes = 1;
+  else if (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (str)))
+	   == TYPE_PRECISION (wchar_type_node))
+    wchar_bytes = TYPE_PRECISION (wchar_type_node) / BITS_PER_UNIT;
+  else
+    abort ();
+
+  charwidth = TYPE_PRECISION (char_type_node);
+  type = TREE_TYPE (constructor_type);
+  p = TREE_STRING_POINTER (str);
+  end = p + TREE_STRING_LENGTH (str);
+
+  for (purpose = bitsize_zero_node;
+       p < end && !tree_int_cst_lt (constructor_max_index, purpose);
+       purpose = size_binop (PLUS_EXPR, purpose, bitsize_one_node))
+    {
+      if (wchar_bytes == 1)
+	{
+	  val[1] = (unsigned char) *p++;
+	  val[0] = 0;
+	}
+      else
+	{
+	  val[0] = 0;
+	  val[1] = 0;
+	  for (byte = 0; byte < wchar_bytes; byte++)
+	    {
+	      if (BYTES_BIG_ENDIAN)
+		bitpos = (wchar_bytes - byte - 1) * charwidth;
+	      else
+		bitpos = byte * charwidth;
+	      val[bitpos < HOST_BITS_PER_WIDE_INT]
+		|= ((unsigned HOST_WIDE_INT) ((unsigned char) *p++))
+		   << (bitpos % HOST_BITS_PER_WIDE_INT);
+	    }
+	}
+
+      if (!TREE_UNSIGNED (type))
+	{
+	  bitpos = ((wchar_bytes - 1) * charwidth) + HOST_BITS_PER_CHAR;
+	  if (bitpos < HOST_BITS_PER_WIDE_INT)
+	    {
+	      if (val[1] & (((HOST_WIDE_INT) 1) << (bitpos - 1)))
+		{
+		  val[1] |= ((HOST_WIDE_INT) -1) << bitpos;
+		  val[0] = -1;
+		}
+	    }
+	  else if (bitpos == HOST_BITS_PER_WIDE_INT)
+	    {
+	      if (val[1] < 0)
+	        val[0] = -1;
+	    }
+	  else if (val[0] & (((HOST_WIDE_INT) 1)
+			     << (bitpos - 1 - HOST_BITS_PER_WIDE_INT)))
+	    val[0] |= ((HOST_WIDE_INT) -1)
+		      << (bitpos - HOST_BITS_PER_WIDE_INT);
+	}
+
+      value = build_int_2 (val[1], val[0]);
+      TREE_TYPE (value) = type;
+      add_pending_init (purpose, value);
+    }
+
+  constructor_incremental = 0;
+}
+
+/* Return value of FIELD in pending initializer or zero if the field was
+   not initialized yet.  */
+
+static tree
+find_init_member (field)
      tree field;
 {
   struct init_node *p;
 
-  p = constructor_pending_elts;
   if (TREE_CODE (constructor_type) == ARRAY_TYPE)
     {
+      if (constructor_incremental
+	  && tree_int_cst_lt (field, constructor_unfilled_index))
+	set_nonincremental_init ();
+
+      p = constructor_pending_elts;
       while (p)
 	{
-	  if (field == p->purpose)
-	    return 1;
-	  else if (tree_int_cst_lt (field, p->purpose))
+	  if (tree_int_cst_lt (field, p->purpose))
 	    p = p->left;
-	  else
+	  else if (tree_int_cst_lt (p->purpose, field))
 	    p = p->right;
+	  else
+	    return p->value;
 	}
     }
-  else
+  else if (TREE_CODE (constructor_type) == RECORD_TYPE)
     {
+      tree bitpos = bit_position (field);
+
+      if (constructor_incremental
+	  && (!constructor_unfilled_fields
+	      || tree_int_cst_lt (bitpos,
+				  bit_position (constructor_unfilled_fields))))
+	set_nonincremental_init ();
+
+      p = constructor_pending_elts;
       while (p)
 	{
 	  if (field == p->purpose)
-	    return 1;
-	  else if (tree_int_cst_lt (bit_position (field),
-				    bit_position (p->purpose)))
+	    return p->value;
+	  else if (tree_int_cst_lt (bitpos, bit_position (p->purpose)))
 	    p = p->left;
 	  else
 	    p = p->right;
 	}
     }
-
+  else if (TREE_CODE (constructor_type) == UNION_TYPE)
+    {
+      if (constructor_elements
+	  && TREE_PURPOSE (constructor_elements) == field)
+	return TREE_VALUE (constructor_elements);
+    }
   return 0;
 }
 
@@ -5811,8 +6147,6 @@ output_init_element (value, type, field,
      tree value, type, field;
      int pending;
 {
-  int duplicate = 0;
-
   if (TREE_CODE (TREE_TYPE (value)) == FUNCTION_TYPE
       || (TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE
 	  && !(TREE_CODE (value) == STRING_CST
@@ -5840,90 +6174,111 @@ output_init_element (value, type, field,
     }
   else if (require_constant_elements
 	   && initializer_constant_valid_p (value, TREE_TYPE (value)) == 0)
-    {
-      error_init ("initializer element is not computable at load time");
-      value = error_mark_node;
-    }
+    pedwarn ("initializer element is not computable at load time");
 
-  /* If this element duplicates one on constructor_pending_elts,
-     print a message and ignore it.  Don't do this when we're
-     processing elements taken off constructor_pending_elts,
-     because we'd always get spurious errors.  */
-  if (pending)
+  /* If this field is empty (and not at the end of structure),
+     don't do anything other than checking the initializer.  */
+  if (field
+      && (TREE_TYPE (field) == error_mark_node
+	  || (COMPLETE_TYPE_P (TREE_TYPE (field))
+	      && integer_zerop (TYPE_SIZE (TREE_TYPE (field)))
+	      && (TREE_CODE (constructor_type) == ARRAY_TYPE
+		  || TREE_CHAIN (field)))))
+    return;
+
+  if (value == error_mark_node)
     {
-      if (TREE_CODE (constructor_type) == RECORD_TYPE
-	  || TREE_CODE (constructor_type) == UNION_TYPE
-	  || TREE_CODE (constructor_type) == ARRAY_TYPE)
-	{
-	  if (pending_init_member (field))
-	    {
-	      error_init ("duplicate initializer");
-	      duplicate = 1;
-	    }
-	}
+      constructor_erroneous = 1;
+      return;
     }
 
   /* If this element doesn't come next in sequence,
      put it on constructor_pending_elts.  */
   if (TREE_CODE (constructor_type) == ARRAY_TYPE
-      && ! tree_int_cst_equal (field, constructor_unfilled_index))
+      && (!constructor_incremental
+	  || !tree_int_cst_equal (field, constructor_unfilled_index)))
     {
-      if (! duplicate)
-	add_pending_init (field,
-			  digest_init (type, value, require_constant_value, 
-				       require_constant_elements));
+      if (constructor_incremental
+	  && tree_int_cst_lt (field, constructor_unfilled_index))
+	set_nonincremental_init ();
+
+      add_pending_init (field,
+			digest_init (type, value, require_constant_value, 
+				     require_constant_elements));
+      return;
     }
   else if (TREE_CODE (constructor_type) == RECORD_TYPE
-	   && field != constructor_unfilled_fields)
+	   && (!constructor_incremental
+	       || field != constructor_unfilled_fields))
     {
       /* We do this for records but not for unions.  In a union,
 	 no matter which field is specified, it can be initialized
 	 right away since it starts at the beginning of the union.  */
-      if (!duplicate)
-	add_pending_init (field,
-			  digest_init (type, value, require_constant_value, 
-				       require_constant_elements));
+      if (constructor_incremental)
+	{
+	  if (!constructor_unfilled_fields)
+	    set_nonincremental_init ();
+	  else
+	    {
+	      tree bitpos, unfillpos;
+
+	      bitpos = bit_position (field);
+	      unfillpos = bit_position (constructor_unfilled_fields);
+
+	      if (tree_int_cst_lt (bitpos, unfillpos))
+		set_nonincremental_init ();
+	    }
+	}
+
+      add_pending_init (field,
+			digest_init (type, value, require_constant_value, 
+				     require_constant_elements));
+      return;
     }
-  else
+  else if (TREE_CODE (constructor_type) == UNION_TYPE
+	   && constructor_elements)
     {
-      /* Otherwise, output this element either to
-	 constructor_elements or to the assembler file.  */
+      if (TREE_SIDE_EFFECTS (TREE_VALUE (constructor_elements)))
+	warning_init ("initialized field with side-effects overwritten");
 
-      if (!duplicate)
-	{
-	  if (field && TREE_CODE (field) == INTEGER_CST)
-	    field = copy_node (field);
-	  constructor_elements
-	    = tree_cons (field, digest_init (type, value,
-					     require_constant_value, 
-					     require_constant_elements),
-			 constructor_elements);
-	}
+      /* We can have just one union field set.  */
+      constructor_elements = 0;
+    }
 
-      /* Advance the variable that indicates sequential elements output.  */
-      if (TREE_CODE (constructor_type) == ARRAY_TYPE)
-	constructor_unfilled_index
-	  = size_binop (PLUS_EXPR, constructor_unfilled_index,
-			bitsize_one_node);
-      else if (TREE_CODE (constructor_type) == RECORD_TYPE)
-	{
-	  constructor_unfilled_fields
-	    = TREE_CHAIN (constructor_unfilled_fields);
-
-	  /* Skip any nameless bit fields.  */
-	  while (constructor_unfilled_fields != 0
-		 && DECL_C_BIT_FIELD (constructor_unfilled_fields)
-		 && DECL_NAME (constructor_unfilled_fields) == 0)
-	    constructor_unfilled_fields =
-	      TREE_CHAIN (constructor_unfilled_fields);
-	}
-      else if (TREE_CODE (constructor_type) == UNION_TYPE)
-	constructor_unfilled_fields = 0;
+  /* Otherwise, output this element either to
+     constructor_elements or to the assembler file.  */
+
+  if (field && TREE_CODE (field) == INTEGER_CST)
+    field = copy_node (field);
+  constructor_elements
+    = tree_cons (field, digest_init (type, value,
+				     require_constant_value, 
+				     require_constant_elements),
+		 constructor_elements);
 
-      /* Now output any pending elements which have become next.  */
-      if (pending)
-	output_pending_init_elements (0);
+  /* Advance the variable that indicates sequential elements output.  */
+  if (TREE_CODE (constructor_type) == ARRAY_TYPE)
+    constructor_unfilled_index
+      = size_binop (PLUS_EXPR, constructor_unfilled_index,
+		    bitsize_one_node);
+  else if (TREE_CODE (constructor_type) == RECORD_TYPE)
+    {
+      constructor_unfilled_fields
+	= TREE_CHAIN (constructor_unfilled_fields);
+
+      /* Skip any nameless bit fields.  */
+      while (constructor_unfilled_fields != 0
+	     && DECL_C_BIT_FIELD (constructor_unfilled_fields)
+	     && DECL_NAME (constructor_unfilled_fields) == 0)
+	constructor_unfilled_fields =
+	  TREE_CHAIN (constructor_unfilled_fields);
     }
+  else if (TREE_CODE (constructor_type) == UNION_TYPE)
+    constructor_unfilled_fields = 0;
+
+  /* Now output any pending elements which have become next.  */
+  if (pending)
+    output_pending_init_elements (0);
 }
 
 /* Output any pending elements which have become next.
@@ -5999,18 +6354,23 @@ output_pending_init_elements (all)
       else if (TREE_CODE (constructor_type) == RECORD_TYPE
 	       || TREE_CODE (constructor_type) == UNION_TYPE)
 	{
+	  tree ctor_unfilled_bitpos, elt_bitpos;
+
 	  /* If the current record is complete we are done.  */
 	  if (constructor_unfilled_fields == 0)
 	    break;
-	  if (elt->purpose == constructor_unfilled_fields)
-	    {
-	      output_init_element (elt->value,
-				   TREE_TYPE (constructor_unfilled_fields),
-				   constructor_unfilled_fields,
-				   0);
+
+	  ctor_unfilled_bitpos = bit_position (constructor_unfilled_fields);
+	  elt_bitpos = bit_position (elt->purpose);
+	  /* We can't compare fields here because there might be empty
+	     fields in between.  */
+	  if (tree_int_cst_equal (elt_bitpos, ctor_unfilled_bitpos))
+	    {
+	      constructor_unfilled_fields = elt->purpose;
+	      output_init_element (elt->value, TREE_TYPE (elt->purpose),
+				   elt->purpose, 0);
 	    }
-	  else if (tree_int_cst_lt (bit_position (constructor_unfilled_fields),
-				    bit_position (elt->purpose)))
+	  else if (tree_int_cst_lt (ctor_unfilled_bitpos, elt_bitpos))
 	    {
 	      /* Advance to the next smaller node.  */
 	      if (elt->left)
@@ -6036,9 +6396,8 @@ output_pending_init_elements (all)
 		    elt = elt->parent;
 		  elt = elt->parent;
 		  if (elt
-		      && (tree_int_cst_lt
-			  (bit_position (constructor_unfilled_fields),
-			   bit_position (elt->purpose))))
+		      && (tree_int_cst_lt (ctor_unfilled_bitpos,
+					   bit_position (elt->purpose))))
 		    {
 		      next = elt->purpose;
 		      break;
@@ -6081,6 +6440,9 @@ process_init_element (value)
   tree orig_value = value;
   int string_flag = value != 0 && TREE_CODE (value) == STRING_CST;
 
+  designator_depth = 0;
+  designator_errorneous = 0;
+
   /* Handle superfluous braces around string cst as in
      char x[] = {"foo"}; */
   if (string_flag
@@ -6123,6 +6485,10 @@ process_init_element (value)
 	break;
     }
 
+  /* In the case of [LO ... HI] = VALUE, only evaluate VALUE once.  */
+  if (constructor_range_stack)
+    value = save_expr (value);
+
   while (1)
     {
       if (TREE_CODE (constructor_type) == RECORD_TYPE)
@@ -6191,9 +6557,8 @@ process_init_element (value)
 		 && DECL_C_BIT_FIELD (constructor_fields)
 		 && DECL_NAME (constructor_fields) == 0)
 	    constructor_fields = TREE_CHAIN (constructor_fields);
-	  break;
 	}
-      if (TREE_CODE (constructor_type) == UNION_TYPE)
+      else if (TREE_CODE (constructor_type) == UNION_TYPE)
 	{
 	  tree fieldtype;
 	  enum tree_code fieldcode;
@@ -6252,9 +6617,8 @@ process_init_element (value)
 	    }
 
 	  constructor_fields = 0;
-	  break;
 	}
-      if (TREE_CODE (constructor_type) == ARRAY_TYPE)
+      else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
 	{
 	  tree elttype = TYPE_MAIN_VARIANT (TREE_TYPE (constructor_type));
 	  enum tree_code eltcode = TREE_CODE (elttype);
@@ -6285,61 +6649,93 @@ process_init_element (value)
 	      break;
 	    }
 
-	  /* In the case of [LO .. HI] = VALUE, only evaluate VALUE once.  */
-	  if (constructor_range_end)
+	  /* Now output the actual element.  */
+	  if (value)
 	    {
-	      if (constructor_max_index != 0
-		  && tree_int_cst_lt (constructor_max_index, 
-				      constructor_range_end))
-		{
-		  pedwarn_init ("excess elements in array initializer");
-		  constructor_range_end = constructor_max_index;
-		}
-
-	      value = save_expr (value);
+	      push_array_bounds (tree_low_cst (constructor_index, 0));
+	      output_init_element (value, elttype, constructor_index, 1);
+	      RESTORE_SPELLING_DEPTH (constructor_depth);
 	    }
 
-	  /* Now output the actual element.
-	     Ordinarily, output once.
-	     If there is a range, repeat it till we advance past the range.  */
-	  do
-	    {
-	      if (value)
-		{
-		  push_array_bounds (tree_low_cst (constructor_index, 0));
-		  output_init_element (value, elttype, constructor_index, 1);
-		  RESTORE_SPELLING_DEPTH (constructor_depth);
-		}
-
-	      constructor_index
-		= size_binop (PLUS_EXPR, constructor_index, bitsize_one_node);
-
-	      if (! value)
-		/* If we are doing the bookkeeping for an element that was
-		   directly output as a constructor, we must update
-		   constructor_unfilled_index.  */
-		constructor_unfilled_index = constructor_index;
-	    }
-	  while (! (constructor_range_end == 0
-		    || tree_int_cst_lt (constructor_range_end,
-					constructor_index)));
+	  constructor_index
+	    = size_binop (PLUS_EXPR, constructor_index, bitsize_one_node);
 
-	  break;
+	  if (! value)
+	    /* If we are doing the bookkeeping for an element that was
+	       directly output as a constructor, we must update
+	       constructor_unfilled_index.  */
+	    constructor_unfilled_index = constructor_index;
 	}
 
       /* Handle the sole element allowed in a braced initializer
 	 for a scalar variable.  */
-      if (constructor_fields == 0)
+      else if (constructor_fields == 0)
 	{
 	  pedwarn_init ("excess elements in scalar initializer");
 	  break;
 	}
+      else
+	{
+	  if (value)
+	    output_init_element (value, constructor_type, NULL_TREE, 1);
+	  constructor_fields = 0;
+	}
+
+      /* Handle range initializers either at this level or anywhere higher
+	 in the designator stack.  */
+      if (constructor_range_stack)
+	{
+	  struct constructor_range_stack *p, *range_stack;
+	  int finish = 0;
+
+	  range_stack = constructor_range_stack;
+	  constructor_range_stack = 0;
+	  while (constructor_stack != range_stack->stack)
+	    {
+	      if (!constructor_stack->implicit)
+		abort ();
+	      process_init_element (pop_init_level (1));
+	    }
+	  for (p = range_stack;
+	       !p->range_end || tree_int_cst_equal (p->index, p->range_end);
+	       p = p->prev)
+	    {
+	      if (!constructor_stack->implicit)
+		abort ();
+	      process_init_element (pop_init_level (1));
+	    }
+
+	  p->index = size_binop (PLUS_EXPR, p->index, bitsize_one_node);
+	  if (tree_int_cst_equal (p->index, p->range_end) && !p->prev)
+	    finish = 1;
+
+	  while (1)
+	    {
+	      constructor_index = p->index;
+	      constructor_fields = p->fields;
+	      if (finish && p->range_end && p->index == p->range_start)
+		{
+		  finish = 0;
+		  p->prev = 0;
+		}
+	      p = p->next;
+	      if (!p)
+		break;
+	      push_init_level (2);
+	      p->stack = constructor_stack;
+	      if (p->range_end && tree_int_cst_equal (p->index, p->range_end))
+		p->index = p->range_start;
+	    }
+
+	  if (!finish)
+	    constructor_range_stack = range_stack;
+	  continue;
+	}
 
-      if (value)
-	output_init_element (value, constructor_type, NULL_TREE, 1);
-      constructor_fields = 0;
       break;
     }
+
+  constructor_range_stack = 0;
 }
 \f
 /* Build an asm-statement, whose components are a CV_QUALIFIER, a
--- gcc/extend.texi.jj	Fri Jan 12 11:35:37 2001
+++ gcc/extend.texi	Fri Jan 12 11:55:29 2001
@@ -1258,6 +1258,10 @@ int widths[] = @{ [0 ... 9] = 1, [10 ...
 @end example
 
 @noindent
+If the value in it has side-effects, the side-effects will happen only once,
+not for each initialized field by the range initializer.
+
+@noindent
 Note that the length of the array is the highest value specified
 plus one.
 
@@ -1341,6 +1345,12 @@ example, with the @samp{struct point} de
 @example
 struct point ptarray[10] = @{ [2].y = yv2, [2].x = xv2, [0].x = xv0 @};
 @end example
+
+@noindent
+If the same field is initialized multiple times, it will have value from
+the last initialization.  If any such overridden initialization has
+side-effect, it is unspecified whether the side-effect happens or not.
+Currently, gcc will discard them and issue a warning.
 
 @node Case Ranges
 @section Case Ranges
--- gcc/testsuite/gcc.dg/c90-init-1.c.jj	Fri Jan 12 11:55:29 2001
+++ gcc/testsuite/gcc.dg/c90-init-1.c	Fri Jan 12 11:55:29 2001
@@ -0,0 +1,25 @@
+/* Test for C99 designated initializers */
+/* Origin: Jakub Jelinek <jakub@redhat.com> */
+/* { dg-do compile } */
+/* { dg-options "-std=iso9899:1990 -pedantic-errors" } */
+
+struct A {
+  int B;
+  short C[2];
+};
+int a[10] = { 10, [4] = 15 };			/* { dg-error "ISO C89 forbids specifying subobject to initialize" } */
+struct A b = { .B = 2 };			/* { dg-error "ISO C89 forbids specifying subobject to initialize" } */
+struct A c[] = { [3].C[1] = 1 };		/* { dg-error "ISO C89 forbids specifying subobject to initialize" } */
+struct A d[] = { [4 ... 6].C[0 ... 1] = 2 };	/* { dg-error "(forbids specifying range of elements to initialize)|(ISO C89 forbids specifying subobject to initialize)" } */
+int e[] = { [2] 2 };				/* { dg-error "use of designated initializer without" } */
+struct A f = { C: { 0, 1 } };			/* { dg-error "use of designated initializer with " } */
+int g;
+
+void foo (int *);
+
+void bar (void)
+{
+  int x[] = { g++, 2 };				/* { dg-error "is not computable at load time" } */
+
+  foo (x);
+}
--- gcc/testsuite/gcc.dg/c99-init-1.c.jj	Fri Jan 12 11:55:29 2001
+++ gcc/testsuite/gcc.dg/c99-init-1.c	Fri Jan 12 11:55:29 2001
@@ -0,0 +1,78 @@
+/* Test for C99 designated initializers */
+/* Origin: Jakub Jelinek <jakub@redhat.com> */
+/* { dg-do run } */
+/* { dg-options "-std=iso9899:1999 -pedantic-errors" } */
+
+typedef __SIZE_TYPE__ size_t;
+typedef __WCHAR_TYPE__ wchar_t;
+extern int memcmp (const void *, const void *, size_t);
+extern void abort (void);
+extern void exit (int);
+
+int a[10] = { 10, 0, 12, 13, 14, 0, 0, 17, 0, 0 };
+int b[10] = { 10, [4] = 15, [2] = 12, [4] = 14, [7] = 17 };
+int c[10] = { 10, [4] = 15, [2] = 12, [3] = 13, 14, [7] = 17 };
+struct A {
+  int B;
+  short C[2];
+};
+struct A d[] = { { 0, { 1, 2 } }, { 0, { 0, 0 } }, { 10, { 11, 12 } } };
+struct A e[] = { 0, 1, 2, [2] = 10, 11, 12 };
+struct A f[] = { 0, 1, 2, [2].C = 11, 12, 13 };
+struct A g[] = { 0, 1, 2, [2].C[1] = 12, 13, 14 };
+struct A h[] = { 0, 1, 2, [2] = { .C[1] = 12 }, 13, 14 };
+struct A i[] = { 0, 1, 2, [2] = { .C = { [1] = 12 } }, 13, 14 };
+union D {
+  int E;
+  double F;
+  struct A G;
+};
+union D j[] = { [4] = 1, [4].F = 1.0, [1].G.C[1] = 4 };
+struct H {
+  char I[6];
+  int J;
+} k[] = { { { "foo" }, 1 }, [0].I[0] = 'b' };
+struct K {
+  wchar_t L[6];
+  int M;
+} l[] = { { { L"foo" }, 1 }, [0].L[2] = L'x', [0].L[4] = L'y' };
+struct H m[] = { { { "foo" }, 1 }, [0] = { .I[0] = 'b' } };
+struct H n[] = { { { "foo" }, 1 }, [0].I = { "a" }, [0].J = 2 };
+int o = { 22 };
+
+int main (void)
+{
+  if (b[3])
+    abort ();
+  b[3] = 13;
+  if (memcmp (a, b, sizeof (a)) || memcmp (a, c, sizeof (a)))
+    abort ();
+  if (memcmp (d, e, sizeof (d)) || sizeof (d) != sizeof (e))
+    abort ();
+  if (f[2].B != 0 || g[2].B != 0 || g[2].C[0] != 0)
+    abort ();
+  if (memcmp (g, h, sizeof (g)) || memcmp (g, i, sizeof (g)))
+    abort ();
+  f[2].B = 10;
+  g[2].B = 10;
+  g[2].C[0] = 11;
+  if (memcmp (d, f, sizeof (d)) || memcmp (d, g, sizeof (d)))
+    abort ();
+  if (f[3].B != 13 || g[3].B != 13 || g[3].C[0] != 14)
+    abort ();
+  if (j[0].E || j[1].G.B || j[1].G.C[0] || j[1].G.C[1] != 4)
+    abort ();
+  if (j[2].E || j[3].E || j[4].F != 1.0)
+    abort ();
+  if (memcmp (k[0].I, "boo\0\0", 6) || k[0].J != 1)
+    abort ();
+  if (memcmp (l[0].L, L"fox\0y", 6 * sizeof(wchar_t)) || l[0].M != 1)
+    abort ();
+  if (memcmp (m[0].I, "b\0\0\0\0", 6) || m[0].J)
+    abort ();
+  if (memcmp (n[0].I, "a\0\0\0\0", 6) || n[0].J != 2)
+    abort ();
+  if (o != 22)
+    abort ();
+  exit (0);
+}
--- gcc/testsuite/gcc.dg/c99-init-2.c.jj	Fri Jan 12 11:55:29 2001
+++ gcc/testsuite/gcc.dg/c99-init-2.c	Fri Jan 12 11:55:29 2001
@@ -0,0 +1,30 @@
+/* Test for C99 designated initializer warnings and errors */
+/* Origin: Jakub Jelinek <jakub@redhat.com> */
+/* { dg-do compile } */
+/* { dg-options "-std=iso9899:1999 -Wall -pedantic-errors" } */
+
+typedef struct {
+  int B;
+  short C[2];
+} A;
+A a = { [2] = 1 };			/* { dg-error "(array index in non-array)|(near initialization)" } */
+int b[] = { .B = 1 };			/* { dg-error "(field name not in record)|(near initialization)" } */
+A c[] = { [0].D = 1 };			/* { dg-error "unknown field" } */
+int d;
+int e = { d++ };			/* { dg-error "(is not constant)|(near initialization)" } */
+A f[2] = { [0].C[0] = 1, [2] = { 2, { 1, 2 } } };/* { dg-error "(array index in initializer exceeds array bounds)|(near initialization)" } */
+int g[4] = { [1] = 1, 2, [6] = 5 };	/* { dg-error "(array index in initializer exceeds array bounds)|(near initialization)" } */
+int h[] = { [0 ... 3] = 5 };		/* { dg-error "forbids specifying range of elements" } */
+int i[] = { [2] 4 };			/* { dg-error "use of designated initializer without" } */
+A j = { B: 2 };				/* { dg-error "use of designated initializer with " } */
+
+void foo (int *, A *);
+
+void bar (void)
+{
+  int a[] = { d++, [0] = 1 };		/* { dg-warning "(initialized field with side-effects overwritten)|(near initialization)" } */
+  A b = { 1, { d++, 2 }, .C[0] = 3 };/* { dg-warning "(initialized field with side-effects overwritten)|(near initialization)" } */
+  A c = { d++, { 2, 3 }, .B = 4 };	/* { dg-warning "(initialized field with side-effects overwritten)|(near initialization)" } */
+
+  foo (a, d ? &b : &c);
+}
--- gcc/testsuite/gcc.dg/gnu99-init-1.c.jj	Fri Jan 12 11:55:29 2001
+++ gcc/testsuite/gcc.dg/gnu99-init-1.c	Fri Jan 12 11:55:29 2001
@@ -0,0 +1,62 @@
+/* Test for GNU extensions to C99 designated initializers */
+/* Origin: Jakub Jelinek <jakub@redhat.com> */
+/* { dg-do run } */
+/* { dg-options "-std=gnu99" } */
+
+typedef __SIZE_TYPE__ size_t;
+extern int memcmp (const void *, const void *, size_t);
+extern void abort (void);
+extern void exit (int);
+
+int a[][2][4] = { [2 ... 4][0 ... 1][2 ... 3] = 1, [2] = 2, [2][0][2] = 3 };
+struct E {};
+struct F { struct E H; };
+struct G { int I; struct E J; int K; };
+struct H { int I; struct F J; int K; };
+struct G k = { .J = {}, 1 };
+struct H l = { .J.H = {}, 2 };
+struct H m = { .J = {}, 3 };
+struct I { int J; int K[3]; int L; };
+struct M { int N; struct I O[3]; int P; };
+struct M n[] = { [0 ... 5].O[1 ... 2].K[0 ... 1] = 4, 5, 6, 7 };
+
+int main (void)
+{
+  int x, y, z;
+
+  if (a[2][0][0] != 2 || a[2][0][2] != 3)
+    abort ();
+  a[2][0][0] = 0;
+  a[2][0][2] = 1;
+  for (x = 0; x <= 4; x++)
+    for (y = 0; y <= 1; y++)
+      for (z = 0; z <= 3; z++)
+	if (a[x][y][z] != (x >= 2 && z >= 2))
+	  abort ();
+  if (k.I || l.I || m.I || k.K != 1 || l.K != 2 || m.K != 3)
+    abort ();
+  for (x = 0; x <= 5; x++)
+    {
+      if (n[x].N || n[x].O[0].J || n[x].O[0].L)
+	abort ();
+      for (y = 0; y <= 2; y++)
+	if (n[x].O[0].K[y])
+	  abort ();
+      for (y = 1; y <= 2; y++)
+	{
+	  if (n[x].O[y].J)
+	    abort ();
+	  if (n[x].O[y].K[0] != 4)
+	    abort ();
+	  if (n[x].O[y].K[1] != 4)
+	    abort ();
+	  if ((x < 5 || y < 2) && (n[x].O[y].K[2] || n[x].O[y].L))
+	    abort ();
+	}
+      if (x < 5 && n[x].P)
+	abort ();
+    }
+  if (n[5].O[2].K[2] != 5 || n[5].O[2].L != 6 || n[5].P != 7)
+    abort ();
+  exit (0);
+}
--- gcc/testsuite/gcc.c-torture/execute/20000801-3.x.jj	Thu Aug  3 09:36:13 2000
+++ gcc/testsuite/gcc.c-torture/execute/20000801-3.x	Thu Aug 24 11:00:32 2000
@@ -1,2 +0,0 @@
-set torture_execute_xfail "*-*-*"
-return 0


	Jakub

Re: Unreviewed patches

[Richard Henderson]

On Fri, Jan 12, 2001 at 07:27:55PM +0100, Jakub Jelinek wrote:
> ia32 ICE testcase - not fixed yet
> 	http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00594.html

Ok.

> (as this last one no longer applies cleanly, I've updated the patch
> to current CVS, bootstrapped with it and regression tested on
> i386-redhat-linux, the updated patch is below):

Ok.


r~