[Bug rtl-optimization/61799] New: [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address

[Bug rtl-optimization/61799] New: [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address

[emeric.maschino at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799

            Bug ID: 61799
           Summary: [4.6/4.7 regression][ia64] r165240 caused GDB stops
                    with SIGTRAP at 0 address
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: emeric.maschino at gmail dot com

With current ia64 stable GCC (4.6 on Debian/ia64, 4.7 on Gentoo/ia64), trying
to debug a program with GDB immediately ends with:

(gdb) run
Starting program: /usr/bin/bogus-program 

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000000000 in ?? ()
(gdb)

Originally incorrectly reported on Debian BTS against the Linux kernel (as
depending on kernel versions, GDB was running fine or not) [1], I've later
discovered that, for a given kernel version, GDB was running fine or not
depending on the kernel configuration (simply changing a component from being
compiled in-kernel vs. as a module could trigger this issue) [2]. So kernel
version wasn't the cause. GCC optimizations were also incorrectly reported as
playing a role there [3], as depending on optimization settings, GDB may run
fine or not. This lead to Ben Hutchings reporting on the behalf of Will Deacon
that "gcc's code generation for ia64 has regressed in 4.6 or earlier" [4]. So,
carefully looking again at the broken kernels, I've indeed noticed that this
issue first appears with kernels compiled with GCC >= 4.6, as alluded to
earlier by Stephan Schreiber [5].

So, having a working environment with a GCC 4.5.4-compiled kernel and a broken
one with the same kernel but compiled with GCC 4.6.3, I ran git bisect on GCC's
git mirror and located the bad commit to be revision 165240 [6], that aimed to
fix PR/rtl-opt/33721 [7].

Not being a GCC developper nor an ia64 guru, I'm now stuck here. So please let
me know how I can help further.

Thanks,

     Émeric


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576
[2] https://lists.debian.org/debian-ia64/2013/09/msg00024.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#131
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#116
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#10
[6] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=165240
[7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
>From gcc-bugs-return-456292-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 14 11:45:10 2014
Return-Path: <gcc-bugs-return-456292-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15730 invoked by alias); 14 Jul 2014 11:45:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15634 invoked by uid 48); 14 Jul 2014 11:45:06 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
Date: Mon, 14 Jul 2014 11:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords: lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-41227-4-piJcn4fIGb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-41227-4@http.gcc.gnu.org/bugzilla/>
References: <bug-41227-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg00883.txt.bz2
Content-length: 1059

https://gcc.gnu.org/bugzilla/show_bug.cgi?idA227

--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #14)
> (In reply to rguenther@suse.de from comment #13)
> > Does it need to inter-operate with
> > extern struct { struct { int i; } a; } a;
> No, I don't read anything in the standard that would allow this.

By your argument,
  int i;
and
  struct { int i; } a;
are interoperable. By this argument, one can also claim that it applies to
  struct { struct { int i; } a; } a;
At least I fail to see a difference between the single and the nested struct.

Otherwise, I stand to what I wrote before: I think the standard does not demand
the interoperability.

There are surely programs out there which do assume for a scalar variable in a
common block that it interoperates with "int" and others which assume that it
interoperates with "struct { int i; }". Thus, one might decide that one wants
to support both versions with LTO. But one shouldn't do so by arguing with the
Fortran standard.

[Bug rtl-optimization/61799] [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |ia64-*-*
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-07-14
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please try at least GCC 4.8 - both 4.6 and 4.7 are no longer supported.

[Bug rtl-optimization/61799] [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address

[emeric.maschino at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799

--- Comment #2 from Émeric MASCHINO <emeric.maschino at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> Please try at least GCC 4.8 - both 4.6 and 4.7 are no longer supported.

GCC 4.8 is fine, thanks. I've tracked down the commit that fixed all of this to
revision 191928, aiming to fix PR rtl-optimization/54457 [2].

Back to the original GDB issue, can it now be explained (breakage and fix) by
retrospectively looking at the code modified by revisions 165240 and 191928? Or
does it make no sense at all and I'm simply observing random side-effects of
some more subtle breakage elsewhere?

     Émeric

[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=191928
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
>From gcc-bugs-return-456827-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 21:41:09 2014
Return-Path: <gcc-bugs-return-456827-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19748 invoked by alias); 20 Jul 2014 21:41:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19491 invoked by uid 48); 20 Jul 2014 21:41:02 -0000
From: "danglin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61359] GCC Bootstrap comparison failures on hppa2.0w-hp-hpux11.23
Date: Sun, 20 Jul 2014 21:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: danglin at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-61359-4-Xx09bEmuei@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61359-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61359-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg01418.txt.bz2
Content-length: 728

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida359

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #3 from John David Anglin <danglin at gcc dot gnu.org> ---
What is your bootstrap compiler?

Check build log as to why UINT64_C is not defined?  GCC provides
include fixes and <stdint.h>, etc.  So, the error you mention should
not occur when building with recent GCC version.  Try building just C
and C++.  Disable libquadmath build until you have working GCC
compiler (I would say 4.7 or later).

[Bug rtl-optimization/61799] [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799

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

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
No idea, both revs point at a gdb issue.