> > But how is it "supposed to mark the variable as addressable"? If this > > just means setting TREE_ADDRESSABLE, what's the point of having the hook? > > It also issues language specific warnings
Then one suggestion is that we rename the langhook to "warn_addressable" and set TREE_ADDRESSABLE explicitly in the middle-end. But another is to move the entire processing into the front end and get rid of the langhook entirely! It's the front end that's emitting the ADDR_EXPR in the first place, so it certainly knows it's taking the address of something! > It's not supposed to be doing other things for languages that don't > want to emit warnings (or do other front-endy things with the answer) And where is this documented? > You haven't explained what you think needs undoing in *any current > language that uses the hook*. > We shouldn't be adding hooks just because some theoretical language > that doesn't exist might want to do things we don't want it to do > *anyway*. > No wonder we have so many langhooks. I was suggesting *removing* a langhook. But the fact that "no current frontend does something" is not a reason why "something" isn't valid! To the greatest extent possible, we are trying to form a documented interace between the front end and the middle-end. To do that, we need to know precisely what a front-end can and can't do and not rely on what some particular set of them do now. Specifically, I suggest that we remove the present mark_addressable langhook. Have the middle-end set TREE_ADDRESSABLE. If necessary (and I don't think it is: see above), call a new langhook that *notifies* the front end about the addressability for the purpose of a warning, but the front end isn't allowed to change anything else or to rely on or assume that the address will still be taken when final code is general. I don't think the alternative of making a new langhook to unmark addressable is the best because then you'd actually have to make the marking "private" and have yet another lang hook to see if something is marked!
