Tested on x86_64-darwin (i.e. that the string is now seen as a regular
c-string and placed in the appropriate section).
OK for trunk?
thanks
Iain
--- 8< ---
In this function, we are generating a string constant but do so with
a mismatch between the actual string length and the length specified
in the type. This causes Darwin, at least, to place the string in an
unexpected section (since the parameters do not match, it is rejected
as a cstring).
The change here makes the parameters match on the assumption that it
is intended to be a null-terminated cstring. Looking through other
cases where build_string() is used, it seems that some of them are
not null-terminated.
gcc/d/ChangeLog:
* d-codegen.cc (build_filename_from_loc): Account for the
terminating null in the string length passed to build_string().
Signed-off-by: Iain Sandoe <i...@sandoe.co.uk>
---
gcc/d/d-codegen.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index e35f75af584..6b07a7a1793 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1940,7 +1940,7 @@ build_filename_from_loc (const Loc &loc)
filename = d_function_chain->module->srcfile.toChars ();
unsigned length = strlen (filename);
- tree str = build_string (length, filename);
+ tree str = build_string (length + 1, filename);
TREE_TYPE (str) = make_array_type (Type::tchar, length + 1);
return build_address (str);
--
2.39.2 (Apple Git-143)
