https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #14 from Joseph S. Myers ---
I think an object declared with a structure type with only const fields and no
padding can be considered const (no valid way to modify it), yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #13 from Jan Hubicka ---
And forgot to write. In case of strcmp I think we can use fnspec info we
already have at the time constructing callgraph to represent it as a read
rather than taking address. This would make things go bit sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #12 from Jan Hubicka ---
Indeed at IPA level we track if address of a symbol is taken, but we do not
keep any extra info about how it may be used. It would be useful to track
1) if address is used only to read (to figure out readon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #11 from Joseph S. Myers ---
A struct with a const field is not a modifiable lvalue in C, so it's not valid
to assign to it. Modifying a const field with memcpy / byte accesses would
probably also violate "If an attempt is made to mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #10 from Jakub Jelinek ---
(In reply to Bruno Haible from comment #9)
> We need only to see that the compilation unit only ever accesses
> html5[i].name and html5[i].value but never html5[i] as an entire struct. I
> don't think any k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #9 from Bruno Haible ---
> But the callee is still allowed to assign the whole struct through the
> non-const pointer.
Oh, I see. Yes,
void
foo (struct S *s)
{
s[-1] = s[0];
}
would disable the optimization.
Yeah, then it need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #8 from Jakub Jelinek ---
CCing Joseph for C legalese, but if the whole struct isn't const, I wonder if
it isn't valid to just
void
foo (struct S *s)
{
struct S y = { ... };
*s = y;
}
Or if e.g. code can't validly change at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #7 from Andreas Schwab ---
But the callee is still allowed to assign the whole struct through the
non-const pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #6 from Bruno Haible ---
> If you do
> struct S { char a[4]; char b[4]; };
> extern void foo (struct S *);
Yeah, but the submitted case looks more like
struct S { const char a[4]; const char b[4]; };
extern void foo (struct S *);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #4 from Bruno Haible ---
> So, you're basically asking for interprocedural optimization
No, I'm basically asking for type analysis: The compiler could note that the
struct has an "all fields are const" property, and that this is eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #5 from Jakub Jelinek ---
Certainly.
If you do
struct S { char a[4]; char b[4]; };
extern void foo (struct S *);
static struct S s[] = { { "abc", "def" }, { "ghi", "jkl" } };
void
bar (void)
{
foo (&s[1]);
}
i.e. if the address esc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
Richard Biener changed:
What|Removed |Added
Component|middle-end |ipa
--- Comment #3 from Richard Biener
12 matches
Mail list logo