PR3042
Mark Mitchell
mark@codesourcery.com
Sun Jun 10 14:34:00 GMT 2001
>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:
David> There is no difference between Jason's and my
David> proposal.
Actually, there is. With your proposal, some programs will work that
will not with Jason's proposal. Jason's proposal (which is my
proposal but only on AIX) would require explicit instantiations in
some cases where yours would not.
>From Jason's perspective, I think this would make your proposal
superior. From mine, it does not -- I am bothered by the fact that we
handle:
static int i = 7;
differently from:
static int i;
and I think that is confusing to users.
David> fine with static linking. Your proposal would change G++
David> semantics on AIX and other non-WEAK platforms even for the
David> normal case of static libraries and static linking.
Yes, that's true. I claim that would be a good thing. You can
disagree -- as Jason has -- because you feel that my judgement about
the user experience is wrong.
But, most of the arguments you have raised are not well-formed. They
deal with correctness or compatibility -- and these really are not the
issues here. Frankly, you don't seem to understand what the C++
programs in question mean or what the requirements on implementations
are. That makes it very difficult for us to have a productive
discussion about what to do.
David> Your proposal breaks G++ compatibility with IBM's
David> compilers in a gratuitous way.
This is a non-issue -- there is already no compatibility with IBM's
compilers. There's nothing to break here. IBM's compilers use
entirely different methods of managing template instantiation from
G++, and this makes everything different, including what storage
classes it makes sense to use for particular symbols.
David> I also have discussed your
David> proposal with members of IBM's compiler development
David> organization. All feedback was that your proposal was
David> incorrect and courting trouble.
I'm sure the xlC people know what they're talking about. But, I doubt
that they understood my proposal, or the current ways in which G++ is
broken -- otherwise, they would not have drawn the conclusion you
describe.
You're really not giving me very much credit. There's *nothing*
AIX-specific in my proposal -- these are issues that I've thought
through, and understood, and seen implemented in multiple compilers
for about ten years now. These issues existed on a.out GNU/Linux way
back when, they existed on SunOS 4.1.3 in 1995 when I worked on C++
compilers at CenterLine, and so forth. I know what the options are
and I know what the pluses and minuses of the various solutions are.
Different people of course have different opinions about which
solution is optimal, but "incorrect" is not a fair criticism, and
"courting trouble" isn't very specific.
David> the standard. I do not know how to get you and Gaby to
David> stop fixating on implicit instantiation requirements and
David> look at the broader precedent among compilers for
David> flexibility with respect to template instantiation versus
David> static class members.
I honestly have no idea what this means. Using words like `fixating',
though, strikes me as baiting.
David> Having "static" stop working for static libraries
David> seems like more surprise to me, not less.
But, as I've said before, it already does not work, in general.
Let me restate the situation, once again.
1. If you can change the linker flags so that things work, go
ahead and do so. I've already approved this strategy multiple
times. That will leave us in the same broken state we have
been in for ages. AIX will behave exactly like any other
platform we support without weak symbols.
In particular, on platforms without weak symbols, you will need
to explicitly instantiate more things that you should. Here is
an example legal C++ program that will work on GNU/Linux, but not
AIX:
template <typename T>
struct S {
static int i;
};
template <typename T>
int S<T>::i = 7;
int main () { return S<double>::i; }
This program will fail to link on AIX. It probably failed to link
with GCC 2.95, too -- G++ has always been broken in this respect.
No proposal on the table will fix this.
Since you seem to favor this approach, and since I've approved
it, why not implement it, rather than debating these issues
further?
2. We can implement my proposal. Under this proposal, the variant
of the program given above that does not contain `= 7' will not
link. (Under your proposal, it will.) In this sense, the
compiler will become "more broken". On the other hand, the
COMMON in shared libraries problem will be fixed, so in this
sense it will be less broken.
An additional advantage, in my opinion, will be that users will
have a simple plan to follow to make code work on AIX: explicitly
instantiate all static data members. (The plan with the current
code, or with your proposal, is "explicitly instantiate all
initialized static data members, and all static data members
with constructors." I claim that is hard to understand,
unintuitive, and that seemingly innocuous changes to your
program will cause link failures.) Not everyone agrees with me
that this change is an improvement.
AIX will still behave exactly like all other platforms without
weak symbols under my proposal.
3. We can implement Jason's proposal. Under Jason's proposal,
AIX will behave as in 2., but other COMMON platforms will behave
as in 1.
This proposal has the disadvantage of making AIX even more of
an exception. Programs that work on GNU/Linux, and on other
COMMON platforms, may require additional modification to work
on AIX.
However, Jason feels that my arguments about user confusion in
2. are bogus, and so this proposal preserves what Jason sees as
useful functionality on non-AIX COMMON platforms.
I suspect that if the linker flags approach makes things work
on AIX, Jason would withdraw his proposal, and favor 1.
Patches to implement 1. are pre-approved, and I will implement 2. if
we decide that's what we want to do.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
More information about the Libstdc++
mailing list