On 08/19/2010 01:15 PM, Job Noorman wrote: > On Thursday 19 August 2010 13:24:49 you wrote: >> >> Finally, does the "g" constraint really not work for you with a recent >> gcc? > > It does work. I just forgot to reply on that in my last mail :-) > >> Hmm, this seems to generalize "i" to symbolic constants, but not to >> expressions that yield addresses. > >> ... a translator is not required to do anything in particular with a program >> that has undefined behaviour. > > So basically you are saying that passing an expression that yields > an address to an "i" constraint results in undefined behavior? We know that passing anything other than a constant (which for this purpose seems to include address constants) to an "i" constraint is not defined by gcc's documentation. However, when dealing with things that are as implementation-specific as this it's hard to make a strict boundary between undefined and implementation-defined. There are parts of gcc that are rather underspecified: this is one of them. Traditionally people use the gcc implementation as the specification, and this results in howls of anguish when things later break. > One thing, however: My interpretation of the sentence > > "This includes symbolic constants whose values will be known only at > assembly time or later." > > is that it is allowed to pass "address constant expressions" (5.19.4 > of the C++ standard) because they will be resolved to constants "at > assembly time or later" (at link time). I think so, but wouldn't be prepared to make a categorical statement without taking a vote of the C++ front-end maintainers! However, you cannot guarantee that every CPU allows a full address as an immediate operand. Some only allow short immediates of (say) 20 bits. And on such machines your example would fail. Andrew.
