Re: GCC support for extensions from later standards

[Nikolas Klauser]

On 06.08.23 12:19, Jason Merrill wrote:
On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser 
 wrote:


Hi everyone!

I'm working on libc++ and we are currently discussing using
language extensions from later standards

(https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4).
By that I mean things like using `if constexpr` with `-std=c++11`.
GCC has quite a lot of these kinds of conforming extensions, but
doesn't document them AFAICT. While discussing using these
extensions, the question came up what GCCs support policy for
these is. Aaron was kind enough to answer these questions for us
on the Clang side. Since I couldn't find anything in the
documentation, I thought I'd ask here.

So, here are my questions:

Do you expect that these extensions will ever be removed for some
reason? If yes, what could those reasons be?


Potentially, if they don't actually work properly in earlier standard 
modes.  I recently noticed that while we allow DMI and =default in 
C++03 mode with a pedwarn, combining them doesn't work.


Some of the extensions are needed by libstdc++ and are therefore well 
tested; these are extremely unlikely to ever be removed.  libstdc++ 
folks, is there a list of these?


Would you be interested in documenting them?


That would be useful, yes.

There is a patch in review to add __has_feature/__has_extension to 
G++, which would seem like a suitable context for this documentation.


Aaron noted that we should ask the Clang folks before using them,
so they can evaluated whether the extension makes sense, since
they might not be aware of them, and some might be broken. So I'd
be interested whether you would also like us to ask whether you
want to actually support these extensions.


Sounds good.

Jason


Thanks for the answers!

There are a few really interesting extensions that I would like to use:

- inline variables
- variable templates
- `if constexpr`
- fold expressions
- conditional explicit
- static operator()

