[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-apple-darwin14.3     |*-apple-darwin*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-20
               Host|x86_64-apple-darwin14.3     |*-apple-darwin*
            Summary|FAIL:                       |[5/6 Regression] FAIL:
                   |gcc.dg/debug/pr65771.c      |gcc.dg/debug/pr65771.c
                   |-gstabs+* -O* (test for     |-gstabs+* -O* (test for
                   |excess errors)              |excess errors)
     Ever confirmed|0                           |1
              Build|x86_64-apple-darwin14.3     |*-apple-darwin*

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Reduced range: no warning for r211652. Confirmed by Iain Sandoe on other darwin
targets (including powerpc-apple-darwin9).

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So most likely r211689 ?  Can you attach assembly created by r211688 and
r211689 ?
Isn't this just a darwin linker bug?

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 35361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35361&action=edit
assembly created by r211652

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 35362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35362&action=edit
assembly created by r211698

The difference between the assembly created by r211652 and r211698 is the
single line

     .stabs    "a:G(0,17)=ar(0,18)=r(0,18);0;037777777777;;0;9;(0,16)",32,0,6,0

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3138 bytes --]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #4)
> Created attachment 35362 [details]
> assembly created by r211698
> 
> The difference between the assembly created by r211652 and r211698 is the
> single line
> 
>  	.stabs	"a:G(0,17)=ar(0,18)=r(0,18);0;037777777777;;0;9;(0,16)",32,0,6,0

maybe that should have been transformed to :
    .stabs   
"__emutls_v.a:G(0,17)=ar(0,18)=r(0,18);0;037777777777;;0;9;(0,16)",32,0,6,0

.. or sth similar, I"m a bit rusty on STABs format.
>From gcc-bugs-return-484042-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 20 09:51:30 2015
Return-Path: <gcc-bugs-return-484042-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84117 invoked by alias); 20 Apr 2015 09:51:30 -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 77479 invoked by uid 48); 20 Apr 2015 09:51:26 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
Date: Mon, 20 Apr 2015 09:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to attachments.created
Message-ID: <bug-65807-4-RQ2CkZTIDY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65807-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65807-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: 2015-04/txt/msg01594.txt.bz2
Content-length: 704

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 35363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5363&actioníit
gcc5-pr65807.patch

