Re: diagnostic framework message array

On Sat, 2025-01-11 at 12:32 -0500, David Malcolm wrote: > On Fri, 2025-01-10 at 15:52 -0500, James K. Lowden wrote: > > What should I do with the following message? > > > >  cobol1: warning: depth line copybook filename > >   - -- > > --

Re: diagnostic framework message array

On Fri, 2025-01-10 at 15:52 -0500, James K. Lowden wrote: > What should I do with the following message? > >  cobol1: warning: depth line copybook filename >   - > >  cobol1: warning: 1    1 prog.cob >  cobol1: warning:

Re: libdiagnostics name clash

On Thu, 2024-11-28 at 03:56 +, Sam James wrote: > David Malcolm via Gcc writes: > > > I merged libdiagnostics to GCC trunk on Monday: > >   https://gcc.gnu.org/wiki/libdiagnostics > > > > Unfortunately I've since discovered there's at least one >

Re: libdiagnostics name clash

On Thu, 2024-11-21 at 08:08 +0200, Eli Zaretskii wrote: > > Date: Wed, 20 Nov 2024 16:11:16 -0500 > > From: David Malcolm via Gcc > > > > I merged libdiagnostics to GCC trunk on Monday: > >   https://gcc.gnu.org/wiki/libdiagnostics > > > > Unfortunat

libdiagnostics name clash

I merged libdiagnostics to GCC trunk on Monday: https://gcc.gnu.org/wiki/libdiagnostics Unfortunately I've since discovered there's at least one libdiagnostics .so already in Debian: https://tracker.debian.org/pkg/diagnostics https://packages.debian.org/search?searchon=contents&keywords=libdiag&

Re: plugin for reference counting

On Tue, 2024-11-12 at 16:54 -0500, Aravind Ceyardass via Gcc wrote: > Hello all, > > I have implemented a GCC plugin that instruments code to implement > reference counted memory management instead of manually adding calls > to inc()/dec() reference counts. It is a work in progress. Any > ideas/su

Automatic URLs in forgejo? (was Re: Sourceware forge experiment)

On Mon, 2024-10-21 at 03:22 +0200, Mark Wielaard wrote: > As an experiment Sourceware is now running an forgejo v9 instance at > https://forge.sourceware.org > > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org > address > can register an account (please use the same user name as you

Re: GCC Doxygen documentation

On Mon, 2024-09-23 at 15:45 -0700, Bryon Quackenbush via Gcc wrote: > Greetings all, > >    I am just starting the fun process of getting familiar with the > GCC > compiler and all it's various components (I'm starting out with > LIBCPP, > since that seems relatively small and simple).. Welcome!

Re: LTO progress indicator

On Sun, 2024-09-15 at 15:20 +0330, Ghorban M. Tavakoly via Gcc wrote: > Hi > > On Sun, Sep 15, 2024 at 11:59 AM Jan Hubicka wrote: > > > > On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc > > > wrote: > > > > > > > > > > Is there any change to have some LTO progress indicator > > >

Re: On the subject of module consumer diagnostics.

On Fri, 2024-09-06 at 08:44 -0400, Ben Boeckel via Gcc wrote: > On Tue, Sep 03, 2024 at 16:53:43 +0100, Iain Sandoe wrote: > > I think that might be a misunderstanding on the part of the author; > > AFAIU both GCC and MSVC _do_ require access to the sources at BMI > > consume-time to give decent di

Fixing dormant bugs in obstack code

I've been debugging a use-immediately-after-free bug involving obstacks (the bug isn't in trunk; I found it whilst testing one of my patches). It was only visible as a crash when it happened that the call to obstack_free led to the underlying buffer being freed. Most of the time, the bug was dorm

Re: Preparation for this weeks call

