Bug 48127 - Program crashes reading a non-aligned variable
Summary: Program crashes reading a non-aligned variable
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ssemmx, wrong-code
Depends on:
Blocks:
 
Reported: 2011-03-15 00:01 UTC by Dmitry Gorbachev
Modified: 2014-06-19 05:18 UTC (History)
3 users (show)

See Also:
Host:
Target: i686-pc-linux-gnu
Build:
Known to work: 4.8.4
Known to fail: 4.5.3, 4.6.0, 4.7.0
Last reconfirmed:


Attachments
Testcase (304 bytes, text/plain)
2011-03-15 00:01 UTC, Dmitry Gorbachev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Gorbachev 2011-03-15 00:01:43 UTC
Created attachment 23657 [details]
Testcase

(See also: <http://sourceware.org/PR12578>.)
Comment 1 Dmitry Gorbachev 2011-03-15 06:22:13 UTC
Works when changing the number of elements in baz to 8.
Comment 2 Richard Biener 2011-03-15 10:27:39 UTC
I think the testcase is invalid as you have two definitions of baz which
are not both common.

The vectorizer relies on being able to promote alignment of definitions
which I'm not sure it can do so for commons (it would rely on the linker
choosing the common with the largest alignment).

A testcase that works with -fno-common would be more convincing here ;)
Comment 3 Dmitry Gorbachev 2011-03-15 18:00:23 UTC
I do not agree that the testcase is invalid. As the standart says:

  Common extensions

  Multiple external definitions

     There may be more than one external definition for the identifier of
  an object, with or without the explicit use of the keyword extern; if
  the definitions disagree, or more than one is initialized, the behavior
  is undefined.

According to the Binutils documentation,

  The linker turns a common symbol into a declaration, if there is a
  definition of the same variable.

Also, from Ian Lance Taylor's article [1]:

  5. If A is a strong definition in an object file:

    * If B is a common symbol, then we treat B as an undefined reference.

I think it would be better to fix this problem in the linker. Gold does not even warn about it!

However, I don't understand why GCC makes baz[8] to have 32 bytes alignment, while baz[4] has only 4 bytes alignment. It seems to be a GCC bug.

When baz is declared extern in main.c, the generated code is correct, but less optimal.


1. http://www.airs.com/blog/archives/49
Comment 4 rguenther@suse.de 2011-03-16 09:40:35 UTC
On Tue, 15 Mar 2011, d.g.gorbachev at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48127
> 
> --- Comment #3 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-03-15 18:00:23 UTC ---
> I do not agree that the testcase is invalid. As the standart says:
> 
>   Common extensions
> 
>   Multiple external definitions
> 
>      There may be more than one external definition for the identifier of
>   an object, with or without the explicit use of the keyword extern; if
>   the definitions disagree, or more than one is initialized, the behavior
>   is undefined.
> 
> According to the Binutils documentation,
> 
>   The linker turns a common symbol into a declaration, if there is a
>   definition of the same variable.
> 
> Also, from Ian Lance Taylor's article [1]:
> 
>   5. If A is a strong definition in an object file:
> 
>     * If B is a common symbol, then we treat B as an undefined reference.
> 
> I think it would be better to fix this problem in the linker. Gold does not
> even warn about it!
> 
> However, I don't understand why GCC makes baz[8] to have 32 bytes alignment,
> while baz[4] has only 4 bytes alignment. It seems to be a GCC bug.

It's an optimization to ensure accesses larger than 4 do not cross
cacheline boundaries.

Richard.
Comment 5 Dmitry Gorbachev 2014-06-19 05:18:04 UTC
GCC 4.8.4 (and recent 4.9, 4.10) do not generate SSE instructions for this testcase.