Re: [PATCH: PR target/46975] Replace 32 bit instructions with 16 bit instructions in thumb2

[Carrot Wei]

Ping

On Sat, Dec 18, 2010 at 3:30 AM, Carrot Wei  wrote:
> On Fri, Dec 17, 2010 at 4:18 AM, Richard Earnshaw  wrote:
>>
>> On Thu, 2010-12-16 at 14:45 -0800, Carrot Wei wrote:
>>> Hi
>>>
>>> Compile the following c code with options -march=armv7-a -mthumb -Os
>>>
>>> int foo (int s)
>>> {
>>>     return s == 1;
>>> }
>>>
>>> GCC 4.6 generates:
>>>
>>>  :
>>>    0:    f1a0 0301     sub.w    r3, r0, #1    // A
>>>    4:    4258          negs    r0, r3
>>>    6:    eb40 0003     adc.w    r0, r0, r3      // B
>>>    a:    4770          bx    lr
>>>
>>> Notice that instructions A and B are 32 bits. In thumb2 we can use subs and 
>>> adcs
>>> instead so they will be 16 bits.
>>>
>>
>> This sequence already contains an instruction that sets the flags as a
>> necessary part of the sequence.  Why doesn't it also generate
>> flag-corrupting variants of the other two instructions when the
>
> That is the root cause of this problem. The old pattern simply didn't
> generate the flag setting version.
>
>> registers selected are suitable?  It seems silly to force the compiler
>> to do yet more work to clean up this code.
>>
>
> This patch doesn't force the compiler to do more work. It directly
> modifies the original peephole2 pattern to generate flag setting
> instructions as you suggested. And the new insn pattern is for
> instruction adcs which didn't exist previously.
>
> thanks
> Guozhi
>

Re: RX: 4.5 branch: Fix alignment and addressing issues.

[Nick Clifton]

Hi Richard,


What is length used for in the rx port?  I don't see any branch shortening
going on here; out of range branches are completely handled by the assembler.

You might be better off simply deleting the length attribute, so that the
compiler skips the bulk of the shorten_branches pass.


Darn - I feel like a complete idiot!  You are right of course - the 
length attribute is not used at all.  Adding the attribute was just 
habitual, I never thought to check to see if it was really needed.


I'll make a patch to remove the lengths and check it in shortly.

Cheers
  Nick

Re: PATCH: PR target/48171: Missing "Save" on -mavx and -mfma

[Richard Guenther]

On Thu, Mar 17, 2011 at 7:42 PM, Uros Bizjak  wrote:
> On Thu, Mar 17, 2011 at 6:51 PM, H.J. Lu  wrote:
>
>> All i386 ISA options, except for -mavx and -mfma, have Save.  This patch
>> fixes it.  OK for trunk and 4.6?
>>
>> 2011-03-17  H.J. Lu  
>>
>>        PR target/48171
>>        * config/i386/i386.opt: Add Save to -mavx and -mfma.
>
> OK for 4.7 and 4.6 with the approval from RM.

Ok for 4.6 (and the 4.5 branch if it applies there).

Thanks,
Richard.

> Thanks,
> Uros.
>

Re: [PATCH] Fix hppa-* --enable-checking=release bootstrap (PR bootstrap/48161)

[Richard Guenther]

On Thu, Mar 17, 2011 at 11:38 PM, Jakub Jelinek  wrote:
> On Thu, Mar 17, 2011 at 09:07:43PM +0100, Jakub Jelinek wrote:
>> The following fixes the testcase in cross to hppa-* as well.
>> I'll bootstrap/regtest it momentarily, ok if it passes?
>
> Now bootstrapped/regtested on x86_64-linux and i686-linux.

Ok.

Thanks,
Richard.

