http://bugzilla.gdcproject.org/show_bug.cgi?id=167

--- Comment #1 from Johannes Pfau <johannespfau@gmail.com> ---
(In reply to Johannes Pfau from comment #0)
> We set Tptrdiff_t and Tsize_t in d-target.cc, but we do not update Type::tsize_t and Type::tptrdiff_t.
> 
> I wonder whether we could just call Target::init before Type::init and remove the if(global.params.isLP64) logic from mtype.c.

OK, Target::init depends on d_backend_init which probably depends on some stuff from Type::init. I guess the next best solution is overwriting Type::tsize_t, Type::tptrdiff_t in Target::init?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=167

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> ---
One of the eventual plans was to encapsulate all isXXX params from Global into Target - removing them from the front-end.  I suppose this is to support 16bit (or less) micro-controllers?

Target::init actually depends on d_backend_init being called first, which in turn relies on Type::init and Id::initialize (for generating the va_list type in D AST form) - so re-arranging as is wouldn't be an option.

As nothing really uses anything set by Type::init up to that point, you can just override field values with the correct one.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=167

--- Comment #3 from Johannes Pfau <johannespfau@gmail.com> ---
Yes, I hit this issue with 8bit AVRs (pointers/size_t is 16 bit on AVR although registers are 8bit). Maybe a clean solution is to split Target::init / Target::init2 and use Target::sizetsize in Type::init? However, overwriting Type::tsize_t seems to work for now.

A related question: in d-codegen.cc::build_offset
tree ofs = fold_convert (Type::tsize_t->toCtype(), byte_offset);

shouldn't this use tptrdiff_t? I think this code could break if wordsize and
pointer size are different.
However, simply changing this to tptrdiff_t breaks the build. I guess we'd
really need a unsigned tptrdiff_t.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=167

--- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Johannes Pfau from comment #3)
> Yes, I hit this issue with 8bit AVRs (pointers/size_t is 16 bit on AVR although registers are 8bit). Maybe a clean solution is to split Target::init / Target::init2 and use Target::sizetsize in Type::init? However, overwriting Type::tsize_t seems to work for now.
> 

Adding more inits won't help.  Moving the isLP64 logic (and subsequent setting of Type::tsize/tptrdiff would.


> A related question: in d-codegen.cc::build_offset
> tree ofs = fold_convert (Type::tsize_t->toCtype(), byte_offset);
> 
> shouldn't this use tptrdiff_t? I think this code could break if wordsize and
> pointer size are different.
> However, simply changing this to tptrdiff_t breaks the build. I guess we'd
> really need a unsigned tptrdiff_t.

Yah, there has been an agreement for quite some time now that size_t/ptrdiff_t types don't really mean their C equivalents in the truest sense.  Both should be the same size.  So if in doubt, just use POINTER_SIZE to determine the correct size_t/ptrdiff_t type in D.

We still have __builtin_machine_[u]int and __builtin_pointer_[u]int for C ABI reasons.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=167

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I'm going to make a final decision on this.  size_t/ptrdiff_t should always
match what we have in object.d which is either a (u)int or (u)long.

So using that as a basis, I suggest we close with the following PR.

https://github.com/D-Programming-GDC/GDC/pull/190

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=167

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

-- 
You are receiving this mail because:
You are watching all bug changes.