On Wed, 2022-06-22 at 16:57 +0200, Tim Lange wrote:
> The checker reaches region-model.cc#3083 in my patch with the
> impl_region_model_context
> on the 'after' node of create_buffer() but then discards the warning
> inside
> impl_region_model_context::warn because m_stmt is null. Even if m_stmt
On Fri, 2022-06-24 at 00:00 +0530, Mir Immad wrote:
Thanks for the updated patch.
This is close to being ready.
One big issue is the target hook idea for isolating the target's
definition of the O_* flags as per Joseph's suggestion here:
https://gcc.gnu.org/pipermail/gcc/2022-June/238961.html
On Thu, 2022-06-23 at 23:58 +0530, Mir Immad wrote:
> Hi Dave,
> Thanks for the suggestions,
>
> I changed most of the things that you suggested, however reporting
> for
> warnings like close of known invalid fd was problematic:
>
> consider the following code:
>
> if (fd >= 0)
> { write (fd,..
Thanks for the updated patch.
Various comments inline below.
Sorry if this seems nitpicky in places.
I think the patch is nearly ready; please write a ChangeLog entry for
the next one (none of my proposed changes are going to affect what the
ChangeLog will look like, apart from new test case fil
Thanks for the updated patch.
Various notes below; mostly nits, but I realized there's a logic error
in fd_state_machine::on_condition that I hadn't spotted before...
[...snip...]
> diff --git a/gcc/analyzer/ChangeLog b/gcc/analyzer/ChangeLog
> index 53b3ffb487b..d30e94f2f62 100644
> --- a/gcc/a
On Wed, 2022-06-29 at 17:39 +0200, Tim Lange wrote:
> Hi,
Thanks for the updated patch.
Overall, looks nearly ready; various nits inline below, throughout...
>
> I've addressed most of the points from the review.
> * The allocation size warning warns whenever region_model::get_capacity
> retu
On our wiki I've renamed:
https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
to:
https://gcc.gnu.org/wiki/StaticAnalyzer
since it's not just me working on the analyzer.
I've updated all the internal links within the wiki accordingly; please
update any external links you see.
Thanks
Dave
On Fri, 2022-07-01 at 00:11 +0200, Tim Lange wrote:
> Hi,
>
> here's the updated patch that should address all the comments from the
> v2.
>
> - Tim
>
> This patch adds an checker that warns about code paths in which a
> buffer is
> assigned to a incompatible type, i.e. when the allocated buffer
On Sat, 2022-07-02 at 19:34 +0530, Mir Immad wrote:
> From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001
> From: mir
> Date: Sat, 2 Jul 2022 15:04:37 +0530
> Subject: [PATCH] analyzer: implement five new warnings for misuse of
> POSIX
> file descriptor APIs [PR106003].
>
> Th
On Sun, 2022-07-03 at 14:36 +0530, Mir Immad wrote:
> Thank you.
> I've committed the patch, and it is covered by the Developer
> Certificate
> of Origin (DCO).
Excellent - thanks.
Congratulations on getting your first patch into GCC!
Dave
On Sun, 2022-07-03 at 02:46 +, Jay K wrote:
> > check for double "close" of a FD (CWE-1341).
> > check for read/write of a closed file descriptor
>
> These sound good but kinda non general or incomplete to me.
> I mean, isn't the "right" thing, to disallow passing
> a closed fd to "al
On Sun, 2022-06-26 at 14:06 +0100, Iain Sandoe wrote:
> Hi Dave, folks,
>
> It seems to me that it is plausible that one could use the JIT in a
> heterogenous system, e.g. an x86_64-linux-host with some kind of co-
> processor which is supported as a GCC target (and therefore can be
> loaded with
std::unique_ptr is C++11, and I'd like to use it in the gcc/analyzer
subdirectory, at least. The following patch eliminates a bunch of
"takes ownership" comments and manual "delete" invocations in favor
of simply using std::unique_ptr.
The problem is that the patch makes use of std::make_unique,
On Mon, 2022-07-11 at 11:56 +0100, Pedro Alves wrote:
> Hi!
>
> On 2022-07-08 9:46 p.m., David Malcolm via Gcc wrote:
> > - pending_diagnostic *d,
> > +
> > std::unique_ptr d,
>
> I see that y
On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
[cross-posting to the glibc development mailing list; updating subject
accordingly]
> Hi everyone,
Hi Immad, GCC developers, and glibc developers.
glibc developers: Immad is a GSoC student, he's been adding checks for
file-descriptor-based API
On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote:
> On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
>
> [cross-posting to the glibc development mailing list; updating subject
> accordingly]
>
> > Hi everyone,
>
> Hi Immad, GCC developers, and glibc develo
On Wed, 2022-07-13 at 09:37 +0100, Szabolcs Nagy wrote:
> The 07/12/2022 18:25, David Malcolm via Libc-alpha wrote:
> > On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote:
> > > On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
> > > GCC's attribute syntax h
On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote:
> * Szabolcs Nagy via Gcc:
[adding Immad back to the CC list]
>
> > to be honest, i'd expect interesting fd bugs to be
> > dynamic and not easy to statically analyze.
> > the use-after-unchecked-open maybe useful. i would
> > not expect th
On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> * David Malcolm:
>
> > On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote:
> > > * Szabolcs Nagy via Gcc:
> >
> > [adding Immad back to the CC list]
> >
> > >
> >
good. Please use the above names/syntax for the next
iteration of your patch to -fanalyzer.
Thanks!
Dave
>
> Thanks
> Immad
>
>
> On Wed, Jul 13, 2022 at 7:31 PM Florian Weimer
> wrote:
>
> > * David Malcolm:
> >
> > > On Wed, 2022-07-13 at 14:0
On Thu, 2022-07-14 at 09:30 +0100, Szabolcs Nagy wrote:
> The 07/13/2022 12:55, David Malcolm wrote:
> > On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> > > * David Malcolm:
> > GCC trunk's -fanalyzer implements the new warnings via a state
> > machine
On Thu, 2022-06-23 at 19:20 -0400, David Malcolm wrote:
> On Fri, 2022-06-24 at 00:00 +0530, Mir Immad wrote:
[...snip...]
> > +
> > +enum access_mode
> > +fd_state_machine::get_access_mode_from_flag (int flag) const
> > +{
> > + /* FIXME: this code assumes
On Mon, 2022-07-18 at 20:35 +0100, lkcl via Gcc wrote:
> (apologies top-posting, strange mobile mailer). i would expect in that
> case that the Rust Foundation to work closely with Certification Mark
> Licensees, and to come to an accommodation, defining a subset if
> necessary.
>
> if the gcc dev
Is there documentation on setting up text editors to work with our
coding style? A lot of the next generation of developers aren't using
vi or emacs; they's using VS Code, CLion, and other editors. Does
anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ ?)
to work well on GCC's
t-end, we are
> > > currently
> > > under heavy development, so this means a fair amount of code
> > > churn
> > > still, and I don't see this changing until we can successfully
> > > compile
> > > the libcore crate later this year. Alth
ences are basically the changelog, some
> > style, and
> > `trtbd` instead of `p1689r5` as the format name).
> >
> > For testing within GCC, I'll work on the following:
> >
> > - scanning non-module source
> > - scanning module-importing source (`impor
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote:
> Unicode does not support such values because they are unrepresentable
> in
> UTF-16.
Wikipedia pointed me to RFC 3629, which was when UTF-8 introduced this
restriction, whereas libcpp was implementing the higher upper limit
from the earlier,
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote:
> This simplifies the interface for other UTF-8 validity detections
> when a
> simple "yes" or "no" answer is sufficient.
>
> Signed-off-by: Ben Boeckel
> ---
> libcpp/ChangeLog | 6 ++
> libcpp/charset.cc | 18 ++
> lib
On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote:
> Hello.
>
> Based on the very positive feedback I was given at the Cauldron
> Sphinx Documentation BoF,
> I'm planning migrating the documentation on 9th November. There are
> still some minor comments
> from Sandra when it comes to the PDF o
[Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> >
> > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
> > >
> > > 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > > > I
On Wed, 2022-11-23 at 20:49 -0500, Gavin Ray via Gcc wrote:
> Hey all, just a few questions about the fantastic GCC Static
> Analyzer:
Hi!
>
> - It's stated that support for C++ vs C is very limited. Does this
> apply if
> you're writing C++ that is very similar-looking to C and uses few
> of
On Sat, 2022-11-26 at 17:47 +, Jonathan Wakely wrote:
> On Sat, 26 Nov 2022, 15:48 Gavin Ray, wrote:
>
> > I was using if (fd != -1) and was still getting the warning which
> > confused
> > me
> > My suggestion was maybe to add the exact condition the fd analyzer
> > is
> > looking for to the
On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
>
> By reverse engineering other front ends, I learned, some months ago,
> how
> to create a function_decl GENERIC node that is the root of a GENERIC
> tree
> describing an entire fu
On Tue, 2022-12-13 at 20:15 +0100, Alejandro Colomar via Gcc wrote:
>
>
> On 12/13/22 20:08, Alejandro Colomar wrote:
> > Hi!
> >
> > For the following program:
> >
> >
> > $ cat buf.c
> > #include
> >
> > int main(void)
> > {
> > char *p, buf[5];
> >
> >
On Wed, 2023-02-08 at 10:57 +0200, Kristiyan Stoimenov via Gcc wrote:
> Hello,
>
> I would like to ask whether I could be part of the upcoming GSoC. I
> have
> been wanting to contribute to the project for some time now and I
> think
> that this would be a nice opportunity for that.
>
> I have lo
On Thu, 2023-02-16 at 15:35 +0100, Alejandro Colomar via Gcc wrote:
> Hi!
>
> I was preparing an example program of a use-after-realloc bug,
> when I found that GCC doesn't warn in a case where it should.
>
>
> alx@debian:~/tmp$ cat realloc.c
> #include
> #include
> #include
> #include
> #in
On Thu, 2023-02-16 at 22:48 -0500, Siddhesh Poyarekar wrote:
> On 2023-02-16 10:15, David Malcolm via Gcc wrote:
> > I'm not convinced that it's useful to the end-user to warn about
> > the
> > "use of q itself" case.
>
> FWIW, -Wuse-after-free
On Tue, 2023-02-21 at 22:26 +0100, Shengyu Huang via Gcc wrote:
> Dear all,
Hi Shengyu, and welcome.
>
> I want to work on the Static Analyzer project and just started to
> read the documentation these days,
Excellent! I'm the author/maintainer of the analyzer, so I would
mentor any such GSoC
On Wed, 2023-02-22 at 15:11 +0100, Shengyu Huang wrote:
> Hi Dave,
>
>
> > But a better place to look would probably be in our bugzilla; see
> > the
> > links on the wiki page:
> > https://gcc.gnu.org/wiki/StaticAnalyzer
> > The "open bugs" list currently has 41 "RFE" bugs ("request for
> > enh
ls.
I'd prefer to keep the mailing list involved in the conversation, as
other new contributors to GCC might find the info useful, and other
existing GCC contributors might have input on some of the discussion.
Thanks
Dave
>
> > On 22 Feb 2023, at 16:43, David Malcolm
> &
On Tue, 2023-02-28 at 15:46 +0100, Shengyu Huang wrote:
> Hi Dave,
>
> > On 22 Feb 2023, at 15:11, Shengyu Huang
> > wrote:
> >
> > > But a better place to look would probably be in our bugzilla; see
> > > the
> > > links on the wiki page:
> > > https://gcc.gnu.org/wiki/StaticAnalyzer
> > > Th
On Wed, 2023-03-01 at 12:16 +0100, Shengyu Huang wrote:
> Hi Dave,
>
> > On 1 Mar 2023, at 00:59, David Malcolm wrote:
> >
> > Did you get it to output your messages?
> >
>
>
> Yes, I chose to emit the warning before the supergraph or exploded
>
On Sat, 2023-03-04 at 08:11 +0530, Rishi Raj via Gcc wrote:
> Hi everyone,
Hi, and welcome!
>
> My name is Rishi Raj, and I am a third-year undergraduate studying
> Computer
> Science and Engineering at the Indian Institute of Technology
> Kharagpur in
> India. I wish to participate in this year
On Sat, 2023-03-04 at 20:56 +0530, Priyabrata Mondal via Gcc wrote:
> Respected sir,
> I am Priyabrata Mondal, an M.tech student in Electric
> Transportation at the Indian Institute of Technology(IIT), Mandi. I
> want to
> participate in Google Summer of Code 2023 by contributing to th
On Fri, 2023-03-03 at 19:28 +0100, Jan Hubicka via Gcc wrote:
> Hello,
> > Hi! I've been interested in compiler development for a while, and
> > would love to
> > work with any of you as part of GSoC, or even just as a side-
> > project on my own.
> >
> > I'm an 18 year-old student going into univ
On Sun, 2023-03-12 at 23:20 +0100, Shengyu Huang wrote:
> Hi Dave,
>
> > >
> > > 4. What’s the most interesting to me are PR103533
> > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533),
> >
> > Turning on taint detection by default would be a great project. It
> > would be good to run the
On Wed, 2023-03-15 at 16:24 +0100, Pierrick Philippe wrote:
> Hi everyone,
Hi Pierrick
>
> I have some question regarding the analyzer.
> I'm currently working on an fully out-of-tree static analyzer plugin.
> I started development on commit tagged as /basepoints/gcc-13/, but
> recently moved m
On Wed, 2023-03-15 at 17:35 +0100, Benjamin Priour via Gcc wrote:
> Hi,
> I'm Benjamin and I have been looking around the mail list and the
> code base
> since last December, where I had to write a simple Deca compiler
> within a
> month as a team. Next paragraph is me introducing myself -ranting
>
On Thu, 2023-03-16 at 09:54 +0100, Pierrick Philippe wrote:
> On 15/03/2023 17:26, David Malcolm wrote:
> > On Wed, 2023-03-15 at 16:24 +0100, Pierrick Philippe wrote:
[...snip...]
> >
> >
> > An ana::svalue is a pattern of bits (possibly symbolic, such as
> &
On Mon, 2023-03-20 at 22:36 +0530, Rishi Raj wrote:
> I am sorry for the previous messed-up reply :(. I was trying to reply
> back
> to my previous mail thread but mistakenly replied to the entire
> digest::((.
> Thanks, David and Martin, for the heads up, and I am sorry for the
> late
> reply due
don’t have a concrete
> example to investigate…During the project, how often do you expect we
> need to run the integration tests? I guess we run it whenever we
> don’t have a small example to work at hand, and iteratively we use
> the integration test results to construct a minimal exam
On Mon, 2023-03-20 at 13:28 +0100, Pierrick Philippe wrote:
> Hi everyone,
>
> I'm still playing around with the analyzer, and wanted to have a look
> at
> loop handling.
> I'm using a build from /trunk/ branch (/20230309/).
>
> Here is my analyzed code:
>
> '''
> 1| #include
> 2| int main(voi
On Tue, 2023-03-21 at 09:21 +0100, Pierrick Philippe wrote:
> On 21/03/2023 00:30, David Malcolm wrote:
> > On Mon, 2023-03-20 at 13:28 +0100, Pierrick Philippe wrote:
> > > Hi everyone,
> > >
> > > I'm still playing around with the analyzer, and wanted
On Tue, 2023-03-21 at 11:01 +0100, Shengyu Huang wrote:
> Hi Dave,
>
> > I implemented my own approach, with a "widening_svalue" subclass of
> > symbolic value. This is widening in the Abstract Interpretation
> > sense,
> > (as opposed to the bitwise operations sense): if I see multiple
> > value
On Sat, 2023-03-25 at 15:38 -0400, Eric Feng via Gcc wrote:
> Hi GCC community,
>
> For GSoC, I am extremely interested in working on the selected
> project
> idea with respect to extending the static analysis pass. In
> particular, porting gcc-python-plugin's cpychecker to a plugin for
> GCC
> -f
On Sun, 2023-03-26 at 18:03 +0200, Shengyu Huang wrote:
> Hi Dave,
>
> (I forgot to cc the list in the last email and it was too late to
> unsend. Sorry for sending you the same email again.)
>
> > On 20 Mar 2023, at 23:50, David Malcolm
> > mailto:dmalc...@redhat.co
or somesuch, documenting the required non-nullness of the args, and
that if PyList_GetItem returns successfully, the caller is borrowing a
reference to the object.
But exactly what these macros would look like would be a decision for
the CPython community (hence do it via PEP, based on a sample
im
On Wed, 2023-03-29 at 15:20 +0200, Alejandro Colomar via Gcc wrote:
> Hi!
>
> With both GCC 12.2.0 (Debian), and GCC 13.0.1 20230315 (built from
> source),
> I can reproduce these false positives.
>
> The reproducer program is a small program that checks a password
> against a
> hardcoded string,
On Thu, 2023-03-30 at 00:50 +0200, Benjamin Priour wrote:
> Hi David,
>
> I've been playing around with sm-malloc on C++ samples.
Note that the analyzer doesn't properly work yet on C++; see:
https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110
I'm hoping to address much of this in GCC
On Sat, 2023-04-01 at 01:33 +0200, Benjamin Priour wrote:
> Hi David,
>
>
> On Thu, Mar 30, 2023 at 2:04 AM David Malcolm
> wrote:
> > I think working on the C++ enablement prerequisites in the analyzer
> > would make more sense. I'd planned to do this myself f
On Sat, 2023-04-01 at 16:19 +0200, Shengyu Huang wrote:
> Hi Dave,
>
> > >
> > > I has looked into compiling those files with the patch some time
> > > ago;
> > > looking at my notes, one issue was with this on-stack buffer:
> > > char extra[1024];
> > > declared outside the loop. Inside the
On Sun, 2023-04-02 at 17:24 +, Sun Steven via Gcc wrote:
> Hi, Eric, Malcom,
Hi - and welcome to the GCC community.
>
> Sorry that I didn't check this thread before.
>
> It sounds like there are a lot of things to do. I want to offer some
> help.
>
> Let me add some backgrounds of memory m
On Sat, 2023-04-01 at 19:49 -0400, Eric Feng wrote:
> > For the task above, I think it's almost all there, it's "just" a
> > case
> > of implementing the special-case knowledge about the CPython API,
> > mostly via known_function subclasses.
>
> Sounds good.
>
>
> > In cpychecker I added some cu
On Sat, 2023-04-01 at 20:32 +, Sun Steven via Gcc wrote:
> Hello,
Hi!
I just replied to your other email in the "[GSoC] Interest and initial
proposal for project on reimplementing cpychecker as -fanalyzer plugin
" thread.
>
> I want to take part in this project.
>
> b. Write a plugin to ad
deadline.
Good luck!
Dave
>
> Best,
> Benjamin.
>
> On Mon, Apr 3, 2023 at 6:44 PM Benjamin Priour
> wrote:
>
> > Hi David,
> >
> > On Mon, Apr 3, 2023 at 12:38 AM David Malcolm
> > wrote:
> >
> > >
> > >
On Wed, 2023-04-05 at 19:50 +0200, Benjamin Priour wrote:
> Hi David,
>
> I used the below code snippet to experiment with out-of-bounds (OOB)
> on
> trunk. Three things occurred that I believe could see some
> improvement. See
> https://godbolt.org/z/57n459cEs for the warnings.
>
> int consecuti
On Thu, 2023-04-06 at 13:02 +0200, Benjamin Priour wrote:
> Hi David,
> I haven't yet looked into your suggestions, probably won't have time
> until
> tomorrow actually :/
> Still, here are some updates
>
> On Thu, Apr 6, 2023 at 2:32 AM David Malcolm
> wrote:
On Mon, 2023-05-01 at 14:43 +0200, Benjamin Priour wrote:
> Hi David,
Hi Benjamin
>
> Sorry for not being active these past two weeks I've been overwhelmed
> at my
> university with creating a new club and other uni stuff.
Fair enough.
>
> I just went back to solving these 3 bugs we discussed
On Mon, 2023-05-29 at 15:09 +0200, Benjamin Priour wrote:
> Hi,
>
> Regstrapping finally done for PR109439 - Spurious
> -Wanalyzer-use-of-uninitialized-value tagging along
> -Wanalyzer-out-of-bounds.
> Now only a OOB warning is reported when necessary instead of OOB +
> Use
> of uninitialized valu
On Wed, 2023-06-07 at 16:21 -0400, Eric Feng wrote:
> Hi everyone,
>
> I am one of the GSoC participants this year — in particular, I am
> working on a static analyzer plugin for CPython extension module
> code.
> I'm encountering a few challenges and would appreciate any guidance
> on
> the follo
On Wed, 2023-06-07 at 19:19 +0200, Benjamin Priour wrote:
> Hi,
>
> I've been mapping where the analyzer is lacking support of the
> operator new
> different variants.
> I've written a bunch of test cases already to demonstrate it, you can
> find
> them below.
> They are not yet formatted for a pa
On Mon, 2023-06-26 at 18:59 +0200, Aaron Lorey via Gcc wrote:
> Hello,
>
> this is the first time I am writing to a mailing list. I've tried
> researching the normal procedure but nothing special seems to be
> required.
>
> I'm currently trying to do a complete graph-discovery of GCC's symtab
> /
(apologies for top-posting; I'm on vacation and don't have my usual email setup)
Sounds interesting, but I'm having difficulty imagining exactly what
you have in mind.
Can you post one or more concrete examples of buggy code that would be
caught by such a warning?
Why wouldn't it be caught by C+
On Tue, 2023-07-25 at 00:49 -0400, Eric Feng wrote:
> Hi all,
Hi Eric, thanks for the update.
Various comments inline below...
>
> I would like to update everyone on the progress of the static
> analyzer
> plugin for CPython extension module code.
> Since the last update, I
> have implemented
On Thu, 2023-07-27 at 18:13 -0400, Eric Feng wrote:
> Hi Dave,
>
> Thanks for the comments!
>
> [...]
> > Do you have any DejaGnu tests for this functionality? For example,
> > given PyList_New
> > https://docs.python.org/3/c-api/list.html#c.PyList_New
> > there could be a test like:
> >
> >
On Sun, 2023-07-30 at 13:52 -0400, Eric Feng wrote:
> [...]
> > As noted in our chat earlier, I don't think we can easily make
> > these
> > work. Looking at CPython's implementation: PyList_Type's
> > initializer
> > here:
> > https://github.com/python/cpython/blob/main/Objects/listobject.c#L3101
On Mon, 2023-07-31 at 14:19 +0200, Benjamin Priour wrote:
> Hi David,
Hi Benjamin
>
> (subject's line totally stolen inspired from Eric's)
:)
> Last week as you know had some special circumstances therefore not
> much has
> been done.
FWIW you still seem to have got a lot done.
>
> I've cha
On Tue, 2023-08-01 at 09:57 -0400, Eric Feng wrote:
> >
> > My guess is that you were trying to do it from the
> > PLUGIN_ANALYZER_INIT
> > hook rather than from the plugin_init function, but it's hard to be
> > sure without seeing the code.
> >
>
> Thanks Dave, you are entirely right — I made t
On Tue, 2023-08-01 at 20:20 +0200, Jose E. Marchesi via Gcc wrote:
>
> > > The Gambit Scheme->C compiler has an option to generate more
> > > efficient
> > > code if it knows that all tail and sibling calls in the generated
> > > C
> > > code will be optimized. If gcc does not, however, optimize
On Wed, 2023-08-02 at 13:16 -0400, Bradley Lucier wrote:
> On 8/1/23 6:08 PM, David Malcolm wrote:
> > FWIW I added it to support Scheme from libgccjit;
>
> Do you know of any Scheme using libgccjit?
I don't.
It's not Scheme, but in case it's relevant, Emacs is do
in Tcl, alas;
let me know if you want help with that.
Dave
>
> Best,
> Eric
>
> On Tue, Aug 1, 2023 at 1:06 PM David Malcolm
> wrote:
> >
> > On Tue, 2023-08-01 at 09:57 -0400, Eric Feng wrote:
> > > >
> > > > My guess is that you wer
On Fri, 2023-08-04 at 16:48 -0400, Eric Feng wrote:
> On Fri, Aug 4, 2023 at 11:39 AM David Malcolm
> wrote:
> >
> > On Fri, 2023-08-04 at 11:02 -0400, Eric Feng wrote:
> > > Hi Dave,
> > >
> > > Tests related to our plugin which depend on Pytho
On Fri, 2023-08-04 at 18:42 -0400, David Malcolm wrote:
> On Fri, 2023-08-04 at 16:48 -0400, Eric Feng wrote:
> > On Fri, Aug 4, 2023 at 11:39 AM David Malcolm
> > wrote:
> > >
> > > On Fri, 2023-08-04 at 11:02 -0400, Eric Feng wrote:
> > > > Hi Dave,
On Mon, 2023-08-07 at 15:04 +0200, Benjamin Priour wrote:
> Hi Dave,
Hi Benjamin.
>
> I made some more progress on moving tests from gcc.dg/analyzer/ to
> c-c++-common/analyzer.
Thanks.
It sounds like you have a large amount of "pending" work that is
accumulating on your hard drive. This make
On Mon, 2023-08-07 at 15:04 +0200, Benjamin Priour wrote:
> Hi Dave,
[...snip...]
> Last test I'd like to discuss is analyzer/pr99193-1.c
>
[...snip...]
>
> If I comment out the call to perror("realloc"), then G++ behaves as
> GCC.
> If I replace perror ("realloc") by any other call, to a ful
On Mon, 2023-08-07 at 14:31 -0400, Eric Feng wrote:
> On Fri, Aug 4, 2023 at 6:46 PM David Malcolm
> wrote:
> >
> > On Fri, 2023-08-04 at 18:42 -0400, David Malcolm wrote:
> > > On Fri, 2023-08-04 at 16:48 -0400, Eric Feng wrote:
> > > > On Fri
s,
which might be due to
- possibly not having all of the patch?
- differences between python 3.8 and python 3.9
- differences between the --cflags affecting the gimple seen by the
analyzer
Anyway, hope this gets you unstuck.
Dave
From 16ca49cb40c3d34b3547b2e0834bb51ae26e2eb5 Mon Sep 17 00:
On Tue, 2023-08-08 at 12:51 -0400, Eric Feng wrote:
> Unfortunately, there doesn’t seem to be any ERRORs in the .log nor
> any of the debug print statements which I’ve scattered within proc
> dg-require-python-h when run. I’ve attached the WIP below; thank you!
> Please note that in this version of
On Wed, 2023-08-09 at 15:22 -0400, Eric Feng wrote:
> Thank you for your help in getting dg-require-python-h working! I can
> confirm that the FAILs are related to differences between the --
> cflags
> affecting the gimple seen by the analyzer. For this reason, I have
> changed it to --includes for
On Wed, 2023-08-16 at 15:17 -0400, Eric Feng via Gcc wrote:
> Hi everyone,
[fixing typo in my email address]
Hi Eric, thanks for the update, and the WIP patch.
>
> After pushing the code that supports various known function classes last week,
> I've turned my attention back to the core referenc
On Mon, 2023-08-21 at 10:05 -0400, Eric Feng wrote:
> Hi Dave,
>
> Just wanted to give you and everyone else a short update on how
> reference count checking is going — we can now observe the refcnt
> diagnostic being emitted:
>
> rc3.c:22:10: warning: REF COUNT PROBLEM
> 22 | return list;
>
On Wed, 2023-08-23 at 17:15 -0400, Eric Feng wrote:
> On Mon, Aug 21, 2023 at 11:04 AM David Malcolm
> wrote:
> >
> > On Mon, 2023-08-21 at 10:05 -0400, Eric Feng wrote:
> > > Hi Dave,
> > >
> > > Just wanted to give you and everyone else a short up
On Wed, 2023-08-23 at 15:55 +0200, Benjamin Priour wrote:
> Hi David,
>
> A quick update on transitioning the analyzer tests from gcc.dg to
> c-c++-common.
> As discussed previously, C builtins are not C++ builtins, therefore I
> had
> to add
> recognition of the builtins by their name rather than
On Fri, 2023-08-25 at 08:50 -0400, Eric Feng wrote:
> Hi Dave,
>
> Please find an updated WIP patch on reference count checking below. Some
> parts aren't properly formatted yet; I apologize for that.
>
> Since the last WIP patch, the major updates include:
> - Updated certain areas of the core a
On Fri, 2023-08-25 at 16:12 -0400, Michael Welsh Duggan via Gcc wrote:
> I am attempting to debug an issue in gcc (PR 110827, if curious). In
> order to do this I have built a stage 1 compiler with debugging and
> without optimization as discussed here:
>
> https://gcc.gnu.org/wiki/DebuggingGCC#B
On Tue, 2023-08-29 at 00:31 -0400, Eric Feng wrote:
> Hi Dave,
Hi Eric.
Thanks for the updated patch.
A few nits below; this is OK for trunk with them fixed...
[...snip...]
>
> gcc/analyzer/ChangeLog:
> PR analyzer/107646
> * engine.cc (impl_region_model_context::warn): New optional p
On Tue, 2023-08-29 at 13:28 -0400, Eric Feng wrote:
> Additionally, by using the old model and the pointer per your
> suggestion,
> we are able to find the representative tree and emit a more accurate
> diagnostic!
>
> rc3.c:23:10: warning: expected ‘item’ to have reference count: ‘1’
> but ob_ref
On Sat, 2023-08-26 at 16:44 +0200, Benjamin Priour wrote:
> Hi David,
>
> Sorry I missed out on your answer about the operator new patch on the
> IRC.
> Should I submit the first bit of the operator new patch ? Putting
> aside for
> now fixing the
> "uninitialized value" that accompanies "null der
On Mon, 2023-08-28 at 17:13 +0200, Benjamin Priour wrote:
> Hi,
>
> Test gcc.dg/analyzer/pr94362-1.c actually has an additional
> null_deref
> > warning in C++, which is not affected by exceptions
> > or optimizations. I will keep updated on that one. Note that no
> > warnings
> > are emitted for
On Wed, 2023-08-30 at 23:24 +0200, FX Coudert wrote:
> > std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573,
> > are not available because is not included.
>
> I originally thought this was only seen in cross-compilers, but it
> actually broke bootstrap on darwin.
> Attached patch
401 - 500 of 557 matches
Mail list logo
