Hi Benjanmin,
On Fri, 1 Sept 2023 at 17:45, David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Fri, 2023-09-01 at 16:48 +0200, Benjamin Priour wrote:
> > Patch has been updated as per your suggestions and successfully
> > regstrapped
> > on x86_64-linux-gnu.
> >
The new testc
On Fri, 2023-09-01 at 16:48 +0200, Benjamin Priour wrote:
> Patch has been updated as per your suggestions and successfully
> regstrapped
> on x86_64-linux-gnu.
>
> call_details::maybe_get_arg_region is now
> /* If argument IDX's svalue at the callsite is of pointer type,
> return the region i
Patch has been updated as per your suggestions and successfully regstrapped
on x86_64-linux-gnu.
call_details::maybe_get_arg_region is now
/* If argument IDX's svalue at the callsite is of pointer type,
return the region it points to.
Otherwise return NULL. */
const region *
call_detail
Hi David,
On Fri, Sep 1, 2023 at 1:59 AM David Malcolm wrote:
> On Fri, 2023-09-01 at 00:04 +0200, priour...@gmail.com wrote:
>
>
[..snip..]
> ...which will only fire if arg 1 is a region_svalue. This won't
> trigger if you have e.g. a binop_svalue for pointer arithmetic.
>
> What happens e.g
On Fri, 2023-09-01 at 00:04 +0200, priour...@gmail.com wrote:
> Hi,
>
> Succesfully regstrapped off trunk 7f2ed06ddc825e8a4e0edfd1d66b5156e6dc1d34
> on x86_64-linux-gnu.
>
> Is it OK for trunk ?
Hi Benjamin.
Thanks for the patch. It's OK as-is, but it doesn't cover every
case...
[...snip..
From: benjamin priour
Hi,
Succesfully regstrapped off trunk 7f2ed06ddc825e8a4e0edfd1d66b5156e6dc1d34
on x86_64-linux-gnu.
Is it OK for trunk ?
Thanks,
Benjamin.
Patch below.
---
Fixed spurious possibly-NULL warning always tagging along throwing
operator new despite it never returning NULL.
On Mon, 2023-07-31 at 13:46 +0200, Benjamin Priour wrote:
> Hi Dave,
>
> On Fri, Jul 21, 2023 at 10:10 PM David Malcolm
> wrote:
[...snip...]
> >
> > I see that we have test coverage for:
> > noexcept-new.C: -fno-exceptions with new vs nothrow-new
> > whereas:
> > new-2.C has (implicitly)
Hi Dave,
On Fri, Jul 21, 2023 at 10:10 PM David Malcolm wrote:
[...]
It looks like something's gone wrong with the indentation in the above:
> previously we had tab characters, but now I'm seeing a pair of spaces,
> which means this wouldn't line up properly. This might be a glitch
> somewhere
On Thu, 2023-07-06 at 16:43 +0200, priour...@gmail.com wrote:
> As per David's suggestion.
> - Improved leading comment of "is_placement_new_p"
> - "kf_operator_new::matches_call_types_p" now checks that arg 0 is of
> integral type and that arg 1, if any, is of pointer type.
> - Changed ambiguous
As per David's suggestion.
- Improved leading comment of "is_placement_new_p"
- "kf_operator_new::matches_call_types_p" now checks that arg 0 is of
integral type and that arg 1, if any, is of pointer type.
- Changed ambiguous "int" to "int8_t" and "int64_t" in placement-new-size.C
to trigger a
Hi David,
On 05/07/2023 22:59, David Malcolm wrote:
diff --git a/gcc/analyzer/kf-lang-cp.cc b/gcc/analyzer/kf-lang-cp.cc
index 393b4f25e79..258d92919d7 100644
--- a/gcc/analyzer/kf-lang-cp.cc
+++ b/gcc/analyzer/kf-lang-cp.cc
@@ -35,6 +35,34 @@ along with GCC; see the file COPYING3. If not see
On Tue, 2023-07-04 at 18:25 +0200, priour...@gmail.com wrote:
> From: benjamin priour
>
> Script contrib/check_GNU_style.sh complains about there being a space
> before a left square bracket ("operator new []").
> Though, it is actually within a literal string, and the space
> is required to co
From: benjamin priour
Script contrib/check_GNU_style.sh complains about there being a space
before a left square bracket ("operator new []").
Though, it is actually within a literal string, and the space
is required to correctly detect the function.
Succesfully regstrapped on x86_64-linux-gnu
13 matches
Mail list logo
