| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of
| Lawrence Crowl
| Sent: Thursday, October 24, 2013 5:35 PM
| To: WG21 UB study group
| Cc: c++std-ext_at_[hidden]
| Subject: Re: [ub] [c++std-ext-14584] Re: Sized integer types and char bits
|
| On 10/24/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > Jean-Marc Bourguet <jm_at_[hidden]> writes:
| > On 24 Oct 2013, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > > > Lawrence, I would like to understand the kind of optimizations
| > > > you have in mind that we would lose if signed integer arithmetic
| > > > overflow is 'unspecified' as opposed to 'undefined behavior'.
| > >
| > > I seems to me that any flow analysis which propagate back
| > > information assuming there is no overflow would not be possible
| > > with unspecified behavior. If I'm right, undefined allows to
| > > remove the if, unspecified doesn't.
| > >
| > > if (i == INT_MAX) {
| > > // something
| > > }
| > > ++i
| > >
| > > Yours,
| >
| > Part of the complaints, and indeed the original motivation for
| > this Study Group, is that people are unhappy with "arbitrary" code
| > removal based on the fact that a construct invokes undefined
| > behavior "down the road" when it hasn't been executed yet (but is
| > on a must-execute path.)
| >
| > [ Note I wrote "abritrary" in quotes. ]
|
| We generally expect compilers to remove redundant conditions. I
| think the concern here is that the implicit precondition of the
| increment operator is causing an explicit condition to be redundant.

Under the "as-if" rule, yes.

| While it is a bit daunting of a task, changing the definition of
| builtin-operators to state their preconditions explicitly would
| help to lessen the surprise at removing the explicit condition.

Would you volunteer to take a first stab at it?

| Of course, the compiler would be helpful if it warned that it was
| removing a redundant condition in these circumstances.
|
| > "unspecified behavior" means:
| >
| > behavior, for a well-formed program construct, correct data,
| > that depends on the implementation [Note: The implementation
| > is not required to document which behavior occurs. The range
| > of possible behaviors is usually delineated by this
| > International Standard. --end note ]
| >
| > In your example, you are correct that a compiler is permitted to
| > remove the if-statement if i has the value INT_MAX. However, if
| > i does not have the value INT_MAX, a conforming implementation
| > cannot remove that if-statement.
|
| Why not? The condition will never be true and the as-if rule
| applies.

Right. Blame that on being up too late in the night.

| > My question is whether we would lose any useful
| > transformations/optimizations (for programs we care about) that
| > would be made much harder to apply if we required 'unspecified
| > behavior'.
|
| Well, in the example above, we have removed code, which at least
| reduces memory use and consequently i-cache pressure.
|
| > I suppose a subsidiary question is whether INT_MAX is considered
| > 'correct data' for the operation "++i".
|
| I say i == INT_MAX violates the operation's precondition.

Our current Standardese vocabulary for Core does not include this.
Are you saying that it is correct data (of type int) but violates
the domain of definition of prefix increment? Or are you suggesting
that we should introduce a new category? Or are you suggesting we should
all go home because everything is fine (undefined behavior)? :-)

It would be good if we can seize the opportunity to do something
in this area.

-- Gaby