[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002 Claus-Justus Heine changed: What|Removed |Added CC||himself@claus-justus-heine. ||de --- Comment #6 from Claus-Justus Heine 2012-03-18 14:50:15 UTC --- Jut a comment: at least I was using -mtiny-stack on targets with 16-bit stack to reduce the size of the prologue/epilogue of a function. This worked quite well, of course only if the actual stack usage really stayed below 256 bytes. With this "fix" this is no longer possible, because now the prologue only loads the lower 8 bits of the stack pointer into the _frame_pointer_. Then the frame-pointer will refer the wrong address region. As a hack-around I'm using (in my own hacked gcc-4.7 version) avr_current_device->short_sp instead of AVR_HAVE_8BIT_SP to decide whether to load SP_H or not into the frame-pointer. Best, Claus
[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002 --- Comment #8 from Claus-Justus Heine 2012-03-18 20:30:06 UTC --- (In reply to comment #7) > (In reply to comment #6) > > Jut a comment: at least I was using -mtiny-stack on targets with 16-bit > > stack > > to reduce the size of the prologue/epilogue of a function. This worked quite > > well, of course only if the actual stack usage really stayed below 256 > > bytes. > > I don't think that works reliably, even if the stack usage is below 256 bytes. > Crucial point is the crossing of a 256-byte boundary, i.e. changing SP.H, for > example while crossing the 0xff/0x100 border. It should work reliably if the stack-top is aligned to a 256 bytes, which is the case for many devices, but of course one has to check this individually. > As there is code in libgcc that has to set the frame pointer, it has to load > the high byte of FP, too. libgcc (just as gcc) assumes that SP.H is always > zero. Yes. Exactly this is the problem: when artificially restricting the stack-space to 256 bytes, then nevertheless the frame pointer high-byte should be initialized with the high-byte of the stack-pointer. > Otherwise, the multilibs had to be split even further, i.e. not only on basis > of SP size but also on basis of RAM size. No. When -mtiny-stack just restricts the stack usage to 256 bytes, then there is no need for additional multi-lib targets. The ABI is not affected. Prerequisites are: - the application really does not need more than 256 bytes stack space - stack-top is aligned to 256 bytes Then: during stack updates no carry will occur from SP_L to SP_H. I can be wrong but I think in the beginning -mtiny-stack was just meant for this kind of optimization. There is also a related commit, which breaks the distinction between 8-bit hardware and -mtiny-stack-8-bit-restricted-stack-space, this was http://gcc.gnu.org/viewcvs?view=revision&revision=150801 However, can be that I'm the only fool which uses -mtiny-stack this way. So what. Still I think originally -mtiny-stack was just introduced for this: reduce the prologue size if one knows that stack usage stays below 256 bytes (and the stack-top is aligned properly). Best, cH
[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002 --- Comment #10 from Claus-Justus Heine 2012-03-18 21:56:35 UTC --- (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > Jut a comment: at least I was using -mtiny-stack on targets with 16-bit > > > > stack to reduce the size of the prologue/epilogue of a function. > > > > This worked quite well, of course only if the actual stack usage > > > > really stayed below 256 bytes. > > > I don't think that works reliably, even if the stack usage is below > > > 256 bytes. Crucial point is the crossing of a 256-byte boundary, i.e. > > > changing SP.H, for example while crossing the 0xff/0x100 border. > > > > It should work reliably if the stack-top is aligned to a 256 bytes, > > No, that's not sufficient. The reason is that gcc does not only change > SP. In some situations the cmopiler has to set up a frame pointer and > build a 16-bit pointer. If the stack pointer in only 8 bits wide, there > is no other sensible value than 0. Sorry, but my comments are just about this: loading the frame pointer with the complete 16bit value of the stack pointer. I will stop the discussion at this point, because I have the impression talk at cross-purposes. I never suggested to tweak the stack pointer, but just realized that recent gcc versions stopped to load the frame pointer with the complete stack pointer value in the presence of -mtiny-stack. I still think that the origin of the "problem" was to "unify" the -mtiny-stack switch with the architectural hardware-constraint of having only an 8 bit stack pointer.
[Bug target/82092] [8/9 regression] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 Claus-Justus Heine changed: What|Removed |Added CC||himself@claus-justus-heine. ||de --- Comment #12 from Claus-Justus Heine --- Still no go, even with that patch: ./auto-host.h:2396:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long And: In file included from /Users/heinecj/Software/src/gcc-8.1.0/build/prev-x86_64-apple-darwin16.7.0/libstdc++-v3/include/cstring:42, from ../../gcc/system.h:235, from ../../gcc/genmodes.c:21: /usr/include/string.h:134:7: note: previous declaration 'char* strsignal(int)' char *strsignal(int __sig); This is OSX Yosemite with that patch mentioned above applied, enable-languages=c,c++,fortran and latest mpc, gmp, mpfr, isl. Cheers
