AVR Freaks

Ah, I see. The very curious thing is I remember reading about this years ago. There was a "boundary condition" issue where 0x20 was included instead of just 0x00..0x1F so either that never actually got fixed or there's been a regression.

I'm not sure what the search terms would be but I do remember a thread about this - either find that or check the Bugzilla for avr-gcc and see if there's an issue raised there (and whether it's closed/open).

It's like deja-vu, all over again.

--Yogi Berra
 

https://www.avrfreaks.net/forum/a...

Does the compiler still resolve to the SBI if you "force" it to do the volatile read? [possible workaround?]

SFIOR = SFIOR | stuff;

Already fixed?  From a Studio7 vanilla build:

#include <avr/io.h>
int main(void){

	while (1){
		SFIOR |= 2;
  9e:	80 b5       	in	r24, 0x20	; 32
  a0:	82 60       	ori	r24, 0x02	; 2
  a2:	80 bd       	out	0x20, r24	; 32
		SFIOR = SFIOR | 2;
  a4:	80 b5       	in	r24, 0x20	; 32
  a6:	82 60       	ori	r24, 0x02	; 2
  a8:	80 bd       	out	0x20, r24	; 32
	}
  aa:	f9 cf       	rjmp	.-14     	; 0x9e <main>

Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\ltheusch\Documents\Atmel Studio\7.0\GccApplication1\GccApplication1\GccApplication1.cproj" (target "Build" depends on it):
	Task "RunCompilerTask"
		Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
		C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 4 --output-sync 
		Building file: .././main.c
		Invoking: AVR/GNU C Compiler : 4.9.2
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.1.130\include"  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax -g2 -Wall -mmcu=atmega128 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.1.130\gcc\dev\atmega128" -c -std=gnu99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c" 
		Finished building: .././main.c
		Building target: GccApplication1.elf
		Invoking: AVR/GNU Linker : 4.9.2
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o GccApplication1.elf  main.o   -Wl,-Map="GccApplication1.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mrelax -mmcu=atmega128 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.1.130\gcc\dev\atmega128"  
		Finished building target: GccApplication1.elf
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "GccApplication1.elf" "GccApplication1.hex"
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "GccApplication1.elf" "GccApplication1.eep" || exit 0
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "GccApplication1.elf" > "GccApplication1.lss"
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication1.elf" "GccApplication1.srec"
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "GccApplication1.elf"
		   text	   data	    bss	    dec	    hex	filename
		    176	      0	      0	    176	     b0	GccApplication1.elf
	Done executing task "RunCompilerTask".
	Task "RunOutputFileVerifyTask"
				Program Memory Usage 	:	176 bytes   0.1 % Full
				Data Memory Usage 		:	0 bytes   0.0 % Full
	Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "GccApplication1.cproj".

How does my 4.9.2 relate to OP's 5.4.0? 

And note that the poster in the thread I linked to was using "Studio7"...

A work around forcing indirect access could also read like

void test (void)
{
#if __GNUC__ == 5
    // PR67839
    volatile unsigned char *psfior = &SFIOR;
    __asm ("" : "+r" (psfior));

    *psfior |= _BV(PSR0);
#else
    SFIOR |= _BV(PSR0);
#endif // PR67839
}

Ignore the p-tags, it's a bug in the forum software.

Hence with a volatile psfior you'll want to have it static, then the work-around is vanilla C.