(https://godbolt.org/z/5n9Y4h69n)

Is anybody aware of any problems with these extensions? I'd be happy to 
provide a patch to add these extensions to the documentation, but I 
couldn't figure out how to build the documentation without building all 
of gcc.


Nikolas

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

[David Malcolm via Gcc]

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
> > > > 
> > > > 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 including /* { dg-options "-
> > > > > > fanalyzer
> > > > > > -I/usr/include/python3.9" } */. This is undoubtedly not
> > > > > > ideal;
> > > > > > is
> > > > > > it
> > > > > > best to approach this problem by adapting a subset of
> > > > > > relevant
> > > > > > definitions like in gil.h?
> > > > > 
> > > > > That might be acceptable in the very short-term, but to
> > > > > create a
> > > > > plugin
> > > > > that's useful to end-user (authors of CPython extension
> > > > > modules)
> > > > > we
> > > > > want to be testing against real Python headers.
> > > > > 
> > > > > As I understand it, https://peps.python.org/pep-0394/ allows
> > > > > for
> > > > > distributors of Python to symlink "python3-config" in the
> > > > > PATH to
> > > > > a
> > > > > python3.X-config script (for some X).
> > > > > 
> > > > > So on such systems running:
> > > > >   python3-config --includes
> > > > > should emit the correct -I option.  On my box it emits:
> > > > > 
> > > > > -I/usr/include/python3.8 -I/usr/include/python3.8
> > > > > 
> > > > > 
> > > > > It's more complicated, but I believe:
> > > > >   python3-config --cflags
> > > > > should emit the build flags that C/C++ extensions ought to
> > > > > use
> > > > > when
> > > > > building.  On my box this emits:
> > > > > 
> > > > > -I/usr/include/python3.8 -I/usr/include/python3.8  -Wno-
> > > > > unused-
> > > > > result -
> > > > > Wsign-compare  -O2 -g -pipe -Wall -Werror=format-security -
> > > > > Wp,-
> > > > > D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -
> > > > > fstack-
> > > > > protector-strong -grecord-gcc-switches   -m64 -mtune=generic
> > > > > -
> > > > > fasynchronous-unwind-tables -fstack-clash-protection -fcf-
> > > > > protection -
> > > > > D_GNU_SOURCE -fPIC -fwrapv  -DDYNAMIC_ANNOTATIONS_ENABLED=1 -
> > > > > DNDEBUG  -
> > > > > O2 -g -pipe -Wall -Werror=format-security -Wp,-
> > > > > D_FORTIFY_SOURCE=2
> > > > > -
> > > > > Wp,-
> > > > > D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -
> > > > > grecord-
> > > > > gcc-switches   -m64 -mtune=generic -fasynchronous-unwind-
> > > > > tables -
> > > > > fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -
> > > > > fwrapv
> > > > > 
> > > > > and it's likely going to vary from distribution to
> > > > > distribution.
> > > > > Some
> > > > > of those options *are* going to affect the gimple that -
> > > > > fanalyzer
> > > > > "sees".
> > > > > 
> > > > > Does your installation of Python have such a script?
> > > > > 
> > > > > So in the short term you could hack in a minimal subset of
> > > > > the
> > > > > decls/defns from Python.h, but I'd prefer it if target-
> > > > > supports.exp
> > > > > gained a DejaGnu directive that invokes python3-config,
> > > > > captures
> > > > > the
> > > > > result (or fails with UNSUPPORTED for systems without python3
> > > > > development headers), and then adds the result to the build
> > > > > flags
> > > > > of
> > > > > the file being tested.  The .exp files are implemented in
> > > > > Tcl,
> > > > > alas;
> > > > > let me know if you want help with that.
> > > > > 
> > > > > Dave
> > > > Sounds good; thanks! Following existing examples in
> > > > target-supports.exp, the following works as expected in terms
> > > > of
> > > > extracting the build flags we are interested in.
> > > > 
> > > > In target-supports.exp:
> > > > proc check_python_flags { } {
> > > >     set result [remote_exec host "python3-config --cflags"]
> > > >     set status [lindex $result 0]
> > > >     if { $status == 0 } {
> > > >     return [lindex $result 1]
> > > >     } else {
> > > >     return "UNSUPPORTED"
> > > >     }
> > > > }
> > > > 
> > > > However, I'm having some trouble figuring out the specifics as
> > > > to
> > > > how
> > > > we may add the build flags to our test cases. My intuition
> > > > looks
> > > > like
> > > > something like the following:
> > > > 
> > > > In plugin.exp:
> > > > foreach plugin_test $plugin_test_list {
> > > >     if {[lindex $plugin_test 0] eq "analyzer_cpython_plugin.c"}
> > > > {
> > > >     set python_flags [check_python_flags]
> > > >     if { $python_flags ne "UNSUPPORTED" } {
> > > >    // append $python_flags to build flags here
> > > >     }
> > > >     }
> > > > 
> > > > }
> > > > 
> > > > How might we do so?
> > > 
> > > Good question.
> > > 
> > > Looking at plugin.exp I see it uses plugin-test-execute, which is
> > > defined in gcc/test

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

