On 21/11/2024 1:47 pm, Frediano Ziglio wrote: > On Thu, Nov 21, 2024 at 1:40 PM Jan Beulich <jbeul...@suse.com> wrote: >> On 21.11.2024 13:53, Frediano Ziglio wrote: >>> On Wed, Oct 30, 2024 at 1:25 PM Andrew Cooper <andrew.coop...@citrix.com> >>> wrote: >>>> On 21/10/2024 1:02 pm, oleksii.kuroc...@gmail.com wrote: >>>>> Hello everyone, >>>>> >>>>> As there were no objections to the proposed release schedule >>>>> (https://lore.kernel.org/xen-devel/CAMacjJxEi6PThwH2=nwg3he8eqn39aiaxzcw3bqf7i4ycmj...@mail.gmail.com/ >>>>> ), I've updated the wiki with the schedule for Xen 4.20 release >>>>> (https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes), and >>>>> it is now accessible from >>>>> https://xenbits.xen.org/docs/unstable-staging/support-matrix.html. >>>> I have a blocker to raise (against myself...) and no good idea of how to >>>> proceed. >>>> >>>> The for_each_bit work has a unexpected bug. >>>> >>>> for_each_bit ( ... ) >>>> { >>>> if ( ... ) >>>> break; >>>> } >>>> >>>> will fall into an infinite loop. This is caused by for_each_bit() >>>> hiding a double for() loop, in order to declare two scope-local >>>> variables of different types. >>>> >>>> The two variables are one copy of the source expression (really quite >>>> important to keep), and one unsigned int iterator (improved optimisation >>>> capability by not using a wider-scope variable). >>>> >>>> Options are (off the top of my head) >>>> >>>> 1) Always take the iterator from outer scope >>>> 2) Iterator always the same type as the source expression >>>> 3) Figure out some way of expressing "once" in the outer loop >>>> >>>> Or anything else that I've missed. >>>> >>>> ~Andrew >>>> >>> Something like >>> >>> #define for_each_set_bit(iter, val) \ >>> for ( typeof(val) __v = (val), __c=1; __c; __c=0) \ >>> for ( unsigned int (iter); \ >>> __v && ((iter) = ffs_g(__v) - 1, true); \ >>> __v &= __v - 1 ) >>> >>> ?
Yes, that was the option 3 I was thinking about, although I'd not got as far as doing the thinking bit yet. >> Hmm, right, but then we don't even need a 2nd variable, do we? >> >> #define for_each_set_bit(iter, val) \ >> for ( typeof(val) __v = (val); __v; __v = 0 ) \ >> for ( unsigned int (iter); \ >> __v && ((iter) = ffs_g(__v) - 1, true); \ >> __v &= __v - 1 ) This does look like a better option. >> >> Jan > In theory it should work too, not sure if the variable aliasing would > compromise the assembly output. We depend on the compiler doing some > optimizations. We already depend on some optimisation to get rid of the double loop (both -O2 and -O1 cope). I'll double check the result here too. ~Andrew