>> 2011-03-17  Richard Henderson  
>>           Jakub Jelinek  
>>
>>       PR bootstrap/48161
>>       * expr.c (expand_expr_addr_expr_1): Use simplify_gen_binary
>>       instead of gen_rtx_PLUS if EXPAND_SUM or EXPAND_INITIALIZER.
>>
>>       * gcc.c-torture/compile/pr48161.c: New test.
>>
>> --- gcc/expr.c.jj     2011-03-14 14:12:15.0 +0100
>> +++ gcc/expr.c        2011-03-17 16:49:01.0 +0100
>> @@ -6971,7 +6971,7 @@ expand_expr_addr_expr_1 (tree exp, rtx t
>>        tmp = convert_memory_address_addr_space (tmode, tmp, as);
>>
>>        if (modifier == EXPAND_SUM || modifier == EXPAND_INITIALIZER)
>> -     result = gen_rtx_PLUS (tmode, result, tmp);
>> +     result = simplify_gen_binary (PLUS, tmode, result, tmp);
>>        else
>>       {
>>         subtarget = bitpos ? NULL_RTX : target;
>> --- gcc/testsuite/gcc.c-torture/compile/pr48161.c.jj  2011-03-09 
>> 16:32:56.85501 +0100
>> +++ gcc/testsuite/gcc.c-torture/compile/pr48161.c     2011-03-17 
>> 17:20:34.0 +0100
>
>        Jakub
>

Re: RX: 4.5 branch: Fix alignment and addressing issues.

[Nick Clifton]

Hi Mike,


And why is that a problem?  You get to write arbitrarily complex C code that 
can depend upon insn and operands.


Ah - I did not know this.  I thought that you had to stick to RTL 
expressions in the definition of attributes.  Thanks for letting me know 
otherwise.


Cheers
  Nick

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

>> Ok for mainline if that passes, and perhaps also the 4.6 branch?
>
> I'm ok with this for mainline - Paolo, can you double-check the
> autofoo stuff?  As for 4.6 I'd like to give it a day or two on
> trunk to allow people to report problems.

The patch has been on mainline for two days now and I'm not aware of any
problems.  Unless someone objects, I'm going to apply it to 4.6 branch
later today.

Rainer

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

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Richard Guenther]

On Fri, Mar 18, 2011 at 10:26 AM, Rainer Orth
 wrote:
> Richard Guenther  writes:
>
>>> Ok for mainline if that passes, and perhaps also the 4.6 branch?
>>
>> I'm ok with this for mainline - Paolo, can you double-check the
>> autofoo stuff?  As for 4.6 I'd like to give it a day or two on
>> trunk to allow people to report problems.
>
> The patch has been on mainline for two days now and I'm not aware of any
> problems.  Unless someone objects, I'm going to apply it to 4.6 branch
> later today.

It seemed to have disabled linker-plugin support for old binutils
with --with-plugin-ld=/usr/local/bin/gold, explicit -fuse-linker-plugin says
it is not supported.  The system linker does not have plugin support
(nor gold).  /usr/local has gold from binutils 2.20.50.xxx.  So it seems that

# Allow -fuse-linker-plugin to enable plugin support in GNU gold 2.20.
elif test "$ld_is_gold" = yes -a "$ld_vers_major" -eq 2 -a
"$ld_vers_minor" -eq 20; then
  gcc_cv_lto_plugin=1
fi

only allows explicit -fuse-linker-plugin for recent gold but based on checking
the system linker version (instead of that of --with-plugin-ld).  I'd say
allow explicit -fuse-linker-plugin always if --with-plugin-ld is specified.

Richard.

Re: [Patch][AVR]: Support tail calls

[Georg-Johann Lay]

Denis Chertykov schrieb:
> 2011/3/16 Georg-Johann Lay 
>> Richard Henderson schrieb:
>>> On 03/16/2011 03:32 AM, Georg-Johann Lay wrote:
>>> 
 Richard Henderson schrieb:
 
> On 03/11/2011 05:43 AM, Georg-Johann Lay wrote:
> 
>> I did not find a way to make this work together with
>> -mcall-prologues. Please let me know if you have
>> suggestion on how call prologues can be combine with tail
>> calls.
> You need a new symbol in libgcc for this.  It should be
> easy enough to have the sibcall epilogue load up Z+EIND
> before jumping to the new symbol (perhaps called
> __sibcall_restores__).  This new symbol would be just like 
> the existing __epilogue_restores__ except that it would
> finish with an eijmp/ijmp instruction (depending on
> multilib) instead of a ret instruction.
 The point is that the intent of -mprologue-saves is to save
 program memory space (flash). If we load the callee's address
 in the epilogue, the epilogue's size will increase. Moreover,
 adding an other lengthy function besides
 __epilogue_restores__ to libgcc, that will increase code size
 because in many cases we will see both epilogue flavors being
 dragged into application.
>>> All true, but supposing there are enough tail calls then on
>>> balance you'll still save flash space.
>> Only if epilogue size decreses. As tail-call saves at most 2
>> bytes and storing the address (either return-to in epilogue or
>> jump-to caller) will take more than 2 bytes. So nothing is won.
>> 
>>> An intermediate alternative is to simply override
>>> TARGET_CALL_PROLOGUES in sibcall epilogues.  I.e. let
>>> __prologue_saves__ be generated as usual, and
>>> __epilogue_restores__ be generated as usual for normal
>>> epilogues, but test for sibcall_p in computing "minimize".
>> This means that long epilogues that with call-prologues would
>> deflate then would no more deflate and had to be coded inline in
>> epilogue.
>> 
>> Maybe we can take the patch as-is, let approve it and fiddle out
>> more optimization opportunities later?
> 
> Is it tested for regressions ?
> 
> Denis.

I ran tests against svn 170942 (latest 4.7.0 snapshot). Besides
timestamps, the diff looks like this:

1435a1436,1437
> XPASS: gcc.dg/sibcall-3.c execution test
> XPASS: gcc.dg/sibcall-4.c execution test
1630,1631c1632,1633
< # of unexpected successes 4
< # of expected failures132
---
> # of unexpected successes 6
> # of expected failures130
1670c1672

This is due to xfail for runtime-test of sibcall abilities for avr-*-*.

Johann

Re: [PATCH][C] Fix PR47939

[Richard Guenther]

On Fri, 11 Mar 2011, Joseph S. Myers wrote:

> On Fri, 11 Mar 2011, Richard Guenther wrote:
> 
> > Indeed.  I tried to let the array case alone (because it's so
> > complicated) but failed to do so.  Appearantly
> > 
> >   if (declarator->kind == cdk_array && TYPE_QUALS (element_type))
> > type = TYPE_MAIN_VARIANT (type);
> > 
> > leaves it alone (and doesn't emit a DW_TAG_typedef for T for your
> > testcase).  Thus out of the set of testcases I added the array
> > case now fails with the above (as I'd have expected but were of
> > course positively surprised as it didn't ...).
> > 
> > I verified the main variants and canonical types are sane with
> > the above variant for your testcase.
> > 
> > If you think such change isn't safe either I'll pursue a dwarf2out.c
> > local change, somehow forcing out the typedef DIE even if it is unused.
> > I don't feel at home in the grokdeclarator dungeon.
> 
> What I think is safe in grokdeclarator is using TYPE_MAIN_VARIANT here if 
> *either* the type given in the declaration specifiers is an array type 
> (TREE_CODE (type) == ARRAY_TYPE, as in your previous patch) *or* the first 
> declarator that is not cdk_attrs is cdk_array (as in this version, but 
> checking through a chain of declarator->declarator to find a possible 
> cdk_array after a sequence of cdk_attrs).
> 
> (Aside from all this it is a longstanding known bug that the debug 
> information for arrays of qualified types isn't quite right: PR 8354.)

Ok, the following works for me.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Thanks,
Richard.

2011-03-17  Richard Guenther  

PR c/47939
* c-decl.c (grokdeclarator): Drop to the main variant only
for array types.  Drop flag_gen_aux_info check.

* gcc.dg/debug/dwarf2/pr47939-1.c: New testcase.
* gcc.dg/debug/dwarf2/pr47939-2.c: Likewise.
* gcc.dg/debug/dwarf2/pr47939-3.c: Likewise.
* gcc.dg/debug/dwarf2/pr47939-4.c: Likewise.

Index: gcc/c-decl.c
===
*** gcc/c-decl.c(revision 171097)
--- gcc/c-decl.c(working copy)
*** grokdeclarator (const struct c_declarato
*** 4892,4897 
--- 4892,4898 
const char *errmsg;
tree expr_dummy;
bool expr_const_operands_dummy;
+   enum c_declarator_kind first_non_attr_kind;
  
if (TREE_CODE (type) == ERROR_MARK)
  return error_mark_node;
*** grokdeclarator (const struct c_declarato
*** 4911,4916 
--- 4912,4918 
{
  const struct c_declarator *decl = declarator;
  
+ first_non_attr_kind = cdk_attrs;
  while (decl)
switch (decl->kind)
{
*** grokdeclarator (const struct c_declarato
*** 4922,4927 
--- 4924,4931 
case cdk_pointer:
  funcdef_syntax = (decl->kind == cdk_function);
  decl = decl->declarator;
+ if (first_non_attr_kind == cdk_attrs)
+   first_non_attr_kind = decl->kind;
  break;
  
case cdk_attrs:
*** grokdeclarator (const struct c_declarato
*** 4932,4937 
--- 4936,4943 
  loc = decl->id_loc;
  if (decl->u.id)
name = decl->u.id;
+ if (first_non_attr_kind == cdk_attrs)
+   first_non_attr_kind = decl->kind;
  decl = 0;
  break;
  
*** grokdeclarator (const struct c_declarato
*** 5038,5044 
  error_at (loc, "conflicting named address spaces (%s vs %s)",
  c_addr_space_name (as1), c_addr_space_name (as2));
  
!   if (!flag_gen_aux_info && (TYPE_QUALS (element_type)))
  type = TYPE_MAIN_VARIANT (type);
type_quals = ((constp ? TYPE_QUAL_CONST : 0)
| (restrictp ? TYPE_QUAL_RESTRICT : 0)
--- 5044,5052 
  error_at (loc, "conflicting named address spaces (%s vs %s)",
  c_addr_space_name (as1), c_addr_space_name (as2));
  
!   if ((TREE_CODE (type) == ARRAY_TYPE
!|| first_non_attr_kind == cdk_array)
!   && TYPE_QUALS (element_type))
  type = TYPE_MAIN_VARIANT (type);
type_quals = ((constp ? TYPE_QUAL_CONST : 0)
| (restrictp ? TYPE_QUAL_RESTRICT : 0)
Index: gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-1.c
===
*** gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-1.c   (revision 0)
--- gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-1.c   (revision 0)
***
*** 0 
--- 1,8 
+ /* { dg-do compile } */
+ /* { dg-options "-save-temps -g -dA" } */
+ 
+ typedef struct _Harry { int dummy; } Harry_t;
+ Harry_t harry;
+ 
+ /* { dg-final { scan-assembler 
"DW_TAG_typedef\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_name: \"Harry_t\"" } } 
*/
+ /* { dg-final { cleanup-saved-temps } } */
Index: gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-2.c
===
*** gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-2.c   (revis

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

> It seemed to have disabled linker-plugin support for old binutils
> with --with-plugin-ld=/usr/local/bin/gold, explicit -fuse-linker-plugin says
> it is not supported.  The system linker does not have plugin support
> (nor gold).  /usr/local has gold from binutils 2.20.50.xxx.  So it seems that
>
> # Allow -fuse-linker-plugin to enable plugin support in GNU gold 2.20.
> elif test "$ld_is_gold" = yes -a "$ld_vers_major" -eq 2 -a
> "$ld_vers_minor" -eq 20; then
>   gcc_cv_lto_plugin=1
> fi
>
> only allows explicit -fuse-linker-plugin for recent gold but based on checking
> the system linker version (instead of that of --with-plugin-ld).  I'd say
> allow explicit -fuse-linker-plugin always if --with-plugin-ld is specified.

Agreed.  I'll have a look and refrain from installing on 4.6 until this
is resolved.  I wasn't even aware of --with-plugin-ld, which isn't
documented in install.texi ;-(  This stuff seems insanely complicated to
me, though: which user is supposed to deal with such complications?

Rainer

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

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Richard Guenther]

On Fri, 18 Mar 2011, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> > It seemed to have disabled linker-plugin support for old binutils
> > with --with-plugin-ld=/usr/local/bin/gold, explicit -fuse-linker-plugin says
> > it is not supported.  The system linker does not have plugin support
> > (nor gold).  /usr/local has gold from binutils 2.20.50.xxx.  So it seems 
> > that
> >
> > # Allow -fuse-linker-plugin to enable plugin support in GNU gold 2.20.
> > elif test "$ld_is_gold" = yes -a "$ld_vers_major" -eq 2 -a
> > "$ld_vers_minor" -eq 20; then
> >   gcc_cv_lto_plugin=1
> > fi
> >
> > only allows explicit -fuse-linker-plugin for recent gold but based on 
> > checking
> > the system linker version (instead of that of --with-plugin-ld).  I'd say
> > allow explicit -fuse-linker-plugin always if --with-plugin-ld is specified.
> 
> Agreed.  I'll have a look and refrain from installing on 4.6 until this
> is resolved.  I wasn't even aware of --with-plugin-ld, which isn't
> documented in install.texi ;-(  This stuff seems insanely complicated to
> me, though: which user is supposed to deal with such complications?

It's sort of historic ... with plugin support for GNU ld we can probably
drop this flag for 4.7 (eventually I'd even like to enforce the use
of the plugin all the time or disable LTO, just for the sake of reducing
the testing and bugreporting matrix ...).

I just noticed the above with the LTO setup of our SPEC testers
which are using somewhat old system tools.

Thanks,
Richard.

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

> It's sort of historic ... with plugin support for GNU ld we can probably

Could you or someone else who understands this stuff please document it
in install.texi then?  Thanks.

> drop this flag for 4.7 (eventually I'd even like to enforce the use
> of the plugin all the time or disable LTO, just for the sake of reducing
> the testing and bugreporting matrix ...).

This would mean no more LTO without GNU ld/gold, then?  Isn't this going
too far?

Rainer

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

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

[Janne Blomqvist]

On Thu, Mar 17, 2011 at 14:21, FX  wrote:
> Thanks for the review!
>
>> - Use the type size_t for tempdirlen as that is the return type of
>> strlen() and argument type for get_mem().
>>
>> - You can use a const size_t variable for the length of the string
>> "slash" rather than calling strlen() in the do-while loop.
>
> Both OK.
>
>> - Don't set errno as we anyway loop until we successfully open a file
>> with O_CREAT|O_EXCL.
>
> No, if I don't set errno, the continue statement will not iteration the loop, 
> as the condition (fd == -1 && errno == EEXIST) is false. Unless I don't 
> understand what you mean.

I was thinking that maybe it's a bit bad style to set errno after
getting an error return from a function that may itself have set errno
(depending on which vendor manpage one reads, mktemp() may or may not
set some errno value, so this is a bit poorly specified, but I
digress), thus overwriting to real cause of the error with an error
code that may or may not have anything to do with the actual failure.
That is, maybe something like

fd = -1;
do
{
// Create template
if (!mktemp(...)) continue;
fd = open(...);
if (fd == -1 && errno != EEXIST) break;
} while (fd == -1)

is a bit clearer, but ultimately I suppose the end result is the same.
So on second thought I guess your original code is Ok too, if you
prefer that.



-- 
Janne Blomqvist

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Richard Guenther]

On Fri, 18 Mar 2011, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> > It's sort of historic ... with plugin support for GNU ld we can probably
> 
> Could you or someone else who understands this stuff please document it
> in install.texi then?  Thanks.

I'll try.

> > drop this flag for 4.7 (eventually I'd even like to enforce the use
> > of the plugin all the time or disable LTO, just for the sake of reducing
> > the testing and bugreporting matrix ...).
> 
> This would mean no more LTO without GNU ld/gold, then?  Isn't this going
> too far?

I'm not sure - the collect2 path has known issues that are hard
to address and result in unexpected behavior, so it's probably
not a good service to our users to serve them half-broken LTO.

But I suppose we can discuss this when we also see a clear benefit
in removing the corresponding code in gcc.

Richard.
kk

[PATCH] Document --with-plugin-ld

[Richard Guenther]

This documents --with-plugin-ld and removes the --enable-gold 
documentation (which is bogus now).

Does this look ok?

Thanks,
Richard.

2011-03-18  Richard Guenther  

* doc/install.texi (--enable-gold): Remove.
(--with-plugin-ld): Document.
* doc/invoke.texi (-fuse-linker-plugin): Clarify.

Index: gcc/doc/install.texi
===
*** gcc/doc/install.texi(revision 171097)
--- gcc/doc/install.texi(working copy)
*** GLIBC 2.11 or above, otherwise disabled.
*** 1666,1678 
  Enable support for link-time optimization (LTO).  This is enabled by
  default, and may be disabled using @option{--disable-lto}.
  
! @item --enable-gold
! Enable support for using @command{gold} as the linker.  If gold support is
! enabled together with @option{--enable-lto}, an additional directory
! @file{lto-plugin} will be built.  The code in this directory is a
! plugin for gold that allows the link-time optimizer to extract object
! files with LTO information out of library archives.  See
! @option{-flto} and @option{-fwhopr} for details.
  @end table
  
  @subheading Cross-Compiler-Specific Options
--- 1666,1676 
  Enable support for link-time optimization (LTO).  This is enabled by
  default, and may be disabled using @option{--disable-lto}.
  
! @item --with-plugin-ld=@var{pathname}
! Enable an alternate linker to be used at link-time optimization (LTO)
! link time when @option{-fuse-linker-plugin} is enabled.
! This linker should have plugin support such as gold or GNU ld starting
! with version 2.21.  See @option{-fuse-linker-plugin} for details.
  @end table
  
  @subheading Cross-Compiler-Specific Options
Index: gcc/doc/invoke.texi
===
*** gcc/doc/invoke.texi (revision 171097)
--- gcc/doc/invoke.texi (working copy)
*** Disabled by default.
*** 7718,7725 
  
  @item -fuse-linker-plugin
  Enables the use of linker plugin during link time optimization.  This option
! relies on the linker plugin support in linker that is available in @code{gold}
! or in GNU ld 2.21.51 or newer..
  
  This option enables the extraction of object files with GIMPLE bytecode out of
  library archives. This improves the quality of optimization by exposing more
--- 7718,7725 
  
  @item -fuse-linker-plugin
  Enables the use of linker plugin during link time optimization.  This option
! relies on the linker plugin support in linker that is available in gold
! or in GNU ld 2.21 or newer.
  
  This option enables the extraction of object files with GIMPLE bytecode out of
  library archives. This improves the quality of optimization by exposing more
*** use hidden visibility) is similar to @co
*** 7730,7736 
  @option{-flto} for a description on the effect of this flag and how to use it.
  
  Enabled by default when LTO support in GCC is enabled and GCC was compiled
! with linker supporting plugins (GNU ld or @code{gold}).
  
  @item -fcompare-elim
  @opindex fcompare-elim
--- 7730,7736 
  @option{-flto} for a description on the effect of this flag and how to use it.
  
  Enabled by default when LTO support in GCC is enabled and GCC was compiled
! with a linker supporting plugins (GNU ld 2.21 or newer or gold).
  
  @item -fcompare-elim
  @opindex fcompare-elim

Re: [PATCH] Document --with-plugin-ld

[Rainer Orth]

Richard Guenther  writes:

> --- 1666,1676 
>   Enable support for link-time optimization (LTO).  This is enabled by
>   default, and may be disabled using @option{--disable-lto}.
>   
> ! @item --with-plugin-ld=@var{pathname}
> ! Enable an alternate linker to be used at link-time optimization (LTO)
> ! link time when @option{-fuse-linker-plugin} is enabled.
> ! This linker should have plugin support such as gold or GNU ld starting
> ! with version 2.21.  See @option{-fuse-linker-plugin} for details.
>   @end table

While gold already existed in binutils 2.19 (maybe earlier, haven't
checked), plugin support only appeared in 2.20, so the references to
gold should be qualified (also in invoke.texi).

Rainer

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

[PATCH][PR48170] Remove bogus asserts from gcse.c

[Maxim Kuvyrkov]

PR48170 is about an ICE in code hoisting when using non-default parameter 
value.  The ICE is due to an outdated assert; the attached patch simply removes 
it.  I will commit the patch under the trivial rule if no one objects in 24 
hours.

The asserts used to verify an invariant that held true before a subsequent 
improvement to code hoisting was committed.  The asserts were active only when 
a non-default value is used for the max-hoist-depth parameter, so no one 
noticed the outdated sanity checks before now.

Thanks,

--
Maxim Kuvyrkov
Mentor Graphics / CodeSourcery
+7-812-677-6839



gcse-assert-1.ChangeLog
Description: Binary data


gcse-assert-1.patch
Description: Binary data

[Committed] S/390: Use define_c_enum for the unspec constants

[Andreas Krebbel]

Hi,

the attached patch uses define_c_enum for defining the unspec constant
as it recently has been changed for other targets as well.

Committed to mainline.

Bye,

-Andreas-


2011-03-18  Andreas Krebbel  

* config/s390/s390.md: Use define_c_enum for the unspec constant
definitions.

Index: gcc/config/s390/s390.md
===
*** gcc/config/s390/s390.md.orig
--- gcc/config/s390/s390.md
***
*** 57,143 
  ;; UNSPEC usage
  ;;
  
! (define_constants
!   [; Miscellaneous
!(UNSPEC_ROUND  1)
!(UNSPEC_CCU_TO_INT 2)
!(UNSPEC_CCZ_TO_INT 3)
!(UNSPEC_ICM10)
!(UNSPEC_TIE  11)
  
 ; GOT/PLT and lt-relative accesses
!(UNSPEC_LTREL_OFFSET   100)
!(UNSPEC_LTREL_BASE 101)
!(UNSPEC_POOL_OFFSET102)
!(UNSPEC_GOTENT 110)
!(UNSPEC_GOT111)
!(UNSPEC_GOTOFF 112)
!(UNSPEC_PLT113)
!(UNSPEC_PLTOFF 114)
  
 ; Literal pool
!(UNSPEC_RELOAD_BASE210)
!(UNSPEC_MAIN_BASE  211)
!(UNSPEC_LTREF  212)
!(UNSPEC_INSN   213)
!(UNSPEC_EXECUTE214)
  
 ; Atomic Support
!(UNSPEC_MB 400)
  
 ; TLS relocation specifiers
!(UNSPEC_TLSGD  500)
!(UNSPEC_TLSLDM 501)
!(UNSPEC_NTPOFF   502)
!(UNSPEC_DTPOFF   503)
!(UNSPEC_GOTNTPOFF504)
!(UNSPEC_INDNTPOFF505)
  
 ; TLS support
!(UNSPEC_TLSLDM_NTPOFF  511)
!(UNSPEC_TLS_LOAD   512)
  
 ; String Functions
!(UNSPEC_SRST   600)
!(UNSPEC_MVST   601)
  
 ; Stack Smashing Protector
!(UNSPEC_SP_SET 700)
!(UNSPEC_SP_TEST701)
  
 ; Test Data Class (TDC)
!(UNSPEC_TDC_INSN   800)
  
 ; Population Count
!(UNSPEC_POPCNT   900)
!(UNSPEC_COPYSIGN 901)
   ])
  
  ;;
  ;; UNSPEC_VOLATILE usage
  ;;
  
! (define_constants
!   [; Blockage
!(UNSPECV_BLOCKAGE  0)
  
 ; TPF Support
!(UNSPECV_TPF_PROLOGUE20)
!(UNSPECV_TPF_EPILOGUE21)
  
 ; Literal pool
!(UNSPECV_POOL  200)
!(UNSPECV_POOL_SECTION  201)
!(UNSPECV_POOL_ALIGN202)
!(UNSPECV_POOL_ENTRY203)
!(UNSPECV_MAIN_POOL 300)
  
 ; TLS support
!(UNSPECV_SET_TP500)
  
 ; Atomic Support
!(UNSPECV_CAS   700)
!(UNSPECV_ATOMIC_OP   701)
])
  
  ;;
--- 57,143 
  ;; UNSPEC usage
  ;;
  
! (define_c_enum "unspec" [
!; Miscellaneous
!UNSPEC_ROUND
!UNSPEC_CCU_TO_INT
!UNSPEC_CCZ_TO_INT
!UNSPEC_ICM
!UNSPEC_TIE
  
 ; GOT/PLT and lt-relative accesses
!UNSPEC_LTREL_OFFSET
!UNSPEC_LTREL_BASE
!UNSPEC_POOL_OFFSET
!UNSPEC_GOTENT
!UNSPEC_GOT
!UNSPEC_GOTOFF
!UNSPEC_PLT
!UNSPEC_PLTOFF
  
 ; Literal pool
!UNSPEC_RELOAD_BASE
!UNSPEC_MAIN_BASE
!UNSPEC_LTREF
!UNSPEC_INSN
!UNSPEC_EXECUTE
  
 ; Atomic Support
!UNSPEC_MB
  
 ; TLS relocation specifiers
!UNSPEC_TLSGD
!UNSPEC_TLSLDM
!UNSPEC_NTPOFF
!UNSPEC_DTPOFF
!UNSPEC_GOTNTPOFF
!UNSPEC_INDNTPOFF
  
 ; TLS support
!UNSPEC_TLSLDM_NTPOFF
!UNSPEC_TLS_LOAD
  
 ; String Functions
!UNSPEC_SRST
!UNSPEC_MVST
  
 ; Stack Smashing Protector
!UNSPEC_SP_SET
!UNSPEC_SP_TEST
  
 ; Test Data Class (TDC)
!UNSPEC_TDC_INSN
  
 ; Population Count
!UNSPEC_POPCNT
!UNSPEC_COPYSIGN
   ])
  
  ;;
  ;; UNSPEC_VOLATILE usage
  ;;
  
! (define_c_enum "unspecv" [
!; Blockage
!UNSPECV_BLOCKAGE
  
 ; TPF Support
!UNSPECV_TPF_PROLOGUE
!UNSPECV_TPF_EPILOGUE
  
 ; Literal pool
!UNSPECV_POOL
!UNSPECV_POOL_SECTION
!UNSPECV_POOL_ALIGN
!UNSPECV_POOL_ENTRY
!UNSPECV_MAIN_POOL
  
 ; TLS support
!UNSPECV_SET_TP
  
 ; Atomic Support
!UNSPECV_CAS
!UNSPECV_ATOMIC_OP
])
  
  ;;

[v3] Start random dists values testing

[Paolo Carlini]

Hi,

the below is a start on the long overdue task of checking the values 
produces by the random distributions. For the time being I'm simply 
adapting rather elementary code in GSL, already good enough to enable 
regression tests for libstdc++/48114.


I expect that testing along similar lines the other discrete 
distributions will be pretty straightforward; for the continuous ones 
we'll need an integration routine (I hope something simpler than 
gsl_integration_qags will be enough).


Tested x86_64-linux, committed to mainline.

Paolo.


2011-03-18  Paolo Carlini  

* testsuite/util/testsuite_random.h: New.
* testsuite/lib/libstdc++.exp (check_v3_target_c99_math,
dg-require-c99_math): Add.
* testsuite/26_numerics/random/bernoulli_distribution/
operators/values.cc: New.
* testsuite/26_numerics/random/binomial_distribution/
operators/values.cc: Likewise.
* testsuite/26_numerics/random/geometric_distribution/
operators/values.cc: Likewise.

Index: testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
===
--- testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc 
(revision 0)
+++ testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc 
(revision 0)
@@ -0,0 +1,50 @@
+// { dg-options "-std=gnu++0x" }
+// { dg-require-cstdint "" }
+//
+// Copyright (C) 2011 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// 26.5.8.2.1 Class template bernoulli_distribution [rand.dist.bern.bernoulli]
+
+#include 
+#include 
+#include 
+
+void test01()
+{
+  using namespace __gnu_test;
+
+  std::mt19937 eng;
+
+  std::bernoulli_distribution bd1(0.25);
+  auto bbd1 = std::bind(bd1, eng);
+  testDiscreteDist(bbd1, [](int n) { return bernoulli_pdf(n, 0.25); } );
+
+  std::bernoulli_distribution bd2(0.5);
+  auto bbd2 = std::bind(bd2, eng);
+  testDiscreteDist(bbd2, [](int n) { return bernoulli_pdf(n, 0.5); } );
+
+  std::bernoulli_distribution bd3(0.75);
+  auto bbd3 = std::bind(bd3, eng);
+  testDiscreteDist(bbd3, [](int n) { return bernoulli_pdf(n, 0.75); } );
+}
+
+int main()
+{
+  test01();
+  return 0;
+}
Index: testsuite/26_numerics/random/binomial_distribution/operators/values.cc
===
--- testsuite/26_numerics/random/binomial_distribution/operators/values.cc  
(revision 0)
+++ testsuite/26_numerics/random/binomial_distribution/operators/values.cc  
(revision 0)
@@ -0,0 +1,52 @@
+// { dg-options "-std=gnu++0x" }
+// { dg-require-cstdint "" }
+// { dg-require-c99_math "" }
+//
+// Copyright (C) 2011 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// 26.5.8.2.2 Class template binomial_distribution [rand.dist.bern.bin]
+
+#include 
+#include 
+#include 
+
+void test01()
+{
+  using namespace __gnu_test;
+
+  std::mt19937 eng;
+
+  std::binomial_distribution<> bd1(5, 0.3);
+  auto bbd1 = std::bind(bd1, eng);
+  testDiscreteDist(bbd1, [](int n) { return binomial_pdf(n, 0.3, 5); } );
+
+  std::binomial_distribution<> bd2(55, 0.3);
+  auto bbd2 = std::bind(bd2, eng);
+  testDiscreteDist(bbd2, [](int n) { return binomial_pdf(n, 0.3, 55); } );
+
+  // libstdc++/48114
+  std::binomial_distribution<> bd3(10, 0.75);
+  auto bbd3 = std::bind(bd3, eng);
+  testDiscreteDist(bbd3, [](int n) { return binomial_pdf(n, 0.75, 10); } );
+}
+
+int main()
+{
+  test01();
+  return 0;
+}
Index: testsuite/26_numerics/random/geometric_distribution/operators/values.cc
==

[PATCH Committed] [SH] Delegitimize more unspecs

[Kaz Kojima]

On SH, there are many new warnings like

  note: non-delegitimized UNSPEC 46 found in variable location

which are reported by dwarf2out.c:const_ok_for_output_1.
The attached patch is a minimal fix.  It's tested with
the top level "make -k check" on cross sh4-unknown-linux-gnu.
Currently, it's hard to test with the native bootstrap on
this target for the periodic long power outage here.
Applied on trunk.

Regards,
kaz
--
2011-03-18  Kaz Kojima  

* config/sh/sh.c (sh_delegitimize_address): Handle UNSPEC_SYMOFF
and UNSPEC_PCREL_SYMOFF.

diff -uprN ORIG/trunk/gcc/config/sh/sh.c LOCAL/trunk/gcc/config/sh/sh.c
--- ORIG/trunk/gcc/config/sh/sh.c   2010-12-24 09:56:26.0 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.c  2011-03-18 08:05:03.0 +0900
@@ -1,6 +1,6 @@
 /* Output routines for GCC for Renesas / SuperH SH.
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-   2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+   2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
Free Software Foundation, Inc.
Contributed by Steve Chamberlain (s...@cygnus.com).
Improved by Jim Wilson (wil...@cygnus.com).
@@ -10019,8 +10019,20 @@ sh_delegitimize_address (rtx orig_x)
   if (GET_CODE (y) == UNSPEC)
{
  if (XINT (y, 1) == UNSPEC_GOT
- || XINT (y, 1) == UNSPEC_GOTOFF)
+ || XINT (y, 1) == UNSPEC_GOTOFF
+ || XINT (y, 1) == UNSPEC_SYMOFF)
return XVECEXP (y, 0, 0);
+ else if (XINT (y, 1) == UNSPEC_PCREL_SYMOFF)
+   {
+ if (GET_CODE (XVECEXP (y, 0, 0)) == CONST)
+   {
+ rtx symplt = XEXP (XVECEXP (y, 0, 0), 0);
+
+ if (GET_CODE (symplt) == UNSPEC
+ && XINT (symplt, 1) == UNSPEC_PLT)
+   return XVECEXP (symplt, 0, 0);
+   }
+   }
  else if (TARGET_SHMEDIA
   && (XINT (y, 1) == UNSPEC_EXTRACT_S16
   || XINT (y, 1) == UNSPEC_EXTRACT_U16))

[PATCH] Emit .debug_aranges when needed (PR debug/48176)

[Jakub Jelinek]

Hi!

Eric changed dwarf2out_finish in January to fix PR46704, unfortunately
that change means we often don't emit .debug_aranges at all even when it
should be present and is needed for e.g. elfutils.
In PR46704 there were 2 DECL_IGNORED functions with -O2 -g
-fkeep-inline-functions, so fde_table_in_use was 2, but .debug_info
section wasn't emitted as it was empty and thus .debug_aranges referenced
non-existent .Ldebug_info0 symbol.
arange_table_in_use is often 0, in particular if all emitted functions
are only in .text/.text.unlikely sections.  .debug_aranges contains
first range of .text the current CU covers, then range of .text.unlikely
and only afterwards the other ranges (arange_table_in_use is count of
those).

The following patch fixes it by emitting .debug_aranges whenever it will
be non-empty (and the extra && info_section_emitted is just to make sure
.Ldebug_info0 can be used too).  If you want, for 4.7+ I think
we could just use
  if (text_section_used || cold_text_section_used || arange_table_in_use)
{
  gcc_assert (info_section_emitted);
...

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.6?

2011-03-18  Jakub Jelinek  

PR debug/48176
* dwarf2out.c (dwarf2out_finish): Call output_aranges even when
arange_table_in_use is 0, but either text_section_used or
cold_text_section_used is true.  Don't call it if
!info_section_emitted.

--- gcc/dwarf2out.c.jj  2011-03-17 21:34:34.0 +0100
+++ gcc/dwarf2out.c 2011-03-18 10:50:33.303546024 +0100
@@ -23667,7 +23667,8 @@ dwarf2out_finish (const char *filename)
 
   /* Output the address range information.  We only put functions in the arange
  table, so don't write it out if we don't have any.  */
-  if (arange_table_in_use)
+  if ((text_section_used || cold_text_section_used || arange_table_in_use)
+  && info_section_emitted)
 {
   switch_to_section (debug_aranges_section);
   output_aranges ();

Jakub

Re: [v3] Regenerate Solaris 2 baselines for GCC 4.6.0 release

[Rainer Orth]

Benjamin Kosnik  writes:

>> ... and I suppose the thinko alone should be fixed in 4_6-branch too,
>> right?
>
> Yeah. The versioning for the latest symbols has to match, or be done
> in a compatible way. But hang on, I'll wait on Rainer and move trunk to
> branch if he can confirm trunk is version-able on solaris.

I had some trouble testing the revised patch since Solaris 2/SPARC
bootstrap was/is broken due to PR bootstrap/48168.  While Ada bootstrap
remains broken, a C++-only bootstrap succeeded today.

Here's the updated baseline, which is identical between 4.6 branch and
mainline.  Only the 32-bit Solaris 8 versions are included below.  The
following symbols are included:

FUNC:std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@@GLIBCXX_3.4.15
FUNC:std::__detail::_List_node_base::_M_reverse()@@GLIBCXX_3.4.15
FUNC:std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*,
 std::__detail::_List_node_base*)@@GLIBCXX_3.4.15
FUNC:std::__detail::_List_node_base::_M_unhook()@@GLIBCXX_3.4.15
FUNC:std::__detail::_List_node_base::swap(std::__detail::_List_node_base&, 
std::__detail::_List_node_base&)@@GLIBCXX_3.4.15
FUNC:std::__throw_regex_error(std::regex_constants::error_type)@@GLIBCXX_3.4.15
FUNC:std::bad_function_call::~bad_function_call()@@GLIBCXX_3.4.15
FUNC:std::bad_function_call::~bad_function_call()@@GLIBCXX_3.4.15
FUNC:std::bad_function_call::~bad_function_call()@@GLIBCXX_3.4.15
FUNC:std::bad_weak_ptr::what() const@@GLIBCXX_3.4.15
FUNC:std::bad_weak_ptr::~bad_weak_ptr()@@GLIBCXX_3.4.15
FUNC:std::bad_weak_ptr::~bad_weak_ptr()@@GLIBCXX_3.4.15
FUNC:std::bad_weak_ptr::~bad_weak_ptr()@@GLIBCXX_3.4.15
FUNC:std::domain_error::~domain_error()@@GLIBCXX_3.4.15
FUNC:std::error_category::error_category()@@GLIBCXX_3.4.15
FUNC:std::error_category::error_category()@@GLIBCXX_3.4.15
FUNC:std::error_category::~error_category()@@GLIBCXX_3.4.15
FUNC:std::error_category::~error_category()@@GLIBCXX_3.4.15
FUNC:std::error_category::~error_category()@@GLIBCXX_3.4.15
FUNC:std::invalid_argument::~invalid_argument()@@GLIBCXX_3.4.15
FUNC:std::length_error::~length_error()@@GLIBCXX_3.4.15
FUNC:std::nested_exception::~nested_exception()@@CXXABI_1.3.5
FUNC:std::nested_exception::~nested_exception()@@CXXABI_1.3.5
FUNC:std::nested_exception::~nested_exception()@@CXXABI_1.3.5
FUNC:std::out_of_range::~out_of_range()@@GLIBCXX_3.4.15
FUNC:std::overflow_error::~overflow_error()@@GLIBCXX_3.4.15
FUNC:std::range_error::~range_error()@@GLIBCXX_3.4.15
FUNC:std::regex_error::~regex_error()@@GLIBCXX_3.4.15
FUNC:std::regex_error::~regex_error()@@GLIBCXX_3.4.15
FUNC:std::regex_error::~regex_error()@@GLIBCXX_3.4.15
FUNC:std::underflow_error::~underflow_error()@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_10@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_11@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_12@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_13@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_14@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_15@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_16@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_17@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_18@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_19@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_1@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_20@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_21@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_22@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_23@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_24@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_25@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_26@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_27@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_28@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_29@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_2@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_3@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_4@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_5@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_6@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_7@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_8@@GLIBCXX_3.4.15
OBJECT:1:std::placeholders::_9@@GLIBCXX_3.4.15
OBJECT:12:typeinfo for std::bad_function_call@@GLIBCXX_3.4.15
OBJECT:12:typeinfo for std::bad_weak_ptr@@GLIBCXX_3.4.15
OBJECT:8:typeinfo for std::nested_exception@@CXXABI_1.3.5
OBJECT:12:typeinfo for std::regex_error@@GLIBCXX_3.4.15
OBJECT:22:typeinfo name for std::bad_function_call@@GLIBCXX_3.4.15
OBJECT:17:typeinfo name for std::bad_weak_ptr@@GLIBCXX_3.4.15
OBJECT:21:typeinfo name for std::nested_exception@@CXXABI_1.3.5
OBJECT:16:typeinfo name for std::regex_error@@GLIBCXX_3.4.15
OBJECT:20:vtable for std::bad_function_call@@GLIBCXX_3.4.15
OBJECT:20:vtable for std::bad_weak_ptr@@GLIBCXX_3.4.15
OBJECT:16:vtable for std::nested_exception@@CXXABI_1.3.5
OBJECT:20:vtable for std::regex_error@@GLIBCXX_3.4.15

Ok for both now?

Thanks.
Rainer


diff -r 799b9125cd6d 
libstdc++-v3/config/abi/post/solaris2.8/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/solaris2.8/baseline

[PING] 3 patches waiting for review

[Andreas Krebbel]

A problem causing wrong code to be generated for decimal floating
point programs:

[PATCH] Fix PR46399 - missing mode promotion for libcall args - updated
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00141.html


To my understandig this is a testcase bug.  Probably the warning is
expected in that line only because it happens to appear there on x86.

[PATCH] Fix PR39246 move uninitialized var warning
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01638.html


A minor rtx unsharing problem with a simple fix (perhaps even
obvious?):

[PATCH] recog.c: Fix RTX unsharing in change groups
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00187.html

Bye,

-Andreas-

Bug 47790 - [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew included a patch in this PR to make
optimize_bitfield_assignment_op work again.  I've fixed a couple
indention problems and added a couple comments.

Bootstrapped and regression tested on x86_64-unknown-linux-gnu.  Applied
to trunk.

Interestingly enough, it clearly helps the testcase referenced in the
PR, but doesn't help GCC itself or the runtime libraries.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNg2WxAAoJEBRtltQi2kC7zBUIAKqguCLpaXKfsQ4LnUfBlnvS
7f4ortxtl30UoIIAVhMD1kaVusdCYPAGBPd4nfvj5QWdf3Ka2h+wrNevRZdG9jqQ
kmcaDt39khLrzagau3EmgxfG3FhjTfLQME8b+4D07Hj3FuYlxepUuv0wQ9phJZKI
Q6Ra33peqlG5q9ywSOoFtDWeOPdhLF/cHt4N6iSPhD4kQEqpo8KyHe3MSON+0WF/
Y1Hu41ASYmNHnjemjUJojbLaVfGkgdJsIBi90TmwNcv1yCEeYpiDQCzdsP5aWpaZ
lv9yVWcuTiUux2uzgNhrHJWBOMAcsJ0i8Wlo5IhnHAKVTg6gwa+7+yYd1c/05ao=
=9x8U
-END PGP SIGNATURE-
PR middle-end/47790
* expr.c (optimize_bitfield_assignment_op): Revamp to work
again after expansion changes.


Index: expr.c
===
*** expr.c  (revision 171074)
--- expr.c  (working copy)
*** optimize_bitfield_assignment_op (unsigne
*** 3974,3979 
--- 3974,3981 
tree op0, op1;
rtx value, result;
optab binop;
+   gimple srcstmt;
+   enum tree_code code;
  
if (mode1 != VOIDmode
|| bitsize >= BITS_PER_WORD
*** optimize_bitfield_assignment_op (unsigne
*** 3983,3995 
  return false;
  
STRIP_NOPS (src);
!   if (!BINARY_CLASS_P (src)
!   || TREE_CODE (TREE_TYPE (src)) != INTEGER_TYPE)
  return false;
  
!   op0 = TREE_OPERAND (src, 0);
!   op1 = TREE_OPERAND (src, 1);
!   STRIP_NOPS (op0);
  
if (!operand_equal_p (to, op0, 0))
  return false;
--- 3985,4021 
  return false;
  
STRIP_NOPS (src);
!   if (TREE_CODE (src) != SSA_NAME)
! return false;
!   if (TREE_CODE (TREE_TYPE (src)) != INTEGER_TYPE)
! return false;
! 
!   srcstmt = get_gimple_for_ssa_name (src);
!   if (!srcstmt
!   || TREE_CODE_CLASS (gimple_assign_rhs_code (srcstmt)) != tcc_binary)
  return false;
  
!   code = gimple_assign_rhs_code (srcstmt);
! 
!   op0 = gimple_assign_rhs1 (srcstmt);
! 
!   /* If OP0 is an SSA_NAME, then we want to walk the use-def chain
!  to find its initialization.  Hopefully the initialization will
!  be from a bitfield load.  */
!   if (TREE_CODE (op0) == SSA_NAME)
! {
!   gimple op0stmt = get_gimple_for_ssa_name (op0);
! 
!   /* We want to eventually have OP0 be the same as TO, which
!should be a bitfield.  */
!   if (!op0stmt
! || !is_gimple_assign (op0stmt)
! || gimple_assign_rhs_code (op0stmt) != TREE_CODE (to))
!   return false;
!   op0 = gimple_assign_rhs1 (op0stmt);
! }
! 
!   op1 = gimple_assign_rhs2 (srcstmt);
  
if (!operand_equal_p (to, op0, 0))
  return false;
*** optimize_bitfield_assignment_op (unsigne
*** 4026,4032 
if (BYTES_BIG_ENDIAN)
  bitpos = str_bitsize - bitpos - bitsize;
  
!   switch (TREE_CODE (src))
  {
  case PLUS_EXPR:
  case MINUS_EXPR:
--- 4052,4058 
if (BYTES_BIG_ENDIAN)
  bitpos = str_bitsize - bitpos - bitsize;
  
!   switch (code)
  {
  case PLUS_EXPR:
  case MINUS_EXPR:
*** optimize_bitfield_assignment_op (unsigne
*** 4054,4060 
  set_mem_expr (str_rtx, 0);
}
  
!   binop = TREE_CODE (src) == PLUS_EXPR ? add_optab : sub_optab;
if (bitsize == 1 && bitpos + bitsize != str_bitsize)
{
  value = expand_and (str_mode, value, const1_rtx, NULL);
--- 4080,4086 
  set_mem_expr (str_rtx, 0);
}
  
!   binop = code == PLUS_EXPR ? add_optab : sub_optab;
if (bitsize == 1 && bitpos + bitsize != str_bitsize)
{
  value = expand_and (str_mode, value, const1_rtx, NULL);
*** optimize_bitfield_assignment_op (unsigne
*** 4087,4093 
  set_mem_expr (str_rtx, 0);
}
  
!   binop = TREE_CODE (src) == BIT_IOR_EXPR ? ior_optab : xor_optab;
if (bitpos + bitsize != GET_MODE_BITSIZE (GET_MODE (str_rtx)))
{
  rtx mask = GEN_INT (((unsigned HOST_WIDE_INT) 1 << bitsize)
--- 4113,4119 
  set_mem_expr (str_rtx, 0);
}
  
!   binop = code == BIT_IOR_EXPR ? ior_optab : xor_optab;
if (bitpos + bitsize != GET_MODE_BITSIZE (GET_MODE (str_rtx)))
{
  rtx mask = GEN_INT (((unsigned HOST_WIDE_INT) 1 << bitsize)

Re: [PATCH] Emit .debug_aranges when needed (PR debug/48176)

[Jason Merrill]

OK.

Jason

Re: [PATCH][PR48170] Remove bogus asserts from gcse.c

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/18/11 05:09, Maxim Kuvyrkov wrote:
> PR48170 is about an ICE in code hoisting when using non-default parameter 
> value.  The ICE is due to an outdated assert; the attached patch simply 
> removes it.  I will commit the patch under the trivial rule if no one objects 
> in 24 hours.
> 
> The asserts used to verify an invariant that held true before a subsequent 
> improvement to code hoisting was committed.  The asserts were active only 
> when a non-default value is used for the max-hoist-depth parameter, so no one 
> noticed the outdated sanity checks before now.
> 
OK.
jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNg2ZgAAoJEBRtltQi2kC7et8H/jksKM/N+A6ckuS7eQiYeILX
m7AsYYwuk0x7zKzEXXUAwMJJNMxWW1OWdF0TSh9KaC9rTLvSIiC/riO2qJYS82ty
k2TfaTWOMNNBHzHAoDe5HeNW36QCAdwL/pkcmWrR0Kxx1VxE3JAJXD8m5ZbUOJyO
32EEAHCxGfv8LTI1ueItN3XznxmDlNnD82YZAFi/o5rJPNFzTdj07AptRHpCvjby
PE6R2ls7DK1+U0Npl/kVdGiZy9k4IVN7qecFLdQ0bGDd6vuhhMS/mLhtXqivvSTE
u9d2xELYEtBeRya1wAucAdH7kH5eH4H5TQWjXZ1GxaNElxVPm3FUSVR/Z5PrBDI=
=Kv2/
-END PGP SIGNATURE-

[testsuite] Skip gcc.dg/torture/20090618-1.c on IRIX (PR middle-end/47405)

[Rainer Orth]

As described in the PR, gcc.dg/torture/20090618-1.c fails on IRIX 5 and
6 due to undefined references to mempcpy, which doesn't exist in libc.
This might be a target bug.  Richard suggested to skip the test, which
this patch does.

Tested with the appropriate runtest invocations.  Applied to mainline
and 4.5 branch, ok for 4.6 branch, too?

Thanks.
Rainer


2011-03-17  Rainer Orth  

PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

diff -r e829a5812e49 gcc/testsuite/gcc.dg/torture/20090618-1.c
--- a/gcc/testsuite/gcc.dg/torture/20090618-1.c Fri Mar 18 08:35:17 2011 +
+++ b/gcc/testsuite/gcc.dg/torture/20090618-1.c Fri Mar 18 10:33:59 2011 +0100
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
+/* { dg-skip-if "PR middle-end/47405" { mips-sgi-irix* } } */
 
 extern void abort (void);
 
-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH][RFC] Add gimple_fold

[Richard Guenther]

This tries to extend the previously posted CCP folding patch by
introducing a generic interface for non-tree-building, GIMPLE SSA
aware folding.  The low-level interface for folding regular
operations is

/* Fold the expression composed by *CODEP, TYPE and valueized operands 
*OP0P,
   *OP1P and *OP2P (as required), using the VALUEIZE callback to valueize
   SSA names that turn up during statement lookup and producing a result
   of at most KIND.  The folding result will be stored in the operands.
   GF_KIND_FAIL is returned if no folding was done.
   If GF_KIND_CONST or GF_KIND_VAL is returned the folding result is
   stored in *OP0P and is a is_gimple_min_invariant or a is_gimple_val.
   If GF_KIND_STMT is returned the folding result is stored in *CODEP,
   *OP0P, *OP1P and *OP2P (as required) and will compose a valid set of
   operands for a gimple assignment.
   If GF_KIND_COMPLEX is returned the folding result is stored in *OP0P
   and will be an arbitrarily complex tree.  */

enum gf_kind
gimple_fold (enum tree_code *codep, tree type,
 tree *op0p, tree *op1p, tree *op2p,
 tree (*valueize)(tree), enum gf_kind kind)

which would allow existing gimple-level foldings to build ontop of this
(including fold_stmt and friends and the special CCP foldings).

The current implementation is quite lame, just dispatching to fold,
but I plan to integrate it with the CCP and fold_stmt foldings before
considering to merge it (eventually producing some sort of statistics
of what the fold path catches that the gimple path does not).

The low-level interface needs to be amended by one for builtin calls
where I'm not sure if it is going to take decomposed operands
or just a gimple statement (I think we have at most 3 operands to
any builtin we can fold in some way).

This again is just a RFC (even though the patch "works" as far as
plugging into the SCCVN binary operation simplification).

Thanks,
Richard.



Index: gcc/gimple-fold.h
===
*** gcc/gimple-fold.h   (revision 0)
--- gcc/gimple-fold.h   (revision 0)
***
*** 0 
--- 1,39 
+ /* Gimple folding definitions.
+ 
+Copyright 2011 Free Software Foundation, Inc.
+Contributed by Richard Guenther 
+ 
+ This file is part of GCC.
+ 
+ GCC is free software; you can redistribute it and/or modify it under
+ the terms of the GNU General Public License as published by the Free
+ Software Foundation; either version 3, or (at your option) any later
+ version.
+ 
+ GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+ WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING3.  If not see
+ .  */
+ 
+ #ifndef GCC_GIMPLE_FOLD_H
+ #define GCC_GIMPLE_FOLD_H
+ 
+ #include "coretypes.h"
+ 
+ enum gf_kind {
+ GF_KIND_FAIL = 0,
+ GF_KIND_CONST,
+ GF_KIND_VAL,
+ GF_KIND_STMT,
+ GF_KIND_COMPLEX
+ };
+ 
+ enum gf_kind gimple_fold (enum tree_code *, tree,
+ tree *, tree *, tree *,
+ tree (*)(tree), enum gf_kind);
+ 
+ #endif  /* GCC_GIMPLE_FOLD_H */
Index: gcc/gimple-fold.c
===
*** gcc/gimple-fold.c   (revision 171133)
--- gcc/gimple-fold.c   (working copy)
*** along with GCC; see the file COPYING3.
*** 30,35 
--- 30,36 
  #include "tree-pass.h"
  #include "tree-ssa-propagate.h"
  #include "target.h"
+ #include "gimple-fold.h"
  
  /* Return true when DECL can be referenced from current unit.
 We can get declarations that are not possible to reference for
*** maybe_fold_or_comparisons (enum tree_cod
*** 2665,2667 
--- 2666,2914 
else
  return or_comparisons_1 (code2, op2a, op2b, code1, op1a, op1b);
  }
+ 
+ 
+ static tree
+ build_valueized_tree_from_def (tree name, tree (*valueize)(tree))
+ {
+   gimple def_stmt = SSA_NAME_DEF_STMT (name);
+   tree op0, op1, op2;
+ 
+   if (!is_gimple_assign (def_stmt)
+   || gimple_vuse (def_stmt))
+ return name;
+ 
+   switch (gimple_assign_rhs_class (def_stmt))
+ {
+ case GIMPLE_SINGLE_RHS:
+   return gimple_assign_rhs1 (def_stmt);
+ 
+ case GIMPLE_TERNARY_RHS:
+   op2 = gimple_assign_rhs3 (def_stmt);
+   if (TREE_CODE (op2) == SSA_NAME
+ && valueize)
+   op2 = (*valueize) (op2);
+ 
+ case GIMPLE_BINARY_RHS:
+   op1 = gimple_assign_rhs2 (def_stmt);
+   if (TREE_CODE (op1) == SSA_NAME
+ && valueize)
+   op1 = (*valueize) (op1);
+ 
+ case GIMPLE_UNARY_RHS:
+   op0 = gimple_assign_rhs1 (def_stmt);
+   if (TREE_CODE (op0) == SSA_NAME
+ && valueize)
+   op0 = (*valueize) (op0);
+   break;
+ 
+ default:;
+ }
+ 

Re: [testsuite] Skip gcc.dg/torture/20090618-1.c on IRIX (PR middle-end/47405)

[Richard Guenther]

On Fri, 18 Mar 2011, Rainer Orth wrote:

> As described in the PR, gcc.dg/torture/20090618-1.c fails on IRIX 5 and
> 6 due to undefined references to mempcpy, which doesn't exist in libc.
> This might be a target bug.  Richard suggested to skip the test, which
> this patch does.
> 
> Tested with the appropriate runtest invocations.  Applied to mainline
> and 4.5 branch, ok for 4.6 branch, too?

Ok.

Thanks,
Richard.

> Thanks.
>   Rainer
> 
> 
> 2011-03-17  Rainer Orth  
> 
>   PR middle-end/47405
>   * gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.
> 
> diff -r e829a5812e49 gcc/testsuite/gcc.dg/torture/20090618-1.c
> --- a/gcc/testsuite/gcc.dg/torture/20090618-1.c   Fri Mar 18 08:35:17 
> 2011 +
> +++ b/gcc/testsuite/gcc.dg/torture/20090618-1.c   Fri Mar 18 10:33:59 
> 2011 +0100
> @@ -1,5 +1,6 @@
>  /* { dg-do run } */
>  /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
> +/* { dg-skip-if "PR middle-end/47405" { mips-sgi-irix* } } */
>  
>  extern void abort (void);
>  
> 

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: [PATCH] Document --with-plugin-ld

[Richard Guenther]

On Fri, 18 Mar 2011, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> > --- 1666,1676 
> >   Enable support for link-time optimization (LTO).  This is enabled by
> >   default, and may be disabled using @option{--disable-lto}.
> >   
> > ! @item --with-plugin-ld=@var{pathname}
> > ! Enable an alternate linker to be used at link-time optimization (LTO)
> > ! link time when @option{-fuse-linker-plugin} is enabled.
> > ! This linker should have plugin support such as gold or GNU ld starting
> > ! with version 2.21.  See @option{-fuse-linker-plugin} for details.
> >   @end table
> 
> While gold already existed in binutils 2.19 (maybe earlier, haven't
> checked), plugin support only appeared in 2.20, so the references to
> gold should be qualified (also in invoke.texi).

Committed with that change.

Richard.

PATCHes for c++/48118 (accepts-invalid with volatile class), 23372 and 35315

[Jason Merrill]

48118 turned out to be caused by the patch for 23372; if we skip the 
ck_rvalue, then we never determine that there is no suitable constructor 
to use for copying from a volatile variable.  Removing that code fixes 
48118.


But that reintroduces 23372 (redundant copying of PODs on argument 
passing), so we need to fix that differently.  The best way to do that 
seems to be stripping the offending TARGET_EXPR in gimplify_arg, since 
the bug is due to a limitation of GIMPLE.


The fix for 48118 also breaks part of attrib32.C; Doug had added a bit 
to the test to check that duplicating a union in order to add 
transparent_union to a typedef worked properly, and it starts blowing up 
when we stop stripping the ck_rvalue.  But we shouldn't be duplicating 
the union in the first place, as it breaks the C++ type system; the 
point of my fix for 35315 was to support the uses of transparent_union 
in C headers without requiring that kind of duplication.  So the third 
patch disables that duplication in C++ mode; if the typedef isn't a 
naming typedef, we just ignore the attribute.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit a0880749cf975786e886c5799a67ac3ff27d606c
Author: Jason Merrill 
Date:   Fri Mar 18 10:33:03 2011 -0400

PR c++/48118
* call.c (build_over_call): Don't skip ck_rvalue.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index d040ec8..93383c6 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6168,12 +6168,6 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
 
   conv = convs[i];
 
-  /* Don't make a copy here if build_call is going to.  */
-  if (conv->kind == ck_rvalue
- && COMPLETE_TYPE_P (complete_type (type))
- && !TREE_ADDRESSABLE (type))
-   conv = conv->u.next;
-
   /* Warn about initializer_list deduction that isn't currently in the
 working draft.  */
   if (cxx_dialect > cxx98
diff --git a/gcc/testsuite/g++.dg/overload/volatile1.C 
b/gcc/testsuite/g++.dg/overload/volatile1.C
new file mode 100644
index 000..baf467d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/volatile1.C
@@ -0,0 +1,14 @@
+// PR c++/48118
+// { dg-prune-output "note" }
+
+struct A { };
+
+void f (A);// { dg-error "argument 1" }
+void (*g)(A);
+
+int main()
+{
+  volatile A a;
+  f(a);// { dg-error "no match" }
+  g(a);// { dg-error "no match" }
+}
commit 65f231e2f988d3a944712509dcaeb52c37cf6a07
Author: Jason Merrill 
Date:   Fri Mar 18 10:31:54 2011 -0400

PR c++/23372
* gimplify.c (gimplify_arg): Strip redundant TARGET_EXPR.

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 400493f..0b314a0 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2255,7 +2255,17 @@ gimplify_arg (tree *arg_p, gimple_seq *pre_p, location_t 
call_location)
   if (is_gimple_reg_type (TREE_TYPE (*arg_p)))
 test = is_gimple_val, fb = fb_rvalue;
   else
-test = is_gimple_lvalue, fb = fb_either;
+{
+  test = is_gimple_lvalue, fb = fb_either;
+  /* Also strip a TARGET_EXPR that would force an extra copy.  */
+  if (TREE_CODE (*arg_p) == TARGET_EXPR)
+   {
+ tree init = TARGET_EXPR_INITIAL (*arg_p);
+ if (init
+ && !VOID_TYPE_P (TREE_TYPE (init)))
+   *arg_p = init;
+   }
+}
 
   /* If this is a variable sized type, we must remember the size.  */
   maybe_with_size_expr (arg_p);
diff --git a/gcc/testsuite/g++.dg/opt/pr23372.C 
b/gcc/testsuite/g++.dg/opt/pr23372.C
new file mode 100644
index 000..9be4c9c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/pr23372.C
@@ -0,0 +1,15 @@
+// PR c++/23372
+// { dg-options -fdump-tree-gimple }
+
+// There shouldn't be an assignment to a temporary in the GIMPLE,
+// as that represents a redundant copy.
+// { dg-final { scan-tree-dump-not "=" gimple } }
+
+struct A {
+  int a[1000];
+  //A(A const &);
+};
+void f(A);
+void g(A *a) { f(*a); }
+
+// { dg-final { cleanup-tree-dump gimple } }
commit 459e2323d965f57f6b4ce5e8c0318b511cb8fb72
Author: Jason Merrill 
Date:   Fri Mar 18 00:33:19 2011 -0400

PR c++/35315
* c-common.c (handle_transparent_union_attribute): Don't
make a duplicate type in C++.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 6674c58..799f815 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -6152,6 +6152,7 @@ handle_transparent_union_attribute (tree *node, tree name,
   if (!(flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
{
  if (TYPE_FIELDS (type) == NULL_TREE
+ || c_dialect_cxx ()
  || TYPE_MODE (type) != DECL_MODE (TYPE_FIELDS (type)))
goto ignored;
 
diff --git a/gcc/testsuite/g++.dg/ext/attrib32.C 
b/gcc/testsuite/g++.dg/ext/attrib32.C
index 77f71de..e4dfe4e 100644
--- a/gcc/testsuite/g++.dg/ext/attrib32.C
+++ b/gcc/testsuite/g++.dg/ext/attrib32.C
@@ -10,10 +10,10 @@ void bar()
   foo(0);
 }
 
-typedef

C++ PATCH for c++/48162 (ICE on call to function pointer returning a class)

[Jason Merrill]

My assert that there wouldn't be any more wrappers around the CALL_EXPR 
was overconfident; cp_build_function_call_vec still does argument 
conversions and uses build_cxx_call, which calls build_cplus_new to wrap 
a call returning a class in TARGET_EXPR.  That should be fixed, but in 
the meantime let's not crash.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit 37e18e28dd51f50d86be4ad48075ee855bc54a13
Author: Jason Merrill 
Date:   Thu Mar 17 16:10:42 2011 -0400

PR c++/48162
* semantics.c (finish_call_expr): Allow TARGET_EXPR for now.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index b6d1008..41ab858 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2155,6 +2155,9 @@ finish_call_expr (tree fn, VEC(tree,gc) **args, bool 
disallow_virtual,
   if (TREE_CODE (result) == INDIRECT_REF)
result = TREE_OPERAND (result, 0);
   gcc_assert (TREE_CODE (result) == CALL_EXPR
+ /* FIXME cp_build_function_call_vec should avoid argument
+and return transformations like build_over_call does.  */
+ || TREE_CODE (result) == TARGET_EXPR
  || TREE_CODE (fn) == PSEUDO_DTOR_EXPR
  || errorcount);
   result = build_call_vec (TREE_TYPE (result), orig_fn, orig_args);
diff --git a/gcc/testsuite/g++.dg/template/fn-ptr1.C 
b/gcc/testsuite/g++.dg/template/fn-ptr1.C
new file mode 100644
index 000..c0e7d98
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/fn-ptr1.C
@@ -0,0 +1,5 @@
+// PR c++/48162
+
+struct A { };
+A (*f)();
+template  void g() { f(); }

[objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Diego Novillo]

I think gengtype is failing me here, but I'm not sure.  In PR 48167 we
are failing to link cc1objplus because of undefined references:

cp/parser.o:(.rodata+0x2b18): undefined reference to `gt_ggc_mx_cp_parser'
cp/parser.o:(.rodata+0x2b20): undefined reference to `gt_pch_nx_cp_parser'
cp/tree.o: In function `gt_ggc_mx_lang_tree_node':
tree.c:(.text+0xd33e): undefined reference to `gt_ggc_mx_cp_token_cache'
cp/tree.o: In function `gt_pch_nx_lang_tree_node':
tree.c:(.text+0xea2e): undefined reference to `gt_pch_nx_cp_token_cache'
cp/tree.o: In function `gt_ggc_mx_lang_decl':
tree.c:(.text+0xd23b): undefined reference to `gt_ggc_mx_cp_token_cache'
cp/tree.o: In function `gt_pch_nx_lang_decl':
tree.c:(.text+0xe923): undefined reference to `gt_pch_nx_cp_token_cache'
collect2: ld returned 1 exit status
make: *** [cc1objplus] Error 1

The problem is that those GTY functions are generated in cp/cp-lang.o,
which is not linked to cc1objplus.

The usual way of getting these functions generated is to #include the
header file in /-lang.c and add it to gtfiles in
config-lang.in (which this patch does).  However, gengtype is not
generating the functions, so I'm not sure how to make it do that.

The Obj-C++ FE is kind of weird as it shares files from cp/ and objc/,
so I'm missing some other connection I need to make to fix this.

Any ideas?


Thanks.  Diego.

diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in
index 5bbd27e..e2e0196 100644
--- a/gcc/objcp/Make-lang.in
+++ b/gcc/objcp/Make-lang.in
@@ -45,7 +45,7 @@ obj-c++: cc1objplus$(exeext)
 .PHONY: obj-c++
 
 START_HDRS = $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) 
$(CXX_TREE_H) \
-  langhooks.h c-family/c-objc.h objc/objc-act.h
+  langhooks.h c-family/c-objc.h objc/objc-act.h $(CXX_PARSER_H)
 
 # Use maximal warnings for this front end.  Also, make ObjC and C++
 # headers accessible.
diff --git a/gcc/objcp/config-lang.in b/gcc/objcp/config-lang.in
index 8c3d9c5..985da17 100644
--- a/gcc/objcp/config-lang.in
+++ b/gcc/objcp/config-lang.in
@@ -37,5 +37,5 @@ build_by_default="no"
 lang_requires="objc c++"
 subdir_requires="objc cp"
 
-gtfiles="\$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c 
\$(srcdir)/objc/objc-runtime-shared-support.c 
\$(srcdir)/objc/objc-gnu-runtime-abi-01.c 
\$(srcdir)/objc/objc-next-runtime-abi-01.c 
\$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/cp/call.c 
\$(srcdir)/cp/class.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.c 
\$(srcdir)/cp/decl2.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/method.c 
\$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c 
\$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/parser.c \$(srcdir)/cp/pt.c 
\$(srcdir)/cp/repo.c \$(srcdir)/cp/rtti.c \$(srcdir)/cp/semantics.c 
\$(srcdir)/cp/tree.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c 
\$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h 
\$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-cppbuiltin.c 
\$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c "
+gtfiles="\$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c 
\$(srcdir)/objc/objc-runtime-shared-support.c 
\$(srcdir)/objc/objc-gnu-runtime-abi-01.c 
\$(srcdir)/objc/objc-next-runtime-abi-01.c 
\$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/cp/call.c 
\$(srcdir)/cp/class.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.c 
\$(srcdir)/cp/decl2.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/method.c 
\$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/parser.h 
\$(srcdir)/cp/parser.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/pt.c 
\$(srcdir)/cp/repo.c \$(srcdir)/cp/rtti.c \$(srcdir)/cp/semantics.c 
\$(srcdir)/cp/tree.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c 
\$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h 
\$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-cppbuiltin.c 
\$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c 
\$(srcdir)/objcp/objcp-lang.c"
 
diff --git a/gcc/objcp/objcp-lang.c b/gcc/objcp/objcp-lang.c
index fe2be66..65857b5 100644
--- a/gcc/objcp/objcp-lang.c
+++ b/gcc/objcp/objcp-lang.c
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "langhooks-def.h"
 #include "target.h"
 #include "cp-objcp-common.h"
+#include "parser.h"
 
 enum c_language_kind c_language = clk_objcxx;
 static void objcxx_init_ts (void);

--
This patch is available for review at http://codereview.appspot.com/4291054

Re: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Laurynas Biveinis]

I will be able to look into this on Monday, not earlier, sorry.

2011/3/18 Diego Novillo :
> I think gengtype is failing me here, but I'm not sure.  In PR 48167 we
> are failing to link cc1objplus because of undefined references:
>
> cp/parser.o:(.rodata+0x2b18): undefined reference to `gt_ggc_mx_cp_parser'
> cp/parser.o:(.rodata+0x2b20): undefined reference to `gt_pch_nx_cp_parser'
> cp/tree.o: In function `gt_ggc_mx_lang_tree_node':
> tree.c:(.text+0xd33e): undefined reference to `gt_ggc_mx_cp_token_cache'
> cp/tree.o: In function `gt_pch_nx_lang_tree_node':
> tree.c:(.text+0xea2e): undefined reference to `gt_pch_nx_cp_token_cache'
> cp/tree.o: In function `gt_ggc_mx_lang_decl':
> tree.c:(.text+0xd23b): undefined reference to `gt_ggc_mx_cp_token_cache'
> cp/tree.o: In function `gt_pch_nx_lang_decl':
> tree.c:(.text+0xe923): undefined reference to `gt_pch_nx_cp_token_cache'
> collect2: ld returned 1 exit status
> make: *** [cc1objplus] Error 1
>
> The problem is that those GTY functions are generated in cp/cp-lang.o,
> which is not linked to cc1objplus.
>
> The usual way of getting these functions generated is to #include the
> header file in /-lang.c and add it to gtfiles in
> config-lang.in (which this patch does).  However, gengtype is not
> generating the functions, so I'm not sure how to make it do that.
>
> The Obj-C++ FE is kind of weird as it shares files from cp/ and objc/,
> so I'm missing some other connection I need to make to fix this.
>
> Any ideas?
>
>
> Thanks.  Diego.
>
> diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in
> index 5bbd27e..e2e0196 100644
> --- a/gcc/objcp/Make-lang.in
> +++ b/gcc/objcp/Make-lang.in
> @@ -45,7 +45,7 @@ obj-c++: cc1objplus$(exeext)
>  .PHONY: obj-c++
>
>  START_HDRS = $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) 
> $(CXX_TREE_H) \
> -  langhooks.h c-family/c-objc.h objc/objc-act.h
> +  langhooks.h c-family/c-objc.h objc/objc-act.h $(CXX_PARSER_H)
>
>  # Use maximal warnings for this front end.  Also, make ObjC and C++
>  # headers accessible.
> diff --git a/gcc/objcp/config-lang.in b/gcc/objcp/config-lang.in
> index 8c3d9c5..985da17 100644
> --- a/gcc/objcp/config-lang.in
> +++ b/gcc/objcp/config-lang.in
> @@ -37,5 +37,5 @@ build_by_default="no"
>  lang_requires="objc c++"
>  subdir_requires="objc cp"
>
> -gtfiles="\$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c 
> \$(srcdir)/objc/objc-runtime-shared-support.c 
> \$(srcdir)/objc/objc-gnu-runtime-abi-01.c 
> \$(srcdir)/objc/objc-next-runtime-abi-01.c 
> \$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/cp/call.c 
> \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.c 
> \$(srcdir)/cp/decl2.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/method.c 
> \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c 
> \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/parser.c \$(srcdir)/cp/pt.c 
> \$(srcdir)/cp/repo.c \$(srcdir)/cp/rtti.c \$(srcdir)/cp/semantics.c 
> \$(srcdir)/cp/tree.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c 
> \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h 
> \$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-cppbuiltin.c 
> \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c "
> +gtfiles="\$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c 
> \$(srcdir)/objc/objc-runtime-shared-support.c 
> \$(srcdir)/objc/objc-gnu-runtime-abi-01.c 
> \$(srcdir)/objc/objc-next-runtime-abi-01.c 
> \$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/cp/call.c 
> \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.c 
> \$(srcdir)/cp/decl2.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/method.c 
> \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c 
> \$(srcdir)/cp/parser.h \$(srcdir)/cp/parser.c \$(srcdir)/cp/cp-objcp-common.c 
> \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c \$(srcdir)/cp/rtti.c 
> \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/typeck2.c 
> \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h 
> \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c 
> \$(srcdir)/c-family/c-cppbuiltin.c \$(srcdir)/c-family/c-pragma.h 
> \$(srcdir)/c-family/c-pragma.c \$(srcdir)/objcp/objcp-lang.c"
>
> diff --git a/gcc/objcp/objcp-lang.c b/gcc/objcp/objcp-lang.c
> index fe2be66..65857b5 100644
> --- a/gcc/objcp/objcp-lang.c
> +++ b/gcc/objcp/objcp-lang.c
> @@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "langhooks-def.h"
>  #include "target.h"
>  #include "cp-objcp-common.h"
> +#include "parser.h"
>
>  enum c_language_kind c_language = clk_objcxx;
>  static void objcxx_init_ts (void);
>
> --
> This patch is available for review at http://codereview.appspot.com/4291054
>



-- 
Laurynas

[testsuite] Properly XFAIL gcc.dg/vect/slp-multitypes-2.c on Solaris 2/SPARC

[Rainer Orth]

I noticed that gcc.dg/vect/slp-multitypes-2.c is failing on Solaris
8/x86 with Sun as:

FAIL: gcc.dg/vect/slp-multitypes-2.c (test for excess errors)
WARNING: gcc.dg/vect/slp-multitypes-2.c compilation failed to produce executable

Excess errors:
Assembler: slp-multitypes-2.c
"/var/tmp//ccmA7WBi.s", line 16 : Illegal mnemonic
"/var/tmp//ccmA7WBi.s", line 16 : Syntax error

unpcklpd %xmm0,%xmm2

This should be dealt with by the explicit
check_vect_support_and_set_flags in vect.exp, which does

} elseif { [istarget "i?86-*-*"] || [istarget "x86_64-*-*"] } {
lappend DEFAULT_VECTCFLAGS "-msse2"
if { [check_effective_target_sse2_runtime] } {
set dg-do-what-default run
} else {
set dg-do-what-default compile
}

Unfortunately, this gets overridden by the explicit 

/* { dg-do run { xfail { sparc*-*-* && ilp32 } } } PR rtl-opt /46603 */

To fix this, I've changed the testcase to use dg-xfail-run-if instead.
Besides, I see the failure only with gas, not Sun as.

The following patch has been tested with the appropriate runtest
invocations on both i386-pc-solaris2.8 and sparc-sun-solaris2.10 (both
as and gas).

I'm about to commit this to mainline.  The 4.5 branch is unaffected, but
4.6 is.  Ok there, too, after testing?

Thanks.

Rainer


2011-03-18  Rainer Orth  

* gcc.dg/vect/slp-multitypes-2.c: Replace dg-do run with
dg-xfail-run-if.
Only xfail with gas.

diff -r eebced2eebe8 gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c
--- a/gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c  Fri Mar 18 10:52:22 
2011 +0100
+++ b/gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c  Fri Mar 18 16:58:49 
2011 +0100
@@ -1,5 +1,5 @@
 /* { dg-require-effective-target vect_int } */
-/* { dg-do run { xfail { sparc*-*-* && ilp32 } } } PR rtl-opt/46603 */
+/* { dg-xfail-run-if "PR rtl-optimization/46603" { sparc*-*-* && { ilp32 && 
gas } } } */
 
 #include 
 #include "tree-vect.h"

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

[PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Jakub Jelinek]

Hi!

The testcase below is miscompiled on x86_64-linux.
The problem is that try_head_merge_bb uses df_get_bb_dirty
to see if it can use df_get_live_out () info
(through simulate_backwards_to_point) reliably, but as at
-O1 the live problem isn't computed, only lr problem,
df_get_live_out () returns the lr out bitmap, but
df_get_bb_dirty which only looks at df_live problem always
returns false.  Thus, if the merge_bb's to compute live_union
from for can_move_insns_across has dirty lr solution caused by earlier
successful crossjumping in the same pass, we happily use its out of data
lr bitmap.

Fixed by returning if the bb has dirty lr problem if live problem
isn't computed.  df_get_bb_dirty is only used here in crossjumping and
in ifcvt, but in the latter we add the live problem at the start of
ifcvt and remove it at the end of ifcvt for -O1.

Bootstrapped/regtested on x86_64-linux, ok for trunk and 4.6.1?

While it is a wrong-code bug, I doubt many people are using
-O -fcrossjumping
options together, and -fcrossjumping is only the default for -O2+,
where live problem is added by default.

2011-03-18  Jakub Jelinek  

PR rtl-optimization/48156
* df-core.c (df_get_bb_dirty): Use df_lr if df_live is NULL.

* gcc.dg/pr48156.c: New test.

--- gcc/df-core.c.jj2010-12-14 08:11:39.0 +0100
+++ gcc/df-core.c   2011-03-18 14:22:43.0 +0100
@@ -1400,10 +1400,16 @@ df_mark_solutions_dirty (void)
 bool
 df_get_bb_dirty (basic_block bb)
 {
-  if (df && df_live)
-return bitmap_bit_p (df_live->out_of_date_transfer_functions, bb->index);
-  else
-return false;
+  if (df)
+{
+  if (df_live)
+   return bitmap_bit_p (df_live->out_of_date_transfer_functions,
+bb->index);
+  else if (df_lr)
+   return bitmap_bit_p (df_lr->out_of_date_transfer_functions,
+bb->index);
+}
+  return false;
 }
 
 
--- gcc/testsuite/gcc.dg/pr48156.c.jj   2011-03-18 14:57:34.0 +0100
+++ gcc/testsuite/gcc.dg/pr48156.c  2011-03-18 14:57:14.0 +0100
@@ -0,0 +1,45 @@
+/* PR rtl-optimization/48156 */
+/* { dg-do run } */
+/* { dg-options "-O -fcrossjumping --param min-crossjump-insns=1" } */
+
+extern void abort (void);
+
+static int __attribute__ ((noinline, noclone))
+equals (int s1, int s2)
+{
+  return s1 == s2;
+}
+
+static int __attribute__ ((noinline, noclone))
+bar (void)
+{
+  return 1;
+}
+
+static void __attribute__ ((noinline, noclone))
+baz (int f, int j)
+{
+  if (f != 4 || j != 2)
+abort ();
+}
+
+void
+foo (int x)
+{
+  int i = 0, j = bar ();
+
+  if (x == 1)
+i = 2;
+
+  if (j && equals (i, j))
+baz (8, i);
+  else
+baz (4, i);
+}
+
+int
+main ()
+{
+  foo (1);
+  return 0;
+}

Jakub

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Kenneth Zadeck]

I believe that this is not the right way to go.

if someone specifies -fcrossjumping, then the pass should turn on live 
for the duration of the pass just as ifcvt does.If they ask for 
crossjumping you should give them crossjumping and not some crippled 
version of it.


kenny



On 03/18/2011 12:13 PM, Jakub Jelinek wrote:

Hi!

The testcase below is miscompiled on x86_64-linux.
The problem is that try_head_merge_bb uses df_get_bb_dirty
to see if it can use df_get_live_out () info
(through simulate_backwards_to_point) reliably, but as at
-O1 the live problem isn't computed, only lr problem,
df_get_live_out () returns the lr out bitmap, but
df_get_bb_dirty which only looks at df_live problem always
returns false.  Thus, if the merge_bb's to compute live_union
from for can_move_insns_across has dirty lr solution caused by earlier
successful crossjumping in the same pass, we happily use its out of data
lr bitmap.

Fixed by returning if the bb has dirty lr problem if live problem
isn't computed.  df_get_bb_dirty is only used here in crossjumping and
in ifcvt, but in the latter we add the live problem at the start of
ifcvt and remove it at the end of ifcvt for -O1.

Bootstrapped/regtested on x86_64-linux, ok for trunk and 4.6.1?

While it is a wrong-code bug, I doubt many people are using
-O -fcrossjumping
options together, and -fcrossjumping is only the default for -O2+,
where live problem is added by default.

2011-03-18  Jakub Jelinek

PR rtl-optimization/48156
* df-core.c (df_get_bb_dirty): Use df_lr if df_live is NULL.

* gcc.dg/pr48156.c: New test.

--- gcc/df-core.c.jj2010-12-14 08:11:39.0 +0100
+++ gcc/df-core.c   2011-03-18 14:22:43.0 +0100
@@ -1400,10 +1400,16 @@ df_mark_solutions_dirty (void)
  bool
  df_get_bb_dirty (basic_block bb)
  {
-  if (df&&  df_live)
-return bitmap_bit_p (df_live->out_of_date_transfer_functions, bb->index);
-  else
-return false;
+  if (df)
+{
+  if (df_live)
+   return bitmap_bit_p (df_live->out_of_date_transfer_functions,
+bb->index);
+  else if (df_lr)
+   return bitmap_bit_p (df_lr->out_of_date_transfer_functions,
+bb->index);
+}
+  return false;
  }


--- gcc/testsuite/gcc.dg/pr48156.c.jj   2011-03-18 14:57:34.0 +0100
+++ gcc/testsuite/gcc.dg/pr48156.c  2011-03-18 14:57:14.0 +0100
@@ -0,0 +1,45 @@
+/* PR rtl-optimization/48156 */
+/* { dg-do run } */
+/* { dg-options "-O -fcrossjumping --param min-crossjump-insns=1" } */
+
+extern void abort (void);
+
+static int __attribute__ ((noinline, noclone))
+equals (int s1, int s2)
+{
+  return s1 == s2;
+}
+
+static int __attribute__ ((noinline, noclone))
+bar (void)
+{
+  return 1;
+}
+
+static void __attribute__ ((noinline, noclone))
+baz (int f, int j)
+{
+  if (f != 4 || j != 2)
+abort ();
+}
+
+void
+foo (int x)
+{
+  int i = 0, j = bar ();
+
+  if (x == 1)
+i = 2;
+
+  if (j&&  equals (i, j))
+baz (8, i);
+  else
+baz (4, i);
+}
+
+int
+main ()
+{
+  foo (1);
+  return 0;
+}

Jakub

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Jakub Jelinek]

On Fri, Mar 18, 2011 at 12:23:11PM -0400, Kenneth Zadeck wrote:
> I believe that this is not the right way to go.
> 
> if someone specifies -fcrossjumping, then the pass should turn on
> live for the duration of the pass just as ifcvt does.If they ask
> for crossjumping you should give them crossjumping and not some
> crippled version of it.

Such (untested) patch is in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48156#c7
But Paolo just added comment there that he prefers this version.

Is the live problem so much more useful for crossjumping than lr problem?
All it wants to prove is if it can safely move a couple of instructions
across some other instructions, and the live_union bitmap that is computed
using the live/lr problem is used to find out if registers set by the
moved instructions are actually live at the end of those instructions
or not.  What would be an example where live problem would allow optimizing
more than lr?

Jakub

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Paolo Bonzini]

On Fri, Mar 18, 2011 at 17:23, Kenneth Zadeck  wrote:
> I believe that this is not the right way to go.
>
> if someone specifies -fcrossjumping, then the pass should turn on live for
> the duration of the pass just as ifcvt does.    If they ask for crossjumping
> you should give them crossjumping and not some crippled version of it.

Then we should have both patches, but df_lr is not always being used
as a fallback for df_live, and that is a bug.

Paolo

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Michael Matz]

Hi,

On Fri, 18 Mar 2011, Kenneth Zadeck wrote:

> I believe that this is not the right way to go.
> 
> if someone specifies -fcrossjumping, then the pass should turn on live for the
> duration of the pass just as ifcvt does.If they ask for crossjumping you
> should give them crossjumping and not some crippled version of it.

OTOH the function is called df_get_bb_dirty, not 
df_get_bb_dirty_but_only_for_df_live.  So irrespective of how 
-fcrossjumping should behave with -O1 the patch seems to be a good idea.


Ciao,
Michael.

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Kenneth Zadeck]

I could be happy with both patches.

On 03/18/2011 12:25 PM, Paolo Bonzini wrote:

On Fri, Mar 18, 2011 at 17:23, Kenneth Zadeck  wrote:

I believe that this is not the right way to go.

if someone specifies -fcrossjumping, then the pass should turn on live for
the duration of the pass just as ifcvt does.If they ask for crossjumping
you should give them crossjumping and not some crippled version of it.

Then we should have both patches, but df_lr is not always being used
as a fallback for df_live, and that is a bug.

Paolo

[build] Remove unused check-consistency target in gcc/Makefile.in

[Rainer Orth]

While looking at the check-* targets, I noticed check-consistency.
Further investigation revealed that it is completely unused.  It was
introduced in 2001 as poart of the consistency.vlad testsuite (i960-only,
it seems)

2001-02-12  Geoffrey Keating  
[...]
* Makefile.in (check-consistency): New target.

which was removed in 2006 already:

2006-01-16  Ian Lance Taylor  

* consistency.vlad: Remove entire directory, 1652 files.

I've thus removed the target, installed as obvious.

Rainer


2011-03-18  Rainer Orth  

* Makefile.in (check-consistency): Remove.

Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 171152)
+++ gcc/Makefile.in (working copy)
@@ -5036,16 +5036,6 @@
fi ; \
$(RUNTEST) --tool $(check_p_tool) $(RUNTESTFLAGS) $$runtestflags)
 
-check-consistency: testsuite/site.exp
-   -rootme=`${PWD_COMMAND}`; export rootme; \
-   srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
-   cd testsuite; \
-   EXPECT=${EXPECT} ; export EXPECT ; \
-   if [ -f $${rootme}/../expect/expect ] ; then  \
-  TCL_LIBRARY=`cd .. ; cd $${srcdir}/../tcl/library ; ${PWD_COMMAND}` 
; \
-  export TCL_LIBRARY ; fi ; \
-   $(RUNTEST) --tool consistency $(RUNTESTFLAGS)
-
 # QMTest targets
 
 # The path to qmtest.


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

Re: [Patch, IRA]: Use LOCAL_REGNO in cost computation for pro/epilogue

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/22/11 07:41, Georg-Johann Lay wrote:
> This patchlet was proposed by Paolo Bonzini in
> 
> http://gcc.gnu.org/ml/gcc/2010-10/msg00427.html
> 
> Hard regs for which LOCAL_REGNO is true do not cause costs in
> prologue/epilogue because they need not to be saved/restored.
> 
> 2011-02-11  Georg-Johann Lay  
> 
>   * ira-color.c (assign_hard_reg): Honor LOCAL_REGNO in cost
>   computation for prologue/epilogue.
Vlad approved this patch here:

http://gcc.gnu.org/ml/gcc/2011-03/msg00108.html

I went ahead and installed it after a bootstrap & regression test run.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNg5C/AAoJEBRtltQi2kC71I8IAKxoWbyIF3HPGs0iqe19HXDm
jXO14Hl/olPFNt1UiXAxSL6nYiZJ/Th3Pfg4RcVhNDfGqVBJn9uxpnEKCZ0IWGO/
gyi6KL9dUMVntOGosVYZUpYF0W1A1zoZAmZ3ZPIPYpTjzP6C/g0/ztoaEO3zCXXW
/KN/6gaxBH6H+H1aoBEck3tOc92SgOde9EMIPJEoeblpavXU+EAisiFwcOow21Ww
ItwgxGQHAYnSEaaeF4ixpktPowKpZ6hAPAQaetvMJfmxs5Z1n6P9uAW9Mgx4Jkmw
UnMkIaOoKGhU064T703DmtR8TBYsGk5kLnzGd58NybkS+5tbvNWDwXfuFpMKG8U=
=hVL7
-END PGP SIGNATURE-

[libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Diego Novillo]

Paolo,

Splitting this test fixes the failures I described in
http://gcc.gnu.org/ml/libstdc++/2011-03/msg00076.html

OK for trunk?


Thanks.  Diego.

2011-03-18  Diego Novillo  

* mixed-mode_neg-1.cc: Rename from mixed-mode_neg.cc
* mixed-mode_neg-2.cc: Factor out of mixed-mode_neg-1.cc

Index: mixed-mode_neg-1.cc
===
--- mixed-mode_neg-1.cc (revision 171068)
+++ mixed-mode_neg-1.cc (working copy)
@@ -114,93 +114,5 @@ bad_lt (void)
   b6 = d < b128;   // { dg-error "error" }
 }
 
-void
-bad_le (void)
-{
-  b1 = b32 <= f;   // { dg-error "error" }
-  b2 = ld <= b32;  // { dg-error "error" }
-  b3 = b64 <= d;   // { dg-error "error" }
-  b4 = ld <= b64;  // { dg-error "error" }
-  b5 = b128 <= ld; // { dg-error "error" }
-  b6 = d <= b128;  // { dg-error "error" }
-}
-
-void
-bad_gt (void)
-{
-  b1 = b32 > f;// { dg-error "error" }
-  b2 = ld > b32;   // { dg-error "error" }
-  b3 = b64 > d;// { dg-error "error" }
-  b4 = ld > b64;   // { dg-error "error" }
-  b5 = b128 > ld;  // { dg-error "error" }
-  b6 = d > b128;   // { dg-error "error" }
-}
-
-void
-bad_ge (void)
-{
-  b1 = b32 >= f;   // { dg-error "error" }
-  b2 = ld >= b32;  // { dg-error "error" }
-  b3 = b64 >= d;   // { dg-error "error" }
-  b4 = ld >= b64;  // { dg-error "error" }
-  b5 = b128 >= ld; // { dg-error "error" }
-  b6 = d >= b128;  // { dg-error "error" }
-}
-
-void
-bad_pluseq (void)
-{
-  a32 += f;// { dg-error "error" }
-  a32 += d;// { dg-error "error" }
-  a32 += ld;   // { dg-error "error" }
-  a64 += f;// { dg-error "error" }
-  a64 += d;// { dg-error "error" }
-  a64 += ld;   // { dg-error "error" }
-  a128 += f;   // { dg-error "error" }
-  a128 += d;   // { dg-error "error" }
-  a128 += ld;  // { dg-error "error" }
-}
-
-void
-bad_minuseq (void)
-{
-  a32 -= f;// { dg-error "error" }
-  a32 -= d;// { dg-error "error" }
-  a32 -= ld;   // { dg-error "error" }
-  a64 -= f;// { dg-error "error" }
-  a64 -= d;// { dg-error "error" }
-  a64 -= ld;   // { dg-error "error" }
-  a128 -= f;   // { dg-error "error" }
-  a128 -= d;   // { dg-error "error" }
-  a128 -= ld;  // { dg-error "error" }
-}
-
-void
-bad_timeseq (void)
-{
-  a32 *= f;// { dg-error "error" }
-  a32 *= d;// { dg-error "error" }
-  a32 *= ld;   // { dg-error "error" }
-  a64 *= f;// { dg-error "error" }
-  a64 *= d;// { dg-error "error" }
-  a64 *= ld;   // { dg-error "error" }
-  a128 *= f;   // { dg-error "error" }
-  a128 *= d;   // { dg-error "error" }
-  a128 *= ld;  // { dg-error "error" }
-}
-
-void
-bad_divideeq (void)
-{
-  a32 /= f;// { dg-error "error" }
-  a32 /= d;// { dg-error "error" }
-  a32 /= ld;   // { dg-error "error" }
-  a64 /= f;// { dg-error "error" }
-  a64 /= d;// { dg-error "error" }
-  a64 /= ld;   // { dg-error "error" }
-  a128 /= f;   // { dg-error "error" }
-  a128 /= d;   // { dg-error "error" }
-  a128 /= ld;  // { dg-error "error" }
-}
 
 // { dg-excess-errors "notes about candidates" }
Index: mixed-mode_neg-2.cc
===
--- mixed-mode_neg-2.cc (revision 0)
+++ mixed-mode_neg-2.cc (revision 0)
@@ -0,0 +1,129 @@
+// Copyright (C) 2009 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do compile }
+// { dg-require-effective-target dfp }
+
+// Test that binary operators do not accept mixed decimal and generic
+// floating-point operands.  This isn't explicity prohibited in
+// ISO/IEC TR 24733 but it is prohibited in C, and in C++ there should
+// not be an implicit conversion from a decimal floating-point type to
+// a generic floating-point type.
+
+#include 
+#include 
+
+using namespace std::decimal;
+
+decimal32 a32, b32, c32;
+decimal64 a64, b64, c64;
+decimal128 a128, b128, c128;
+float f;
+double d;
+long double ld;
+bool b1, b2, b3, b4, b5, b

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Paolo Carlini]

On 03/18/2011 06:16 PM, dnovi...@google.com wrote:

Paolo,

Splitting this test fixes the failures I described in
http://gcc.gnu.org/ml/libstdc++/2011-03/msg00076.html

OK for trunk?
Sure, it's Ok. A nit, however: we have been using quite consistently the 
*_neg suffix for such kind of testcases, I think mixed-mode-1_neg.cc and 
mixed-mode-2_neg.cc are better names.


Paolo.

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Diego Novillo]

On Fri, Mar 18, 2011 at 13:23, Paolo Carlini  wrote:
> On 03/18/2011 06:16 PM, dnovi...@google.com wrote:
>>
>> Paolo,
>>
>> Splitting this test fixes the failures I described in
>> http://gcc.gnu.org/ml/libstdc++/2011-03/msg00076.html
>>
>> OK for trunk?
>
> Sure, it's Ok. A nit, however: we have been using quite consistently the
> *_neg suffix for such kind of testcases, I think mixed-mode-1_neg.cc and
> mixed-mode-2_neg.cc are better names.

Will do.  Thanks.


Diego.

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Paolo Carlini]

On 03/18/2011 06:29 PM, Diego Novillo wrote:

Will do.  Thanks.
Sorry again - otherwise I have to do it myself anyway: why don't you 
split it a more meaningful way, like splitting out all the comparisons? 
That would avoid the naming issue in the first place.


Thanks,
Paolo.

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Diego Novillo]

On Fri, Mar 18, 2011 at 13:31, Paolo Carlini  wrote:
> On 03/18/2011 06:29 PM, Diego Novillo wrote:
>>
>> Will do.  Thanks.
>
> Sorry again - otherwise I have to do it myself anyway: why don't you split
> it a more meaningful way, like splitting out all the comparisons? That would
> avoid the naming issue in the first place.

I can split it any way you prefer.  You mean create 14 files?  Or two
files, one with all the bad_ another with the bad_ ?


Diego.

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Paolo Carlini]

On 03/18/2011 06:34 PM, Diego Novillo wrote:

I can split it any way you prefer. You mean create 14 files? Or two
files, one with all the bad_  another with the bad_  ?
Please split out the comparisons and create mixed-mode-comp_neg.cc, 
rename the existing file as mixed-mode-arith_neg.cc.


Paolo.

[Committed] S/390: Don't split litpool between call and call_arg_location note

[Andreas Krebbel]

Hi,

java bootstrap currently fails on s390 with:

/build3/gcc-head/libjava/classpath/javax/swing/plaf/basic/BasicLookAndFeel.java:1649:0:
 internal compiler error: in 
dwarf2out_var_location, at dwarf2out.c:21972
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The problem is that a literal pool split happens just between a call
insn and the NOTE_INSN_CALL_ARG_LOCATION following it.  dwarf2out
currently expects the call insn to be found just one insn before.

The attached patch makes sure that we never split at such a location.

With the patch java bootstrap gets a bit further and then fails due to
delegitimize_address still returning UNSPECs :( but that's a different
story.

Committed to mainline.

Bye,

-Andreas-


2011-03-18  Andreas Krebbel  

* config/s390/s390.c (s390_chunkify_start): Prevent literal pool
splitting between a call and its corresponding CALL_ARG_LOCATION
note.


Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** s390_chunkify_start (void)
*** 6651,6657 
  s390_add_execute (curr_pool, insn);
  s390_add_pool_insn (curr_pool, insn);
}
!   else if (GET_CODE (insn) == INSN || GET_CODE (insn) == CALL_INSN)
{
  rtx pool_ref = NULL_RTX;
  find_constant_pool_ref (PATTERN (insn), &pool_ref);
--- 6651,6657 
  s390_add_execute (curr_pool, insn);
  s390_add_pool_insn (curr_pool, insn);
}
!   else if (GET_CODE (insn) == INSN || CALL_P (insn))
{
  rtx pool_ref = NULL_RTX;
  find_constant_pool_ref (PATTERN (insn), &pool_ref);
*** s390_chunkify_start (void)
*** 6676,6681 
--- 6676,6690 
  pending_ltrel = pool_ref;
}
}
+ /* Make sure we do not split between a call and its
+corresponding CALL_ARG_LOCATION note.  */
+ if (CALL_P (insn))
+   {
+ rtx next = NEXT_INSN (insn);
+ if (next && NOTE_P (next)
+ && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
+   continue;
+   }
}
  
if (GET_CODE (insn) == JUMP_INSN || GET_CODE (insn) == CODE_LABEL)

[Committed] S/390: Handle GOTOFF unspecs in delegitimize_address

[Andreas Krebbel]

Hi,

the attached patch adds handling for GOTOFF unspecs to
delegitimize_address.

A lot of "note: non-delegitimized UNSPEC 112" messages disappear with
this.  However not all of them.

Committed to mainline.

Bye,

-Andreas-


2011-03-18  Andreas Krebbel  

* config/s390/s390.c (s390_delegitimize_address): Handle GOTOFF
unspecs.


Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** s390_delegitimize_address (rtx orig_x)
*** 5015,5020 
--- 5015,5037 
  
orig_x = delegitimize_mem_from_attrs (orig_x);
x = orig_x;
+ 
+   /* Extract the symbol ref from:
+  (plus:SI (reg:SI 12 %r12)
+   (const:SI (unspec:SI [(symbol_ref/f:SI ("*.LC0"))]
+   UNSPEC_GOTOFF)))  */
+   if (GET_CODE (x) == PLUS
+   && REG_P (XEXP (x, 0))
+   && REGNO (XEXP (x, 0)) == PIC_OFFSET_TABLE_REGNUM
+   && GET_CODE (XEXP (x, 1)) == CONST)
+ {
+   /* The const operand.  */
+   y = XEXP (XEXP (x, 1), 0);
+   if (GET_CODE (y) == UNSPEC
+ && XINT (y, 1) == UNSPEC_GOTOFF)
+   return XVECEXP (y, 0, 0);
+ }
+ 
if (GET_CODE (x) != MEM)
  return orig_x;
  

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Paolo Bonzini]

On Fri, Mar 18, 2011 at 17:31, Jakub Jelinek  wrote:
> On Fri, Mar 18, 2011 at 12:23:11PM -0400, Kenneth Zadeck wrote:
>> I believe that this is not the right way to go.
>>
>> if someone specifies -fcrossjumping, then the pass should turn on
>> live for the duration of the pass just as ifcvt does.    If they ask
>> for crossjumping you should give them crossjumping and not some
>> crippled version of it.
>
> Such (untested) patch is in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48156#c7
> But Paolo just added comment there that he prefers this version.
>
> Is the live problem so much more useful for crossjumping than lr problem?
> All it wants to prove is if it can safely move a couple of instructions
> across some other instructions, and the live_union bitmap that is computed
> using the live/lr problem is used to find out if registers set by the
> moved instructions are actually live at the end of those instructions
> or not.  What would be an example where live problem would allow optimizing
> more than lr?

LIVE == LR except when you have uninitialized uses.

Unless it is needed for correctness, I see no reason to prefer LIVE to
LR at -O1.

Paolo

Re: [DOC PATCH] 4.6 branching changes

[Joseph S. Myers]

On Mon, 14 Mar 2011, Jakub Jelinek wrote:

> --- c99status.html6 Apr 2010 11:34:44 -   1.55
> +++ c99status.html14 Mar 2011 13:52:00 -  1.56
> @@ -21,6 +21,7 @@ paragraph 6) do not count as library iss
>  
>  This page describes the C99 support in mainline GCC, not in any
>  particular release.  Information is also available on  +href="gcc-4.6/c99status.html">C99 support in GCC 4.5, This page describes the C99 support in mainline GCC, not in any
 particular release.  Information is also available on C99 support in GCC 4.5, C99 support in GCC 4.6, C99 support in GCC 4.5, C99 support in GCC 4.4, C99 support in GCC 4.3, 

[PATCH,committed] Update config.guess and config.sub

[David Edelsohn]

I have imported the latest config.guess and config.sub from upstream
repository and committed to both GCC Subversion repository and SRC CVS
repository.  Among other changes, this allows configure to recognize
AIX 7.1.

* config.guess: Update to version 2011-02-02
* config.sub: Update to version 2011-02-24

diff -uw attached to avoid many gratuitous white space changes.

This probably is too late for GCC 4.6, but should be backported to GCC 4.6.1.

David


config-diff
Description: Binary data

RE: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Nicola Pero]

> The Obj-C++ FE is kind of weird as it shares files from cp/ and objc/,
> so I'm missing some other connection I need to make to fix this.
>
> Any ideas?

As far as I can see, the problem is that header files (such as cp/parser.h)
generate GC stuff that gets put into gtype-{lang}.h, where {lang} is determined
by looking at the directory where the file is (eg, if it's in the cp/ directory,
then {lang} is cp) ... unless you override this with a custom hardcoded rule in
gengtype.c.

It seems that all files that are shared between ObjC or C++ and ObjC++ have 
custom
hardcoded rules in gengtype.c.  The cp/parser.h file you added didn't, and 
without
it, every time it is processed, the results are stored in gtype-cp.h even if the
file is processed for ObjC++. :-(

This all looks ugly.  Anyhow, until someone refactors everything, the following
patch fixes ObjC++ bootstrap in trunk by processing cp/parser.h in the same way
as the other C++ headers are processed. :-)

Ok to commit ?

Thanks

Index: gcc/gengtype.c
===
--- gcc/gengtype.c  (revision 171155)
+++ gcc/gengtype.c  (working copy)
@@ -1761,6 +1761,12 @@
matters, so change with extreme care!  */
 
 struct file_rule_st files_rules[] = {
+  /* The general rule assumes that files in subdirectories belong to a
+ particular front-end, and files not in subdirectories are shared.
+ The following rules deal with exceptions - files that are in
+ subdirectories and yet are shared, and files that are top-level,
+ but are not shared.  */
+
   /* the c-family/ source directory is special.  */
   { DIR_PREFIX_REGEX "c-family/([[:alnum:]_-]*)\\.c$",
 REG_EXTENDED, NULL_REGEX,
@@ -1792,7 +1798,12 @@
 REG_EXTENDED, NULL_REGEX,
 "gt-cp-name-lookup.h", "cp/name-lookup.c", NULL_FRULACT },
 
-  /* objc/objc-act.h fives gt-objc-objc-act.h for objc/objc-act.c !  */
+  /* cp/parser.h gives gt-cp-parser.h for cp/parser.c !  */
+  { DIR_PREFIX_REGEX "cp/parser\\.h$",
+REG_EXTENDED, NULL_REGEX,
+"gt-cp-parser.h", "cp/parser.c", NULL_FRULACT },
+
+  /* objc/objc-act.h gives gt-objc-objc-act.h for objc/objc-act.c !  */
   { DIR_PREFIX_REGEX "objc/objc-act\\.h$",
 REG_EXTENDED, NULL_REGEX,
 "gt-objc-objc-act.h", "objc/objc-act.c", NULL_FRULACT },
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 171155)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2011-03-18  Nicola Pero  
+
+   * gengtype.c (files_rules): Added rule for cp/parser.h.
+
 2011-03-18  Maxim Kuvyrkov  
 
PR rtl-optimization/48170
Index: gcc/objcp/Make-lang.in
===
--- gcc/objcp/Make-lang.in  (revision 171155)
+++ gcc/objcp/Make-lang.in  (working copy)
@@ -45,7 +45,7 @@
 .PHONY: obj-c++
 
 START_HDRS = $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) 
$(CXX_TREE_H) \
-  langhooks.h c-family/c-objc.h objc/objc-act.h
+  $(CXX_PARSER_H) $(CXX_PRETTY_PRINT_H) langhooks.h c-family/c-objc.h 
objc/objc-act.h
 
 # Use maximal warnings for this front end.  Also, make ObjC and C++
 # headers accessible.
@@ -78,7 +78,7 @@
 
 objcp/objcp-lang.o : objcp/objcp-lang.c $(START_HDRS) \
   $(C_COMMON_H) $(LANGHOOKS_DEF_H) cp/cp-objcp-common.h \
-  $(TARGET_H) gtype-objcp.h 
+  $(TARGET_H) gtype-objcp.h
 
 objcp/objcp-decl.o : objcp/objcp-decl.c \
$(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(CXX_TREE_H) \
Index: gcc/objcp/ChangeLog
===
--- gcc/objcp/ChangeLog (revision 171155)
+++ gcc/objcp/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2011-03-17  Nicola Pero  
+
+   * Make-lang.in (START_HDRS): Added CXX_PARSER_H and
+   CXX_PRETTY_PRINT_H.
+   * config-lang.in (gtfiles): Added cp/parser.h and reorganized list
+   so that it is more obvious that it is identical to the C++ one
+   with the addition of some files at the end.
+   
 2011-03-06  Joseph Myers  
 
* lang-specs.h: Match -save-temps* instead of -save-temps.
Index: gcc/objcp/config-lang.in
===
--- gcc/objcp/config-lang.in(revision 171155)
+++ gcc/objcp/config-lang.in(working copy)
@@ -37,5 +37,14 @@
 lang_requires="objc c++"
 subdir_requires="objc cp"
 
-gtfiles="\$(srcdir)/objc/objc-act.h \$(srcdir)/objc/objc-act.c 
\$(srcdir)/objc/objc-runtime-shared-support.c 
\$(srcdir)/objc/objc-gnu-runtime-abi-01.c 
\$(srcdir)/objc/objc-next-runtime-abi-01.c 
\$(srcdir)/objc/objc-next-runtime-abi-02.c \$(srcdir)/cp/call.c 
\$(srcdir)/cp/class.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.c 
\$(srcdir)/cp/decl2.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/method.c 
\$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c 
\$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/parser.c \$(srcdir)/cp/pt.c 
\$(srcdir)/cp/repo.c \$(srcdir)/cp/rtti.c \$(s

Re: C++0x PATCH to add -fconstexpr-depth

[Joseph S. Myers]

On Tue, 15 Mar 2011, Jason Merrill wrote:

> +/* Likewise, for constexpr function call evaluations.  N3225 specifies a
> +   minimum of 512.  */
>  
> +int max_constexpr_depth = 512;

Since all you're doing in the option handler is setting a global variable, 
it's better to declare the option in the .opt file with 
Var(max_constexpr_depth) Init(512).  Then you don't need to define the 
variable manually in c-common.c or declare it in c-common.h or have any 
handler code for it in c-opts.c.

> +fconstexpr-depth=
> +C++ ObjC++ Joined RejectNegative UInteger
> +-constexpr-depth=Specify maximum constexpr recursion depth

Typo in the help text: it's -fconstexpr-depth not -constexpr-depth.

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

Re: [Patch][AVR]: Support tail calls

[Denis Chertykov]

2011/3/18 Georg-Johann Lay :

>> Is it tested for regressions ?
>>
>> Denis.
>
> I ran tests against svn 170942 (latest 4.7.0 snapshot). Besides
> timestamps, the diff looks like this:
>
> 1435a1436,1437
>> XPASS: gcc.dg/sibcall-3.c execution test
>> XPASS: gcc.dg/sibcall-4.c execution test
> 1630,1631c1632,1633
> < # of unexpected successes     4
> < # of expected failures                132
> ---
>> # of unexpected successes     6
>> # of expected failures                130
> 1670c1672
>
> This is due to xfail for runtime-test of sibcall abilities for avr-*-*.
>


So, the patch can be committed.
Please, prepare the final version of the patch.

Denis.

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Jakub Jelinek]

On Fri, Mar 18, 2011 at 06:45:57PM +0100, Paolo Bonzini wrote:
> > Is the live problem so much more useful for crossjumping than lr problem?
> > All it wants to prove is if it can safely move a couple of instructions
> > across some other instructions, and the live_union bitmap that is computed
> > using the live/lr problem is used to find out if registers set by the
> > moved instructions are actually live at the end of those instructions
> > or not.  What would be an example where live problem would allow optimizing
> > more than lr?
> 
> LIVE == LR except when you have uninitialized uses.
> 
> Unless it is needed for correctness, I see no reason to prefer LIVE to
> LR at -O1.

So, looking at some rtl dumps with uninitialized vars at -O2, I see
that LR out is either the same as LIVE out, or contains some extra regs
(the uninitialized ones).  But this all is at the end of a bb
which contains insns that set those registers (can_move_insns_across
is only interested in test_set registers from the merge_live bitmap).
Thus I believe it is fine both for corectness and even generated code
quality to just use LR (i.e. LIVE vs. LR should make no difference
on the crossjumping).

That said, I'm currently also bootstrapping/regtesting following patch
just in case:

2011-03-18  Jakub Jelinek  

PR rtl-optimization/48156
* combine-stack-adj.c (rest_of_handle_stack_adjustments): Compute live
problem if flag_crossjumping && optimize <= 1.

--- gcc/combine-stack-adj.c.jj  2010-12-02 11:51:32.0 +0100
+++ gcc/combine-stack-adj.c 2011-03-18 18:02:04.0 +0100
@@ -551,7 +551,16 @@ gate_handle_stack_adjustments (void)
 static unsigned int
 rest_of_handle_stack_adjustments (void)
 {
-  cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
+  if (flag_crossjumping && optimize <= 1)
+{
+  df_live_add_problem ();
+  df_live_set_all_dirty ();
+  df_analyze ();
+  cleanup_cfg (CLEANUP_CROSSJUMP);
+  df_remove_problem (df_live);
+}
+  else
+cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
 
   /* This is kind of a heuristic.  We need to run combine_stack_adjustments
  even for machines with possibly nonzero TARGET_RETURN_POPS_ARGS


Jakub

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

[Kenneth Zadeck]

i see your point.I had forgotten that crossjumping is not really a 
pass, it is more of an infectious agent.


On 03/18/2011 01:45 PM, Paolo Bonzini wrote:

On Fri, Mar 18, 2011 at 17:31, Jakub Jelinek  wrote:

On Fri, Mar 18, 2011 at 12:23:11PM -0400, Kenneth Zadeck wrote:

I believe that this is not the right way to go.

if someone specifies -fcrossjumping, then the pass should turn on
live for the duration of the pass just as ifcvt does.If they ask
for crossjumping you should give them crossjumping and not some
crippled version of it.

Such (untested) patch is in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48156#c7
But Paolo just added comment there that he prefers this version.

Is the live problem so much more useful for crossjumping than lr problem?
All it wants to prove is if it can safely move a couple of instructions
across some other instructions, and the live_union bitmap that is computed
using the live/lr problem is used to find out if registers set by the
moved instructions are actually live at the end of those instructions
or not.  What would be an example where live problem would allow optimizing
more than lr?

LIVE == LR except when you have uninitialized uses.

Unless it is needed for correctness, I see no reason to prefer LIVE to
LR at -O1.

yes, but i think that the reason this is a pr is that it seems to be 
needed for correctness.
i certainly am not advocating using live at O1.it is more 
expensive.however, we do have the ability to turn on some problem 
only in one pass, and that was what i was suggesting.   you make 
crossjumping require LIVE, and you will get LIVE for that pass, not for 
the entire compilation.

Paolo

Re: RFA: fix PR c/48116

[Joseph S. Myers]

On Wed, 16 Mar 2011, Tom Tromey wrote:

> It seems ok to me to accept it as a GNU extension.
> But, it still doesn't warn with -std=c89 or -std=c99.
> -pedantic seems too heavy for this, to me.

It is not the function of -std to enable diagnostics for extensions; 
that's the function of -pedantic.  This (returning void expressions from a 
function returning void) is an extension that's standard in C++; it should 
probably be documented as an extension in GNU C if it isn't already 
documented.

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

Re: [PATCH][C] Fix PR47939

[Joseph S. Myers]

On Fri, 18 Mar 2011, Richard Guenther wrote:

> > What I think is safe in grokdeclarator is using TYPE_MAIN_VARIANT here if 
> > *either* the type given in the declaration specifiers is an array type 
> > (TREE_CODE (type) == ARRAY_TYPE, as in your previous patch) *or* the first 
> > declarator that is not cdk_attrs is cdk_array (as in this version, but 
> > checking through a chain of declarator->declarator to find a possible 
> > cdk_array after a sequence of cdk_attrs).
> > 
> > (Aside from all this it is a longstanding known bug that the debug 
> > information for arrays of qualified types isn't quite right: PR 8354.)
> 
> Ok, the following works for me.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

This patch version is OK.

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

Re: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Basile Starynkevitch]

On Fri, 18 Mar 2011 18:59:47 +0100 (CET)
"Nicola Pero"  wrote:

> 
> > The Obj-C++ FE is kind of weird as it shares files from cp/ and objc/,
> > so I'm missing some other connection I need to make to fix this.
> 
> This all looks ugly.  Anyhow, until someone refactors everything, the 
> following
> patch fixes ObjC++ bootstrap in trunk by processing cp/parser.h in the same 
> way
> as the other C++ headers are processed. :-)
> 
> Ok to commit ?


I don't have authority to Ok, but I find your patch nice (and I believe
that it illustrates the fact that adding some regexp rules to gengtype
was a good idea).

Regards!
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Diego Novillo]

On 03/18/2011 01:35 PM, Paolo Carlini wrote:

On 03/18/2011 06:34 PM, Diego Novillo wrote:

I can split it any way you prefer. You mean create 14 files? Or two
files, one with all the bad_ another with the bad_ ?

Please split out the comparisons and create mixed-mode-comp_neg.cc,
rename the existing file as mixed-mode-arith_neg.cc.

Paolo.



Like this?  Tested on my insanely deep tree and on mainline on x86_64.


Thanks.  Diego.

2011-03-18  Diego Novillo  

* mixed-mode-arith_neg.cc: Rename from mixed-mode_neg.cc
* mixed-mode-cmp_neg.cc: Factor out of mixed-mode-arith_neg.cc

diff --git a/libstdc++-v3/testsuite/decimal/mixed-mode-arith_neg.cc 
b/libstdc++-v3/testsuite/decimal/mixed-mode-arith_neg.cc

new file mode 100644
index 000..5cc67fb
--- /dev/null
+++ b/libstdc++-v3/testsuite/decimal/mixed-mode-arith_neg.cc
@@ -0,0 +1,140 @@
+// Copyright (C) 2009 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do compile }
+// { dg-require-effective-target dfp }
+
+// Test that binary arithmetic operators do not accept mixed decimal
+// and generic floating-point operands.  This isn't explicity
+// prohibited in ISO/IEC TR 24733 but it is prohibited in C, and in C++
+// there should not be an implicit conversion from a decimal
+// floating-point type to a generic floating-point type.
+
+#include 
+#include 
+
+using namespace std::decimal;
+
+decimal32 a32, b32, c32;
+decimal64 a64, b64, c64;
+decimal128 a128, b128, c128;
+float f;
+double d;
+long double ld;
+bool b1, b2, b3, b4, b5, b6;
+
+void
+bad_add (void)
+{
+  a32 = b32 + f;   // { dg-error "error" }
+  a32 = ld + b32;  // { dg-error "error" }
+  a64 = b64 + d;   // { dg-error "error" }
+  a64 = ld + b64;  // { dg-error "error" }
+  a128 = b128 + ld;// { dg-error "error" }
+  a128 = d + b128; // { dg-error "error" }
+}
+
+void
+bad_subtract (void)
+{
+  a32 = b32 - f;   // { dg-error "error" }
+  a32 = ld - b32;  // { dg-error "error" }
+  a64 = b64 - d;   // { dg-error "error" }
+  a64 = ld - b64;  // { dg-error "error" }
+  a128 = b128 - ld;// { dg-error "error" }
+  a128 = d - b128; // { dg-error "error" }
+}
+
+void
+bad_multiply (void)
+{
+  a32 = b32 * f;   // { dg-error "error" }
+  a32 = ld * b32;  // { dg-error "error" }
+  a64 = b64 * d;   // { dg-error "error" }
+  a64 = ld * b64;  // { dg-error "error" }
+  a128 = b128 * ld;// { dg-error "error" }
+  a128 = d * b128; // { dg-error "error" }
+}
+
+void
+bad_divide (void)
+{
+  a32 = b32 / f;   // { dg-error "error" }
+  a32 = ld / b32;  // { dg-error "error" }
+  a64 = b64 / d;   // { dg-error "error" }
+  a64 = ld / b64;  // { dg-error "error" }
+  a128 = b128 / ld;// { dg-error "error" }
+  a128 = d / b128; // { dg-error "error" }
+}
+
+void
+bad_pluseq (void)
+{
+  a32 += f;// { dg-error "error" }
+  a32 += d;// { dg-error "error" }
+  a32 += ld;   // { dg-error "error" }
+  a64 += f;// { dg-error "error" }
+  a64 += d;// { dg-error "error" }
+  a64 += ld;   // { dg-error "error" }
+  a128 += f;   // { dg-error "error" }
+  a128 += d;   // { dg-error "error" }
+  a128 += ld;  // { dg-error "error" }
+}
+
+void
+bad_minuseq (void)
+{
+  a32 -= f;// { dg-error "error" }
+  a32 -= d;// { dg-error "error" }
+  a32 -= ld;   // { dg-error "error" }
+  a64 -= f;// { dg-error "error" }
+  a64 -= d;// { dg-error "error" }
+  a64 -= ld;   // { dg-error "error" }
+  a128 -= f;   // { dg-error "error" }
+  a128 -= d;   // { dg-error "error" }
+  a128 -= ld;  // { dg-error "error" }
+}
+
+void
+bad_timeseq (void)
+{
+  a32 *= f;// { dg-error "error" }
+  a32 *= d;// { dg-error "error" }
+  a32 *= ld;   // { dg-error "error" }
+  a64 *= f;// { dg-error "error" }
+  a64 *= d;// { dg-error "error" }
+  a64 *= ld;   // { dg-error "error" }
+  a128 *= f;   // { dg-error "error" }
+  a128 *= d;   // { dg-error "error" }
+  a128 *= ld;  // { dg-error "error" }
+}
+
+void
+bad_divideeq (void)
+{
+  a32 /= f;// { dg-error "erro

Re: 4.7 deprecated targets removal patch

[Ralf Wildenhues]

Hello Joseph,

* Joseph S. Myers wrote on Fri, Mar 18, 2011 at 12:12:09PM CET:
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?

The build system changes look OK from a build system technical POV,
with a couple of comments below.

> 2011-03-17  Joseph Myers  
> 
>   * MAINTAINERS (crx port, m68hc11 port): Remove.  Move maintainers
>   to Write After Approval.
>   * config-ml.in: Don't handle arc-*-elf*.
>   * configure.ac (arc-*-*, crx-*-*, i[[3456789]]86-*-pe,
>   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*, mcore-*-pe*): Don't
>   handle GCC libraries.
>   * configure: Regenerate.
[...]

> --- config-ml.in  (revision 171107)
> +++ config-ml.in  (working copy)

I'll merge this change to Automake in your name, once you've committed
it to GCC and src.

> @@ -2,7 +2,7 @@
>  # wanting multilib support.
>  #
>  # Copyright (C) 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
> -# 2005, 2006, 2007, 2008, 2010  Free Software Foundation, Inc.
> +# 2005, 2006, 2007, 2008, 2010, 2011  Free Software Foundation, Inc.
>  #
>  # This file is free software; you can redistribute it and/or modify
>  # it under the terms of the GNU General Public License as published by
> @@ -224,19 +224,6 @@ done
>  # $host here, not $target.
>  
>  case "${host}" in
> -arc-*-elf*)
> - if [ x$enable_biendian != xyes ]
> - then
> -   old_multidirs=${multidirs}
> -   multidirs=""
> -   for x in ${old_multidirs}; do
> - case "${x}" in
> -   *be*) : ;;
> -   *) multidirs="${multidirs} ${x}" ;;
> - esac
> -   done
> - fi
> - ;;
>  arm-*-*)
>   if [ x"$enable_fpu" = xno ]
>   then

> --- configure.ac  (revision 171107)
> +++ configure.ac  (working copy)
> @@ -670,7 +670,7 @@ case "${target}" in
>  libgloss_dir=wince
>  ;;
>arc-*-*)
> -noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
> +noconfigdirs="$noconfigdirs target-libgloss"
>  ;;
>arm-semi-aof )
>  ;;
> @@ -744,7 +744,6 @@ case "${target}" in
>  libgloss_dir=cris
>  ;;
>crx-*-*)
> -noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap ${libgcj}"
>  ;;

Why not also remove the line before and after this one?
Is that because crx is still supported in binutils or other
src projects?  If yes, the hunk is fine, but then I wonder
whether it is too early to drop the config-ml.in bits for src.

>d10v-*-*)
>  noconfigdirs="$noconfigdirs target-libstdc++-v3 target-libgloss 
> ${libgcj}"
> @@ -862,7 +861,7 @@ case "${target}" in
>i[[3456789]]86-*-uwin* | i[[3456789]]86-*-interix* )
>  ;;
>i[[3456789]]86-*-pe)
> -noconfigdirs="$noconfigdirs target-libstdc++-v3 target-libgloss 
> ${libgcj}"
> +noconfigdirs="$noconfigdirs target-libgloss"
>  ;;
>i[[3456789]]86-*-sco3.2v5*)
>  # The linker does not yet know about weak symbols in COFF,
> @@ -888,7 +887,7 @@ case "${target}" in
>  noconfigdirs="$noconfigdirs ${libgcj}"
>  ;;
>m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
> -noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 
> ${libgcj}"
> +noconfigdirs="$noconfigdirs target-libiberty"
>  libgloss_dir=m68hc11
>  ;;
>m68k-*-elf*)
> @@ -901,9 +900,6 @@ case "${target}" in
>  libgloss_dir=m68k
>  ;;
>mcore-*-pe*)
> -  # The EPOC C++ environment does not support exceptions or rtti,
> -  # and so building libstdc++-v3 tends not to always work.
> -noconfigdirs="$noconfigdirs target-libstdc++-v3"
>  ;;

Likewise.

>mmix-*-*)
>  noconfigdirs="$noconfigdirs target-libffi target-boehm-gc gdb libgloss"

Thanks,
Ralf

Re: 4.7 deprecated targets removal patch

[Joseph S. Myers]

On Fri, 18 Mar 2011, Ralf Wildenhues wrote:

> > @@ -744,7 +744,6 @@ case "${target}" in
> >  libgloss_dir=cris
> >  ;;
> >crx-*-*)
> > -noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap 
> > ${libgcj}"
> >  ;;
> 
> Why not also remove the line before and after this one?
> Is that because crx is still supported in binutils or other
> src projects?  If yes, the hunk is fine, but then I wonder
> whether it is too early to drop the config-ml.in bits for src.

Yes, it is still supported in binutils - and the general reason for not 
removing the empty cases is that there are plenty of such cases already 
there, some for truly ancient targets.  It seems quite likely that some of 
the targets mentioned at toplevel actually have no useful support anywhere 
in gcc or src and that all of those target cases should be reviewed for 
usefulness and correctness.  (There are also lots of cases for "canonical 
aliases" that have been deprecated and removed from GCC - that is, names 
that should be aliases but that config.sub treats as canonical and so 
cause problems because of needing duplication in case statements etc. 
everywhere.  In those cases it probably makes sense to remove support for 
the duplicate names in src, along maybe with making config.sub convert 
them to canonical form.  i?86-*-pe as an alias for Cygwin is an example in 
the present patch; various such aliases were obsoleted in 4.3 as well, but 
support for "thumb-*" targets was obsolete long before the other ARM 
aliases obsoleted in 4.3.)

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

Re: [libstdc++] Split testsuite/decimal/mixed-mode_neg.cc (issue4273077)

[Paolo Carlini]

Hi,

> Like this?  Tested on my insanely deep tree and on mainline on x86_64.

Sure.

Thanks,
Paolo

Re: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Diego Novillo]

On Fri, Mar 18, 2011 at 13:59, Nicola Pero
 wrote:
>
>> The Obj-C++ FE is kind of weird as it shares files from cp/ and objc/,
>> so I'm missing some other connection I need to make to fix this.
>>
>> Any ideas?
>
> As far as I can see, the problem is that header files (such as cp/parser.h)
> generate GC stuff that gets put into gtype-{lang}.h, where {lang} is 
> determined
> by looking at the directory where the file is (eg, if it's in the cp/ 
> directory,
> then {lang} is cp) ... unless you override this with a custom hardcoded rule 
> in
> gengtype.c.

Oh!  That's what I was missing.  Thanks for the fix.

>
> It seems that all files that are shared between ObjC or C++ and ObjC++ have 
> custom
> hardcoded rules in gengtype.c.  The cp/parser.h file you added didn't, and 
> without
> it, every time it is processed, the results are stored in gtype-cp.h even if 
> the
> file is processed for ObjC++. :-(

Ugh.

> This all looks ugly.  Anyhow, until someone refactors everything, the 
> following
> patch fixes ObjC++ bootstrap in trunk by processing cp/parser.h in the same 
> way
> as the other C++ headers are processed. :-)
>
> Ok to commit ?
>
> Thanks
>
> Index: gcc/gengtype.c
> ===
> --- gcc/gengtype.c      (revision 171155)
> +++ gcc/gengtype.c      (working copy)
> @@ -1761,6 +1761,12 @@
>    matters, so change with extreme care!  */
>
>  struct file_rule_st files_rules[] = {
> +  /* The general rule assumes that files in subdirectories belong to a
> +     particular front-end, and files not in subdirectories are shared.
> +     The following rules deal with exceptions - files that are in
> +     subdirectories and yet are shared, and files that are top-level,
> +     but are not shared.  */
> +
>   /* the c-family/ source directory is special.  */
>   { DIR_PREFIX_REGEX "c-family/([[:alnum:]_-]*)\\.c$",
>     REG_EXTENDED, NULL_REGEX,
> @@ -1792,7 +1798,12 @@
>     REG_EXTENDED, NULL_REGEX,
>     "gt-cp-name-lookup.h", "cp/name-lookup.c", NULL_FRULACT },
>
> -  /* objc/objc-act.h fives gt-objc-objc-act.h for objc/objc-act.c !  */
> +  /* cp/parser.h gives gt-cp-parser.h for cp/parser.c !  */
> +  { DIR_PREFIX_REGEX "cp/parser\\.h$",
> +    REG_EXTENDED, NULL_REGEX,
> +    "gt-cp-parser.h", "cp/parser.c", NULL_FRULACT },

But cp/parser.c also gets its own gt-cp-parser.h.  Won't they
conflict?  Doesn't this mean that cp/parser.h should be renamed to
something else?  (say cp/cp-parser.h).

Other than that, it looks fine.


Diego.

Re: PATCH: PR rtl-optimization/47502: Never combine asm statement

[Eric Botcazou]

> Is this patch OK for trunk?

This has always worked for the other ports AFAIK so I don't think we should 
disable it without evaluating the impact on them.  If reload has so many 
problems with x32, maybe more fundamental changes should be made to the x86 
back-end to support it.

-- 
Eric Botcazou

Re: 4.7 deprecated targets removal patch

[Ralf Wildenhues]

* Joseph S. Myers wrote on Fri, Mar 18, 2011 at 08:46:56PM CET:
> On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
> 
> > > @@ -744,7 +744,6 @@ case "${target}" in
> > >  libgloss_dir=cris
> > >  ;;
> > >crx-*-*)
> > > -noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap 
> > > ${libgcj}"
> > >  ;;
> > 
> > Why not also remove the line before and after this one?
> > Is that because crx is still supported in binutils or other
> > src projects?  If yes, the hunk is fine, but then I wonder
> > whether it is too early to drop the config-ml.in bits for src.
> 
> Yes, it is still supported in binutils

Then config-ml.in should not be changed yet, IIUC.

> - and the general reason for not 
> removing the empty cases is that there are plenty of such cases already 
> there, some for truly ancient targets.

I can understand keeping them when there are later case matches that
might match the pattern in question.  That doesn't apply to crx-*-*
however.

(FWIW, my knowledge about history of GCC and binutils targets is really
limited, so I rely on others here.)

> It seems quite likely that some of 
> the targets mentioned at toplevel actually have no useful support anywhere 
> in gcc or src and that all of those target cases should be reviewed for 
> usefulness and correctness.

Right, but that sounds like an independent task.

> (There are also lots of cases for "canonical 
> aliases" that have been deprecated and removed from GCC - that is, names 
> that should be aliases but that config.sub treats as canonical and so 
> cause problems because of needing duplication in case statements etc. 
> everywhere.  In those cases it probably makes sense to remove support for 
> the duplicate names in src, along maybe with making config.sub convert 
> them to canonical form.  i?86-*-pe as an alias for Cygwin is an example in 
> the present patch; various such aliases were obsoleted in 4.3 as well, but 
> support for "thumb-*" targets was obsolete long before the other ARM 
> aliases obsoleted in 4.3.)

That's yet another task that might be a good idea to do (by somebody who
knows this in and out), but config.sub changes have the potential to
break or at least require adjustment in lots of other software.  Many
packages look at those aliases, be that in their configury, or through
Libtool or gnulib or other third-party macros.  I can't judge this well
without seeing a list of affected aliases (and even then it might be
hard).

Thanks,
Ralf

Re: [PATCH] recog.c: Fix RTX unsharing in change groups

[Eric Botcazou]

> The attached patch prevents that by doing RTX unsharing for all
> subsequent changes after finding a single change where unsharing has
> been explicitly requested.

This looks like a big hammer.  Why not doing it in canonicalize_change_group, 
i.e. calling validate_unshare_change instead of validate_change there?

-- 
Eric Botcazou

[google] Cherry pick rev 171161

[Diego Novillo]

I have cherry picked rev 171161
(http://codereview.appspot.com/4273077/) from trunk to fix the last
testsuite failure we were getting in libstdc++.  I've committed the
change to google/main.  I will commit the same change to
google/integration and google/gcc-4_6.


Diego.

Re: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Nicola Pero]

>> +  /* cp/parser.h gives gt-cp-parser.h for cp/parser.c !  */
>> +  { DIR_PREFIX_REGEX "cp/parser\\.h$",
>> +    REG_EXTENDED, NULL_REGEX,
>> +    "gt-cp-parser.h", "cp/parser.c", NULL_FRULACT },
>
> But cp/parser.c also gets its own gt-cp-parser.h.  Won't they
> conflict?  Doesn't this mean that cp/parser.h should be renamed to
> something else?  (say cp/cp-parser.h).

My understanding is that, with that rule, GC generated code from
cp-parser.h will end up into gt-cp-parser.h, together with the code
generated from cp-parser.c.  gengtype basically runs once for all
files, so has no problem putting GC generated code from multiple
input files into the same output file.

In practical terms, cp/decl.c and cp/decl.h (or cp/name-lookup.c
and cp/name-lookup.h) are in a similar situation, and work fine
with similar gengtype.c rules. :-)

Thanks

[PATCH, i386]: Use indirect functions some more

[Uros Bizjak]

Hello!

Just a trivial cleanup, no functional changes.

2011-03-18  Uros Bizjak  

* config/i386/i386.md (float2):
Rewrite using indirect functions.
(lwp_slwpcb): Ditto.
(avx_vextractf128): Ditto.
(avx_vinsertf128): Ditto.

Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.

Uros.
Index: i386.md
===
--- i386.md (revision 171163)
+++ i386.md (working copy)
@@ -4959,18 +4959,18 @@
   && !X87_ENABLE_FLOAT (mode, mode))
 {
   rtx reg = gen_reg_rtx (XFmode);
-  rtx insn;
+  rtx (*insn)(rtx, rtx);
 
   emit_insn (gen_floatxf2 (reg, operands[1]));
 
   if (mode == SFmode)
-   insn = gen_truncxfsf2 (operands[0], reg);
+   insn = gen_truncxfsf2;
   else if (mode == DFmode)
-   insn = gen_truncxfdf2 (operands[0], reg);
+   insn = gen_truncxfdf2;
   else
gcc_unreachable ();
 
-  emit_insn (insn);
+  emit_insn (insn (operands[0], reg));
   DONE;
 }
 })
@@ -18216,10 +18216,13 @@
(unspec_volatile [(const_int 0)] UNSPECV_SLWP_INTRINSIC))]
   "TARGET_LWP"
 {
-  if (TARGET_64BIT)
-emit_insn (gen_lwp_slwpcbdi (operands[0]));
-  else
-emit_insn (gen_lwp_slwpcbsi (operands[0]));
+  rtx (*insn)(rtx);
+
+  insn = (TARGET_64BIT
+ ? gen_lwp_slwpcbdi
+ : gen_lwp_slwpcbsi);
+
+  emit_insn (insn (operands[0]));
   DONE;
 })
 
