[Bug c/63326] New: pragma GCC causes wrong code generation

[Bug c/63326] New: pragma GCC causes wrong code generation

[dietmar.schindler@manroland-web.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

            Bug ID: 63326
           Summary: pragma GCC causes wrong code generation
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dietmar.schindler@manroland-web.com

Created attachment 33530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33530&action=edit
preprocessed file

The following command generates wrong code, returning 1 instead of 0 (as if the
pragma line ended the statement in which it is placed).

raeksrv1:~/bin/so/c> /tmp/usr/local/bin/gcc -v -save-temps bug.c -o bug         
Using built-in specs.
COLLECT_GCC=/tmp/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.1/configure --enable-plugin --disable-libsanitizer
: (reconfigured) ../gcc-4.9.1/configure --enable-plugin --enable-languages=c
--disable-libsanitizer : (reconfigured) ../gcc-4.9.1/configure --enable-plugin
--enable-languages=c --disable-libsanitizer --disable-libcilkrts
Thread model: posix
gcc version 4.9.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1 -E -quiet
-v -iprefix /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/ bug.c
-mtune=generic -march=x86-64 -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include"
ignoring duplicate directory
"/tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed"
ignoring nonexistent directory
"/tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include
 /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1
-fpreprocessed bug.i -quiet -dumpbase bug.c -mtune=generic -march=x86-64
-auxbase bug -version -o bug.s
GNU C (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa505e323dbffe0cb500ba62f983d917
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.20.1-system.20100303
COMPILER_PATH=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/:/tmp/usr/local/bin/../libexec/gcc/
LIBRARY_PATH=/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/:/tmp/usr/local/bin/../lib/gcc/:/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/crtbegin.o
-L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1
-L/tmp/usr/local/bin/../lib/gcc
-L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../.. bug.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/crtend.o
/usr/lib/../lib64/crtn.o

[Bug c/63326] pragma GCC causes wrong code generation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
#pragma are considered statements.

[Bug c/63326] pragma GCC causes wrong code generation

[dietmar.schindler@manroland-web.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #2 from Dietmar Schindler <dietmar.schindler@manroland-web.com> ---
(In reply to Andrew Pinski from comment #1)
> #pragma are considered statements.

This can't be entirely true, since #pragma can be used where statements cannot
(outside of functions), and #pragma STDC certainly isn't considered a
statement.
At least, this implementation-defined behaviour has to be documented (hasn't
it?), and I couldn't find mention of it in the documentation. Would you
recommend filing a separate documentation bug report?

[Bug c/63326] pragma GCC causes wrong code generation

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2014-09-24
                 CC|                            |manu at gcc dot gnu.org
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
If you use #pragma GCC system_header, you get a different result, so this seems
a bug to me (whatever the behavior, it should not depend on the type of
#pragma). At the very least, GCC could give a warning if the #pragma is the
only statement in a if/else/while/do/for body, since this is probably a bug.
>From gcc-bugs-return-462437-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 24 14:38:16 2014
Return-Path: <gcc-bugs-return-462437-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26680 invoked by alias); 24 Sep 2014 14:38:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26283 invoked by uid 48); 24 Sep 2014 14:38:12 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63326] whether a #pragma is a statement depends on the type of pragma
Date: Wed, 24 Sep 2014 14:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63326-4-xYO9m9CxKb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63326-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63326-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02271.txt.bz2
Content-length: 192

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
When compiled with Clang, it returns 0 by the way.
>From gcc-bugs-return-462438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 24 14:41:59 2014
Return-Path: <gcc-bugs-return-462438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4635 invoked by alias); 24 Sep 2014 14:41:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4612 invoked by uid 48); 24 Sep 2014 14:41:56 -0000
From: "richard at netbsd dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/63352] problem with fmt_g0_1.f08  on i386-pc-solaris2.11
Date: Wed, 24 Sep 2014 14:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: richard at netbsd dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63352-4-bbqFY0H4QQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63352-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63352-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02272.txt.bz2
Content-length: 257

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc352

--- Comment #2 from Richard PALO <richard at netbsd dot org> ---
FWIW, just checked ... this is a regression introduce after 4.7.3 (where this
test seems to work fine...can't test 4.8.3 any more, sorry).

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> When compiled with Clang, it returns 0 by the way.

So ...
Pragma that are not recognized are ignored.
>From gcc-bugs-return-462452-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 24 15:52:35 2014
Return-Path: <gcc-bugs-return-462452-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12168 invoked by alias); 24 Sep 2014 15:52:35 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12119 invoked by uid 55); 24 Sep 2014 15:52:24 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63326] whether a #pragma is a statement depends on the type of pragma
Date: Wed, 24 Sep 2014 15:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63326-4-4Sk4RHdQhW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63326-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63326-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02286.txt.bz2
Content-length: 608

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc326

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
#pragma STDC is functionally a declaration (it can only occur "either
outside external declarations or preceding all explicit declarations and
statements inside a compound statement" - each such pragma has the same
wording, including FENV_ROUND in TS 18661-1).  Thus, while those pragmas
are not currently implemented in GCC, treating them as syntactical
entities at the same level as declarations and statements would be fully
in accordance with the standard.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |q.gcc@rsn-tech.co.uk

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 63612 has been marked as a duplicate of this bug. ***

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Maybe we should also warn about

  if (...)
