Why is there now a difference between "{static const char a[]={...}" and "{const char a[]={...}"?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is there now a difference between "{static const char a[]={...}" and "{const char a[]={...}"?

John Carter-12
https://gcc.godbolt.org/z/6c4QLO

Something changed between gcc 4.1 and 4.4

--
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

--
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer
<http://www.taitradio.com/email_disclaimer>
Reply | Threaded
Open this post in threaded view
|

Re: Why is there now a difference between "{static const char a[]={...}" and "{const char a[]={...}"?

Jonathan Wakely-4
On Tue, 30 Oct 2018 at 02:16, John Carter wrote:
>
> https://gcc.godbolt.org/z/6c4QLO
>
> Something changed between gcc 4.1 and 4.4

I think this changed with https://gcc.gnu.org/r143570 to fix
https://gcc.gnu.org/PR38615

See https://gcc.gnu.org/ml/gcc/2008-11/msg00201.html and
https://gcc.gnu.org/ml/gcc/2008-11/msg00202.html for a more complete
explanation of why the 4.1 behaviour is non-conforming and had to be
fixed.

If you use -fmerge-all-constants you get the old behaviour back, but
as noted in the manual that option makes the program non-confirming.
If your program doesn't rely on stack variables having distinct
addresses in recursive calls, you can probably use that option safely.
Reply | Threaded
Open this post in threaded view
|

Re: Why is there now a difference between "{static const char a[]={...}" and "{const char a[]={...}"?

Jonathan Wakely-4
On Fri, 2 Nov 2018 at 11:11, Jonathan Wakely wrote:

>
> On Tue, 30 Oct 2018 at 02:16, John Carter wrote:
> >
> > https://gcc.godbolt.org/z/6c4QLO
> >
> > Something changed between gcc 4.1 and 4.4
>
> I think this changed with https://gcc.gnu.org/r143570 to fix
> https://gcc.gnu.org/PR38615
>
> See https://gcc.gnu.org/ml/gcc/2008-11/msg00201.html and
> https://gcc.gnu.org/ml/gcc/2008-11/msg00202.html for a more complete
> explanation of why the 4.1 behaviour is non-conforming and had to be
> fixed.
>
> If you use -fmerge-all-constants you get the old behaviour back, but
> as noted in the manual that option makes the program non-confirming.

s/non-confirming/non-conforming/

> If your program doesn't rely on stack variables having distinct
> addresses in recursive calls, you can probably use that option safely.