Re: [Patch ObjC++] Fix PR32052

On Apr 9, 2010, at 3:54 AM, IainS wrote:
> whilst crawling through the dustier twisty passages of bugzilla...
> 
> OK for trunk?

Ok.  I've checked this in for you.

> and eventually relevant branch(s)?

Yes.  I'll let you do that work when you get back.  158958 is the relevant change, if you like svn merge.

Thanks.

> 2010-04-09  Iain Sandoe  <iains <at> gcc.gnu.org>
> 
> 	PR objc++/32052
> 	* objc-act.c (encode_aggregate_within): Encode structure tags
> 	with template args for ObjC++.
> 
> 2010-04-09  Iain Sandoe <iains <at> gcc.gnu.org>
> 
> 	PR objc++/32052
> 	* obj-c++.dg/encode-2.mm: Remove XFAIL. Add test for anonymous
> 	structure and nested declarations.
> 	* obj-c++.dg/encode-3.mm:  Remove XFAIL. Add test for anonymous
> 	structure and nested declarations.  Reduce header clutter and
> 	use _exit() rather than abort().
> 	* objc.dg/encode-10.m: New.
> 	* objc.dg/encode-11.m: New.
> 

Re: Fix -fsection-anchors on Darwin

On Apr 28, 2010, at 1:06 PM, Jack Howarth wrote:
>   Do you think that Steven will be running into any issues with
> subsections_via_symbols while implementing the Mach-O LTO support
> or can this likely be put off until later? I ask because he thinks
> we could be running into linker bugs.

I suspect it is an assembler bug.  I think the revised code code should reliably work around the bug.  Only
larger scale testing can verify that.  Say, macports with lto on!  

Re: Fix xalancbmk LTO/WHOR ICE

> On Fri, Apr 30, 2010 at 11:28 AM, Jan Hubicka <hubicka <at> ucw.cz> wrote:
> > Hi,
> > with the varpool dumping I broke xalancbmk on LTO (it never worked with WHOPR).
> > The problem is that decl merging attempts to replace variable with a varpool node
> > with variable without.
> 
> It may also break it at -O2:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951

None of the patches should affect non-lto compilation.

Honza

Re: [PING] [PATCH: PR target/42879] Replace "tst r3, 1" with "lsls r3, r3, 31" in thumb2

