https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63937
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-apple-darwin14
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-11-18
Component|fortran |target
CC| |amylaar at gcc dot gnu.org,
| |jgreenhalgh at gcc dot gnu.org
Host| |x86_64-apple-darwin14
Ever confirmed|0 |1
Summary|[5 Regression] Compiling a |[5 Regression] Compiling
|very simple fortran code |large arrays fails
|fails. |
Target Milestone|--- |5.0
Build| |x86_64-apple-darwin14
--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I can confirm, and can provide a C testcase (on x86_64-apple-darwin14 with
trunk r217694):
$ cat a.c
void foo (void)
{
int v[1073741825] = {};
}
$ ./bin/gcc a.c
[blows up]
And I know it sounds weird, but the behavior depends on the exact value of the
array size, in a deterministic manner. It fails for 1073741825 (every time),
but works with both 1003741825 (smaller) and 1173741825 (bigger).
I stopped it at some random moments in this long "freeze", and the stable part
of the backtrace is:
frame #4: 0x00000001005c662a cc1`store_by_pieces_1 + 183 at expr.c:2721
frame #5: 0x00000001005c6573 cc1`store_by_pieces_1(data=0x00007fff5fbff190,
align=64) + 275
frame #6: 0x00000001005d98d0 cc1`clear_storage_hints(rtx_def*, rtx_def*,
block_op_methods, unsigned int, long long, unsigned long long, unsigned long
long, unsigned long long) + 58 at expr.c:2605
frame #7: 0x00000001005d9896
cc1`clear_storage_hints(object=0x0000000142e44738, size=0x0000000142e46060,
method=BLOCK_OP_NORMAL, expected_align=0, expected_size=-1,
min_size=4294967300, max_size=4294967300, probable_max_size=4294967300) + 486
I'm not sure when that change occurred, but the only thing related to
"store_by_pieces" I could find in the ChangeLog is a series of commits:
2014-11-01 James Greenhalgh <james.greenha...@arm.com>
