Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers

[Paul Schlie]

> From: Joerg Wunsch <address@hidden>
>> As Dmitry K. wrote:
>> Also, you can try old setjmp (from your's library). To do it,
>> ...
> Yes, it does (which is basically expected then, obviously).  If I
> comment out the global reg var test, it passes everything else though.
> 
>>> I use avr-gcc 3.3 branch only.
>>> I try 3.4.1: generated code differ !!!
> 
> That probably means we should also make sure it will work on the
> pre-4.0 GCC version.
> 
> As it is now, I'm rather inclined to document that setjmp cannot work
> in environments with global register variables (which are a GCC
> extension anyway) than touching anything that makes it dependent of
> the compiler version.

- actually, global register variables are likely typically more useful
  than setjump/longjump typically is, as being able to specify global
  registers which the compiler leaves alone, is critical to enabling
  the development of small fast interrupt routings, impossible otherwise;
  however, I don't believe that they're properly working presently either.
  (and indirectly another reason that unless someone can figure out how
   to make 64-bit operations significantly more register efficient, 64
   bit type support should likely be intentionally removed, as otherwise
   the definition of a even a few global registers would prevent the
   compiler from being able to allocate enough registers to execute basic
   64-bit operations.)

> There have been rumours though (by Ted Roth) that GCC 4.0 might break
> the ABI which would force us to ship an avr-libc 2.x version for it.
> In that case, we could of course make changes that will only be
> applicable for GCC-4 generated code.

- possibly a valid reason to consider newlib, and alternatively investing
  effort in improving avr target code generation, rather than attempting to
  develop/maintain what may become a version specific asm based C library?

> p.s.: Thank you very much for the test suite, good work!  It took me a
> while to understand what you're trying to do at first, but I much
> appreciate the wide range of tests it is running.

- yes, very much agree.