[Bug analyzer/115044] New: -Wanalyzer-malloc-leak diagnostic in terminal path

["andrew.cooper3 at citrix dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115044

            Bug ID: 115044
           Summary: -Wanalyzer-malloc-leak diagnostic in terminal path
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: andrew.cooper3 at citrix dot com
  Target Milestone: ---

I've been experimenting with -fanalyzer and attribute(malloc) in Xen.

For a simple case, it reported:

drivers/passthrough/x86/iommu.c: In function 'iommu_init_domid':
./include/xen/bug.h:141:13: warning: leak of '_xzalloc(4096, 8)' [CWE-401]
[-Wanalyzer-malloc-leak]
  141 |     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
      |             ^
drivers/passthrough/x86/iommu.c:551:9: note: in expansion of macro 'ASSERT'
  551 |         ASSERT(reserve > DOMID_MASK);
      |         ^~~~~~


If I'm reading this correctly, it's saying that allocated memory is being
leaked by ASSERT().

The whole function is:

unsigned long *__init iommu_init_domid(domid_t reserve)
{
    unsigned long *map;

    if ( !iommu_quarantine )
        return ZERO_BLOCK_PTR;

    BUILD_BUG_ON(DOMID_MASK * 2U >= UINT16_MAX);

    map = xzalloc_array(unsigned long, BITS_TO_LONGS(UINT16_MAX - DOMID_MASK));
    if ( map && reserve != DOMID_INVALID )
    {
        ASSERT(reserve > DOMID_MASK);
        __set_bit(reserve & DOMID_MASK, map);
    }

    return map;
}

but I can't seem to reproduce the -fanalyzer warning in a simpler example. 
Assuming it might be something to do with our implementation of ASSERT(), I
reduced it to just

  do { if (!(x)) __builtin_trap(); } while ( 0 )

in place, and that still did reproduce the warning.

So while the analyser is technically accurate (i.e. the memory is leaked when
we encounter a fatal path), I'm not sure it's a helpful diagnostic.

Is there a reason why it's reported like this?