Bug 68986 - [5 Regression] internal compiler error: Segmentation fault
Summary: [5 Regression] internal compiler error: Segmentation fault
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 5.3.0
: P3 normal
Target Milestone: 5.4
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2015-12-18 16:30 UTC by jasonr
Modified: 2016-02-01 20:26 UTC (History)
7 users (show)

See Also:
Host:
Target: x86_64-linux-gnu
Build:
Known to work: 4.9.3
Known to fail:
Last reconfirmed: 2016-01-11 00:00:00


Attachments
C source file that demonstrates the error (323 bytes, text/x-csrc)
2015-12-18 16:30 UTC, jasonr
Details
preprocessed output file from gcc (4.56 KB, text/plain)
2015-12-18 16:30 UTC, jasonr
Details
A patch (1.15 KB, patch)
2016-01-25 19:38 UTC, H.J. Lu
Details | Diff
An updated patch (1.56 KB, patch)
2016-01-25 23:14 UTC, H.J. Lu
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jasonr 2015-12-18 16:30:03 UTC
Created attachment 37087 [details]
C source file that demonstrates the error

I'm running on Ubuntu 14.04 (x86_64) using gcc 5.3.0. I've also observed this problem with 5.2.0 and 5.2.1 at least, however. I haven't seen any problems with any gcc versions in the 4.x series; it appears to be isolated to 5.x at least.

Here is the output of gcc run with the `-v` argument:

$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04)

I compile the attached C file (which is reduced down from the original file, down to the minimum code required to show the compiler error) using the following command line:

    gcc-5 tracesig.c -c -fPIC -mpreferred-stack-boundary=5 -mincoming-stack-boundary=4

The stack-related options come from source code elsewhere in this project that has particular SIMD requirements. When I execute the above command line, I get the following output:

tracesig.c: In function ‘char* __check_point_msg_buffer()’:
tracesig.c:20:1: internal compiler error: Segmentation fault
 }
 ^
0xa8842f crash_signal
	../../src/gcc/toplev.c:383
0xcca22c ix86_expand_prologue()
	../../src/gcc/config/i386/i386.c:11503
0xda9dca gen_prologue()
	../../src/gcc/config/i386/i386.md:12254
0x877cbf thread_prologue_and_epilogue_insns()
	../../src/gcc/function.c:5930
0x8784a2 rest_of_handle_thread_prologue_and_epilogue
	../../src/gcc/function.c:6500
0x8784a2 execute
	../../src/gcc/function.c:6538
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.

I will attach the preprocessed file in a subsequent reply to the report.
Comment 1 jasonr 2015-12-18 16:30:47 UTC
Created attachment 37088 [details]
preprocessed output file from gcc
Comment 2 Richard Biener 2016-01-11 10:08:23 UTC
Confirmed.
Comment 3 Markus Trippelsdorf 2016-01-24 12:03:59 UTC
*** Bug 69454 has been marked as a duplicate of this bug. ***
Comment 4 Markus Trippelsdorf 2016-01-24 12:19:25 UTC
PR69454 testcase only crashes with gcc-6:

markus@x4 VEX % cat guest_amd64_helpers.i
typedef struct { long long w64[2]; } V128;
extern V128* fn2(void);
long long a;
V128 b;
void fn1() {
  V128 *c = fn2();
  c->w64[0] = a ^ b.w64[0];
}

markus@x4 VEX % gcc -c -m32 -mpreferred-stack-boundary=2 -O2 guest_amd64_helpers.i
guest_amd64_helpers.i: In function ‘fn1’:
guest_amd64_helpers.i:8:1: internal compiler error: Segmentation fault
 }
 ^

0xb2051f crash_signal
        ../../gcc/gcc/toplev.c:335
0x7f543f74614f ???
        /home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xe3d804 ix86_expand_prologue()
        ../../gcc/gcc/config/i386/i386.c:12751
0xff543a gen_prologue()
        ../../gcc/gcc/config/i386/i386.md:12451
0xe248e8 target_gen_prologue
        ../../gcc/gcc/config/i386/i386.md:18466
0x87a6ff thread_prologue_and_epilogue_insns()
        ../../gcc/gcc/function.c:6037
0x87b1d2 rest_of_handle_thread_prologue_and_epilogue
        ../../gcc/gcc/function.c:6588
0x87b1d2 execute
        ../../gcc/gcc/function.c:6630


Reduced testcase, crashes for gcc-5 and gcc-6:

markus@x4 tmp % cat tracesig.ii
struct {
  char msgdata[][8];
} __thread *mythread;
char *fn1() { return mythread->msgdata[1]; }