[Eric Feng via Gcc]

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 
> > > 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 including /* { dg-options "-
> > > > > fanalyzer
> > > > > -I/usr/include/python3.9" } */. This is undoubtedly not ideal;
> > > > > is
> > > > > it
> > > > > best to approach this problem by adapting a subset of relevant
> > > > > definitions like in gil.h?
> > > >
> > > > That might be acceptable in the very short-term, but to create a
> > > > plugin
> > > > that's useful to end-user (authors of CPython extension modules)
> > > > we
> > > > want to be testing against real Python headers.
> > > >
> > > > As I understand it, https://peps.python.org/pep-0394/ allows for
> > > > distributors of Python to symlink "python3-config" in the PATH to
> > > > a
> > > > python3.X-config script (for some X).
> > > >
> > > > So on such systems running:
> > > >   python3-config --includes
> > > > should emit the correct -I option.  On my box it emits:
> > > >
> > > > -I/usr/include/python3.8 -I/usr/include/python3.8
> > > >
> > > >
> > > > It's more complicated, but I believe:
> > > >   python3-config --cflags
> > > > should emit the build flags that C/C++ extensions ought to use
> > > > when
> > > > building.  On my box this emits:
> > > >
> > > > -I/usr/include/python3.8 -I/usr/include/python3.8  -Wno-unused-
> > > > result -
> > > > Wsign-compare  -O2 -g -pipe -Wall -Werror=format-security -Wp,-
> > > > D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -
> > > > fstack-
> > > > protector-strong -grecord-gcc-switches   -m64 -mtune=generic -
> > > > fasynchronous-unwind-tables -fstack-clash-protection -fcf-
> > > > protection -
> > > > D_GNU_SOURCE -fPIC -fwrapv  -DDYNAMIC_ANNOTATIONS_ENABLED=1 -
> > > > DNDEBUG  -
> > > > O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > > > -
> > > > Wp,-
> > > > D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -
> > > > grecord-
> > > > gcc-switches   -m64 -mtune=generic -fasynchronous-unwind-tables -
> > > > fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -
> > > > fwrapv
> > > >
> > > > and it's likely going to vary from distribution to distribution.
> > > > Some
> > > > of those options *are* going to affect the gimple that -fanalyzer
> > > > "sees".
> > > >
> > > > Does your installation of Python have such a script?
> > > >
> > > > So in the short term you could hack in a minimal subset of the
> > > > decls/defns from Python.h, but I'd prefer it if target-
> > > > supports.exp
> > > > gained a DejaGnu directive that invokes python3-config, captures
> > > > the
> > > > result (or fails with UNSUPPORTED for systems without python3
> > > > development headers), and then adds the result to the build flags
> > > > of
> > > > the file being tested.  The .exp files are implemented in Tcl,
> > > > alas;
> > > > let me know if you want help with that.
> > > >
> > > > Dave
> > > Sounds good; thanks! Following existing examples in
> > > target-supports.exp, the following works as expected in terms of
> > > extracting the build flags we are interested in.
> > >
> > > In target-supports.exp:
> > > proc check_python_flags { } {
> > > set result [remote_exec host "python3-config --cflags"]
> > > set status [lindex $result 0]
> > > if { $status == 0 } {
> > > return [lindex $result 1]
> > > } else {
> > > return "UNSUPPORTED"
> > > }
> > > }
> > >
> > > However, I'm having some trouble figuring out the specifics as to
> > > how
> > > we may add the build flags to our test cases. My intuition looks
> > > like
> > > something like the following:
> > >
> > > In plugin.exp:
> > > foreach plugin_test $plugin_test_list {
> > > if {[lindex $plugin_test 0] eq "analyzer_cpython_plugin.c"} {
> > > set python_flags [check_python_flags]
> > > if { $python_flags ne "UNSUPPORTED" } {
> > >// append $python_flags to build flags here
> > > }
> > > }
> > > 
> > > }
> > >
> > > How might we do so?
> >
> > Good question.
> >
> > Looking at plugin.exp I see it uses plugin-test-execute, which is
> > defined in gcc/testsuite/lib/plugin-support.exp.
> >
> > Looking there, I see it attempts to build the plugin, and then if it
> > succeeds, it calls
> >   dg-runtest $plugin_tests $plugin_enabling_flags $default_flags
> > where $plugin_tests is the list of source files to be compiled using
> > the plugin.  So one way to do this would be to modify that code from
> > plugin.exp to pass in a different value, rather than $default_flags.
> > Though it seems hackish to special-case this.
>
> Sorry, I think I misspoke here; that line that uses $default_flags is
>

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

[David Malcolm via Gcc]

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 fully-defined
> function or whatever, then the warning reappears.
> The above SSA differ by an extra basic block in G++ that splits GCC's
>  6> in two.
> However, that doesn't account for much, as changing
>   if (p == NULL) {
>   perror ("realloc");
>   __builtin_va_end (args); // (*)
>   return -1;
>     }
> to
>     if (p == NULL) {
>   int x;
>   perror("realloc");
>   if (x > 7)
>     x = 12;
>   __builtin_va_end (args);
>   return -1;
>     }
> generates a similar basic block around __builtin_va_end, yet G++
> keeps
> emitting the false positive whereas GCC doesn't.
> // GCC modified SSA
>    :
>   perror ("realloc");
>   if (x_51(D) > 7)
>     goto ; [INV]
>   else
>     goto ; [INV]
> 
>    :
>   x_52 = 12;
> 
>    :
>   __builtin_va_end (&args);
>   _54 = -1;
>   // predicted unlikely by early return (on trees) predictor.
>   goto ; [INV]
> 
> // G++ modified SSA
>    :
>   perror ("realloc");
> 
>    :
>   if (x_55(D) > 7)
>     goto ; [INV]
>   else
>     goto ; [INV]
> 
>    :
>   x_56 = 12;
> 
>    :
>   __builtin_va_end (&args);
>   _58 = -1;
>   // predicted unlikely by early return (on trees) predictor.
>   goto ; [INV]
> 
> Debugging and glaring at the exploded graph gave me no clue towards
> fixing
> this test.
> If you have any hint, I welcome it.

