This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix optimization regression in constant folder


> The flags aren't fixed in stone.  In fact, I just introduced them
> earlier this year.  So all this tells me is that we need to change the
> flags.

Why?  As I keep saying, we already HAVE a flag to denote sizetypes: we
don't need another one but can just use THAT one.  Why muck around with
flags that are designed for an entirely different purpose, namely to
characterize user-visible types.

> Again, it's a big deal because at the moment most of the gcc
> maintainers don't understand the semantics.  After all this discussion
> I still barely have a handle on what you want.  You are talking in
> vague generalities, and you are unable to give us any actual code.
> It's no wonder we remain confused.

It is indeed hard to characterize the semantics of sizetypes in anything
other than a case-by-case manner, as this discussion has shown.  But, as I
said, "the code" is in stor-layout.c: that's where the vast majority of the
sizetype operations are found.  I think the C front end has almost none,
the Ada front end has only a few (mostly related to zero-length arrays),
and I don't know how many the C++ front-end has, but I doubt it's very many
either.  So if we need to understand what types of operations are being
done and what those operations are entitled to assume, stor-layout is the
place to look.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]