Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED

a symbol lookup for (st_value==0 st_shndx==SHN_UNDEF) will bind to a STV_PROTECTED definition in a shared object, can the diagnostic be moved there? The compatibility property is per-symbol and the symbol lookup is a perfect place for a diagnostic, like a symbol versioning error. I guess GCC folks

Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED

tion in a shared > object, can the diagnostic be moved there? > The compatibility property is per-symbol and the symbol lookup is a > perfect place for a diagnostic, like a symbol versioning error. > > > I guess GCC folks may get noticed if you start a thread adding > -fsingle-global

Hongtao Liu as x86 vectorization maintainer

I am pleased to announce that the GCC Steering Committee has appointed Hongtao Liu as maintainer of the i386 vector extensions in GCC. Hongtao, please update your listing in the MAINTAINERS file. Cheers, Jason

RE: Hongtao Liu as x86 vectorization maintainer

>-Original Message- >From: Jason Merrill >Sent: Monday, June 21, 2021 10:07 AM >To: Liu, Hongtao >Cc: gcc Mailing List ; Marek Polacek >Subject: Hongtao Liu as x86 vectorization maintainer > >I am pleased to announce that the GCC Steering Committee has a

Looking for newcomer project

Hi all, I am want to contribute to GCC as a volunteer. And I am seeking the guidance on which project to select. I have build the GCC and run the test cases. I have read through GCC summer of code page and few other related documentation Currently I have no preference, I am available to any

Re: [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog)

e >> 'ranger' - removes a datastructure (no testcase but also >> does not make sense here) >> * 17a4bee01c3b29c5ccdd39f34384521e5d44135b >> Fixes an ICE for one testcase (but of course does not add >> a new testcase or modify an existing one.) >> * 76

Progress update on extending static analyser to support c++'s virtual function

so I have a good news and a bad news good news is that I was successfully able to split the calls at every call-site during the creation of super-graph. I did it by simply adding an 'else’ statement where analyser handles splitting of snodes, so that it can still handle the known calls ( one

Re: Looking for newcomer project

Really sorry, please ignore the previous mail. I am currently working on another project. Best regards, Shivam Original Message On Jun 21, 2021, 12:06 PM, Super Man wrote: > Hi all, > > I am want to contribute to GCC as a volunteer. And I am seeking the guidance &

Re: replacing the backwards threader and more

On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff. Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite of the backwards threader code. I'd like to d

Re: Hongtao Liu as x86 vectorization maintainer

On Mon, Jun 21, 2021 at 02:49:56AM +, Liu, Hongtao via Gcc wrote: > >-Original Message- > >From: Jason Merrill > >Sent: Monday, June 21, 2021 10:07 AM > >To: Liu, Hongtao > >Cc: gcc Mailing List ; Marek Polacek > >Subject: Hongtao Liu as x86

Re: Hongtao Liu as x86 vectorization maintainer

On Tue, Jun 22, 2021 at 3:58 PM Jakub Jelinek via Gcc wrote: > > On Mon, Jun 21, 2021 at 02:49:56AM +, Liu, Hongtao via Gcc wrote: > > >-Original Message- > > >From: Jason Merrill > > >Sent: Monday, June 21, 2021 10:07 AM > > >To: Liu,

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Mon, Jun 21, 2021 at 7:36 AM Michael Matz wrote: > > Hello, > > On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote: > > > > > • Disallow copy relocation against definition with the STV_PROTECTED > > > > visibility in the shared library with the marker. > >

Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper

On 6/22/21 3:30 AM, Martin Liška wrote: Hello. There's a patch candidate that comes up with a wrapper for 'git commit-mklog' alias. Using my patch, one can do: $ git commit-mklog -a -b 12345, Thoughts? Looks good to me. Can one do that without the wrapper script and passing data throu

Re: Progress update on extending static analyser to support c++'s virtual function

On Mon, 2021-06-21 at 14:22 +0530, Ankur Saini wrote: > so I have a good news and a bad news > > good news is that I was successfully able to split the calls at every > call-site during the creation of super-graph. > > I did it by simply adding an 'else’ statement where analyser handles > split

Re: Semantics of OBJ_TYPE_REF

