https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-05-08
Ever confirmed|0 |1
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
The "issue" in the C++ FE is probably that it uses the size promoted
to sizetype in the loop rather than the original size.
(void) (p = TARGET_EXPR <D.2282, operator new [] ((long unsigned int)
NON_LVALUE_EXPR <SAVE_EXPR <(sizetype) n>>)>;, try
{
char * D.2283;
<<< Unknown tree: expr_stmt
(void) (D.2283 = (char *) D.2282) >>>;
char * D.2284;
<<< Unknown tree: expr_stmt
(void) (D.2284 = D.2283) >>>;
long int D.2285;
<<< Unknown tree: expr_stmt
(void) (D.2285 = (long int) (SAVE_EXPR <(sizetype) n> +
18446744073709551615)) >>>;
while (1)
{
if (D.2285 < 0) goto <D.2287>;
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (*D.2284 = 0) >>>>>;
<<< Unknown tree: expr_stmt
(void) ++D.2284 >>>;
(void) --D.2285;
}
see how it uses (sizetype) n in the SAVE_EXPR and the loop conditional.
The looping construct it emits is "interesting" as well, it boils down to
for (;--n>=0;)
*p++ = 0;
I suppose the FE should emit what suits -Os/-O0 best, the ME should handle
turning this into a do-while style loop.
