Gcc reports wrong vector number if redefined

All vector numbers reported by gcc and avr-objdump are off by one compared to ATMEL docs.

  lines copied from:
  Table 11-6. Reset and Interrupt Vectors in ATmega328P
   8 0x000E TIMER2 COMPA Timer/Counter2 Compare Match A
   9 0x0010 TIMER2 COMPB Timer/Counter2 Compare Match B
  10 0x0012 TIMER2 OVF Timer/Counter2 Overflow

ISR(__vector_8) {
  // do nothing


// vector 8:
  //do nothing

// vector 9:
  // do nothing
  // error:  redefinition of 'void __vector_8()'

void setup() {
  Serial.println("\n" __FILE__);

void loop() {}


Looks like the avr/iom328p.h file provided with the AVR-GCC compiler doesn't agree with the datasheet. In the datasheet, Reset is VectorNo. 1. In the definitions file Reset is Vector 0.

#define TIMER2_COMPA_vect_num 7
#define TIMER2_COMPA_vect _VECTOR(7)   /* Timer/Counter2 Compare Match A */

#define TIMER2_COMPB_vect_num 8
#define TIMER2_COMPB_vect _VECTOR(8)   /* Timer/Counter2 Compare Match A */

#define TIMER2_OVF_vect_num   9
#define TIMER2_OVF_vect   _VECTOR(9)   /* Timer/Counter2 Overflow */

hello John,

I am more than honored to receive an email from the boss personally.

The discrepancy between the iom328p.h and the ATMEL datasheet obviously has existed since the very beginning, and it seems that it will never be abandoned for reasons of compatibility.

Before I sent my posting, I had been looking everywhere for the discrepancy, but couldn't find any clues.

I came across that discrepancy using the avr-objdump.exe in order to understand what code gcc is producing and sometimes to optimize it using the inline assembler.
For all users who, like me, are using the avr-objdump.exe, a reference to this discrepancy would be very useful to compensate for their confusion.
In the meantime I fixed a table next to my monitor telling me both vector numbers ...