.
@c Contributed by Benjamin Priour .
@title Modulo Scheduler Internals
@node Modulo Scheduler
@chapter Modulo Scheduler
@cindex SMS
@cindex modulo scheduler
@menu
* Modulo Scheduler Overview:: Overview
* Pruned DDG:: How to make SMS more likely to succeed
* SMS interoperability:: Interoperability
FE between the two configurations.
Need further investigation.
Best,
Benjamin.
On Mon, Sep 11, 2023 at 10:03 AM Jiang, Haochen
wrote:
> On Linux/x86_64,
>
> 50b5199cff690891726877e1c00ac53dfb7cc1c8 is the first bad commit
> commit 50b5199cff690891726877e1c00ac53dfb7cc1c8
> A
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:
>> &g
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 mis
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
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
w (p + 1) int32_t; /* { dg-warning "heap-based buffer
overflow" } */
+ *i = 42; /* { dg-warning "heap-based buffer overflow" } */
+ free (p);
+}
Is it OK for trunk ?
I didn't resend the whole patch as it otherwise was OK.
Thanks,
Benjamin.
On Fri, Sep 1, 2023 at 12:07 PM Be
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/
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'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
> > ca
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
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
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 a
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.
> &g
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 d
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
new-2.C: New test.
* g++.dg/analyzer/noexcept-new.C: New test.
* g++.dg/analyzer/placement-new-size.C: New test.
Signed-off-by: benjamin priour
---
gcc/analyzer/analyzer.h | 1 +
gcc/analyzer/call-details.cc | 11 ++
gcc/analyzer/call-de
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
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
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
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
>From 04186f04a3f172d7ccf9824cc71faca489eb39af Mon Sep 17 00:00:00 2001
From: benjamin priour
Date: Thu, 22 Jun 2023 21:39:05 +0200
Subject: [PATCH] [PATCH] analyzer: Fix regression bug after
r14-1632-g9589a46ddadc8b [pr110198]
g++.dg/analyzer/pr100244.C was failing after a patch of PR109439.
The reas
after the patch.
It is now fixed.
Thanks again a lot for you attention,
Benjamin.
On Fri, Jun 9, 2023 at 2:19 AM Benjamin Priour wrote:
> Hi David,
>
> So first real committed patch actually was a misstep. So I'm currently
> fixing that.
> The issue is that the original idea,
irst commit, and pushed it.
Thanks,
Benjamin.
-- Forwarded message -
From: Benjamin Priour
Date: Thu, Jun 8, 2023 at 8:18 PM
Subject: Re: [PATCH] analyzer: Standalone OOB-warning [PR109437, PR109439]
To: Maxim Kuvyrkov
Cc: , Benjamin Priour , <
dmalc...@redhat.com>
Hi,
Yes of co
.
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
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.
> >
>
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
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
: Additional warning for name-hiding [PR12341]
Add a new warning for name-hiding. When a class's field
is named similarly to one inherited, a warning should
be issued.
2023-04-13 Benjamin Priour vutlk...@gcc.gnu.org
gcc/cp/ChangeLog:
* search.cc (lookup_member):
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
39 matches
Mail list logo
