https://issues.dlang.org/show_bug.cgi?id=21974

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #1 from Iain Buclaw <ibuclaw@gdcproject.org> ---
On a note of hindsight, the original location of tvalist being in Type was in-fact a good thing, and moving the type to Target will result in a bit of manoeuvring to keep the dmd.cparse happily isolated.

--

https://issues.dlang.org/show_bug.cgi?id=21974

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ImportC, rejects-valid

--

https://issues.dlang.org/show_bug.cgi?id=21974

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Current workaround is to add `typedef` declarations in the "wrapper" sources.

--

https://issues.dlang.org/show_bug.cgi?id=21974

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
What is the typedef you've added to the wrapper sources?

--

https://issues.dlang.org/show_bug.cgi?id=21974

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
As you say, it's problematic to add the __builtin_va_list to cparse, as cparse does not have access to the types.

A simple approach is to have the semantic routines start by adding the declaration for it, rather than cparse.

--

https://issues.dlang.org/show_bug.cgi?id=21974

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Walter Bright from comment #3)
> What is the typedef you've added to the wrapper sources?
For testing purposes.
---
/* Provide user declarations of the built-in va_list type.  */
#if defined(__i386__)
typedef char* __builtin_va_list;
#elif defined(__x86_64__)
typedef struct
{
    unsigned gp_offset;
    unsigned fp_offset;
    void *overflow_arg_area;
    void *reg_save_area;
} __builtin_va_list[1];
#else
#error "unsupported"
#endif
---

It's not the only `__builtin_` that I've written something to provide for. e.g:
---
#define __builtin_bswap16(x) \
    ((u_int16_t) ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8)))
#define __builtin_bswap32(x) \
    ((((x) & 0xff000000u) >> 24) | (((x) & 0x00ff0000u) >> 8) \
     | (((x) & 0x0000ff00u) << 8) | (((x) & 0x000000ffu) << 24))
#define __builtin_bswap64(x) \
    ((((x) & 0xff00000000000000ull) >> 56) \
     | (((x) & 0x00ff000000000000ull) >> 40) \
     | (((x) & 0x0000ff0000000000ull) >> 24) \
     | (((x) & 0x000000ff00000000ull) >> 8) \
     | (((x) & 0x00000000ff000000ull) << 8) \
     | (((x) & 0x0000000000ff0000ull) << 24) \
     | (((x) & 0x000000000000ff00ull) << 40) \
     | (((x) & 0x00000000000000ffull) << 56))
---

I'm currently on the fence really whether we should open the gates for handling `__builtin_` symbols.

--

https://issues.dlang.org/show_bug.cgi?id=21974

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
Those last three look like they were added before gcc could handle inline functions.

--

https://issues.dlang.org/show_bug.cgi?id=21974

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
One theory is if a declaration can be supplied by the library or some source file, it should *not* be built in to the compiler. This:

1. reduces the complexity of the compiler
2. makes it editable by the user
3. means updates can be done without altering the compiler
4. makes it unnecessary to get it to match every version of every C compiler
out there

We do this in D by automatically importing object.d.

I already believe we'll have to supply such a file anyway simply to deal with all the 400 predefines that gcc generates.

--

https://issues.dlang.org/show_bug.cgi?id=21974

--- Comment #8 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Walter Bright from comment #6)
> Those last three look like they were added before gcc could handle inline functions.
More like, it existed before gcc recognized bswap as an intrinsic.

The original code from bits/byteswap.h:
---
static __inline __uint32_t
__bswap_32 (__uint32_t __bsx)
{
#if __GNUC_PREREQ (4, 3)
  return __builtin_bswap32 (__bsx);
#else
  return __bswap_constant_32 (__bsx);
#endif
}
---

--

https://issues.dlang.org/show_bug.cgi?id=21974

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=22307

--