Is there an existing issue for this?
Problem statement
The documentation for __log2_up() states that the function computes log2 rounded up, as illustrated by the following examples:
/** \brief Calculate log2 rounded up
* - log(0) => 0
* - log(1) => 0
* - log(2) => 1
* - log(3) => 2
* - log(4) => 2
* - log(5) => 3
* : :
* - log(16) => 4
* - log(32) => 5
* : :
* \param [in] n Input value
* \return log2(n)
*/
Testing the current implementation shows that its behavior does not consistently match the comment. In my opinion, the expected result should correspond to ceil(log2(n)), but the function returns a lower value:
__log2_up(00)=0 vs. ceil(log2(00))=-2147483648
__log2_up(01)=0 vs. ceil(log2(01))=0
__log2_up(02)=1 vs. ceil(log2(02))=1
__log2_up(03)=2 vs. ceil(log2(03))=2
__log2_up(04)=2 vs. ceil(log2(04))=2
__log2_up(05)=3 vs. ceil(log2(05))=3
__log2_up(06)=2 vs. ceil(log2(06))=3
__log2_up(07)=3 vs. ceil(log2(07))=3
__log2_up(08)=3 vs. ceil(log2(08))=3
__log2_up(09)=4 vs. ceil(log2(09))=4
__log2_up(10)=3 vs. ceil(log2(10))=4
__log2_up(11)=4 vs. ceil(log2(11))=4
__log2_up(12)=3 vs. ceil(log2(12))=4
__log2_up(13)=4 vs. ceil(log2(13))=4
__log2_up(14)=3 vs. ceil(log2(14))=4
__log2_up(15)=4 vs. ceil(log2(15))=4
__log2_up(16)=4 vs. ceil(log2(16))=4
__log2_up(17)=5 vs. ceil(log2(17))=5
__log2_up(18)=4 vs. ceil(log2(18))=5
__log2_up(19)=5 vs. ceil(log2(19))=5
__log2_up(20)=4 vs. ceil(log2(20))=5
__log2_up(21)=5 vs. ceil(log2(21))=5
__log2_up(22)=4 vs. ceil(log2(22))=5
__log2_up(23)=5 vs. ceil(log2(23))=5
__log2_up(24)=4 vs. ceil(log2(24))=5
__log2_up(25)=5 vs. ceil(log2(25))=5
__log2_up(26)=4 vs. ceil(log2(26))=5
__log2_up(27)=5 vs. ceil(log2(27))=5
__log2_up(28)=4 vs. ceil(log2(28))=5
__log2_up(29)=5 vs. ceil(log2(29))=5
__log2_up(30)=4 vs. ceil(log2(30))=5
__log2_up(31)=5 vs. ceil(log2(31))=5
__log2_up(32)=5 vs. ceil(log2(32))=5
As a result, the implementation is incorrect and does not satisfy its documented behavior, or the documentation is misleading and should be updated to reflect the actual algorithm.
An underestimated result from __log2_up() may lead to incorrect calculations in components relying on cache geometry parameters, potentially affecting cache maintenance operations (e.g. __L1C_MaintainDCacheSetWay function).
Steps To Reproduce
No response
Is there an existing issue for this?
Problem statement
The documentation for __log2_up() states that the function computes log2 rounded up, as illustrated by the following examples:
Testing the current implementation shows that its behavior does not consistently match the comment. In my opinion, the expected result should correspond to ceil(log2(n)), but the function returns a lower value:
As a result, the implementation is incorrect and does not satisfy its documented behavior, or the documentation is misleading and should be updated to reflect the actual algorithm.
An underestimated result from __log2_up() may lead to incorrect calculations in components relying on cache geometry parameters, potentially affecting cache maintenance operations (e.g. __L1C_MaintainDCacheSetWay function).
Steps To Reproduce
No response