On Wed, 2024-07-24 at 02:59 -0500, Thor Preimesberger via Gcc wrote: > Sure - we actually already emit json in optinfo-emit-json.cc,  and > there > are implementations of json and pretty-printing/dumping it out also. > I got > a hacky version of our current raw dump working with json objects, > but

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 17:54 +0100, Joern Wolfgang Rennecke wrote: > > > On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote: >   > I guess you could reduce the differences between platforms if you > didn't > > use types as defined by headerfiles directly, as they might be > > #defines > > or type

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 17:13 +0100, Joern Wolfgang Rennecke wrote: > > > On 22/07/2024 16:44, David Malcolm wrote: > > Does it help to hack this change into prune.exp: > > > > diff --git a/gcc/testsuite/lib/prune.exp > > b/gcc/testsuite/lib/prune.exp > > index d00d37f015f7..f467d1a97bc6 100644 >

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 11:37 +0100, Joern Wolfgang Rennecke wrote: > While on x86_64-pc-linux-gnu, the second diagram shows the type > written > as 'int', as expected, on a 16 and 32 bit newlib based toolchain, it > is > being output as int32_t .  And all the formatting is also a bit > different,

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Mon, 2024-07-08 at 17:01 +0200, Alejandro Colomar wrote: > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > > Why is this change worth > > > > making? Real-world programs do not make calls like that. > > > > > > Because it makes analysis of 'restrict' more consistent.  The > >

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Sun, 2024-07-07 at 14:42 +0200, Alejandro Colomar wrote: > Hi Paul, > > On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: > > On 7/7/24 03:58, Alejandro Colomar wrote: > > > > > I've incorporated feedback, and here's a new revision, let's call > > > it > > > v0.2, of the draft for a W

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

On Tue, 2024-07-02 at 22:39 +0200, Mark Wielaard wrote: > Hi David, > > On Tue, Jul 02, 2024 at 03:57:58PM -0400, David Malcolm wrote: > > > > At -O0 sure, that is how __builtin_constant_p works. > > > > The above is intended for optimized compilation, and I think it > > > > works just fine then.

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

On Tue, 2024-07-02 at 21:21 +0200, Florian Weimer wrote: > * Jakub Jelinek: > > > On Tue, Jul 02, 2024 at 12:54:09PM -0400, David Malcolm via Gcc > > wrote: > > > Back in 2007 glibc gained some logic to implement "error" and > > > "error_at_li

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

On Tue, 2024-07-02 at 19:02 +0200, Jakub Jelinek wrote: > On Tue, Jul 02, 2024 at 12:54:09PM -0400, David Malcolm via Gcc > wrote: > > Back in 2007 glibc gained some logic to implement "error" and > > "error_at_line" by splitting into zero and non-zero case

Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

Back in 2007 glibc gained some logic to implement "error" and "error_at_line" by splitting into zero and non-zero cases, with the nonzero case calling a "noreturn" function [1]. This doesn't seem to work. I tested back to 4.8.1 with Compiler Explorer [2], which seems to be the earliest GCC that su

Re: SARIF support in GCC: wiki page and BZ keyword

On Fri, 2024-06-21 at 18:46 -0400, Eric Gallager wrote: > On Fri, Jun 21, 2024 at 12:12 PM David Malcolm via Gcc > wrote: > > > > I've create a wiki page to track our support for GCC: > >   https://gcc.gnu.org/wiki/SARIF > > > > and a keyword "SAR

SARIF support in GCC: wiki page and BZ keyword

I've create a wiki page to track our support for GCC: https://gcc.gnu.org/wiki/SARIF and a keyword "SARIF" in our bugzilla instance for bugs relating to it (see links on the above page). Dave

Building libgccjit with -fno-semantic-interposition? ( was Re: 1.76% performance loss in VRP due to inlining)

On Tue, 2024-04-30 at 21:15 +0200, Richard Biener via Gcc wrote: > > > > Am 30.04.2024 um 21:11 schrieb Jason Merrill via Gcc > > : > > > > On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc > > wrote: > > > > > > In implementing prange (pointer ranges), I have found a 1.74% > > > slowdow

Re: GSoC Timeline Review

