[Bug c/65892] New: gcc fails to implement N685 aliasing of union members

[Bug c/65892] New: gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

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

            Bug ID: 65892
           Summary: gcc fails to implement N685 aliasing of union members
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As the following program derived from the snippet in WG14 paper N685
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm) shows, GCC fails to
take into account the C99 and C11 permission for struct members of unions that
declare initial members of compatible types to alias one another.

$ cat n685.c && /build/gcc-65479/gcc/xgcc -B/build/gcc-65479/gcc -O2
-fstrict-aliasing n685.c && ./a.out
#include <assert.h>

union U {
    struct t1 { int m; } s1;
    struct t2 { int m; } s2;
};

int f (struct t1 *p1, struct t2 *p2)
{
    // union U visible here, p1->m and p2->m may alias

    if (p1->m < 0)
        p2->m = -p2->m;

    return p1->m;
}

int main (void)
{
    union U u = { .s1 = { -1 } };

    int n = f (&u.s1, &u.s2);

    assert (1 == n);

    return 0;
}
a.out: n685.c:21: main: Assertion `1 == n' failed.
Aborted (core dumped)

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Some folks think that resolution is not fully correct.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is an exact dup of bug 14319.

*** This bug has been marked as a duplicate of bug 14319 ***

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also if we follow that defect resolution, basically strict aliasing does not
mean anything any more and we would have to turn off strict aliasing for all
structs.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #4)
> Thanks for the pointer!  I had looked for a related bug report but couldn't
> find it.
> 
> There's an important difference between the test cases in pr14319 and the
> one here that's easy to overlook.  The rule only applies to structs defined
> in unions, not those defined at file scope and only used to declare union
> members, and to translation units in which the union definition is visible. 


No that is not the rule.  If I read the section:
    [#5] One special guarantee is made in order to simplify the use of unions:
if a union contains several structures that share a common initial sequence
(see
below), and if the union object currently contains one of these structures, it
is permitted to inspect the common initial part of any of them anywhere that a
declaration of the complete type of the union is visible. Two structures share
a
common initial sequence if corresponding members have compatible types (and,
for
bit-fields, the same widths) for a sequence of one or more initial members.
--- CUT ----
I don't see anywhere the standard says about where the struct is defined in the
statement above.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
I agree it's subtle and could be clearer but I believe the key phrase is "a
union contains several structures."  Here, the term "union" refers to the type,
not the object.  This is supported by the use of the term "union object" in the
second part of the sentence.

This interpretation is in line with Derek Jones' excellent The New C Standard
-- An Economic and Cultural Commentary: http://www.coding-guidelines.com/cbook

But if there's doubt that this interpretation is intended I'd be happy to raise
an interpretation request on the WG14 mailing list.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |alias
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
As Andrew says GCCs behavior is intentional and N685 is just completely broken.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
If one of you can explain the problem with it I'm willing to write up a paper
and submit it to WG14 and request to have the standard changed.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The rule certainly has nothing to do with whether the struct types are 
defined inside the union definition, or defined outside and then used 
inside via a tag or typedef.

The "it is permitted" wording is poorly defined, and the C99 changes 
confused this through failing to realise how it's poorly defined.  In C90, 
the paragraph starts "With one exception, if a member of a union object is 
accessed after a value has been stored in a different member of the 
object, the behavior is implementation-defined.[41]  One special guarantee 
is made ... it is permitted ...".  This reads to me like "it is permitted" 
was intended as an exception to the general rule of behavior being 
implementation-defined (that is, it was defining one case of type punning, 
which was more generally defined non-normatively in the footnote added in 
C99 TC3).

The difficulty with "it is permitted" is there are any number of cases 
where other wording indicates something is not permitted that it could be 
interpreted as overriding - just saying "it is permitted" fails to say 
which are or are not overridden.  (As a C11 example, something might not 
be permitted because it's a data race, for example, but accessing a common 
initial sequence can hardly be intended to override the normal rules about 
data races.)  So the authors of N685 read "it is permitted" as relating 
not to the previous sentence in the same paragraph about accessing 
different union members, but as relating to completely separate rules 
about aliasing.  The visible union rule was then inserted for C99, thereby 
serving to confuse things further by supporting the suggestion that "it is 
permitted" relates to aliasing.

DR#236 then considered a different case of aliasing through pointers to 
union members.  However, the response never decided the question of 
whether the accesses must visibly be through the union, or whether it's 
sufficient for the declaration of the union to be visible.

Basing things on whether a union is visible in the translation unit is 
clearly a bad rule because of action-at-a-distance effects (the visible 
union might be in a header included for some completely unrelated purpose, 
but would still inhibit optimization).

(Note that the exact example given in this bug is invalid as the union has 
active member s1, but is modified via member s2; you can only "inspect" 
common members of non-active union members, not modify them.  But 
presumably using .s2 in the initializer would still show the issue.)

Thus, "it is permitted" needs reworking to describe what it's an exception 
to.  To the extent that it's an exception to aliasing rules, I think that 
should only be where the union is actually used for the accesses in 
question (in which case no exception is actually needed beyond defining 
the layout requirements and making the type punning rules normative), and 
DR#236 should be clarified accordingly.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor <msebor at gcc dot gnu.org> ---
Thanks (again) for your comments, Joseph.  I had a chance to discuss this issue
with Clark Nelson last week.  Clark has worked on improving the aliasing parts
of the C specification in the past, for example in N1520
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1520.htm).  He agreed that
like the issues pointed out in N1520, this is also an outstanding problem that
would be worth for WG14 to revisit and fix.  We also agreed to work together on
a revised paper for the next WG14 meeting in October 2015.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2015-05-21
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #11 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Suspending until then.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[myriachan at gmail dot com]

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

Melissa <myriachan at gmail dot com> changed:

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

--- Comment #12 from Melissa <myriachan at gmail dot com> ---
This is broken in C++ as well, and in C++, the rules are much more clear that
GCC isn't following them.

Quoting the C++ Standard, revision 4296 (post-C++14?):

16. The "common initial sequence" of two standard-layout struct (Clause 9)
types is the longest sequence of non-static data members and bit-fields in
declaration order, starting with the first such entity in each of the structs,
such that the corresponding entries have layout-compatible types and either
neither entity is a bit-field or both are bit-fields with the same width.

19. In a standard-layout union with an active member (9.5) of struct type T1,
it is permitted to read a non-static data member m of another union member of
struct type T2 provided m is part of the common initial sequence of T1 and T2.


A C++ conversion of the original example is below.  I asked about the word
"read" on the C++ Standard Discussion (std-discussion) mailing list, because it
probably should also allow writing if it allows reads.  As a result, I modified
the below to only *read* in an aliasing way, to fully comply with the written
word of the Standard.


#include <cassert>

struct t1 { int m; };
struct t2 { int m; };

union U {
    t1 s1;
    t2 s2;
};

int f (t1 *p1, t2 *p2)
{
    // union U visible here, p1->m and p2->m may alias
    // p1 is the active member; read from p2 per [class.mem]/19.

    if (p2->m < 0)
        p1->m = -p1->m;

    return p2->m;
}

int main (void)
{
    union U u = { { -1 } };

    int n = f (&u.s1, &u.s2);

    assert (1 == n);

    return 0;
}

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[myriachan at gmail dot com]

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

--- Comment #13 from Melissa <myriachan at gmail dot com> ---
As for a reason why this should be allowed, all I need is to do is mention
struct sockaddr.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
That C++ wording doesn't have any obvious bearing on what "it is 
permitted" is intended to be an exception to - the general 
implementation-defined nature of type punning (which I think was the 
original intent in C90), or the aliasing rules.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Melissa from comment #12)
> A C++ conversion of the original example is below.  I asked about the word
> "read" on the C++ Standard Discussion (std-discussion) mailing list, because
> it probably should also allow writing if it allows reads.

Up to C++14 the wording said "inspect" which was changed to use "read" by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1719 so I think
limiting to reads and not writes is intended.

(In reply to joseph@codesourcery.com from comment #14)
> That C++ wording doesn't have any obvious bearing on what "it is 
> permitted" is intended to be an exception to - the general 
> implementation-defined nature of type punning (which I think was the 
> original intent in C90), or the aliasing rules.

C++ doesn't support any type-punning, only reading from the common initial
sequence (where the types must be compatible), so I think it can only be an
exception to the aliasing rules.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Message [c++std-core-20893] on the C++ core reflector on 2011-12-14 supports
the GCC view that a C++ compiler can apply strict aliasing rules to p1->m and
p2->m unless the fact they come from the same object is visible to the
compiler.

<quote>
| Either I'm mistaken, or it is a 'magical property of unions'. If the
| compiler can figure out two objects didn't come form the same union,
| it can assume they do not alias,

Yes.  I believe I filled a core issue regarding this -- coming from
controversy originating from optimizations performed by compilers
today (especially without full program analysis) -- and the resolution
is that if intend to play type punning games with X and Y you better let
the type checker and optimizer see your cards upfront.  Otherwise, you
are on your own.  I can't remember the issue number right now.  In the
end, I think that was the right decision.
</quote>

But I can't find the core issue referred to.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor <msebor at gcc dot gnu.org> ---
The C Union Visibility rule was intended to cover that case.  The trouble is
that the rule tends to be interpreted differently by different people, users
and implementers alike: Is it the union object that must be visible at the
point of the access, or just the union type?  Must the access be performed
using the union object, or just the union type, or neither?  There are
implementations that apparently disable aliasing at the first sight of a union
in a translation unit.  There are others that only disable it for structs used
in a union.  And others still that don't do anything special unless the aliased
object is accessed through the union itself.

There are also aliasing problems beyond unions that affect both languages. 
WG14 N1520 referenced in comment #10 gives a few scary examples.  This still
needs to be resolved.  (I haven't talked to Clark since Lenexa so unless he's
made progress on the issue the new paper I mentioned in comment #10 will have
to wait until 2016.)

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[joseph at codesourcery dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 37156 bytes --]

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

--- Comment #39 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:

> Code which relies upon this feature to implement a C-style approximation to
> inheritance has been fairly common, which is precisely why the C committee
> decided to create this rule, to make sure such code had well-defined behavior.

To make sure such code had well-defined behavior *notwithstanding the 
adjacent rule (in C90) that access to a non-current union member was 
otherwise implementation-defined*.  Not overriding any other rule 
elsewhere in the standard that might make such accesses undefined, such as 
type-based aliasing, even though it's subsequently sometimes been 
interpreted in connection with such rules (and access to a non-current 
union member is now non-normatively specified in a footnote as type 
punning).
>From gcc-bugs-return-602489-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 15:13:00 2018
Return-Path: <gcc-bugs-return-602489-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 101131 invoked by alias); 23 Apr 2018 15:12: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 101052 invoked by uid 48); 23 Apr 2018 15:12:55 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/85501] missed if-conversion / phiopt trick
Date: Mon, 23 Apr 2018 15:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 8.0.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-85501-4-KyMvjeNZQN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85501-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85501-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: 2018-04/txt/msg02613.txt.bz2
Content-length: 474

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For scalar code or vector code?  For the latter, it needs a gather load, which
is expensive...
>From gcc-bugs-return-602490-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 15:19:47 2018
Return-Path: <gcc-bugs-return-602490-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 112604 invoked by alias); 23 Apr 2018 15:19:46 -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 112449 invoked by uid 55); 23 Apr 2018 15:19:40 -0000
From: "abel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403
Date: Mon, 23 Apr 2018 15:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: abel at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: abel at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 8.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-85423-4-547agmF6fy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85423-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85423-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: 2018-04/txt/msg02614.txt.bz2
Content-length: 624

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

--- Comment #5 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
Author: abel
Date: Mon Apr 23 15:19:06 2018
New Revision: 259563

URL: https://gcc.gnu.org/viewcvs?rev=259563&root=gcc&view=rev
Log:
        PR rtl-optimization/85423

        * sel-sched-ir.c (has_dependence_note_mem_dep): Only discard
        dependencies to debug insns when the previous insn is non-debug.

        * gcc.dg/pr85423.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr85423.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/sel-sched-ir.c
    trunk/gcc/testsuite/ChangeLog
>From gcc-bugs-return-602491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 15:37:13 2018
Return-Path: <gcc-bugs-return-602491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29699 invoked by alias); 23 Apr 2018 15:37:12 -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 29629 invoked by uid 48); 23 Apr 2018 15:37:08 -0000
From: "yangyibiao at nju dot edu.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/85201] [GCOV] A statement with two && operators and a comma operator in the for loop body is wrongly marked in gcov
Date: Mon, 23 Apr 2018 15:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: yangyibiao at nju dot edu.cn
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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-85201-4-RPfsVrYAaG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85201-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85201-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: 2018-04/txt/msg02615.txt.bz2
Content-length: 187

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

--- Comment #2 from Yibiao Yang <yangyibiao at nju dot edu.cn> ---
@marxin Is this a real bug? or this bug is only default behavior?
>From gcc-bugs-return-602492-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 15:44:56 2018
Return-Path: <gcc-bugs-return-602492-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 34199 invoked by alias); 23 Apr 2018 15:44:56 -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 34134 invoked by uid 48); 23 Apr 2018 15:44:51 -0000
From: "doko at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/85503] New: [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
Date: Mon, 23 Apr 2018 15:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: doko at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone attachments.created
Message-ID: <bug-85503-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: 2018-04/txt/msg02616.txt.bz2
Content-length: 2034

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

            Bug ID: 85503
           Summary: [8 Regression] ICE in replace_swapped_load_constant,
                    at config/rs6000/rs6000-p8swap.c:1853 on
                    powerpc64le-linux-gnu
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen with r259383 on the trunk, powerpc64le-linux-gnu, worked around with -O2:

$ g++ -Wall -std=gnu++11 -c -O2 gasgraphics.ii 
during RTL pass: swaps
: In function �int GasGraphicsItemcreateOnHoverHandler()�:
:211:1: internal compiler error: in replace_swapped_load_constant, at
config/rs6000/rs6000-p8swap.c:1853
Please submit a full bug report,
with preprocessed source if appropriate.

gcc configured with

--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/powerpc64le-linux-gnu-as
--with-ld=/usr/bin/powerpc64le-linux-gnu-ld --program-suffix=-8
--program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --disable-libphobos
--enable-objc-gc=auto --enable-secureplt --with-cpu=power8
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch
--disable-werror --with-long-double-128 --enable-checking=release
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu
>From gcc-bugs-return-602493-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 15:48:48 2018
Return-Path: <gcc-bugs-return-602493-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23095 invoked by alias); 23 Apr 2018 15:48:48 -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 13363 invoked by uid 48); 23 Apr 2018 15:48:37 -0000
From: "doko at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
Date: Mon, 23 Apr 2018 15:48: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: 8.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: doko at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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-85503-4-NYIIIrMe1j@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85503-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85503-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: 2018-04/txt/msg02617.txt.bz2
Content-length: 7137

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

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> ---
$ cat gasgraphics.ii
# 3 "" 3
namespace b {
template < int c > struct d { static constexpr int e = c; };
typedef d< false > f;
template < typename g > struct h { typedef g i; };
template < typename > class j;
template < bool, bool, typename... > struct aa;
struct k {
  template < typename n, typename... q >
  static h< decltype(n()(q()...)) > o(int);
};
template < typename p, typename... t > struct aa< false, false, p, t... > : k {
  typedef decltype(o< p, t... >(0)) i;
};
template < typename p, typename... t >
struct ab : aa< f::e, f::e, p, t... >::i {};
template < typename p, typename... t > struct j< p(t...) > : ab< p, t... > {};
} enum { r, s };
typedef long x;
template < typename > struct ac;
template < typename y > struct ac< y & > { typedef y i; };
template < typename y > struct j { typedef typename b::j< y >::i i; };
template < typename > struct ad;
template < typename > struct ae;
template < typename > class af;
template < typename, int ag, int ah, int = 0, int = ag, int = ah > class ai;
template < typename > class aj;
template < typename, typename, typename > class ak;
template < typename > class al;
template < typename > struct am;
template < typename > struct an;
template < typename y > struct ao { typedef typename am< y >::i i; };
struct aq {
  typedef const ai< double, 2, 1 > &ar;
};
template < typename as > struct at { typedef aj< as > i; };
template < typename as > struct au { typedef typename at< as >::i i; };
template < typename av > av aw(const typename an< av >::i *);
template < typename av, int > av az(const typename an< av >::i *ba) {
  return aw< av >(ba);
}
typedef __attribute__((altivec(vector__))) double bb;
template <> struct am< double > { typedef bb i; };
template <> struct an< bb > { typedef double i; };
template <> bb aw(const double *ba) { return __builtin_vec_vsx_ld(0, ba); }
struct bc {
  template < typename av > bd(av a) { bd(a); }
};
struct be {
  double operator()(const, const);
};
template < typename as > class bf : public ae< as > {
public:
  typedef typename ad< as >::bg bg;
  ae< as >::bh;
  enum { bi };
  bg bj() const;
  template < typename bk > bg bl(const bk &) const;
};
template < typename as > class aj : public bf< as > {
public:
  bf< as >::bh;
  template < typename bm > ak< be, const as, const bm > operator-(bm bn) {
    return ak< be, const as, const bm >(bh(), bn);
  }
  bo() const;
  al< as > array() { return bh(); }
};
template < typename as > struct ae {
  const as &bh() const { return *static_cast< const as * >(this); }
};
template < typename > struct bp;
template < typename > struct bq;
template < typename y > struct br : bq< y > {
  br(y bs) : bq< y >(bs) {}
};
template < typename y > struct br< const y > : br< y > {
  br(const y &bs) : br< y >(bs) {}
};
template < typename as > struct br< af< as > > {
  typedef as bt;
  br(const bt &m) : bu(m.bv()) {}
  template < int bw, typename ay > ay bx(x, x by) {
    return az< ay, bw >(bu + by);
  }
  const typename bt::bg *bu;
};
template < typename bg, int u, int bz, int ca, int cb, int cc >
struct br< ai< bg, u, bz, ca, cb, cc > > : br< af< ai< bg, u, bz > > > {
  typedef ai< bg, u, bz > cd;
  br(const cd &m) : br< af< cd > >(m) {}
};
template < typename bk, typename ce, typename cf >
struct br< ak< bk, ce, cf > > : bp< ak< bk, ce, cf > > {
  br(ak< bk, ce, cf > bs) : bp< ak< bk, ce, cf > >(bs) {}
};
template < typename bk, typename ce, typename cf >
struct bp< ak< bk, ce, cf > > {
  bp(ak< bk, ce, cf > bs) : cg(), ch(bs.ci()) {}
  template < int bw, typename ay > ay bx(x cj, x by) {
    return ch.template bx< bw, ay >(cj, by);
  }
  ce cg;
  br< cf > ch;
};
template < typename cd > struct v {
  typedef typename ac< typename cd::ck >::i cl;
  v(cl &arg) : cn(arg) {}
  template < int bw, typename ay > ay bx(x cj, x by) {
    return cn.template bx< bw, ay >(cj, by);
  }
  br< cl > cn;
};
template < typename cm > struct bq< al< cm > > : v< al< cm > > {
  bq(al< cm > w) : v< al< cm > >(w.dd()) {}
};
template < typename as > class ap : public bf< as > {};
template < int ax > struct co { double array[ax]; };
template < int ax > class cq {
  co< ax > bu;

public:
  const double *bv() const { return bu.array; }
};
template < typename as > class af : public at< as >::i {
public:
  typedef typename at< as >::i cp;
  cq< cp::bi > cs;
  const typename ad< as >::bg *bv() const { return cs.bv(); }
};
template < typename cr, int ag, int ah, int cu, int ct, int cw >
struct ad< ai< cr, ag, ah, cu, ct, cw > > {
  typedef cr bg;
};
template < typename, int ag, int ah, int, int, int >
class ai : public af< ai< double, ag, ah > > {
  typedef ai cv;
};
template < typename bk, typename ce, typename cf >
struct ad< ak< bk, ce, cf > > {
  typedef typename j< bk(typename ce::bg, typename cf::bg) >::i bg;
};
template < typename, typename, typename > class z;
template < typename bk, typename cy, typename cx >
class ak : public z< bk, cy, cx > {
public:
  typedef cx RhsNested;
  ak(cy, cx cz) : da(), db(cz) {}
  RhsNested ci() { return db; }
  cy da;
  RhsNested db;
};
template < typename bk, typename ce, typename cf >
class z : public au< ak< bk, ce, cf > >::i {};
template < typename as > aj< as >::bo() const { (*this).bj(); }
template < typename as > struct dc {
  typedef typename ao< typename as::bg >::i ay;
  enum { d, de };
  enum { df = de };
};
template < typename as > struct dk {
  enum { dh, di, dj, alignment };
  typedef typename dc< as >::ay PacketScalar;
  static PacketScalar dl(as dm, bc) {
    return dm.template dn< alignment, PacketScalar >(di, dj);
  }
};
template < typename, typename as, int = dc< as >::df > struct redux_impl;
template < typename Func, typename as > struct redux_impl< Func, as, s > {
  static dl(as dm, Func func) { func.bd(dk< as >::dl(dm, func)); }
};
template < typename _XprType > class redux_evaluator {
public:
  typedef _XprType cd;
  redux_evaluator(cd bs) : m_evaluator(bs), m_xpr(bs) {}
  typedef typename cd::bg bg;
  template < int bw, typename ay > ay dn(x di, x dj) {
    return m_evaluator.template bx< bw, ay >(dj, di);
  }
  br< cd > m_evaluator;
  cd m_xpr;
};
template < typename as >
template < typename Func >
typename ad< as >::bg bf< as >::bl(const Func &func) const {
  typedef redux_evaluator< as > ThisEvaluator;
  ThisEvaluator thisEval(bh());
  redux_impl< Func, ThisEvaluator >::dl(thisEval, func);
}
template < typename as > typename ad< as >::bg bf< as >::bj() const {
  bl(bc());
}
template < typename ExpressionType >
struct ad< al< ExpressionType > > : ad< typename ExpressionType::cv > {};
template < typename > class al : public ap< al< ai< double, 2, 1 > > > {
public:
  typedef aq::ar ck;
  al(const ai< double, 2, 1 > &dg) : m_expression(dg) {}
  const ai< double, 2, 1 > &dd() { return m_expression; }
  ck m_expression;
};
typedef ai< double, 2, 1 > Vector2d;
class OnHoverHandlerGraphicsItem {
public:
  static Vector2d corners;
};
GasGraphicsItemcreateOnHoverHandler() {
  Vector2d l;
  (l - OnHoverHandlerGraphicsItem::corners.array()).bo();
}
>From gcc-bugs-return-602494-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 17:35:04 2018
Return-Path: <gcc-bugs-return-602494-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 72239 invoked by alias); 23 Apr 2018 17:35:04 -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 72150 invoked by uid 48); 23 Apr 2018 17:34:59 -0000
From: "segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
Date: Mon, 23 Apr 2018 17:35: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: 8.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: segher at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority cc
Message-ID: <bug-85503-4-QYXRRwlbJO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85503-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85503-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: 2018-04/txt/msg02618.txt.bz2
Content-length: 370

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |segher at gcc dot gnu.org
>From gcc-bugs-return-602495-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 17:38:16 2018
Return-Path: <gcc-bugs-return-602495-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 79435 invoked by alias); 23 Apr 2018 17: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 77058 invoked by uid 48); 23 Apr 2018 17:38:12 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"
Date: Mon, 23 Apr 2018 17: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: 7.3.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-85470-4-QyygqdHlCq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85470-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85470-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: 2018-04/txt/msg02619.txt.bz2
Content-length: 378

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
>From gcc-bugs-return-602496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 17:39:50 2018
Return-Path: <gcc-bugs-return-602496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 125547 invoked by alias); 23 Apr 2018 17:39:50 -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 123221 invoked by uid 48); 23 Apr 2018 17:39:46 -0000
From: "segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/85503] [8 Regression] ICE in replace_swapped_load_constant, at config/rs6000/rs6000-p8swap.c:1853 on powerpc64le-linux-gnu
Date: Mon, 23 Apr 2018 17:39: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: 8.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: segher at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 8.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: target_milestone
Message-ID: <bug-85503-4-oryQEkjHuO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85503-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85503-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: 2018-04/txt/msg02620.txt.bz2
Content-length: 296

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |8.0
>From gcc-bugs-return-602497-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 18:52:37 2018
Return-Path: <gcc-bugs-return-602497-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 39812 invoked by alias); 23 Apr 2018 18:52:37 -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 39767 invoked by uid 48); 23 Apr 2018 18:52:32 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/85504] New: Bogus -Wrestrict warning with -fsanitize=undefined
Date: Mon, 23 Apr 2018 18:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone attachments.created
Message-ID: <bug-85504-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: 2018-04/txt/msg02621.txt.bz2
Content-length: 3075

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

            Bug ID: 85504
           Summary: Bogus -Wrestrict warning with -fsanitize=undefined
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Created attachment 44008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44008&action=edit
unreduced test case

This happens with current openssl trunk revision:

./config -fsanitize=undefined --strict-warnings

$ gcc  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64  -Wa,--noexecstack
-DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare
-Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3
-fsanitize=undefined -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM
-DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\""
-DNDEBUG  -MMD -MF crypto/engine/eng_ctrl.d.tmp -MT crypto/engine/eng_ctrl.o -c
-o crypto/engine/eng_ctrl.o crypto/engine/eng_ctrl.c
crypto/engine/eng_ctrl.c: In function 'ENGINE_ctrl':
crypto/engine/eng_ctrl.c:110:23: error: 'strcpy' source argument is the same as
destination [-Werror=restrict]
         return strlen(strcpy(s, cdp->cmd_name));
                       ^~~~~~~~~~~~~~~~~~~~~~~~

while I can use -save-temps with this one (see attached test case)
there is another file which does not show the error with -save-temps:

$ gcc  -I. -Iinclude -Iapps -pthread -m64  -Wa,--noexecstack -DDEBUG_UNUSED
-DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes
-Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined
-DNDEBUG  -MMD -MF apps/s_client.d.tmp -MT apps/s_client.o -c -o
apps/s_client.o apps/s_client.c

In file included from /usr/include/string.h:635,
                 from apps/s_client.c:15:
apps/s_client.c: In function 's_client_main':
apps/s_client.c:2585:13: error: '__builtin_strncpy' source argument is the same
as destination [-Werror=restrict]
             strncpy(sbuf, mbuf, 2);
             ^~~~~~~

$ gcc  -I. -Iinclude -Iapps -pthread -m64  -Wa,--noexecstack -DDEBUG_UNUSED
-DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wswitch -Wsign-compare -Wmissing-prototypes
-Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wall -O3 -fsanitize=undefined
-DNDEBUG  -MMD -MF apps/s_client.d.tmp -MT apps/s_client.o -c -o
apps/s_client.o apps/s_client.c -save-temps
>From gcc-bugs-return-602498-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 23 19:04:07 2018
Return-Path: <gcc-bugs-return-602498-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 68135 invoked by alias); 23 Apr 2018 19:04:07 -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 68115 invoked by uid 89); 23 Apr 2018 19:04:06 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=our
X-HELO: mail-pf0-f180.google.com
Received: from mail-pf0-f180.google.com (HELO mail-pf0-f180.google.com) (209.85.192.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Apr 2018 19:04:05 +0000
Received: by mail-pf0-f180.google.com with SMTP id g14so10082325pfh.3        for <gcc-bugs@gcc.gnu.org>; Mon, 23 Apr 2018 12:04:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d\x1e100.net; s 161025;        h=x-gm-message-state:subject:to:references:from:message-id:date         :user-agent:mime-version:in-reply-to:content-language         :content-transfer-encoding;        bh=TYJ3vVwu1Po+f4zHOckJwgipDUfQUIUBg2YRR/lxhHE=;        bûchohrD1+sSC8svGnOmPGLHuVLOAeacdgO12JtlOagRNiaS/i42DiQc0xc/ApPPnO         u33Ifq5488YbXr0wgTRMfA+5LrGTLzP8kZGYia/jjyGd24Gx9xm3yM99DRZiSBbuA+2S         d4Vch3MoS2hoH2YWhC6PRh3EbUq4TlLfeMT++fCHMfOnv0p2yTCzFY/JHCCoFwLOdEcO         5VnJIOHFt2MytDv8YrrM1dxf0yb0yVpmQDmsNw9KMIg+dGZ3v0tDjGFim1t+r7jI08ik         pNn3cblS7UL8u6qy3NklzzOf0qTZyMDMM+hPBpFINB7ipAMRqJr+Lm72KbNhqnx8CRjE         4nVg=X-Gm-Message-State: ALQs6tC8eCakbNBTQny+SsK+b/L/Jaxtqg5liUtaOtnUTQg1HQWq2i4n	+03rzIrlW3g+NMZkpw++9wvQ+1ZgOcAX-Google-Smtp-Source: AIpwx4/EmMDYFy4mpEoKNxUsQNusb44bM54IsJE4tu/LmXWbRIUNDhWmdBCWJDSuhNXbUF6c6XkpOw=X-Received: by 10.98.186.26 with SMTP id k26mr21255255pff.195.1524510243638;        Mon, 23 Apr 2018 12:04:03 -0700 (PDT)
Received: from [10.17.0.102] ([12.206.222.5])        by smtp.gmail.com with ESMTPSA id x14sm24461134pgo.82.2018.04.23.12.04.02        (version=TLS1_2 cipherìDHE-RSA-AES128-GCM-SHA256 bits\x128/128);        Mon, 23 Apr 2018 12:04:02 -0700 (PDT)
Subject: Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint
To: Jason Vas Dias <jason.vas.dias@gmail.com>, gcc-bugs@gcc.gnu.org
References: <o9iac8sg.fsf@gmail.com>
From: Jim Wilson <jimw@sifive.com>
Message-ID: <f0aa39a7-cdae-764c-3273-298a96899261@sifive.com>
Date: Mon, 23 Apr 2018 19:04:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <o9iac8sg.fsf@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-04/txt/msg02622.txt.bz2
Content-length: 1367

On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
>
> I really do not think a '-Wpedantic -Wconversion' warning should
> be generated for the following code, but it is
> (with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
>
>   $ echo '
>   typedef unsigned short U16_t;
>   static void f(void)
>   { U16_t a = 1;
>     a-=1;
>   }' > t.C;

gcc@gcc.gnu.org dropped as inappropriate.  Note that gcc-bugs is output
from our bugzilla.  Sending email here isn't very useful.  If you want a
bug fixed, you have to open a bug report in bugzilla.  You can ask gcc
questions on gcc help.

In the C language, operations on short and always performed as int, and
then converted back to short.  Subtracting one may generated a negative
number, which converted to unsigned short will change its value.  So the
warning seems appropriate.

Note that -Wconversion means different things in different gcc versions.
  It current meaning is to warn for any implicit cast that may change a
value.  This is not very useful in general, and is not an option that I
would recommend using by default.  In old gcc versions, -Wconversion
warned for code that had different meaning in K&R C and ISO C.  That was
useful, and some people used that option by default, but the option no
longer does that.

You can silence the warning by adding an explicit cast.
    a = (U16_t) (a - 1);

Jim