This is the mail archive of the gcc-help@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: Optimisation puzzle


Erik <sigra@home.se> writes:

> > This is not a bug.  const on an automatic variable in C is more
> > advisory than anything else.  You are not permitted to change a const
> > object, but you can cast its address to a non-const pointer.
> It is a bug. If not in gcc, then in C, that allows the programmers to
> do such strange things, preventing the compiler from optimizing the
> code. The right thing for gcc to do would be to enable such
> optimizations and warn when the code casts away constness, that it
> could break optimized code. I believe that is what gcc already does
> for some stupidities; gcc performs some optimizations that are broken
> by reinterpret_cast and gives "warning: dereferencing type-punned
> pointer will break strict-aliasing rules". So gcc should be modified
> to be useful for users who need the optimization but not the bizarre
> misfeatures of C.

Those uses of reinterpret_cast are actually forbidden by the standard;
that warning is telling you that you are doing something forbidden.
The standard serves as a contract between the compiler and the
programmer.  There are reasons to sometimes modify the standard; it's
not clear that this is one of them.

> Anyway, it is surely a bug that gcc does not optimize away the "pushl
> $77" inside the loop from the Ada program. Unlike C, Ada was not
> designed for ugly hacks, but for clarity and for letting compilers
> perform optimizations. So a promise is a promise. If a function says
> it will not touch something, it won't.

I don't know Ada.

Ian


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