do we ever thread computed gotos?

Howdy. In the backwards threader we attempt to thread paths that lead to a basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a GIMPLE_GOTO. The latter doesn't make much sense, since we only handle constants. What does a goto to a constant mean? Does that ever happen? In tree-s

Re: do we ever thread computed gotos?

On Thu, Oct 26, 2017 at 1:05 PM, Aldy Hernandez wrote: > Howdy. > > In the backwards threader we attempt to thread paths that lead to a basic > block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a GIMPLE_GOTO. The > latter doesn't make much sense, since we only handle constants. What does a

Re: do we ever thread computed gotos?

On 10/26/2017 08:31 AM, Richard Biener wrote: On Thu, Oct 26, 2017 at 1:05 PM, Aldy Hernandez wrote: Howdy. In the backwards threader we attempt to thread paths that lead to a basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a GIMPLE_GOTO. The latter doesn't make much sense, si

Re: do we ever thread computed gotos?

On Thu, Oct 26, 2017 at 2:35 PM, Aldy Hernandez wrote: > > > On 10/26/2017 08:31 AM, Richard Biener wrote: >> >> On Thu, Oct 26, 2017 at 1:05 PM, Aldy Hernandez wrote: >>> >>> Howdy. >>> >>> In the backwards threader we attempt to thread paths that lead to a basic >>> block ending in either a GIM

Re: do we ever thread computed gotos?

On 10/26/2017 05:05 AM, Aldy Hernandez wrote: > Howdy. > > In the backwards threader we attempt to thread paths that lead to a > basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a > GIMPLE_GOTO.  The latter doesn't make much sense, since we only handle > constants.  What does a goto t

LLVM disagrees with GCC on bitfield handling

Hi, Sorry if this question has been raised in past. I am running GCC testsuite for our LLVM port. There are several failures related to bitfields handling (pr32244-1.c, bitfld-3.c bitfld-5.c, etc) that LLVM disagrees with GCC. Taking pr32444-1.c as example, struct foo { unsigned long long b:40;

Re: LLVM disagrees with GCC on bitfield handling

There is a line of C90 DRs and associated textual history (compare the relevant text in C90 and C99, or see my comparison of it in WG14 reflector message 11100 (18 Apr 2006)) to the effect of bit-fields acting like they have a type with the given number of bits; that line is what's followed by

Question about generated type for common block in fortran

Hi, I am looking into DSE transformation of some fortran codes. Given below fortran declarations: real*8 a(len) , b(len) , c(len) , d(len) common /area/ a, b, c, d real*8 src1(len), temp1(len), temp2(len), src2(len) equivalence(src1, a), (src2, b), (temp

Re: Question about generated type for common block in fortran

On October 26, 2017 6:47:59 PM GMT+02:00, "Bin.Cheng" wrote: >Hi, >I am looking into DSE transformation of some fortran codes. Given >below fortran declarations: > > real*8 a(len) , b(len) , c(len) , d(len) > common /area/ a, b, c, d > real*8 src1(len), temp1(len), t

Missed possible branch elimination

While poring over the Transport Tycoon Deluxe disassembly, commonly known to have been hand-written in assembler, I stumbled across this tidbit, which I think is kinda neat: 004057F7 83 7D B8 01 cmp dword ptr [ebp-48h],1 004057FB 1B C0sbb eax,eax 004057FD F

gcc-7-20171026 is now available

Snapshot gcc-7-20171026 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20171026/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7

Re: [std-discussion] Is this union aliasing code well-defined?

+Cc gcc-list. Does any gcc developer have any comments? On Mon, Sep 25, 2017 at 01:41:55PM -0700, Myriachan wrote: > This question that "supercat" posted on Stack Overflow ran into an > interesting problem: > > https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conformi