markus@x4 tmp % g++ -c -fPIC -mpreferred-stack-boundary=5 -mincoming-stack-boundary=4 tracesig.ii
tracesig.ii: In function ‘char* fn1()’:
tracesig.ii:4:44: internal compiler error: Segmentation fault
 char *fn1() { return mythread->msgdata[1]; }
                                            ^

0xcfb38f crash_signal
        ../../gcc/gcc/toplev.c:335
0x7f22485a914f ???
        /home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1017c94 ix86_expand_prologue()
        ../../gcc/gcc/config/i386/i386.c:12751
0x11cf8ca gen_prologue()
        ../../gcc/gcc/config/i386/i386.md:12451
0xffed78 target_gen_prologue
        ../../gcc/gcc/config/i386/i386.md:18466
0xa5649f thread_prologue_and_epilogue_insns()
        ../../gcc/gcc/function.c:6037
0xa56f72 rest_of_handle_thread_prologue_and_epilogue
        ../../gcc/gcc/function.c:6588
0xa56f72 execute
        ../../gcc/gcc/function.c:6630
Please submit a full bug report,
Comment 5 Mark Wielaard 2016-01-24 12:36:30 UTC
Thanks for finding the duplicate and creating a small reproducer. This is indeed a GCC 6 regression. valgrind builds fine with gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) but fails with gcc (GCC) 6.0.0 20160123 (experimental).

But it looks like we were just lucky since you were able to tweak the reproducer to also fail with 5.3.
Comment 6 Uroš Bizjak 2016-01-24 20:31:27 UTC
I was not able to reproduce the ICE with the first testcase from the Comment #4, but was able to trigger the ICE with the second testcase with both gcc-5 and gcc-6.

