I've been having some trouble with Judy1 + 64-bit producing some nonsense values when compiled with "-O2 -fpeel-loops" (or O3, which enables loop peeling), but works fine with just "-O2". I thinkk I've tracked the problem down to here in Judy1Set.c:
#if (defined(JUDY1) && defined(JU_64BIT))
// Special case, as described above, go directly from Immed to LeafB1:
case cJ1_JPIMMED_1_15:
{
Word_t DcdP0;
int offset;
Pjlb_t PjlbRaw;
Pjlb_t Pjlb;
offset = j__udySearchLeaf1((Pjll_t) Pjp->jp_1Index, 15, Index);
JU_CHECK_IF_EXISTS(offset, ignore, Pjpm);
// Create a bitmap leaf (special case for Judy1 64-bit only, see usage): Set
// new Index in bitmap, copy an Immed1_15 to the bitmap, and set the parent JP
// EXCEPT jp_DcdPopO, leaving any followup to the caller:
if ((PjlbRaw = j__udyAllocJLB1(Pjpm)) == (Pjlb_t) NULL)
return(-1);
Pjlb = P_JLB(PjlbRaw);
JU_BITMAPSETL(Pjlb, Index);
for (offset = 0; offset < 15; ++offset)
JU_BITMAPSETL(Pjlb, Pjp->jp_1Index[offset]);
// Set jp_DcdPopO including the current pop0; incremented later:
DcdP0 = (Index & cJU_DCDMASK(1)) + 15 - 1;
JU_JPSETADT(Pjp, (Word_t)PjlbRaw, DcdP0, cJU_JPLEAF_B1);
return(1);
}
#endif
More specifically, this loop right here:
for (offset = 0; offset < 15; ++offset)
JU_BITMAPSETL(Pjlb, Pjp->jp_1Index[offset]);
Which GCC tells me:
/mnt/c/projects/setmatch/main/src/external/judy/Judy1Set.c: In function ‘j__udyInsWalk’:
/mnt/c/projects/setmatch/main/src/external/judy/Judy1Set.c:1506:17: warning: iteration 8 invokes undefined behavior [-Waggressive-loop-optimizations]
JU_BITMAPSETL(Pjlb, Pjp->jp_1Index[offset]);
^
/mnt/c/projects/setmatch/main/src/external/judy/Judy1Set.c:1505:13: note: within this loop
for (offset = 0; offset < 15; ++offset)
^
After preprocessing, the relevant line expands to:
for (offset = 0; offset < 15; ++offset)
(((Pjlb)->j1lb_Bitmap[(((Pjp->j_pi.j_pi_1Index[offset]) / (sizeof(uint64_t) * 0x8)) & ((256 / (sizeof(uint64_t) * 0x8))-1))]) |= (1L << ((Pjp->j_pi.j_pi_1Index[offset]) % (sizeof(uint64_t) * 0x8))));
Which is a little WTFy to me, but my impression is that GCC's static analysis has discovered some sort of out-of-bounds index access.
Oops, this appears to be a dupe of https://sourceforge.net/p/judy/bugs/25/ ; the patch there fixed the problem.
Bobby:
This "fix" on sourceforge was temporary until the Bug iin gcc was fixed. That was several years agoWe know the code is very old and needs an update. We are very active on that front.
Doug,
Doug Baskins dougbaskins@yahoo.com
Oops, this appears to be a dupe of https://sourceforge.net/p/judy/bugs/25/ ; the patch there fixed the problem.
[bugs:#28] Judy1 on 64-bit producing nonsense values
Status: open
Group: Judy-1.0.0
Created: Sat Dec 01, 2018 02:50 AM UTC by Bobby Fraser
Last Updated: Sat Dec 01, 2018 02:50 AM UTC
Owner: nobody
I've been having some trouble with Judy1 + 64-bit producing some nonsense values when compiled with "-O2 -fpeel-loops" (or O3, which enables loop peeling), but works fine with just "-O2". I thinkk I've tracked the problem down to here in Judy1Set.c:
if (defined(JUDY1) && defined(JU_64BIT))
// Special case, as described above, go directly from Immed to LeafB1:
// Create a bitmap leaf (special case for Judy1 64-bit only, see usage): Set
// new Index in bitmap, copy an Immed1_15 to the bitmap, and set the parent JP
// EXCEPT jp_DcdPopO, leaving any followup to the caller:
// Set jp_DcdPopO including the current pop0; incremented later:
DcdP0 = (Index & cJU_DCDMASK(1)) + 15 - 1;
JU_JPSETADT(Pjp, (Word_t)PjlbRaw, DcdP0, cJU_JPLEAF_B1);
endif
More specifically, this loop right here:
for (offset = 0; offset < 15; ++offset)
JU_BITMAPSETL(Pjlb, Pjp->jp_1Index[offset]);
Which GCC tells me:
/mnt/c/projects/setmatch/main/src/external/judy/Judy1Set.c: In function ‘j__udyInsWalk’:
/mnt/c/projects/setmatch/main/src/external/judy/Judy1Set.c:1506:17: warning: iteration 8 invokes undefined behavior [-Waggressive-loop-optimizations]
JU_BITMAPSETL(Pjlb, Pjp->jp_1Index[offset]);
^
/mnt/c/projects/setmatch/main/src/external/judy/Judy1Set.c:1505:13: note: within this loop
for (offset = 0; offset < 15; ++offset)
^
After preprocessing, the relevant line expands to:
for (offset = 0; offset < 15; ++offset)
(((Pjlb)->j1lb_Bitmap[(((Pjp->j_pi.j_pi_1Index[offset]) / (sizeof(uint64_t) * 0x8)) & ((256 / (sizeof(uint64_t) * 0x8))-1))]) |= (1L << ((Pjp->j_pi.j_pi_1Index[offset]) % (sizeof(uint64_t) * 0x8))));
Which is a little WTFy to me, but my impression is that GCC's static analysis has discovered some sort of out-of-bounds index access.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/judy/bugs/28/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs: #28