Index: sse.md
===
--- sse.md  (revision 171163)
+++ sse.md  (working copy)
@@ -4122,17 +4122,21 @@
(match_operand:SI 2 "const_0_to_1_operand" "")]
   "TARGET_AVX"
 {
+  rtx (*insn)(rtx, rtx);
+
   switch (INTVAL (operands[2]))
 {
 case 0:
-  emit_insn (gen_vec_extract_lo_ (operands[0], operands[1]));
+  insn = gen_vec_extract_lo_;
   break;
 case 1:
-  emit_insn (gen_vec_extract_hi_ (operands[0], operands[1]));
+  insn = gen_vec_extract_hi_;
   break;
 default:
   gcc_unreachable ();
 }
+
+  emit_insn (insn (operands[0], operands[1]));
   DONE;
 })
 
@@ -11776,19 +11780,21 @@
(match_operand:SI 3 "const_0_to_1_operand" "")]
   "TARGET_AVX"
 {
+  rtx (*insn)(rtx, rtx, rtx);
+
   switch (INTVAL (operands[3]))
 {
 case 0:
-  emit_insn (gen_vec_set_lo_ (operands[0], operands[1],
-   operands[2]));
+  insn = gen_vec_set_lo_;
   break;
 case 1:
-  emit_insn (gen_vec_set_hi_ (operands[0], operands[1],
-   operands[2]));
+  insn = gen_vec_set_hi_;
   break;
 default:
   gcc_unreachable ();
 }
+
+  emit_insn (insn (operands[0], operands[1], operands[2]));
   DONE;
 })
 

