search for: cwg_defect

...ayer.h:314:29: > warning: redundant move in return statement [-Wredundant-move] > 314 |         return std::move(Err); Note that the move (into the implicit JITSymbol(Error) ctor) is only redundant if the compiler implements a fix for <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> "Return by converting move constructor". (But not sure whether the LLVM compiler baselines imply that, anyway. In LibreOffice it forced me to introduce ugly #ifs, to not have to disable that warning outright, <https://cgit.freedesktop.org/libreoffice/core/commit/?i...

...move in return statement [-Wredundant-move] >> > 314 | return std::move(Err); >> >> Note that the move (into the implicit JITSymbol(Error) ctor) is only >> redundant if the compiler implements a fix for >> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> >> "Return by converting move constructor". (But not sure whether the LLVM >> compiler baselines imply that, anyway. > > > Looks like that was accepted for C++14, not 11. So I don't believe it's > valid to remove the std::move in C++11 code....

C says that plain bit-fields could be either signed or unsigned. C++ removed this allowance in core issue 739: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739 On Sat, Nov 16, 2013 at 1:55 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > > > I don’t have the C/C++ standards in front of me but IIRC whether a > char/short/int/long/l...

...ove] >>>> > 314 | return std::move(Err); >>>> >>>> Note that the move (into the implicit JITSymbol(Error) ctor) is only >>>> redundant if the compiler implements a fix for >>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> >>>> "Return by converting move constructor". (But not sure whether the >>>> LLVM >>>> compiler baselines imply that, anyway. >>> >>> >>> Looks like that was accepted for C++14, not 11. So I don't believe i...

On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > I don’t have the C/C++ standards in front of me but IIRC whether a char/short/int/long/long long bitfield is signed or unsigned is implementation defined. You need to explicitly specify signed or unsigned in order to have any guarantee of the signedness, e.g. signed int. Section 3.9.1 of the C++11 standard [1]

...gt; category. Is that how LLVM treats them? With the current version of LLVM, there is slightly a gap, and with our suggestion this becomes correct. https://godbolt.org/z/nxhnTK Reading padding is optimized to undef, but according to the previous link ( http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1787), this isn't valid because unspecified value is a 'stable' value. In our suggestion, well-defined bits are stored into padding at object creation, so it becomes okay. Juneyoung On Fri, Oct 9, 2020 at 11:58 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote:...

...the second x is initialized with its own (*indeterminate*) value. —end example] ``` It seems there was a phrase saying that reading indeterminate value as an unsigned char should yield unspecified value in the C++14 draft in the past, but it is removed: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1787 The removed phrase did not exist in C++11, so I believe it is fine to use poison for uninitialized char types. Juneyoung On Fri, Oct 9, 2020 at 12:19 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Thu, Oct 8, 2020 at 11:09 PM Juneyoung Lee <juneyoung.lee...

...14 | return std::move(Err); >>>>>> >>>>>> Note that the move (into the implicit JITSymbol(Error) ctor) is only >>>>>> redundant if the compiler implements a fix for >>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> >>>>>> "Return by converting move constructor". (But not sure whether the >>>>>> LLVM >>>>>> compiler baselines imply that, anyway. >>>>> >>>>> >>>>> Looks like that was acce...

Hello, GCC 9.0 introduces a new warning checkers and some of them found possible issues in LLVM. In file included from /home/davidbolvansky/trunk/llvm/include/llvm/Analysis/LazyCallGraph.h:38, from /home/davidbolvansky/trunk/llvm/unittests/Analysis/LazyCallGraphTest.cpp:10: /home/davidbolvansky/trunk/llvm/include/llvm/ADT/ArrayRef.h: In instantiation of

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we