#pragma STDC ...
    foo ();

both if we are treating the #pragma as stmt and if not.  That is, if the
#pragma appears in a place where that would make a difference.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, we already error out on OpenMP pragmas in such places, because the OpenMP
standard requires that the pragmas aren't used in contexts where accepting them
as statements or ignoring them would make a difference for parsing the
function:
"For C/C++, a stand-alone directive may not be used in place of the statement
following an if, while, do, switch, or label. See Appendix B for the formal
grammar."
so for other pragmas we could use similar conditions.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to steveren from comment #6)
> Seems the consensus is that it's not contrary to Standard, but it's agreed
> to be confusing and undesirable by everyone except the gcc maintainers :-)

Not sure how you reached such conclusion, but it clearly misinterprets reality,
otherwise this PR would be closed as INVALID already.

I'm pretty sure if you submitted a patch making the behavior of all pragmas
consistent with comment #9, this will be fixed by next week.
(https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)

> I'll take a lot of persuading that this isn't a reasonable thing to want to
> do. (Flagging the nasty, that is; purists who say you should never /do/
> anything you need to warn people about need not apply :-) )

I'm not sure to which "purists" you are referring but, from my experience, GCC
welcomes warnings that help people to write better code and prevent mistakes as
long as patches are written and tested properly and do not generate too many
hard-to-work-around false positives. New warnings are added in every release.
Thus, I would encourage you to submit a patch and see for yourself.
>From gcc-bugs-return-464648-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 22 12:50:09 2014
Return-Path: <gcc-bugs-return-464648-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6176 invoked by alias); 22 Oct 2014 12:50:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6148 invoked by uid 48); 22 Oct 2014 12:50:05 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63616] New: PRE failure
Date: Wed, 22 Oct 2014 12:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cf_gcctarget
Message-ID: <bug-63616-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01669.txt.bz2
Content-length: 3060

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc616

            Bug ID: 63616
           Summary: PRE failure
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
            Target: alpha-linux-gnu

Currently text/template/parse testcase from libgo fails on alpha-linux-gnu due
to failure of PRE pass.

Before PRE pass, we have:

  409: r229:DI=[FP:DI+0x60]
  410: pc={(r229:DI==0)?L437:pc}
      REG_DEAD r229:DI
      REG_BR_PROB 1500
  ...
  427: L427:                                   [***] <--- jump target
  428: NOTE_INSN_BASIC_BLOCK 33
  430: r236:SI=[r70:DI+0x10]                   <--- load from r70+0x10
  431: r235:QI#0=zero_extract(r236:SI#0,0x8,0)
      REG_DEAD r236:SI
  432: r95:DI=zero_extend(r235:QI)
      REG_DEAD r235:QI
  433: pc={(r95:DI!=0)?L458:pc}
      REG_DEAD r95:DI
      REG_BR_PROB 5000
  437: L437:
  438: NOTE_INSN_BASIC_BLOCK 34
  439: r237:QI=0x1
  440: r238:SI=[r70:DI+0x10]                   <--- load from r70+0x10
  441: r238:SI#0=r238:SI#0&0xffffffffffffff00
  443: r239:SI#0=r238:SI#0|0x1
      REG_DEAD r238:SI
  444: [r70:DI+0x10]=r239:SI                   <--- store to r70+0x10
      REG_DEAD r239:SI
  445: [r70:DI+0x18]=r94:DI
  446: pc={(r94:DI!=0)?L427:pc}                jump back ---> [***]
      REG_DEAD r94:DI
      REG_BR_PROB 5000
  ...

PRE pass eliminates load to:

  ...
  409: r229:DI=[FP:DI+0x60]
  410: pc={(r229:DI==0)?L437:pc}
      REG_DEAD r229:DI
      REG_BR_PROB 1500
  708: NOTE_INSN_BASIC_BLOCK 30
  699: r307:SI=[r70:DI+0x10]                   <--- load to temp from r70+0x10
  ...
  427: L427:                                   [***] <--- jump target
  428: NOTE_INSN_BASIC_BLOCK 32
  698: r236:SI=r307:SI                         <--- move from temp
      REG_EQUAL [r70:DI+0x10]
  431: r235:QI#0=zero_extract(r236:SI#0,0x8,0)
      REG_DEAD r236:SI
  432: r95:DI=zero_extend(r235:QI)
      REG_DEAD r235:QI
  433: pc={(r95:DI!=0)?L458:pc}
      REG_DEAD r95:DI
      REG_BR_PROB 5000
  437: L437:
  438: NOTE_INSN_BASIC_BLOCK 33
  439: r237:QI=0x1
  440: r307:SI=[r70:DI+0x10]                   <--- load to temp from r70+0x10
  707: r238:SI=r307:SI                         <--- move from temp
  441: r238:SI#0=r238:SI#0&0xffffffffffffff00
  443: r239:SI#0=r238:SI#0|0x1
      REG_DEAD r238:SI
  444: [r70:DI+0x10]=r239:SI                   <--- store to r70+0x10
      REG_DEAD r239:SI
  445: [r70:DI+0x18]=r94:DI
  446: pc={(r94:DI!=0)?L427:pc}                jump back ---> [***]
      REG_DEAD r94:DI
      REG_BR_PROB 5000
  ...

