http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #7 from Jakub Jelinek 2011-04-13
15:47:44 UTC ---
Author: jakub
Date: Wed Apr 13 15:47:40 2011
New Revision: 172378
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172378
Log:
PR c++/48570
* semantics.c (cxx_eval_array_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #6 from Jakub Jelinek 2011-04-13
15:38:53 UTC ---
Author: jakub
Date: Wed Apr 13 15:38:50 2011
New Revision: 172377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172377
Log:
PR c++/48570
* semantics.c (cxx_eval_array_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #5 from Jakub Jelinek 2011-04-12
14:01:38 UTC ---
Created attachment 23962
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23962
gcc46-pr48570.patch
Untested fix (tested just on the new testcase, both on x86_64 and with powerpc
c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #4 from joseph at codesourcery dot com 2011-04-12 12:44:03 UTC ---
There are lots of optimizations that are only present for narrow strings
but logically make sense for wide strings as well (for example, some str*
and mem* built-in f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #3 from Jakub Jelinek 2011-04-12
12:30:54 UTC ---
Yeah, cxx_eval_array_reference doesn't expect to have sizeof (x) > 1 accesses
to STRING_CSTs. Unfortunately, fold_read_from_constant_string doesn't handle
those either, and as for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #2 from Jonathan Wakely 2011-04-12
12:21:48 UTC ---
Breakpoint 1, main () at sub.cc:4
4 const wchar_t& z0 = (L"01234")[0];
(gdb) n
5 const wchar_t& z1 = (L"01234")[1];
(gdb)
6 const wchar_t& z2 = (L"01234")[2];
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