Re: PATCH: PR rtl-optimization/47502: Never combine asm statement

[H.J. Lu]

On Fri, Mar 18, 2011 at 12:51 PM, Eric Botcazou  wrote:
>> Is this patch OK for trunk?
>
> This has always worked for the other ports AFAIK so I don't think we should
> disable it without evaluating the impact on them.  If reload has so many
> problems with x32, maybe more fundamental changes should be made to the x86
> back-end to support it.
>

X32 port exposed many issues in GCC middle-end and RTL optimizations.
The other ports never generate such asm statements combine has to deal with.
Do you have any suggestions how to fix it in backend?

Thanks.


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/17/2011 03:28 PM, H.J. Lu wrote:
> It will require very extensive changes to x86 backend since stack pointer
> and frame pointer are really in DImode for x32 as x32 process runs in
> 64bit mode. If you can make it to work, please let me know.

Yes, the stack pointer uses all 64 bits for e.g. push/pop/call.  But so
what?  Given that our 32-bit move insns also implicitly zero-extend, I
don't see that we need to actually expose the fact of the 64-bit RSP to
the rest of the compiler.


r~

Re: PATCH: PR rtl-optimization/47502: Never combine asm statement

[Richard Henderson]

On 03/18/2011 01:56 PM, H.J. Lu wrote:
> On Fri, Mar 18, 2011 at 12:51 PM, Eric Botcazou  wrote:
>>> Is this patch OK for trunk?
>>
>> This has always worked for the other ports AFAIK so I don't think we should
>> disable it without evaluating the impact on them.  If reload has so many
>> problems with x32, maybe more fundamental changes should be made to the x86
>> back-end to support it.
>>
> 
> X32 port exposed many issues in GCC middle-end and RTL optimizations.
> The other ports never generate such asm statements combine has to deal with.
> Do you have any suggestions how to fix it in backend?

