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]
Other format: [Raw text]

Re: [PATCH] Fix PR middle-end/26306


> I don't think we should ignore vs[i]; that's an expression of type
> "volatile int", and should trigger a read from the appropriate location.
>  I thought the case in questions was just plan "vs;".

In the example I gave, vs[i] was a record.

> I think we're stuck.  Fundamentally, I think references to volatile
> structures (e.g., "vs;" in your example) should generate reads.  You
> apparently think they shouldn't.

No.  I don't have a strong feeling whether they should or not, but feel that
it's pointless to add code to make them reliably generate reads when they
didn't used to do that and we're not even sure that it's desirable.

> The second makes volatile meaningless on aggregates, which
> seems under-expressive;

Hardly meaningless!  Volatile has plenty of *other* sematics besides forcing
a read in this case and those semantics apply more to aggregates than to
scalars.  And in any event, reading a[i] for a volatile array of ints will
definitely do do a read.

> But, I am burned out on arguing about it.  Realistically, there aren't
> many C/C++ programs that use volatile structures types in this way, so
> the number of real-world programs that could benefit from the automatic
> read is probably very small.  I promise not to comment further and I
> apologize for picking nits about a minor issue.

I don't really have a strong opinion *either* and so I don't really think
there's a fundamental issue.  I see the BLKmode vs. AGGREGATE_TYPE_P as being
between keeping old behavior vs. ease of documentation and I could argue
either way.

My feeling is that we should just do the absolute minimum needed to not cause
the ICE and be as compatible as possible to what we did in the past.


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