There a CFG difference here, so have a look at the .supergraph.dot
files with gcc vs g++, using -fdump-analyzer-supergraph.

Both write out to pr99193-1.c.supergraph.dot, but renaming the results
and then comparing them side-by-side, I see various differences.  In
particular, looking at the BB containing the perror ("realloc"), both
GCC and G++ have an out-edge with flag FALLTHRU going to the BB that
starts with __builtin_va_end, but G++ also has an out-edge with flag EH
going to BB 16, which starts with guestfs_int_cleanup_free (generated
by the __attribute__((cleanup(guestfs_int_cleanup_free))) on argv.

So I think what we're seeing here is the execution path that follows
that EH edge, which is to handle the case where perror raises an
exception.  I don't know if that's actually possible, but perhaps it
is.

Are you adding any exception-handling flags to the G++ cases? (e.g.
disabling exception-handling?)

Dave

Re: There Might a Bug in the Compiler: When Calling Weak Defined Function

[Andrew Pinski via Gcc]

On Mon, Aug 7, 2023 at 8:52 AM Şahin Duran via Gcc  wrote:
>
> Dear GCC Developers,
>
> I think I've just discovered a bug/ undefined situation in the compiler.
> When I try to call a weakly defined function, compiler successfully
> generates the code of calling procedure. However, this calling procedure is
> nothing but branching to address 0 which results in segmentation fault. I
> am not sure if this is the case for the latest version of GCC but it is for
> GCC 4.9.2 and many online compilers. I just thought that maybe including a
> rule that generates compilation error when the user defines a weak function
> and calls it without actually implementing it. You may find the results in
> the attachments.

You need to check the address of weak defined symbol (function) to
make sure it is not a nullptr before calling it.
A weak defined symbol might have the address of nullptr if it is not
defined. And you are running into that.
This is a feature of elf and weak symbols.

Thanks,
Andrew

>
> Kind regards,
> I am looking forward to hearing from you about this.
> Şahin Duran
>
>
> Attachments:
>
> Source Code:
> #include 
> #include 
> #include "header.h"
>
> __attribute__((weak)) int add(int,int);
>
> int main(int argc, char *argv[]) {
> printf("%x",add);
> add(31,31);
> return 0;
> }
> terminal result : 0
>
> Disassembly (on a 64bit AMD Machine):
> 0x00401530 <+0>: push   rbp
>0x00401531 <+1>: movrbp,rsp
>0x00401534 <+4>: subrsp,0x20
>0x00401538 <+8>: movDWORD PTR [rbp+0x10],ecx
>0x0040153b <+11>: movQWORD PTR [rbp+0x18],rdx
>0x0040153f <+15>: call   0x402100 <__main>
>0x00401544 <+20>: movrdx,QWORD PTR [rip+0x2ed5]#
> 0x404420 <.refptr.add>
>0x0040154b <+27>: learcx,[rip+0x2aae]# 0x404000
>0x00401552 <+34>: call   0x402b18 
> => 0x00401557 <+39>: movedx,0x1f
>0x0040155c <+44>: movecx,0x1f
>0x00401561 <+49>: call   0x0
>0x00401566 <+54>: moveax,0x0
>0x0040156b <+59>: addrsp,0x20
>0x0040156f <+63>: poprbp
>0x00401570 <+64>: ret

Re: There Might a Bug in the Compiler: When Calling Weak Defined Function

[Richard Earnshaw (lists) via Gcc]

On 07/08/2023 16:51, Şahin Duran via Gcc wrote:

Dear GCC Developers,

I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
nothing but branching to address 0 which results in segmentation fault. I
am not sure if this is the case for the latest version of GCC but it is for
GCC 4.9.2 and many online compilers. I just thought that maybe including a
rule that generates compilation error when the user defines a weak function
and calls it without actually implementing it. You may find the results in
the attachments.

Kind regards,
I am looking forward to hearing from you about this.
Şahin Duran




If a function might be weak, you need to test that it is defined before 
calling it.  So this is a bug in your program.  You need to write


  if (add)
add (31, 31);

Or something like that which checks that the symbol has been defined.

R.


Attachments:

Source Code:
#include 
#include 
#include "header.h"

__attribute__((weak)) int add(int,int);

int main(int argc, char *argv[]) {
printf("%x",add);
add(31,31);
return 0;
}
terminal result : 0

Disassembly (on a 64bit AMD Machine):
0x00401530 <+0>: push   rbp
0x00401531 <+1>: movrbp,rsp
0x00401534 <+4>: subrsp,0x20
0x00401538 <+8>: movDWORD PTR [rbp+0x10],ecx
0x0040153b <+11>: movQWORD PTR [rbp+0x18],rdx
0x0040153f <+15>: call   0x402100 <__main>
0x00401544 <+20>: movrdx,QWORD PTR [rip+0x2ed5]#
0x404420 <.refptr.add>
0x0040154b <+27>: learcx,[rip+0x2aae]# 0x404000
0x00401552 <+34>: call   0x402b18 
=> 0x00401557 <+39>: movedx,0x1f
0x0040155c <+44>: movecx,0x1f
0x00401561 <+49>: call   0x0
0x00401566 <+54>: moveax,0x0
0x0040156b <+59>: addrsp,0x20
0x0040156f <+63>: poprbp
0x00401570 <+64>: ret

There Might a Bug in the Compiler: When Calling Weak Defined Function

[Şahin Duran via Gcc]

Dear GCC Developers,

I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
nothing but branching to address 0 which results in segmentation fault. I
am not sure if this is the case for the latest version of GCC but it is for
GCC 4.9.2 and many online compilers. I just thought that maybe including a
rule that generates compilation error when the user defines a weak function
and calls it without actually implementing it. You may find the results in
the attachments.

Kind regards,
I am looking forward to hearing from you about this.
Şahin Duran


Attachments:

Source Code:
#include 
#include 
#include "header.h"

__attribute__((weak)) int add(int,int);

int main(int argc, char *argv[]) {
printf("%x",add);
add(31,31);
return 0;
}
terminal result : 0

Disassembly (on a 64bit AMD Machine):
0x00401530 <+0>: push   rbp
   0x00401531 <+1>: movrbp,rsp
   0x00401534 <+4>: subrsp,0x20
   0x00401538 <+8>: movDWORD PTR [rbp+0x10],ecx
   0x0040153b <+11>: movQWORD PTR [rbp+0x18],rdx
   0x0040153f <+15>: call   0x402100 <__main>
   0x00401544 <+20>: movrdx,QWORD PTR [rip+0x2ed5]#
0x404420 <.refptr.add>
   0x0040154b <+27>: learcx,[rip+0x2aae]# 0x404000
   0x00401552 <+34>: call   0x402b18 
=> 0x00401557 <+39>: movedx,0x1f
   0x0040155c <+44>: movecx,0x1f
   0x00401561 <+49>: call   0x0
   0x00401566 <+54>: moveax,0x0
   0x0040156b <+59>: addrsp,0x20
   0x0040156f <+63>: poprbp
   0x00401570 <+64>: ret

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

[David Malcolm via Gcc]

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 makes me nervous; if we disagree
on how an aspect of the work should be done, it would be better to sort
that out sooner rather than when you've done all the work.  So in the
spirit of "release early, release often", are you able to post a small
representative subset of the work to gcc-patches?

Also, do you have backups?

Further comments inline below...

> I'll only detail the most noteworthy tests I encountered.
> 
> gcc.dg/analyzer/pr103892.c troubled me with an Excess error when
> compiled
> with g++
> analysis bailed out early (91 'after-snode' enodes; 314 enodes)
> [-Wanalyzer-too-complex]
> 
> pr103892.c is compiled with optimization level -O2.
> Analysis bails out when the number of "after-SN" enodes explodes,
> i.e.
> exceeds a certain proportion of the total number of SG nodes.
> limit(after-SN) = m_sg.num_nodes ()  * param-bb-explosion-factor.
> The reason why C and C++ differs is simply due to what '-O2' does to
> each
> of them.
> Under -O0 or -O1, there is no failure whatsoever, under -O2 only C++
> fails,
> whereas with -O3 both gcc and g++ emits -Wanalyzer-too-complex.
> With -O2, although GCC produces a greater total number of "after-SN"
> enodes
> than G++, their proportion barely stays under limit(after-SN) as
> the total number of SN is also bigger, hence no warning is emitted.

Is the gimple seen by -fanalyzer different between the C and C++
frontends for this case?

> 
> All in all, I don't believe there is a significant difference here
> between
> C and C++, nor is there much we can do about this.
> Therefore I'll simply add a { dg-warning "analysis bailed out early"
> "" {
> target c++ } }