On Fri, Apr 30, 2010 at 4:27 PM, Richard Earnshaw <rearnsha <at> arm.com> wrote:
>> Since only when both registers are LO_REGS, then the lsls will be
>> encoded as 16bit. Otherwise it is 32 bit, no better than current tst
>> instruction.
>>
>
> Except that at the time the pattern is generated we don't know whether
> or not HI or LO regs will be used (since this is in combine and we are
> still using pseudos).
>
>> With this patch should it fall back to tst instruction when there are HI_REGS?
>
> So your pattern needs to handle the fall-back case as well, when we want
> to generate TST rather than LSLS (note you can use 'X' as a constraint
> for the output in this case to say that you don't need a register).
>

According to your suggestion, I added a new insn pattern to handle it on thumb2.

It passed the regression tests on arm qemu.

ChangeLog:
2010-05-01  Wei Guozhi  <carrot <at> google.com>

       PR target/42879
       * config/arm/thumb2.md (thumb2_tlobits_cbranch): New insn pattern.

ChangeLog:
2010-05-01  Wei Guozhi  <carrot <at> google.com>

Re: [PATCH, MIPS] 74k tuning for divide traps

Jim Wilson <wilson <at> codesourcery.com> writes:
> On Wed, 2010-04-14 at 15:11 -0700, Fu, Chao-Ying wrote:
>>   This involves the replay penalty of teq on 74k, when
>> teq's operand is from a load and there is a load miss.
>
> OK.  This is helpful and makes some sense.  I was able to write a little
> testcase with this info and confirm that it runs faster with the trap
> before the divide.  I revised the patch to include a comment explaining
> what is going on.

Sorry publicly for the long time this patch has been stuck in review.
I got stranded by the Iceland volcano eruption for a couple of weeks
and only got back yesterday.

> 2010-04-09  David Ung <davidu <at> mips.com>
> 	    James E. Wilson  <wilson <at> codesourcery.com>
>
> 	* config/mip/mips.c (mips_output_division): When GENERATE_DIVIDE_TRAPS,
> 	emit the trap instruction before the divide for TUNE_74K.

OK, thanks.

Richard

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

>> It should not be x86_64 specific (well, not in a x86_64 specific place -
>> the pass can still be enabled on a selected set of archs only).
>
> It was originally generic, and it was Paolo (Bonzini) who asked Sri to
> move it to config/i386.  Paolo, are you fine with moving it back to
> generic code?

Yes.  To be clear, I proposed that because I understood that it would
do nothing on other arches and so it would be a waste of compile time.

Paolo

Re: [PATCH, MIPS] SDE -fpic means -mabicalls

Jim Wilson <wilson <at> codesourcery.com> writes:
> The intent of this patch is to fix a historical error, which is that the
> MIPS toolchain is the only one where you can't use -fpic to get PIC
> code.

To be sure I understand, you mean MTI's SDE toolchain rather than the
MIPS GCC port generally, right?  Because all MIPS targets that currently
have full PIC support do indeed allow -fpic to be used to select it.
The problem is that...

> This patch follows the intent of the original MIPS patch which is to
> only change the sde targets.  It might be worth doing this for other
> MIPS targets too.  I think this is a generally good idea, but haven't
> tried to do that at this time.  I noticed that the vxworks target has
> some -fpic support, so that one might need a little work.  The linux
> target already has -mabicalls hard wired on, so this change would not
> affect the linux targets.  And the other targets apparently don't use
> -fpic currently.

...there used to be another form of PIC called "embedded PIC".  And there's
VxWorks PIC, which is different again.  I've also dealt with requests for
a fourth type of PIC that was similar to embedded PIC in not using a GOT,
but which used a different approach.  I therefore think it would be a bad
idea to assume that PIC == -mabicalls for toolchains that have no real PIC
support (like the generic *-elf ones).  If you want to use these toolchains
to generate what amounts to a "foreign"* ABI, I think it's good that you
have to specify the form of PIC that you want.

  [*] Recall that -mabicalls is _not_ link-compatible with -mno-abicalls
      code in the general case.  The former has a function-local GP while

[patch] NetBSD _I386_ANSI_H_/_X86_64_ANSI_H_

Hi,

The patch below addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43952

OK to commit?

Ralf

2010-05-01  Ralf Corsépius <ralf.corsepius <at> rtems.org>

	PR bootstrap/43952:
	* ginclude/stddef.h: Define _MACHINE_ANSI_H_ on for
	{i386,amd64}-netbsd*

Index: ginclude/stddef.h
===================================================================
--- ginclude/stddef.h	(revision 158958)
+++ ginclude/stddef.h	(working copy)
 <at>  <at>  -53,7 +53,14  <at>  <at> 
    one less case to deal with in the following.  */
 #if defined (__BSD_NET2__) || defined (____386BSD____) || (defined (__FreeBSD__) && (__FreeBSD__ < 5))
|| defined(__NetBSD__)
 #include <machine/ansi.h>
+#if !defined(_MACHINE_ANSI_H_)
+/* i386/amd64-NetBSD5's machine/ansi.h doesn't define _MACHINE_H_ */
+#if defined(_I386_ANSI_H_) || defined(_X86_64_ANSI_H_)
+#define _MACHINE_ANSI_H_
 #endif

Re: [PATCH, MIPS] .gnu.attribute support for sdemtk -mno-float

This may be OK, but I want to make sure I understand.

I assume the point of this patch is that you can't currently link
-mno-float objects with -mhard-float objects.  If so...

Jim Wilson <wilson <at> codesourcery.com> writes:
> The mipsisa32r2-sdemtk-elf target supports a -mno-float option, which
> disallows any FP operations.  It uses the -msoft-float ABI, and then
> links with a library without the soft-float routines.  Since it doesn't
> allow any FP operations, it is ABI compatible with all other ABIs with
> respect to FP support.

...why is it relevant that -mno-float links to a library without the
soft-float routines (or indeed any float routines)?  Presumably you
wouldn't be linking with -mno-float if you were combining -mhard-float
and -mno-float objects.

The problem is that I can compile:

  float f (float x, float y) { return x + y; }

using -mno-float without error.  It generates a call to __addsf3.
Now this is admittedly user error, but it isn't flagged by the compiler.
We rely on the linker (and the absence of soft-float routines) to catch
the mistake.

Or to put it another way: -mno-float only differs from -msoft-float in the
way that its libraries are constructed.  There is no difference in the
compiler itself beyond the set of preprocessor macros that are defined.
I'm uncomfortable with the idea of .gnu_attribute being used to model

Re: Patch: PR40900, extending call patterns

On Sat, May 1, 2010 at 00:54, Eric Botcazou <ebotcazou <at> adacore.com> wrote:
>> When finished, it looks like the one below.  Simply setting
>> sign_bit_copies in record_dead_and_set_regs_1 doesn't work, and rather
>> than duplicating the bookkeeping I construct a small piece of RTL to
>> pass to record_value_for_reg that makes it do the right thing.
>>
>> This works without modifying backends, but it has the drawback that it
>> can't optimize indirect calls since we're lacking a decl for them.

REG_EXPR?

> And going back to the Tree level in the RTL combiner is ugly.  Why can PowerPC
> and MIPS already optimize this and not ARM?  That's worth investigating.

True, however promote_function_mode is already being used by combine
for similar reasons (see setup_incoming_promotions), which is why I
suggested it.

Paolo