From: "Linda A. Walsh" <gcc@tlinx.org>
To: Andrew Haley <aph@redhat.com>
Cc: Bill McEnaney <bill@rkirkpat.net>, gcc-help@gcc.gnu.org
Subject: Re: "gcc" complains about a constant being non constant...
Date: Fri, 10 Jul 2009 21:53:00 -0000 [thread overview]
Message-ID: <4A57B844.5030102@tlinx.org> (raw)
In-Reply-To: <4A5460C1.5030806@redhat.com>
Andrew Haley wrote:
> Linda A. Walsh wrote:
>> Certainly breaks or voids the concept of equivalent expressions being
>> equal.
>
> But they're not equivalent.
> The key thing to remember here:
> A const variable is not a constant.
> const in C is just a type qualifier.
----
You are right -- However, The C Compiler still could do better.
It's not a bug, but would be an RFE in my circumstance.
The reason is that all of my 'const inst' were formed from
Pre-processor known values (none really came from actual runtime computed
data.
I rewrote the program to make it more clear about what the
improvement could have been. I wasn't misunderstanding the word const
(though I could see my meaning was unclear) -- I was using it also as
a descriptive element to remind me that everything that fed into it
came from compile-time constants.
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>
/* start with assumptions true */
/* Note on abbreviations used in defines:
* Ar = Array
* Asigd= Assigned
* Bltn = Builtin
* others, I hope are obvious */
#define PreProc_Groks_sizeof_ConstLenAr_div_sizeof_BltnType_min_one_is_Const 1
#define PreProc_Groks_sizeof_BltnType_AsigdTo_const_int_is_const 0
#define PreProc_Groks_sizeof_ConstLenAr_AsigdTo_const_int_is_const 0
#define PreProc_Groks_const_ints_as_const 1
static const const char * days [] ={
"Sun", "Mon", "Tue", "Wed", "Thu" , "Fri", "Sat"};
#if PreProc_Groks_sizeof_ConstLenAr_div_sizeof_BltnType_min_one_is_Const
static const int last_index = sizeof(days) / sizeof(const char *)-1;
#endif
#if PreProc_Groks_sizeof_BltnType_AsigdTo_const_int_is_const
static const int szof_charptr = sizeof(const char *);
#endif
#if PreProc_Groks_sizeof_ConstLenAr_AsigdTo_const_int_is_const
static const int szof_days = sizeof(days);
#endif
#if PreProc_Groks_sizeof_BltnType_AsigdTo_const_int_is_const
static const int sizeof_charptr = (const) szof_charptr;
#endif
#if PreProc_Groks_sizeof_ConstLenAr_AsigdTo_const_int_is_const
static const int sizeof_days = (const) szof_days;
#endif
static const int num_days = (const) sizeof(days) / sizeof(const char *);
/* fundamental issue boils down to this: PreProc does not understand consts
* assigned values that are only constants determined at Pre Preocessing time
* are not "folded" at Pre-Precessing time when they could.
*
* Not a bug -- just an optimization that could be done
* (an RFE...so nevermind...)
*
*/
#if PreProc_Groks_const_ints_as_const
static const int alt_last_index = (const) num_days - 1;
#endif
int main () {
printf("last_index = %d", last_index);
#if PreProc_Groks_const_ints_as_const
printf(", alt_last_index = %d", alt_last_index);
#endif
printf("\n");
}
/* vim: ts=4:sw=4
*/
The fact that C++ "fixes" this isn't really a difference in the language, it's just a 'next-generation' of the compile time constant folding. In "C" you'd
have to do the same thing using "#define"'s which just looked uglier...
Can you think of any backward incompatibility if "C were to rold compile
time constants the same way C++ did?
Obviously, that optimization would have to be disabled if one tried
to take the address of one of the values that has been folded as a constant.
If you don't have r/o-segment or text-write segment disabled, you could
do this in C:
static const int c=1+1;
int * trouble=&c;
++*trouble;
static const int d=c;
The pre-processor would have to do the same type of optimization disabling detection due to anonymous memory assignments that are sometimes disabled
for similar reasons when detectable at runtime. Hopefully in C++ that'd
throw an exception...
It'd have to say that anyone who got that 'fancy' at compile time should
be strung up and tickled harshly in front of their peers. :-), but it'd
probably eventually happen by accident...to anyone.
-l
next prev parent reply other threads:[~2009-07-10 21:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-06 10:56 "gcc" complains about a constant being non constant...(sorry for dup) Bill McEnaney
2009-07-06 19:13 ` "gcc" complains about a constant being non constant Linda A. Walsh
2009-07-08 9:03 ` Andrew Haley
2009-07-10 21:53 ` Linda A. Walsh [this message]
2009-07-11 0:53 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A57B844.5030102@tlinx.org \
--to=gcc@tlinx.org \
--cc=aph@redhat.com \
--cc=bill@rkirkpat.net \
--cc=gcc-help@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).