[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #9 from Iain Buclaw --- (In reply to Iain Buclaw from comment #8) > I see in the olden days when D sat outside of GCC, this is what was done too. > > https://github.com/D-Programming-GDC/gdc/commit/ > b9d36fc9d71ec4122d1c986599d87c6cb91ca55c Although thinking it over, that did not take into consideration wide character literals. The number of 0's at the end of the raw string in STRING_CST nodes would need to be the same as the width of the type it's representing - one, two, or four 0's for char, wchar and dchar respectively.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #8 from Iain Buclaw --- Looking at C++ FE, I see they construct the string literal using build_string (4, "foo") because I can see the terminating 0 in the pretty-printed string. --- unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7743b5e8 precision:8 min max pointer_to_this > type_6 BLK size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7717d0a8 domain type_6 DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7717de70 precision:64 min max > pointer_to_this > readonly constant static "hello world\000"> --- I see in the olden days when D sat outside of GCC, this is what was done too. https://github.com/D-Programming-GDC/gdc/commit/b9d36fc9d71ec4122d1c986599d87c6cb91ca55c This might have been accidentally removed by another contributor in an apparent drive-by search and replace of a specific pattern. https://github.com/D-Programming-GDC/gdc/commit/f8a05f41cb756ef7ed2b1d8b1d33eb8f815421a5
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #7 from Iain Buclaw ---
(In reply to David Malcolm from comment #5)
> Is D correctly building that string_cst? Are D strings 0-terminated?
Yes, D strings are 0-terminated.
The way I've done it is, the string is constructed using
build_string(3, "foo")
but the TREE_TYPE is set to `char[4]` so that the terminating 0 is considered.
I'm sure it's like this because either GCC has a tendency to emit strings
side-by-side without the 0 so strlen("foo") could return 20, or there's an
optimization pass for strlen() that would otherwise evaluate strlen("foo") into
2 if I set the type of the literal as `char[3]`.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #6 from David Malcolm --- Oops; the above got truncated; the string_cst prints as follows in gdb (gdb) pt string_cst unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea772930 precision:8 min max pointer_to_this > SI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea78a150 domain DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea672150 precision:64 min max > pointer_to_this > constant "foo">
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #5 from David Malcolm --- It's complaining about the read from the string literal. If I change the string in the reproducer from "hello world" to "foo", I see: (gdb) pt string_cst unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea772930 precision:8 min max pointer_to_this > SI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea78a150 domain DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea672150 precision:64 min max > pointer_to_this string.length) (gdb) p string_cst->string.length $36 = 3 The analyzer is using this for determining the validly accessible size of the string, which it determines is 3 bytes: (gdb) call valid_bits.dump(true) bytes 0-2 whereas the read is of 4 bytes: (gdb) call actual_bits.dump(true) bytes 0-3 Is D correctly building that string_cst? Are D strings 0-terminated?
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #4 from David Malcolm --- (In reply to David Malcolm from comment #3) > Thanks; that reproducer works for me. ...or rather, demonstrates the ICE in a way that I can see in the debugger.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-10-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from David Malcolm --- Thanks; that reproducer works for me.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #2 from Iain Buclaw ---
(In reply to David Malcolm from comment #1)
> Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc:
> ./gdc -B. -S -fanalyzer oob.d
> I get:
> d21: error: cannot find source code for runtime library file 'object.d'
>
> Possibly a silly question, but what am I doing wrong?
The library sources aren't in any paths that the compiler looks for. It should
work without any explicit `-I` if the target libraries were installed.
This alternative reproducer should get you off the ground though.
---
mkdir gcc;
echo "module gcc.builtins;" > gcc/builtins.d
cat > oob.d << EOF
module object;
import gcc.builtins;
void main()
{
char[5] arr;
__builtin_strcpy(arr.ptr, "hello world");
}
EOF
./gdc -B. -S -fanalyzer oob.d
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #1 from David Malcolm --- Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc: ./gdc -B. -S -fanalyzer oob.d I get: d21: error: cannot find source code for runtime library file 'object.d' Possibly a silly question, but what am I doing wrong?
