date:20230320

RISC-V V C Intrinsic API v1.0 release meeting reminder (March 20th, 2023)

2023-03-20 Thread Eop Chen via Gcc

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held later on 2023/03/20 6AM (GMT -7) / 11PM (GMT +8).

The agenda can be found in the second page of the meeting slides (link 
).
Please join the calendar to be constantly notified - Google calender link 
,
 ICal 

We also have a mailing list now hosted by RISC-V International (link 
).

I was busy in SiFive-related work for the past month, so the implementation of 
tuple-types is not done
as we expected for our planning until 03/20. We might not have much to discuss 
for today but I will
hold the meeting for discussion of planning. Any other topics related to RVV 
intrinsics are welcomed.

Regards,

eop Chen

Re: [GSoC] gccrs Unicode support

2023-03-20 Thread Raiki Tamura via Gcc

2023年3月18日(土) 18:28 Jakub Jelinek :

> That is a pretty simple thing, so no need to use an extra library for that.
> As is documented in contrib/unicode/README, the Unicode *.txt files are
> already checked in and there are several generators of tables.
> libcpp/makeucnid.cc already creates tables based on the
> UnicodeData.txt DerivedNormalizationProps.txt DerivedCoreProperties.txt
> files, including NFC/NKFC, it is true it doesn't currently compute
> whether a character is alphanumeric.  That is either Alphabetic
> DerivedCoreProperties.txt property, or for numeric Nd, Nl or No category
> (3rd column) in UnicodeData.txt.  Should be a few lines to add that support
> to libcpp/makeucnid.cc, the only question is if it won't make the ucnranges
> array much larger if it differentiates based on another ALPHANUM flag.
> If it doesn't grow too much, let's put it there, if it would grow too much,
> perhaps we should emit it in a separate table.
>

Sounds good. I have got a concrete idea of implementation.
Thank you everyone for giving your advice.

Sincerely yours,
Raiki Tamura

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

2023-03-20 Thread Alejandro Colomar via Gcc

Hi Bastien and Eric!

On 3/18/23 08:54, roucaries bastien wrote:
> Hi,
> 
> I have opened a defect at austin group
> https://www.austingroupbugs.net/view.php?id=1641

Sorry for not having prepared yet my report as I promised to Eric.
I've been busy with other stuff, but still had in mind doing it :).
But yes, basically that report is what I would have written, so you
have my +1.  ;)

Cheers,

Alex

> 
> Bastien
> 
> Le lun. 6 févr. 2023 à 18:45, Eric Blake  a écrit :
>>
>> On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
>>
>> Regardless of the merits of the patch, let's not introduce typos:
>>
>>> +++ b/man3type/sockaddr.3type
>>> @@ -120,6 +120,26 @@ .SH NOTES
>>>  .I 
>>>  and
>>>  .IR  .
>>> +.SH BUGS
>>> +.I sockaddr_storage
>>> +was designed back when strict aliasing wasn't a problem.
>>> +Back then,
>>> +one would define a variable of that type,
>>> +and then access it as any of the other
>>> +.IR sockaddr_ *
>>> +types,
>>> +depending on the value of the first member.
>>> +This is Undefined Behavior.
>>> +However, there is no way to use these APIs without invoking Unedfined 
>>> Behavior,
>>
>> Undefined
>>
>>> +either in the user program or in libc,
>>> +so it is still recommended to use this method.
>>> +The only correct way to use different types in an API is through a union.
>>> +However,
>>> +that union must be implemented in the library,
>>> +since the type must be shared between the library and user code,
>>> +so libc should be fixed by implementing
>>> +.I sockaddr_storage
>>> +as a union.
>>>  .SH SEE ALSO
>>>  .BR accept (2),
>>>  .BR bind (2),
>>
>> Also, while I could raise the issue with the Austin Group on your
>> behalf to get the POSIX wording improved, I think it would work better
>> if you initiate a bug report rather than having me do it:
>>
>> https://www.austingroupbugs.net/main_page.php
>>
>> --
>> Eric Blake, Principal Software Engineer
>> Red Hat, Inc.   +1-919-301-3266
>> Virtualization:  qemu.org | libvirt.org
>>

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

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

