Basile STARYNKEVITCH wrote:
I believe that Kiril mentioned in a separate post the equation
(mcs | csc | cscc) & gcc & libJIT == LLVM ?
I tend to believe that Kiril dreams of building a CLI/.NET
infrastructure and VM which uses all the powerful optimisations of GCC.
For reference to Kiril:
Hi all,
I'm going on brutalizing GIMPLE code to make it more suitable for CIL emition in
the CLI be/fe branch and I've stumbled across something which looks really weird.
When working with types I always assumed that if 't' is a RECORD_TYPE,
UNION_TYPE or QUAL_UNION_TYPE then calling DECL_FIEL
Dave Korn wrote:
On 10 January 2008 16:12, Gabriele SVELTO wrote:
> [snip]
>
A new type still named 'struct try' is used in the COMPONENT_REFs of
this function but this type has a different TYPE_UID from the 'struct try'
used in main. Since the original type was loca
Dave Korn wrote:
On 10 January 2008 16:40, Gabriele SVELTO wrote:
Yes, you're completely correct about the artificial initialiser function; I
thought the compiler might output it as a nested function, but I don't know
without checking. (But I've been working on gcc for onl
Tom Tromey wrote:
"Gabriele" == Gabriele SVELTO <[EMAIL PROTECTED]> writes:
Gabriele> Good to know, TYPE_MAIN_VARIANT () is exactly what I was
Gabriele> looking for, unfortunately it's description in tree.def
Gabriele> isn't exactly crystal clear :P Thank y
Hello everybody,
I started working on the GCC CLI back end just a few weeks ago and I'm having
some trouble declaring new fields and adding them to an already existing
structure. I'm still fairly unfamiliar with gcc's code so please bear with me :)
Since CLI doesn't support bit-fields I am tr
Ian Lance Taylor wrote:
Are you emitting CLI directly from GIMPLE?
Yes, we emit gimple right before GIMPLE is transformed into RTL so our code
doesn't go through the RTL-only optimizations
It may help to look at
store_bit_field and extract_bit_field so see how this sort of thing is
handled
built in the first place
and how to keep it up to date with the transformed code.
Sorry for the long post but I'm really stuck and even looking at the other
passes and internal documentation didn't provide much clues about how to deal
with this problem.
Gabriele Svelto
Richard Guenther wrote:
This transformation is indeed invalid according to our type-based alias
rules. There is no 'easy' way to make it work (well, force
-fno-strict-aliasing)
other than to make the access through a pointer to a union. That is:
union {
struct s;
long long int x;
} *cilsim
