[Bug target/63937] [5 Regression] Compiling large arrays fails

["fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.greenhalgh@arm.com>