Jump to page: 1 2
Thread overview
[Issue 21974] importC: Error: undefined identifier '__builtin_va_list'
[Issue 21974] ImportC: support __builtin_va_list, __builtin_va_start, __builtin_va_arg, __builtin_va_end
May 25
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.

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

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

--
July 05
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.

--
July 16
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?

--
July 16
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.

--
July 16
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.

--
July 17
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.

--
July 17
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.

--
July 18
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
}
---

--
September 16
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

--
« First   ‹ Prev
1 2