Re: GSoC: Getting started
On Wed, 2022-06-01 at 14:50 -0400, David Malcolm wrote: > On Wed, 2022-06-01 at 23:22 +0530, Mir Immad wrote: > > HI everyone, > > > > I'm Immad Mir -- one of the GSoC students this year. I'll be working > > on > > adding static analysis support for POSIX file description APIs this > > summer. > > Welcome Immad - I'm looking forward to helping you on this project. > > For reference, I think you posted an initial prototype of this work > earlier this year here: > https://gcc.gnu.org/pipermail/gcc/2022-January/238192.html > https://gcc.gnu.org/pipermail/gcc/2022-February/238215.html > > > > > The plan is to let the static analyzer know about the FD APIs through > > the > > use of function attributes, although initially we might hardcode the > > logic > > to get started working. I'm looking for the suggestions on this from > > the > > people who have experience working with file-descriptors. > > We talked about this off-list; I think next steps could be: > > (1) get your initial prototype working again, hardcoding the names of > the functions for simplicity at first > > (2) find a list of system calls (e.g. those implemented on Linux), and > see which ones relate to file descriptors e.g. acquiring them, using > them, releasing them, and duplicating them. Look for patterns of usage > that could be expressed using function attributes. Probably ignore > "ioctl" for now. > > (3) probably talk to glibc's developers about this, since glibc > provides headers that wrap system calls, which would want to use the > attributes if we provide them > > (4) implement the attributes, so that the analyzer doesn't have > hardcoded function names, and can instead rely on function attributes. > GCC's attributes are implemented in gcc/c-family/c-attribs.cc; see the > big c_common_attribute_table array, which associates the string names > of the attrbutes with properties, including a handler callback. These > either set flags of a decl, or the attribute itself is appended to a > singly-linked list on that decl (for those things that don't directly > relate to fields of a decl). > > I believe Siddhesh Poyarekar has been looking at attributes from the > glibc side of things, so I'm CCing him in case he has input on this. > > I'm wondering if other people on this list have ideas for projects that > make heavy use of syscalls/file-descriptors that would benefit from > having this analyzer feature. Maybe systemd? > > Welcome again; hope this makes sense and is helpful > Dave I've gone ahead and filed an RFE bug in our bugzilla to help track this work: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Immad: you should probably assign that bug to yourself. Do you have an account yet for bugzilla? See: https://gcc.gnu.org/gitwrite.html#authenticated for info on how to get an account on sourceware.org/gcc.gnu.org I can be your sponsor. Once you have that, I think you automatically get a usern...@gcc.gnu.org account that you can use to login to the GCC bugzilla. Dave
gomp_affinity_format_len
Hello, this variable doesn't take value. It's always zero. Is this intended? Mohamed
Re: gomp_affinity_format_len
Sorry i found it in affinity-fmt.c في الخميس، ١٦ يونيو، ٢٠٢٢ ٥:٤١ م Mohamed Atef كتب: > Hello, >this variable doesn't take value. It's always zero. > Is this intended? > > Mohamed >
Re: gomp_affinity_format_len
I cant't get the value of "gomp_affinity_format_let" I used the plugin but it only gives 0 value. if you noticed in the gompd_get_affinity_format i used 100 for the length of the affinity format. Mohamed. في الخميس، ١٦ يونيو، ٢٠٢٢ ٥:٤٦ م Mohamed Atef كتب: > Sorry i found it in affinity-fmt.c > > في الخميس، ١٦ يونيو، ٢٠٢٢ ٥:٤١ م Mohamed Atef > كتب: > >> Hello, >>this variable doesn't take value. It's always zero. >> Is this intended? >> >> Mohamed >> >
Re: gomp_affinity_format_len
On Thu, Jun 16, 2022 at 06:00:47PM +0200, Mohamed Atef wrote: > I cant't get the value of "gomp_affinity_format_let" I used the plugin but > it only gives 0 value. if you noticed in the gompd_get_affinity_format i > used 100 for the length of the affinity format. gomp_affinity_format_len is just an internal var holding how many bytes have been allocated for the gomp_affinity_format pointer. Unless you use OMP_AFFINITY_FORMAT env var or call omp_set_affinity_format, it will be 0. Jakub
gcc-10-20220616 is now available
Snapshot gcc-10-20220616 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20220616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 20ece449e06f2d0dd0c50db0203d13b4e4ff2d96 You'll find: gcc-10-20220616.tar.xz Complete GCC SHA256=908afcde078b1e6ba5355044cbff6e5c9de54ea5059a34e070805b58d4650a73 SHA1=b64b4262e78e0cf81354fb86f5ce07bc7ca360e9 Diffs from 10-20220609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[RFC] Warnings for cases where int promotion is unexpected and may cause bugs
Hello,
A colleague patched a prod-critical bug today caused by an overlooked implicit
int promotion when adding uint8_t's. g++ (v12.1) doesn't report any warnings
for it with all combinations of warnings flags that I've tried, so I thought
I'd ask if:
- there *is* already some combination of warning flags that *would* report a
warning for this code
- if not, then if there's any interest in work (which of course I'd be happy to
contribute to) on detecting and flagging this sort of problem.
A (much simplified) example which illustrates the bug:
#+BEGIN_SRC cpp
#include
using std::uint8_t;
bool foo(uint8_t a, uint8_t b, uint8_t c) {
return (a + b) == c;
}
#+END_SRC
Here's the problem: the expectation here is that "a + b" will have type
uint8_t. So, for example it expects "foo(200, 200, 144)" to return "true".
In reality, "a + b" implicitly promotes to an "int" and so we end up comparing
400 and 144, which returns false.
(Side note, not immediately relevant: I'm not sure if this ends up being
equivalent to calling something like a "bool operator==(int, uint8_t)" or if
the RHS is also implicitly promoted to an int before the comparison. This is
irrelevant for the immediate example because the end result is the same in
either case, but I would appreciate it if someone can shed light on what the
standard has to say on this for future reference.)
A correct implementation of the expected behavior is instead therefore:
#+BEGIN_SRC cpp
#include
using std::uint8_t;
bool foo(uint8_t a, uint8_t b, uint8_t c) {
return static_cast(a + b) == c;
}
#+END_SRC
Does anyone else find this very surprising, and as I asked above, does it seem
worthwhile to try to flag code like in the first snippet? I don't know what
gcc's general policy on trying to warn about code like this is. The new
theoretical warning would be in the spirit of -Wconversion.
-Ani
Re: [RFC] Warnings for cases where int promotion is unexpected and may cause bugs
Apologies, I didn't realize that my mail client doesn't
auto-wrap. Please find a wrapped copy of my original message below my
signature.
-Ani
On Thu, Jun 16, 2022, at 9:11 PM, Aniruddh Agarwal wrote:
> Hello,
>
> A colleague patched a prod-critical bug today caused by an overlooked
> implicit int promotion when adding uint8_t's. g++ (v12.1) doesn't
> report any warnings for it with all combinations of warnings flags that
> I've tried, so I thought I'd ask if:
>
> - there *is* already some combination of warning flags that *would*
> report a warning for this code
>
> - if not, then if there's any interest in work (which of course I'd be
> happy to contribute to) on detecting and flagging this sort of problem.
>
> A (much simplified) example which illustrates the bug:
> #+BEGIN_SRC cpp
> #include
>
> using std::uint8_t;
>
> bool foo(uint8_t a, uint8_t b, uint8_t c) {
> return (a + b) == c;
> }
> #+END_SRC
>
> Here's the problem: the expectation here is that "a + b" will have type
> uint8_t. So, for example it expects "foo(200, 200, 144)" to return
> "true".
>
> In reality, "a + b" implicitly promotes to an "int" and so we end up
> comparing 400 and 144, which returns false.
>
> (Side note, not immediately relevant: I'm not sure if this ends up
> being equivalent to calling something like a "bool operator==(int,
> uint8_t)" or if the RHS is also implicitly promoted to an int before
> the comparison. This is irrelevant for the immediate example because
> the end result is the same in either case, but I would appreciate it if
> someone can shed light on what the standard has to say on this for
> future reference.)
>
> A correct implementation of the expected behavior is instead therefore:
> #+BEGIN_SRC cpp
> #include
>
> using std::uint8_t;
>
> bool foo(uint8_t a, uint8_t b, uint8_t c) {
> return static_cast(a + b) == c;
> }
> #+END_SRC
>
> Does anyone else find this very surprising, and as I asked above, does
> it seem worthwhile to try to flag code like in the first snippet? I
> don't know what gcc's general policy on trying to warn about code like
> this is. The new theoretical warning would be in the spirit of
> -Wconversion.
>
> -Ani
