On Wednesday, 25 July 2018 at 10:05:50 UTC, Mike Franklin wrote:
On Wednesday, 25 July 2018 at 08:37:28 UTC, Zheng (Vic) Luo
wrote:
Current implementation of compilers assumes the existence of
some symbols from libc, which leads to an infinite loop if we
want to implement primitives like "memset" with our own code
because the compiler will optimize consecutive set with
"memset". This suggests that we cannot write a freestanding
program without supports from compiler. With "-betterC" flag,
dmd/gdc/ldc also come into this issue[5], which also applies
to C/C++[1] and rust [2][3][4].
GDC doesn't seem to be affected. See
https://explore.dgnu.org/g/ZJVjAu i.e. no recursive calls to
`memset`, but I don't know if I just got lucky with my
implementation.
It would be better to provide a standard flag like
"-ffreestanding" (or -fno-builtin?) to disable such
optimizations to facilitate freestanding programming instead
of forcing the developers to hack around different compiler
implementations, so I was wondering is there any progress on
this problem?
According to https://wiki.dlang.org/Using_GDC, `-fno-builtin`
is already there.
From my experience I haven't yet found a need for
`-ffreestanding`, as GDC always seems to do the right thing for
me. It does generate calls for `memset`, `memcmp`, etc..., but
as long as I provide my own implementation with the correct
symbol name as it expects (i.e. `memset` with no name mangling,
a.k.a `extern(C) void* memset(void*, int, size_t)`) it seems to
work fine.
Mike
The real problem is that current D toolchain makes no promise
about the generation of calls to libc: When are they called/Which
subset is called/How to disable the calls? What if users embed
this memset snippet in their own function? Instead of forcing
developers to avoid memset-like access pattern in a freestanding
environment and increasing their mental burden, a universal flags
to disable these the generation of these calls will probably be a
better choice.
