https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127066
Torbjorn SVENSSON <azoff at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |azoff at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Target|sparc*-*-* x86_64-*-* |sparc*-*-* x86_64-*-*
|nvptx-*-* |nvptx-*-* arm*-*-*
--- Comment #4 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> ---
I ran GDB on a native x86_64-linux-gnu and an arm-none-eabi toolchain.
On x86_64, line 26 XFAILs as expected, but on arm-none-eabi it XPASSes:
XPASS: g++.old-deja/g++.pt/ptrmem6.C -std=c++11 (test for errors, line 26)
Below are the two GDB runs.
$ g++ -std=c++11 -o /dev/null gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C
-wrapper gdb,-q,--args
Reading symbols from
/build/r17-5950-g5a5ad4c11dbdfa/libexec/gcc/x86_64-pc-linux-gnu/17.0.0/cc1plus...
(gdb) break check_valid_ptrmem_cst_expr if expand_location
(input_location).line == 26
Breakpoint 1 at 0xe58420: file /build/src_gcc/gcc/cp/pt.cc, line 7210.
(gdb) run
Starting program:
/build/r17-5950-g5a5ad4c11dbdfa/libexec/gcc/x86_64-pc-linux-gnu/17.0.0/cc1plus
-quiet -imultiarch x86_64-linux-gnu -D_GNU_SOURCE
gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C -quiet -dumpdir a- -dumpbase
ptrmem6.C -dumpbase-ext .C -mtune=generic -march=x86-64 -std=c++11 -o
/tmp/ccDrxvS8.s
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C: In function ‘int main()’:
...
Breakpoint 1, check_valid_ptrmem_cst_expr (type=type@entry=0x7ffff73c2f18,
expr=expr@entry=0x7ffff73c57a0, complain=complain@entry=256) at
/build/src_gcc/gcc/cp/pt.cc:7210
7210 STRIP_NOPS (expr);
(gdb) call debug_generic_expr (expr)
<<< Unknown tree: ptrmem_cst >>>
(gdb) p expr->typed.type == expr->exp.operands[0]->typed.type
$1 = true
(gdb) p mode_name[expr->typed.type->type_common.mode]
$2 = 0x3110c29 "TI"
(gdb) p tree_nop_conversion_p (expr->typed.type,
expr->exp.operands[0]->typed.type)
$3 = true
(gdb) p get_tree_code_name (tree_strip_nop_conversions (expr)->base.code)
$4 = 0x30ff988 "ptrmem_cst"
(gdb)
$ arm-none-eabi-g++ -std=c++11 -o /dev/null
gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C -wrapper gdb,-q,--args
Reading symbols from
/build/r17-5950-g5a5ad4c11dbdfa/lib/gcc/arm-none-eabi/17.0.0/cc1plus...
(gdb) break check_valid_ptrmem_cst_expr if expand_location
(input_location).line == 26
Breakpoint 1 at 0x911590: file /build/src_gcc/gcc/cp/pt.cc, line 7208.
(gdb) run
Starting program:
/build/r17-5950-g5a5ad4c11dbdfa/lib/gcc/arm-none-eabi/17.0.0/cc1plus -quiet
-iprefix /build/r17-5950-g5a5ad4c11dbdfa/bin/../lib/gcc/arm-none-eabi/17.0.0/
-isysroot /build/r17-5950-g5a5ad4c11dbdfa/bin/../arm-none-eabi
-D__USES_INITFINI__ gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C -quiet -dumpdir
a- -dumpbase ptrmem6.C -dumpbase-ext .C -mcpu=arm7tdmi -mfloat-abi=soft -marm
-mlibarch=armv4t -march=armv4t -std=c++11 -o /tmp/ccFnSbsc.s
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
...
Breakpoint 1, check_valid_ptrmem_cst_expr (type=type@entry=0x7ffff786fbd0,
expr=expr@entry=0x7ffff786c940, complain=complain@entry=256) at
/build/src_gcc/gcc/cp/pt.cc:7208
7208 {
(gdb) call debug_generic_expr (expr)
<<< Unknown tree: ptrmem_cst >>>
(gdb) p expr->typed.type == expr->exp.operands[0]->typed.type
$1 = true
(gdb) p mode_name[expr->typed.type->type_common.mode]
$2 = 0x24f931d "BLK"
(gdb) p tree_nop_conversion_p (expr->typed.type,
expr->exp.operands[0]->typed.type)
$3 = false
(gdb) p get_tree_code_name (tree_strip_nop_conversions (expr)->base.code)
$4 = 0x25dc268 "nop_expr"
(gdb)
On arm-none-eabi the type is BLKmode, so tree_nop_conversion_p returns false
and the error is emitted.
On x86_64 it returns true and no error is emitted.
@Richard, r17-3464-gffb9629b258229 introduced the BLKmode check in
tree_nop_conversion_p, which caused this regression. Shouldn't the if-statement
also check whether either outer_type or inner_type is a vector?
