Re: Doubts about GCC advancement (GSoC)

[Martin Jambor]

Hello,

I am delighted you found contributing to GCC interesting.  Sorry for the
delay in replying.

I am adding the GCC mailing list in case other GCC developers have
something to add to my reply.  It is usually a good idea to email the
list and not an individual, if only because most of the community is
better at timely replies than I am.

On Wed, Jan 19 2022, Krishna wrote:
> Respected Sir,
>
> Hello,I am Krishna Narayanan ,an undergraduate pursuing electronics and 
> telecommunications,I am a beginner and new to this community.I kicked 
> off by building the gcc from source and I have successfully build the 
> gcc 10.1 on my linux which had a default of gcc-9.3.0.

If you want to contribute new features (as opposed to fixing old bugs),
you should really check-out the current development version (master) from
our git and build that.  If you managed to build gcc 10 from the
sources, you should find it easy.  But in order to study the sources to
plan your project, it is important to look at the current version.

Although git master is a moving target, usually that is generally not a
problem and until approximately April we are now in bug-fixing stage
only, so it really should not be a concern.  Later, if there are any big
changes in an area related to your GSoC project, your mentor will help
you overcome it.

> I was surfing for 
> projects but GCC caught my attention as I was familiar with the 
> technologies and eager to learn more in depth about the compiler.
>
> I am not familiar with many terms but trying to cope up with it.

This might not be easy but perhaps there is still time to learn the
important basics, depending on the area in which you'd like to work.

In most cases, you would need at least to know what an Intermediate
Language (IR) is and have a general understanding of the relevant one in
GCC - which is probably Gimple or the representation used by the
front-end (such as Fortran or Rust) if you decide to contribute to one.

The "Make cp-demangle non-recursive" project requires "just" good
working knowledge of C and how to implement a recursion driven by an
explicit stack.

> I went 
> through last year projects read about their definitions what they meant 
> and what was modified/changed for a better enhancement but I did'nt get 
> a grasp over it as I have just started. Can you suggest me some good 
> first issues,

No unfortunately I cannot.  Perhaps someone else might.  But I am afraid
there are not very many open easy issues in GCC.  Easy issues get fixed
quickly.

But if you have a specific question abut any particular term or problem,
feel free to ask on the mailing list.  It might even help us to phrase
it better on our wiki.

> I have read the simple projects given on the webpage  about 
> debugging of test suites but I did not get a clear idea about that,can 
> you suggest me a tutprial or manual which I can follow debugging

Perhaps https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html
and especially
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html 

>I read 
> about project topics but have a doubt regarding their implementation for 
> example I understood static analysis pass but how do I implement it in 
> gcc,!?

GCC already has static analyzer, it just needs to be extended (see files
in subdirectory src/gcc/analyzer after you have checked out our master).
Figuring out how to extend it - with the help of the community(!) - is
part of the game.  So again, if you have any specific question about it,
feel free to ask.

Hope this helps at least a little,

Martin

Re: GSoC: Working on the static analyzer

[Ankur Saini via Gcc]

The following can be a possible example of a case where the analyzer fails
to understand POSIX file-descriptor API.

- - -
#include 
#include 

void test()
{
int fd;
fd = open("foo.txt", O_RDONLY | O_CREAT);
}

void test_2()
{
FILE *f;
f = fopen("demo.c", "r");
}

godbolt link: https://godbolt.org/z/vbTq6fTnd
- - -

You can see that unlike the "File *” pointer ( f ), analyzer is not
tracking integer file descriptor ( fd ) which is also leaking at the end of
function "test ()” and should ideally be reported with CWE-775
( https://cwe.mitre.org/data/definitions/775.html )

If you look at the exploded graph of the given program, the analyzer is not
able to identify the call to `open ()` and treating it as a "call to
unknown function”.

- Ankur

syslog: ISO C does not support the ‘%m’ gnu_printf format

[Kris Andersen via Gcc]

The %m format specifier is a documented feature of syslog, but gcc gives a
warning when -Wpedantic is used. Is this a bug?

For example, the program:

#include 
int main(void)
{
syslog(LOG_ERR, "%m");
return 0;
}

gives:
warning: ISO C does not support the ‘%m’ gnu_printf format [-Wformat=]

when compiled[1] with
gcc -Wall -Wextra -Wpedantic -o test test.c

The man page for syslog(3) states that %m is supported: "the two-character
sequence %m will be replaced by the error message string strerror(errno)."

Submitting a bug report for this feels like arguing that the answer in the
back of the book is wrong (...rarely the right move). What am I missing
here?

Thanks in advance,

  Kris

[1]: gcc (GCC) 11.2.1 20211203 on Linux version 5.15.16-200.fc35.x86_64
(Fedora v35)

Re: syslog: ISO C does not support the ‘%m’ gnu_printf format

[Ankur Saini via Gcc]

> On 25-Jan-2022, at 9:38 AM, Kris Andersen via Gcc  wrote:
> 
> The %m format specifier is a documented feature of syslog, but gcc gives a
> warning when -Wpedantic is used. Is this a bug?
> 
> For example, the program:
> 
> #include 
> int main(void)
> {
>syslog(LOG_ERR, "%m");
>return 0;
> }
> 
> gives:
> warning: ISO C does not support the ‘%m’ gnu_printf format [-Wformat=]

I think, the compiler is correct by complaining about it when strict
warnings are enabled.

according to GNU documentation
(http://www.gnu.org/software/libc/manual/html_node/Other-Output-Conversions.html)

“ The ‘%m’ conversion is a GNU C Library extension “

> 
> when compiled[1] with
> gcc -Wall -Wextra -Wpedantic -o test test.c
> 
> The man page for syslog(3) states that %m is supported: "the two-character
> sequence %m will be replaced by the error message string strerror(errno)."
> 
> Submitting a bug report for this feels like arguing that the answer in the
> back of the book is wrong (...rarely the right move). What am I missing
> here?

FWIW, A bug report requesting support for __format__ attribute for
syslog is already filed as bug 15338 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15338 )

Thanks
- Ankur