The following was tested on avr-gcc, but this behavior should not be different on other platforms.

Consider the following array declaration with initialization of all elements to 0:

int main(void)
{
   char arr[256] = {0};
   return 0;
}

In avr-gcc 8.2.0 and before the following asm code is generated:

  9a:	de 01       	movw	r26, r28
  9c:	11 96       	adiw	r26, 0x01	; 1
  9e:	80 e0       	ldi	r24, 0x00	; 0
  a0:	91 e0       	ldi	r25, 0x01	; 1
  a2:	fd 01       	movw	r30, r26
  a4:	9c 01       	movw	r18, r24
  a6:	11 92       	st	Z+, r1
  a8:	21 50       	subi	r18, 0x01	; 1
  aa:	30 40       	sbci	r19, 0x00	; 0
  ac:	e1 f7       	brne	.-8      	; 0xa6 <main+0x1e>

This behavior is what to expect. 256 Bytes of 0 (register r1) is pushed on the stack.

In avr-gcc 9.0.0 (20181118) this code is generated. Here a 256-bytes data field is generated in section .rodata
I don't fully understand the code because in the last three lines, still 0 (register r1) is pushed on the stack! 

  b0:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <__data_start>
  b4:	90 91 01 01 	lds	r25, 0x0101	; 0x800101 <__data_start+0x1>
  b8:	9a 83       	std	Y+2, r25	; 0x02
  ba:	89 83       	std	Y+1, r24	; 0x01
  bc:	fe 01       	movw	r30, r28
  be:	33 96       	adiw	r30, 0x03	; 3
  c0:	8e ef       	ldi	r24, 0xFE	; 254
  c2:	df 01       	movw	r26, r30
  c4:	1d 92       	st	X+, r1
  c6:	8a 95       	dec	r24
  c8:	e9 f7       	brne	.-6      	; 0xc4 <main+0x26>

In this case RAM is wated because of the 256 bytes reserved in .rodata
The examples were compiled with -Os. At first I was thinking this new behavior is the result of some runtime optimization but for -Os, the focus should be laid on code size / memory consumption. So I consider this as a bug!