Untested obvious fix.  I'd say this is safe even for 5.1 at this point.
Keeping uninitialized garbage in val_entry pointer is undesirable for GC.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, __emutls_v.a certainly is not a user variable, that is an artificial
object, the thread local variable of course lives elsewhere.
You could just drop the stabs for TLS vars on the floor, stabs really doesn't
have extensions to describe the TLS vars.  Like:
--- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
+++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
@@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree

   if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
     {
+      if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
+        return 0;
       if (TREE_PUBLIC (decl))
         {
           int offs;

The disadvantage of doing that is that (at least on x86_64-linux with
-gstabs+), ptype a etc. will stop working, but one couldn't inspect the
variables there either, you really need DWARF for that.
p &a
$3 = (struct S (*)[10]) 0x0
is of course wrong.  So, I'd classify this as a buggy Apple toolchain, but the
above patch might be just ok and not really break anything anyone cares about.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> No, __emutls_v.a certainly is not a user variable, that is an artificial
> object, the thread local variable of course lives elsewhere.
> You could just drop the stabs for TLS vars on the floor, stabs really
> doesn't have extensions to describe the TLS vars.  Like:
> --- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
> +++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
> @@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
>  
>    if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
>      {
> +      if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
> +        return 0;
>        if (TREE_PUBLIC (decl))
>          {
>            int offs;
> 
> The disadvantage of doing that is that (at least on x86_64-linux with
> -gstabs+), ptype a etc. will stop working, but one couldn't inspect the
> variables there either, you really need DWARF for that.
> p &a
> $3 = (struct S (*)[10]) 0x0
> is of course wrong.  So, I'd classify this as a buggy Apple toolchain,

there's nothing apple-specific about this - or even Darwin-specific.
The problem will exist for all the toolchains that use emutls (*iff* they are
interested in STABs debug).

AFAICT ld64 just detected an inconsistency that has gone un-noticed elsewhere, 
if that's really a ld64 bug we should file it… 

OTOH, I agree that there's probably little interest in STABs - even on Darwin
it's only relevant for the most ancient system on the horizon.

> the above patch might be just ok and not really break anything anyone cares
> about.

let's test that out.
>From gcc-bugs-return-484054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 20 10:53:45 2015
Return-Path: <gcc-bugs-return-484054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104954 invoked by alias); 20 Apr 2015 10:53:45 -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 104901 invoked by uid 48); 20 Apr 2015 10:53:40 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
Date: Mon, 20 Apr 2015 10:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-65812-4-uWW5UlOogj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65812-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65812-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: 2015-04/txt/msg01606.txt.bz2
Content-length: 903

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This changed supposedly with r138933 and from that PR20644 I think it is quite
clear this is intentional.  The code in foo_2 is conditional (on a condition
later proved to be always true, though), so we really don't want to warn on it
early, because it might be in dead code, and we don't warn for it late because
it really is dead code, optimized away as nothing uses it.  If you add say a
global void *b; variable and change the a = a; statements to b = a;, then it
will warn even when optimizing, as the code won't be dead.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Jakub Jelinek from comment #6)

> > --- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
> > +++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
> > @@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
> >  
> >    if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
> >      {
> > +      if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
> > +        return 0;
> >        if (TREE_PUBLIC (decl))
> >          {
> >            int offs;

hmm .. not as things stand ..

(gdb) p debug_rtx(home)
(mem/c:BLK (symbol_ref:SI ("__emutls_v.a") [flags 0x1402] <var_decl 0x14260ed80
__emutls_v.a>) [0 __emutls_v.a+0 S16 A32])

(flags [5:3] contain the tls model which is 0 == TLS_MODEL_NONE in the case
above).

Current language:  auto; currently c++
(gdb) p debug_tree(decl)
 <var_decl 0x14260e990 a
    type <array_type 0x14271d888
        type <record_type 0x14271d738 S type_0 DI
            size <integer_cst 0x142601d20 constant 64>
            unit size <integer_cst 0x142601d38 constant 8>
            align 32 symtab 18 alias set -1 canonical type 0x14271d738 fields
<field_decl 0x142626980 s> context <translation_unit_decl 0x1424cf258 D.1823>
            pointer_to_this <pointer_type 0x14271d930> chain <type_decl
0x1426268e8 D.1815>>
        BLK
        size <integer_cst 0x14261d300 constant 640>
        unit size <integer_cst 0x142712870 constant 80>
        align 32 symtab 0 alias set -1 canonical type 0x14271d888
        domain <integer_type 0x14271d7e0 type <integer_type 0x1426050a8
sizetype>
            SI
            size <integer_cst 0x142601cc0 constant 32>
            unit size <integer_cst 0x142601cd8 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0x14271d7e0 precision
32 min <integer_cst 0x142601cf0 0> max <integer_cst 0x142712810 9>>>
    addressable used public static BLK file
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/debug/pr65771.c line 6 col 19 size
<integer_cst 0x14261d300 640> unit size <integer_cst 0x142712870 80>
    align 32 context <translation_unit_decl 0x1424cf258 D.1823>
    value-expr <var_decl 0x14260ed80 __emutls_v.a
        type <record_type 0x14271dd20 __emutls_object BLK
            size <integer_cst 0x14261d030 constant 128>
            unit size <integer_cst 0x14261d048 constant 16>
            align 32 symtab 0 alias set -1 canonical type 0x14271dd20 fields
<field_decl 0x142626c78 __size>>
        asm_written used public static ignored BLK file
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/debug/pr65771.c line 6 col 19 size
<integer_cst 0x14261d030 128> unit size <integer_cst 0x14261d048 16>
        align 32 context <translation_unit_decl 0x1424cf258 D.1823> initial
<constructor 0x1427129a8>
        (mem/c:BLK (symbol_ref:SI ("__emutls_v.a") [flags 0x1402] <var_decl
0x14260ed80 __emutls_v.a>) [0 __emutls_v.a+0 S16 A32])> chain <var_decl
0x14260ea20 b>>

(gdb) p decl->decl_common.ignored_flag
$3 = 0
(gdb) p decl_tls_model(decl)          
$4 = TLS_MODEL_NONE

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Then perhaps one needs to check

TREE_CODE (decl) == VAR_DECL
&& (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
&& decl_tls_model (decl) != TLS_MODEL_NONE

instead.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> Then perhaps one needs to check
> 
> TREE_CODE (decl) == VAR_DECL
> && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
> && decl_tls_model (decl) != TLS_MODEL_NONE
> 
> instead.

except for:
(gdb) p decl_tls_model(decl)          
$4 = TLS_MODEL_NONE

which doesn't seem right .. but haven't got a chance to debug further right
now.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This PR seems to have been fixed between r224139 (test for excess errors) and
224288 (UNSUPPORTED).