Need help with Proc compilation with GCC 4.8.3

[Kondreddy, Vinay Kumar via Gcc]

Hi Team,

We are using GCC 4.8.3 for one of our legacy applications i.e: Automatch. after 
database upgrade from 11/2 to 19.0.0, while recompiling one of our proc program 
we are getting below error. Could you please help us to resolve below issue. 
Please find full error trace in above attachment.

Also could you please provide any URL or website to download proper GCC along 
with their dependencies as we are not able to find all dependencies at one 
place.

Error:-
amatch@autd1db01 $ make -f PushOfPayables.mk
/ORACLE/app/oracle/product/19.0.0/dbhome_1/bin/proc SQLCHECK=SEMANTICS 
mode=oracle ireclen=120  userid=am_user/steve7 DEFINE=__64BIT__ /usr/include/  
iname=/app/amatch/tst/code/src/proc/PushOfPayables.pc  
oname=/app/amatch/tst/code/src/c/PushOfPayables.c

Pro*C/C++: Release 19.0.0.0.0 - Production on Wed Feb 22 09:54:42 2023
Version 19.15.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

System default option values taken from: 
/ORACLE/app/oracle/product/19.0.0/dbhome_1/precomp/admin/pcscfg.cfg

/usr/bin/gcc -c -o /app/amatch/tst/code/obj/PushOfPayables.o -maix64  
/usr/include/  /app/amatch/tst/code/include  
-I/ORACLE/app/oracle/product/19.0.0/dbhome_1/precomp/public 
-I/app/amatch/tst/code/include /app/amatch/tst/code/src/c/PushOfPayables.c
In file included from /usr/include/sys/resource.h:57:0,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/wait.h:62,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdlib.h:349,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:181:
/usr/include/sys/time.h:110:16: error: redefinition of 'struct sigset_t'
typedef struct sigset_t {
^
In file included from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdio.h:479:0,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:180:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/types.h:345:16:
 note: originally defined here
typedef struct sigset_t {
^
In file included from /usr/include/sys/resource.h:57:0,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/wait.h:62,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdlib.h:349,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:181:
/usr/include/sys/time.h:126:3: error: conflicting types for 'sigset_t'
} sigset_t;
   ^

Thanks & Regards,
Vinay Kumar
amatch@autd1db01 $ make -f PushOfPayables.mk
/ORACLE/app/oracle/product/19.0.0/dbhome_1/bin/proc SQLCHECK=SEMANTICS 
mode=oracle ireclen=120  userid=am_user/steve7 DEFINE=__64BIT__ /usr/include/  
iname=/app/amatch/tst/code/src/proc/PushOfPayables.pc  
oname=/app/amatch/tst/code/src/c/PushOfPayables.c

Pro*C/C++: Release 19.0.0.0.0 - Production on Wed Feb 22 09:54:42 2023
Version 19.15.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

System default option values taken from: 
/ORACLE/app/oracle/product/19.0.0/dbhome_1/precomp/admin/pcscfg.cfg

/usr/bin/gcc -c -o /app/amatch/tst/code/obj/PushOfPayables.o -maix64  
/usr/include/  /app/amatch/tst/code/include  
-I/ORACLE/app/oracle/product/19.0.0/dbhome_1/precomp/public 
-I/app/amatch/tst/code/include /app/amatch/tst/code/src/c/PushOfPayables.c
In file included from /usr/include/sys/resource.h:57:0,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/wait.h:62,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdlib.h:349,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:181:
/usr/include/sys/time.h:110:16: error: redefinition of 'struct sigset_t'
 typedef struct sigset_t {
^
In file included from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdio.h:479:0,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:180:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/types.h:345:16:
 note: originally defined here
 typedef struct sigset_t {
^
In file included from /usr/include/sys/resource.h:57:0,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/wait.h:62,
 from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdlib.h:349,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:181:
/usr/include/sys/time.h:126:3: error: conflicting types for 'sigset_t'
 } sigset_t;
   ^
In file included from 
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/stdio.h:479:0,
 from /app/amatch/tst/code/src/c/PushOfPayables.c:180:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.3/include-fixed/sys/types.h:361:3:
 note: previous declaration of 'sigset_t' was here
 } sigset_t;
   ^
/app/amatch/tst/code/src/c/PushOfPayables.c:190:0:

Re: [GSoC][Static Analyzer] Ideas for proposal

[David Malcolm via Gcc]

On Tue, 2023-02-28 at 15:46 +0100, Shengyu Huang wrote:
> Hi Dave,
> 
> > On 22 Feb 2023, at 15:11, Shengyu Huang 
> > wrote:
> > 
> > > But a better place to look would probably be in our bugzilla; see
> > > the
> > > links on the wiki page:
> > >  https://gcc.gnu.org/wiki/StaticAnalyzer 
> > > The "open bugs" list currently has 41 "RFE" bugs ("request for
> > > enhancement" i.e. ideas for new features), some of which might
> > > make
> > > suitable GSoC ideas, and/or be of interest to you (ideally both!)
> > > 
> > > Also, the GSoC wiki page has some project ideas:
> > >  https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas
> > > 
> > 
> > Yeah I was also searching for interesting ideas on the bugzilla,
> > and I will communicate to you once I have any more concrete ideas.
> 
> I spent some time searching through Bugzilla this weekend while
> familiarizing with the analyzer internals, and I found the following
> things interesting, and it’d be great if you can give me some
> preliminary feedback:

Great; thanks.

> 
> 1. I am not sure why we added the class
> `shift_count_negative_diagnostic` in region-model.cc
> , because there is a similar warning issued
> from c/c-typeck.cc , and when I compiled with -
> fanalyzer that has the code `b = b << -1`, I got two warnings that
> mean the same thing. 

The analyzer works based on execution paths, and so can potentially
find more things that a purely AST-based approach.  That said, I'm not
happy with the signal:noise ratio of that analyzer warning; maybe it
needs some tuning?

> Maybe interestingly, when I compiled my test case with -O2, I got the
> warning from -Wshift-count-negative but not from -Wanalyzer-shift-
> count-negative. Would it be considered as a false negative for the
> analyzer? 

The analyzer runs relatively late compared to most analyzers, on the
gimple-ssa representation after some optimizations have already run, so
that's probably why you didn't get the warning at -O2.

> 
> 2. Something related to 1. is PR98447
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447)


> 
> 3. PR104955 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955)
> still takes a long without -Wno-analyzer-double-free. I’d be
> interested in further investigating the problem (probably as you said
> sharing one feasible_graph can fix the problem).

