[llvm-bugs] [Bug 47921] New: va_arg() with type 'id' produces incorrect output
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Oct 20 12:26:11 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=47921
Bug ID: 47921
Summary: va_arg() with type 'id' produces incorrect output
Product: clang
Version: 8.0
Hardware: Other
OS: OpenBSD
Status: NEW
Keywords: compile-fail
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangbugs at nondot.org
Reporter: anthonyc at gmx.co.uk
CC: blitzrakete at gmail.com, dgregor at apple.com,
erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
richard-llvm at metafoo.co.uk
Created attachment 24084
--> https://bugs.llvm.org/attachment.cgi?id=24084&action=edit
This reproduces the bug, compile with -DUSE_HACK to apply the workaround
mentioned.
When I use va_arg, providing type 'id', the return values are incorrect.
In the source code I have attached, I have a function taking a variable number
of arguments of type 'id', I pass in 3 arguments, and return the third out of
it. The value of this third agument returned should be equal to the third
argument passed in. However it is not.
When I instead change the type passed to va_arg() to 'void*', (I guess this
works as they're both the same size?), I get the expected result.
I've tried to boil my example code down to demonstrate it as simple as
possible, however this behavior is present when I try to use the GNUstep system
too, and indeed the 'fix' of replacing occurances of va_arg(*, id) with
va_arg(*, void*) results in a completely stable system.
Here's an example shell session using the code I have attached:
netty$ cc bug.m -o bug
netty$ ./bug
netty$ echo $?
1
netty$ cc -DUSE_HACK bug.m -o bug
netty$ ./bug
netty$ echo $?
0
netty$ cc -v
OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1)
Target: powerpc-unknown-openbsd6.7
Thread model: posix
InstalledDir: /usr/bin
netty$ uname -a
OpenBSD netty.my.domain 6.7 GENERIC#714 macppc
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201020/49d08f14/attachment.html>
More information about the llvm-bugs
mailing list