https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The question is how far we want to go and what we just ignore.
With -fmerge-all-constants, we can have:
const char var[] = "foobar";
int foo (void) { return &var[0] != "foobar"; }
which will likely be now miscompiled. But we could even have two sources,
const char var2[] = "foobar";
compiled with -fmerge-all-constants and
extern char var2[];
int bar (void) { return &var2[0] != "foobar"; }
compiled with -fmerge-constants (the default).
So, can we e.g. optimize less if we see flag_merge_all_constants and a
TREE_READONLY decl(s) (both the above first case and your const int case)?
If the decl(s) have DECL_INITIAL and bind to current TU, we could of course
check further the initializers, and ignore the nasty second case above, by
saying that
if you define vars as const and declare as non-const, it is your problem and
similarly, if you -fmerge-all-constants the defining TUs but not uses of those
decls, it is again your fault? I'd lean towards that.
