public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).