Hi,
Thanks for the report,
After investigation it seems the location of the new dejagnu directive for
C++ differs depending on the configuration.
The expected warning is still emitted, but its location differ slightly.
I expect it to be not an issue per se of the analyzer, but a divergence in
the
Hi Christophe,
On Mon, Sep 11, 2023 at 4:23 PM Christophe Lyon
wrote:
> Hi!
>
>
> On Wed, 6 Sept 2023 at 22:22, David Malcolm via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
>> > Hi David,
>> > Thanks for the review.
>> >
>> >
>>
From: benjamin priour
Hi,
Second version of this patch after David's suggestions.
Thanks David for pointing out how I could implement it using sedges.
I hadn't thought of them being independent of the exploded path taken,
and unique for a conditional block's outcome. I had mistaken them with
eed
Hi David,
Thanks for the review.
On Tue, Sep 5, 2023 at 1:53 PM David Malcolm wrote:
> On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
>
>
[...snip...]
> All of these "new" tests (apart from the "-noexcept" ones) look like
> they're meant to be existing tests that were moved, b
From: benjamin priour
Hi,
This patch was the first I wrote and had been
at that time returned to me because ill-formatted.
Getting busy with other things, I forgot about it.
I've now fixed the formatting.
Succesfully regstrapped on x86_64-linux-gnu off trunk
a7d052b3200c7928d903a0242b8cfd75d13
From: benjamin priour
Hi,
Patch succesfully regstrapped off trunk 7f2ed06ddc825e8a4e0edfd1d66b5156e6dc1d34
on x86_64-linux-gnu.
Is it OK for trunk ?
Thanks,
Benjamin.
Patch below.
---
Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc su
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
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.
his mail changes.
Thanks again,
Benjamin.
On Tue, Aug 29, 2023 at 8:47 AM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On Sat, 26 Aug 2023 at 18:02, Benjamin Priour via Gcc-patches
> wrote:
> >
> > From: benjamin priour
> >
> > Hi,
> >
&
Hi David,
Thanks for the review.
On Fri, Aug 25, 2023 at 2:12 AM David Malcolm wrote:
> > From: benjamin priour
> >
> > Hi,
> >
> > Below the first batch of a serie of patches to transition
> > the analyzer testsuite from gcc.dg/analyzer to c-c++-common/analyzer.
> > I do not know how long thi
On Thu, Aug 17, 2023 at 12:34 AM David Malcolm wrote:
> On Wed, 2023-08-16 at 14:19 +0200, priour...@gmail.com wrote:
> > From: benjamin priour
> >
> > Hi,
> > (s/we/the analyzer/)
>
> Hi Benjamin, thanks for the updated patch.
>
> >
> > I've been continuing my patch of supporting operator new v
From: benjamin priour
Hi,
(s/we/the analyzer/)
I've been continuing my patch of supporting operator new variants
in the analyzer, and have added a few more test cases.
> > If "y" is null then the allocation failed and dereferencing "y" will
> > cause
> > a segfault, not a "use-of-u
From: benjamin priour
Yet another blunder.
Succesfully regstrapped against ce8cdf5bcf96a2db6d7b9f656fc9ba58d7942a83
on x86_64-linux-gnu.
OK to push on trunk ?
Sorry,
Benjamin.
Fixup below.
---
Test case g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C
introduced by patch ce8cdf5bcf96
From: benjamin priour
Plenty useful, thanks David. I've adjusted some few things, especially
the artifacts of earlier versions I missed when building the commit.
I didn't how to test for warnings within , I couldn't figure a portable
test.
I cannot pinpoint the line the warning is issued at in
I forgot to mention that this has been successfully regstrapped off trunk
54be338589ea93ad4ff53d22adde476a0582537b on x86_64-linux-gnu.
Is it OK for trunk ?
Thanks,
Benjamin.
From: benjamin priour
This patch introduces -fanalyzer-show-events-in-system-headers,
disabled by default.
This option reduce the noise of the analyzer emitted diagnostics
when dealing with system headers.
The new option only affects the display of the diagnostics,
but doesn't hinder the actual
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 Sat, Jul 22, 2023 at 12:04 AM David Malcolm wrote:
> On Fri, 2023-07-21 at 17:35 +0200, Benjamin Priour wrote:
> > Hi,
> >
> > Upon David's request I've joined the in progress patch to the below
> > email.
> > I hope it makes more sense now.
> >
> > Best,
> > Benjamin.
>
> Thanks for posting t
Hi,
Upon David's request I've joined the in progress patch to the below email.
I hope it makes more sense now.
Best,
Benjamin.
-- Forwarded message -
From: Benjamin Priour
Date: Tue, Jul 18, 2023 at 3:30 PM
Subject: [RFC] analyzer: Add optional trim of the analyzer diagnostics
g
Hi,
I'd like to request comments on a patch I am writing for PR110543.
The goal of this patch is to reduce the noise of the analyzer emitted
diagnostics when dealing with
system headers, or simply diagnostic paths that are too long. The new
option only affects the display
of the diagnostics, but d
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
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
From: benjamin priour
See below formatting updates on my patch.
In mail https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html,
David Malcolm says regtesting failed for him.
So I did it once more this morning rebased on fresh trunk dc93a0f633b
and target x86_64-linux-gnu, the output was
Hi,
Pinging that regression fix.
Is everything OK for trunk ?
Thanks,
Benjamin
On Thu, Jun 22, 2023 at 9:57 PM wrote:
From: benjamin priour
Resend with proper subject line ...
Hi,
Below is the fix to regression bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
Was b
From: benjamin priour
Resend with proper subject line ...
Hi,
Below is the fix to regression bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
Was bootstrapped and regtested successfully on x86_64-linux-gnu
Considering mishap from last patch, I'd would appreciate if you could
also regtes
Hi,
Below is the fix to regression bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
Was bootstrapped and regtested successfully on x86_64-linux-gnu
Considering mishap from last patch, I'd would appreciate if you could
also regtest it, to be sure :)
Thanks,
Benjamin.
>From 04186f04a3f172d
r , <
> dmalc...@redhat.com>
>
>
> Hi,
>
> Yes of course, I tested many days ago since regtesting takes several days
> on my box, I should have retested !
> But I got an account for the compile farm today, so I'm on it immediately,
> I also see a divergence in t
23 at 7:53 PM Maxim Kuvyrkov
wrote:
> > On Jun 6, 2023, at 15:48, Benjamin Priour via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >
> > From: Benjamin Priour
> >
> > This patch enchances -Wanalyzer-out-of-bounds that is no longer paired
> > wi
.
On Thu, Jun 8, 2023 at 7:53 PM Maxim Kuvyrkov
wrote:
> > On Jun 6, 2023, at 15:48, Benjamin Priour via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >
> > From: Benjamin Priour
> >
> > This patch enchances -Wanalyzer-out-of-bounds that is n
From: Benjamin Priour
For the record, below is the previous patch I submitted, with the
little formatting issues fixed - multiline docstring no ends on a newline.
It was otherwise validated by David Malcolm, so I already committed it.
This patch enhances -Wanalyzer-out-of-bounds that is no longe
On Tue, Jun 6, 2023 at 8:37 PM David Malcolm wrote:
>
> On Tue, 2023-06-06 at 18:05 +0200, Benjamin Priour wrote:
[...]
> [Looks like you droppped the mailing list from the recipients; was that
> intentional?]
>
Not at all, just me missing the reply all button.
> >
> > I indeed bootstrapped an
From: Benjamin Priour
This patch enchances -Wanalyzer-out-of-bounds that is no longer paired
with a -Wanalyzer-use-of-uninitialized-value on out-of-bounds-read.
This also fixes PR analyzer/109437.
Before there could always be at most one OOB-read warning per frame because
-Wanalyzer-use-of-unini
From: Benjamin Priour
ChangeLog:
* MAINTAINERS: New entry.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e4dee76e2df..b1d174af280 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -600,6 +600,7 @@ Antoniu Pop
Hi everyone,
My first patch, and I don't have write access yet.
This patch add a new warning under -Wshadow, to warn when a class
field hides another inherited.
At the moment, I'm looking for a similarly
named field independently of its visibility (whether it is public,
protected or private with
I've tried my hands on this first patch, to add new warnings for
name-hiding, i.e.
when a derived class's field shares the name of a base class's field.
I have currently put it under -Wshadow, but I could instead add a
-Wname-hiding warning, what do you think about this ?
At the moment, I'm using
Hi, below is my first patch ever. I ran the testsuites against trunk
20230322, everything seems OK to me, but as it is my first submission I'd
like to be sure of it.
Thanks a lot for the review !
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 68b62086340..147a7458488 100644
--- a/gcc/cp/clas
38 matches
Mail list logo