How about analyzing the problem properly?

All you posted was a patch, with no explanation of how the problem occurred.
Without that, no one can say whether this is the x32 port really tickling a
latent bug in the compiler, or whether it's a bug in your port.


r~

Re: [PATCH, i386]: Use indirect functions some more

[Richard Henderson]

On 03/18/2011 01:40 PM, Uros Bizjak wrote:
>if (mode == SFmode)
> - insn = gen_truncxfsf2 (operands[0], reg);
> + insn = gen_truncxfsf2;
>else if (mode == DFmode)
> - insn = gen_truncxfdf2 (operands[0], reg);
> + insn = gen_truncxfdf2;
>else
>   gcc_unreachable ();

Why is this a good thing?  Surely the direct calls are much
better predicted by the CPU...

I can certainly understand sinking the call to emit_insn, as
in the second hunk; that ought to save code size.  Though the
compiler really ought to be able to figure that out itself.


r~

Re: 4.7 deprecated targets removal patch

[Joseph S. Myers]

On Fri, 18 Mar 2011, Ralf Wildenhues wrote:

> * Joseph S. Myers wrote on Fri, Mar 18, 2011 at 08:46:56PM CET:
> > On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
> > 
> > > > @@ -744,7 +744,6 @@ case "${target}" in
> > > >  libgloss_dir=cris
> > > >  ;;
> > > >crx-*-*)
> > > > -noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap 
> > > > ${libgcj}"
> > > >  ;;
> > > 
> > > Why not also remove the line before and after this one?
> > > Is that because crx is still supported in binutils or other
> > > src projects?  If yes, the hunk is fine, but then I wonder
> > > whether it is too early to drop the config-ml.in bits for src.
> > 
> > Yes, it is still supported in binutils
> 
> Then config-ml.in should not be changed yet, IIUC.

