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: stab info for const fields


Richard Kenner writes:
 >     You seem to have smipped
 > 
 >        Most of the time there is just one, well-defined, conversion
 >        operation that makes sense in any such context.  If there is none,
 >        or if there could be multiple intended semantics, the tree is
 >        ill-formed; the middle-end will abort if handed such a tree.
 > 
 >     So the question becomes: "in what circumstances is there just one,
 >     well-defined, conversion that makes sense?"  If we properly define
 >     those circumstances the problem is solved.
 > 
 > Well, that's exactly what we're trying to do: to "properly define" what
 > "implicit conversions" are valid.  What is your proposal?
 > 
 > To restate the four that we've talked about into that terminology, they are:
 > 
 > (1) None.
 > (2) Only between types whose TYPE_MAIN_VARIANT are the same.
 > (3) Some other, language-independent formulation.
 > (3a) A language-dependent formulation.
 > 
 > So we're back to the original question.

I believe that Zack implicitly meant (3), using a superset of (2).
This has the advantage of economy because we won't be generating tree
nodes for many implicit conversions.

For example, we might decide that widening signed and unsigned
integers is well-defined, whereas narrowing is not.

Andrew.


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