[Bug libgcc/105016] [libgcc, TARGET_HAS_NO_HW_DIVIDE] Incorrect result for __udivmodti4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105016 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-03-22 Resolution|INVALID |--- Status|RESOLVED|NEW
[Bug libgcc/105016] [libgcc, TARGET_HAS_NO_HW_DIVIDE] Incorrect result for __udivmodti4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105016 --- Comment #5 from Richard Biener --- The UDIV_NEEDS_NORMALIZATION path with !TARGET_HAS_NO_HW_DIVIDE might be similarly affected.
[Bug libgcc/105016] [libgcc, TARGET_HAS_NO_HW_DIVIDE] Incorrect result for __udivmodti4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105016 --- Comment #4 from Richard Biener --- I see. The function should probably use count_leading_zeros instead of __builtin_clzll? Though I fail to see how that would make a difference since it doesn't have support for TImode either.
[Bug libgcc/105016] [libgcc, TARGET_HAS_NO_HW_DIVIDE] Incorrect result for __udivmodti4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105016 --- Comment #3 from Tom de Vries --- In libgcc.h, I see: ... #define __udivmoddi4__NDW(udivmod,4) ... and for LIBGCC2_UNITS_PER_WORD == 8 we have: ... #define __NDW(a,b) __ ## a ## ti ## b ... So, AFAICT it's possible that __udivmoddi4 is mapped to __udivmodti4.
[Bug libgcc/105016] [libgcc, TARGET_HAS_NO_HW_DIVIDE] Incorrect result for __udivmodti4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105016 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- since long long is DImode the function cannot work with TImode UDWtype. It's called __udivmoddi4 for a reason.
[Bug libgcc/105016] [libgcc, TARGET_HAS_NO_HW_DIVIDE] Incorrect result for __udivmodti4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105016 --- Comment #1 from Tom de Vries --- Created attachment 52662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52662&action=edit test-case