public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory
@ 2013-08-01  4:52 bar at mariadb dot org
  2013-08-06  9:55 ` [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a " bar at mariadb dot org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: bar at mariadb dot org @ 2013-08-01  4:52 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 58039
           Summary: -ftree-vectorizer make a loop crash on non-aligned
                    memory
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bar at mariadb dot org

Created attachment 30578
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30578&action=edit
The program that repeats the report crash

If I compile the attached program using:

gcc -Wall -O2 -fno-inline -ftree-vectorize -ftree-vectorizer-verbose=2 a.c

it crashes with "segmentation fault".


$ gcc --version
gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)

Processor: Intel® Core™ i7-3520M CPU @ 2.90GHz × 4


The program is a minimal extract from the MariaDB-10.0 sources
that reproduces the crash.

The GCC flags that are actually used in the debug build of MariaDB are:
gcc -Wall -O3 -fno-inline a.c

but after tracking it down we noticed that the actually reason is
-ftree-vectorize.
>From gcc-bugs-return-427079-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 01 05:18:35 2013
Return-Path: <gcc-bugs-return-427079-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28569 invoked by alias); 1 Aug 2013 05:18: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 28481 invoked by uid 48); 1 Aug 2013 05:18:31 -0000
From: "bar at mariadb dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/58039] -ftree-vectorizer make a loop crash on non-aligned memory
Date: Thu, 01 Aug 2013 05:18: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: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: bar at mariadb 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-58039-4-c3rt32eusL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58039-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58039-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-08/txt/msg00003.txt.bz2
Content-length: 225

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

--- Comment #1 from Alexander Barkov <bar at mariadb dot org> ---
The bug is known to repeat on the following operating systems:

- Fedora 17
- Ubuntu 13.04
- OpenSUSE 11.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
  2013-08-01  4:52 [Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory bar at mariadb dot org
@ 2013-08-06  9:55 ` bar at mariadb dot org
  2013-08-07  9:15 ` mikpe at it dot uu.se
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: bar at mariadb dot org @ 2013-08-06  9:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Alexander Barkov <bar at mariadb dot org> ---
Any updates? Thanks.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
  2013-08-01  4:52 [Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory bar at mariadb dot org
  2013-08-06  9:55 ` [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a " bar at mariadb dot org
@ 2013-08-07  9:15 ` mikpe at it dot uu.se
  2013-08-12 10:32 ` bar at mariadb dot org
  2013-08-12 12:18 ` mikpe at it dot uu.se
  3 siblings, 0 replies; 5+ messages in thread
From: mikpe at it dot uu.se @ 2013-08-07  9:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> ---
Your code performs mis-aligned uint16_t stores, which x86 allows.  The
vectorizer turns those into larger and still mis-aligned `movdqa' stores, which
x86 does not allow, hence the SEGV.

Replace the non-portable mis-aligned stores with portable code like

#define int2store_little_endian(s,A) memcpy((s), &(A), 2)

or gcc-specific code like

struct __attribute__((__packed__)) packed_uint16 {
    uint16_t u16;
};
#define int2store_little_endian(s,A) ((struct packed_uint16*)(s))->u16 = (A)

and then the vectorizer generates large `movdqu' stores, which is pretty much
the best you can hope for unless you rewrite the code to avoid mis-aligned
stores.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
  2013-08-01  4:52 [Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory bar at mariadb dot org
  2013-08-06  9:55 ` [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a " bar at mariadb dot org
  2013-08-07  9:15 ` mikpe at it dot uu.se
@ 2013-08-12 10:32 ` bar at mariadb dot org
  2013-08-12 12:18 ` mikpe at it dot uu.se
  3 siblings, 0 replies; 5+ messages in thread
From: bar at mariadb dot org @ 2013-08-12 10:32 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Alexander Barkov <bar at mariadb dot org> ---
Mikael, thanks for  your comment on this.

(In reply to Mikael Pettersson from comment #3)
> Your code performs mis-aligned uint16_t stores, which x86 allows.

Right, this is done for performance purposes.


> The
> vectorizer turns those into larger and still mis-aligned `movdqa' stores,
> which x86 does not allow, hence the SEGV.

Can you please clarify: is it a bug in the recent gcc versions?

Note, we've used such performance improvement tricks for years.
It worked perfectly fine until now.
Has anything changed in how the gcc vectorizer works recently?


> 
> Replace the non-portable mis-aligned stores with portable code like
> 
> #define int2store_little_endian(s,A) memcpy((s), &(A), 2)
> 
> or gcc-specific code like
> 
> struct __attribute__((__packed__)) packed_uint16 {
>     uint16_t u16;
> };
> #define int2store_little_endian(s,A) ((struct packed_uint16*)(s))->u16 = (A)
> 
> and then the vectorizer generates large `movdqu' stores, which is pretty
> much the best you can hope for unless you rewrite the code to avoid
> mis-aligned stores.


Unfortunately it's not possible to avoid mis-aligned stores due to the
project architecture.


I've read somewhere that gcc vectorizer generates two code branches,
for aligned memory and for non-aligned memory (but can't find
the reference now). Can you please confirm this?

Thanks.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
  2013-08-01  4:52 [Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory bar at mariadb dot org
                   ` (2 preceding siblings ...)
  2013-08-12 10:32 ` bar at mariadb dot org
@ 2013-08-12 12:18 ` mikpe at it dot uu.se
  3 siblings, 0 replies; 5+ messages in thread
From: mikpe at it dot uu.se @ 2013-08-12 12:18 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Mikael Pettersson <mikpe at it dot uu.se> ---
(In reply to Alexander Barkov from comment #4)
> > The
> > vectorizer turns those into larger and still mis-aligned `movdqa' stores,
> > which x86 does not allow, hence the SEGV.
> 
> Can you please clarify: is it a bug in the recent gcc versions?
> 
> Note, we've used such performance improvement tricks for years.
> It worked perfectly fine until now.
> Has anything changed in how the gcc vectorizer works recently?

I know next to nothing about the vectorizer, so I cannot comment on this.

> Unfortunately it's not possible to avoid mis-aligned stores due to the
> project architecture.

Mis-aligned accesses are Ok, as long as they are expressed using the proper
mechanisms (memcpy, attribute packed, or pragma packed).

> I've read somewhere that gcc vectorizer generates two code branches,
> for aligned memory and for non-aligned memory (but can't find
> the reference now). Can you please confirm this?

I don't know, see above.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-08-12 12:18 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-01  4:52 [Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory bar at mariadb dot org
2013-08-06  9:55 ` [Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a " bar at mariadb dot org
2013-08-07  9:15 ` mikpe at it dot uu.se
2013-08-12 10:32 ` bar at mariadb dot org
2013-08-12 12:18 ` mikpe at it dot uu.se

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).