Re: A value number issue

Richard, OK, all that I've gotten so far out of the dump file is that the name of "_920" is just something sccvn concocted and wasn't something I accidentally caused. That still leaves me with the question of what is going on. Here's all the interesting bits of the dumpfile concerning dedangled_

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

On Thu, 2021-07-22 at 22:40 +0530, Ankur Saini wrote: > AIM FOR TODAY: > > - Add custom edge info to the eedges created for dynamically > discovered calls > - Add the custom events to be showing in diagnostics > - update call_event and return_event to also work for the cases where > there is no u

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

On Wed, 2021-07-21 at 21:44 +0530, Ankur Saini wrote: > > > > On 17-Jul-2021, at 2:57 AM, David Malcolm > > wrote: > > > > On Fri, 2021-07-16 at 21:04 +0530, Ankur Saini wrote: > > > > > > > > > > On 15-Jul-2021, at 4:53 AM, David Malcolm > > > > wrote: > > > > > > > > On Wed, 2021-07-14 at

gcc-9-20210722 is now available

Snapshot gcc-9-20210722 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210722/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: gcc plugin on MacOS failure

> On 22 Jul 2021, at 20:41, Andrew Pinski via Gcc wrote: > > On Thu, Jul 22, 2021 at 7:37 AM Marc wrote: >> >> I have a gcc plugin (for afl++, >> https://github.com/AFLplusplus/AFLplusplus) that works fine when >> compiled on Linux but when compiled on MacOS (brew install gcc) it fails: >>

Re: gcc plugin on MacOS failure

On Thu, Jul 22, 2021 at 7:37 AM Marc wrote: > > Hi, > > I have a gcc plugin (for afl++, > https://github.com/AFLplusplus/AFLplusplus) that works fine when > compiled on Linux but when compiled on MacOS (brew install gcc) it fails: > > ~/afl++ $ g++-11 -g -fPIC -std=c++11 > -I/usr/local/Cellar/gcc/

Re: gcc plugin on MacOS failure

Hi Marc, > On 22 Jul 2021, at 15:34, Marc wrote: > I have a gcc plugin (for afl++, > https://github.com/AFLplusplus/AFLplusplus) that works fine when > compiled on Linux but when compiled on MacOS (brew install gcc) it fails: > > ~/afl++ $ g++-11 -g -fPIC -std=c++11 > -I/usr/local/Cellar/gcc/1

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

AIM FOR TODAY: - Add custom edge info to the eedges created for dynamically discovered calls - Add the custom events to be showing in diagnostics - update call_event and return_event to also work for the cases where there is no underlying superedge representing the call --- PROGRESS : - I cre

Unsubscribe

Joseph Ayers, Professor Departments of Marine and Environmental Science, Biology, Civil and Environmental & Electrical and Computer Engineering Bioengineering and Marine Science Center Northeastern University East Point, Nahant, MA 01908 Phone (781) 581-7370 x309(office), x335(lab) Boston: 516 I

Re: Disabling TLS address caching to help QEMU on GNU/Linux

Hello, On Thu, 22 Jul 2021, Richard Biener via Gcc wrote: > But how does TLS usage transfer between threads? On the gimple level > the TLS pointer is not visible and thus we'd happily CSE its address: Yes. All take-address operations then need to be encoded explicitely with a non-CSE-able in

[WIP][not for GCC main branch] CHERI/Morello capabilities in GCC

Hello, We're working on adding CHERI capability support to GCC, specifically focusing on targetting the experimental Morello architecture. The eventual aim is to help bring up a GNU system on the upcoming Morello boards. Morello is an integration of the CUCL CHERI (Capability Hardware Enhanced RI

gcc plugin on MacOS failure

Hi, I have a gcc plugin (for afl++, https://github.com/AFLplusplus/AFLplusplus) that works fine when compiled on Linux but when compiled on MacOS (brew install gcc) it fails: ~/afl++ $ g++-11 -g -fPIC -std=c++11 -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin/i

Re: Proper Place for builtin_define(__ELF__)

On Wed, Jul 21, 2021 at 11:09 PM Jeff Law via Gcc wrote: > > > > On 7/21/2021 6:31 PM, Michael Eager wrote: > > > > > > On 7/21/21 5:22 PM, Joel Sherrill wrote: > >> > >> > >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager >> > wrote: > >> > >> On 7/21/21 2:28 PM, Joel

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

> > But the addresses are at LGEN time? The following is what runs at WPA time unsigned long pid = streamer_read_uhwi (&ib); unsigned long id = streamer_read_uhwi (&ib); lto_symtab_encoder_t encoder = file_data->symtab_node_encoder; cgraph_node *cnode = dyn_cast(lto_symtab_encoder_deref(encoder,

Re: GCC 11.2 Release Candidate available

On 7/21/21 4:02 AM, Richard Biener wrote: The first release candidate for GCC 11.2 is available from https://sourceware.org/pub/gcc/snapshots/11.2-RC-20210721/ and shortly its mirrors. It has been generated from git commit 076930b9690ac3564638636f6b13bbb6bc608aea. I have so far bootstrapped

Re: Proper Place for builtin_define(__ELF__)

On Wed, Jul 21, 2021 at 10:08 PM Jeff Law wrote: > > > > On 7/21/2021 6:31 PM, Michael Eager wrote: > > > > > > On 7/21/21 5:22 PM, Joel Sherrill wrote: > >> > >> > >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager >> > wrote: > >> > >> On 7/21/21 2:28 PM, Joel Sherril

Re: More aggressive GCC 12 -Wmaybe-uninitialized when using

On Thu, 22 Jul 2021 at 11:03, Jonathan Wakely wrote: > > On Thu, 22 Jul 2021 at 10:23, Stephan Bergmann via Libstdc++ > wrote: > > > > Compared to GCC 11 (at least gcc-c++-11.1.1-3.fc34.x86_64), recent GCC > > 12 trunk emits two "unhelpful" -Wmaybe-uninitialized for > > > > > $ cat test.cc > > > #

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

On Thu, Jul 22, 2021 at 2:33 PM Erick Ochoa wrote: > > > > > 1. pid of lgen process that generated the encoding > > > > 2. index returned by lto_symtab_encoder_encode > > > > 3. varpool_node->name () > > > > 4. the pointer address being pointed by varpool node > > > > Well, yes, during LGEN no WPA

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

> > > 1. pid of lgen process that generated the encoding > > > 2. index returned by lto_symtab_encoder_encode > > > 3. varpool_node->name () > > > 4. the pointer address being pointed by varpool node > > Well, yes, during LGEN no WPA has run. Do you mean LTRANS after WPA? > Sure, the encoder numbe

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

On Thu, Jul 22, 2021 at 2:04 PM Erick Ochoa wrote: > > > > If this is the case, I can indeed get the varpool node's at WPA time > > > (as shown above), but comparing their pointer addresses will be > > > distinct. How can one find out that two varpool nodes/cgraph nodes are > > > the same at WPA t

Re: A value number issue

On Thu, Jul 22, 2021 at 8:06 AM Gary Oblock via Gcc wrote: > > I seem to be having a problem with the pre pass. > > When eliminate_dom_walker::eliminate_stmt is called with > the gsi to "dedangled_864 = bea_43->tail;" which in turn > calls eliminate_dom_walker::eliminate_avail op of dedangled_864.

Re: gcc_assert() and inhibit_libc

On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber wrote: > > Hello, > > while testing this patch > > https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking > > I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from > tsystem.h): > > #ifdef ENABLE_RUNTIME_CHEC

Re: Disabling TLS address caching to help QEMU on GNU/Linux

On Tue, Jul 20, 2021 at 4:54 PM Florian Weimer via Gcc wrote: > > Currently, the GNU/Linux ABI does not really specify whether the thread > pointer (the address of the TCB) may change at a function boundary. > > Traditionally, GCC assumes that the ABI allows caching addresses of > thread-local var

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

> > fopen $PID1 8 $ADDR1 > fopen $PID2 7 $ADDR2 > Just to clarify a bit further. $PID is generated and stored during LGEN. The encoding is obviously generated during LGEN. These are read during WPA. And the encoding is decoded and dyn_casted into a cgraph_node at WPA time. All these are printed du

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

> > If this is the case, I can indeed get the varpool node's at WPA time > > (as shown above), but comparing their pointer addresses will be > > distinct. How can one find out that two varpool nodes/cgraph nodes are > > the same at WPA time? Is just looking at the assembler name enough? I > > of co

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

On Wed, Jul 21, 2021 at 6:55 PM Erick Ochoa wrote: > > Hello Richard, I need a little bit more help. In our previous messages > you mentioned "" > > > > > > > > I guess the way to encode SSA trees would be to use sth like a > > > > , SSA-version tuple much like PTA internally > > > > uses the vari

Re: More aggressive GCC 12 -Wmaybe-uninitialized when using

On Thu, 22 Jul 2021 at 10:23, Stephan Bergmann via Libstdc++ wrote: > > Compared to GCC 11 (at least gcc-c++-11.1.1-3.fc34.x86_64), recent GCC > 12 trunk emits two "unhelpful" -Wmaybe-uninitialized for > > > $ cat test.cc > > #include > > using fn = std::function; > > fn f(fn x) { > > fn a; >

More aggressive GCC 12 -Wmaybe-uninitialized when using

Compared to GCC 11 (at least gcc-c++-11.1.1-3.fc34.x86_64), recent GCC 12 trunk emits two "unhelpful" -Wmaybe-uninitialized for $ cat test.cc #include using fn = std::function; fn f(fn x) { fn a; a = x; return x; } $ ~/gcc/trunk/inst/bin/g++ -c -Wmaybe-uninitialized -O2 test.cc

Re: GCC 11.2 Release Candidate available

> On 21 Jul 2021, at 10:02, Richard Biener wrote: > > > The first release candidate for GCC 11.2 is available from > > https://sourceware.org/pub/gcc/snapshots/11.2-RC-20210721/ > > and shortly its mirrors. It has been generated from git commit > 076930b9690ac3564638636f6b13bbb6bc608aea. >