Cannot get Bit test RTL to cooperate with Combine.

All, I have been debugging AVR port to see why we fail to match so many bit test opportunities. When dealing with longer modes I have come across a problem I can not solve. Expansion in RTL for a bit test can produce two styles. STYLE 1 Bit to be tested is NOT LSB (e.g. if ( longthing & 0x1

Re: Cannot get Bit test RTL to cooperate with Combine.

01:49:39PM -0400, Andrew Hutchinson wrote: All, I have been debugging AVR port to see why we fail to match so many bit test opportunities. When dealing with longer modes I have come across a problem I can not solve. Expansion in RTL for a bit test can produce two styles. STYLE 1 Bit to be tested

Re: Cannot get Bit test RTL to cooperate with Combine.

Why doesn't combine try matching "unsimplified" expressions when it fails? This would at least permit creating patterns based on explicit format of input RTL without the added vagaries of simplification Andy Joern Rennecke wrote: On Sun, Sep 20, 2009 at 01:49:39P

Constraint modifier for partially overlaping operands

Hi I can use "=" modifier to make operands use same register and early clobber "&" to avoid overlaps. Is it possible to have or construct a contraint that permits partial overlap operands. (which neither = or & would allow) The case would be wide types taking multiple hard registers. eg In

Bug in binop rotate ?

I have been adding rotate capability to AVR port and have come across what I think is bug in optabs.c: expand_binop() This occurs during a rotate expansion. For example target = op0 rotated by op1 In the particular situation (code extract below) it tries a reverse rotate of (bits - op1). Wh

Re: Bug in binop rotate ?

Thanks for your review. I have submitted bug report. Richard Guenther wrote: On Sat, Oct 17, 2009 at 3:47 PM, Andrew Hutchinson wrote: I have been adding rotate capability to AVR port and have come across what I think is bug in optabs.c: expand_binop() This occurs during a rotate

Re: Constraint modifier for partially overlaping operands

preffered case - full Using & gives only the no-overlapping case - none Ideally "NOT"= is required - which I would hope the register allocator would quite like too. Dave Korn wrote: Ian Lance Taylor wrote: Andrew Hutchinson writes: I can use "=" modifier t

Re: Constraint modifier for partially overlaping operands

chard Henderson wrote: On 10/16/2009 11:04 PM, Ian Lance Taylor wrote: Andrew Hutchinson writes: I can use "=" modifier to make operands use same register and early clobber "&" to avoid overlaps. Is it possible to have or construct a contraint that permits partial overla

How does builtin_sqrt get used - or not

I am tracking test failure with avr target where function sqrtf is undefined reference at link time. Here is command line: /media/verbatim/gcchead/obj-dir/gcc/xgcc -B/media/verbatim/gcchead/obj-dir/gcc/ /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.dg/pr41963.c -O2 -ffast-math -DSTACK_SI

Need help to correct vla-dealloc testcase

I need advise before I submit pathc to fix the test gcc-torture/execute/vla-dealloc-1.c (attached below) The test appears to be unsafe. The original fault was failure to deallocate VLA on the jump - thus with the fault present the test would appear to perform 1 million new allocation - and fa

Re: Need help to correct vla-dealloc testcase

. Myers wrote: On Sun, 6 Dec 2009, Andrew Hutchinson wrote: The test appears to be unsafe. The original fault was failure to deallocate VLA on the jump - thus with the fault present the test would appear to perform 1 million new allocation - and fail presumably due to either execution time or run

Which optimizer should remove redundant subreg of sign_extension?

I came across this RTL on AVR in combine dump (part of va-arg-9.c test) (set (reg:QI 25 r25 [+1 ]) (subreg:QI (sign_extend:HI (reg:QI 49)) 1)) The sign extension is completely redundant - the upper part of register is not used elsewhere - but the RTL remains unchanged through all the optim

How should I prototype cpp_define in target patch?

I want to post patch for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457 The code moved out to -c.c file ALREADY uses: builtin_define_std cpp_define Both from c-cppbuiltin.c. These have no prototypes defined in gcc. So of course there are warnings emitted. Is this OK? Should I locally defi

Re: How should I prototype cpp_define in target patch?

Doh! Joseph S. Myers wrote: On Wed, 23 Dec 2009, Andrew Hutchinson wrote: builtin_define_std cpp_define Both from c-cppbuiltin.c. These have no prototypes defined in gcc. They do have prototypes, in c-common.h and cpplib.h.

Re: Which optimizer should remove redundant subreg of sign_extension?

Paolo Bonzini wrote: I think that if you add the simplification to simplify-rtx.c's simplify_subreg, combine should pick it up automagically. Paolo There we have it! There is apparently already this optimization performed - so I will have to dig further into why it does not a happen.

Approval as AVR maintainer

How does one get to be maintainer of port? Specifically AVR port - so that I do not need to get approval to commit changes. The time it takes now is rather longer than getting approval on other parts of GCC. The process does not seem to be written down anywhere - but I am sure someone will c

AVR gives weird error with LTO

When AVR target is built, without explicitly disabling LTO, it will produce 1000's of testsuite failures of -LTO -WHOPR tests with this compilation error: "ld: -f may not be used without -shared" Any idea what is wrong or how to make LTO work correctly here? Andy http://gcc.gnu.org/bugzilla/

Re: AVR gives weird error with LTO

Note this is cross compile toolchain. Andy Dave Korn wrote: Andrew Hutchinson wrote: When AVR target is built, without explicitly disabling LTO, it will produce 1000's of testsuite failures of -LTO -WHOPR tests with this compilation error: "ld: -f may not be used without -shared&q

Re: AVR gives weird error with LTO

Dave Korn wrote: Rafael Espindola wrote: It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if i

Re: AVR gives weird error with LTO

Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME "ld" That's indeed going to break LTO. Richard. That seems to be the key issue. Without #define LINKER_N

Success with MinGW and AVR and LTO - almost

I have just succeed in building last snapshot version 4.5.0 20100107 for AVR target with working LTO on both LINUX and MinGW hosts! As noted before #define LINKER_NAME has to be deleted from target avr.h (I will raise patch for this) I also built avr target for MINGW under MSYS and this has

Re: Success with MinGW and AVR and LTO - almost

I think "rb" is nop. However, O_BINARY is less portable. There is another way. If MinGW hosted build is linked with binmode.o - the default for files become binary Some other methods are here: http://oldwiki.mingw.org/index.php/binary Rafael Espindola wrote: I hacked fopen/open calls i

Re: Success with MinGW and AVR and LTO - almost

Kai Tietz wrote: Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but handled). For O_BINARY the common approach here is to do the following condifition before use: #ifndef O_BINARY #define O_BINARY 0 #endif This is a pattern pretty often used. To rely here on binmode.o is a way, t

Re: Success with MinGW and AVR and LTO - almost

Kai Tietz wrote: Well, open call there aren't that much but point of interest is in 'c-pch.c: fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses O_BINARY, too. See also for pattern in libiberty mkstemps.c Regards, Kai It looks like O_BINARY is already defined in system.h, so all

Segmentation fault in df-scan.c

While working on a Cygwin/AVR backend patch, I had segmentation fault occur in df-scan.c - which appears unrelated to target. I can't provide testcase as backend is modfied - but source was 2003-1.c It all happens in df_scan.c (Rev 130805 14 Dec 2007) df_ref_create_structure() trys to a

Re: Segmentation fault in df-scan.c

Alas, enable-checking produced no different result or additional warnings or errors (though it might help me in the future!) I have a work around but don't fully understand why a define_expand should have caused segmentation fault. I believe the issue might be that gcse does not expect to see

Finding out what backend instruction pattern matches instruction

I am working on AVR port and seek advice of the best way working out what instructions patterns have been natched to RTL. This requires adjustment of instruction length to assist branching - when operands are finally known. Before this, worst case lengths are used from pattern length attribut

Re: Finding out what backend instruction pattern matches instruction

e seems optimal. Andy Ian Lance Taylor wrote: Andrew Hutchinson <[EMAIL PROTECTED]> writes: The alternative, perhaps, would be to set each length attribute dynamically in each pattern - if that was possible. But that looks like way more work. That is certainly the best way. S

Excess registers pushed - regs_ever_live not right way?

Register saves by prolog (pushes) are typically made with reference to "df_regs_ever_live_p()" or "regs_ever_live. "|| If my understanding is correct, these calls reflect register USEs and not register DEFs. So if register is used in a function, but not otherwise changed, it will get pushed

Re: Excess registers pushed - regs_ever_live not right way?

not a leaf function (as same register would be preserved by deeper calls) Andy Seongbae Park (박성배, 朴成培) wrote: On Wed, Feb 27, 2008 at 5:16 PM, Andrew Hutchinson <[EMAIL PROTECTED]> wrote: Register saves by prolog (pushes) are typically made with reference to "df_regs_ever_l

Re: Excess registers pushed - regs_ever_live not right way?

> > On Wed, Feb 27, 2008 at 6:03 PM, Andrew Hutchinson > <[EMAIL PROTECTED]> wrote: > >> Register contains parameter that is passed to function. This register >> is not part of call used set. >> >> If this type of register were modified by func

Re: Excess registers pushed - regs_ever_live not right way?

register, > there should be only one def (artificial def) or no def at all. > Or if you want to see all defs for the reg, > follow DF_REG_DEF_CHAIN(). > > Seongbae > > On Wed, Feb 27, 2008 at 6:03 PM, Andrew Hutchinson > <[EMAIL PROTECTED]> wrote: > >> Register

Re: Excess registers pushed - regs_ever_live not right way?

all chains for "possible" arguments to see if that external def is actually used inside function. This can not be shortcut by looking for just any use - or multiple defs as real argument registers can be re-use inside function. Is this conclusion correct? Andy Seongbae Park (박성

Re: Excess registers pushed - regs_ever_live not right way?

/2008-03/msg00115.html best regards and thanks for help. Seongbae Park (???, ???) wrote: 2008/3/1 Andrew Hutchinson <[EMAIL PROTECTED]>: I'm am still struggling with a good solution that avoids unneeded saves of parameter registers. To solve problem all I need to know are th

Problems with builtin setjmp receiver getting eliminated - Help

I have real problems trying to get to the root of bug in builtin_setjmp implementation and seek anyones wisdom on what I have found and a way forward. Sometimes it's not always clear which part is wrong - when presented with mismatches. I will post a bug report when I have got a little clos

Re: Problems with builtin setjmp receiver getting eliminated - Help

pointers? I guess the same problem exists for non-local goto? I am not convinced it could be this wrong. So please comment and suggest solution - I'm sure I can write target handler but it seems so wrong to leave this as issue open. Andy Andrew Hutchinson wrote: I have real problems tryi