[Bug target/57156] New: miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[Bug target/57156] New: miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

             Bug #: 57156
           Summary: miscompilation of call to _mm_cmpeq_epi8(a, a) or
                    _mm_comtrue_epu8(a, a) with uninitialized a
    Classification: Unclassified
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: kretz@kde.org


Testcase:

#include <x86intrin.h>

static inline __m128 allone() {
    __m128i a;
#ifdef __XOP__
    return _mm_castsi128_ps(_mm_comtrue_epu8(a, a));
#else
    return _mm_castsi128_ps(_mm_cmpeq_epi8(a, a));
#endif
}
struct X {
    explicit X() : k(allone()) {}
    explicit X(bool b) : k(b ? allone() : _mm_setzero_ps()) {}
    bool operator!=(const X &rhs) const { return _mm_movemask_ps(k) !=
_mm_movemask_ps(rhs.k); }
    __m128 k;
};
int main() {
    if (X() != X(true)) {
        __builtin_abort();
    }
    return 0;
}

Compile with "g++ -O1 -msse2" or "g++ -O1 -mxop". If you initialize 'a' with
_mm_setzero_si128() the problem disappears.

[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

Matthias Kretz <kretz at kde dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.7.0, 4.7.1, 4.7.2, 4.8.0

--- Comment #1 from Matthias Kretz <kretz at kde dot org> 2013-05-03 09:10:31 UTC ---
This testcase also fails with GCC 4.6 if you use -O2.

[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

--- Comment #2 from Matthias Kretz <kretz at kde dot org> 2013-05-03 09:15:33 UTC ---
The failure disappears with -fno-tree-ccp

[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-05-03 09:16:20 UTC ---
I think this is undefined code as you use a uninitialized.

[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

--- Comment #4 from Matthias Kretz <kretz at kde dot org> 2013-05-03 09:37:58 UTC ---
(In reply to comment #3)
> I think this is undefined code as you use a uninitialized.

I wouldn't know how to counter this for the _mm_cmpeq_epi8 case, but for
_mm_comtrue_epu8? How am I supposed to use this intrinsic?

[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

--- Comment #5 from Matthias Kretz <kretz at kde dot org> 2013-05-03 09:56:00 UTC ---
(In reply to comment #4)
> I wouldn't know how to counter this for the _mm_cmpeq_epi8 case

Actually, I have yet to find something in the standard that says using an
uninitialized __m128 is undefined behavior. ;)
Thus the only standard that would define the rules here would be Intel's, no?
And from reading their docs I understand that calling an intrinsics maps to the
behavior you'd get when using the associated instruction. In this case
comparing any XMM register with itself will result in what I expect.

[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2013-05-03 12:27:05 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > I wouldn't know how to counter this for the _mm_cmpeq_epi8 case
> 
> Actually, I have yet to find something in the standard that says using an
> uninitialized __m128 is undefined behavior. ;)
> Thus the only standard that would define the rules here would be Intel's, no?
> And from reading their docs I understand that calling an intrinsics maps to the
> behavior you'd get when using the associated instruction. In this case
> comparing any XMM register with itself will result in what I expect.

The standard says that using uninitialized variables invoke undefined
behavior.  That doesn't magically exclude types that are not explicitely
covered by the standard.  Doing

 int a;
 _Bool true = a == a;

is undefined as well, so is

 int a;
 int zero = a ^ a;

You cannot translate optimized assembler back to C in this way.

Well, you can.  Sth like

 register int a asm("eax");
 int zero = a ^ a;

should do it.

[Bug tree-optimization/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

Matthias Kretz <kretz at kde dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |tree-optimization

--- Comment #7 from Matthias Kretz <kretz at kde dot org> 2013-05-03 14:13:30 UTC ---
(In reply to comment #6)
> The standard says that using uninitialized variables invoke undefined
> behavior.

Is this §4.1p1: Lvalue-to-rvalue conversion?
"[...] if the object is uninitialized, a program that necessitates this
conversion has undefined behavior"

> That doesn't magically exclude types that are not explicitely
> covered by the standard.

True.

> You cannot translate optimized assembler back to C in this way.
> 
> Well, you can.  Sth like
> 
>  register int a asm("eax");
>  int zero = a ^ a;
> 
> should do it.

Interesting. But then I'd rather use:
 int a;
 asm("xor %0,%0":"=r"(a));
so that GCC can determine what register to use. I wanted to avoid this, though.
Because with inline asm I expect that the compiler does not know how cheap this
call really is.

Still, I'm wondering how _mm_comtrue_epu8 is meant to be used. The intrinsic
returns 11...1 independent of the input. It shouldn't have any arguments in the
first place, but it does. And just passing it anything doesn't work reliably...
>From gcc-bugs-return-421550-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 03 14:19:31 2013
Return-Path: <gcc-bugs-return-421550-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7611 invoked by alias); 3 May 2013 14:19:31 -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 7546 invoked by uid 55); 3 May 2013 14:19:23 -0000
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
Date: Fri, 03 May 2013 14:19: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-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57038-4-jLMH7esUxE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57038-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57038-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00223.txt.bz2
Content-length: 416


http://gcc.gnu.org/bugzilla/show_bug.cgi?idW038

--- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> 2013-05-03 14:19:22 UTC ---
Hi,
I can not find any symbol
ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev in the
preprocessed file you added.  Can you check if the symbol appears in LTO symbol
table for you in that .o object?
Did you preprocessed it with the same -D options?

Honza

[Bug tree-optimization/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[kretz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

--- Comment #8 from Matthias Kretz <kretz at kde dot org> ---
I just noticed the following in the Intel Optimization Reference Manual
(Version 028 from July 2013), section 2.2 "Sandy Bridge":
2.2.3.1 Renamer
[...]
There is another dependency breaking idiom - the "ones idiom".
• CMPEQ XMM1, XMM1; "ones idiom" set all elements to all "ones"
In this case, the micro-op must execute, however, since it is known that
regardless of the input data the output data is always "all ones" the micro-op
dependency upon its sources does not exist as with the zero idiom and it can
execute as soon as it finds a free execution port.

Therefore I think it makes sense if this feature is exposed somehow. Right now,
according to what you said, it is impossible to make use of this feature when
programming with intrinsics.
I see two solutions right now:
1. Let the cmpeq intrinsic reflect this special behavior: i.e. if the two
inputs are the same variable, this behaves like a function without input.
2. Provide a new intrinsic/builtin analogous to _mm_setzero_* /
_mm256_setzero_*
>From gcc-bugs-return-426138-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 11 09:45:34 2013
Return-Path: <gcc-bugs-return-426138-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16943 invoked by alias); 11 Jul 2013 09:45:34 -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 16927 invoked by uid 48); 11 Jul 2013 09:45:31 -0000
From: "bardeau at iram dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/57881] New: Pre-processor pre-includes breaks preprocessing of non C/C++ code
Date: Thu, 11 Jul 2013 09:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bardeau at iram dot fr
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
Message-ID: <bug-57881-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: 2013-07/txt/msg00645.txt.bz2
Content-length: 1721

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW881

            Bug ID: 57881
           Summary: Pre-processor pre-includes breaks preprocessing of non
                    C/C++ code
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bardeau at iram dot fr

According to http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Standards.html the C
pre-precessor includes implicitly the file /usr/include/stdc-predef.h to any
pre-processed source.

For non C/C++ code, we are told here http://gcc.gnu.org/gcc-4.8/porting_to.html
to add the option -P. This just won't work in real use cases. People using the
C preprocessor on non C/C++ code combine the following options:
-P: no line markers added,
-C: do not discard comments. In non-C/C++ code, false-positive blocks of /* */
could be deleted out.
-traditional-cpp: preserve blank lines. In non C/C++ code, blank lines may be
relevant. At least, it preserves line numbering.

Obviously, pre-preprocessing of non-C/C++ code with "cpp -P -C -traditional"
adds now C comments and blank lines. Its certainly a feature, not a bug, but:

1) you should modify the comment in http://gcc.gnu.org/gcc-4.8/porting_to.html:
"For non C/C++ code, use the pre-processor flag -ffreestanding" for full
compatibility with possible options.

2) the option "-ffreestanding" has no meaning for non C/C++ code. You should
consider adding an option for preprocessing of non C/C++ sources, which gathers
the options "-P -C -traditional -ffreestanding", plus any future change needed.

Thanks for having a look into this!

[Bug tree-optimization/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |INVALID

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Using uninitialized objects results in undefined behaviour according to the
standards.  This is not a bug.