[Bug rtl-optimization/45962] New: [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[Bug rtl-optimization/45962] New: [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

           Summary: [4.6 Regression]: many c/c++ failures on cris-elf, in
                    r165236:165242
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, wrong-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hp@gcc.gnu.org
                CC: rth@gcc.gnu.org
              Host: x86_64-unknown-linux-gnu
            Target: cris-axis-elf


Created attachment 22013
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22013
Preprocessed gcc.dg-struct-layout-1//t001_x.c.  Run cc1 -w -quiet
-fpreprocessed t001_x.i

With revision 165236 these tests passed.
>From revision 165242 and on, these tests have failed as follows (cutnpasted,
bad wrapping):
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O1
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O2
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -Os
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O2 -fwhopr
... (non-regressions elided)
FAIL: gcc.c-torture/execute/simd-5.c execution,  -O0
... (non-regressions elided)
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/compat/compat.exp ...
FAIL: gcc.dg/compat/vector-1 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o execute
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ...
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_y_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_y_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t012 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t014 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t015 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t017 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t018 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t019 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t020 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t021 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t022 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t023 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_y_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_y_tst.o compile,  (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o
execute
... (non-regressions elided)
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/stackalign/stackalign.exp
...
FAIL: gcc.dg/torture/stackalign/nested-1.c  -O0  execution test
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O0  execution test
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O1  execution test
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2  execution test
FAIL: gcc.dg/torture/stackalign/nested-2.c  -Os  execution test
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/torture/stackalign/nested-3.c  -O0  execution test
FAIL: gcc.dg/torture/stackalign/nested-3.c  -O1  execution test
FAIL: gcc.dg/torture/stackalign/nested-3.c  -O2  execution test
FAIL: gcc.dg/torture/stackalign/nested-3.c  -Os  execution test
FAIL: gcc.dg/torture/stackalign/nested-3.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/stackalign/nested-3.c  -O2 -fwhopr  execution test

With the messages in the logfile being:
PASS: gcc.c-torture/execute/20060420-1.c compilation,  -O1
program stopped with signal 6.^M
FAIL: gcc.c-torture/execute/20060420-1.c execution,  -O1
...
PASS: gcc.c-torture/execute/simd-5.c compilation,  -O0
program stopped with signal 6.^M
FAIL: gcc.c-torture/execute/simd-5.c execution,  -O0
...
PASS: gcc.dg/compat/vector-1 c_compat_x_tst.o-c_compat_y_tst.o link
core: 4 byte misaligned write to address 0x68676665 at 0xeb0^M
program stopped with signal 10.^M
...

Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/  -w -I/tmp\
/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/compat -Wno-abi -DSKIP_DECIMAL_FLOAT
-DSKIP_DECIMAL_FLOAT -c   -isystem /tmp/\
hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include  -\
o c_compat_x_tst.o
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_x.c
   (timeout \
= 300)
In file included from
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_x.c:9:0:^M
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_test.h:
In function 'test85':^M
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_test.h:86:1:
internal compiler erro\
r: Segmentation fault^M
...
PASS: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link
core: 4 byte misaligned read to address 0x871fd41f at 0x5500^M
program stopped with signal 10.^M
FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o
execute

other messages similar.

Author of patches in suspect revision range CC:ed.

(I'll provide basic analysis for the execution failures if fixing the
compilation SEGV's don't fix them too.)

[Bug rtl-optimization/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2010.10.11 17:27:01
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-11 17:27:01 UTC ---
Please give me pre-processed sources to test.  I tried building a
cross-toolchain to cris-elf, but I don't see that failure.  I see
many others due to what appear to be newlib bugs, but no compiler
crash.

[Bug rtl-optimization/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-11 17:37:46 UTC ---
(In reply to comment #1)
> Please give me pre-processed sources to test.  I tried building a
> cross-toolchain to cris-elf, but I don't see that failure.  I see
> many others due to what appear to be newlib bugs, but no compiler
> crash.

But you already have that with options for cc1!

[Bug rtl-optimization/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

[Bug rtl-optimization/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |rth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #3 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-11 18:12:10 UTC ---
Sorry, I don't know how I didn't see the attachment.

The problem is related to the computation of the size
of an area including a variable of zero size:

 <var_decl 0x7ffff19d50a0 D.16659
    type <record_type 0x7ffff1ae4150 S85 type_0 BLK
        size <integer_cst 0x7ffff1e1fa28 constant 0>
        unit size <integer_cst 0x7ffff1e1f320 constant 0>
        user align 32 ...>

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|rtl-optimization            |middle-end
         Resolution|                            |FIXED

--- Comment #4 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-11 22:45:57 UTC ---
Fixed.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-12 02:31:08 UTC ---
(In reply to comment #4)
> Fixed.

Not really until it's committed.  Pending approval?  Or a missing git2svn push?

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-12 15:53:21 UTC ---
Author: rth
Date: Tue Oct 12 15:53:15 2010
New Revision: 165382

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165382
Log:
PR middle-end/45962
    * cfgexpand.c (add_stack_var): Ensure every variable has 1 byte.
    (expand_stack_vars): Assert large base allocated when used.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-12 15:55:09 UTC ---
Bah.  Changelog conflict and I wasn't paying attention.  Done now.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #8 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-12 19:30:20 UTC ---
I have to reopen this: the SEGV ICE is gone, but no regressions were fixed;
it's all execution errors now, at r165383.  I'll see which of the test codes is
the best to show the miscompilation.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-12 20:23:26 UTC ---
I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0.
I'll compare r165239 to (r165240 plus your commit at r165382), ok?

Looking at r165240, I have a hunch that we're going to find a function call to
a libgcc function with the stack-pointer at an...awkward state.

cris.h:
#define BIGGEST_ALIGNMENT 8
#define STACK_BOUNDARY \
 (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8)
(i.e. 8 for cris-elf default.)

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-12 21:31:00 UTC ---
(In reply to comment #8)
> I have to reopen this: the SEGV ICE is gone, but no regressions were fixed...

These aren't technically regressions; these tests were never run previously.
I'm certain you'll find that ...

(In reply to comment #9)
> I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0.
> I'll compare r165239 to (r165240 plus your commit at r165382), ok?

... these tests fail with r165239 too, if you run them by hand.  If you
just compare gcc.sum files of course they'll appear as new failures.

> #define STACK_BOUNDARY \
>  (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8)
> (i.e. 8 for cris-elf default.)

This is definitely wrong, according to the documentation in the opt file.

You'd either have to multilib on this option, or implement the full stack
re-alignment scheme supported by i386.  Unless you multilib:

STACK_BOUNDARY should be BITS_PER_UNIT always.

PREFERRED_STACK_BOUNDARY may vary depending on those options.

INCOMING_STACK_BOUNDARY ... I dunno, may need to be set to S_B;
the default is P_S_B, which seems wrong when P_S_B actually
varies.  Of course, i386 redefines this anyway, and no one else
currently varies.

MAX_STACK_ALIGNMENT should be MAX_OFILE_ALIGNMENT if you support
the full stack re-alignment scheme.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-12 21:55:26 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > I have to reopen this: the SEGV ICE is gone, but no regressions were fixed...
> 
> These aren't technically regressions; these tests were never run previously.
> I'm certain you'll find that ...
> 
> (In reply to comment #9)
> > I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0.
> > I'll compare r165239 to (r165240 plus your commit at r165382), ok?
> 
> ... these tests fail with r165239 too, if you run them by hand.  If you
> just compare gcc.sum files of course they'll appear as new failures.

Incorrect.  I don't see what makes you say that.

> > #define STACK_BOUNDARY \
> >  (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8)
> > (i.e. 8 for cris-elf default.)
> 
> This is definitely wrong, according to the documentation in the opt file.

Uh... what?  Ok, it's been a while since I wrote that part (which you can see
by the comment at the top of that macro!) so I might have to revisit that but
any such observation is incidental, because...

> You'd either have to multilib on this option, or implement the full stack
> re-alignment scheme supported by i386.  Unless you multilib:
> 
> STACK_BOUNDARY should be BITS_PER_UNIT always.

...it is; constant 8, for the purpose of this PR, as none of the options are
active.

Let's see how we can best proceed here.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #12 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-12 22:05:48 UTC ---
(In reply to comment #11)
> > ... these tests fail with r165239 too, if you run them by hand.  If you
> > just compare gcc.sum files of course they'll appear as new failures.
> 
> Incorrect.  I don't see what makes you say that.

You don't agree they're new tests, or you don't agree that they
will fail when run by hand on the older compiler?

> > STACK_BOUNDARY should be BITS_PER_UNIT always.
> 
> ...it is; constant 8, for the purpose of this PR, as none of the options are
> active.

Fine.  But just so you know that you have a couple of options
that don't do what they say in the documentation, you can 
clean that up separately.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #13 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-12 22:15:46 UTC ---
(In reply to comment #12)
> You don't agree they're new tests, or you don't agree that they
> will fail when run by hand on the older compiler?

Both. They exist and run and PASS at r165239, like I wrote initially.
Why would they be new tests or fail before?  I don't see that.

FWIW, I'm studying the (differences in) simulator traces right now.
I may have to timeout for Z's...

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #14 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-12 22:49:23 UTC ---
Created attachment 22025
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22025
tarball with asm files and somewhat readable simulator traces

Just dumping state.  Not expecting anyone to follow it at this time, but then
again it should be possible.

sok.txt: simulator trace using -O0 at r16539.
simd-5.s.ok: ditto generated assembly.
sbad.txt: simulator trace using -O0 at r165240+c165382.  (The assembly file
from gcc.c-torture/execute/simd-5.c was used together with the tree from r16539
to avoid mixing up e.g. miscompilations of libgcc.a or newlib.)
simd-5.s.bad: ditto generated assembly.

The cris-elf src/sim simulator says, for r165240+c165382, generating sbad.txt:
"core: 4 byte misaligned read to address 0x30002b at 0x486"
(where "misaligned" is a misnomer for "access to undefined memory")
On return to func2 register r7 is broken; it was saved on stack in func1, but
the location on stack has been clobbered.

I haven't yet figured out which function's stack-frame is borked / where
exactly the saved value of r7 is clobbered. Tomorrow.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #15 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-19 02:37:49 UTC ---
(In reply to comment #14)
> I haven't yet figured out which function's stack-frame is borked / where
> exactly the saved value of r7 is clobbered. Tomorrow.

Ookay, so... With r165240+c165382 and simd-5.c and -O0, gcc feels it needs to
dynamically (allocate and) align the stack-location for the resulting vectors,
though the vector alignment is neither explicit nor mandatory.  No such dynamic
allocation at r165239.  When doing so, it feels it needs to save the
stack-pointer.  That's redundant; it's already saved when a frame-pointer is
needed. It so emits "move.d $sp,[$r8-8]" (i.e. (set (mem (plus
frame_pointer_rtx -8)) stack_pointer_rtx)).  Where it gets the -8 from, I don't
know, I'll look further. That insn just clobbers; it overwrites a saved
register that held an address, which at return to the function, is referenced
and causes the SEGV.

Code at the two revisions are identical for -O1 as well as for-O2; no dynamic
allocation or anything needed, so I guess the new dynamic alignment at -O0 is
not an issue that needs to be investigated per se.


Regarding the earlier "these are not regressions, dammit"-type comments, I see
I made a boo-boo when quoting which failures were regressions: the new FAILs
from gcc.dg/torture/stackalign (13 of them) snuck in.  (To bystanders, the
c165240 "floodgated" check_effective_target_automatic_stack_alignment, but it's
only used in g++.dg/torture/stackalign and gcc.dg/torture/stackalign, outside
of gcc.target/i386/stackalign).

Here's the list of the 62 true regressions (by definition of
contrib/regression/btest-gcc.sh) caused by r165240(+c165382) for cris-elf:

g++.sum tmpdir-g++.dg-struct-layout-1/t001
g++.sum tmpdir-g++.dg-struct-layout-1/t002
g++.sum tmpdir-g++.dg-struct-layout-1/t003
g++.sum tmpdir-g++.dg-struct-layout-1/t004
g++.sum tmpdir-g++.dg-struct-layout-1/t005
g++.sum tmpdir-g++.dg-struct-layout-1/t006
g++.sum tmpdir-g++.dg-struct-layout-1/t007
g++.sum tmpdir-g++.dg-struct-layout-1/t008
g++.sum tmpdir-g++.dg-struct-layout-1/t009
g++.sum tmpdir-g++.dg-struct-layout-1/t010
g++.sum tmpdir-g++.dg-struct-layout-1/t011
g++.sum tmpdir-g++.dg-struct-layout-1/t012
g++.sum tmpdir-g++.dg-struct-layout-1/t013
g++.sum tmpdir-g++.dg-struct-layout-1/t014
g++.sum tmpdir-g++.dg-struct-layout-1/t015
g++.sum tmpdir-g++.dg-struct-layout-1/t016
g++.sum tmpdir-g++.dg-struct-layout-1/t017
g++.sum tmpdir-g++.dg-struct-layout-1/t018
g++.sum tmpdir-g++.dg-struct-layout-1/t019
g++.sum tmpdir-g++.dg-struct-layout-1/t020
g++.sum tmpdir-g++.dg-struct-layout-1/t021
g++.sum tmpdir-g++.dg-struct-layout-1/t022
g++.sum tmpdir-g++.dg-struct-layout-1/t023
g++.sum tmpdir-g++.dg-struct-layout-1/t024
g++.sum tmpdir-g++.dg-struct-layout-1/t025
g++.sum tmpdir-g++.dg-struct-layout-1/t026
g++.sum tmpdir-g++.dg-struct-layout-1/t027
g++.sum tmpdir-g++.dg-struct-layout-1/t028
g++.sum tmpdir-g++.dg-struct-layout-1/t029
g++.sum tmpdir-g++.dg-struct-layout-1/t030
gcc.sum gcc.c-torture/execute/20060420-1.c
gcc.sum gcc.c-torture/execute/simd-5.c
gcc.sum gcc.dg/compat/vector-1
gcc.sum gcc.dg/compat/vector-2
gcc.sum tmpdir-gcc.dg-struct-layout-1/t001
gcc.sum tmpdir-gcc.dg-struct-layout-1/t002
gcc.sum tmpdir-gcc.dg-struct-layout-1/t003
gcc.sum tmpdir-gcc.dg-struct-layout-1/t004
gcc.sum tmpdir-gcc.dg-struct-layout-1/t005
gcc.sum tmpdir-gcc.dg-struct-layout-1/t006
gcc.sum tmpdir-gcc.dg-struct-layout-1/t007
gcc.sum tmpdir-gcc.dg-struct-layout-1/t008
gcc.sum tmpdir-gcc.dg-struct-layout-1/t009
gcc.sum tmpdir-gcc.dg-struct-layout-1/t010
gcc.sum tmpdir-gcc.dg-struct-layout-1/t011
gcc.sum tmpdir-gcc.dg-struct-layout-1/t012
gcc.sum tmpdir-gcc.dg-struct-layout-1/t013
gcc.sum tmpdir-gcc.dg-struct-layout-1/t014
gcc.sum tmpdir-gcc.dg-struct-layout-1/t015
gcc.sum tmpdir-gcc.dg-struct-layout-1/t016
gcc.sum tmpdir-gcc.dg-struct-layout-1/t017
gcc.sum tmpdir-gcc.dg-struct-layout-1/t018
gcc.sum tmpdir-gcc.dg-struct-layout-1/t019
gcc.sum tmpdir-gcc.dg-struct-layout-1/t020
gcc.sum tmpdir-gcc.dg-struct-layout-1/t021
gcc.sum tmpdir-gcc.dg-struct-layout-1/t022
gcc.sum tmpdir-gcc.dg-struct-layout-1/t023
gcc.sum tmpdir-gcc.dg-struct-layout-1/t024
gcc.sum tmpdir-gcc.dg-struct-layout-1/t025
gcc.sum tmpdir-gcc.dg-struct-layout-1/t026
gcc.sum tmpdir-gcc.dg-struct-layout-1/t027
gcc.sum tmpdir-gcc.dg-struct-layout-1/t028

The initial description is missing the c++ part of the log, but I don't think
that adds anything interesting.  The important text for the C tests is already
there; just the gcc.dg/torture/stackalign results too.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW

--- Comment #16 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-19 15:49:02 UTC ---
(In reply to comment #15)
> ... though the vector alignment is neither explicit nor mandatory.

It's implicit in the DImode mode of the type.  If you'd like to reduce
the alignment of local variables, use the MINIMUM_ALIGNMENT macro; see
the i386 port for an example.

> No such dynamic allocation at r165239.

Yes, that's the whole point of the patch, to honor alignment as given.

> When doing so, it feels it needs to save the stack-pointer.  That's
> redundant; it's already saved when a frame-pointer is needed.

The cris port fails to define EXIT_IGNORE_STACK to indicate this.

Without that, the middle-end thinks it must save/restore sp around
the function.  Frankly, there's nothing otherwise unusual about this
new alloca from any other.  I guess you've just never noticed this
extra save previously?

> It so emits "move.d $sp,[$r8-8]" ...  Where it gets the -8 from, I don't
> know, I'll look further.

I assume that's a stack slot for a spilled pseudo?

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #17 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2010-10-19 22:21:43 UTC ---
(In reply to comment #10)
> MAX_STACK_ALIGNMENT should be MAX_OFILE_ALIGNMENT if you support
> the full stack re-alignment scheme.

Is there a particular reason it should be MAX_OFILE_ALIGNMENT?  The object file
features shouldn't matter for stack objects.  I'd think it should be something
like the minimum supported value for the equivalent of (ulimit -s) / 2, not an
easy value to get hold of though.

(In reply to comment #16)
> (In reply to comment #15)
> > ... though the vector alignment is neither explicit nor mandatory.
> 
> It's implicit in the DImode mode of the type.  If you'd like to reduce
> the alignment of local variables, use the MINIMUM_ALIGNMENT macro; see
> the i386 port for an example.

Hm, the default should fall back to effectively BIGGEST_ALIGNMENT unless
there's a specific __attribute__ ((__aligned__ (N))) in there.  That it
apparently doesn't is a bug; the defaults of the *_ALIGNMENT macros shouldn't
second-guess the basic alignment macros, increasing alignment.  (BTW, shouldn't
MINIMUM_ALIGNMENT default to STACK_ALIGNMENT? And be named
DYNAMIC_STACK_ALIGNMENT?)

Are you open to having that fixed?

> > No such dynamic allocation at r165239.
> 
> Yes, that's the whole point of the patch, to honor alignment as given.

Right, it apparently correctly uses macros which have the wrong values.
Your cleanups had (at least) fallouts, business as usual...

> > When doing so, it feels it needs to save the stack-pointer.  That's
> > redundant; it's already saved when a frame-pointer is needed.
> 
> The cris port fails to define EXIT_IGNORE_STACK to indicate this.

IIRC I tried to define that macro some (long) time ago, but that had fallouts. 
Too much water under the bridges, so it might be a good idea to try that again.
 (Defining it would not be a proper fix though, it'd just be covering up the
bug.)

> Without that, the middle-end thinks it must save/restore sp around
> the function.  Frankly, there's nothing otherwise unusual about this
> new alloca from any other.  I guess you've just never noticed this
> extra save previously?

I have inspected alloca-using code some time or other and have IIRC noticed it
being slightly suboptimal, but then again, not unexpected from alloca.  I've
never seen such a save/restore using an _invalid_ location, just being
redundant.

> > It so emits "move.d $sp,[$r8-8]" ...  Where it gets the -8 from, I don't
> > know, I'll look further.
> 
> I assume that's a stack slot for a spilled pseudo?

Not a spilled pseudo, rather the stack-saving code going wrong. 
Stack-saving/restoring seems explicit and a bit intertwined; earlier
well-placed do_pending_stack_adjust() calls playing a part, then effected by
explow.c:emit_stack_save.  Not a big surprise if it goes wrong due to or
uncovered by r165240. To be investigated; I'll do my part.

It might not be wrong in the long run to completely replace EXIT_IGNORE_STACK
with 1 and apply dead-code-elimination.  At a glance, no weird-stack targets
define it to 0 AFAICT and those future ones that would, would IMHO be better
off doing a port-specific save and restore in their prologues/epilogues.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #18 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-19 23:21:31 UTC ---
(In reply to comment #17)
> Is there a particular reason it should be MAX_OFILE_ALIGNMENT?

No.  For ELF, that just means "arbitrarily large".

> Hm, the default should fall back to effectively BIGGEST_ALIGNMENT unless
> there's a specific __attribute__ ((__aligned__ (N))) in there.  That it
> apparently doesn't is a bug

Hum.  I hadn't noticed previously that your BIGGEST_ALIGNMENT
is *also* set to BITS_PER_UNIT.

> (BTW, shouldn't MINIMUM_ALIGNMENT default to STACK_ALIGNMENT?
> And be named DYNAMIC_STACK_ALIGNMENT?)

I dunno about "dynamic".  That sounds like stack re-alignment.
The current MINIMUM_ALIGNMENT leaves the alignment unchanged.

> Are you open to having that fixed?

Well, it appears as if get_mode_alignment is already correct, but
TYPE_ALIGN and thus DECL_ALIGN don't honor BIGGEST_ALIGNMENT.

I can see that if we adjust TYPE_ALIGN we'll alter the layout of
all structures, which can't be a good thing.  I'm not sure what
the fallout would be from changing 

  if (code != FIELD_DECL)
    /* For non-fields, update the alignment from the type.  */
    do_type_align (type, decl);

to also take BIGGEST_ALIGNMENT into account.  Certainly we can't
change do_type_align because that's also used for FIELD_DECLs.

> Not a spilled pseudo, rather the stack-saving code going wrong. 
> Stack-saving/restoring seems explicit and a bit intertwined; earlier
> well-placed do_pending_stack_adjust() calls playing a part, then effected by
> explow.c:emit_stack_save.  Not a big surprise if it goes wrong due to or
> uncovered by r165240. To be investigated; I'll do my part.

Ug.

> It might not be wrong in the long run to completely replace EXIT_IGNORE_STACK
> with 1 and apply dead-code-elimination.

That would be really nice.  There are several ports that explicitly
set it to 0: arc, h8300, m68hc11, spu, mcore, m32c.  Those probably
need a simple update to their epilogues to restore from frame pointer.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #19 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-03-11 04:42:21 UTC ---
(In reply to comment #18)
> > To be investigated; I'll do my part.

Famous last words... well, it didn't happen yet, but something else happened:

This bug was either fixed or re-covered in the range 170660..170665 and I'd be
very surprised if it wasn't your 170663.  Tracking down the related mailing
list conversations (with DJ regarding m32r) it was apparently a fix intended
for exactly this problem, so thanks. :]  Yay, no regressions since T0.

Did I mention I tried at the previous iteration setting EXIT_IGNORE_STACK to 1
and got massive regressions?  Ripe for a revisit.  Just not now.

As an intended fix was committed, I'm closing this PR.