How to handle address which contain SUBREG

I'm am fixing some reload bugs for AVR. In a couple of situations an address is formed which included a SUBREG expression. I am not sure how I should be handling these. Initial attempts produce sub-optimal code - and/or reload failures, so thought is a good idea to get some advise! Either

How should I disable vectorization test for AVR?

For AVR I get failures of: FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL:

Why does loop-35.c store motion testcase fail for AVR?

Help ! gcc.dg/tree-ssa/loop-35.c is a test that looks for Executing store motion in dump-tree-lim-details As the load and store of memory location should be pulled out of loop. This works for 3 out of 4 tescases. But on AVR target test3() will fail. The only difference between this and

Bugs in dg/struct profilr test - but what was intended?

Hi, In the process of fixing tests for AVR and other small targets I have come across issues with profile tests in gcc/dg/struct that affect all targets and I would like reviewed so I can raise patches to rectify them correctly. Both involve random creating structures then setting and

Re: Help with reload and naked constant sum causing ICE

Thank you very much for reply. reload is such a lonely place! TBH, it sounds like the opposite: LEGITIMIZE_RELOAD_ADDRESS should not be handling this address at all. Yes but reload will not do anything before call to L_R_A. So in practice that would mean L_R_A has to check

Re: Help with reload and naked constant sum causing ICE

If L_R_A does nothing with it, the normal reload handling will first try: (const:HI (plus:HI (symbol_ref:HI (chk_fail_buf) (const_int 2 This worked just as your described after I added test of reg_equiv_constant[] inside L_R_A . So I guess that looks like the fix for bug I

Re: Where is setup for goto in nested function created?

Thanks Ian! I found it in function.c (expand_function_start) emit_move_insn (r_save, virtual_stack_vars_rtx); Whereas it should be emit_move_insn (r_save, targetm.builtin_setjmp_frame_value ()); to match same construction used for setjmp. thanks for help! Ian Lance Taylor

Re: Whats going on with the conversion warning?

correctly for AVR or post a bug. best regards Andy Manuel López-Ibáñez wrote: 2008/5/20 Andy H [EMAIL PROTECTED]: I came across this odd issue with testsuite test Wconversion-5.c and AVR target. I should get warning going from a unsigned value that is wider than signed result. Yes. You

Whats going on with the conversion warning?

I came across this odd issue with testsuite test Wconversion-5.c and AVR target. I should get warning going from a unsigned value that is wider than signed result. As I am not skilled in the art of the all conversions rules. I would appreciate some guidance before I report this as bug.

How do I add target specific tests?

I want to add target specific tests for AVR. These would be testcases for PR that fail related to AVR back end problems - rather than testcases for generic PR. Do I just add them to directory testsuite/gcc.target/avr? Or are there some other configuration steps needed? Andy

Re: Problem with reloading in a new backend...

Take at look at AVR target which is very similar. Here onluy d constrained register accept constants (they are call used registers too) The AVR move pattern (*reloadinqi) has multiple constrain options d against i being relevant. So check you have all the combinations defined. You omitted i

Re: RFC Test suite fix testing of no_trampolines

Thank you so much. I can test it easily and will let you know of any divergence from original other than the those you mention. Andy Janis Johnson wrote: On Sat, 2008-04-05 at 06:57 -0400, Andy H wrote: There are several test in testsuite that use trampolines that are still run

RFC Test suite fix testing of no_trampolines

There are several test in testsuite that use trampolines that are still run with dejagnu switch set to no_trampolines. Its on my TODO list for AVR target but a recent email reminded me that it affects testing of other targets than can't or won't support trampolines. Theres an old patch

Re: How to avoid stack calling for trapoline code?

no_trampolines Dejagnu switch will omit many but not all trampoline dependent tests. Nested function are ok - but anything that takes an address of a nested function will use trampoline. They can be hard to find as testcases are devilish at hiding that part! For example:

Forward propagation before register allocation

I have been working on AVR port and have come across many instances where poor code is produced due to the absence of effective forward propagation of operands before register allocation. The AVR target in particular benefits from register lowering pass as many physical registers and

Combine repeats matching on insn pairs and will ICE on 3.

Hi, I have problem with data flow and combine that is causing ICE with experimental build. Despite all efforts to blame my own target changes, I have reached the conclusion that this is a gcc COMBINE bug, but seek your advice before filing a bug report. The problem seems to be that the

Re: Redundant logical operations left after early splitting

I very grateful for your help and wisdom Testcase and MD Patch attached unsigned long f (unsigned char *P) { unsigned long C; C = ((unsigned long)P[1] 24) | ((unsigned long)P[2] 16) | ((unsigned long)P[3] 8) | ((unsigned long)P[4] 0); return C; } Index: avr.md

Re: Redundant logical operations left after early splitting

Paolo, As you suggested, I moved the extra fwprop nearer combine, just after split - but it failed to propagate anything. The reason is that immediately post split the data flow is reflecting cross dependencies between Word and subreg U/D. So the USE of just 1 QImode subreg of SImode

Re: Redundant logical operations left after early splitting

I tried extra fwprop pass and got some very interesting results! First caveat I just cut/pasted extra pass into list - nor worrying about detail. NEXT_PASS (pass_rtl_fwprop); NEXT_PASS (pass_local_alloc); To show effects here is assembler code dump (which is easier to read than

Re: Redundant logical operations left after early splitting

Dave and Jeff, Here are more details and I have include testcase, splitter patterns and RTL dump to show problem in more detail. The testcase is: unsigned long f (unsigned char *P) { unsigned long C; C = ((unsigned long)P[1] 24) | ((unsigned long)P[2] 16) | ((unsigned long)P[3]