tambre added a comment. In D77491#2299938 <https://reviews.llvm.org/D77491#2299938>, @rsmith wrote:
> We've hit a fairly subtle miscompile caused by this patch. > > glibc's setjmp.h looks like this (irrelevant parts removed): > > struct __jmp_buf_tag { /*...*/ }; > extern int __sigsetjmp(struct __jmp_buf_tag __env[1], int); > typedef struct __jmp_buf_tag sigjmp_buf[1]; > #define sigsetjmp __sigsetjmp > > This worked fine with the old approach. But with the new approach, we decide > the declaration of `__sigsetjmp` is not a builtin, because at its point of > declaration, we can't compute the "proper" type because `sigjmp_buf` has not > been declared yet. As a result, we don't add a `BuiltinAttr` to > `__sigsetjmp`, but much more critically, we don't add a `ReturnsTwiceAttr`, > which results in miscompiles in calls to this function. (I think `sigsetjmp` > is the only affected function with glibc. `jmp_buf` is declared prior to > `__setjmp` and friends.) > > I suppose we don't actually care what the parameter types for `__sigsetjmp` > are, and it would be fine (and much safer) to treat any function with that > name as a builtin, like we used to. Perhaps we should have a way of marking > builtins as "the given type is what we expect / what we will implicitly > declare, but it's OK if it doesn't actually match"? Marking `__sigsetjmp` as having custom typechecking should suffice (`t` attribute in Builtins.def), no? Though a case in `Sema::CheckBuiltinFunctionCall()` might also then be necessary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77491/new/ https://reviews.llvm.org/D77491 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits