can't reproduce documented overflow behavior of _delay_ms()

[Britton Kerin]

On a 16 MHz Arduino Mega 256, this code:

  __builtin_avr_delay_cycles (100.0);   // Compiles, so we apparently have it
  debug_led_on ();
  _delay_ms (290000.0);
  debug_led_off ();
  assert (0);

leaves the debug led on for about 269 s.  Same for larger arguments to
_delay_ms (e.g. 350000.0).  This is different from what this
documentation implies will happen:

  If the avr-gcc toolchain has __builtin_avr_delay_cycles() support,
maximal possible delay is
  4294967.295 ms/ F_CPU in MHz. For values greater than the maximal
possible delay,
  overflows results in no delay i.e., 0ms.

It looks like the result is now the maximum delay, rather than 0ms.
Perhaps __builtin_avr_delay_cycles() has changed?

Also, the documentation for _delay_us() also contains this:

  If the user requests a delay greater than the maximal possible one,
_delay_us() will
  automatically call _delay_ms() instead. The user will not be
informed about this case.

  If the avr-gcc toolchain has __builtin_avr_delay_cycles() support,
maximal possible delay is
  4294967.295 us/ F_CPU in MHz. For values greater than the maximal
possible delay, overflow
  results in no delay i.e., 0us.

This looks suspicious because if _delay_us() calls _delay_ms() for
longer delays, one would
expect the same maximum low-resolution delay as for _delay_ms().  And
in fact this code
behaves as expected (gives 10 seconds with LED on):

  __builtin_avr_delay_cycles (100.0);   // Compiles, so we apparently have it
  debug_led_on ();
  _delay_us (10000000.0);   // 10 s in us
  debug_led_off ();
  assert (0);

but this code delays for only 269s:

  __builtin_avr_delay_cycles (100.0);   // Compiles, so we apparently have it
  debug_led_on ();
  _delay_us (290000000.0);   // 290 s in us
  debug_led_off ();
  assert (0);

So it looks like with recent avr gcc at least my suspicion is correct.

If it would get applied I could prepare a documentation patch for
these issues, but I don't know when the __builtin_avr_delay_cycles()
behavior changed (assuming that's the cause of the above problem).

Britton