ia16-elf-c++ misdetects "__far" keyword in extern "C" block

[ecm-pushbx]

It appears that the C++ compiler does not support the __far keyword.

test$ ia16-elf-c++ --version
ia16-elf-c++ (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

test$ ia16-elf-gcc --version
ia16-elf-gcc (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

test$ cat test.c 

#ifdef __cplusplus
extern "C" {
#endif
int strstri(const char __far * str1, const char __far * str2);
#ifdef __cplusplus
}
#endif
test$ ia16-elf-gcc test.c -c
test$ ia16-elf-g++ test.c -c
test.c:5:30: error: expected ‘,’ or ‘...’ before ‘*’ token
 int strstri(const char __far * str1, const char __far * str2);
                              ^
test$ 

[tkchia]

Hello @ecm-pushbx,

It appears that the C++ compiler does not support the __far keyword.

Yes, unfortunately. 🙁 The G++ parser and middle-end do not support named address spaces, at least not yet. This affects all the ports of G++, not just IA-16.

I guess this means you will have to work around the lack of support somehow. (My libi86 tries to do that by defining a partial implementation of far pointers as a C++ class template.)

Thank you!

[tkchia]

Hello @ecm-pushbx,

By the way, a straightforward way to test for __far support, is to check if a __FAR macro (caps) is defined.

Thank you!

[asiekierka]

Nothing something down which seems relevant: It seems Clang, when faced with a similar dilemma, drafted support on top of __attribute__: __attribute__((address_space(1))), for example. (source)

Maybe this would be "cheaper" than adding named address spaces; though certainly not as "nice" as __far in a typical 16-bit C compiler.