[Bug debug/79444] New: Inconsistent use of DW_OP_piece for vector registers on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79444
Bug ID: 79444
Summary: Inconsistent use of DW_OP_piece for vector registers
on s390x
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: arnez at linux dot vnet.ibm.com
Target Milestone: ---
GCC emits DW_OP_piece for vector registers on s390x in (at least) two
different incompatible ways:
(1) When describing a float field in a structure that was optimized into a
floating-point register:
extern void do_something (float a, float b, float s, float p);
void foo (float a, float b)
{
struct { float a; float b; } s = { a, b };
do_something (a, b, s.a + s.b, s.a * s.b);
}
Compiling the above with "gcc -march=z13 -O3 -g" yields a location list
for foo's variable 's' with an entry like this:
(DW_OP_reg16 (f0); DW_OP_piece: 4; DW_OP_reg17 (f2); DW_OP_piece: 4)
Here the piece operations refer to the *upper* bytes of the floating-point
registers f0 and f2 (aka v0 and v2).
(2) When describing an __int128 bit field that was optimized into a vector
register:
extern void do_something (__int128);
void foo (__int128 x, __int128 y)
{
struct {
unsigned __int128 p: 32;
unsigned __int128 a: 96;
} w = {0, x};
do_something (w.a + y);
}
Compiling the above code with "gcc -march=z13 -O3 -g" yields a location
list for foo's variable 'w' with an entry like this:
(DW_OP_lit0; DW_OP_stack_value; DW_OP_piece: 4; DW_OP_reg16 (f0);
DW_OP_piece: 12)
And here the latter piece operation refers to the *lower* bytes of the vector
register v0.
[Bug tree-optimization/68835] New: ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68835
Bug ID: 68835
Summary: ICE in set_value_range, at tree-vrp.c:387, with
__int128 bit field
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnez at linux dot vnet.ibm.com
Target Milestone: ---
"tst.c":
unsigned __int128
foo (unsigned long a, unsigned long b)
{
unsigned __int128 x = (unsigned __int128) a * b;
struct { unsigned __int128 a: 96; } w;
w.a = x;
return w.a;
}
$ gcc -O2 -c -o tst.o tst.c
tst.c: In function ‘foo’:
tst.c:2:1: internal compiler error: in set_value_range, at tree-vrp.c:387
foo (unsigned long a, unsigned long b)
^~~
0xd94363 set_value_range
/home/arnez/gtools/gcc/gcc/tree-vrp.c:387
0xda878d set_value_range_to_nonnegative
/home/arnez/gtools/gcc/gcc/tree-vrp.c:586
0xda878d extract_range_basic
/home/arnez/gtools/gcc/gcc/tree-vrp.c:4110
0xda9e5a extract_range_from_assignment
/home/arnez/gtools/gcc/gcc/tree-vrp.c:4154
0xdab5d8 vrp_visit_assignment_or_call
/home/arnez/gtools/gcc/gcc/tree-vrp.c:7033
0xdabeba vrp_visit_stmt
/home/arnez/gtools/gcc/gcc/tree-vrp.c:7913
0xcb3abd simulate_stmt
/home/arnez/gtools/gcc/gcc/tree-ssa-propagate.c:331
0xcb4447 simulate_block
/home/arnez/gtools/gcc/gcc/tree-ssa-propagate.c:509
0xcb4447 ssa_propagate(ssa_prop_result (*)(gimple*, edge_def**, tree_node**),
ssa_prop_result (*)(gphi*))
/home/arnez/gtools/gcc/gcc/tree-ssa-propagate.c:926
0xda07e7 execute_vrp
/home/arnez/gtools/gcc/gcc/tree-vrp.c:10319
0xda07e7 execute
/home/arnez/gtools/gcc/gcc/tree-vrp.c:10405
[Bug gcov-profile/68603] [6 Regression] FAIL: g++.dg/gcov/gcov-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68603 --- Comment #2 from Andreas Arnez --- Right, the regression is caused by r230979 -- sorry about that. I've posted a suggested fix: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03502.html
[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 Andreas Arnez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #25 from Andreas Arnez --- To me the problem looks fixed now. In particular checkpoint.exp from the GDB test suite shows no more FAILs on s390x. There's another patch pending that deals with C++: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html But that addresses a different issue and shouldn't affect this PR's status.
[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #22 from Andreas Arnez --- Here's another version of the fix: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00368.html It addresses an issue with the previous version that was brought up by Bernd Schmidt: A breakpoint on the "while (1)" didn't behave as expected, but on the first hit one loop iteration may have executed already.
[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #21 from Andreas Arnez --- (In reply to Andreas Arnez from comment #20) > Posted a patch that is not as ambitious as completely getting rid of > input_location, but also doesn't require a new function like > c_parser_peek_token_keep_input_location(): > > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html After investigating this further I recognized that this patch doesn't cover all cases where the backward-goto is wrongly located. Thus I've created a version that basically follows the suggestion from comment #13, to pass an explicit location to c_finish_loop: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html I haven't checked whether there are still other cases where add_stmt needs to use input_location as the default location for the given statement. It should probably be one goal to get rid of this default handling.
[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #20 from Andreas Arnez --- Posted a patch that is not as ambitious as completely getting rid of input_location, but also doesn't require a new function like c_parser_peek_token_keep_input_location(): https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html
[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #16 from Andreas Arnez --- (In reply to Manuel López-Ibáñez from comment #15) > (In reply to Andreas Arnez from comment #11) > > Any news here? AFAIK the problem still exists. > > I still think the solution in comment #10 is the least invasive without > being a hack. But someone (you?) would need to submit a patch and get it > approved by the C maintainers. Well, I'm rather a GDB- than a GCC developer. My interest in this is to ensure that GDB doesn't become completely useless ;-) Also, I thought that David was a better candidate for fixing this because his patch introduced the regression. Anyway, if it helps speeding this up, and if nobody objects, I could give it a try. In this case I actually lean towards your suggestion from comment #13, to pass an explicit location to c_finish_loop. Somehow I don't like adding a function like c_parser_peek_token_keep_input_location and then using it only for this fix, just to get rid of it in the long run. (Right?)
[Bug debug/67192] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #11 from Andreas Arnez --- Any news here? AFAIK the problem still exists.
[Bug debug/67192] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #7 from Andreas Arnez arnez at linux dot vnet.ibm.com --- (In reply to David Malcolm from comment #3) The issue seems to be in here in c_parser_for_statement: warn_for_misleading_indentation (for_loc, body_loc, c_parser_peek_token (parser)-location, c_parser_peek_token (parser)-type, for); where the calls to c_parser_peek_token can lead to input_location being changed. I'm curious why this would lead to the problem seen, and whether that's working as intended. When looking at c_finish_loop(), I see: SET_EXPR_LOCATION (t, start_locus); where t seems to be the GOTO_EXPR for the backward-goto and start_locus is the location of the beginning of the loop. Naively I would conclude that the GOTO_EXPR is intended to have the location of the *beginning* of the loop. But neither before nor after your patch this seems to be the case?
[Bug debug/67192] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 Andreas Arnez arnez at linux dot vnet.ibm.com changed: What|Removed |Added CC||dmalcolm at redhat dot com --- Comment #1 from Andreas Arnez arnez at linux dot vnet.ibm.com --- Bisecting reveals that the problem was introduced with SVN commit #223098 on trunk: Implement -Wmisleading-indentation, by David Malcolm.
[Bug debug/67192] New: Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192
Bug ID: 67192
Summary: Backward-goto in loop can get wrong line number
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: arnez at linux dot vnet.ibm.com
Target Milestone: ---
This bug causes a number of failures in the GDB test suite, e.g. with
checkpoint.exp. I can reproduce it with the command line:
gcc -fdump-tree-gimple-lineno -o foo.o -c -g foo.c
foo.c
extern int bar(void);
extern int baz(void);
extern int foo(int x);
int foo(int x)
{
for (;;)
{
if (bar ())
break;
baz ();
}
baz (); /* Line 14. */
}
foo.c.004t.gimple
foo (int x)
[foo.c:7:1] {
int D.1415;
D.1413:
[foo.c:10:11] D.1415 = bar ();
[foo.c:10:10] if (D.1415 != 0) goto D.1416; else goto D.1417;
D.1416:
[foo.c:11:2] goto D.1412;
D.1417:
[foo.c:12:7] baz ();
[foo.c:14:3] goto D.1413; /* == WRONG! Should be [foo.c:13:5]. */
D.1412:
[foo.c:14:3] baz ();
}
[Bug debug/63300] 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300 Andreas Arnez arnez at linux dot vnet.ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andreas Arnez arnez at linux dot vnet.ibm.com --- The fix works and I didn't find any regressions.
[Bug debug/63300] 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300 Andreas Arnez arnez at linux dot vnet.ibm.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Andreas Arnez arnez at linux dot vnet.ibm.com --- Closing per comment #5.
[Bug debug/63300] New: 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300
Bug ID: 63300
Summary: 'const volatile' sometimes stripped in debug info
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: arnez at linux dot vnet.ibm.com
With current upstream gcc, the following commands do not yield the expected
output:
echo 'void f (const volatile int x) { }' | gcc -xc -c -g -o foo.o -
readelf -wi foo.o | grep 'volatile\|const'
With an older gcc we get something like this:
154: Abbrev Number: 4 (DW_TAG_const_type)
159: Abbrev Number: 5 (DW_TAG_volatile_type)
With the current gcc we get nothing. Indeed, the resulting debug info declares
the parameter 'x' merely as an 'int' instead of 'const volatile int'.
The same happens with some other combinations as well, e.g.:
char *const volatile x
const volatile float x
const volatile int *x
[Bug debug/54887] gdb test case failure with mi-var-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887 --- Comment #5 from Andreas Arnez arnez at linux dot vnet.ibm.com 2012-10-24 17:51:44 UTC --- (In reply to comment #4) 232e: Abbrev Number: 27 (DW_TAG_lexical_block) 32f DW_AT_low_pc : 0x400758 337 DW_AT_high_pc : 0x38 0x0 333f: Abbrev Number: 28 (DW_TAG_variable) 340 DW_AT_name: d Such a whole-subprogram lexical block is still generated by mainline gcc at r192761. I verified this on x86_64 with use_rtti_for_ptr_test() in mi-var-rtti.cc. Note that the lexical block's range is slightly smaller than the subprogram's: 130d: Abbrev Number: 26 (DW_TAG_subprogram) 30e DW_AT_external: 1 30e DW_AT_name: (indirect string, offset: 0x35f): use_rtti_for_ptr_test 312 DW_AT_decl_file : 1 313 DW_AT_decl_line : 30 314 DW_AT_linkage_name: (indirect string, offset: 0x173): _Z21use_rtti_for_ptr_testv 318 DW_AT_low_pc : 0x400750 320 DW_AT_high_pc : 0x42 0x0 328 DW_AT_frame_base : 1 byte block: 9c(DW_OP_call_frame_cfa) 32a Unknown AT value: 2116: 1 32a DW_AT_sibling : 0x386 232e: Abbrev Number: 27 (DW_TAG_lexical_block) 32f DW_AT_low_pc : 0x400758 337 DW_AT_high_pc : 0x38 0x0 Is this expected or not? If needed, I can open a separate Bugzilla for this.
[Bug debug/54887] gdb test case failure with mi-var-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887 Andreas Arnez arnez at linux dot vnet.ibm.com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Andreas Arnez arnez at linux dot vnet.ibm.com 2012-10-11 08:28:52 UTC --- (In reply to comment #3) That should also have been fixed in r192165. Hm, for the test case above I still see the locals of rtti_for_ptr_test() wrapped in a lexical block: 232e: Abbrev Number: 27 (DW_TAG_lexical_block) 32f DW_AT_low_pc : 0x400758 337 DW_AT_high_pc : 0x38 0x0 333f: Abbrev Number: 28 (DW_TAG_variable) 340 DW_AT_name: d ... Should we follow up on this?
[Bug debug/54887] New: gdb test case failure with mi-var-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887
Bug #: 54887
Summary: gdb test case failure with mi-var-rtti
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ar...@linux.vnet.ibm.com
Current upstream gcc causes a regression with the gdb test case
mi-var-rtti.exp:
FAIL: gdb.mi/mi-var-rtti.exp: create varobj for ptr (without RTTI) in
use_rtti_for_ptr
...
Here's a link to the C++ source:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/testsuite/gdb.mi/mi-var-rtti.cc?rev=1.1cvsroot=src
The test case sets a breakpoint in use_rtti_for_ptr_test() on the last
variable declaration ('constPtrConst', line 37) and then advances with
'next' to the return statement. There it tries to access the variable
'ptr', but the 'next' already carried us into the epilogue beyond that
variable's lexical block. This is because the line number information
now places the return statement _after_ everything else, even after
the destructor call for 'd'.
I've verified the failure on x86_64 and s390x. The regression was
introduced by: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191338
[Bug debug/54887] gdb test case failure with mi-var-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887 --- Comment #2 from Andreas Arnez arnez at linux dot vnet.ibm.com 2012-10-10 17:14:32 UTC --- Right. I've checked that the new upstream gcc with r192285 fixes the problem. Thanks! BTW, while investigating this I wondered why g++ wraps all locals in a lexical block instead of attaching them directly to the subprogram DIE. Is there a particular reason for that?
[Bug debug/54826] gdb test case failure (bs15503) due to gaps in lexical block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54826 Andreas Arnez arnez at linux dot vnet.ibm.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Andreas Arnez arnez at linux dot vnet.ibm.com 2012-10-09 09:02:08 UTC --- Very well, thanks!
[Bug debug/54826] New: gdb test case failure (bs15503) due to gaps in lexical block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54826 Bug #: 54826 Summary: gdb test case failure (bs15503) due to gaps in lexical block Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: ar...@linux.vnet.ibm.com Current upstream gcc causes a regression with the gdb test case bs15503.exp: FAIL: gdb.cp/bs15503.exp: print s.length() FAIL: gdb.cp/bs15503.exp: print s[0] FAIL: gdb.cp/bs15503.exp: print s[s.length()-1] FAIL: gdb.cp/bs15503.exp: print (const char *) s FAIL: gdb.cp/bs15503.exp: print (const char *) s.substr(0,4) FAIL: gdb.cp/bs15503.exp: print (const char *) (s=s.substr(0,4)) What happens is that the DWARF output for bs15503.cc wraps the string variable s from StringTestwchar_t::testFunction() in a lexical block with spurious gaps. The test case happens to set a break point into one of these gaps and tries to access the variable from there, which gdb (correctly) refuses. For reference, here's a link to the source code: http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/testsuite/gdb.cp/bs15503.cc?rev=1.11cvsroot=src I've verified the failure on x86_64 and s390x. The regression was introduced by: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191494
