-Wanalyzer-malloc-leak false positives

[Alejandro Colomar via Gcc]

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, and conditionally prints "validated".  I wrote it
precisely to demonstrate how [[gnu::malloc(deallocator)]] can be used to
ensure that passwords are not leaked in memory, but I found out that it
fails to detect some conditions.

Here's the program (it uses agetpass(), as defined in the shadow project):

$ cat pass.c 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define PASS_MAX  BUFSIZ - 1


#define MALLOCARRAY(n, type)   ((type *) mallocarray(n, sizeof(type)))


[[gnu::malloc, gnu::malloc(free)]] void *mallocarray(size_t nmemb, size_t size);
void erase_pass(char *pass);
[[gnu::malloc(erase_pass)]] char *agetpass(const char *prompt);


void
do_work(void)
{
char  *pass;

pass = agetpass("Enter your password: ");
if (pass == NULL)
err(EXIT_FAILURE, "agetpass");

if (strcmp(pass, "secret") == 0)
puts("validated");

/* erase_pass() zeroes the memory (think of memset(3), or bzero(3))
   and then releases the memory to the system (think of free(3)).
   If you only call free(pass), then you release the memory to the
   system without zeroing it.  Remember it contains a password!
   We would be leaking a password into the system memory, which can
   later be assigned to a different process.

   So, we should call erase_pass() as soon as possible, but let's
   say we forgot, and just call free():
*/
#if defined(BUG_1)
// We forgot to zero the memory.
free(pass);
// GCC correctly catches this as -Wmismatched-dealloc
#elif defined(BUG_2)
// We zeroed, but forgot to free(3).
bzero(pass, PASS_MAX + 2);
// GCC misses this.
#elif defined(BUG_3)
// We forgot both of them.
// GCC also misses this.
#else
erase_pass(pass);  // OK, but 2 false positives.
#endif
}


int
main(void)
{
do_work();

for (;;)
sleep(1);
}


void *
mallocarray(size_t nmemb, size_t size)
{
return reallocarray(NULL, nmemb, size);
}


char *
agetpass(const char *prompt)
{
char*pass;
size_t  len;

pass = MALLOCARRAY(PASS_MAX + 2, char);
if (pass == NULL)
return NULL;

if (readpassphrase(prompt, pass, PASS_MAX + 2, RPP_REQUIRE_TTY) == NULL)
goto fail;

len = strlen(pass);
if (len == PASS_MAX + 1) {
errno = ENOBUFS;
goto fail;
}

return pass;

fail:
freezero(pass, PASS_MAX + 2);
return NULL;
}


void
erase_pass(char *pass)
{
freezero(pass, PASS_MAX + 2);
}



$ cc -Wall -Wextra pass.c $(pkgconf --cflags --libs libbsd-overlay) -fanalyzer 
-O3
pass.c: In function ‘agetpass’:
pass.c:84:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
   84 | if (pass == NULL)
  |^
  ‘do_work’: events 1-3
|
|   22 | do_work(void)
|  | ^~~
|  | |
|  | (1) entry to ‘do_work’
|..
|   26 | pass = agetpass("Enter your password: ");
|  |~
|  ||
|  |(2) allocated here
|  |(3) calling ‘agetpass’ from ‘do_work’
|
+--> ‘agetpass’: events 4-5
   |
   |   78 | agetpass(const char *prompt)
   |  | ^~~~
   |  | |
   |  | (4) entry to ‘agetpass’
   |..
   |   84 | if (pass == NULL)
   |  |~
   |  ||
   |  |(5) ‘pass’ leaks here; was allocated at (2)
   |
