This is the mail archive of the gcc-bugs@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]

type control of builtins; `&var;'


I consider it necessary to enable explicit type specification of
builtin functions for particular target and compilation- time type
checking for them.

Lack of such a control has just caused problems on alpha where they
were worked around by refusing to use memcpy -> bcopy transform.  But
anybody may wish to enable this transform again, e. g., for his custom
modification of `standard' target.  It is unlikely that alpha is the
only target where it will cause surprises.  Unless such a control is
implemented, there are chances to break gcc with innocently- looking
modification.

After all, it should be useful to confirm what is said in
http://www.gnu.org/software/reliability.html :)

Since number and semantics of bultins' args is platform- independent,
implementing type control may not require creating complex data
structures at compile time.  All the necessary information might be
stored in small number of scalar constants with reasonable defaults
settable my mere #define's in target headers.

==

A completely unrelated question.  In msg being referenced (of 23.10) I
described a phenomenon that looked strange to me.  With -O2 option a
statement with no possible side effect kept affecting compiler output
and causing otherwise unnecessary use of stack (to allocate a var that
otherwise is stored in register).  What magic combination of
optimization options will fix it?

Please reply by mail.  Remove the obvious from the email address.


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