That one involves deep surgery that could affect every analyzer
warning, so I'm worried that it could turn out to be too hard to do as
a first project on the analyzer.  Also, some warnings that have grown a
pending_diagnostic::check_valid_fpath_p vfunc since I wrote that
comment, which could complicate the implementation :-/

> 
> 4. What’s the most interesting to me are PR103533
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533),

Turning on taint detection by default would be a great project.  It
would be good to run the integration tests:
  https://github.com/davidmalcolm/gcc-analyzer-integration-tests
to see if anything regresses, or if it adds noise - so this might be a
bit of an open-ended project, in that we'd want to fix whatever issues
show up there, as well as the known ones that are documented in that
bug.


>  PR104940 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940)

I've actually been prototyping SMT solver support in a private branch,
but based on writing out SMT-LIB scripts and invoking z3 as a
subprocess, and parsing the results, which is much slower than it could
be, as I'm reevaluating all the constraints as each one is added,
rather than using an API and sharing/pushing/popping state.

Taking my SMT prototype and turning it into something usable could be a
good project, I think.  I'll look at posting what I've got somewhere
public if you're interested.

> because I focus on formal methods in my university studies, and I’m
> currently looking into Dafny internals for my semester project.
> 
> 5. PR105891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105891)
> seems fitted to get started during the project phase, or be used as a
> warm-up before the official project phase.

Yeah, but probably would only count as part of full GSoC project.  Last
year Tim Lange did a highly successful GSoC project on the analyzer
which was a grab-bag of adding various new warnings, each of which
wasn't quite a full project.

Could be a good warmup; though I wonder what would show up when running
it on real world C examples (e.g. via my integration test suite).

> 
> 6. PR106147 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147)
> says you are implementing a prototype already, so I guess I’ll leave
> it out, but I am also quite interested in this analysis. 

GCC 13 has the infinite recursion detection, but I didn't get the
infinite loop detection ready before feature freeze.

If you're interested, I can post my prototype of the latter if you or
someone else wants to take it up and finish it.

> At a glimpse I am not quite sure why infinite recursion and infini

Re: [GSoC][Static Analyzer] Some questions and request for a small patch to work on

[David Malcolm via Gcc]

On Tue, 2023-02-28 at 10:18 +0100, Shengyu Huang wrote:
> Hi Dave,
> 
> Do you want me to follow the steps 7-10
> (https://gcc-newbies-guide.readthedocs.io/en/latest/how-to-improve-th
> e-location-of-a-diagnostic.html) or tell you where I add the code
> simply? Basically, I added
> 
> warning_at (DECL_SOURCE_LOCATION (node->decl), 0, "hello world, I’m
> compiling %qE", node->decl);
> 
> to the loop of cgraph_node inside impl_run_checkrs (logger *logger)
> of analyzer/engine.cc . 
> 
> (I also tried adding this code to cgraph_node::cgraphunit.cc
>  in cgraphunit.cc , and
> then I found out the warning_at is different in that scope…but inform
> would work.)

Did you get it to output your messages?

The next thing to do might be to try stepping through the code in the
debugger; that's often a good way to learn about a new codebase.  See:
  https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html
and maybe have a look at the support scripts mentioned on that page.


BTW, are you building trunk, or GCC 12?  I've made a *lot* of changes
to the analyzer in trunk, so it would be good for you to be working
with something that's reasonably up-to-date.

> 
> Best,
> Shengyu
> 
> P.S. Shall I continue put mailing list in my cc? Not sure the
> community wants to receive that many GSoC related emails.

I'd prefer to keep the mailing list involved in the conversation, as
other new contributors to GCC might find the info useful, and other
existing GCC contributors might have input on some of the discussion.

Thanks
Dave

> 
> > On 22 Feb 2023, at 16:43, David Malcolm 
> > wrote:
> > 
> > Sorry, I was unclear; I was referring to this part of my guide:
> > https://gcc-newbies-guide.readthedocs.io/en/latest/getting-started.html#hello-world-from-the-compiler
> > 
> > i.e. try writing a new warning that simply emits something like:
> > 
> > test.c:2:1: warning: hello world, I'm compiling 'main'
> >    2 | int main ()
> >  | ^~~~
> > 
> > for each function that it sees.
> 

Re: GSOC 2023 Contribution Request

[Patrick Palka via Gcc]

Hi Kritika,

On Wed, Feb 22, 2023 at 6:49 AM Kritika Rag via Gcc  wrote:
>
> Hello Everyone!
>
> I’m Kritika Rag, a Computer Science pre-final year undergraduate
> student from India. I’m quite passionate about web development and
> competitive programming and now I’m looking forward to contributing to
> open-source projects. I believe that GSOC 2023 would provide me with
> the best way to start my open-source contribution journey. Since I’m a
> competitive programmer, I have excellent command over Data Structures
> & Algorithms and my primary language is C++, so C++ and GCC are
> something that I use daily, therefore I would love to make my
> contributions to GCC projects. I sincerely hope that this community
> will provide me with the opportunity to do so and to work alongside
> them.

Great, thanks for your interest in contributing to GCC, and welcome!

>
>
> I’m proficient in various coding languages like C/C++, HTML, CSS,
> JavaScript, React, and Python, and have experimented with Git, Linux,
> APIs, etc. I have also been fortunate enough to secure 3 internships,
> 2 as a DSA problem setter and 1 as a research intern. I have also
> participated in a few open-source programs like Hack October Fest 2022
> and GWoC 2022 and contributed to web development and data science
> projects.
>
> I had been checking up on recent project proposals listed in GCC wiki
> for the past 3 weeks and was interested in working either on the
> project which aims to improve the utility routine library used by GCC
> or related to Bug Patrol especially analyzing failing test cases (this
> was present over the site a while ago but now I can't see it anywhere)
> so I just wanted to ask can I choose it as my GSoC 2023 project? If
> yes can anyone guide me to whom to connect to discuss it?
>
> And if I can't work on the above ideas then I have also gone through
> the selected project ideas and want to work on the project "Implement
> comp built-in traits for the standard library traits" so would be
> grateful if anyone could guide me here also.

I can't speak about the other projects, but I'm listed as the mentor
for the built-in C++ trait project idea.

On the frontend side most of the existing built-in traits are tabulated in
gcc/cp/cp-trait.def, and their logic is defined in finish_trait_type
or finish_trait_expr in gcc/cp/semantics.cc[2], and on library side the traits
are conditionally used in the standard type trait definitions in
libstdc++, e.g. std::remove_cv[3].

Take a look at the following commits that define (and add tests for)
the built-in traits __remove_cv, __remove_reference and __remove_cvref
and subsequently use them in libstdc++. Note that this first commit
predates the new gcc/cp/cp-trait.def file which streamlined much of
the boilerplate of adding a new built-in trait.  In the new approach
(that you would be using), only the semantics.cc change (which defines
their logic) would be needed, alongside additions to cp-trait.def to
declare each trait.
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ca147154074a0de548138b4e73477e94903a855
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ddbbbffbb5759a6c1d56c191364a6bd021f733e

If you haven't already I'd recommend going through the GCC for new
contributors guide
https://gcc-newbies-guide.readthedocs.io/en/latest/index.html which
goes through checking out, building and debugging GCC.
Let me know if you have any questions :)

[1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cp-trait.def
[2]: 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/semantics.cc;h=79b7cc72f212cef780a3eea65af2b883bb4ec3c8;hb=HEAD#l12102
[3]: 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/type_traits;h=2bd607a8b8ff52aba6fd205ab1af2bc4b92f78d0;hb=HEAD#l1539


>
> Thank you so much and I hope to hear from you soon.
>

Re: [GSoC][C++: Compiler Built-in Traits]: Example Impls & Small Patches

[Patrick Palka via Gcc]

Hi Ken,

On Mon, Feb 27, 2023 at 5:02 PM Ken Matsui via Gcc  wrote:
>
> Hi,
>
> My name is Ken Matsui. I am highly interested in contributing to the
> project idea, "C++: Implement compiler built-in traits for the
> standard library traits." To understand how to implement those traits,
> could you please give me some example implementations of the compiler
> built-in traits, as well as some recommended traits to get started
> with making small patches?

Awesome, thanks for your interest in this project, and welcome!

Most of the existing built-in traits are tabulated in
gcc/cp/cp-trait.def, and their logic is defined in finish_trait_type
or finish_trait_expr in gcc/cp/semantics.cc[2], and then the traits
are conditionally used in the standard type trait definitions in
libstdc++, e.g. std::remove_cv[3].

Take a look at the following commits that define (and add tests for)
the built-in traits __remove_cv, __remove_reference and __remove_cvref
and subsequently use them in libstdc++. Note that this first commit
predates the new gcc/cp/cp-trait.def file which streamlined much of
the boilerplate of adding a new built-in trait.  In the new approach
(that you would be using), only the semantics.cc change (which defines
their logic) would be needed, alongside additions to cp-trait.def to
declare each trait.
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ca147154074a0de548138b4e73477e94903a855
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ddbbbffbb5759a6c1d56c191364a6bd021f733e

To get started, I'd recommend implementing bulit-in traits for
std::remove_pointer, std::add_pointer and std::is_reference[4].  Let
me know if you have any questions :)

[1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cp-trait.def
[2]: 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/semantics.cc;h=79b7cc72f212cef780a3eea65af2b883bb4ec3c8;hb=HEAD#l12102
[3]: 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/type_traits;h=2bd607a8b8ff52aba6fd205ab1af2bc4b92f78d0;hb=HEAD#l1539
[4]: As specified in https://en.cppreference.com/w/cpp/header/type_traits

>
> Also, I would appreciate receiving the contact information for the
> project mentor, Patrick Palka.
>
> Sincerely,
> Ken Matsui

Re: [GSoC][Static Analyzer] Ideas for proposal

[Shengyu Huang via Gcc]

Hi Dave,

> On 22 Feb 2023, at 15:11, Shengyu Huang  wrote:
> 
>> But a better place to look would probably be in our bugzilla; see the
>> links on the wiki page:
>>  https://gcc.gnu.org/wiki/StaticAnalyzer 
>> The "open bugs" list currently has 41 "RFE" bugs ("request for
>> enhancement" i.e. ideas for new features), some of which might make
>> suitable GSoC ideas, and/or be of interest to you (ideally both!)
>> 
>> Also, the GSoC wiki page has some project ideas:
>>  https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas
>> 
> 
> Yeah I was also searching for interesting ideas on the bugzilla, and I will 
> communicate to you once I have any more concrete ideas.

I spent some time searching through Bugzilla this weekend while familiarizing 
with the analyzer internals, and I found the following things interesting, and 
it’d be great if you can give me some preliminary feedback:

1. I am not sure why we added the class `shift_count_negative_diagnostic` in 
region-model.cc , because there is a similar warning 
issued from c/c-typeck.cc , and when I compiled with 
-fanalyzer that has the code `b = b << -1`, I got two warnings that mean the 
same thing. Maybe interestingly, when I compiled my test case with -O2, I got 
the warning from -Wshift-count-negative but not from 
-Wanalyzer-shift-count-negative. Would it be considered as a false negative for 
the analyzer? 

2. Something related to 1. is PR98447 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447)

3. PR104955 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955) still takes a 
long without -Wno-analyzer-double-free. I’d be interested in further 
investigating the problem (probably as you said sharing one feasible_graph can 
fix the problem).

4. What’s the most interesting to me are PR103533 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533), PR104940 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940) because I focus on formal 
methods in my university studies, and I’m currently looking into Dafny 
internals for my semester project.

5. PR105891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105891) seems fitted 
to get started during the project phase, or be used as a warm-up before the 
official project phase.

6. PR106147 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147) says you are 
implementing a prototype already, so I guess I’ll leave it out, but I am also 
quite interested in this analysis. At a glimpse I am not quite sure why 
infinite recursion and infinite loop should be treated differently (maybe it’ll 
become clearer to me once I am more familiar with the internals). In addition, 
a simple function that looks like this

void re (int c)
{
  if (c > 0)
re (c + 1);
  else
re (1);
}

can also be concluded as infinite recursion because there is no base case in 
all possible paths.

7. Other PRs that interest me: PR106006 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106006) and PR107017 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017, already mentioned in the 
GSoC page).

Best,
Shengyu

Re: [GSoC][C++: Implement compiler built-in traits for the standard library traits]

[Jonathan Wakely via Gcc]

On Tue, 28 Feb 2023 at 10:58, Berke Yavas via Gcc  wrote:
>
> Hi,
>
> I am Berke. I am interested in the project C++: Implement compiler built-in
> traits for the standard library traits for the upcoming GSoC. I am a
> Software Engineer with a year of experience. I am very excited to have a
> chance to work on gcc.

Great, thanks for your interest in the project.

> So far, I have built gcc from source, runned tests. Have a few follow up
> questions.
>
> 1. Project is related with C++ frontend and library development, so during
> the development there should be no issue configuring with
> --disable-bootstrap --disable-multilib --disablelibstdcxx-pch(Thanks to irc
> folks who suggested the latter 2, I just wanted to confirm) right?

