Re: Question for coverage report
| От | Álvaro Herrera |
|---|---|
| Тема | Re: Question for coverage report |
| Дата | |
| Msg-id | 202510171743.yihu2etsyzek@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: Question for coverage report (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: Question for coverage report
|
| Список | pgsql-hackers |
On 2025-Oct-17, Jacob Champion wrote: > On Fri, Oct 17, 2025 at 3:55 AM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: > > Oh, I didn't notice. Yeah it was also strange. Is there a > > possibility that complier optimization did prefetch and it was also > > counted? > > FWIW, I'm used to having to set -O0 for the best coverage behavior. > -Og _usually_ works fine, but it occasionally results in nonsensical > reports for me. Hmm, these reports are supposed to have been generated with -O0. This is the configure line: ./configure --cache-file=/home/coverage/pgsrc/configure.cache --enable-depend --enable-coverage --enable-tap-tests --enable-nls--with-python --with-perl --with-tcl --with-openssl --with-libxml --with-ldap --with-pam --with-llvm --with-lz4--enable-injection-points CFLAGS=-O0 'CPPFLAGS=-DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST'LLVM_CONFIG=/usr/bin/llvm-config-19 CLANG=clang-19 >> $LOG 2>&1 Is this somehow not effective? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La gente vulgar sólo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo"
В списке pgsql-hackers по дате отправления: