A value number issue

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. This gives VN_INFO (lhs)->valnum of _920. The _920 is not associated w

Re: Proper Place for builtin_define(__ELF__)

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 Sherrill wrote: > Hi > > We are in the process of porting RTEMS to the Microbla

Re: Proper Place for builtin_define(__ELF__)

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 Sherrill wrote: > Hi > > We are in the process of porting RTEMS to the Microblaze and gcc does > not have __ELF__ as a p

Re: Proper Place for builtin_define(__ELF__)

On Wed, Jul 21, 2021, 7:12 PM Michael Eager wrote: > On 7/21/21 2:28 PM, Joel Sherrill wrote: > > Hi > > > > We are in the process of porting RTEMS to the Microblaze and gcc does > > not have __ELF__ as a predefine. In looking around at where to add it, > > it looks like there are multiple ways t

Re: Proper Place for builtin_define(__ELF__)

On 7/21/21 2:28 PM, Joel Sherrill wrote: Hi We are in the process of porting RTEMS to the Microblaze and gcc does not have __ELF__ as a predefine. In looking around at where to add it, it looks like there are multiple ways to do it. We see variations on the following patterns: + dbxelf.h + OS s

Proper Place for builtin_define(__ELF__)

Hi We are in the process of porting RTEMS to the Microblaze and gcc does not have __ELF__ as a predefine. In looking around at where to add it, it looks like there are multiple ways to do it. We see variations on the following patterns: + dbxelf.h + OS specific header in config/ + Arch/OS specifi

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

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 varinfo array index as identifier for the variables in the > > > constr

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

> 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 22:41 +0530, Ankur Saini wrote: >>> >>> > > [...snip...] > >>> 2. ( pr

Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations

N.B. I already answered this when you sent it to the libstdc++ list, read past the first line of my reply: https://gcc.gnu.org/pipermail/libstdc++/2021-July/052932.html On Wed, 21 Jul 2021 at 14:00, Amar Memic wrote: > > > Hi,6.55 Built-in Functions for Memory Model Aware Atomic Operations > (ht

6.55 Built-in Functions for Memory Model Aware Atomic Operations

Hi,6.55 Built-in Functions for Memory Model Aware Atomic Operations (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html)  says:Note that the ‘__atomic’ builtins assume that programs will conform to the C++11 memory model. In particular, they assume that programs are free of data

gcc_assert() and inhibit_libc

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_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else

Re: Pushing XFAILed test cases

Hi all, hi Thomas (2x), hi Sandra, On 16.07.21 09:52, Thomas Koenig via Fortran wrote: The part of the patch to add tests for this goes on top of my base TS29113 testsuite patch, which hasn't been reviewed or committed yet. It is my understanding that it is not gcc policy to add xfailed test c

GCC 11.2 Release Candidate available

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 and tested the release candidate on x86_64

GCC 11.1.1 Status Report (2021-07-21), branch frozen for release

Status == The GCC 11 branch is now frozen for the upcoming GCC 11.2 release. All changes require release manager approval now. Quality Data Priority # Change from last report --- --- P1 P2 260 - 12

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

On 20/07/2021 16.52, Florian Weimer 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. [...] One important piece of software for GNU is QEMU (not just for GNU/Linux, Hurd development also benefits fr