On Tue, 2024-04-02 at 10:06 -0400, David Malcolm wrote: > What timezone are you in?  (I'm in EDT, UTC+4) Sorry, that should be UTC-4 (on the east coast of the US) Dave

Re: GSoC Timeline Review

On Sat, 2024-03-30 at 13:54 +0200, Nada Elsayed wrote: > I think that I didn't fully understand the project, so I read more > and > updated the Timeline Suggestion. Hi Nada I'm very sorry for not responding sooner; I've been dealing with an difficult issue that's arisen outside of my computer wo

Re: Using std types and functions within GCC

On Thu, 2024-03-14 at 13:28 +, Jonathan Wakely via Gcc wrote: > On Thu, 14 Mar 2024 at 12:54, Pierrick Philippe > wrote: > > > > Hi all, Hi Pierrick! It was good to meet you at FOSDEM. > > > > I was wondering, is there any conventions or guidelines regarding > > the > > usage of types and

Re: Discussing gcc font end hobby project

On Tue, 2024-02-27 at 10:15 +0100, Richard Biener via Gcc wrote: > On Fri, Feb 23, 2024 at 10:22 AM Miro Palmu via Gcc > wrote: > > > > Hi. > > > > I have a idea about long term hobby project relating to gcc, > > so with this email I'm asking feedback about the idea > > early rather than later.

Valid types for a binary op in GENERIC?

The ICE in PR analyzer/111441 is due to this assertion in fold_binary_loc failing: 11722 gcc_assert (TYPE_PRECISION (atype) == TYPE_PRECISION (type)); where code=MULT_EXPR, type=, and: (gdb) p type $1 = (gdb) p atype $2 = due to the analyzer building a mult_expr node with tho

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

On Tue, 2024-02-13 at 23:40 -0800, Andi Kleen via Gcc wrote: > Robert Dubner writes: > > > There didn't seem to be any such functionality in GCC.  I found a > > routine > > in print-tree.cc which printed out a single node, but I needed to > > understand the entire tree of nodes for a function. >

Re: [Tree][Static Analyzer] Tree representing types and svalues type

On Wed, 2024-01-17 at 17:52 -0500, David Malcolm wrote: > On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote: > > Hi David, hi all, > > Hi Pierrick. > > > > > I was playing along with APIs from the Static Analyzer and > > encountered a > > segfault in gcc/tree.cc:5068 (i.e. in function b

Re: GCC GSoC 2024: Call for project ideas and mentors

On Mon, 2024-01-15 at 18:48 +0100, Martin Jambor wrote: > Hello, > > another year has passed, Google has announced there will be again > Google > Summer of Code (GsoC) in 2024 and the deadline for organizations to > apply is already approaching (February 6th).  I'd like to volunteer > to > be the

Re: [Tree][Static Analyzer] Tree representing types and svalues type

On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote: > Hi David, hi all, Hi Pierrick. > > I was playing along with APIs from the Static Analyzer and > encountered a > segfault in gcc/tree.cc:5068 (i.e. in function build2 and failure is > due > to a > gcc_assert call), after a call to > an

Re: Expected warning maybe-uninitialized does not appear using g++13.2.0?

On Wed, 2023-12-20 at 11:16 -0800, Eric Batchelor wrote: > Hello, I unintentionally stumbled upon some strange behaviour that > occurred due to a typo. > I reproduced the behaviour where an object (std::string in my case) > can > be passed to a function by reference, uninitialized, WITHOUT a > co

Re: Debugging the tree object constructed by cp_parser

On Mon, 2023-12-04 at 10:09 -0500, Stan Srednyak wrote: > Hi David, thanks for your email. I really appreciate it. > > Your notes are certainly of help, but I also had a specific question: > how > to access the trees as they are being constructed by the front end. > Do you > have an answer to this

Re: Debugging the tree object constructed by cp_parser

On Sat, 2023-12-02 at 17:41 -0500, Stan Srednyak via Gcc wrote: > Dear GCC community, > > I am assigned the task to debug the trees as being produced by the > cp_parser. I was able to print some of the trees using the > debug_tree() > function. But I am still confused as to where is the tree objec

Re: Typo in "C++ Standards Support in GCC"

On Wed, 2023-11-15 at 08:23 +, Taisei Katô via Gcc wrote: > Dear GCC developers, > > There is a typo in Section "C++14 Support in GCC" in "C++ Standards > Support in GCC." > "GCC has full support for the of the 2014 C++ standard." > Good ca

GCC devroom at FOSDEM 2024: Call for Participation open

We're excited to announce that GCC will have a developer room at the upcoming FOSDEM 2024, in Brussels, Belgium: https://fosdem.org/2024/ This email is a Call for Presentations about GCC for the developer room. Important Dates: 1st December 2023 Submission deadline 8th December 202

Re: Need some analyzer testcase help

On Fri, 2023-10-27 at 12:48 -0700, Andrew Pinski wrote: > Hi David and others, >   I am in the process of improving phi-opt and moving what was > handled > in value_replacement to match-and-simplify and ran into a few > failures > in the analyzer testsuite. > For an example c-c++-common/analyzer/in

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

On Mon, 2023-10-23 at 11:24 -0400, Jason Merrill wrote: > On 10/23/23 11:16, David Malcolm wrote: > > On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc > > wrote: > > > > > > This simplifies the interface for other UTF-8 validity detections > > > when a > > > simple "yes" or "no" answer is suff

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc wrote: > > This simplifies the interface for other UTF-8 validity detections when a > simple "yes" or "no" answer is sufficient. > > libcpp/ > > * charset.cc: Add `_cpp_valid_utf8_str` which determines whether > a C string is vali

Re: Anyone interesting to submit a GCC devroom request proposal at FOSDEM? (was Re: After Cauldron - online mini BoFs and Fosdem)

On Tue, 2023-10-03 at 14:37 +0200, Dodji Seketeli wrote: > Good day fine fellows! > > [...] > > Mark Wielaard a écrit: > > > Also Dodji, Jose and Gwen (on CC) are trying to coordinate a Fosdem > > devroom for the various projects. Please contact them if you want > > to > > help out with that. >

Re: GCC workshop at university

On Wed, 2023-09-27 at 22:20 +0200, Benjamin Priour wrote: > Hi everyone, > > I'm in my final MSc year and figured after this weekend's Q&A > that I could replicate David's workshop on a smaller scale within my > university. > > Would that be doable/acceptable ? That sounds like a great idea. >

Re: [PATCH] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646]

On Sun, 2023-09-10 at 22:12 -0400, Eric Feng wrote: > On Thu, Sep 7, 2023 at 1:28 PM David Malcolm > wrote: > > > On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote: > > [...snip...] > > > > > > I know you're emulating the old behavior I implemented way back in > > cpychecker, but I don't li

Re: [PATCH] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646]