pass.c:91:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
   91 | if (len == PASS_MAX + 1) {
  |^
  ‘do_work’: events 1-3
|
|   22 | do_work(void)
|  | ^~~
|  | |
|  | (1) entry to ‘do_work’
|..
|   26 | pass = agetpass("Enter your password: ");
|  |~
|  ||
|  |(2) allocated here
|  |(3) calling ‘agetpass’ from ‘do_work’
|
+--> ‘agetpass’: events 4-9
   |
   |   78 | agetpass(const char *prompt)
   |  | ^~~~
   |  | |
   |  | (4) entry to ‘agetpass’
   |..
   |   84 | if (pass == NULL)
   |  |~
   |  ||
   |  |(5) following ‘false’ branch...
   |..
   |   87 | if (readpassphrase(prompt, pass, PASS_MAX + 2, 
R

Re: -Wanalyzer-malloc-leak false positives

[David Malcolm via Gcc]

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, and conditionally prints "validated".  I wrote it
> precisely to demonstrate how [[gnu::malloc(deallocator)]] can be used
> to
> ensure that passwords are not leaked in memory, but I found out that
> it
> fails to detect some conditions.
> 
> Here's the program (it uses agetpass(), as defined in the shadow
> project):
> 
> $ cat pass.c 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 

[...snip...]

I very briefly tried to reproduce this myself, but I suspect we've got
different headers.

> 
> 
> Maybe I'm missing something, but I don't think falanyzer is correct
> here.

Quite possibly.

> Should I report this in bugzilla?

Yes please.  Please can you attach the preprocessed source [1] to the
bug report(s) so that we're looking at the same code.  Ideally also a
link to godbolt.org showing the issue.

Thanks
Dave

[1] you can get this via -E

Re: -Wanalyzer-malloc-leak false positives

[Alejandro Colomar via Gcc]

Hi David,

On 3/29/23 15:32, David Malcolm wrote:
>> $ cat pass.c 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
> 
> [...snip...]
> 
> I very briefly tried to reproduce this myself, but I suspect we've got
> different headers.

I'm on Debian Sid with libbsd-dev 0.11.7-4, and libc-dev 2.36-8.
Maybe that tells you something?

> 
>>
>>
>> Maybe I'm missing something, but I don't think falanyzer is correct
>> here.
> 
> Quite possibly.
> 
>> Should I report this in bugzilla?
> 
> Yes please.

Will do.

>  Please can you attach the preprocessed source [1] to the
> bug report(s) so that we're looking at the same code.

Sure; it's attached to this mail.  Produced with:

$ cc -Wall -Wextra pass.c $(pkgconf --cflags --libs libbsd-overlay) -fanalyzer 
-O3 -E > pass.c.i

 > Ideally also a
> link to godbolt.org showing the issue.

I'm not very used to godbolt, sorry.  If this email isn't enough for you,
I'll try godbolt.

> 
> Thanks
> Dave

Cheers,
Alex

> 
> [1] you can get this via -E
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5# 0 "pass.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "pass.c"
# 1 "/usr/include/bsd/err.h" 1 3 4
# 29 "/usr/include/bsd/err.h" 3 4
# 1 "/usr/include/bsd/sys/cdefs.h" 1 3 4
# 47 "/usr/include/bsd/sys/cdefs.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 1 3 4
# 24 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 392 "/usr/include/features.h" 3 4
# 1 "/usr/include/features-time64.h" 1 3 4
# 20 "/usr/include/features-time64.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 21 "/usr/include/features-time64.h" 2 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/timesize.h" 1 3 4
# 19 "/usr/include/x86_64-linux-gnu/bits/timesize.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 20 "/usr/include/x86_64-linux-gnu/bits/timesize.h" 2 3 4
# 22 "/usr/include/features-time64.h" 2 3 4
# 393 "/usr/include/features.h" 2 3 4
# 513 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 1 3 4
# 10 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/gnu/stubs-64.h" 1 3 4
# 11 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 2 3 4
# 514 "/usr/include/features.h" 2 3 4
# 25 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 2 3 4
# 559 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 560 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 2 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/long-double.h" 1 3 4
# 561 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 2 3 4
# 48 "/usr/include/bsd/sys/cdefs.h" 2 3 4
# 30 "/usr/include/bsd/err.h" 2 3 4

# 1 "/usr/include/err.h" 1 3 4
# 25 "/usr/include/err.h" 3 4
# 1 "/usr/lib/gcc/x86_64-linux-gnu/12/include/stdarg.h" 1 3 4
# 40 "/usr/lib/gcc/x86_64-linux-gnu/12/include/stdarg.h" 3 4

# 40 "/usr/lib/gcc/x86_64-linux-gnu/12/include/stdarg.h" 3 4
typedef __builtin_va_list __gnuc_va_list;
# 26 "/usr/include/err.h" 2 3 4








extern void warn (const char *__format, ...)
 __attribute__ ((__format__ (__printf__, 1, 2)));
extern void vwarn (const char *__format, __gnuc_va_list)
 __attribute__ ((__format__ (__printf__, 1, 0)));


extern void warnx (const char *__format, ...)
 __attribute__ ((__format__ (__printf__, 1, 2)));
extern void vwarnx (const char *__format, __gnuc_va_list)
 __attribute__ ((__format__ (__printf__, 1, 0)));


extern void err (int __status, const char *__format, ...)
 __attribute__ ((__noreturn__, __format__ (__printf__, 2, 3)));
extern void verr (int __status, const char *__format, __gnuc_va_list)
 __attribute__ ((__noreturn__, __format__ (__printf__, 2, 0)));
extern void errx (int __status, const char *__format, ...)
 __attribute__ ((__noreturn__, __format__ (__printf__, 2, 3)));
extern void verrx (int __status, const char *, __gnuc_va_list)
 __attribute__ ((__noreturn__, __format__ (__printf__, 2, 0)));

# 1 "/usr/include/x86_64-linux-gnu/bits/floatn.h" 1 3 4
# 120 "/usr/include/x86_64-linux-gnu/bits/floatn.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/floatn-common.h" 1 3 4
# 24 "/usr/include/x86_64-linux-gnu/bits/floatn-common.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/long-double.h" 1 3 4
# 25 "/usr/include/x86_64-linux-gnu/bits/floatn-common.h" 2 3 4
# 121 "/usr/include/x86_64-linux-gnu/bits/floatn.h" 2 3 4
# 56 "/usr/include/err.h" 2 3 4





# 32 "/usr/include/bsd/err.h" 2 3 4
# 47 "/usr/include/bsd/err.h" 3 4
# 1 "/usr/lib/gcc/x86_64-linux-gnu/12/include/stdarg.h" 1 3 4
# 99 "/usr/lib/gcc/x86_64-linux-gnu/12/include/stdarg.h" 3 4
typedef __gnuc_va_list va_list;
# 48 "/usr/include/bsd/err.h" 2 3 4


void vwarnc(int code, const char *format, va_list ap)
 __attribute((__format__(__printf__, (2), (0;
void warnc(int code, const char *format, ...)
 __attribute((__format__(__printf__, (2), (3;

void verrc(int status, int 

Re: -Wanalyzer-malloc-leak false positives

[Alejandro Colomar via Gcc]

On 3/29/23 15:41, Alejandro Colomar wrote:
>>> Should I report this in bugzilla?
>> Yes please.
> Will do.
> 
>>  Please can you attach the preprocessed source [1] to the
>> bug report(s) so that we're looking at the same code.

Reported:


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: GSoC 2023

[Martin Jambor]

Hello,

we are delighted you found contributing to GCC interesting.

On Mon, Mar 27 2023, Igor Putovny via Gcc wrote:
> Dear all,
>
> I am a student of computer science and I was thinking about applying for
> Google Summer of Code 2023. Naturally, I wanted to reach out to you before
> applying for GCC projects.

Please look again at the "Before you apply" section of the idea page
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC and then have it generate dumps
and step through some function during compilation.

>
> From selected topics you are interested in, several grabbed my attention:
> 1. Bypass assembler when generating LTO object file

See https://gcc.gnu.org/pipermail/gcc/2023-March/240833.html

> 2. Extend the static analysis pass

This is an area, rather than a specific project.  I'd suggest you look
trough recent archives of the gcc mailing list too, as many projects in
that area have been discussed there recently.

> 3. Rust Front-End: HIR Dump
> 4. Rust Front-End: Improving user errors

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to them there as well.

>
> I have to admit that I feel a bit intimidated by projects of "hard
> difficulty", because I have seen how hard it is to find your way in a large
> codebase (which GCC definitely is).

I definitely agree that GCC source can be hard to go through, especially
for newcomers but often even for seasoned contributors when they look at
a part they are not familiar with.  But when you manage to manage to
overcome the difficulty, the project can be very rewarding.  And so not
hesitate to ask us any specific question you may have here on the
mailing list or on IRC.

>
> Therefore, I would like to ask you for your opinion about these topics and
> the level of theoretical/practical experience with compilers you are
> expecting.

The topics were selected because they are good in various ways and the
necessary level of experience is also broadly described on our wiki
page.  You need to be good at C/C++ and have to be willing (and able) to
navigate the big-code base.  Figuring it out is work, but doable.

>
> As for the languages used, I have advanced knowledge of C and intermediate
> knowledge of C++.

That should be good enough.  I think.  But you need to do some research
of the code related to the topics yourself and you should fairly quickly
realize whether your C/C++ skills are sufficient.

Good luck!

Martin

Re: GSoC Rust : Metadata exports for Rust frontend

[Martin Jambor]

Hello,

we are delighted you found contributing to GCC interesting.

On Mon, Mar 27 2023, Omkar Mohanty via Gcc wrote:
> Hello GCC developers,
>
> I am Omkar Mohanty, currently an undergrad in CS. I have contributed to a
> number of open Source organizations for the past one year and I have one
> year experience programming in both Rust and C++. I have attached my
> proposal for GSoC 2023, I hope it  meets the standards of GCC.
>
> link :
> https://docs.google.com/document/d/1CC6OdB3U1TK4e9enFbvjr4XCy2X0Ys_M22NnE5oy5Nc/edit?usp=sharing
>

I can see that you have already discussed the project on the gcc-rust
zulip, which for Rust projects is probably the better place.  But thanks
for letting us know here as well and do not hesitate to ask here too if
you have any specific question about GCC in general.

Good luck,

Martin

Re: GSoC Project - Bypass Assembler for LTO Object Files

[Martin Jambor]

Hello,

we are delighted you found contributing to GCC interesting.

On Tue, Mar 28 2023, Hathik H via Gcc wrote:
> Dear Jan Hubicka,
>
> My name is Hathik , and I'm a student . I'm writing to express my interest
> in the GCC LTO , and to ask for your guidance as I prepare my application.
>
> I have some experience in C/C++ programming and a strong interest in
> low-level systems programming, and I believe that this project aligns well
> with my interests and skills. I'm excited about the opportunity to work on
> this project and contribute to the GCC community.

This project has already been discussed on the mailing list, see for
example https://gcc.gnu.org/pipermail/gcc/2023-March/240833.html

While a few people have expressed interest in the project, I don't think
we have seen a developed proposal yet, so don't let the fact that we
discussed it with others discourage you.

>
> I would be grateful if you could provide me with some guidance, and any
> suggestions or resources that you think would be helpful for me to review.
> Additionally, if you have any specific requirements or preferences for the
> project, please let me know.

The specific understanding of the project is understanding the ELF file
format (mach/coff can come later).  The general ones, i.e. good command
of C/C++, ability to navigate large source-code and understanding of
basic compiling concepts such as Intermediate Representation (IR), often
also called Intermediate Language (IL).

Please look again at the "Before you apply" section of the idea page
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC and then have it generate dumps,
LTO object files, and step through some function during compilation.

>
> I actually have a strong interest in low levels of the systems.I Am eager
> to work with you.I want to learn something from this project.I kindly
> request you to teach me something.
>
> Thank you for your time and consideration, and I look forward to hearing
> from you.
>

We'll be happy to help you further with any specific GCC development
issues you may encounter after reading through and trying the above.

Good luck!

Martin Jambor

Re: Open source contribution for Rust Front-End (GSoC)

[Martin Jambor]

Hello,

we are delighted you found contributing to GCC interesting.

On Wed, Mar 29 2023, Deepanshu Joshi via Gcc wrote:
> Hello,
> Myself Deepanshu Joshi, pursuing Bachelors in Computer Science. I would
> like to display my interest towards the Rust Front End project. Currently I
> am working on my own compiler and hence contributing to this project will
> help me expand my knowledge.
>

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to them there as well.

> I would request you to brief me regarding the resources and the tech stack
> required for this project.

There are those listed in the "Before you apply" section of the idea
page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and
additionally you probably need to know a thing or two about Rust as well.

Good luck!

Martin Jambor

Re: Clarification on newlib version for building AMDGCN offloading backend

[Wileam Yonatan Phan via Gcc]

Hi Andrew,

I just built GCC 12.2.0 with AMDGCN offloading successfully with Spack!
However, when I tried to test it with an OpenACC test code that I have, I 
encountered the following error message:

wyp@basecamp:~/work/testcodes/f90-acc-ddot$ gfortran -fopenacc 
-foffload=amdgcn-unknown-amdhsa="-march=gfx900" ddot.f90 
as: unrecognized option '-triple=amdgcn--amdhsa'
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-amdgcn-unknown-amdhsa-gcc 
returned 1 exit status
compilation terminated.
lto-wrapper: fatal error: 
/home/wyp/work/spack/opt/spack/linux-ubuntu20.04-zen2/gcc-12.2.0/gcc-12.2.0-w7lclfarefmge3uegn2a5vw37bnwhwto/libexec/gcc/x86_64-pc-linux-gnu/12.2.0//accel/amdgcn-unknown-amdhsa/mkoffload
 returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

For reference, the target options that are recognized by llvm-mc are the 
following:

yp@basecamp:~/work/spack/opt/spack/linux-ubuntu20.04-zen2/gcc-12.2.0/llvm-13.0.1-6zvbqlbev3wiqihvz2god7pzcptnoxu3/bin$
 llvm-mc -version
LLVM (http://llvm.org/):
  LLVM version 13.0.1
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver2

  Registered Targets:
amdgcn - AMD GCN GPUs
r600   - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

Please advise,
Wil

From: Wileam Yonatan Phan 
Sent: Tuesday, March 7, 2023 13:42
To: Andrew Stubbs ; gcc@gcc.gnu.org 
Subject: Re: Clarification on newlib version for building AMDGCN offloading 
backend 
 
Hi Andrew,

Thanks! I've created the first draft as a GitHub PR here:


I think it still needs some work on the part where it builds LLVM utilities 
with CMake.
As much as I want supporting only the newest GCC version, Spack currently 
supports building all stable versions of GCC from the tarballs, as well as 
latest develop branch, so I've enabled all versions >= 10.

Thanks,
Wil

From: Andrew Stubbs 
Sent: Tuesday, March 7, 2023 10:38
To: Wileam Yonatan Phan ; gcc@gcc.gnu.org 

Subject: Re: Clarification on newlib version for building AMDGCN offloading 
backend 
 
On 06/03/2023 19:23, Wileam Yonatan Phan via Gcc wrote:
> Hi,
> 
> I'm working on adding a build recipe for GCC with AMDGCN offloading backend 
> in Spack. Can anyone clarify the following sentence listed on the wiki?
> 
>> The Newlib version needs to be contemporaeous with GCC, at least until the 
>> ABI is finalized.
> 
> 
> What are the correct contemporaneous versions for each version of GCC >= 10?

Just match the dates and you'll probably be fine. We've mostly 
synchronised the ABI changes across the GCC mainline and the development 
branch precisely because the Newlib dependency is shared.

Right now the required version of Newlib is 4.3.0.20230120. Prior to the 
ABI change a month or so ago you would have to use a Newlib snapshot.

I wouldn't recommend spending very much of your valuable time on 
enabling old versions of these toolchains.

Andrew

RE: FYI - International Microwave Symposium 2023

[Sasha Grace]

Hi,

Can I share Counts & Cost for review?

Regards,
Sasha

From: Sasha Grace
Sent: 23 March 2023 12:59 PM
To: 'gcc@gcc.gnu.org' 
Subject: RE: FYI - International Microwave Symposium 2023



Hi,

Any update on my previous email?

If YES, please reply back as "Send Counts and Pricing".

Regards
Sasha

From: Sasha Grace
Sent: 20 March 2023 07:39 PM
To: gcc@gcc.gnu.org
Subject: FYI - International Microwave Symposium 2023

Hello

Are you interested in purchasing International Microwave Symposium 2023 Updated 
Database

Attendees:
Design Engineering, Executive/Senior Management, Student, Professor / 
Research-Academic, Marketing/Sales, Research & Development-Industry, 
Engineering Management, Application Engineer, Executive/Senior Technology 
Development, Research & Development-Government, Engineering Services, Other...

Record in the list contains: Contact Name, Job Title, Company/Business Name, 
Complete Mailing Address, email, Telephone/Fax Number, Website/URL, Revenue, 
Employee Size, SIC Code, Industry.

If you are interested to purchase reply back as "Send Counts and Pricing".

Regards,
Sasha

Re: GSoC Separate Host Process Offloading

[Thomas Schwinge]

Hi Adi!

On 2023-03-28T20:39:04+, "Prasad, Adi via Gcc"  wrote:
> I’m Adi Prasad, a 2nd year Computing student at Imperial College London, 
> interested in doing the Separate Host Process Offloading GSoC project this 
> summer.

Greak, and welcome to GCC!  :-)

> First off, I’m aware I’m getting in touch very late; I have been busy up 
> until now with a university project deadline. I am however determined to work 
> as hard as I need to this week to catch up for my late start; I hope you are 
> still willing to consider me.

No worries, you're to too late; no decisions have been made, yet.

> I was wondering if the devs had any recommendations for starter issues to 
> work on (or simpler tasks like tests and documentation) that would help me 
> familiarise myself with the relevant code?

Building GCC and producing test results would be one obvious first task.
 and
 have
some pointers to get started.  If you have specific questions, we're
happy to help, of course.

Then, get familiar with the basic concepts of code offloading in GCC.
 is the best (only?) we have,
unfortunately, and it's somewhat out of date, so beware, sorry.  Looking
at existing libgomp plugins may help: 'libgomp/plugin/plugin-*.c' (The
'GOMP_OFFLOAD_[...]' functions implement the offloading plugin API), and
actually also the very simple 'libgomp/oacc-host.c'.  That's essentially
the API you need to care about (for OpenACC; but OpenMP 'target' also
won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

> Thank you for reading this, and I will stay in touch as I develop my proposal!

Yes, please do.  In particular, think about a timeline for your proposal.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

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

[Benjamin Priour via Gcc]

Hi David,

I've been playing around with sm-malloc on C++ samples.
I've noticed double delete don't go under -Wanalyzer-double-free but within
-Wanalyzer-use-after-free scope.

With the reproducer ...
> struct A {};
>
> int main() {
> A* a = new A();
> delete a;
> delete a;
> return 0;
> }

... the analyzer diagnoses:
build/gcc/xg++ -Bbuild/gcc -S -fanalyzer
-Wanalyzer-mismatching-deallocation -Wanalyzer-use-after-free
-Wanalyzer-double-free -Wanalyzer-malloc-leak  double_delete_test.cpp
double_delete_test.cpp: In function ‘int main()’:
double_delete_test.cpp:7:1: warning: use after ‘delete’ of ‘a’ [CWE-416]
[-Wanalyzer-use-after-free]
7 | }
  | ^
  ‘int main()’: events 1-8
|
|3 | A* a = new A();
|  |  ^
|  |  |
|  |  (1) allocated here
|  |  (2) assuming ‘operator new(8)’ is non-NULL
|4 | delete a;
|  | 
|  | |  |
|  | |  (4) ...to here
|  | |  (5) deleted here
|  | (3) following ‘true’ branch...
|5 | delete a;
|  | 
|  | |  |
|  | |  (7) ...to here
|  | (6) following ‘true’ branch...
|6 | return 0;
|7 | }
|  | ~
|  | |
|  | (8) use after ‘delete’ of ‘a’; deleted at (5)
|
double_delete_test.cpp:3:18: warning: dereference of possibly-NULL
‘operator new(8)’ [CWE-690] [-Wanalyzer-possible-null-dereference]
3 | A* a = new A();
  |  ^
  ‘int main()’: events 1-2
|
|3 | A* a = new A();
|  |  ^
|  |  |
|  |  (1) this call could return NULL
|  |  (2) ‘operator new(8)’ could be NULL:
unchecked value from (1)
|


Debugging read out two things:
- During second call of 'on_deallocator_call' on delete, the state would be
'stop' instead of the expected 'freed'
- The call to set_next_state transitions malloc instead of delete from
'nonnull' to 'freed'.
I'm still trying to come up with why these two behaviors happens.

By the way, in the first call to 'on_deallocator_call' on delete, the state
is set to 'nonnull',
which conforms to C++ behavior for new. However, a
-Wanalyzer-possible-null-dereference is emitted at the expression 'new'.
I haven't yet figured out why, but I'm looking into it.


Another observation was in the distinction between delete and free in the
case of mixing them.
With 'a' being allocated with malloc:
> A* a = (A*) malloc(sizeof(A));
> free(a);
> delete a; // -Wanalyzer-use-after-free, OK, might expect warning for
double free though ?

but with allocation through new and inversion of free/delete
> A* a = new A();
> delete a;
> free(a); // No diagnostics at all from the analyzer, got
-Wmismatched-new-delete from the front-end though.

I believe this might come from a similar issue as above, but I still have
to investigate on that front.

I just noticed another unexpected behavior. Let's consider
> struct A {int x; int y;};
> void* foo() { A* a = (A*) __builtin_malloc(sizeof(A)); return a; }
> int main() {
> A* a2 = (A*) __builtin_malloc(sizeof(A));
> foo();
> return 0;
> }

Then a -Wanalyzer-malloc-leak is correctly ensued for allocation in foo(),
but none is emitted for the leak in main(), although I checked the exploded
graph it is correctly marked as unchecked(free).

Should I file those on bugzilla ?


Also I have taken interest in PR106388 - Support for use-after-move in
-fanalyzer -.
The prerequisite PR106386 - Reuse libstdc++ assertions - would also be of
great help in extending the support of -Wanalyzer-out-of-bounds,
as we could detect out-of-bounds on vectors through
__glibcxx_requires_subscript used in the definition of operator[].

I already thought about a few ideas to implement that, but I'll develop
them more and try to come up with some proof of concept before sending them
to you.
Hopefully by tomorrow I'll update on this, I'll preferably hop to bed now
haha.
Do you think this could make a suitable GSoC subject ?


Best,
Benjamin.

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

[David Malcolm via Gcc]

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 14.

Other notes inline below...

> I've noticed double delete don't go under -Wanalyzer-double-free but
> within
> -Wanalyzer-use-after-free scope.
> 
> With the reproducer ...
> > struct A {};
> > 
> > int main() {
> >     A* a = new A();
> >     delete a;
> >     delete a;
> >     return 0;
> > }
> 
> ... the analyzer diagnoses:
> build/gcc/xg++ -Bbuild/gcc -S -fanalyzer
> -Wanalyzer-mismatching-deallocation -Wanalyzer-use-after-free
> -Wanalyzer-double-free -Wanalyzer-malloc-leak  double_delete_test.cpp
> double_delete_test.cpp: In function ‘int main()’:
> double_delete_test.cpp:7:1: warning: use after ‘delete’ of ‘a’ [CWE-
> 416]
> [-Wanalyzer-use-after-free]
>     7 | }
>   | ^
>   ‘int main()’: events 1-8
>     |
>     |    3 | A* a = new A();
>     |  |  ^
>     |  |  |
>     |  |  (1) allocated here
>     |  |  (2) assuming ‘operator new(8)’ is non-
> NULL
>     |    4 | delete a;
>     |  | 
>     |  | |  |
>     |  | |  (4) ...to here
>     |  | |  (5) deleted here
>     |  | (3) following ‘true’ branch...
>     |    5 | delete a;
>     |  | 
>     |  | |  |
>     |  | |  (7) ...to here
>     |  | (6) following ‘true’ branch...
>     |    6 | return 0;
>     |    7 | }
>     |  | ~
>     |  | |
>     |  | (8) use after ‘delete’ of ‘a’; deleted at (5)
>     |
> double_delete_test.cpp:3:18: warning: dereference of possibly-NULL
> ‘operator new(8)’ [CWE-690] [-Wanalyzer-possible-null-dereference]
>     3 | A* a = new A();
>   |  ^
>   ‘int main()’: events 1-2
>     |
>     |    3 | A* a = new A();
>     |  |  ^
>     |  |  |
>     |  |  (1) this call could return NULL
>     |  |  (2) ‘operator new(8)’ could be NULL:
> unchecked value from (1)
>     |
> 
> 
> Debugging read out two things:
> - During second call of 'on_deallocator_call' on delete, the state
> would be
> 'stop' instead of the expected 'freed'
> - The call to set_next_state transitions malloc instead of delete
> from
> 'nonnull' to 'freed'.
> I'm still trying to come up with why these two behaviors happens.
> 
> By the way, in the first call to 'on_deallocator_call' on delete, the
> state
> is set to 'nonnull',
> which conforms to C++ behavior for new. However, a
> -Wanalyzer-possible-null-dereference is emitted at the expression
> 'new'.
> I haven't yet figured out why, but I'm looking into it.

I'm guessing that the CFG and thus the supergraph contains edges for
handling exceptions, and the analyzer currently doesn't know anything
about these, and mishandled them:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111

You might want to have a look at the supergraph (via -fdump-analyzer-
supergraph); I recently added more debugging notes here:
 https://gcc.gnu.org/onlinedocs/gccint/Debugging-the-Analyzer.html

If that's the case, then -fno-exceptions might affect the behavior.

> 
> 
> Another observation was in the distinction between delete and free in
> the
> case of mixing them.
> With 'a' being allocated with malloc:
> > A* a = (A*) malloc(sizeof(A));
> > free(a);
> > delete a; // -Wanalyzer-use-after-free, OK, might expect warning
> > for
> double free though ?
> 
> but with allocation through new and inversion of free/delete
> > A* a = new A();
> > delete a;
> > free(a); // No diagnostics at all from the analyzer, got
> -Wmismatched-new-delete from the front-end though.
> 
> I believe this might come from a similar issue as above, but I still
> have
> to investigate on that front.
> 
> I just noticed another unexpected behavior. Let's consider
> > struct A {int x; int y;};
> > void* foo() { A* a = (A*) __builtin_malloc(sizeof(A)); return a; }
> > int main() {
> >     A* a2 = (A*) __builtin_malloc(sizeof(A));
> >     foo();
> >     return 0;
> > }
> 
> Then a -Wanalyzer-malloc-leak is correctly ensued for allocation in
> foo(),
> but none is emitted for the leak in main(), although I checked the
> exploded
> graph it is correctly marked as unchecked(free).
> 
> Should I file those on bugzilla ?

We already know that "C++ doesn't work yet".  Minimal examples of
problems with C++ support might be worth filing, to isolate specific
issues.  If you do, please add them to the tracker bug (by adding
"analyzer-c++" to the "Blocks" field of the new bug(s))

> 
> 
> Also I have taken interest in PR106388 - Support for use-after-move
> in
> -fanalyzer -.
> The prerequisite PR106386 - Reuse libstdc++ assertions - would also
>

Re: [GSoC] Conflicted Built-in Trait Name

[François Dumont via Gcc]

Hi

Do not hesitate to dig into library doc. Especially this page:

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html

You can also find it in your git clone in /libstdc++-v3/doc/html.

You'll see also how to run test in different std modes like --std=c++98 
to catch the kind of issue reported by Jonathan.


Regarding your patches I wonder if it's not too splitted. 1 patch per 
builtin would sound more logical, at least for an easy one like __is_void.


François


On 29/03/2023 01:33, Ken Matsui wrote:

Oooh, thank you for your help!

On Tue, Mar 28, 2023 at 4:25 PM Jonathan Wakely  wrote:

On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++
 wrote:

Hi François,

I tried to use `make check-debug`, but my Makefile does not include
the target. Could you please tell me how you generated your Makefile?

It's a target in the libstdc++ makefile, so you need to run it from
the $target/libstdc++-v3 directory.