config-ml.in should have nothing to do with binutils here, since binutils 
does not build target libraries.  The only potentially relevant target 
code in the src tree would be newlib/libgloss - and I see no sign of an 
arc port there.  So I believe the arc code in config-ml.in was only used 
for building GCC's own target libraries, and so can safely be removed.

Actually I'd rather like to deprecate the entire set of configure options 
that control multilib building in config-ml.in, on the basis that the 
correct way to configure this is through options processed in config.gcc 
that end up controlling the MULTILIB_* variables, like SH's multilib 
configure options (and that if target maintainers actually care about 
these obscure configure options, they should reimplement them in 
config.gcc).  If we were to deprecate all those options in GCC, what would 
you then think is required to be able to remove them from config-ml.in, 
given the possibility of newlib using these options?

> > - and the general reason for not 
> > removing the empty cases is that there are plenty of such cases already 
> > there, some for truly ancient targets.
> 
> I can understand keeping them when there are later case matches that
> might match the pattern in question.  That doesn't apply to crx-*-*
> however.

Well, it would match the *-*-* case (which is fairly harmless).  But just 
the same would seem to apply to the i370-*-opened* case, for example - I 
don't see anything else that would match other than *-*-*.

> > (There are also lots of cases for "canonical 
> > aliases" that have been deprecated and removed from GCC - that is, names 
> > that should be aliases but that config.sub treats as canonical and so 
> > cause problems because of needing duplication in case statements etc. 
> > everywhere.  In those cases it probably makes sense to remove support for 
> > the duplicate names in src, along maybe with making config.sub convert 
> > them to canonical form.  i?86-*-pe as an alias for Cygwin is an example in 
> > the present patch; various such aliases were obsoleted in 4.3 as well, but 
> > support for "thumb-*" targets was obsolete long before the other ARM 
> > aliases obsoleted in 4.3.)
> 
> That's yet another task that might be a good idea to do (by somebody who
> knows this in and out), but config.sub changes have the potential to
> break or at least require adjustment in lots of other software.  Many
> packages look at those aliases, be that in their configury, or through
> Libtool or gnulib or other third-party macros.  I can't judge this well
> without seeing a list of affected aliases (and even then it might be
> hard).