On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote: > Hi Dave, Hi Eric, thanks for the patch. > > Recently I've been working on symbolic value support for the reference > count checker. I've attached a patch for it below; let me know it looks > OK for trunk. Thanks! > > Best, > Eric > > --- >

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

On Fri, 2023-09-01 at 04:49 +0200, Hans-Peter Nilsson wrote: > (Looks like this was committed as r14-3580-g597b9ec69bca8a) > > > Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, Eric Feng > > > > From: Eric Feng via Gcc > > > gcc/testsuite/ChangeLog: > >   PR analyzer/107646 > > * gcc.dg/p

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

On Thu, 2023-08-31 at 21:25 -0400, Eric Feng wrote: > On Thu, Aug 31, 2023 at 4:19 PM David Malcolm > wrote: > > > > On Thu, 2023-08-31 at 15:09 -0400, Eric Feng wrote: > > > On Thu, Aug 31, 2023 at 1:01 PM David Malcolm > > > > > > wrote: > > > > > > > > On Wed, 2023-08-30 at 18:15 -0400, Eric

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

On Thu, 2023-08-31 at 15:09 -0400, Eric Feng wrote: > On Thu, Aug 31, 2023 at 1:01 PM David Malcolm > wrote: > > > > On Wed, 2023-08-30 at 18:15 -0400, Eric Feng wrote: [...] > > > > > > Thanks; pushed to trunk with nits fixed: > > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=597b9ec69bca8a

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

On Wed, 2023-08-30 at 18:15 -0400, Eric Feng wrote: > On Tue, Aug 29, 2023 at 5:14 PM David Malcolm > wrote: > > > > 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 representati

Re: Analyzer failure due to missing header

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

Re: analyzer: Weekly update on extending C++ support (3)

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

Re: analyzer: Weekly update on extending C++ support (3)

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

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

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

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

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

Re: How can I run xg++ from its build location?

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

Re: Update on CPython Extension Module -fanalyzer plugin development

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

Re: analyzer: How to recognize builtins

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

Re: Update on CPython Extension Module -fanalyzer plugin development

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 update on how > > > reference count checking is g

Re: Update on CPython Extension Module -fanalyzer plugin development

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; >

Re: Update on CPython Extension Module -fanalyzer plugin development

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

Re: [PATCH v2] analyzer: More features for CPython analyzer plugin [PR107646]

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

Re: [PATCH] WIP for dg-require-python-h [PR107646]

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

Re: [PATCH] WIP for dg-require-python-h [PR107646]

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

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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, Aug 4, 2023 at 11:39 AM David Malcolm > > > > > >

Re: analyzer: Weekly update on extending C++ support (2)

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

Re: analyzer: Weekly update on extending C++ support (2)

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

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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, > > > > > > > > Tests related to our plugin

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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 Python-specific > > > definitions have been run by inclu

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

On Fri, 2023-08-04 at 11:02 -0400, Eric Feng wrote: > Hi Dave, > > Tests related to our plugin which depend on Python-specific > definitions have been run by including /* { dg-options "-fanalyzer > -I/usr/include/python3.9" } */. This is undoubtedly not ideal; is it > best to approach this problem

Re: Where to place warning about non-optimized tail and sibling calls

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 doing ahead-of- time compilation o

Re: Where to place warning about non-optimized tail and sibling calls

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

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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

Re: analyzer: Weekly update and questions on extending c++ support.

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

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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: > > > >

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

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

Re: analyzer: New state machine should be C++ only

(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+

Re: Mapping of TREE_CODE to tree_node

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 > /

Re: An overview of the analyzer support of the operator new

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

Re: On inform diagnostics in plugins, support scripts for gdb and modeling creation of PyObjects for static analysis

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

Re: Testing a patch

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

Re: PR109439 - Terminate analysis path when OOB detected

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

Re: -Wanalyzer-use-of-uninitialized-value always shadows -Wanalyzer-out-of-bounds

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 Wed, 2023-04-05 at 19:50 +

Re: -Wanalyzer-use-of-uninitialized-value always shadows -Wanalyzer-out-of-bounds

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

Re: [GSoC][analyzer-c++] Submission of a draft proposal

On Mon, 2023-04-03 at 18:46 +0200, Benjamin Priour wrote: > Following last mail, a classic I forgot to link my draft ! > https://docs.google.com/document/d/1MaLDo-Rt8yrJIvC1MO8SmFc6fp4eRQM_JeSdv-1kbsc/edit?usp=sharing Some notes: * The document still has some notes in italics marked "[RFC]" whic

Re: GSoC: want to take part in `Extend the static analysis pass for CPython Extension`

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

Re: [GSoC] Interest and initial proposal for project on reimplementing cpychecker as -fanalyzer plugin

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

Re: [GSoC] Interest and initial proposal for project on reimplementing cpychecker as -fanalyzer plugin

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

Re: [GSoC][Static Analyzer] First proposal draft and a few more questions/requests

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

Re: [GSoC][analyzer-c++] Enable enough C++ support for self-analysis

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 for GCC 14, > > but > > there are p

Re: [GSoC] A bunch of questions about sm-malloc behavior, and proposition of a GSoC subject.

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

Re: -Wanalyzer-malloc-leak false positives

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,

Re: [GSoC] Interest and initial proposal for project on reimplementing cpychecker as -fanalyzer plugin

On Tue, 2023-03-28 at 08:08 -0400, Eric Feng wrote: > My apologies. Forgot to CC the mailing list in my previous e-mail. > Original reply below: > > ___ > > > Hi David, > > Thank you for your feedback! > > > [...snip...] > > > > > > Error-handling checking: Various checks for common er

Re: [GSoC][Static Analyzer] First proposal draft and a few more questions/requests

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.com>> wrote: > > > > I think if

Re: [GSoC] Interest and initial proposal for project on reimplementing cpychecker as -fanalyzer plugin

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

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

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

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

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 to have a > > > look > > > at > > > loop han

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

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

Re: [GSoC][Static Analyzer] First proposal draft and a few more questions/requests

On Mon, 2023-03-20 at 18:28 +0100, Shengyu Huang wrote: > Hi Dave, > > Thanks for always getting back to me so promptly! I am drafting the > proposal today. Here is the link: > > https://docs.google.com/document/d/1MRI1R5DaX8kM6DaqRQsEri5Mx2FvHmWv13qe1W0Bj0g/ > > (The proposal was first written

Re: [GSOC] getting "gdb: unrecognized option '-dumpdir'' while trying to debug gcc using gdb

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

  1   2   3   >