Re: clang/musl progress and a small bug.

[John Spencer <maillist-musl@barfooze.de>]

On 05/26/2012 01:17 AM, Rich Felker wrote:
> On Fri, May 25, 2012 at 04:40:51PM -0500, Richard Pennington wrote:
>
>> I think I found a bug while running my library regression test. The zero test
>> failed in the following code:
>>
>>      TEST_TRACE(C99 7.20.3.1)
>>      p = calloc(100, sizeof(char));
>>      TEST(p != NULL, "calloc() returned a pointer");
>>      int flag = 1;
>>      for (i = 0; i<  100; ++i) {
>>          if (p[i] != 0) {
>>              flag = 0;
>>          }
>>      }
>>      TEST(flag, "calloc() returned zeroed memory");
>>
>> The TEST() macro is kind of like assert but it prints out the message and
>> counts failures and successes:
>>
>> PASS: 001stdlib.c:74: Stdlib(Stdlib): calloc() returned a pointer
>> FAIL: 001stdlib.c:81: Stdlib(Stdlib): calloc() returned zeroed memory
>> Stdlib unit tests completed
>>      32 tests run
>>      1 test failed
>>
>> Am I missing something?
> I'm guessing clang miscompiled calloc.c due to not respecting
> -ffreestanding. There was a related issue reported a while back by
> someone experimenting with clang and musl but I don't know what came
> of it. Basically I think the issue is that clang is treating the
> malloc call calloc makes as a call to the standard malloc, and
> optimizing out inspections calloc makes on the returned memory because
> it's "indeterminate" and thus undefined behavior. This contradicts the
> meaning of -ffreestanding which is to behave as a freestanding C
> environment where malloc and other library functions are not special.
>
> I'm not sure how to work around the issue without making the code
> behave a lot worse. If you can determine this is the issue, I think it
> really calls for a bug report to clang...
>
> Rich
>
has this issue been reported on the LLVM list finally ?
imo this is a major blocker