This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/14/2018 07:27 AM, James Greenhalgh wrote:
On Wed, Aug 08, 2018 at 07:17:07PM -0500, Martin Sebor wrote:
On 08/08/2018 05:08 AM, Jason Merrill wrote:
On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor <> wrote:
On 08/07/2018 02:57 AM, Jason Merrill wrote:

On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor <> wrote:

On 07/31/2018 07:38 AM, Jason Merrill wrote:


Done in the attached patch.  I've also avoided dealing with
zero-length arrays and added tests to make sure their size
stays is regardless of the form of their initializer and
the appropriate warnings are issued.

Using build_string() rather than build_string_literal() needed
a tweak in digest_init_r().  It didn't break anything but since
the array type may not have a domain yet, neither will the
string.  It looks like that may get adjusted later on but I've
temporarily guarded the code with #if 1.  If the change is
fine I'll remove the #if before committing.

This initial patch only handles narrow character initializers
(i.e., those with TYPE_STRING_FLAG set).  Once this gets some
exposure I'd like to extend it to other character types,
including wchar_t.

Hi Martin,

This causes issues for the AArch64 tests (full list below).

I see an error message on the following construct:

  void foo (void)
    __Poly8_t x[4] = { 1, 2, 3, 4 };

  init.c:3:20: error: array of inappropriate type initialized from string constant
  3 |   __Poly8_t x[4] = { 1, 2, 3, 4 };

__Poly8_t is a type we define in our backend, through a convoluted set of
functions, which operates a lot like an unsigned, QI mode type.

I see the error with my aarch64 cross-compiler .  The new code
that does the conversion of array initializers to STRING_CSTs
looks for the TYPE_STRING_FLAG() to be set on the type of
the array elements.  Perhaps __Poly8_t should not have the flag
set?  (If it needs it then I think we'd have to only consider
named character types.)

A second set of tests fail due to changed inlining behaviour for functions
with char array initialization:

I'm not sure what's going on here.  The tests are very big and
take forever to compile with an aarch64 cross-compiler, and I'm
not sure what to look for.  Can you provide a smaller test case
that shows the issue?




New failures in:


PR tree-optimization/71625 - missing strlen optimization on different array initialization style


	PR tree-optimization/71625
	* c-parser.c (c_parser_declaration_or_fndef): Call


	PR tree-optimization/71625
	* c-common.c (braced_list_to_string): New function.
	* c-common.h (braced_list_to_string): Declare it.


	PR tree-optimization/71625
	* decl.c (check_initializer):  Call braced_list_to_string.
	(eval_check_narrowing): New function.
	* gcc/cp/typeck2.c (digest_init_r): Accept strings literals
	as initilizers for all narrow character types.


	PR tree-optimization/71625
	* g++.dg/init/string2.C: New test.
	* g++.dg/init/string3.C: New test.
	* g++.dg/init/string4.C: New test.
	* gcc.dg/init-string-3.c: New test.
	* gcc.dg/strlenopt-55.c: New test.
	* gcc.dg/strlenopt-56.c: New test.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]