search for: x86_f80

...ter or garbage pointer into an API that would then bus error. Besides invalid IR, codegen also uses abort and assert when it encounters valid and Verifier-clean IR that uses features that codegen does not suport, due to missing functionality (e.g. i1024) or due to target-specific limitations (e.g. x86_f80 on non-x86 targets). Currently there no way to recover if the IR contains some construct that codegen can't handle. This is unfortunate for some applications. Dan

...nto an API that would then bus error. > > Besides invalid IR, codegen also uses abort and assert when it > encounters valid and Verifier-clean IR that uses features that > codegen does not suport, due to missing functionality (e.g. i1024) > or due to target-specific limitations (e.g. x86_f80 on non-x86 > targets). There are also some cases with inline asm that do the same thing. > Currently there no way to recover if the IR contains some > construct that codegen can't handle. This is unfortunate for some > applications. I completely agree, but these should not be fix...

...gnment. There is no need to allocate more than 10 bytes for scalars of this type, and we currently don't for stack objects. (The code you point to in visitAlloca does look like it might be a problem, but I can't make it fail. Known-size arrays appear here as a single object [3 x x86_f80], and the size is computed correctly; unknown-size arrays have the size of the elements passed from the FE, and this includes padding. How does that size*count computation get executed?)

Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking