provide a hint to clang-analyzer-optin.portability.UnixAPI?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

provide a hint to clang-analyzer-optin.portability.UnixAPI?

suyash singh via cfe-dev

To whom it may concern,

tl;dr I think I found a bug in the clang static analyzer. Could someone please help me find a workaround/where to properly report the bug?

I have a statement in a class initializer list:

data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr)

rhs.has_data() is a const function that returns t/f if rhs.data_ptr != null

rhs.size_in_bytes() a const function that returns the number of bytes in the structure if has_data was true

i.e. it is possible that rhs.has_data() is false, and rhs.size_in_bytes() > 0

However the clang static analyzer seems to get a false positive here.

/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/unique_ptr.h:831:34: note: Calling copy constructor for 'pressio_data'
../include/libpressio_ext/cpp/data.h:247:15: note: Left side of '&&' is true
    data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr),
              ^
../include/libpressio_ext/cpp/data.h:247:33: note: Assuming the condition is true
    data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr),
                                ^
../include/libpressio_ext/cpp/data.h:247:14: note: '?' condition is true
    data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr),
             ^
../include/libpressio_ext/cpp/data.h:247:66: note: Calling 'pressio_data::size_in_bytes'
    data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr),
                                                                 ^
../include/libpressio_ext/cpp/data.h:384:12: note: Calling 'data_size_in_bytes<unsigned long>'
    return data_size_in_bytes(data_dtype, num_dimensions(), dims.data());
           ^
../include/libpressio_ext/cpp/data.h:31:5: note: Returning zero
    return data_size_in_elements(dimensions, dims) * pressio_dtype_size(type);
    ^
../include/libpressio_ext/cpp/data.h:384:12: note: Returning from 'data_size_in_bytes<unsigned long>'
    return data_size_in_bytes(data_dtype, num_dimensions(), dims.data());
           ^
../include/libpressio_ext/cpp/data.h:384:5: note: Returning zero
    return data_size_in_bytes(data_dtype, num_dimensions(), dims.data());
    ^
../include/libpressio_ext/cpp/data.h:247:66: note: Returning from 'pressio_data::size_in_bytes'
    data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr),
                                                                 ^
../include/libpressio_ext/cpp/data.h:247:59: note: Call to 'malloc' has an allocation size of 0 bytes
    data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr),

Is there a way to instruct the static analyzer that malloc cannot be called with size_in_bytes == 0 because saying (rhs.size_in_bytes() > 0) isn’t enough. I’m using clang-9.0.1 on gentoo.

Respectfully,
Robert Underwood


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: provide a hint to clang-analyzer-optin.portability.UnixAPI?

suyash singh via cfe-dev
It looks like we don't understand that size_in_bytes() always returns
the same value. There may be multiple reasons for this. I'd like to see
the whole code in order to understand what's going on. Could you produce
a preprocessed file and attach it together with the analyzer invocation?

As a workaround / suppression you should be able to do something like this:

   static void *make_data_ptr(RHS rhs) {
     if (!rhs.has_data())
       return nullptr;

     size_t size = rhs.size_in_bytes();
     return size ? malloc(size) : nullptr;
   }

   Ctor(RHS rhs): data_ptr(make_data_ptr(rhs)) {}

This would prevent the analyzer (and, well, your actual generated code)
from calling size_in_bytes() twice and believing that it may return two
different values.

On 2/28/20 5:41 PM, Robert Underwood via cfe-dev wrote:

>
> To whom it may concern,
>
> tl;dr I think I found a bug in the clang static analyzer. Could
> someone please help me find a workaround/where to properly report the bug?
>
> I have a statement in a class initializer list:
>
> |data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr)|
>
> rhs.has_data() is a const function that returns t/f if rhs.data_ptr !=
> null
>
> rhs.size_in_bytes() a const function that returns the number of bytes
> in the structure *if has_data was true*
>
> i.e. it is possible that rhs.has_data() is false, and
> rhs.size_in_bytes() > 0
>
> However the clang static analyzer seems to get a false positive here.
>
> |/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/unique_ptr.h:831:34:
> note: Calling copy constructor for 'pressio_data'
> ../include/libpressio_ext/cpp/data.h:247:15: note: Left side of '&&'
> is true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:33: note: Assuming the
> condition is true data_ptr((rhs.has_data() && rhs.size_in_bytes() >
> 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:14: note: '?' condition is
> true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:66: note: Calling
> 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:384:12: note: Calling
> 'data_size_in_bytes<unsigned long>' return
> data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
> ../include/libpressio_ext/cpp/data.h:31:5: note: Returning zero return
> data_size_in_elements(dimensions, dims) * pressio_dtype_size(type); ^
> ../include/libpressio_ext/cpp/data.h:384:12: note: Returning from
> 'data_size_in_bytes<unsigned long>' return
> data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
> ../include/libpressio_ext/cpp/data.h:384:5: note: Returning zero
> return data_size_in_bytes(data_dtype, num_dimensions(), dims.data());
> ^ ../include/libpressio_ext/cpp/data.h:247:66: note: Returning from
> 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:59: note: Call to 'malloc'
> has an allocation size of 0 bytes data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), |
>
> Is there a way to instruct the static analyzer that malloc cannot be
> called with size_in_bytes == 0 because saying (rhs.size_in_bytes() >
> 0) isn’t enough. I’m using clang-9.0.1 on gentoo.
>
> Respectfully,
> Robert Underwood
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: provide a hint to clang-analyzer-optin.portability.UnixAPI?

suyash singh via cfe-dev
I might be wrong, but probably this is the line which triggered the warning.

On Mon, Mar 16, 2020, 05:35 Artem Dergachev via cfe-dev <[hidden email]> wrote:
It looks like we don't understand that size_in_bytes() always returns
the same value. There may be multiple reasons for this. I'd like to see
the whole code in order to understand what's going on. Could you produce
a preprocessed file and attach it together with the analyzer invocation?

As a workaround / suppression you should be able to do something like this:

   static void *make_data_ptr(RHS rhs) {
     if (!rhs.has_data())
       return nullptr;

     size_t size = rhs.size_in_bytes();
     return size ? malloc(size) : nullptr;
   }

   Ctor(RHS rhs): data_ptr(make_data_ptr(rhs)) {}

This would prevent the analyzer (and, well, your actual generated code)
from calling size_in_bytes() twice and believing that it may return two
different values.

On 2/28/20 5:41 PM, Robert Underwood via cfe-dev wrote:
>
> To whom it may concern,
>
> tl;dr I think I found a bug in the clang static analyzer. Could
> someone please help me find a workaround/where to properly report the bug?
>
> I have a statement in a class initializer list:
>
> |data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr)|
>
> rhs.has_data() is a const function that returns t/f if rhs.data_ptr !=
> null
>
> rhs.size_in_bytes() a const function that returns the number of bytes
> in the structure *if has_data was true*
>
> i.e. it is possible that rhs.has_data() is false, and
> rhs.size_in_bytes() > 0
>
> However the clang static analyzer seems to get a false positive here.
>
> |/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/unique_ptr.h:831:34:
> note: Calling copy constructor for 'pressio_data'
> ../include/libpressio_ext/cpp/data.h:247:15: note: Left side of '&&'
> is true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:33: note: Assuming the
> condition is true data_ptr((rhs.has_data() && rhs.size_in_bytes() >
> 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:14: note: '?' condition is
> true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:66: note: Calling
> 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:384:12: note: Calling
> 'data_size_in_bytes<unsigned long>' return
> data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
> ../include/libpressio_ext/cpp/data.h:31:5: note: Returning zero return
> data_size_in_elements(dimensions, dims) * pressio_dtype_size(type); ^
> ../include/libpressio_ext/cpp/data.h:384:12: note: Returning from
> 'data_size_in_bytes<unsigned long>' return
> data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
> ../include/libpressio_ext/cpp/data.h:384:5: note: Returning zero
> return data_size_in_bytes(data_dtype, num_dimensions(), dims.data());
> ^ ../include/libpressio_ext/cpp/data.h:247:66: note: Returning from
> 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:59: note: Call to 'malloc'
> has an allocation size of 0 bytes data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), |
>
> Is there a way to instruct the static analyzer that malloc cannot be
> called with size_in_bytes == 0 because saying (rhs.size_in_bytes() >
> 0) isn’t enough. I’m using clang-9.0.1 on gentoo.
>
> Respectfully,
> Robert Underwood
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: provide a hint to clang-analyzer-optin.portability.UnixAPI?

suyash singh via cfe-dev
Yeah but it doesn't help much, i'm more interested in intermediate
events across the path.

On 3/16/20 8:50 PM, Balázs Benics wrote:

> I might be wrong, but probably this is the line which triggered the
> warning.
> https://github.com/robertu94/libpressio/blob/master/include/libpressio_ext/cpp/data.h#L247
>
>
> On Mon, Mar 16, 2020, 05:35 Artem Dergachev via cfe-dev
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     It looks like we don't understand that size_in_bytes() always returns
>     the same value. There may be multiple reasons for this. I'd like
>     to see
>     the whole code in order to understand what's going on. Could you
>     produce
>     a preprocessed file and attach it together with the analyzer
>     invocation?
>
>     As a workaround / suppression you should be able to do something
>     like this:
>
>        static void *make_data_ptr(RHS rhs) {
>          if (!rhs.has_data())
>            return nullptr;
>
>          size_t size = rhs.size_in_bytes();
>          return size ? malloc(size) : nullptr;
>        }
>
>        Ctor(RHS rhs): data_ptr(make_data_ptr(rhs)) {}
>
>     This would prevent the analyzer (and, well, your actual generated
>     code)
>     from calling size_in_bytes() twice and believing that it may
>     return two
>     different values.
>
>     On 2/28/20 5:41 PM, Robert Underwood via cfe-dev wrote:
>     >
>     > To whom it may concern,
>     >
>     > tl;dr I think I found a bug in the clang static analyzer. Could
>     > someone please help me find a workaround/where to properly
>     report the bug?
>     >
>     > I have a statement in a class initializer list:
>     >
>     > |data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
>     > malloc(rhs.size_in_bytes()) : nullptr)|
>     >
>     > rhs.has_data() is a const function that returns t/f if
>     rhs.data_ptr !=
>     > null
>     >
>     > rhs.size_in_bytes() a const function that returns the number of
>     bytes
>     > in the structure *if has_data was true*
>     >
>     > i.e. it is possible that rhs.has_data() is false, and
>     > rhs.size_in_bytes() > 0
>     >
>     > However the clang static analyzer seems to get a false positive
>     here.
>     >
>     >
>     |/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/unique_ptr.h:831:34:
>
>     > note: Calling copy constructor for 'pressio_data'
>     > ../include/libpressio_ext/cpp/data.h:247:15: note: Left side of
>     '&&'
>     > is true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
>     > malloc(rhs.size_in_bytes()) : nullptr), ^
>     > ../include/libpressio_ext/cpp/data.h:247:33: note: Assuming the
>     > condition is true data_ptr((rhs.has_data() && rhs.size_in_bytes() >
>     > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
>     > ../include/libpressio_ext/cpp/data.h:247:14: note: '?' condition is
>     > true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
>     > malloc(rhs.size_in_bytes()) : nullptr), ^
>     > ../include/libpressio_ext/cpp/data.h:247:66: note: Calling
>     > 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
>     > rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
>     > ../include/libpressio_ext/cpp/data.h:384:12: note: Calling
>     > 'data_size_in_bytes<unsigned long>' return
>     > data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
>     > ../include/libpressio_ext/cpp/data.h:31:5: note: Returning zero
>     return
>     > data_size_in_elements(dimensions, dims) *
>     pressio_dtype_size(type); ^
>     > ../include/libpressio_ext/cpp/data.h:384:12: note: Returning from
>     > 'data_size_in_bytes<unsigned long>' return
>     > data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
>     > ../include/libpressio_ext/cpp/data.h:384:5: note: Returning zero
>     > return data_size_in_bytes(data_dtype, num_dimensions(),
>     dims.data());
>     > ^ ../include/libpressio_ext/cpp/data.h:247:66: note: Returning from
>     > 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
>     > rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
>     > ../include/libpressio_ext/cpp/data.h:247:59: note: Call to 'malloc'
>     > has an allocation size of 0 bytes data_ptr((rhs.has_data() &&
>     > rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), |
>     >
>     > Is there a way to instruct the static analyzer that malloc
>     cannot be
>     > called with size_in_bytes == 0 because saying
>     (rhs.size_in_bytes() >
>     > 0) isn’t enough. I’m using clang-9.0.1 on gentoo.
>     >
>     > Respectfully,
>     > Robert Underwood
>     >
>     >
>     > _______________________________________________
>     > cfe-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: provide a hint to clang-analyzer-optin.portability.UnixAPI?

suyash singh via cfe-dev

All,

Sorry for the delay, was on break then adjusting to a new workspace as I expect many of us are.

I have attached the prepossessed file you asked for.

Balázs was correct about the code triggering the bug. It is from a project that I wrote/maintain called libpressio.

You can also reproduce build with the following script.  The default build features the bug, and it doesn't have any dependencies outside a relatively recent standard library (c++17)

First, remove the reference to -clang-analyzer-optin.portability.UnixAPI in the .clang-tidy file.

git clone https://github.com/robertu94/libpressio
mkdir build
cd build
cmake .. -DUSE_CLANG_TIDY=ON
cd ..
cmake --build ./build

You can then run clang-tidy for an offending file with:

clang-tidy -p build ./src/pressio_options.cc

On Mon, Mar 16, 2020 at 3:22 PM Artem Dergachev noqnoqneo@... wrote:
>

Yeah but it doesn’t help much, i’m more interested in intermediate
events across the path.

On 3/16/20 8:50 PM, Balázs Benics wrote:

I might be wrong, but probably this is the line which triggered the
warning.
https://github.com/robertu94/libpressio/blob/master/include/libpressio_ext/cpp/data.h#L247

On Mon, Mar 16, 2020, 05:35 Artem Dergachev via cfe-dev

> wrote:

It looks like we don't understand that size_in_bytes() always returns
the same value. There may be multiple reasons for this. I'd like
to see
the whole code in order to understand what's going on. Could you
produce
a preprocessed file and attach it together with the analyzer
invocation?

As a workaround / suppression you should be able to do something
like this:

   static void *make_data_ptr(RHS rhs) {
     if (!rhs.has_data())
       return nullptr;

     size_t size = rhs.size_in_bytes();
     return size ? malloc(size) : nullptr;
   }

   Ctor(RHS rhs): data_ptr(make_data_ptr(rhs)) {}

This would prevent the analyzer (and, well, your actual generated
code)
from calling size_in_bytes() twice and believing that it may
return two
different values.

On 2/28/20 5:41 PM, Robert Underwood via cfe-dev wrote:
>
> To whom it may concern,
>
> tl;dr I think I found a bug in the clang static analyzer. Could
> someone please help me find a workaround/where to properly
report the bug?
>
> I have a statement in a class initializer list:
>
> |data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr)|
>
> rhs.has_data() is a const function that returns t/f if
rhs.data_ptr !=
> null
>
> rhs.size_in_bytes() a const function that returns the number of
bytes
> in the structure *if has_data was true*
>
> i.e. it is possible that rhs.has_data() is false, and
> rhs.size_in_bytes() > 0
>
> However the clang static analyzer seems to get a false positive
here.
>
>
|/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/unique_ptr.h:831:34:

> note: Calling copy constructor for 'pressio_data'
> ../include/libpressio_ext/cpp/data.h:247:15: note: Left side of
'&&'
> is true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:33: note: Assuming the
> condition is true data_ptr((rhs.has_data() && rhs.size_in_bytes() >
> 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:14: note: '?' condition is
> true data_ptr((rhs.has_data() && rhs.size_in_bytes() > 0)?
> malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:66: note: Calling
> 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:384:12: note: Calling
> 'data_size_in_bytes<unsigned long>' return
> data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
> ../include/libpressio_ext/cpp/data.h:31:5: note: Returning zero
return
> data_size_in_elements(dimensions, dims) *
pressio_dtype_size(type); ^
> ../include/libpressio_ext/cpp/data.h:384:12: note: Returning from
> 'data_size_in_bytes<unsigned long>' return
> data_size_in_bytes(data_dtype, num_dimensions(), dims.data()); ^
> ../include/libpressio_ext/cpp/data.h:384:5: note: Returning zero
> return data_size_in_bytes(data_dtype, num_dimensions(),
dims.data());
> ^ ../include/libpressio_ext/cpp/data.h:247:66: note: Returning from
> 'pressio_data::size_in_bytes' data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), ^
> ../include/libpressio_ext/cpp/data.h:247:59: note: Call to 'malloc'
> has an allocation size of 0 bytes data_ptr((rhs.has_data() &&
> rhs.size_in_bytes() > 0)? malloc(rhs.size_in_bytes()) : nullptr), |
>
> Is there a way to instruct the static analyzer that malloc
cannot be
> called with size_in_bytes == 0 because saying
(rhs.size_in_bytes() >
> 0) isn’t enough. I’m using clang-9.0.1 on gentoo.
>
> Respectfully,
> Robert Underwood
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email] <mailto:[hidden email]>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email] <mailto:[hidden email]>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

pressio_options.cc.tgz (291K) Download Attachment