Displaying 5 results from an estimated 5 matches for "__l".
Did you mean:
__
2019 Sep 03
2
SourceMgr vs EXPENSIVE_CHECKS
...nsion of ‘std::min<int>(std::initializer_list<int>{((const int*)(& ._61)), 6})’
> /usr/include/c++/8/bits/stl_algo.h:3451:31: error: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ called in a constant expression
> { return *std::min_element(__l.begin(), __l.end()); }
> ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
> /usr/include/c++/8/bits/stl_algo.h:5610:12: note: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ is not usable as a ‘constexpr’ function because:
> inline min_element(_Fo...
2019 Oct 02
2
SourceMgr vs EXPENSIVE_CHECKS
...<int>(std::initializer_list<int>{((const int*)(& ._61)), 6})’
>> > /usr/include/c++/8/bits/stl_algo.h:3451:31: error: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ called in a constant expression
>> > { return *std::min_element(__l.begin(), __l.end()); }
>> > ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
>> > /usr/include/c++/8/bits/stl_algo.h:5610:12: note: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ is not usable as a ‘constexpr’ function because:
>> >...
2019 Sep 03
2
SourceMgr vs EXPENSIVE_CHECKS
...xpr’ expansion of
‘std::min<int>(std::initializer_list<int>{((const int*)(& ._125)),
4})’
/usr/include/c++/8/bits/stl_algo.h:3451:31: error: ‘constexpr _FIter
std::min_element(_FIter, _FIter) [with _FIter = const int*]’ called in
a constant expression
{ return *std::min_element(__l.begin(), __l.end()); }
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/8/bits/stl_algo.h:5610:12: note: ‘constexpr _FIter
std::min_element(_FIter, _FIter) [with _FIter = const int*]’ is not
usable as a ‘constexpr’ function because:
inline min_element(_ForwardIterator _...
2008 May 01
0
[LLVMdev] optimization assumes malloc return is non-null
...gt;
> This isn't safe in general unless you can (tightly) bound "n". You
> don't
> want to overflow the stack.
Ah yes, of course. Does LLVM do this for known & small constant n?
(I suppose it could be transformed into:
void f(size_t n) {
bool __opt = n < __L;
char *str = (char*)(opt ? alloca(n) : malloc(n));
// ...
if (!opt) free(str);
}
The payoff is less obvious here.)
> We do delete "free(malloc(n))" though.
Cool.
Daveed
2008 May 01
2
[LLVMdev] optimization assumes malloc return is non-null
On Wed, 30 Apr 2008, David Vandevoorde wrote:
> Note that more interesting optimizations are possible. E.g., it's
> perfectly valid to transform:
>
> void f(size_t n) {
> char *str = (char*)malloc(n);
> // use str[0 .. 99 ]
> free(str);
> }
>
> into
>
> void f(size_t n) {
> char *str = (char*)alloca(n);
> // use str[0 .. 99 ]
> }