Putting in a dg-warning directive would mean that we expect the warning
at that line, which would be over-specifying the behavior of the test.

It's usually better to add -Wno-analyzer-too-complex to the options. 
Looking at git log, that test was added in
3d41408c5d28105e7a3ea2eb2529431a70b96369 as part of a fix for state
explosions.  So the absense of -Wanalyzer-too-complex is something that
the test is effectively asserting.  Hence the -Wno-analyzer-too-complex
should be conditional on { target c++ }.


> An interesting divergence between GCC and G++ was in the handling of
> built-ins.
> Tests gcc.dg/analyzer/{pr104062.c,sprintf-2.c} are failing when
> compiling
> with G++.
> FAIL: c-c++-common/analyzer/pr104062.c  leak of ap7 at line 13 (test
> for
> warnings, line 12)
> The reason is neither realloc nor sprintf are considered by G++ as a
> built-in, contrary to GCC.

Do you know why this happens?  I see both of those tests have their own
prototypes for the functions in question, rather than using system
headers; maybe those prototypes don't match some property that the C++
FE is checking for?

> C built-ins are mapped within the analyzer to known_functions using
> their
> 'enum combined_fn' code
> (See kf.cc:register_known_functions), not their function name.
> Therefore, we find a built-in known function by checking
> tree.h:fndecl_built_in_p returns true
> and calling known_function_manager::get_normal_builtin.
> The former returns false for 'realloc' and 'sprintf' when using G++.
> 
> To fix that, I've derived builtin_known_function from known_function.
> 
> /* Subclass of known_function for builtin functions.  */
> 
> class builtin_known_function : public known_function
> {
> public:
>   virtual enum built_in_function builtin_code () const = 0;
>   tree builtin_decl () const {
>     gcc_assert (builtin_code () < END_BUILTINS);
>     return builtin_info[builtin_code ()].decl;
>   }
> 
>   virtual const builtin_known_function *
>   dyn_cast_builtin_kf () const { return this; }
>   virtual builtin_known_function *
>   dyn_cast_builtin_kf () { return this; }
> };
> 
> And 'kfm.add (BUILT_IN_REALLOC, make_unique ());' becomes
> kfm.add ("realloc", make_unique ());
> kfm.add ("__builtin_realloc", make_unique ());
> 
> Unfortunately we have to register the built-ins using their function
> name
> which is more apt to bugs,
> and the double call to kfm.add is quite messy. Having two instances
> of
> kf_realloc however is not that troubling,
> as builtin_known_function objects are lightweight.
> 
> That GCC built-ins are not recognized by G++ doesn't only impede
> their
> detection,
> but also how we process them, and what information we have of them.
> In gcc.dg/analyzer/sprintf-2.c, sprintf signature follows the manual
> and
> cppreference.
> Yet we expect sm-malloc to warn about use of NULL when either of the
> argument is NULL,
> although there is no attribute(nonnull) specified.
> In fact, sm-malloc isn't using the signature of sprintf as specified
> in the
> test case, but rather the one provided
> by