Cool, thanks! I think I understand now. On Tue, 22 Jun 2021 at 23:58, Martin Jambor wrote: > > Hi, > > On Fri, Jun 18 2021, Erick Ochoa via Gcc wrote: > > Hi, > > > > I am having some trouble understanding the semantics of OBJ_TYPE_REF. > > I understa

Why does printing a pointer cause it to escape?

Hello, I know that some BUILT_IN functions are treated in a special way by the points-to analysis. Those functions are those that take pointers as arguments or return them but do not change their points-to set and similar cases. (E.g. strcpy returns a pointer to the same object as their first argu

Re: Why does printing a pointer cause it to escape?

On Wed, 23 Jun 2021, Martin Jambor wrote: > Hi, > > On Wed, Jun 23 2021, Erick Ochoa via Gcc wrote: > > Hello, > > > > I know that some BUILT_IN functions are treated in a special way by > > the points-to analysis. Those functions are those that take pointers &g

Re: Why does printing a pointer cause it to escape?

在 6/23/21 6:32 PM, Erick Ochoa via Gcc 写道: I notice that in these special cases, the printf function is nowhere to be found, and if one prints a pointer using printf the pointer points to escaped memory. Why is this the case? I think it is due to the incapability of ruling out the

Re: Why does printing a pointer cause it to escape?

> I guess that to assume otherwise, one would have to make sure the > pointer does not correspond to a "%n" (or similar, perhaps even future) > conversion specifier. > Oh, wow, I didn't know about the %n specifier. Thanks Martin!

Re: Why does printing a pointer cause it to escape?

Hi Liu, thanks, this also seems correct. I originally thought that (in your example) ptr would be marked as pointing to { ESCAPE NONLOCAL } and that would be enough to hinder some optimizations that might influence variable value. Therefore, it wasn't necessary to mark "value" as pointing to { ESC

daily report on extending static analyzer project [GSoC]

CURRENT STATUS : analyzer is now splitting nodes even at call sites which doesn’t have a cgraph_edge. But as now the call and return nodes are not connected, the part of the function after such calls becomes unreachable making them impossible to properly analyse. AIM for today : - try to cre

Re: replacing the backwards threader and more

On 6/21/2021 8:40 AM, Aldy Hernandez wrote: On 6/9/21 2:09 PM, Richard Biener wrote: On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote: Hi Jeff.  Hi folks. What started as a foray into severing the old (forward) threader's dependency on evrp, turned into a rewrite o

Re: daily report on extending static analyzer project [GSoC]

On Thu, 2021-06-24 at 19:59 +0530, Ankur Saini wrote: > CURRENT STATUS : > > analyzer is now splitting nodes even at call sites which doesn’t have > a cgraph_edge. But as now the call and return nodes are not > connected, the part of the function after such calls becomes > unreachable making them

RE: [EXTERNAL] Re: State of AutoFDO in GCC

ozen-Virtual-Machine:~/objdir/gcc$ dmesg | egrep -i 'pmu' [0.266474] Performance Events: PEBS fmt4+, Icelake events, 32-deep LBR, full-width counters, Intel PMU driver. 3. Ran erozen@erozen-Virtual-Machine:~/objdir/gcc$ perf record -e cpu/event=0xc4,umask=0x20/p

Re: replacing the backwards threader and more

On Thu, Jun 24, 2021 at 6:14 PM Jeff Law wrote: > > > > On 6/21/2021 8:40 AM, Aldy Hernandez wrote: > > > > > > On 6/9/21 2:09 PM, Richard Biener wrote: > >> On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc > >> wrote: > >>> > &

Re: replacing the backwards threader and more

On Fri, Jun 25, 2021 at 9:54 AM Richard Biener wrote: > > On Thu, Jun 24, 2021 at 6:14 PM Jeff Law wrote: > > > > > > > > On 6/21/2021 8:40 AM, Aldy Hernandez wrote: > > > > > > > > > On 6/9/21 2:09 PM, Richard Biener wrote: >

Does GCC have __gnuc_literal_encoding__ macro defined?

eral_encoding__ __gnuc_wide_literal_encoding__ __gnuc_literal_encoding_is_ascii_based__ __gnuc_wide_literal_encoding_is_ascii_based__ In GCC Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

Re: daily report on extending static analyzer project [GSoC]

AIM for today : - try to create an intra-procedural link between the calls the calling and returning snodes - figure out the program point where exploded graph would know about the function calls - figure out how the exploded node will know which function to call - create enodes and eedges for

Re: daily report on extending static analyzer project [GSoC]

On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: > AIM for today : > > - try to create an intra-procedural link between the calls the calling > and returning snodes > - figure out the program point where exploded graph would know about > the function calls > - figure out how the exploded nod

Re: replacing the backwards threader and more

Hi folks. I'm done with benchmarking, testing and cleanups, so I'd like to post my patchset for review. However, before doing so, I'd like to address a handful of meta-issues that may affect how I post these patches. Trapping on differences === Originally I wanted to con

Re: replacing the backwards threader and more

On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: Hi folks. I'm done with benchmarking, testing and cleanups, so I'd like to post my patchset for review.  However, before doing so, I'd like to address a handful of meta-issues that may affect how I post these patches

Re: Does GCC have __gnuc_literal_encoding__ macro defined?

GCC defines __GNUC_EXECUTION_CHARSET_NAME and __GNUC_WIDE_EXECUTION_CHARSET_NAME instead. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

Re: __fp16 is ambiguous error in C++

> foo.c:6:23: error: call of overloaded 'exp(__fp16&)' is ambiguous __fp16 isn't ambiguous, calling std::exp with an argument of that type is ambiguous, because the standard library doesn't provide an overload for that type. It could be added (probably defined to cast to float and use the overloa

Re: daily report on extending static analyzer project [GSoC]

> On 25-Jun-2021, at 9:04 PM, David Malcolm wrote: > > On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: >> AIM for today : >> >> - try to create an intra-procedural link between the calls the calling >> and returning snodes >> - figure out the program point where exploded graph would kno

Re: daily report on extending static analyzer project [GSoC]

On Sat, 2021-06-26 at 20:50 +0530, Ankur Saini wrote: > > > On 25-Jun-2021, at 9:04 PM, David Malcolm > > wrote: > > > > On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: > > > AIM for today : > > > > > > - try to create an intra-procedural link between the calls the > > > calling > > > an

Re: replacing the backwards threader and more

On 6/25/21 7:19 PM, Martin Sebor wrote: On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: Hi folks. I'm done with benchmarking, testing and cleanups, so I'd like to post my patchset for review.  However, before doing so, I'd like to address a handful of meta-issues that m

Re: replacing the backwards threader and more

current pipeline is 1.55% of overall compilation time. As is being > discussed, we should be able to mitigate this significantly by removing > other threading passes. 1.55% for the overall compilation looks quite large - is this suite particularly demanding on VRP/ranger? Is the figure for

Re: replacing the backwards threader and more

being discussed, we should be able to mitigate this significantly by removing other threading passes. 1.55% for the overall compilation looks quite large - is this suite particularly demanding on VRP/ranger? Is the figure for 'cc1files' similar? (collect preprocessed sources of gcc/*.

Re: daily report on extending static analyzer project [GSoC]

l for that case? That already gets used in some > places, so maybe try putting a breakpoint on that and see if fixing > that gets you further? shouldn’t the fn_decl should still have a cgraph_node if the function is declared in the program itself ? it should just not have an edge represent

Using source-level annotations to help GCC detect buffer overflows

level-annotations-help-gcc-detect-buffer-overflows Martin

Re: replacing the backwards threader and more

On 6/28/21 12:17 AM, Aldy Hernandez wrote: On 6/25/21 7:19 PM, Martin Sebor wrote: On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: Hi folks. I'm done with benchmarking, testing and cleanups, so I'd like to post my patchset for review.  However, before doing so, I'd lik

Re: daily report on extending static analyzer project [GSoC]

might already do most of what you need, but it looks like it bails > > out > > for the "NULL cgraph_node" case.  Maybe that needs fixing, so that > > it > > returns the fndecl for that case?  That already gets used in some > > places, so maybe try putting a brea

Re: replacing the backwards threader and more

gt; > > On 6/25/21 7:19 PM, Martin Sebor wrote: > >> On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: > >>> Hi folks. > >>> > >>> I'm done with benchmarking, testing and cleanups, so I'd like to post > >>> my patchset for re

Re: [PATCH] Port GCC documentation to Sphinx

on of the gcc manual the sidebar has an "Option index" link but no link to the general index. When you follow that link the page contents is just a link to the "index" where everything is all lumped together. If we can't have separate indexes for options and general e

Unique identifier across different partitions (LTO)

Hello, I'm trying to generate unique identifiers for some trees at link time. I understand that there are already some unique identifiers in declarations (DECL_UID) and perhaps others. Do all trees have unique identifiers or only declarations? Alternatively, if they don't have unique identifiers,

Re: Using source-level annotations to help GCC detect buffer overflows

On 6/29/21 6:27 AM, David Brown wrote: On 28/06/2021 21:06, Martin Sebor via Gcc wrote: I wrote an article for the Red Hat Developer blog about how to annotate code to get the most out of GCC's access checking warnings like -Warray-bounds, -Wformat-overflow, and -Wstringop-overflow.

Re: daily report on extending static analyzer project [GSoC]

edges instead of taking it from the calling edge. It looks something like this :- File: {$SCR_DIR}/gcc/analyzer/call-string.cc <http://call-string.cc/> 158: void 159: call_string::push_call(const return_superedge *return_sedge) 160: { 161: gcc_assert (return_sedge); 162: m_ret

Re: [PATCH] Port GCC documentation to Sphinx

> From: Martin Liška > Date: Tue, 29 Jun 2021 12:09:23 +0200 > Cc: GCC Development , gcc-patc...@gcc.gnu.org > > On 6/28/21 5:33 PM, Joseph Myers wrote: > > Are formatted manuals (HTML, PDF, man, info) corresponding to this patch > > version also available for revi

Re: [PATCH] Port GCC documentation to Sphinx

> Date: Tue, 29 Jun 2021 19:57:11 +0300 > From: Eli Zaretskii via Gcc > Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, jos...@codesourcery.com > > Or how about this: > > `Overall Options' > >See Options Controlling the Kind of Output. > >

Re: daily report on extending static analyzer project [GSoC]

t; return call ( which we don’t have ) > > so I decided to make an overload of "call_string::push_call()” which > directly takes a return_superedge and push it the underlying vector > of edges instead of taking it from the calling edge. It looks > something like this :- > &

Re: replacing the backwards threader and more

dez wrote: > > > On 6/25/21 7:19 PM, Martin Sebor wrote: >> On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: >>> Hi folks. >>> >>> I'm done with benchmarking, testing and cleanups, so I'd like to post >&

Re: replacing the backwards threader and more

On 6/30/21 12:16 AM, Martin Sebor wrote: On 6/28/21 6:32 PM, Aldy Hernandez wrote: I had changed my approach to passing -Wno-free-nonheap-object in the Makefile. Can you try disabling the Makefile bit and bootstrapping, cause that was still failing. I see.  I just tested it and my patch do

How to get the global namespace (DECL_CONTEXT) at LTO during LGEN?

Hello, I am wondering if there's a way to get the global namespace at LTO during LGEN in each of the partitions being processed. I believe that during parse time for c/c++ there is a global_namespace macro or variable that can be used, but I don't think that it is possible to use at link time. Th

Re: How to get the global namespace (DECL_CONTEXT) at LTO during LGEN?

On Wed, Jun 30, 2021 at 10:23 AM Erick Ochoa via Gcc wrote: > > Hello, > > I am wondering if there's a way to get the global namespace at LTO > during LGEN in each of the partitions being processed. I believe that > during parse time for c/c++ there is a global_namespace m

Re: [PATCH] Port GCC documentation to Sphinx

just uploaded them here: https://splichal.eu/gccsphinx-final/ Martin In the HTML version of the gcc manual the sidebar has an "Option index" link but no link to the general index.  When you follow that link the page contents is just a link to the "index" where everythin

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Wed, 30 Jun 2021 12:11:03 +0200 > > > (Admittedly, Emacs by default hides some of the text of a > > cross-reference, but not hiding them in this case produces an ev

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Wed, 30 Jun 2021 15:28:40 +0200 > > >‘@`file'’ > > > > Read command-line options from ‘`file'’. The options read are > > inse

Are DECL_UIDs for the same across partitions during LGEN?

. That is, a single global variable has different DECL_UIDs in different partitions. Is this the correct behaviour? My understanding of DECL_UID is that for every declaration there is a unique identifier, but is this not the case during LTO? I am building a transformation on top of releases/gcc-11

Re: Are DECL_UIDs for the same across partitions during LGEN?

On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc wrote: >Hi, > >I am still working on understanding the LTO framework and how the >gimple representation works across multiple partitions. I found myself >printing all global variables and printing their DECL_UID. I noticed

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Wed, 30 Jun 2021 16:04:32 +0200 > > > Thanks, but does that mean @var will no longer stand out in the > > produced Info format? That'd be sub-optimal, I think, becau

Re: Are DECL_UIDs for the same across partitions during LGEN?

On Wed, 30 Jun 2021 at 17:06, Richard Biener wrote: > > On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc > wrote: > >Hi, > > > >I am still working on understanding the LTO framework and how the > >gimple representation works across multiple partition

Re: Using source-level annotations to help GCC detect buffer overflows

On 6/29/21 12:31 PM, David Brown wrote: On 29/06/2021 17:50, Martin Sebor wrote: On 6/29/21 6:27 AM, David Brown wrote: On 28/06/2021 21:06, Martin Sebor via Gcc wrote: I wrote an article for the Red Hat Developer blog about how to annotate code to get the most out of GCC's access che

Re: daily report on extending static analyzer project [GSoC]

On Wed, 2021-06-30 at 21:39 +0530, Ankur Saini wrote: > > > > On 30-Jun-2021, at 1:23 AM, David Malcolm > > wrote: > > > > On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote: > > [...] > > > P.S. it has been over a week since I sent a mail to    > > > overse...@gcc.gnu.org 

Re: Are DECL_UIDs for the same across partitions during LGEN?

On June 30, 2021 6:28:29 PM GMT+02:00, Erick Ochoa wrote: >On Wed, 30 Jun 2021 at 17:06, Richard Biener > wrote: >> >> On June 30, 2021 4:07:00 PM GMT+02:00, Erick Ochoa via Gcc > wrote: >> >Hi, >> > >> >I am still working on understanding the LTO

How to dump_decl_name to a string instead to a file?

Hello, I have a function that looks at identifiers of formal parameters. I found that when I ran this function on larger projects, the compiler segfaulted. I looked into this and I found that there are some formal parameters which have NULL in their DECL_NAME and that triggered a NULL dereference.

Re: How to dump_decl_name to a string instead to a file?

On Thu, Jul 1, 2021 at 9:40 AM Erick Ochoa via Gcc wrote: > > Hello, > > I have a function that looks at identifiers of formal parameters. I > found that when I ran this function on larger projects, the compiler > segfaulted. I looked into this and I found that there are some f

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Thu, 1 Jul 2021 14:44:10 +0200 > > > It helps some, but not all of the issues disappear. For example, > > stuff like this is still hard to read: > > > >

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Thu, 1 Jul 2021 16:14:30 +0200 > > >> If I understand the notes correct, the '.' should be also hidden by e.g. > >> Emacs. > > > >

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Thu, 1 Jul 2021 18:04:24 +0200 > > > Emacs doesn't hide the period. But there shouldn't be a period to > > begin with, since it's the middle of a sentenc

Re: Question on tree LIM

On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote: > > Hi, > > I am investigating one degradation related to SPEC2017 exchange2_r, > with loop vectorization on at -O2, it degraded by 6%. By some > isolation, I found it isn't directly caused by vectorization i

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > From: Martin Liška > Date: Fri, 2 Jul 2021 11:30:02 +0200 > > > So the purpose of having the comma there is to avoid having a period > > in the middle of a sentence, which is added by makeinfo (beca

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: Eli Zaretskii , gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, > jos...@codesourcery.com > From: Martin Liška > Date: Fri, 2 Jul 2021 11:40:06 +0200 > > > It must > > look sensible without that. In this case it seems that already the > > generated .texinfo inp

Re: Question on tree LIM

On Fri, Jul 2, 2021 at 11:05 AM Kewen.Lin wrote: > > Hi Richard, > > on 2021/7/2 下午4:07, Richard Biener wrote: > > On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote: > >> > >> Hi, > >> > >> I am investigating one degradation related to

Re: daily report on extending static analyzer project [GSoC]

r me, it looks like maybe just tracking gcalls is not enough, or maybe I don’t know enough about the stuff I can access from from the gcalls ( I am currently looking into gcc/gimple.c for the all the possible actions I can take with a gimple statement ) STATUS AT THE END OF THE DAY :- - find

ubsan built-in function types

Most sanitizer built-in argument types are all of pointer types. For example: BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS as BT_FN_VOID_PTR_PTR_PTR or BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE as BT_FN_VOID_PTR_PTR. But some calls to these functions are made with some arguments of int

Re: daily report on extending static analyzer project [GSoC]

AIM for today : - update the call_stack to track something else other than supergraph edges — PROGRESS : - After some brainstorming about tracking the callstack, I think one better way to track the call stack is to keep track of source and destination of the call instead of supperedges repre

Re: [PATCH] Port GCC documentation to Sphinx

Hans-Peter Nilsson writes: > I've read the discussion downthread, but I seem to miss (a recap > of) the benefits of moving to Sphinx. Maybe other have too and > it'd be a good idea to repeat them? Otherwise, the impression > is not so good, as all I see is bits here and there getting lost > in t

Re: ubsan built-in function types

On Fri, Jul 2, 2021 at 6:33 PM Martin Sebor via Gcc wrote: > > Most sanitizer built-in argument types are all of pointer types. > For example: > >BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS > as >BT_FN_VOID_PTR_PTR_PTR > > or > >BUILT_IN_UBSAN_H

Re: [PATCH] Port GCC documentation to Sphinx

> From: Richard Sandiford > Cc: Eli Zaretskii , gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, > jos...@codesourcery.com > Date: Mon, 05 Jul 2021 10:17:38 +0100 > > Hans-Peter Nilsson writes: > > I've read the discussion downthread, but I seem to miss (a recap >

Re: [PATCH] Port GCC documentation to Sphinx

Eli Zaretskii writes: >> Hans-Peter Nilsson writes: >> > I've read the discussion downthread, but I seem to miss (a recap >> > of) the benefits of moving to Sphinx. Maybe other have too and >> > it'd be a good idea to repeat them? Otherwise, the impression >> > is not so good, as all I see is b

Re: daily report on extending static analyzer project [GSoC]

function called without the superedge - make the analyser figure out the correct point to return back in the caller function - make enode and eedge representing the return call - test the changes on the example I created before - speculate what GCC generates for a vfunc call and discuss how can we use

where is PRnnnn required again?

lized at declaration si te PR middle-end/98512 - #pragma GCC diagnostic ignored ineffective in conjunct ion with alias attribute gcc/ChangeLog: * diagnostic.c (get_any_inlining_info): New. (update_effective_level_from_pragmas): Handle inlining

Re: where is PRnnnn required again?

On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: > I came away from the recent discussion of ChangeLogs requirements > with the impression that the PR bit should be in the subject > (first) line and also above the ChangeLog part but doesn't need > to be

Re: where is PRnnnn required again?

On 7/6/21 3:36 PM, Marek Polacek wrote: On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: I came away from the recent discussion of ChangeLogs requirements with the impression that the PR bit should be in the subject (first) line and also above the ChangeLog part but

Re: where is PRnnnn required again?

On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, wrote: > On 7/6/21 3:36 PM, Marek Polacek wrote: > > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: > >> I came away from the recent discussion of ChangeLogs requirements > >> with the impression th

Re: daily report on extending static analyzer project [GSoC]

On Sat, 2021-07-03 at 20:07 +0530, Ankur Saini wrote: > AIM for today : > > - update the call_stack to track something else other than supergraph > edges > > — > > PROGRESS : > > - After some brainstorming about tracking the callstack, I think one > better way to track the call stack is to kee

Re: daily report on extending static analyzer project [GSoC]

On Tue, 2021-07-06 at 18:46 -0400, David Malcolm wrote: > On Sat, 2021-07-03 at 20:07 +0530, Ankur Saini wrote: > > AIM for today : > > > > - update the call_stack to track something else other than > > supergraph > > edges > > > > — > > > > PROGRESS : > > > > - After some brainstorming about

Re: daily report on extending static analyzer project [GSoC]

changes on the example I created before > - speculate what GCC generates for a vfunc call and discuss how can we > use it to our advantage > > — > > PROGRESS  ( changes can be seen on > "refs/users/arsenic/heads/analyzer_extension “ branch of the repository > ) : >

GCC arc port defaults to -fcommon

It seems to me that the arc port still defaults to -fcommon, presumably due to this in gcc/common/config/arc/arc-common.c: static void arc_option_init_struct (struct gcc_options *opts) { opts->x_flag_no_common = 255; /* Mark as not user-initialized. */ /* Which cpu we're compi

tree decl stored during LGEN does not map to a symtab_node during WPA

Hi, I am saving some tree declarations during LGEN that I will be later analyzing at WPA time. I am able to read the decl from my summaries and print it at WPA time. It corresponds to a global variable. However, whenever I use symtab_node::get (decl) during WPA time I keep getting NULL. Does anyo

Re: GCC arc port defaults to -fcommon

On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc wrote: > > It seems to me that the arc port still defaults to -fcommon, presumably > due to this in gcc/common/config/arc/arc-common.c: > > static void > arc_option_init_struct (struct gcc_options *opts) > { > opts

Re: GCC arc port defaults to -fcommon

On Wed, Jul 7, 2021 at 11:56 AM Richard Biener wrote: > > On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc > wrote: > > > > It seems to me that the arc port still defaults to -fcommon, presumably > > due to this in gcc/common/config/arc/arc-co

Re: GCC arc port defaults to -fcommon

* Richard Biener: > On Wed, Jul 7, 2021 at 11:56 AM Richard Biener > wrote: >> >> On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc >> wrote: >> > >> > It seems to me that the arc port still defaults to -fcommon, presumably >> >

Re: GCC arc port defaults to -fcommon

ener Sent: Wednesday, July 7, 2021 12:58 PM To: Florian Weimer Cc: GCC Development ; Joern Wolfgang Rennecke ; Claudiu Zissulescu Subject: Re: GCC arc port defaults to -fcommon On Wed, Jul 7, 2021 at 11:56 AM Richard Biener wrote: > > On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer v

Re: GCC arc port defaults to -fcommon

Hi, I have quickly tested the next patch, and it looks like everything is alright. In the end we don't really need to temper with fcommon. diff --git a/gcc/common/config/arc/arc-common.c b/gcc/common/config/arc/arc-common.c index 6a1190296167..3b36d09997c7 100644 --- a/gcc/common/confi

Re: daily report on extending static analyzer project [GSoC]

> > auto_vec m_supernodes; > > or > > auto_vec m_elements; > > within the call_string, if that makes sense. Does that simplify > things? Yes, this is a nice idea, I will update the call-stack with next update to the analyzer, or should I update it and send a patch to the mailing list with this call_string changes for review first and then work on the other changes ? also regarding the ChangeLog how exactly does one update the changelog, does it get updated with the commit messages or do one have to update it manually ? I found and read this doc (https://gcc.gnu.org/codingconventions.html#ChangeLogs <https://gcc.gnu.org/codingconventions.html#ChangeLogs>) about the same which says that “ ChangeLog entries are part of git commit messages and are automatically put into a corresponding ChangeLog file “. But when I pushed the commits which looks properly formatted to me, I was not able to see the changes reflecting back in gcc/analyzer/changelog . > > Dave Thanks - Ankur Saini

Re: daily report on extending static analyzer project [GSoC]

ng at it in the repository. One benefit is that other list subscribers (and archive readers) can easily see the code we're discussing; this will become more significant as we go into the ipa- devirt code which wasn't written by me. That said, one benefit of having your own branch is so

Re: where is PRnnnn required again?

On 7/6/21 4:09 PM, Jonathan Wakely wrote: On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, <mailto:gcc@gcc.gnu.org>> wrote: On 7/6/21 3:36 PM, Marek Polacek wrote: > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: >> I came away from the

Re: where is PRnnnn required again?

On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: > I came away from the recent discussion of ChangeLogs requirements > with the impression that the PR bit should be in the subject > (first) line and also above the ChangeLog part but doesn't need > to be

Re: where is PRnnnn required again?

On 7/7/21 11:51 AM, Jakub Jelinek wrote: On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: I came away from the recent discussion of ChangeLogs requirements with the impression that the PR bit should be in the subject (first) line and also above the ChangeLog part but

<    36   37   38   39   40   41   42   43   44   45   >