This is an archive of the discontinued LLVM Phabricator instance.

Revert "[SLC] Preserve attrs for strncpy(x, "", y) -> memset(align 1 x, '\0', y)"
AbandonedPublic

Authored by krasimir on Sep 17 2019, 6:47 AM.

Details

Summary

This reverts commit r372101.

Causes ASAN build bot failures:

http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/14176
From http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/14176/steps/64-bit%20check-asan/logs/stdio:

[ RUN      ] AddressSanitizer.StrNCatOOBTest
/home/buildbots/ppc64be-sanitizer/sanitizer-ppc64be/build/llvm-project/compiler-rt/lib/asan/tests/asan_str_test.cpp:462: Failure
Death test: strncat(to - 1, from, 0)
    Result: failed to die.

Diff Detail

Repository
rL LLVM

Event Timeline

krasimir created this revision.Sep 17 2019, 6:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 17 2019, 6:47 AM
krasimir added a reviewer: xbolva00.
This revision is now accepted and ready to land.Sep 17 2019, 7:08 AM

There was several commits touching this code in rapid succession.
This seems to revert rL372101, but what about rL372097, rL372096, and possibly relevant part of D53342/rL372091 ?

xbolva00 accepted this revision.Sep 17 2019, 7:16 AM

Ok, sorry. Will investigate.

This revision was automatically updated to reflect the committed changes.
xbolva00 added a comment.EditedSep 17 2019, 8:26 AM

There was several commits touching this code in rapid succession.
This seems to revert rL372101, but what about rL372097, rL372096, and possibly relevant part of D53342/rL372091 ?

Yeah, but unfortunely. My system GCC 7 does not warn me about that "attrs" bug :/ (testing compiler.h fix currently).

The failed test mentions strncat so yeah, maybe this revert is incorrect - but let's just do it to see.

I checked the new code for strncat again and I see nothing bad.

annotateNonNullBasedOnAccess(CI, 0);
 if (isKnownNonZero(Size, DL))
   annotateNonNullBasedOnAccess(CI, 1);

 // We don't do anything if length is not constant.
 ConstantInt *LengthArg = dyn_cast<ConstantInt>(Size);
 if (LengthArg) {
   Len = LengthArg->getZExtValue();
   // strncat(x, c, 0) -> x
   if (!Len)
     return Dst;
 } else {
   return nullptr;
 }

so for "strncat(to - 1, from, 0)" we eliminate strncat call and return "to - 1" ptr. (patch does not change the behaviour here).

xbolva00 added a comment.EditedSep 17 2019, 8:39 AM

so for "strncat(to - 1, from, 0)" we eliminate strncat call and return "to - 1" ptr. (patch does not change the behaviour here).

No.

char *foo(char *s, char *p) {

return strncat(s, p, 0);

}

GCC
foo(char*, char*):

movq    %rdi, %rax
ret

Clang before https://reviews.llvm.org/rL372091
_Z3fooPcS_: # @_Z3fooPcS_
.cfi_startproc

%bb.0:

xorl %edx, %edx
jmp strncat # TAILCALL

Clang after
_Z3fooPcS_:
.LFB27:
.cfi_startproc
movq %rdi, %rax
ret

But Clang already had pattern for that!

// Handle the simple, do-nothing cases:
// strncat(x, "", c) -> x
// strncat(x,  c, 0) -> x
if (SrcLen == 0 || Len == 0)
  return Dst;

But somehow it wasn't working. I had to reorder the code a bit and it works now (we hadn't test for it, rL372091 added it).

@krasimir for "strncat(s, p, 0);" there is no libcall and probably this is reason why test failed. Could you please fix test for new behaviour? (well, either remove it or change to 1), please? And reland original commit which was reverted.

I am sorry for late investigation, I was out of PC..

Edit: I landed the fix, watching the bot now..

xbolva00 reopened this revision.Sep 17 2019, 8:39 AM
This revision is now accepted and ready to land.Sep 17 2019, 8:39 AM
xbolva00 requested changes to this revision.Sep 17 2019, 8:39 AM
This revision now requires changes to proceed.Sep 17 2019, 8:39 AM

Hey! Thank you very much for your investigations!

Sorry for the late reply, I was out. I was just trying to fix several build bot failures to unblock continuous builds. Wasn't familiar with the details of the patches.

I see you rolled all the fixes for this and rolled forward your updates in r372141 - r372143.

It's pretty cool that we don't get a call in this case anymore!

krasimir abandoned this revision.Sep 18 2019, 2:44 AM