Re: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code
On 2019-Mar-12, at 22:08, Mark Millard wrote:
> I have submitted:
>
> https://bugs.llvm.org//show_bug.cgi?id=41050
>
> for the clang 8 code generation problem of
> no code for setting r2 appropriately before
> the:
>
> bl . . . <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3>
>
> in unoptimized code ( no -O ). For the -O2 code:
>
> ld r2,40(r1)
>
> is present but is being skipped by the libunwind return
> to the code: it returns to the just-following bl
> instruction (like above) instead.
>
> In both cases:
>
> (gdb) x/32i 0x17c0
> 0x17c0 <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3>:std
> r2,40(r1)
> 0x17c4 <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: ld
> r12,-32608(r2)
> 0x17c8 <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: mtctr
> r12
> 0x17cc <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: ld
> r11,-32592(r2)
> 0x17d0 <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: ld
> r2,-32600(r2)
> 0x17d4 <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: bctr
> 0x17d8 <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: .long
> 0x0
> 0x17dc <0018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: .long
> 0x0
> . . .
>
> with an inappropriate r2 value leads to jumping to
> inappropriate places.
>
> The example source code was:
>
> #include
>
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {}
> return 0;
> }
>
>
>
> Note:
>
> This is from investigations of head -r345044 using
> WITH_LLVM_LIBUNWIND= on powerpc64.
>
The discussion on https://bugs.llvm.org//show_bug.cgi?id=41050
indicates that the ld r2,??? to restore the value appropriate to
the a.out code in my example should be happening via the library
holding libunwind's code instead of the ld executing in the
a.out code.
So: thus far it is viewed as a libunwind issue instead of a clang
one.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote:
> On 3/13/19 9:40 AM, Steve Kargl wrote:
> > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
> >> On 3/13/19 8:16 AM, Steve Kargl wrote:
> >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>
> gcc8 --version
> gcc8 (FreeBSD Ports Collection) 8.3.0
>
> gcc8 -fno-builtin -o z a.c -lm && ./z
> gcc8 -O -fno-builtin -o z a.c -lm && ./z
> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
>
> Max ULP: 2.297073
> Count: 0 (# of ULP that exceed 21)
>
> >>>
> >>> clang agrees with gcc8 if one changes ...
> >>>
> int
> main(void)
> {
> double re, im, u, ur, ui;
> float complex f;
> float x, y;
> >>>
> >>> this line to "volatile float x, y".
> >>
> >> So it seems to be a regression in clang 7 vs clang 6?
> >>
> >
> > /usr/local/bin/clang60 has the same problem.
> >
> > % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z
> > Maximum ULP: 23.061242
> > # of ULP > 21: 39
> >
> > Adding volatile as in the above "fixes" the problem.
> >
> > AFAICT, this a i386/387 code generation problem. Perhaps,
> > an alignment issue?
>
> Oh, I misread your earlier e-mail to say that clang60 worked.
>
> One issue I'm aware of is that clang does not have any support for the
> special arrangement FreeBSD/i386 uses where it uses different precision
> for registers vs in-memory for some of the floating point types (GCC has
> a special hack that is only used on FreeBSD for this but isn't used on
> any other OS's). I wonder if that could be a factor? Volatile probably
> forces a round trip between memory which might explain why this is the
> case.
>
> I wonder what your test program does on i386 Linux with GCC?
I don't have an i386 Linux environment. I tried comparing the
assembly generated with and without volatile, but it proves
difficult as register numbers are changed between the 2 listings
so almost all lines mismatch
If I move ranged(), rangef(), dp_csinh(), and ulpfd() into b.c
so a.c only contains main(), add appropriate prototypes to a.c,
and comment out the printf() statements, I still see the problem.
Judging from the diff, there is a difference in the spills and
loads in 2 places.
% diff -uw without_volatile with_volatile
--- without_volatile2019-03-13 10:51:33.244226000 -0700
+++ with_volatile 2019-03-13 10:51:54.088095000 -0700
@@ -35,11 +35,13 @@
movl%esi, 68(%esp) # 4-byte Spill
calll rangef
fadds .LCPI0_0
- fstpl 24(%esp)# 8-byte Folded Spill
+ fstps 28(%esp)
calll rangef
fadds .LCPI0_1
- fstl100(%esp) # 8-byte Folded Spill
- fldl24(%esp)# 8-byte Folded Reload
+ fstps 24(%esp)
+ flds28(%esp)
+ flds24(%esp)
+ fxch%st(1)
fstps 48(%esp)
fstps 52(%esp)
movl48(%esp), %eax
@@ -49,13 +51,13 @@
calll csinhf
movl%eax, %esi
movl%edx, %edi
+ flds28(%esp)
+ flds24(%esp)
leal72(%esp), %eax
movl%eax, 20(%esp)
leal80(%esp), %eax
movl%eax, 16(%esp)
- fldl100(%esp) # 8-byte Folded Reload
fstpl 8(%esp)
- fldl24(%esp)# 8-byte Folded Reload
fstpl (%esp)
calll dp_csinh
movl%esi, 40(%esp)
@@ -75,7 +77,7 @@
fnstsw %ax
# kill: def $ah killed $ah killed $ax
sahf
- fstl24(%esp)# 8-byte Folded Spill
+ fstl100(%esp) # 8-byte Folded Spill
ja .LBB0_3
# %bb.2:# %for.body
# in Loop: Header=BB0_1 Depth=1
@@ -114,7 +116,7 @@
# in Loop: Header=BB0_1 Depth=1
fstp%st(2)
fldl92(%esp)# 8-byte Folded Reload
- fldl24(%esp)# 8-byte Folded Reload
+ fldl100(%esp) # 8-byte Folded Reload
fucomp %st(1)
fnstsw %ax
# kill: def $ah killed $ah killed $ax
Adding ieeefp.h to a.c and fpsetprec(FP_PE) in main()
produces a massive diff, but still wrong results if
volatile is not use.
Clang appears to be broken for FP on i386/387.
--
Steve
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
Hi John, On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote: > One issue I'm aware of is that clang does not have any support for the > special arrangement FreeBSD/i386 uses where it uses different precision > for registers vs in-memory for some of the floating point types (GCC has > a special hack that is only used on FreeBSD for this but isn't used on > any other OS's). I wonder if that could be a factor? Volatile probably > forces a round trip between memory which might explain why this is the > case. > > I wonder what your test program does on i386 Linux with GCC? $ uname -sr Linux 4.20.4 $ gcc --version gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) ... $ rpm -qf /usr/lib/libm-2.27.so glibc-2.27-37.fc28.i686 $ gcc -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: 1.959975 Count: 0 $ gcc -O -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: 1.959975 Count: 0 $ gcc -O1 -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: 1.959975 Count: 0 $ gcc -O2 -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: nan Count: 0 $ gcc -O3 -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: nan Count: 0 Uh. kargl.c: In function ‘main’: kargl.c:80:10: warning: ‘u’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (ur > u) u = ur; ^ If I initialize 'u' (to, e.g., -1e52), I get: Max ULP: 1.959975 Count: 0 at -O2 and -O3 as well. Best, Conrad ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On 3/13/19 9:40 AM, Steve Kargl wrote:
> On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
>> On 3/13/19 8:16 AM, Steve Kargl wrote:
>>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
gcc8 --version
gcc8 (FreeBSD Ports Collection) 8.3.0
gcc8 -fno-builtin -o z a.c -lm && ./z
gcc8 -O -fno-builtin -o z a.c -lm && ./z
gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
Max ULP: 2.297073
Count: 0 (# of ULP that exceed 21)
>>>
>>> clang agrees with gcc8 if one changes ...
>>>
int
main(void)
{
double re, im, u, ur, ui;
float complex f;
float x, y;
>>>
>>> this line to "volatile float x, y".
>>
>> So it seems to be a regression in clang 7 vs clang 6?
>>
>
> /usr/local/bin/clang60 has the same problem.
>
> % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z
> Maximum ULP: 23.061242
> # of ULP > 21: 39
>
> Adding volatile as in the above "fixes" the problem.
>
> AFAICT, this a i386/387 code generation problem. Perhaps,
> an alignment issue?
Oh, I misread your earlier e-mail to say that clang60 worked.
One issue I'm aware of is that clang does not have any support for the
special arrangement FreeBSD/i386 uses where it uses different precision
for registers vs in-memory for some of the floating point types (GCC has
a special hack that is only used on FreeBSD for this but isn't used on
any other OS's). I wonder if that could be a factor? Volatile probably
forces a round trip between memory which might explain why this is the
case.
I wonder what your test program does on i386 Linux with GCC?
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
> On 3/13/19 8:16 AM, Steve Kargl wrote:
> > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> >>
> >> gcc8 --version
> >> gcc8 (FreeBSD Ports Collection) 8.3.0
> >>
> >> gcc8 -fno-builtin -o z a.c -lm && ./z
> >> gcc8 -O -fno-builtin -o z a.c -lm && ./z
> >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
> >> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
> >>
> >> Max ULP: 2.297073
> >> Count: 0 (# of ULP that exceed 21)
> >>
> >
> > clang agrees with gcc8 if one changes ...
> >
> >> int
> >> main(void)
> >> {
> >>double re, im, u, ur, ui;
> >>float complex f;
> >>float x, y;
> >
> > this line to "volatile float x, y".
>
> So it seems to be a regression in clang 7 vs clang 6?
>
/usr/local/bin/clang60 has the same problem.
% /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z
Maximum ULP: 23.061242
# of ULP > 21: 39
Adding volatile as in the above "fixes" the problem.
AFAICT, this a i386/387 code generation problem. Perhaps,
an alignment issue?
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On 3/13/19 8:16 AM, Steve Kargl wrote:
> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>>
>> gcc8 --version
>> gcc8 (FreeBSD Ports Collection) 8.3.0
>>
>> gcc8 -fno-builtin -o z a.c -lm && ./z
>> gcc8 -O -fno-builtin -o z a.c -lm && ./z
>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
>>
>> Max ULP: 2.297073
>> Count: 0 (# of ULP that exceed 21)
>>
>
> clang agrees with gcc8 if one changes ...
>
>> int
>> main(void)
>> {
>>double re, im, u, ur, ui;
>>float complex f;
>>float x, y;
>
> this line to "volatile float x, y".
So it seems to be a regression in clang 7 vs clang 6?
--
John Baldwin
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On Wed, Mar 13, 2019 at 04:56:26PM +0100, Hans Petter Selasky wrote:
> On 3/13/19 4:50 PM, Steve Kargl wrote:
> > Using sin() and cos() directly as in
> >
> > /* Double precision csinh() without using C's double complex.s */
> > void
> > dp_csinh(double x, double y, double *re, double *im)
> > {
> > double c, s;
> > *re = sinh(x) * cos(y);
> > *im = cosh(x) * sin(y);
> > }
> >
> > does not change the result. I'll also note that libm
> > is compiled by clang, and I do not recompile it for the
> > tests. Both gcc8 and cc are using the same libm.
> >
> > I've also tested clang of amd64 with the -m32, it fails
> > as well.
>
> Hi,
>
> I cannot see this is failing with 11-stable userland. Can you check with
> objdump() that clang doesn't optimise it to sincos() ?
It doesn't.
% nm z | grep sin
U csinhf
00401360 T dp_csinh
U sin
U sinh
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
> LLVM 3.8.0)
> Target: x86_64-unknown-freebsd11.0
The test does not fail on x86_64 unless you add the -m32 option,
which forces i386 behavior.
cc --version
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250)
(based on LLVM 7.0.1)
Target: x86_64-unknown-freebsd13.0
cc -fno-builtin -O2 -o z a.c -lm && ./z
Max u: 2.297073
Count: 0
cc -fno-builtin -O2 -o z a.c -lm -m32 && ./z
Max u: 23.061242
Count: 39
> Thread model: posix
> InstalledDir: /usr/bin
>
> cc -lm -O2 -Wall test.c && ./a.out
> Max ULP: 2.297073
> Count: 0
add -m32.
>
> clang40 -lm -O2 test6.c
> > ./a.out
> Max ULP: 2.297073
> Count: 0
>
> clang50 -lm -O2 test6.c
> > ./a.out
> Max ULP: 2.297073
> Count: 0
>
> clang60 -lm -O2 test6.c
> > ./a.out
> Max ULP: 2.297073
> Count: 0
--
Steve
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On 3/13/19 4:50 PM, Steve Kargl wrote:
Using sin() and cos() directly as in
/* Double precision csinh() without using C's double complex.s */
void
dp_csinh(double x, double y, double *re, double *im)
{
double c, s;
*re = sinh(x) * cos(y);
*im = cosh(x) * sin(y);
}
does not change the result. I'll also note that libm
is compiled by clang, and I do not recompile it for the
tests. Both gcc8 and cc are using the same libm.
I've also tested clang of amd64 with the -m32, it fails
as well.
Hi,
I cannot see this is failing with 11-stable userland. Can you check with
objdump() that clang doesn't optimise it to sincos() ?
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
cc -lm -O2 -Wall test.c && ./a.out
Max ULP: 2.297073
Count: 0
clang40 -lm -O2 test6.c
> ./a.out
Max ULP: 2.297073
Count: 0
clang50 -lm -O2 test6.c
> ./a.out
Max ULP: 2.297073
Count: 0
clang60 -lm -O2 test6.c
> ./a.out
Max ULP: 2.297073
Count: 0
--HPS
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236313] graphics/opencollada: excessive build time with clang 8 on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236313 --- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Wed Mar 13 15:54:15 UTC 2019 New revision: 495589 URL: https://svnweb.freebsd.org/changeset/ports/495589 Log: graphics/opencollada: back out r494777 after base r345021 PR: 236313 Changes: head/graphics/opencollada/files/patch-clang8 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On Wed, Mar 13, 2019 at 04:41:51PM +0100, Hans Petter Selasky wrote:
> On 3/13/19 4:16 PM, Steve Kargl wrote:
> > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> >>
> >> gcc8 --version
> >> gcc8 (FreeBSD Ports Collection) 8.3.0
> >>
> >> gcc8 -fno-builtin -o z a.c -lm && ./z
> >> gcc8 -O -fno-builtin -o z a.c -lm && ./z
> >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
> >> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
> >>
> >> Max ULP: 2.297073
> >> Count: 0 (# of ULP that exceed 21)
> >>
> >
> > clang agrees with gcc8 if one changes ...
> >
> >> int
> >> main(void)
> >> {
> >> double re, im, u, ur, ui;
> >> float complex f;
> >> float x, y;
> >
> > this line to "volatile float x, y".
> >
>
> Can you try to use:
>
> #define sincos(x,p,q) do { \
> *(p) = sin(x); \
> *(q) = cos(x); \
> } while (0)
>
>
> Instead of libm's sincos(). Might be a bug in there.
>
Using sin() and cos() directly as in
/* Double precision csinh() without using C's double complex.s */
void
dp_csinh(double x, double y, double *re, double *im)
{
double c, s;
*re = sinh(x) * cos(y);
*im = cosh(x) * sin(y);
}
does not change the result. I'll also note that libm
is compiled by clang, and I do not recompile it for the
tests. Both gcc8 and cc are using the same libm.
I've also tested clang of amd64 with the -m32, it fails
as well.
--
Steve
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On 3/13/19 4:16 PM, Steve Kargl wrote:
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
gcc8 --version
gcc8 (FreeBSD Ports Collection) 8.3.0
gcc8 -fno-builtin -o z a.c -lm && ./z
gcc8 -O -fno-builtin -o z a.c -lm && ./z
gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
Max ULP: 2.297073
Count: 0 (# of ULP that exceed 21)
clang agrees with gcc8 if one changes ...
int
main(void)
{
double re, im, u, ur, ui;
float complex f;
float x, y;
this line to "volatile float x, y".
Can you try to use:
#define sincos(x,p,q) do { \
*(p) = sin(x); \
*(q) = cos(x); \
} while (0)
Instead of libm's sincos(). Might be a bug in there.
--HPS
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > All, > > There seems to an optimization bug with clang on > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 > > IOW, if you do numerica work on i386, you may want to check your > results. > > The program demonstrating the issue is at the end of this email. > > gcc8 --version > gcc8 (FreeBSD Ports Collection) 8.3.0 > > gcc8 -fno-builtin -o z a.c -lm && ./z > gcc8 -O -fno-builtin -o z a.c -lm && ./z > gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > > Max ULP: 2.297073 > Count: 0 (# of ULP that exceed 21) > The above results do not change if one add -ffloat-store to the command line. > cc -O -fno-builtin -o z a.c -lm && ./z > cc -O2 -fno-builtin -o z a.c -lm && ./z > cc -O3 -fno-builtin -o z a.c -lm && ./z > > Max ULP: 23.061242 > Count: 39 (# of ULP that exceeds 21) Clang doesn't support -ffloat-store, so the above does not change. -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Is this a programming error, or a compiler error..
On 13 Mar 2019, at 12:57, Willem Jan Withagen wrote:
>
> I'm getting a crash in a Ceph test program in the following pice of code:
>
> struct entity_addrvec_t {
> vector v;
> .
> entity_addr_t legacy_addr() const {
> for (auto& a : v) {
> if (a.type == entity_addr_t::TYPE_LEGACY) {
> return a;
> }
> }
> return entity_addr_t();
> }
> ..
>
> Where the loop is taken, even if v.size() == 0
> So v content is pointing to random memory and itterating over the next
> pointer results in a crash.
This can happen when the vector is invalidated, due to either it, or its
parent object having been moved from. Maybe run this under valgrind or
AddressSanitizer, that should give some more clues.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Is this a programming error, or a compiler error..
Hi,
I'm getting a crash in a Ceph test program in the following pice of code:
struct entity_addrvec_t {
vector v;
.
entity_addr_t legacy_addr() const {
for (auto& a : v) {
if (a.type == entity_addr_t::TYPE_LEGACY) {
return a;
}
}
return entity_addr_t();
}
..
Where the loop is taken, even if v.size() == 0
So v content is pointing to random memory and itterating over the next
pointer results in a crash.
I would expect the loop not to be executed
--WjW
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
