don't assume pointer cast to unsigned long is a valid initializer

[Geoff Keating]

> Cc: rth@redhat.com, gcc-patches@gcc.gnu.org
> From: Alexandre Oliva <aoliva@redhat.com>
> Organization: GCC Team, Red Hat
> Date: 01 Mar 2003 05:46:54 -0300

> On Feb 28, 2003, Geoff Keating <geoffk@geoffk.org> wrote:
> 
> >> The obvious assembler in such a case is
> >> 
> >> x:      .long _text-0x100000001
> 
> >> On some platforms, this may not work, because the appropriate relocs
> >> do not exist, but I don't think there are many such platforms---I
> >> couldn't find even one.
> 
> Any platform that have long wider than pointers probably has this
> problem.  The assumption in the testcase was that long and pointers
> had the same width,

You provide no evidence for either of these two statements, and I have
evidence to the contrary.

This testcase could work on the following platforms:

- MIPS64-ELF (32-bit ELF with 64-bit 'long')
- Xstormy16
- Powerpc-AIX (32-bit but using 64-bit 'long')

and, while I wouldn't try to read the mind of a sequence of bits, you
can see that this is a different testcase from the one that tests the
case where the static data item has the same size as a pointer.

> but this assumption doesn't hold in general.

> > Which can be summarised as "this testcase fails, so let's change the
> > testcase rather than fixing the bug".
> 
> There's no bug in GCC here.  It just can't be assumed that you can put
> symbols in expressions that have a wider mode.  It would have to
> require the compiler, the assembler and the linker to agree on how to
> extend symbols if they appear in relocations wider than the pointer
> type, *if* such relocations exist.  

In fact, such relocations do exist on many platforms, and
there's no reason why GCC should prevent the user from accessing
them.  Sign-extension is already controlled by
POINTERS_EXTEND_UNSIGNED, and I'd hope that the compiler, assembler,
and linker already agree on it---and, if they don't, that's a
bug that this testcase will reveal.

> My position has always been that
> the compiler had better not even try to fix this up, it's just that I
> hadn't run into this testcase before.

Why do you think that the compiler shouldn't do this?  It can do it,
and it's useful to do it.

> Since we already have a correct version of this testcase, I suggest
> that we simply drop this broken one.  Ok to install?

No.  If you want to XFAIL the testcase on your platform, feel free
to do that, but don't delete the testcase.



> > The most fundamental reason is that Alexandre's patch changes this testcase.
> > Changing testcases without changing their name is strongly discouraged.
> 
> I disagree with your reasoning.  You're basically saying automated
> regression testers are more important than the time of the
> developers and than tracking the history of fixes in a testcase that
> was previously broken.

Automated regression testers themselves save time, so your logic is
flawed.

> > Other reasons are that Alexandre's patch makes the testcase an exact
> > duplicate of 20011114-1.c; and that we've had almost this exact patch
> > proposed before, committed, and reverted by me for the first reason above.
. 
> Your reason is also incompatible with:
> 
> > + <p>If a testcase itself is incorrect, but there's a possibility that an
> > + improved testcase might fail on some platform where the incorrect
> > + testcase passed,
> 
> This is not the case of the change I made.

How can you say that?  The last time this change was made, it was
backed out because exactly this happened!

> there is no possible fix except by giving the
> compiler knowledge about the existence of wider (or narrower)
> relocations in the assembler and about policies on sign- or
> zero-extending pointers by the linker and the dynamic linker when
> applying such relocations.  I don't think the compiler has any
> business worrying about this.

I think the compiler does.  The compiler knows about lots of other
things related to the object file format; it knows about the maximum
alignment it can handle, for instance.  Is this testcase much
different from

static int __attribute__((aligned(4096))) x;

for instance?

-- 
- Geoffrey Keating <geoffk@geoffk.org>