Teensy 4.0 STD Library Compilation Failure

[quadrupel]

I was messing around with code the other day and I came upon a weird compilation error. If I compiled code using std::vector, compilation was successful if I optimized for Faster, Fastest, or Smallest Code. Compilation failed if optimized for Fast, or Debug. The proof-of-concept below will demonstrate the failure for Fast or Debug and succeeds for Faster, Fastest or Smallest Code

/*
vector_error_poc
When set for Optimize: Faster, or Fastest, or Smallest Code  <-- compilation successful
When set for Optimize: Fast or Debug <-- compilation fails
c:/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7e-m/fpu/fpv5-d16\libgcc.a(unwind-arm.o): In function `get_eit_entry':
unwind-arm.c:(.text+0x134): undefined reference to `__exidx_end'
unwind-arm.c:(.text+0x138): undefined reference to `__exidx_start'
 */
#include <vector>
using std::vector;

vector<uint16_t> testArray;
const uint8_t led = LED_BUILTIN;

void setup()
{
  while(!Serial);
  pinMode(led, OUTPUT);
  testArray.push_back(12345);

  Serial.println(testArray[0]);
}

void loop()
{
  bool ledState = !digitalRead(led);
  digitalWrite(led, ledState);
  delay(ledState?25:975);
}

The errors are typical of STD library errors, but why does compilation only fail for Optimize: Fast or Debug?

[defragster]

The 1062 .ld's are missing any spec like the prior Teensy's have :

	.ARM.exidx : {
		__exidx_start = .;
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
		__exidx_end = .;
	} > FLASH

[quadrupel]

i can appreciate that, but the fact that compilation is successful for some optimize options and not others implies .ARM.exidx is not implemented for all optimizations. Or, am I over thinking this?

[defragster]

i can appreciate that, but the fact that compilation is successful for some optimize options and not others implies .ARM.exidx is not implemented for all optimizations. Or, am I over thinking this?

I wondered about that - but not enough to look any farther. Assumed it was maybe a build diff where code doesn't get put into _exidx_??? for faster versions but resides in existing segments not specifying FLASH like on the other Teensy LD's.

[quadrupel]

defragster, thanks for your info on this quirk. It's more of a "what the heck" moment than a show stopper, but I thought I'd share what I'd discovered.

[luni]

I also asked to fix this in 1.52 https://forum.pjrc.com/threads/59767...idx#post230936 but looks like it didn't make it.

[defragster]

@quadrupel - it is great to have things like this noted - especially with usable repro steps so these things can get resolved. Mainline testing for HARDWARE function generally uses the default 'FASTEST' - mostly because that always gave expected results - and other options failed ... and software can get fixed after production - then right after T_4.0 shipped it seems free time at PJRC was spent making the {the coolest Teensy to date} T_4.1 ... made all the harder by the extended Chinese New Year ... that spread worldwide.

I also asked to fix this in 1.52 https://forum.pjrc.com/threads/59767...idx#post230936 but looks like it didn't make it.

COVID strikes again! ...

@luni - repost a link to that on the TD 1.52 B4 thread - given the other .ld files it 'seemed' to be a simple fix. I didn't try the simple looking copy/paste because I figured Paul would better know where it should go.

[Frank B]

@Paul, can you fix this, please?

[PaulStoffregen]

@Paul, can you fix this, please?

I've added this to my list of bugs, but I'm considering it a low priority.

Best to remind me when 1.53-beta1 or 1.53-beta2 is posted. I do not intend to look at this until we're into the 1.53 betas. So many other things are much more important.