NAS-139162 / 26.04 / call service.started in truesearch.py (#17950)
This is, literally, the single place that `service.get_state` is called
in a plugin. Let's follow paradigm and use `service.started`.
net/frr: Prevent errors in diagnostics view when a frr daemon is not started (#5119)
* net/frr: Prevent errors in diagnostics view when a frr daemon is not started
* Add revision
make: happy new year!
Most of the glue in Makefile belongs to version nowadays, but we
haven't moved the barely moving parts yet. Start with the copyright
block since we're touching it now for the obvious reason.
(cherry picked from commit b7af57327cc7e00642530eefc703fc37c0d1c28b)
[mlir][OpenMP] Implement OutlinableOpenMPOpInterface for Taskloop
The body of taskloop is outlined and so OutlinableOpenMPOpInterface is
needed to ensure that language frontends know not to hoist allocas
outside of the body of taskloop.
The complication here is that taskloop is also a loop wrapper. Currently
some code assumes that taskloop contains only the wrapped loop, and so
there is no place to put the allocas other than in the loop body. This
is obviously not good. Unfortunately LLVM does not seem to be able to
hoist these allocas back out of the loop. The taskloop loop body will
need to contain stack saves and restores, which unfortunately hinder
some optimizations.
I think it is better to land some taskloop in LLVM 22 than not at all.
It will take more work to find an appropriate MLIR representation for
allocas inside of outlinable loop wrappers.
Fix freeing private vars and context struct
I decided not to fix the TODO about zero iteration taskloops because
this is part of a larger problem affecting similar constructs e.g.
ordinary tasks with an if clause that evaluates to false.
[analyzer] Fix BuiltingFunctionChecker crash on large types (#174335)
Previously, if the result type was 'large' (at least 65 bits), then the
ASTContext::getIntTypeForBitwidth would return an empty QualType,
causing later a crash when we assume it's non-empty.
Instead of using this API, we could piggyback on the BigInt type to
formulate a "large enough" type for calculating the mathematically
correct result for the operation to check against.
Crash: https://godbolt.org/z/dGY3vh39a
```c++
void bigint(_BitInt(63) a, _BitInt(63) b) {
_BitInt(63) result = 0;
(void)__builtin_add_overflow(a, b, &result); // crashes here
}
```
Fixes #173795
rdar://166709144
[X86] Add test showing failure to make use of existing concatenated operands for profitable fadd concatenation (#174383)
Since we've already concatenated the fsqrt operands, we only need to concatenate the other fadd operand