Re: GNU Tools Cauldron 2023

[Richard Earnshaw (lists) via Gcc]

We have now finalized the ticket price for this year's Cauldron at £75.
Sarah is now contacting those who have already registered to arrange
payment.

If you have not yet registered then there is still time.  Registration
closes at 12 Noon BST (7am EDT) on Friday 1st September, and all tickets 
must be paid for by 6pm BST (1pm EDT) on Monday 4th September.  This is 
to allow time to finalize catering requirements before the event.


We have a full schedule for the event, so registration of talks is now
closed.  If you have not yet submitted a talk but wish to do so, please
do contact the organisers: we will fit you in if we can, but priority
will go to those who have already submitted something.

Richard.

On 25/07/2023 18:01, Richard Earnshaw via Gcc wrote:
It is now just under 2 months until the GNU Tools Cauldron. Registration 
is still open, but we would really appreciate it if you could register 
as soon as possible so that we have a clear idea of the numbers.


Richard.

On 05/06/2023 14:59, Richard Earnshaw wrote:

We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Cambridge, UK, on September 22-24, 2023.

As for the previous instances, we have setup a wiki page for
details:

https://gcc.gnu.org/wiki/cauldron2023 




Like last year, we are having to charge for attendance.  We are still
working out what we will need to charge, but it will be no more than 
£250.


