This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Wide STRING_CSTs


What is the (undocumented) format of a wide string STRING_CST meant to be?  
lex_string seems to treat it as being stored as an array of target wchar_t
(in the target endianness), but combine_strings seems to treat it as being
stored in the host endianness.  Which of these is right?  I'll document
the conclusion for c-tree.texi.

As is, it seems (from the source and examining assembler output) that the
following testcase will fail for cross-compiles to architectures of
different endianness.  OK to commit it to gcc.c-torture/execute/ on
mainline and branch?  (It's an execution test rather than a link-time test
since GCC doesn't seem to optimise accesses to wide string literals here.)

Also, what is the format of (wide or narrow) string literals meant to be
when the target has >8-bit bytes?  GCC just seems to assume
(inconsistently) that target bytes should be stuffed in host bytes.

/* Origin: Joseph Myers <jsm28@cam.ac.uk>.

   This tests for inconsistency in whether wide STRING_CSTs use the host
   or the target endianness.  */

extern void exit (int);
extern void abort (void);

int
main (void)
{
  if (L"a" "b"[1] != L'b')
    abort ();
  exit (0);
}

-- 
Joseph S. Myers
jsm28@cam.ac.uk


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