From: SourceForge.net <no...@so...> - 2006-03-28 17:26:18
|
Bugs item #1453093, was opened at 2006-03-18 11:40 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1453093&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: msc51(8051) target Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Stas Sergeev (stsp) Assigned to: Nobody/Anonymous (nobody) Summary: relocation error (peephole) Initial Comment: Hi. The following program (attached) cannot be compiled with the sdcc code from CVS: --- static idata unsigned char f[1]; static unsigned char tst; unsigned char main() { idata unsigned char *ptr = f; while (ptr < f) tst = *ptr++; return tst; } --- $ sdcc ptrbug.c ?ASxxxx-Error-<r> in line 137 of ptrbug.asm <r> relocation error removing ptrbug.rel ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2006-03-28 19:26 Message: Logged In: YES user_id=589052 > Could you please clarify/confirm that its a peephole's > fault? I am quite ignorant about that asm semantic, but > I suspect that maybe an assembler is really guilty here? The problem with peephole 132.e was that it was applied to a symbol (resulting in a negative sign before a symbol, which causes the relocation error "mov a,#0x100 - _f") > and perhaps it would be better to leave this bug > open for now? If it is closed, then it is likely > to never be properly addressed. :( You're right - reopened. There are probably three approaches to address it (in the order of my preference) : a) modifying genCMP that it includes the tricks of 132.a-e, b) introduce an additional Peephole condition checking for non_symbols, c) remove 132.a-d (most likely an overkill as SDCC probably doesn't generate code which would match the peephole AND is using a symbol). ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-28 18:57 Message: Logged In: YES user_id=501371 > fixed with SDCC version #1230 by disabling peephole 132.e Could you please clarify/confirm that its a peephole's fault? I am quite ignorant about that asm semantic, but I suspect that maybe an assembler is really guilty here? > Note: peepholes 132.a-d are still lurking there. Exactly - thats what I did locally too, but thats the problem, and perhaps it would be better to leave this bug open for now? If it is closed, then it is likely to never be properly addressed. :( > Ideally the > optimizations of rules 132.x should be done in genCmpXX But are you sure that the assembler should not be fixed instead? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-03-28 08:37 Message: Logged In: YES user_id=589052 fixed with SDCC version #1230 by disabling peephole 132.e Note: peepholes 132.a-d are still lurking there. Ideally the optimizations of rules 132.x should be done in genCmpXX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1453093&group_id=599 |