That's fine.

> 2. Is there any other built-in compiler traits that are not in the file
> `gcc/cp/cp-trait.def`?
> 3. __is_same built in is already used in a couple of places in libstdc++.
>
> File: libstdc++-v3/include/bits/c++config
>840 #if _GLIBCXX_HAS_BUILTIN(__is_same)
> 841 #  define _GLIBCXX_HAVE_BUILTIN_IS_SAME 1
> 842 #endif
>
> Is this the file where gcc checks if the compiler built in is available? So
> other compiler built-ins should be checked here too?

No, that's old code that's done differently for historical reasons.
For new built-ins you can just use __has_builtin instead. There are
lots of examples of using that in .

[GSoC][C++: Implement compiler built-in traits for the standard library traits]

[Berke Yavas via Gcc]

Hi,

I am Berke. I am interested in the project C++: Implement compiler built-in
traits for the standard library traits for the upcoming GSoC. I am a
Software Engineer with a year of experience. I am very excited to have a
chance to work on gcc.

So far, I have built gcc from source, runned tests. Have a few follow up
questions.

1. Project is related with C++ frontend and library development, so during
the development there should be no issue configuring with
--disable-bootstrap --disable-multilib --disablelibstdcxx-pch(Thanks to irc
folks who suggested the latter 2, I just wanted to confirm) right?
2. Is there any other built-in compiler traits that are not in the file
`gcc/cp/cp-trait.def`?
3. __is_same built in is already used in a couple of places in libstdc++.

