Lines Matching +refs:po +refs:fuzzy +refs:counter
1967 Our hardware counter profiling is based on perf_event_open().
3800 4) Check out */po/*.pot which we don't update frequently.
14659 bit fuzzy.
17266 * po/bfd.pot: Regenerate.
17281 * po/bfd.pot: Regenerate.
17295 * po/bfd.pot: Regenerate.
25170 or hardware data watchpoint hit with a program counter beyond the
26487 Fix this by removing the counter / types_counter distinction in
30891 (po/SRC-POTFILES.in): uniq SRC_POTFILES.
30892 (po/BLD-POTFILES.in): uniq BFD_POTFILES.
30894 * po/Make-in (bfd.pot): Edit out source dir from comments.
30895 * po/SRC-POTFILES.in: Regenerate.
30899 * po/POTFILES.in: Regenerate.
32159 until the loop counter exceeded 100 iterations. The C file for the
33226 write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed.
33232 - gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ());
33233 + gdb_assert (counter == per_bfd->all_units.size ());
33238 gdb_assert (counter == per_bfd->all_comp_units.size ());
55924 fixup which involves adjusting the program counter back to its
55994 inferior's program counter in order figure out how far through the
56014 that's needed is the program counter restore anyway.
56027 patch relied too much on checking the program-counter value in order
56030 program counter check is not sufficient. The new tests expose this
56234 under bfd/po/, i.e. in maintainer mode.
56850 program counter. As such, GDB sees that the stack frame has been
57595 immediate operands, the new predicate-as-counter registers are
57706 - the predicate-as-counter WHILE* instructions have a fourth operand
57722 The instructions are predicated on a predicate-as-counter register in
57747 aarch64: Add support for predicate-as-counter registers
57871 SME2 adds "predicate-as-counter" registers that are denoted PN.
61463 Regen ld/po/BLD-POTFILES.in
62204 counter is (a) not correct, and (b) counter to what is laid out in the
66585 and reset the thread id counter, otherwise we get regressions like
66616 I.e., GDB was failing to restart the thread counter back to 1, because
69255 (gdb) p $counter = 0
69257 (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0
69293 (gdb) p $counter
69311 (gdb) p $counter = 0
69313 (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0
72898 concerned) by incrementing a volatile counter in the loop.
73067 This change has been tested on Beaglebone AI-64 [4]. Static counter
79298 * po/SRC-POTFILES.in: Regenerate.
82445 Regen opcodes/po/POTFILES.in
85930 * po/POTFILES.in: Likewise.
91054 If the counter for LOOP instruction is provided by a register with
95887 * po/hu.po: Updated Hungarian translation.
96306 Regen ld/po/BLD-POTFILES.in
99569 make[4]: Entering directory '/home/alan/build/gas/all/bfd/po'
99570 …to make target '../elf32-aarch64.c', needed by '/home/alan/src/binutils-gdb/bfd/po/bfd.pot'. Stop.
102740 Making info in po
102741 make[3]: Entering directory '/build/gas/all/bfd/po'
102742 cd .. && make po/SRC-POTFILES.in
102743 cd .. && make po/BLD-POTFILES.in
102763 * Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES).
102764 (po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES).
111828 I'm inclined to think that abbrev caching is counter-productive. The
112024 steps-left counter. If the counter is 0, it returns true and we
116265 Note that I didn't touch */po/*.po{,t} on the assumption that these
120358 FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout)
131779 use an index counter to find the next item from the vector when
134564 Regen bfd po/SRC-POTFILES.in
136564 line counter uses of .line inside e.g. an .irp construct won't have the
137920 * po/SRC-POTFILES.in: Regenerate.
145129 counter.
145130 (demangle_path): Increment/decrement the recursion counter upon
145131 entry and exit. Fail if the counter exceeds a fixed limit.
145133 (rust_demangle_callback): Initialise the recursion counter,
145833 global function like this is counter to that goal. Also, existing
149210 * po/fr.po: Same.
149211 * po/ru.po: Same.
149212 * po/uk.po: Same.
149229 * po/fr.po: Same.
149230 * po/ru.po: Same.
149231 * po/uk.po: Same.
150355 out */po/*.pot which we don't update frequently.
156963 * po/BLD-POTFILES.in: Regenerate.
156964 * po/SRC-POTFILES.in: Regenerate.
156969 * po/fr.po; Updated French translation.
157373 * po/Make-in (msgid-bugs-address): Likewise.
157377 * po/Make-in (msgid-bugs-address): Update.
157380 * po/Make-in: Update bug address.
157382 * po/Make-in: Update bug address.
157384 * po/Make-in: Update bug address.
157386 * po/Make-in: Update bug address.
157388 * po/Make-in: Update bug address.
159976 * po/POTFILESin: Regenerate.
163538 * po/BLD-POTFILES.in: Regenerate.
163576 * po/POTFILES.in: Regenerate.
163634 * po/POTFILES.in: Regenerate.
163659 * po/BLD-POTFILES.in: Regenerate.
163660 * po/SRC-POTFILES.in: Regenerate.
166205 This solution however is counter-trend in the sense that we're trying to
172374 * po/BLD-POTFILES.in: Regenerate.
172724 53 | std::atomic<int> counter = 0;
176400 So I added a global counter, as each thread starts successfully it
176401 decrements the counter. The main thread does not proceed to the final
176404 thread doesn't successfully enter clone_fn then the counter will never
178031 program counter register.
178039 of the program counter, and so the lazy register value is resolved
181675 * po/gas.pot: Regenerate.
181682 * po/bfd.pot: Regenerate.
181920 counter, i.e. a clock with the highest available resolution to
182178 we must instead pass 'counter', to handle the situation where a TU is