Attendance will remain free for community volunteers and others who do
not have a commercial backer and we will be providing a small number of
travel bursaries for students to attend.

For all details of how to register, and how to submit a proposal for a
track session, please see the wiki page.

The Cauldron is organized by a group of volunteers. We are keen to add
some more people so others can stand down. If you'd like to be part of
that organizing committee, please email the same address.

This announcement is being sent to the main mailing list of the
following groups: GCC, GDB, binutils, CGEN, DejaGnu, newlib and glibc.

Please feel free to share with other groups as appropriate.

Richard (on behalf of the GNU Tools Cauldron organizing committee).

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

[Benjamin Priour via Gcc]

Hi Dave,

I made some more progress on moving tests from gcc.dg/analyzer/ to
c-c++-common/analyzer.
I'll only detail the most noteworthy tests I encountered.

gcc.dg/analyzer/pr103892.c troubled me with an Excess error when compiled
with g++
analysis bailed out early (91 'after-snode' enodes; 314 enodes)
[-Wanalyzer-too-complex]

pr103892.c is compiled with optimization level -O2.
Analysis bails out when the number of "after-SN" enodes explodes, i.e.
exceeds a certain proportion of the total number of SG nodes.
limit(after-SN) = m_sg.num_nodes ()  * param-bb-explosion-factor.
The reason why C and C++ differs is simply due to what '-O2' does to each
of them.
Under -O0 or -O1, there is no failure whatsoever, under -O2 only C++ fails,
whereas with -O3 both gcc and g++ emits -Wanalyzer-too-complex.
With -O2, although GCC produces a greater total number of "after-SN" enodes
than G++, their proportion barely stays under limit(after-SN) as
the total number of SN is also bigger, hence no warning is emitted.

All in all, I don't believe there is a significant difference here between
C and C++, nor is there much we can do about this.
Therefore I'll simply add a { dg-warning "analysis bailed out early" "" {
target c++ } }

An interesting divergence between GCC and G++ was in the handling of
built-ins.
Tests gcc.dg/analyzer/{pr104062.c,sprintf-2.c} are failing when compiling
with G++.
FAIL: c-c++-common/analyzer/pr104062.c  leak of ap7 at line 13 (test for
warnings, line 12)
The reason is neither realloc nor sprintf are considered by G++ as a
built-in, contrary to GCC.
C built-ins are mapped within the analyzer to known_functions using their
'enum combined_fn' code
(See kf.cc:register_known_functions), not their function name.
Therefore, we find a built-in known function by checking
tree.h:fndecl_built_in_p returns true
and calling known_function_manager::get_normal_builtin.
The former returns false for 'realloc' and 'sprintf' when using G++.

To fix that, I've derived builtin_known_function from known_function.

/* Subclass of known_function for builtin functions.  */

class builtin_known_function : public known_function
{
public:
  virtual enum built_in_function builtin_code () const = 0;
  tree builtin_decl () const {
gcc_assert (builtin_code () < END_BUILTINS);
return builtin_info[builtin_code ()].decl;
  }

  virtual const builtin_known_function *
  dyn_cast_builtin_kf () const { return this; }
  virtual builtin_known_function *
  dyn_cast_builtin_kf () { return this; }
};

And 'kfm.add (BUILT_IN_REALLOC, make_unique ());' becomes
kfm.add ("realloc", make_unique ());
kfm.add ("__builtin_realloc", make_unique ());