File: libstdc++-v3/include/bits/c++config
   840 #if _GLIBCXX_HAS_BUILTIN(__is_same)
841 #  define _GLIBCXX_HAVE_BUILTIN_IS_SAME 1
842 #endif

Is this the file where gcc checks if the compiler built in is available? So
other compiler built-ins should be checked here too?

I will prepare a draft of the proposal and send it here for review as soon
as possible.

Best regards,
Berke

Re: [GSoC][Static Analyzer] Some questions and request for a small patch to work on

[Shengyu Huang via Gcc]

Hi Dave,

Do you want me to follow the steps 7-10 
(https://gcc-newbies-guide.readthedocs.io/en/latest/how-to-improve-the-location-of-a-diagnostic.html)
 or tell you where I add the code simply? Basically, I added

warning_at (DECL_SOURCE_LOCATION (node->decl), 0, "hello world, I’m compiling 
%qE", node->decl);

to the loop of cgraph_node inside impl_run_checkrs (logger *logger) of 
analyzer/engine.cc . 

(I also tried adding this code to cgraph_node::cgraphunit.cc 
 in cgraphunit.cc , and then I 
found out the warning_at is different in that scope…but inform would work.)

Best,
Shengyu

P.S. Shall I continue put mailing list in my cc? Not sure the community wants 
to receive that many GSoC related emails.

> On 22 Feb 2023, at 16:43, David Malcolm  wrote:
> 
> Sorry, I was unclear; I was referring to this part of my guide:
> https://gcc-newbies-guide.readthedocs.io/en/latest/getting-started.html#hello-world-from-the-compiler
> 
> i.e. try writing a new warning that simply emits something like:
> 
> test.c:2:1: warning: hello world, I'm compiling 'main'
>2 | int main ()
>  | ^~~~
> 
> for each function that it sees.