The ones eliminated in GCC include at least:

strongarm*-*-*
ep9312*-*-*
xscale*-*-*
(much longer ago) thumb-*-*
parisc*-*-*
m680[012]0-*-*
i?86-*-pe

All of these appear in the toplevel configure.ac.  Of these, the only one 
config.guess might sometimes produce is m680[012]0-*-*, so the others can 
only ever appear as targets in cross-compilation.

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

Re: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Diego Novillo]

On Fri, Mar 18, 2011 at 16:17, Nicola Pero
 wrote:
>
>>> +  /* cp/parser.h gives gt-cp-parser.h for cp/parser.c !  */
>>> +  { DIR_PREFIX_REGEX "cp/parser\\.h$",
>>> +    REG_EXTENDED, NULL_REGEX,
>>> +    "gt-cp-parser.h", "cp/parser.c", NULL_FRULACT },
>>
>> But cp/parser.c also gets its own gt-cp-parser.h.  Won't they
>> conflict?  Doesn't this mean that cp/parser.h should be renamed to
>> something else?  (say cp/cp-parser.h).
>
> My understanding is that, with that rule, GC generated code from
> cp-parser.h will end up into gt-cp-parser.h, together with the code
> generated from cp-parser.c.  gengtype basically runs once for all
> files, so has no problem putting GC generated code from multiple
> input files into the same output file.

OK, thanks.

I'm OK with the patch, but please wait for a specific approval from
Laurynas.  I'm not sufficiently familiar with this code to give final
approval.


Diego.

Make C1X anonymous structs/unions follow N1549

[Joseph S. Myers]

This week's London WG14 meeting agreed to disallow the use of typedefs
in declaring anonymous structure and union fields, as per N1549.  This
patch implements this, restricting the use of typedefs in this case to
-fms-extensions and -fplan9-extensions as in 4.5 and earlier releases.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  Applied
to mainline.  Any comments from other RMs about whether this should go
in 4.6 as well, to avoid 4.6.0 being more lenient in this area than
both 4.5 and 4.7?  (The issue is about what is accepted by default
rather than -std=c1x, since -std=c1x users in 4.6 should know it's
experimental and subject to change.)

2011-03-18  Joseph Myers  

* c-decl.c (grokfield): Don't allow typedefs for structures or
unions with no tag by default.
* doc/extend.texi (Unnamed Fields): Update.

testsuite:
2011-03-18  Joseph Myers  

* gcc.dg/c1x-anon-struct-1.c: Don't test use of typedefs.
* gcc.dg/c1x-anon-struct-3.c: New test.
* gcc.dg/anon-struct-11.c: Update.

Index: doc/extend.texi
===
--- doc/extend.texi (revision 171110)
+++ doc/extend.texi (working copy)
@@ -13352,12 +13352,11 @@ The compiler gives errors for such const
 @opindex fms-extensions
 Unless @option{-fms-extensions} is used, the unnamed field must be a
 structure or union definition without a tag (for example, @samp{struct
-@{ int a; @};}), or a @code{typedef} name for such a structure or
-union.  If @option{-fms-extensions} is used, the field may
+@{ int a; @};}).  If @option{-fms-extensions} is used, the field may
 also be a definition with a tag such as @samp{struct foo @{ int a;
 @};}, a reference to a previously defined structure or union such as
 @samp{struct foo;}, or a reference to a @code{typedef} name for a
-previously defined structure or union type with a tag.
+previously defined structure or union type.
 
 @opindex fplan9-extensions
 The option @option{-fplan9-extensions} enables
Index: testsuite/gcc.dg/c1x-anon-struct-3.c
===
--- testsuite/gcc.dg/c1x-anon-struct-3.c(revision 0)
+++ testsuite/gcc.dg/c1x-anon-struct-3.c(revision 0)
@@ -0,0 +1,34 @@
+/* Test for anonymous structures and unions in C1X.  Test for invalid
+   cases: typedefs disallowed by N1549.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c1x -pedantic-errors" } */
+
+typedef struct
+{
+  int i;
+} s0;
+
+typedef union
+{
+  int i;
+} u0;
+
+struct s1
+{
+  int a;
+  u0; /* { dg-error "declaration does not declare anything" } */
+  struct
+  {
+int b;
+  };
+};
+
+union u1
+{
+  int b;
+  s0; /* { dg-error "declaration does not declare anything" } */
+  union
+  {
+int c;
+  };
+};
Index: testsuite/gcc.dg/anon-struct-11.c
===
--- testsuite/gcc.dg/anon-struct-11.c   (revision 171110)
+++ testsuite/gcc.dg/anon-struct-11.c   (working copy)
@@ -50,7 +50,7 @@ struct E {
   struct F { char f; };/* { dg-warning "does not declare anything" } */
   char c;
   union {
-D;
+D; /* { dg-warning "does not declare anything" } */
   };
   char e;
 };
@@ -85,7 +85,7 @@ test2 (void)
   e.e = 5;
   f2 (&e); /* { dg-warning "incompatible pointer type" } */
   f3 (&e); /* { dg-warning "incompatible pointer type" } */
-  if (e.d != 4)
+  if (e.d != 4)/* { dg-error "no member" } */
 abort ();
   if (e.f != 6)/* { dg-error "no member" } */
 abort ();
Index: testsuite/gcc.dg/c1x-anon-struct-1.c
===
--- testsuite/gcc.dg/c1x-anon-struct-1.c(revision 171110)
+++ testsuite/gcc.dg/c1x-anon-struct-1.c(working copy)
@@ -4,20 +4,13 @@
 
 #include 
 
