This is the mail archive of the gcc@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] C undefined behavior fix


> Date: Sat, 5 Jan 2002 20:07:07 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: mike stump <mrs@windriver.com>

> There's one that appears to just clean up the code, so that's fine.

Ok, the specific case is handled for now.

gcc is never going to forsake C.  (statement true for the next 20
years only) Though, the danger as time wears on is few users, little
testing, and reformulating the compiler is a decent language...

As everyone else migrates to C's replacement, hopefully the kernel
will.

If you bet against us putting in more and more optimizations, you'll
loose.  The solution is to not do that, or at least know when you're
doing it.  I can understand when users don't like such optimizations,
and we generally try and understand when they are likely to cause user
impact.  -fno-strict-aliasing makes a fine canonical example of a rude
optimization, and a flag to remove the rudeness.

I don't see much of a way of stopping it.

I think the implications for programming and programming languages and
language design and specification are rather interesting.  The problem
is the standard gives wide latitude in what the optimizer can
optimize, and anytime one tries to be smarter than the compiler, one
will get burned.  As the compiler gets smarter and smarter, the
ability to out-wit the compiler drops, and as this happens, unexpected
bugs bubble up to the surface.

Is it the end of the world?  No.  One solution is to refocus our
efforts by asking for the introduction of additional language elements
that more properly describe what you want from the language/compiler.
By the introduction of formal elements into the langauges and into the
optimizer, one can keep in check the problems that would otherwise
arise.

Also, keep in mind that just people some people might reply and say
certain things certain ways, doesn't define how gcc is.  In the end,
it is what is acccepted by the maintainers, and sometimes the
maintainers and distinctly underrepresented on the lists.

If the ptr->int converstions are really the only interesting cases,
and unless someone wants to argue that these happen in performance
critical code, let's talk about having these drop `knowledge' about
what is going on.

I have a specific proposal.  Lets, in the front end, hence, we avoid
the RTL doesn't have the info problems, when converting from a pointer
to an int, add in a magic asm("") that will appear to read the value,
and will appear to perturb it in some unspecified way and make it
availible for output at the same place it was upon input.  I think
this semantic exactly matches what Linus would like to see, and I
think it would cure certain types of problems.  I believe we already
support all the required semantics in the compiler.  It should be just
a few lines:

   if (converting_to_type == interger_type_node
       && TREE_CODE (converting_from_type) == POINTER_TYPE)
	  x = build_asm_stmt(NULL_TREE, "", ..., NULL_TREE)

to add it.  Any one want to argue against putting it in?  If not,
someone want to add the missing few characters and give it a try?

People could cast to an unsigned integer have have the compiler see
through it.  Only a cast to the exact type int would cause the compiler
to forget what it might have known about the value.

Ok, now that we have a specific proposal on the table, people can
comment on why this cannot solve the problem, or why it isn't this
easy.  Why solving this is bad, or doesn't solve associated problems,
or causes additional headaches for either the compiler developer's or
the compiler users?  I know it is someone magical, but dropping
knowledge doesn't violate anything except for people that see magical
blank lines in the .s file and wonder why they are there, or people
that want an additional, but minor optimization.

Also, people can put in a warning, and compile large bodies of code to
get a feel for how much of an impact on real code this might cause.


Thoughts?


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