Unfortunately we have to register the built-ins using their function name
which is more apt to bugs,
and the double call to kfm.add is quite messy. Having two instances of
kf_realloc however is not that troubling,
as builtin_known_function objects are lightweight.

That GCC built-ins are not recognized by G++ doesn't only impede their
detection,
but also how we process them, and what information we have of them.
In gcc.dg/analyzer/sprintf-2.c, sprintf signature follows the manual and
cppreference.
Yet we expect sm-malloc to warn about use of NULL when either of the
argument is NULL,
although there is no attribute(nonnull) specified.
In fact, sm-malloc isn't using the signature of sprintf as specified in the
test case, but rather the one provided
by GCC in builtins.def

/* See e.g. https://en.cppreference.com/w/c/io/fprintf
   and https://www.man7.org/linux/man-pages/man3/sprintf.3.html */

  extern int
  sprintf(char* dst, const char* fmt, ...)
__attribute__((__nothrow__)); // No attribute(nonnull)

int
test_null_dst (void)
{
  return sprintf (NULL, "hello world"); /* { dg-warning "use of NULL where
non-null expected" } */
}

int
test_null_fmt (char *dst)
{
  return sprintf (dst, NULL);  /* { dg-warning "use of NULL where non-null
expected" } */
}

Signature in builtins.def: DEF_LIB_BUILTIN(BUILT_IN_SPRINTF,
"sprintf", BT_FN_INT_STRING_CONST_STRING_VAR,
ATTR_NOTHROW_NONNULL_1_FORMAT_PRINTF_2_3)

My question is then : Should G++ behave as GCC and ignore the user's
signatures of built-ins, instead using the attributes specified by GCC ?
At the moment I went with a "yes". If the function is a builtin, I'm
operating on its builtin_known_function::builtin_decl () (see above) rather
than the callee_fndecl
deduced from a gimple call, therefore overriding the user's signature.

Doing so led to tests sprintf-2.c and realloc-1.c to pass both in GCC and
G++.


Last test I'd like to discuss is analyzer/pr99193-1.c

/* { dg-additional-options "-Wno-analyzer-too-complex" } */

/* Verify absence of false positive from -Wanalyzer-mismatching-deallocation
   on realloc(3).
   Based on
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/command.c#L115
   which is GPLv2 or later.  */

typedef __SIZE_TYPE__ size_t;
typedef __builtin_va_list va_list;

#ifdef __cp

Re: GCC support for extensions from later standards

[Jonathan Wakely via Gcc]

On Sun, 6 Aug 2023 at 20:43, Jonathan Wakely  wrote:
>
> On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++
>  wrote:
> >
> > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser 
> > wrote:
> >
> > > Hi everyone!
> > >
> > > I'm working on libc++ and we are currently discussing using language
> > > extensions from later standards (
> > > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4).
> > > By that I mean things like using `if constexpr` with `-std=c++11`. GCC has
> > > quite a lot of these kinds of conforming extensions, but doesn't document
> > > them AFAICT. While discussing using these extensions, the question came up
> > > what GCCs support policy for these is. Aaron was kind enough to answer
> > > these questions for us on the Clang side. Since I couldn't find anything 
> > > in
> > > the documentation, I thought I'd ask here.
> > >
> > > So, here are my questions:
> > >
> > > Do you expect that these extensions will ever be removed for some reason?
> > > If yes, what could those reasons be?
> > >
> >
> > Potentially, if they don't actually work properly in earlier standard
> > modes.  I recently noticed that while we allow DMI and =default in C++03
> > mode with a pedwarn, combining them doesn't work.
> >
> > Some of the extensions are needed by libstdc++ and are therefore well
> > tested; these are extremely unlikely to ever be removed.  libstdc++ folks,
> > is there a list of these?
>
> We use variadic templates and long long in C++98. We use a DMI in
> __gnu_cxx::__mutex even in C++98. I don't think we unconditionally use
> anything else, because we can't rely on it being available when using
> non-GCC compilers, or when compiling with -Wsystem-headers -pedantic.
> We don't use if-constexpr before C++17 for example.

Oh, but we do use __decltype in a few places.

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

[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/08/07 7AM (GMT -7) / 10PM (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 
).

Regards,

eop Chen