-typedef struct
-{
-  int i;
-} s0;
-
-typedef union
-{
-  int i;
-} u0;
-
 struct s1
 {
   int a;
-  u0;
+  union
+  {
+int i;
+  };
   struct
   {
 int b;
@@ -27,7 +20,10 @@ struct s1
 union u1
 {
   int b;
-  s0;
+  struct
+  {
+int i;
+  };
   union
   {
 int c;
@@ -44,7 +40,10 @@ struct s2
 
 struct s3
 {
-  u0;
+  union
+  {
+int i;
+  };
 };
 
 struct s4
Index: c-decl.c
===
--- c-decl.c(revision 171110)
+++ c-decl.c(working copy)
@@ -6674,11 +6674,14 @@ grokfield (location_t loc,
  || TREE_CODE (type) == UNION_TYPE);
   bool ok = false;
 
-  if (type_ok)
+  if (type_ok
+ && (flag_ms_extensions
+ || flag_plan9_extensions
+ || !declspecs->typedef_p))
{
  if (flag_ms_extensions || flag_plan9_extensions)
ok = true;
- else if (TYPE_NAME (TYPE_MAIN_VARIANT (type)) == NULL)
+ else if (TYPE_NAME (type) == NULL)
ok = true;
  else
ok = false;

-- 
Jos

Re: C++0x PATCH to add -fconstexpr-depth

[Jason Merrill]

Thanks for the feedback; fixed.

Jason

Re: [patch i386,c,c++]: PR/12171 - calling convention omitted in error message

[Jason Merrill]

OK.

Jason

Re: PATCH: PR rtl-optimization/47502: Never combine asm statement

[H.J. Lu]

On Fri, Mar 18, 2011 at 2:05 PM, Richard Henderson  wrote:
> On 03/18/2011 01:56 PM, H.J. Lu wrote:
>> On Fri, Mar 18, 2011 at 12:51 PM, Eric Botcazou  
>> wrote:
 Is this patch OK for trunk?
>>>
>>> This has always worked for the other ports AFAIK so I don't think we should
>>> disable it without evaluating the impact on them.  If reload has so many
>>> problems with x32, maybe more fundamental changes should be made to the x86
>>> back-end to support it.
>>>
>>
>> X32 port exposed many issues in GCC middle-end and RTL optimizations.
>> The other ports never generate such asm statements combine has to deal with.
>> Do you have any suggestions how to fix it in backend?
>
> How about analyzing the problem properly?
>
> All you posted was a patch, with no explanation of how the problem occurred.
> Without that, no one can say whether this is the x32 port really tickling a
> latent bug in the compiler, or whether it's a bug in your port.
>

See analysis in:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47502


-- 
H.J.

Re: Make C1X anonymous structs/unions follow N1549

[Jakub Jelinek]

On Fri, Mar 18, 2011 at 09:16:55PM +, Joseph S. Myers wrote:
> This week's London WG14 meeting agreed to disallow the use of typedefs
> in declaring anonymous structure and union fields, as per N1549.  This
> patch implements this, restricting the use of typedefs in this case to
> -fms-extensions and -fplan9-extensions as in 4.5 and earlier releases.

If I understand it right, your patch restores the 4.5 code except for
-fplan9-extensions and with flag_iso not being checked.

I guess it is ok for 4.6.0 too.

Jakub

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Fri, Mar 18, 2011 at 2:03 PM, Richard Henderson  wrote:
> On 03/17/2011 03:28 PM, H.J. Lu wrote:
>> It will require very extensive changes to x86 backend since stack pointer
>> and frame pointer are really in DImode for x32 as x32 process runs in
>> 64bit mode. If you can make it to work, please let me know.
>
> Yes, the stack pointer uses all 64 bits for e.g. push/pop/call.  But so
> what?  Given that our 32-bit move insns also implicitly zero-extend, I
> don't see that we need to actually expose the fact of the 64-bit RSP to
> the rest of the compiler.
>

X86 backend uses Pmode for hardware pointer size. Changes
it to 32bit for x32, which is really 64bit process, breaks many
assumptions of x86 backend. push/pop/call is just the tip of
the iceberg.


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/18/2011 02:56 PM, H.J. Lu wrote:
> X86 backend uses Pmode for hardware pointer size. Changes
> it to 32bit for x32, which is really 64bit process, breaks many
> assumptions of x86 backend. push/pop/call is just the tip of
> the iceberg.

Please enumerate "many assumptions".  I can't think of any off
the top of my head.


r~

Re: Make C1X anonymous structs/unions follow N1549

[Mark Mitchell]

On 3/18/2011 2:52 PM, Jakub Jelinek wrote:

>> This week's London WG14 meeting agreed to disallow the use of typedefs
>> in declaring anonymous structure and union fields, as per N1549.  This
>> patch implements this, restricting the use of typedefs in this case to
>> -fms-extensions and -fplan9-extensions as in 4.5 and earlier releases.

> I guess it is ok for 4.6.0 too.

I think avoiding the ping-pong in behavior between 4.5 and 4.7 is a good
call.  So, I think the patch is OK for 4.6.

Thank you,

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

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson  wrote:
> On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> X86 backend uses Pmode for hardware pointer size. Changes
>> it to 32bit for x32, which is really 64bit process, breaks many
>> assumptions of x86 backend. push/pop/call is just the tip of
>> the iceberg.
>
> Please enumerate "many assumptions".  I can't think of any off
> the top of my head.
>

I don't have a complete list.  gen_push is one of them:

static rtx
gen_push (rtx arg)
{
  struct machine_function *m = cfun->machine;

  if (m->fs.cfa_reg == stack_pointer_rtx)
m->fs.cfa_offset += UNITS_PER_WORD;
  m->fs.sp_offset += UNITS_PER_WORD;

  return gen_rtx_SET (VOIDmode,
  gen_rtx_MEM (Pmode,
   gen_rtx_PRE_DEC (Pmode,
stack_pointer_rtx)),
  arg);
}

You can only push/pup 64bit in hardware 64bit mode.


-- 
H.J.

Re: 4.7 deprecated targets removal patch

[Ralf Wildenhues]

* Joseph S. Myers wrote on Fri, Mar 18, 2011 at 10:09:04PM CET:
> On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
> > * Joseph S. Myers wrote on Fri, Mar 18, 2011 at 08:46:56PM CET:
> > > On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
> > > > Why not also remove the line before and after this one?
> > > > Is that because crx is still supported in binutils or other
> > > > src projects?  If yes, the hunk is fine, but then I wonder
> > > > whether it is too early to drop the config-ml.in bits for src.
> > > 
> > > Yes, it is still supported in binutils
> > 
> > Then config-ml.in should not be changed yet, IIUC.
> 
> config-ml.in should have nothing to do with binutils here, since binutils 
> does not build target libraries.  The only potentially relevant target 
> code in the src tree would be newlib/libgloss - and I see no sign of an 
> arc port there.  So I believe the arc code in config-ml.in was only used 
> for building GCC's own target libraries, and so can safely be removed.

OK then.

> Actually I'd rather like to deprecate the entire set of configure options 
> that control multilib building in config-ml.in, on the basis that the 
> correct way to configure this is through options processed in config.gcc 
> that end up controlling the MULTILIB_* variables, like SH's multilib 
> configure options (and that if target maintainers actually care about 
> these obscure configure options, they should reimplement them in 
> config.gcc).  If we were to deprecate all those options in GCC, what would 
> you then think is required to be able to remove them from config-ml.in, 
> given the possibility of newlib using these options?

A quick look at other projects that use config-ml.in would be prudent.
I glanced at codesearch, there doesn't seem to be a problem outside GCC
IMVHO.  So yes, such a cleanup would seem good.

> > > - and the general reason for not 
> > > removing the empty cases is that there are plenty of such cases already 
> > > there, some for truly ancient targets.
> > 
> > I can understand keeping them when there are later case matches that
> > might match the pattern in question.  That doesn't apply to crx-*-*
> > however.
> 
> Well, it would match the *-*-* case (which is fairly harmless).  But just 
> the same would seem to apply to the i370-*-opened* case, for example - I 
> don't see anything else that would match other than *-*-*.

i370-ibm-opened* would.  I have no idea how relevant that is; it only
sets tentative_cc.

[...]
> The ones eliminated in GCC include at least:
> 
> strongarm*-*-*
> ep9312*-*-*
> xscale*-*-*
> (much longer ago) thumb-*-*
> parisc*-*-*
> m680[012]0-*-*
> i?86-*-pe
> 
> All of these appear in the toplevel configure.ac.  Of these, the only one 
> config.guess might sometimes produce is m680[012]0-*-*, so the others can 
> only ever appear as targets in cross-compilation.

Except for the PE one, all of these are only about CPU type aliases.
At least the gnulib and Libtool configury rarely looks at those, and
their matching would seem limited outside of tool-related projects.
I'd say a quick codesearch would allow to improve here with some
confidence.

Thanks,
Ralf

Re: PATCH: PR rtl-optimization/47502: Never combine asm statement

[Richard Henderson]

On 03/18/2011 02:51 PM, H.J. Lu wrote:
> See analysis in:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47502

You're patching the wrong place.  See can_combine_p,
which can test for specific sources, rather than 
cant_combine_insn_p which has no access to sources.


r~

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/18/2011 03:32 PM, H.J. Lu wrote:
> I don't have a complete list.  gen_push is one of them:
...
> You can only push/pup 64bit in hardware 64bit mode.

Ok, seems an easy enough place to use word_mode instead.


r~

Re: Can't use SImode as Pmode for x32

[Jakub Jelinek]

On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
> On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson  wrote:
> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
> >> X86 backend uses Pmode for hardware pointer size. Changes
> >> it to 32bit for x32, which is really 64bit process, breaks many
> >> assumptions of x86 backend. push/pop/call is just the tip of
> >> the iceberg.
> >
> > Please enumerate "many assumptions".  I can't think of any off
> > the top of my head.
> >
> 
> I don't have a complete list.  gen_push is one of them:
> 
> static rtx
> gen_push (rtx arg)
> {
>   struct machine_function *m = cfun->machine;
> 
>   if (m->fs.cfa_reg == stack_pointer_rtx)
> m->fs.cfa_offset += UNITS_PER_WORD;
>   m->fs.sp_offset += UNITS_PER_WORD;
> 
>   return gen_rtx_SET (VOIDmode,
>   gen_rtx_MEM (Pmode,
>gen_rtx_PRE_DEC (Pmode,
> stack_pointer_rtx)),
>   arg);
> }
> 
> You can only push/pup 64bit in hardware 64bit mode.

That's still push/pop/call.  And you can certainly use a Pmode (== SImode)
stack_pointer_rtx to describe it too, push/pop reference %rsp just
implicitly.  For the MEM you would just use DImode for x32 in that case,
or for <= 32 bit pushes you could describe it as a SImode MEM with
PRE_MODIFY inside of it.

For addresses, you could use 32-bit regs (i.e. addr32 prefix) by default,
perhaps with machine reorg optimizing away some of the addr32 prefixes when
it can prove the base register is already zero extended, and if there is no
added or very small one.

Jakub

Re: [Committed] S/390: Handle GOTOFF unspecs in delegitimize_address

[Jakub Jelinek]

On Fri, Mar 18, 2011 at 06:37:38PM +0100, Andreas Krebbel wrote:
> Hi,
> 
> the attached patch adds handling for GOTOFF unspecs to
> delegitimize_address.
> 
> A lot of "note: non-delegitimized UNSPEC 112" messages disappear with
> this.  However not all of them.

Please look at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00922.html
for what i?86 does here...

Jakub

Re: Make C1X anonymous structs/unions follow N1549

[Joseph S. Myers]

On Fri, 18 Mar 2011, Jakub Jelinek wrote:

> On Fri, Mar 18, 2011 at 09:16:55PM +, Joseph S. Myers wrote:
> > This week's London WG14 meeting agreed to disallow the use of typedefs
> > in declaring anonymous structure and union fields, as per N1549.  This
> > patch implements this, restricting the use of typedefs in this case to
> > -fms-extensions and -fplan9-extensions as in 4.5 and earlier releases.
> 
> If I understand it right, your patch restores the 4.5 code except for
> -fplan9-extensions and with flag_iso not being checked.

Yes, that's the intent of the grokfield changes in this patch.  (All the 
other front-end changes in 4.6 relating to anonymous structs and unions 
are unaffected by this typedef change.)

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

Re: 4.7 deprecated targets removal patch

[Joseph S. Myers]

On Fri, 18 Mar 2011, Ralf Wildenhues wrote:

> > > > - and the general reason for not 
> > > > removing the empty cases is that there are plenty of such cases already 
> > > > there, some for truly ancient targets.
> > > 
> > > I can understand keeping them when there are later case matches that
> > > might match the pattern in question.  That doesn't apply to crx-*-*
> > > however.
> > 
> > Well, it would match the *-*-* case (which is fairly harmless).  But just 
> > the same would seem to apply to the i370-*-opened* case, for example - I 
> > don't see anything else that would match other than *-*-*.
> 
> i370-ibm-opened* would.  I have no idea how relevant that is; it only
> sets tentative_cc.

i370-ibm-opened* is in a different case statement.  In the case statement 
with an empty i370-*-opened* case the only other case matching it would 
seem to be *-*-*.

Can some global reviewer review the patch apart from the toplevel 
config-ml.in / configure.ac changes?  Those toplevel changes are purely 
cleanups that are not required by the rest of the patch.

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

Re: [patch, fortran] Function call optimization

[Tobias Burnus]

Thomas Koenig wrote:

+  if (!(*e)->value.function.esym->attr.pure
+   &&  !(*e)->value.function.esym->attr.implicit_pure
+   &&  !(*e)->value.function.esym->attr.elemental)
+   return 0;


I have not followed the discussion nor have I fully read the patch, but 
what's the reason for allowing ELEMENTAL functions? I understand the 
PURE and the implicitly pure part. But without looking at the 
scalarizer, I would assume that the same reasons which speak against 
non-elemental impure functions should also speak against IMPURE 
ELEMENTAL functions, don't they?


Tobias

[PATCH, 4.7] PR 48192, Make conditional macros not defined for #ifdef

[Michael Meissner]

This patch makes conditional macros that are used in the PowerPC and SPU ports
not be 'defined' for the #ifdef, #ifndef, and #if defined(...) tests.  The way
the PowerPC and SPU uses conditional macros is provide conditional keywords to
support the vector systen (i.e. if the next token after vector is not bool,
pixel, or a standard type, the vector macro is not expanded).

Some users have run into this when compiling for Power7, which enables the
Altivec support by default in code fragments like:

#ifndef bool
#define bool char
#endif

On the powerpc if you compile with -mcpu=power7, the #ifndef test does not
succeed, because 'bool' is defined as a macro, it never defines bool to be char
and a syntax error will come up.

I bootstraped 4.7 and tested that the 3 PowerPC conditional macros are not
defined.  Is this ok to install in 4.7?

I would like to backport this to 4.6, 4.5 and maybe 4.4.  Are there objections
to backporting it?

[libcpp]
2011-03-18  Michael Meissner  

PR preprocessor/48192
* directives.c (do_ifdef): Do not consider conditional macros as
being defined.
(do_ifndef): Ditto.
* expr.c (parse_defined): Ditto.

[gcc/testsuite]
2011-03-18  Michael Meissner  

PR preprocessor/48192
* gcc.target/powerpc/pr48192.c: New file.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: libcpp/directives.c
===
--- libcpp/directives.c (revision 171162)
+++ libcpp/directives.c (working copy)
@@ -1819,7 +1819,12 @@ do_ifdef (cpp_reader *pfile)
 
   if (node)
{
- skip = node->type != NT_MACRO;
+ /* Do not treat conditional macros as being defined.  This is due to
+the powerpc and spu ports using conditional macros for 'vector',
+'bool', and 'pixel' to act as conditional keywords.  This messes
+up tests like #ifndef bool.  */
+ skip = (node->type != NT_MACRO
+ || ((node->flags & NODE_CONDITIONAL) != 0));
  _cpp_mark_macro_used (node);
  if (!(node->flags & NODE_USED))
{
@@ -1860,7 +1865,12 @@ do_ifndef (cpp_reader *pfile)
 
   if (node)
{
- skip = node->type == NT_MACRO;
+ /* Do not treat conditional macros as being defined.  This is due to
+the powerpc and spu ports using conditional macros for 'vector',
+'bool', and 'pixel' to act as conditional keywords.  This messes
+up tests like #ifndef bool.  */
+ skip = (node->type == NT_MACRO
+ && ((node->flags & NODE_CONDITIONAL) == 0));
  _cpp_mark_macro_used (node);
  if (!(node->flags & NODE_USED))
{
Index: libcpp/expr.c
===
--- libcpp/expr.c   (revision 171162)
+++ libcpp/expr.c   (working copy)
@@ -720,10 +720,15 @@ parse_defined (cpp_reader *pfile)
 
   pfile->state.prevent_expansion--;
 
+  /* Do not treat conditional macros as being defined.  This is due to the
+ powerpc and spu ports using conditional macros for 'vector', 'bool', and
+ 'pixel' to act as conditional keywords.  This messes up tests like #ifndef
+ bool.  */
   result.unsignedp = false;
   result.high = 0;
   result.overflow = false;
-  result.low = node && node->type == NT_MACRO;
+  result.low = (node && node->type == NT_MACRO
+   && (node->flags & NODE_CONDITIONAL) == 0);
   return result;
 }
 
Index: gcc/testsuite/gcc.target/powerpc/pr48192.c
===
--- gcc/testsuite/gcc.target/powerpc/pr48182.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr48182.c  (revision 0)
@@ -0,0 +1,49 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O3 -mcpu=power7 -std=gnu89" } */
+
+/* Make sure that the conditional macros vector, bool, and pixel are not
+   considered as being defined.  */
+
+#ifdef bool
+#error "bool is considered defined"
+#endif
+
+#ifdef vector
+#error "vector is considered defined"
+#endif
+
+#ifdef pixel
+#error "pixel is condsidered defined"
+#endif
+
+#if defined(bool)
+#error "bool is considered defined"
+#endif
+
+#if defined(vector)
+#error "vector is considered defined"
+#endif
+
+#if defined(pixel)
+#error "pixel is condsidered defined"
+#endif
+
+#ifndef bool
+#else
+#error "bool is considered defined"
+#endif
+
+#ifndef vector
+#else
+#error "vector is considered defined"
+#endif
+
+#ifndef pixel
+#else
+#error "pixel is condsidered defined"
+#endif
+
+#define bool long double
+bool pixel = 0;

Disallow redefinition of variably modified typedefs

[Joseph S. Myers]

This week's London WG14 meeting decided that typedef redefinition
should not be allowed in the case of variably modified types.  This
patch implements this, giving an error for such redefinitions.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  Applied
to mainline.  Any comments from other RMs about whether this should go
in 4.6 as well, to avoid 4.6.0 being more lenient in this area than
both 4.5 and 4.7?  This is much the same issue as for anonymous
structs and unions, but for a much more obscure case.

(These two patches cover the only two cases of C1X features that were
fully implemented for 4.6 according to the pre-London draft, and then
changed in London.  The post-London document will be going to
enquiry-stage ITTF/JTC1 ballot so if that passes there should be no
more technical changes before publication.)

2011-03-18  Joseph Myers  

* c-decl.c (diagnose_mismatched_decls): Give an error for
redefining a typedef with variably modified type.

testsuite:
2011-03-18  Joseph Myers  

* gcc.dg/c1x-typedef-1.c: Expect errors for redefinitions of
variably modified typedefs.
* gcc.dg/c1x-typedef-2.c: Remove.

Index: testsuite/gcc.dg/c1x-typedef-1.c
===
--- testsuite/gcc.dg/c1x-typedef-1.c(revision 171110)
+++ testsuite/gcc.dg/c1x-typedef-1.c(working copy)
@@ -3,7 +3,8 @@
 /* { dg-options "-std=c1x -pedantic-errors" } */
 
 /* C1X permits typedefs to be redeclared to the same type, but not to
-   different-but-compatible types.  */
+   different-but-compatible types, and not when the type is variably
+   modified.  */
 
 #include 
 
@@ -60,9 +61,10 @@ f (void)
   typedef void FN2(int (*p)[*]); /* { dg-message "previous declaration" } */
   typedef void FN2(int (*p)[]); /* { dg-error "with different type" } */
   typedef int AV[a]; /* { dg-message "previous declaration" } */
-  typedef int AV[b-1]; /* { dg-warning "may be a constraint violation at 
runtime" } */
-  typedef int AAa[a];
+  typedef int AV[b-1]; /* { dg-error "redefinition" } */
+  typedef int AAa[a]; /* { dg-message "previous declaration" } */
   typedef int AAb[b-1];
   typedef AAa *VF(void); /* { dg-message "previous declaration" } */
-  typedef AAb *VF(void); /* { dg-warning "may be a constraint violation at 
runtime" } */
+  typedef AAb *VF(void); /* { dg-error "redefinition" } */
+  typedef AAa AAa; /* { dg-error "redefinition" } */
 }
Index: testsuite/gcc.dg/c1x-typedef-2.c
===
--- testsuite/gcc.dg/c1x-typedef-2.c(revision 171110)
+++ testsuite/gcc.dg/c1x-typedef-2.c(working copy)
@@ -1,18 +0,0 @@
-/* Test typedef redeclaration in C1X.  Side effects from duplicate
-   declarations still apply.  */
-/* { dg-do run } */
-/* { dg-options "-std=c1x -pedantic-errors" } */
-
-extern void exit (int);
-extern void abort (void);
-
-int
-main (void)
-{
-  int a = 1, b = 1;
-  typedef int T[++a]; /* { dg-message "previous declaration" } */
-  typedef int T[++b]; /* { dg-warning "may be a constraint violation at 
runtime" } */
-  if (a != 2 || b != 2)
-abort ();
-  exit (0);
-}
Index: c-decl.c
===
--- c-decl.c(revision 171110)
+++ c-decl.c(working copy)
@@ -1813,20 +1813,16 @@ diagnose_mismatched_decls (tree newdecl,
  || TREE_NO_WARNING (olddecl))
return true;  /* Allow OLDDECL to continue in use.  */
 
-  if (pedantic && !flag_isoc1x)
+  if (variably_modified_type_p (newtype, NULL))
{
- pedwarn (input_location, OPT_pedantic,
-  "redefinition of typedef %q+D", newdecl);
+ error ("redefinition of typedef %q+D with variably modified type",
+newdecl);
  locate_old_decl (olddecl);
}
-  else if (variably_modified_type_p (newtype, NULL))
+  else if (pedantic && !flag_isoc1x)
{
- /* Whether there is a constraint violation for the types not
-being the same cannot be determined at compile time; a
-warning that there may be one at runtime is considered
-appropriate (WG14 reflector message 11743, 8 May 2009).  */
- warning (0, "redefinition of typedef %q+D may be a constraint "
-  "violation at runtime", newdecl);
+ pedwarn (input_location, OPT_pedantic,
+  "redefinition of typedef %q+D", newdecl);
  locate_old_decl (olddecl);
}
 

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

Re: [PATCH, 4.7] Have all inlining destinations "analyzed"

[Martin Jambor]

Hi,

On Fri, Mar 11, 2011 at 03:30:53PM +0100, Jan Hubicka wrote:
> > Index: src/gcc/cgraph.c
> > ===
> > --- src.orig/gcc/cgraph.c
> > +++ src/gcc/cgraph.c
> > @@ -2495,11 +2495,11 @@ cgraph_add_new_function (tree fndecl, bo
> >case CGRAPH_STATE_FINISHED:
> > /* At the very end of compilation we have to do all the work up
> >to expansion.  */
> > +   node = cgraph_node (fndecl);
> > +   cgraph_analyze_function (node);
> > push_cfun (DECL_STRUCT_FUNCTION (fndecl));
> > current_function_decl = fndecl;
> > gimple_register_cfg_hooks ();
> > -   if (!lowered)
> > -  tree_lowering_passes (fndecl);
> 
> The analysis shoud happent in cgraph_process_new_functions that
> should be called after every IPA pass.

I'm not sure I understand.  Since cgraph_state is in
CGRAPH_STATE_FINISHED, new functions are not added to cgraph_new_nodes
linked list to be picked up by cgraph_process_new_functions.  If you
are wondering why cgraph_state has that value because mudflap passes
are early passes and so that should not happen if the function was
invoked from them, the explanation is simple, it is not invoked from
them.  Instead this is some part of mudflap finalization invoked
directly from toplev.c:

#0  fancy_abort (file=0xe07230 "/home/mjambor/icln/src/gcc/tree-inline.c", 
line=4206,
function=0xe08860 "optimize_inline_calls") at 
/home/mjambor/icln/src/gcc/diagnosti
c.c:892 
  
#1  0x00a4ce05 in optimize_inline_calls (fn=0x75237f00) 
  
at /home/mjambor/icln/src/gcc/tree-inline.c:4206

#2  0x00a1d802 in cgraph_early_inlining ()  
  
at /home/mjambor/icln/src/gcc/ipa-inline.c:1757 

#3  0x00756ccf in execute_one_pass (pass=0x1255a00) 
  
at /home/mjambor/icln/src/gcc/passes.c:1556 

#4  0x00756fc5 in execute_pass_list (pass=0x1255a00)
at /home/mjambor/icln/src/gcc/passes.c:1611
#5  0x00a08518 in cgraph_add_new_function (fndecl=0x75237f00, 
lowered=0 '\000')
at /home/mjambor/icln/src/gcc/cgraph.c:2505
#6  0x00a342bf in cgraph_build_static_cdtor_1 (which=73 'I', 
body=0x753e0820,
priority=, final=0 '\000') at 
/home/mjambor/icln/src/gcc/ipa.c:1593
#7  0x004e2683 in mudflap_finish_file ()
at /home/mjambor/icln/src/gcc/tree-mudflap.c:1366
#8  0x007fe3f9 in compile_file (argc=34, argv=0x7fffddf8)
at /home/mjambor/icln/src/gcc/toplev.c:601
#9  do_compile (argc=34, argv=0x7fffddf8) at 
/home/mjambor/icln/src/gcc/toplev.c:1900
#10 toplev_main (argc=34, argv=0x7fffddf8) at 
/home/mjambor/icln/src/gcc/toplev.c:1963

> I don't think we should move
> analysis here nor we should drop the !lowered path (even if it is
> unused currently, cgraph_add_new_function is supposed to work on
> unlowered functions).

I'm not really dropping that path.  cgraph_analyze_function calls
cgraph_lower_function which calls tree_lowering_passes.  It even calls
lower_nested_functions and, perhaps more importantly, sets
node->lowered to true.  But I see that lowered is actually a function
parameter that we should honor so I adjusted my patch slightly to do
that.

Is the explanation above enough to persuade you that the adjusted
patch below is correct?  (Or is there something else I still miss?)

I'm about to re-bootstrap it, just to make sure it still passes.

Thanks,

Martin


2011-03-18  Martin Jambor  

* tree-inline.c (expand_call_inline): Do not check that destination
node is analyzed.
(optimize_inline_calls): Assert that destination node is analyzed.
* cgraph.c (cgraph_add_new_function): Call cgraph_analyze_function, do
not call tree_lowering_passes.
* cgraph.h (cgraph_analyze_function): Declare.
* cgraphunit.c (cgraph_analyze_function): Make public.

Index: src/gcc/tree-inline.c
===
--- src.orig/gcc/tree-inline.c  2011-03-19 01:17:10.0 +0100
+++ src/gcc/tree-inline.c   2011-03-19 01:31:22.0 +0100
@@ -3766,11 +3766,6 @@ expand_call_inline (basic_block bb, gimp
   if (gimple_code (stmt) != GIMPLE_CALL)
 goto egress;
 
-  /* Objective C and fortran still calls tree_rest_of_compilation directly.
- Kill this check once this is fixed.  */
-  if (!id->dst_node->analyzed)
-goto egress;
-
   cg_edge = cgraph_edge (id->dst_node, stmt);
   gcc_checking_assert (cg_edge);
   /* First, see if we can figure out what function is being called.
@@ -4203,6 +4198,7 @@ optimize_inline_calls (tree fn)
   memset (&id, 0, sizeof (id));
 
   id.src_node = id.dst_node = cgraph_node (fn);
+  gcc_assert (id.dst_node->analyzed);
   id.dst_fn = fn;
   /* Or any funct

Re: [objc++] RFH: PR 48167 gengtype failure (issue4291054)

[Mike Stump]

On Mar 18, 2011, at 10:59 AM, Nicola Pero wrote:
> This all looks ugly.  Anyhow, until someone refactors everything, the 
> following
> patch fixes ObjC++ bootstrap in trunk by processing cp/parser.h in the same 
> way
> as the other C++ headers are processed. :-)
> 
> Ok to commit ?

Ok for the Objective parts.  Thanks for the work.