We hit this corner case in i386.c:

  /* Emit prologue code to adjust stack alignment and setup DRAP, in case
     of DRAP is needed and stack realignment is really needed after reload */
  if (stack_realign_drap)
    {
      int align_bytes = crtl->stack_alignment_needed / BITS_PER_UNIT;

      /* Only need to push parameter pointer reg if it is caller saved.  */
      if (!call_used_regs[REGNO (crtl->drap_reg)])
	{
	  /* Push arg pointer reg */
	  insn = emit_insn (gen_push (crtl->drap_reg));
	  RTX_FRAME_RELATED_P (insn) = 1;
	}
...

Unfortunately, crtl->drap_reg is NULL at this point.

CC author.
Comment 7 H.J. Lu 2016-01-24 23:39:31 UTC
This is caused by r210220.
Comment 8 Uroš Bizjak 2016-01-25 08:13:37 UTC
(In reply to H.J. Lu from comment #7)
> This is caused by r210220.

A testsuite-only patch that only changes scan-assembler strings?

 	* gcc.target/i386/avx256-unaligned-load-2.c,
	gcc.target/i386/pr49002-1.c, gcc.target/i386/pr53712.c,
	gcc.target/i386/pr53907.c, gcc.target/i386/pr59539-1.c: Allow
	packed-single instructions.
Comment 9 Jakub Jelinek 2016-01-25 08:25:20 UTC
I need additional -march=x86-64 to trigger this.  With that it started with
r228231.
Comment 10 Jakub Jelinek 2016-01-25 08:29:59 UTC
(In reply to Jakub Jelinek from comment #9)
> I need additional -march=x86-64 to trigger this.  With that it started with
> r228231.

Note that is with #c4 testcase.
Comment 11 Jakub Jelinek 2016-01-25 08:36:41 UTC
Ah, missed the second testcase in #c4.  That started with r210222.
Comment 12 Jakub Jelinek 2016-01-25 08:47:53 UTC
And I bet the bug is exactly in the:
  /* preferred_stack_boundary is never updated for call
9499 	  	      expanded from tls descriptor. Update it here. We don't update it in
9500 	  	      expand stage because according to the comments before
9501 	  	      ix86_current_function_calls_tls_descriptor, tls calls may be optimized
9502 	  	      away.  */
9503 	  	   else if (ix86_current_function_calls_tls_descriptor
9504 	  	            && crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
9505 	  	     {
9506 	  	       crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
9507 	  	       if (crtl->stack_alignment_needed < PREFERRED_STACK_BOUNDARY)
9508 	  	         crtl->stack_alignment_needed = PREFERRED_STACK_BOUNDARY;
9509 	  	     }
being performed too late, I believe the drap register is created during expansion and not later on.  Perhaps one could postpone that until some pass shortly before IRA, but not further.
Comment 13 H.J. Lu 2016-01-25 19:38:09 UTC
Created attachment 37466 [details]
A patch

I am testing this.
Comment 14 H.J. Lu 2016-01-25 23:14:19 UTC
(In reply to H.J. Lu from comment #13)
> Created attachment 37466 [details]
> A patch
> 
> I am testing this.

This patch is wrong.  After ix86_finalize_stack_realign_flags, there should
be no stack alignment changes.  We should update stack alignment for
__tls_get_addr in ix86_update_stack_boundary.  Also there is no need to
over-align stack for __tls_get_addr and function with __tls_get_addr call
isn't a leaf function.
Comment 15 H.J. Lu 2016-01-25 23:14:56 UTC
Created attachment 37471 [details]
An updated patch
Comment 16 hjl@gcc.gnu.org 2016-01-26 12:51:38 UTC
Author: hjl
Date: Tue Jan 26 12:51:07 2016
New Revision: 232825

URL: https://gcc.gnu.org/viewcvs?rev=232825&root=gcc&view=rev
Log:
Update stack alignment in ix86_update_stack_boundary

Stack alignment adjustment for __tls_get_addr should be done in
ix86_update_stack_boundary, not ix86_compute_frame_layout.  Also
there is no need to over-align stack for __tls_get_addr and function
with __tls_get_addr call isn't a leaf function.

gcc/

	PR target/68986
	* config/i386/i386.c (ix86_compute_frame_layout): Move stack
	alignment adjustment to ...
	(ix86_update_stack_boundary): Here.  Don't over-align stack for
	__tls_get_addr.
	(ix86_finalize_stack_realign_flags): Use stack_alignment_needed
	if __tls_get_addr is called.

gcc/testsuite/

	PR target/68986
	* gcc.target/i386/pr68986-1.c: New test.
	* gcc.target/i386/pr68986-2.c: Likewise.
	* gcc.target/i386/pr68986-3.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr68986-1.c
    trunk/gcc/testsuite/gcc.target/i386/pr68986-2.c
    trunk/gcc/testsuite/gcc.target/i386/pr68986-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog
Comment 17 H.J. Lu 2016-01-26 12:53:13 UTC
Fixed on trunk so far.
Comment 18 hjl@gcc.gnu.org 2016-01-27 19:54:35 UTC
Author: hjl
Date: Wed Jan 27 19:54:03 2016
New Revision: 232901

URL: https://gcc.gnu.org/viewcvs?rev=232901&root=gcc&view=rev
Log:
Don't change stack_alignment_needed for __tls_get_addr

__tls_get_addr must be called with 16-byte aligned stack, which is
guaranted by setting preferred_stack_boundary to 128 bits.  There
is no need to change stack_alignment_needed for __tls_get_addr.

	PR target/68986
	* config/i386/i386.c (ix86_update_stack_boundary): Don't
	change stack_alignment_needed for __tls_get_addr call.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
Comment 19 hjl@gcc.gnu.org 2016-02-01 20:21:27 UTC
Author: hjl
Date: Mon Feb  1 20:20:56 2016
New Revision: 233046

URL: https://gcc.gnu.org/viewcvs?rev=233046&root=gcc&view=rev
Log:
Update preferred stack boundary in ix86_update_stack_boundary

__tls_get_addr must be called with 16-byte aligned stack, which is
guaranted by setting preferred_stack_boundary to 128 bits.  Preferred
stack boundary adjustment for __tls_get_addr should be done in
ix86_update_stack_boundary, not ix86_compute_frame_layout Also
there is no need to over-align stack for __tls_get_addr and function
with __tls_get_addr call isn't a leaf function.

gcc/

	Backport from mainline
	PR target/68986
	* config/i386/i386.c (ix86_compute_frame_layout): Move stack
	alignment adjustment to ...
	(ix86_update_stack_boundary): Here.  Don't over-align stack nor
	change stack_alignment_needed for __tls_get_addr.
	(ix86_finalize_stack_realign_flags): Use stack_alignment_needed
	if __tls_get_addr is called.

gcc/testsuite/

	Backport from mainline
	PR target/68986
	* gcc.target/i386/pr68986-1.c: New test.
	* gcc.target/i386/pr68986-2.c: Likewise.
	* gcc.target/i386/pr68986-3.c: Likewise.

Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-1.c
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-2.c
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-3.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/i386/i386.c
    branches/gcc-5-branch/gcc/testsuite/ChangeLog
Comment 20 H.J. Lu 2016-02-01 20:26:55 UTC
Fixed for GCC 5.4.