2023-03-20 Thread Pierrick Philippe


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(void) {
3|    void * ptr = malloc(sizeof(int));
4|    for (int i = 0; i < 10; i++) {
5|    if (i == 5) free(ptr);
6|    }
7|}
'''

And here, the malloc-sm is reporting a double-free on line 5 with a 
quite confusing output:


'''
./test.c: In function ‘main’:
./test.c:5:21: warning: double-‘free’ of ‘ptr’ [CWE-415] 
[-Wanalyzer-double-free]

    5 | if (i == 5) free(ptr);
   | ^
  ‘main’: events 1-13
    |
    |   3 | void * ptr = malloc(sizeof(int));
    |  |    ^~~
    |  |    |
    |  |    (1) allocated here
    |   4 | for (int i = 0; i < 10; i++) {
    |  |   ~~~
    |  | |    |
    |  | |    (5) ...to here
    |  | (2) following ‘true’ branch (when 
‘i <= 9’)...
    |  | (6) following ‘true’ branch (when 
‘i <= 9’)...
    |  | (9) following ‘true’ branch (when 
‘i <= 9’)...

    |   5 | if (i == 5) free(ptr);
    |  |    ~       ~
    |  |    | |
    |  |    | (8) first ‘free’ here
    |  |    |         (12) ...to here
    |  |    | (13) second ‘free’ here; first 
‘free’ was at (8)

    |  |    (3) ...to here
    |  |    (4) following ‘false’ branch (when ‘i != 5’)...
    |  |    (7) ...to here
    |  |    (10) ...to here
    |  |    (11) following ‘true’ branch (when ‘i == 5’)...
    |
'''

So, I'm guessing that this false positive is due to how the analyzer is 
handling loops.

Which lead to my question: how are loops handled by the analyzer?

Thanks for your time,

Pierrick

Re: Gcc Digest, Vol 37, Issue 8

2023-03-20 Thread Rishi Raj via Gcc

Thanks, David and Martin, for the heads up, and I am sorry for the late
reply due to health issues. Anyways I could emit the warning "hello world,
I am function foo.".  After that, I tried debugging using the` ../gcc
-wrapper gdb test.c`(gcc binary is in parent folder) but I am getting this
error "gdb: unrecognized option '-dumpdir'
Use `gdb --help' for a complete list of options.". I googled it and got
this on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195), but
it has already been fixed. These are the gdb configurations during the
build:
Using built-in specs.
COLLECT_GCC=../gcc
COLLECT_LTO_WRAPPER=gcc-dir/libexec/gcc/x86_64-pc-linux-gnu/12.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../project/configure --prefix=gcc-dir
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.1 20230302 [OG12] (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
Can anyone point out how to resolve this or if I am missing something
during build?
Thanks and regards
Rishi Raj


On Tue, 7 Mar 2023 at 17:30,  wrote:

> Send Gcc mailing list submissions to
> gcc@gcc.gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://gcc.gnu.org/mailman/listinfo/gcc
> or, via email, send a message with subject or body 'help' to
> gcc-requ...@gcc.gnu.org
>
> You can reach the person managing the list at
> gcc-ow...@gcc.gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gcc digest..."
> Today's Topics:
>
>1. Re: [GSOC] Looking for small patch/project to work on
>   (David Malcolm)
>2. Re: Request for participation in GSoC (David Malcolm)
>3. Re: [GSoC] Introduction and query on LTO object emmission
>   project (David Malcolm)
>4. Clarification on newlib version for building AMDGCN
>   offloading backend (Wileam Yonatan Phan)
>
>
>
> -- Forwarded message --
> From: David Malcolm 
> To: Rishi Raj , gcc@gcc.gnu.org
> Cc:
> Bcc:
> Date: Mon, 06 Mar 2023 11:25:16 -0500
> Subject: Re: [GSOC] Looking for small patch/project to work on
> 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's GSOC with GCC.
> >
> > My progress so far:
> >
> >1. Successfully built the GCC from source using the installing gcc
> >guide. (I will run the test suite today.)
> >2. Read about different configuration options during installations
> > and
> >also went through the gcc-newbies-guide, which was an exciting
> > read and
> >provided an overview of how to proceed in gcc-contribution. I want
> > to
> >extend my appreciation to David for this.
>
> Thanks.  You've already built GCC from source, which is a great start.
> A good thing to try next (if you haven't already) would be to try
> hacking in a warning that emits:
>   "hello world, I'm compiling function 'foo'"
> for each function being compiled, and compile something with that...
> and then do it again in the debugger, with a breakpoint on that, and
> step through some of the code, as per:
>
> https://gcc-newbies-guide.readthedocs.io/en/latest/getting-started.html#hello-world-from-the-compiler
>
> The point here is to get you and your development environment to the
> point where you can comfortably make a simple change to GCC's source,
> rebuild it and quickly see the results of your edits (without having to
> wait ages), and for you to get comfortable stepping through it in the
> debugger.
>
> Let me know if you run into issues (which could suggest improvements to
> the guide).
>
> >
> > After reading about the suggested projects described on GCC's GSOC
> > page, I
> > found "Bypass assembler when generating LTO object files" and "C++:
> > Implement compiler built-in traits for the standard library traits"
> > interesting. Currently, I am examining the preliminary patch
> > https://gcc.gnu.org/ml/gcc/2014-09/msg00340.html for the first
> > project.
>
> FWIW I'm not particularly expert at the specific areas of GCC relating
> to the two projects you mentioned, so hopefully others on this list can
> give advice/mentoring with those.
>
> > I
> > can work on a small project/patch after this in a day or two. I would
> > greatly appreciate your suggestions for the same.
>
> I'm biased here in favor of my own subproject, the static analyzer; as
> discussed in the recent "[GSoC][Static Analyzer] Ideas for proposal"
> thread on this list there are dozens of RFEs against the "analyzer"
> component in our bugzilla, many of which are relatively small.  That
> said analyzer is quite complicated, so I don't know if that's a good
> first warm-up for someone who isn't

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

2023-03-20 Thread Rishi Raj via Gcc

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 to health issues. Anyways I could emit the warning "hello world,
I am function foo.".  After that, I tried debugging using the` ../gcc
-wrapper gdb test.c`(gcc binary is in parent folder) but I am getting this
error "gdb: unrecognized option '-dumpdir'
Use `gdb --help' for a complete list of options.". I googled it and got
this on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195), but
it has already been fixed. These are the gdb configurations during the
build:
Using built-in specs.
COLLECT_GCC=../gcc
COLLECT_LTO_WRAPPER=gcc-dir/libexec/gcc/x86_64-pc-linux-gnu/12.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../project/configure --prefix=gcc-dir
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.1 20230302 [OG12] (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
Can anyone point out how to resolve this or if I am missing something
during build?
Thanks and regards
Rishi Raj

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

2023-03-20 Thread Shengyu Huang via Gcc

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 in markdown and then copied pasted to Google 
Docs, so some formatting may look ugly...)

In the timeline section, I mention your name twice where I expect your input 
can help me speed up the work. For example, the mentioned paper 
(https://users.ece.cmu.edu/~aavgerin/papers/Oakland10.pdf) has a section 
“performance” on page 12 that lists out several solutions to mitigate the 
exponential blow up in straightforward implementation of symbolic execution, 
but the current implementation may have some clever tricks already (e.g., 
purging the states?) that some of the solutions may not be applicable to us.

I can further polish this proposal based on your feedback. I may not be as 
responsive as you are because I have several deadlines from coursework every 
week.

>> 1. What should I do with the integration tests?
> 
> First of all, AFAIK I'm the only person who's tried running the
> integration tests.  They're the test scripts I wrote to help me
> validate my own patches, so there will be rough edges; please let me
> know as you run into them, so I can fix/document them.

You append the path “../sarifdump” in results.py, but this path is not in the 
repo. 

>> 2. I ran gcc -fanalyzer -fanalyzer-checker=taint ./gcc-
>> src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools-signed-char.c , but
>> I got different results from what you documented in PR103533:
>> 
>> /usr/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function `_start':
>> (.text+0x17): undefined reference to `main'
>> collect2: error: ld returned 1 exit status
> 
> gcc's default is to try to compile, assemble, and link into an
> executable.  This testcase doesn't have a "main" function, hence the
> linker complains.  If you pass "-S", it will merely compile the .c to a
> .s assembler file whilst still running the analyzer.
> 
> In terms of actually running the test suite via DejaGnu, see:
> https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html
> 
> I typically use:
> 
>  make -k -jN \
>  && time make check-gcc \
> RUNTESTFLAGS="-v -v --target_board=unix\{-m32,-m64\} 
> analyzer-torture.exp=*.c analyzer.exp=*.c"
> 
> when testing the analyzer regression test suite, where N is the number
> of cores on my box
> 
> When I run an individual testcase, I do something like:
> 
> ./xgcc -B. -S -fanalyzer ../../src/PATH_TO_TEST_CASE
> 
> in the "gcc" subdirectory of the build directory.

Yeah sorry for not taking a good look at the testcase before sending you this 
question…the tips were very helpful still, thanks a lot!

Under latest trunk, all the individual testcases documented in PR103533 compile 
with no error (no ICE or state explosion). I double checked that I did turn on 
-fanalyzer-checker=taint (although it is a bit annoying there is no error or 
warning when I mistyped it as -fanalyzer-checker=tai8nt). I also ran the test 
suite via DejaGNU, and there are only four unexpected failures (no unexpected 
successes) and some unsupported tests:

```
FAIL: gcc.dg/analyzer/file-CWE-1341-example.c (test for excess errors) 
FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors) 
FAIL: gcc.dg/analyzer/file-CWE-1341-example.c (test for excess errors) 
FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors)
```

(Why is the same file reported twice in the summary?)

These testcases are not relevant for taint analysis, but indeed when I turned 
on the taint mode other checkers are suppressed without any warnings (I guess 
this should be one of the goals if we don’t manage to turn on the taint mode by 
default in the end).

Does it mean there are no small testcases that will cause state explosion at 
the moment? It is a bit tricky for me to have an intuition for where the 
problem stems when I 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 example 
to fix the next encountered issue?

By the way, I have applied for the compile farm account after the first email 
exchanges and I have been working on compile farm for a while now.


Best,
Shengyu

P.S. There is no more `pr93032-mztools.c` in the testsuit, and the two files 
`pr93032-mztools-{simplified, signed-char, unsigned-char}.c` do not incur state 
explosion.

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

2023-03-20 Thread David Malcolm via Gcc

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 to health issues. Anyways I could emit the warning "hello
> world,
> I am function foo.".  After that, I tried debugging using the` ../gcc
> -wrapper gdb test.c`(gcc binary is in parent folder) but I am getting
> this
> error "gdb: unrecognized option '-dumpdir'
> Use `gdb --help' for a complete list of options.". 

The invocation above should be:

  ../xgcc -B.. -wrapper gdb,--args test.c

in that:
- when building from source, the "driver" binary is normally called
"xgcc" rather than "gcc"
- you're missing "-B PATH_TO_GCC_DIR" so that the "xgcc" driver can
find the cc1 binary
- the wrapper argument is "gdb,--args" so that it adds the option "--
args" to gdb's invocation

Does that fix things?

That said, I normally debug from inside the BUILDDIR/gcc subdirectory,
from which I type:

  ./xgcc -B. ARGS TO GCC   -wrapper gdb,--args


Another way to invoke cc1 under the debugger is to add "-v" to the gcc
invocation to get verbose output, and then see what command-line it
uses to invoke cc1, and then run:

  gdb --args ARGS_OF_CC1_INVOCATION

but I tend to use the former approach.

Hope this is helpful
Dave




> I googled it and got
> this on Bugzilla
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195), but
> it has already been fixed. These are the gdb configurations during
> the
> build:
> Using built-in specs.
> COLLECT_GCC=../gcc
> COLLECT_LTO_WRAPPER=gcc-dir/libexec/gcc/x86_64-pc-linux-
> gnu/12.2.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../project/configure --prefix=gcc-dir
> --enable-languages=c,c++ --disable-bootstrap
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 12.2.1 20230302 [OG12] (GCC)
> COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir'
> 'a-'
> Can anyone point out how to resolve this or if I am missing something
> during build?
> Thanks and regards
> Rishi Raj

[GSOC] query about C++: Implement compiler built-in traits for the standard library traits

2023-03-20 Thread Anastasia3412 via Gcc

Hello Everyone I'm Anastasia. I am a prospective GSOC Student. I wish to know 
if the project C++: Implement compiler built-in traits for the standard library 
traits is still available. I have already build and got my hand dirty on 
debugging GCC. How should I proceed to make a proposal. Also I want to know 
does having theoretical knowledge of compiler knowledge a prerequisite for this 
proposal, if yes I will do a course on compiler design.
Regards
Anastasia Zakharov

[GSoC 2023] Rust front-end: Improving User Errors

2023-03-20 Thread Panagiotis Foliadis via Gcc

Greetings,

My name is Panagiotis Foliadis, Ι'm 26 years old and I am from Athens, Greece.

I'm interesting in the Rust frοnt-end project and especially at Improving user 
errors. I'm a self taught 
software developer with solid knowledge about Rust, and also Ι'm doing my 
internship that mainly uses C. I'm really 
interested in the low level side of programming and especially compilers. I 
have already built gcc from source and 
did some studying on the documentation to acquire some basic knowledge about 
the compiler.

I'd like some guidance from the mentors prior to making a proposal, if there is 
any to give.

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

2023-03-20 Thread David Malcolm via Gcc

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 in markdown and then copied pasted to
> Google Docs, so some formatting may look ugly...)

Thanks.

> 
> In the timeline section, I mention your name twice where I expect
> your input can help me speed up the work. For example, the mentioned
> paper (https://users.ece.cmu.edu/~aavgerin/papers/Oakland10.pdf) has
> a section “performance” on page 12 that lists out several solutions
> to mitigate the exponential blow up in straightforward implementation
> of symbolic execution, but the current implementation may have some
> clever tricks already (e.g., purging the states?) that some of the
> solutions may not be applicable to us.

One note on the timeline: I'm planning to take a vacation from July
1st-16th, and will only have intermittent access to a computer during
that time, but hopefully will at least be able to respond to questions.

> 
> I can further polish this proposal based on your feedback. I may not
> be as responsive as you are because I have several deadlines from
> coursework every week.

I seem to have spent the whole day looking at bugzilla reports, so I
hope to look at your draft properly later in the week.

> 
> > > 1. What should I do with the integration tests?
> > 
> > First of all, AFAIK I'm the only person who's tried running the
> > integration tests.  They're the test scripts I wrote to help me
> > validate my own patches, so there will be rough edges; please let
> > me
> > know as you run into them, so I can fix/document them.
> 
> You append the path “../sarifdump” in results.py, but this path is
> not in the repo. 

Sorry about this; it's this repo:
  https://github.com/davidmalcolm/sarif-dump
which I'm simply checking out to a sister directory for now.

> 
> > > 2. I ran gcc -fanalyzer -fanalyzer-checker=taint ./gcc-
> > > src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools-signed-char.c ,
> > > but
> > > I got different results from what you documented in PR103533:
> > > 
> > > /usr/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function `_start':
> > > (.text+0x17): undefined reference to `main'
> > > collect2: error: ld returned 1 exit status
> > 
> > gcc's default is to try to compile, assemble, and link into an
> > executable.  This testcase doesn't have a "main" function, hence
> > the
> > linker complains.  If you pass "-S", it will merely compile the .c
> > to a
> > .s assembler file whilst still running the analyzer.
> > 
> > In terms of actually running the test suite via DejaGnu, see:
> > https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html
> > 
> > I typically use:
> > 
> >  make -k -jN \
> >  && time make check-gcc \
> >     RUNTESTFLAGS="-v -v --target_board=unix\{-m32,-m64\}
> > analyzer-torture.exp=*.c analyzer.exp=*.c"
> > 
> > when testing the analyzer regression test suite, where N is the
> > number
> > of cores on my box
> > 
> > When I run an individual testcase, I do something like:
> > 
> > ./xgcc -B. -S -fanalyzer ../../src/PATH_TO_TEST_CASE
> > 
> > in the "gcc" subdirectory of the build directory.
> 
> Yeah sorry for not taking a good look at the testcase before sending
> you this question…the tips were very helpful still, thanks a lot!
> 
> Under latest trunk, all the individual testcases documented in
> PR103533 compile with no error (no ICE or state explosion). I double
> checked that I did turn on -fanalyzer-checker=taint (although it is a
> bit annoying there is no error or warning when I mistyped it as -
> fanalyzer-checker=tai8nt). 
> bit annoying there is no error or warning when I mistyped it as -
> fanalyzer-checker=tai8nt). 

Oops, sorry about that; good catch.  I've filed that as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109220



> I also ran the test suite via DejaGNU, and there are only four
> unexpected failures (no unexpected successes) and some unsupported
> tests:
> 
> ```
> FAIL: gcc.dg/analyzer/file-CWE-1341-example.c (test for excess
> errors) 
> FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors) 
> FAIL: gcc.dg/analyzer/file-CWE-1341-example.c (test for excess
> errors) 
> FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors)
> ```
> 
> (Why is the same file reported twice in the summary?)

If you're running with -m32,-m64 as above, it's running all the tests
twice: once for 32-bit, and again for 64-bit x86 targets.

> 
> These testcases are not relevant for taint analysis, but indeed when
> I turned on the taint mode other checkers are suppressed without any
> warnings (I guess this should be one of the goals if we don’t manage
> to turn on the taint mode by default in the end).

Yeah,  -fanalyzer-checker=NAME means "just run state machine NAME".

I've been testing the "run with taint-checkin

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

2023-03-20 Thread David Malcolm via Gcc

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(void) {
> 3|    void * ptr = malloc(sizeof(int));
> 4|    for (int i = 0; i < 10; i++) {
> 5|    if (i == 5) free(ptr);
> 6|    }
> 7|}
> '''
> 
> And here, the malloc-sm is reporting a double-free on line 5 with a 
> quite confusing output:
> 
> '''
> ./test.c: In function ‘main’:
> ./test.c:5:21: warning: double-‘free’ of ‘ptr’ [CWE-415] 
> [-Wanalyzer-double-free]
>  5 | if (i == 5) free(ptr);
>     | ^
>    ‘main’: events 1-13
>  |
>  |   3 | void * ptr = malloc(sizeof(int));
>  |  |    ^~~
>  |  |    |
>  |  |    (1) allocated here
>  |   4 | for (int i = 0; i < 10; i++) {
>  |  |   ~~~
>  |  | |    |
>  |  | |    (5) ...to here
>  |  | (2) following ‘true’ branch
> (when 
> ‘i <= 9’)...
>  |  | (6) following ‘true’ branch
> (when 
> ‘i <= 9’)...
>  |  | (9) following ‘true’ branch
> (when 
> ‘i <= 9’)...
>  |   5 | if (i == 5) free(ptr);
>  |  |    ~       ~
>  |  |    | |
>  |  |    | (8) first ‘free’ here
>  |  |    |         (12) ...to here
>  |  |    | (13) second ‘free’ here; first
> ‘free’ was at (8)
>  |  |    (3) ...to here
>  |  |    (4) following ‘false’ branch (when ‘i !=
> 5’)...
>  |  |    (7) ...to here
>  |  |    (10) ...to here
>  |  |    (11) following ‘true’ branch (when ‘i ==
> 5’)...
>  |
> '''
> 
> So, I'm guessing that this false positive is due to how the analyzer
> is 
> handling loops.
> Which lead to my question: how are loops handled by the analyzer?

Sadly, the answer is currently "not very well" :/

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 values
on successive iterations, the widening_svalue tries to simulate that we
know the start value and the direction the variable is moving in.

This doesn't work well; arguably I should rewrite it, perhaps with an
iterator_svalue, though I'm not sure how it ought to work.  Some ideas:

* reuse gcc's existing SSA-based loop analysis, which I believe can
identify SSA names that are iterator variables, figure out their
bounds, and their per-iteration increments, etc.

* rework the program_point or supergraph code to have a notion of "1st
iteration of loop", "2nd iteration of loop", "subsequent iterations",
or similar, so that the analyzer can explore those cases differently
(on the assumption that such iterations hopefully catch the most
interesting bugs)

Dave

FYI - International Microwave Symposium 2023

2023-03-20 Thread Sasha Grace

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

RISC-V V C Intrinsic API v1.0 release meeting reminder (March 20th, 2023)

Re: [GSoC] gccrs Unicode support

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

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

Re: Gcc Digest, Vol 37, Issue 8

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

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

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

[GSOC] query about C++: Implement compiler built-in traits for the standard library traits

[GSoC 2023] Rust front-end: Improving User Errors

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

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

FYI - International Microwave Symposium 2023

13 matches

Site Navigation

Mail list logo

Footer information