As shown above, PRE inserted BB 30, but when progam jumps back, the value is
moved from temporary, not from the memory. It looks that when a new BB is
inserted, the compiler forgot to update the jumpback label.

I will attach complete cprop1 and pre dumps. I didn't find any kind of
"preprocessed" go file with -fsave-temps to attach.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[q.gcc@rsn-tech.co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #11 from steveren <q.gcc@rsn-tech.co.uk> ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to steveren from comment #6)
> > Seems the consensus is that it's not contrary to Standard, but it's agreed
> > to be confusing and undesirable by everyone except the gcc maintainers :-)
> 
> Not sure how you reached such conclusion, but it clearly misinterprets
> reality, otherwise this PR would be closed as INVALID already.

Ok, my apologies. However, this bug /was/ closed as invalid before being
reopened, and my own report was closed as invalid before being marked as a dupe
of this one, so it's not entirely clear that there's a general feeling of a
real problem that needs to be addressed.

> I'm pretty sure if you submitted a patch making the behavior of all pragmas 
> consistent with comment #9,

But I don't /want/ behaviour consistent with #9 (ie, warning that the usage is
invalid), I want the usage to be valid /and/ sensible - ie, the same as other
compilers. I suspect that's more difficult...

Don't get me wrong - I'm not whingeing that other people should solve my
problems for me without being prepared to get involved myself, but if this is
WAD in the eyes of the majority, then I'll live with it sooner than create my
own fork!

So assuming it's not actually beyond somebody completely unfamiliar with the
innards of gcc, what would be the response to a patch which changed #pragma
message from 'statement' to 'not-a-statement'?
>From gcc-bugs-return-464655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 22 14:08:16 2014
Return-Path: <gcc-bugs-return-464655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13906 invoked by alias); 22 Oct 2014 14:08:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13612 invoked by uid 48); 22 Oct 2014 14:08:12 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63609] incompatibility with C++11 standard on 14.5.6.2 Partial ordering of function templates
Date: Wed, 22 Oct 2014 14:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed bug_severity
Message-ID: <bug-63609-4-OcBLNvpxVt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63609-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63609-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01676.txt.bz2
Content-length: 729

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc609

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-22
     Ever confirmed|0                           |1
           Severity|blocker                     |normal

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please don't set severity=blocker just because you think it's quite important
to you. We're not going to block a GCC release for this issue, especially since
it's been present in several releases already!

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to steveren from comment #11)
> So assuming it's not actually beyond somebody completely unfamiliar with the
> innards of gcc, what would be the response to a patch which changed #pragma
> message from 'statement' to 'not-a-statement'?

I think that even if not a definitive solution, it would be a positive step
towards understanding what would it take to change the behavior for specific
#pragmas (since we cannot change how OMP #pragmas behave).
>From gcc-bugs-return-464658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 22 14:11:58 2014
Return-Path: <gcc-bugs-return-464658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18570 invoked by alias); 22 Oct 2014 14:11:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18527 invoked by uid 48); 22 Oct 2014 14:11:53 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs
Date: Wed, 22 Oct 2014 14:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63600-4-J3ZwSzD3VO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63600-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63600-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01679.txt.bz2
Content-length: 286

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc600

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I would have expected VI instead of IV in the iterator name, but I never
understood the rules for i?86 iterator names.
And, you want the testcase in the testsuite too.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |romain.geissler at amadeus dot com

--- Comment #27 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 94367 has been marked as a duplicate of this bug. ***

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

--- Comment #28 from Romain Geissler <romain.geissler at amadeus dot com> ---
Hi David,

Do you have plans to submit this patch for review when stage 1 of gcc 11 opens
?

Cheers,
Romain

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.0                        |10.2

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.1 has been released.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.2                        |10.3

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.2 is released, adjusting target milestone.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.3                        |10.4

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #32 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 101538 has been marked as a duplicate of this bug. ***

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |---

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |domen.stangar at gmail dot com

--- Comment #34 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111758 has been marked as a duplicate of this bug. ***

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liavonlida at gmail dot com

--- Comment #35 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 113587 has been marked as a duplicate of this bug. ***