Sebastian Pop <[EMAIL PROTECTED]> wrote on 19/07/2005 12:58:23:
| Michael Veksler wrote:
| > This is problematic:
| > 1. I am not sure it will turn the warning off.
|
| So you don't want a warning that cannot be turned off simply by
| modifying the code.
Most of gcc warnings are like that: you
Michael Veksler wrote:
> This is problematic:
> 1. I am not sure it will turn the warning off.
So you don't want a warning that cannot be turned off simply by
modifying the code. Then, I withdraw the patch that I have proposed
to implement the warning.
Sebastian Pop wrote on 19/07/2005 09:49:11:
> Robert Dewar wrote:
> >
> > and that is called a false positive if in fact the loop does
> > not overrun. this sounds very dubious to me
I concur.
>
> The problem is that the compiler has no other information about the
> number of iterations in t
Robert Dewar wrote:
>
> and that is called a false positive if in fact the loop does
> not overrun. this sounds very dubious to me
The problem is that the compiler has no other information about the
number of iterations in the loop, otherwise it wouldn't spend cycles
on computing such estimations
Sebastian Pop wrote:
I don't really see what a false positive could be in this case. In
the patch that I have proposed, the warning is triggered every time
the flag -Wloop-bound-estimated is used and the loop optimizer
triggers the estimation of loop bounds for a parametric loop, as in
the foll
Robert Dewar wrote:
>
> As with all warnings, you have to run this over a large test suite
> of real applications to find out whether there are too many false
> positives.
I don't really see what a false positive could be in this case. In
the patch that I have proposed, the warning is triggered
> > I think we would like them better if you could choose to silence them,
> > especially when people use -Werror.
>
> How can I do this?
Create a -W* command line option for it. Pass the corresponding OPT_*
to warning(). Theen the -W option controls that warning.
> I have just mimicked one
DJ Delorie wrote:
>
> > Then, you will like the following kind of patches:
> >
> > + warning (0, "%H undefined behavior if loop runs for more than %qE
> > iterations",
> > + find_loop_location (loop), estimation);
>
> I think we would like them better if you could choose to silenc
Sebastian Pop wrote:
This is the best the compiler can do: it has warned the user of a
possible undefined behavior in the code, and that it will use this
assumption for transforming the code.
As with all warnings, you have to run this over a large test suite
of real applications to find out wh
On Jun 18, 2005, at 11:50 AM, Paul Schlie wrote:
[ curiously can't find any actual reference stating that integer
overflow
is specifically results in undefined behavior, although it's
obviously ill defined?
Every operation that isn't defined is undefined. Only the operations
that are de
General note, please, this list is for developers of gcc to develop
gcc. Using it as a way to teach yourself how to read the C standard,
isn't ok, please stop.
On Saturday, June 18, 2005, at 07:15 AM, Paul Schlie wrote:
Maybe I didn't phrase my statement well;
I think you did, you are j
[EMAIL PROTECTED] (Robert Dewar) wrote on 19.06.05 in <[EMAIL PROTECTED]>:
> Kai Henningsen wrote:
>
> > But at least, in that case, the compiler could easily issue the
> > (presumably not required by the standard) warning that the else branch is
> > "unreachable code".
>
> Yes, absolutely, a com
> Then, you will like the following kind of patches:
>
> + warning (0, "%H undefined behavior if loop runs for more than %qE
> iterations",
> +find_loop_location (loop), estimation);
I think we would like them better if you could choose to silence them,
especially when people u
> From: Michael Veksler <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16:
>>> From: Michael Veksler <[EMAIL PROTECTED]>>
>>> As for overflow, you can say that you want instead of "undefined"
>>> to treat is "unspecified". Where each architecture / opsys / compiler
Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16:
> > From: Michael Veksler <[EMAIL PROTECTED]>>
> > As for overflow, you can say that you want instead of "undefined"
> > to treat is "unspecified". Where each architecture / opsys / compiler
> > must consistently define what happens
Robert Dewar wrote:
> Yes, absolutely, a compiler should generate warnings as much as possible when
> it is making these kind of assujmptions.
Then, you will like the following kind of patches:
Index: tree-data-ref.c
===
RCS file: /c
Paul Schlie wrote:
- yes, effectively I don't perceive any necessity for undefined, vs
unspecified; as I don't perceive any necessity to give the compiler
the freedom to treat generate an arbitrary program which may contain
a potentially ambiguous specific and isolatable behavior.
OK, then you
Paul Schlie wrote:
There don't need to be examples. The as-if rule always applies, if you cannot
write a legitimate C program that shows the difference between two possible
implementations, then both are correct.
??? as-if means they're logically equivalent (i.e. there is no logical
differenc
> From: Michael Veksler <[EMAIL PROTECTED]>>
>> Paul Schlie wrote on 20/06/2005 14:13:33:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
> ...
>>> Note that in the cases where something is statically optimized away
>>> (these are the easy cases), it is nice if the compiler warns that this
>>> is happen
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>
>> - You may be correct, although it's not obviously the case? (As requiring
>> all undefined behavior be encapsulated between sequence points already
>> seems implied to me, as I don't see any explicit counter examples
>> requ
Michael Veksler wrote:
As for overflow, you can say that you want instead of "undefined"
to treat is "unspecified".
In Ada 95 we introduced a new category of behavior, called a bounded
error. We tried to recategorize as many erroneous (= C undefined)
cases as possible to bounded error.
A bou
Paul Schlie wrote on 20/06/2005 14:13:33:
> > From: Robert Dewar <[EMAIL PROTECTED]>
...
> > Note that in the cases where something is statically optimized away
(these
> > are the easy cases), it is nice if the compiler warns that this is
happening
> > (that would certainly be the case in Ada
Michael Veksler wrote:
Getting a consistent definition of "bounded side-effects"
is a nontrivial task. Simply hacking and patching the
definition does not work. Trust me, I've been there done
that, got burnt and are still paying for my sins.
Indeed! I think anyone who has been involved in the
Paul Schlie wrote:
- You may be correct, although it's not obviously the case? (As requiring
all undefined behavior be encapsulated between sequence points already
seems implied to me, as I don't see any explicit counter examples
requiring otherwise.
There don't need to be examples. The
Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 14:03:53:
> > From: Michael Veksler <[EMAIL PROTECTED]>
...
> > Almost any optimization over line 8 will change the
> > behavior of line 4. I believe that you did not intend to
> > cover this case in your requirement. Maybe you would
> > like
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> I too believe I understand your position, however don't believe it's the
>> compiler's job to make life for the programmer harder than it need be when
>> a program may contain an undefined behavior; but agree it would likely
>> alw
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> As in my mind, the semantics of foo() dictate that it print the value of
>> the storage location which was allocated to the variable "a", where unless
>> "a" is initialized with an explicit value, may be arbitrary. So I've got no
>
Paul Schlie wrote:
I too believe I understand your position, however don't believe it's the
compiler's job to make life for the programmer harder than it need be when
a program may contain an undefined behavior; but agree it would likely
always be helpful to for it to point them out when identif
Paul Schlie wrote:
As in my mind, the semantics of foo() dictate that it print the value of
the storage location which was allocated to the variable "a", where unless
"a" is initialized with an explicit value, may be arbitrary. So I've got no
problem with arbitrary results or behavior, I just si
> From: Robert Dewar <[EMAIL PROTECTED]>
> Robert Dewar wrote:
>
>> That may be your position, but it is not the position of the standard, and
>> indeed it is not a well-formed position. Why, because the whole point is
>> that
>> when the behavior is undefined, then the change DOES yield a logical
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> My position is simply that an optimization should never remove a specified
>> operation unless it is known to yield logically equivalent behavior, as
>> producing a program which does not behave as specified is not a good idea
>
>
> From: Michael Veksler <[EMAIL PROTECTED]>
> Paul Schlie wrote on 20/06/2005 08:55:20:
>> y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
> Invalid syntax, what did you mean?
Sorry, meant:
y = z + x; // y == [INT_MIN, INT_MAX] + [1, 2] == [INT_MIN+1, INT_MAX+2]
>> I guess I simply believe t
Robert Dewar wrote:
That may be your position, but it is not the position of the standard, and
indeed it is not a well-formed position. Why, because the whole point is
that
when the behavior is undefined, then the change DOES yield a logically
equivalent behavior, because undefined means undef
Paul Schlie wrote:
My position is simply that an optimization should never remove a specified
operation unless it is known to yield logically equivalent behavior, as
producing a program which does not behave as specified is not a good idea
That may be your position, but it is not the position
Paul Schlie wrote on 20/06/2005 08:55:20:
> y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
Invalid syntax, what did you mean?
> I guess I simply believe that optimizations should never alter the
logical
> behavior of a specified program relative to it's un-optimized form unless
> explic
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> The root of the concern being expressed is with respect to the compilers use
>> of statically identified undefined behaviors as opportunities to invoke
>> alternative semantics which are easily identified as being inconsistent with
>
Paul Schlie wrote:
The root of the concern being expressed is with respect to the compilers use
of statically identified undefined behaviors as opportunities to invoke
alternative semantics which are easily identified as being inconsistent with
the target's native semantics, thus altering the lo
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>>> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>>> "no requirements" means that *any* translation conforms in the case of
>>> undefined behavior. Only those executions not involving undefined
>>> behavior have any requirements.
>>
>>
Kai Henningsen wrote:
But at least, in that case, the compiler could easily issue the
(presumably not required by the standard) warning that the else branch is
"unreachable code".
Yes, absolutely, a compiler should generate warnings as much as possible when
it is making these kind of assujm
[EMAIL PROTECTED] (Robert Dewar) wrote on 18.06.05 in <[EMAIL PROTECTED]>:
> Here is an interesting example I have used sometimes to indicate just
> how this kind of information can propagate in a manner that would result
> in unexpected chaos. (Ada but obvious analogies in other languages)
>
>
>
[EMAIL PROTECTED] (Florian Weimer) wrote on 18.06.05 in <[EMAIL PROTECTED]>:
> * Paul Schlie:
>
> > So in effect the standard committee have chosen to allow any program which
> > invokes any undefined behavior to behave arbitrarily without diagnosis?
> >
> > This is a good thing?
>
> It's the way
Paul Schlie wrote:
[Justification snipped]
> Therefore regardless of the result of an "undefined" result/operation at
> it's enclosing sequence point, the remaining program must continue to abide
> by the specified semantics of the language.
Tell that to Mister my_array[sizeof(my_array) / sizeof
Paul Schlie wrote:
From: "Joseph S. Myers" <[EMAIL PROTECTED]>
"no requirements" means that *any* translation conforms in the case of
undefined behavior. Only those executions not involving undefined
behavior have any requirements.
What delineates the bounds between undefined and non-undefine
Joseph S. Myers wrote:
The traditional form of undefined behavior is for demons to fly out of
your nose. We just haven't yet got -fnasal-demons working reliably but it
would be conforming for it to be on by default. If you are lucky, it will
happen anyway without that option.
A nice piece
* Paul Schlie:
> So in effect the standard committee have chosen to allow any program which
> invokes any undefined behavior to behave arbitrarily without diagnosis?
>
> This is a good thing?
It's the way things are. There isn't a real market for
bounds-checking C compilers, for example, which o
Paul Schlie wrote:
- an optimization which presumes the execution state of a program does not
proceed past a sequence point. but in fact does, may result in erroneous
behavior; which would be the case if NULL pointer comparisons were optimized
away presuming an earlier pointer dereference would
On Sat, 18 Jun 2005, Paul Schlie wrote:
> So in effect the standard committee have chosen to allow any program which
> invokes any undefined behavior to behave arbitrarily without diagnosis?
That is the *whole point* of undefined behavior. Unless the program also
violates a compile-time syntax
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
> "no requirements" means that *any* translation conforms in the case of
> undefined behavior. Only those executions not involving undefined
> behavior have any requirements.
What delineates the bounds between undefined and non-undefined behaviors?
(
So in effect the standard committee have chosen to allow any program which
invokes any undefined behavior to behave arbitrarily without diagnosis?
This is a good thing?
[ curiously can't find any actual reference stating that integer overflow
is specifically results in undefined behavior, altho
On Sat, 18 Jun 2005, Paul Schlie wrote:
>[#1] Behavior, upon use of a nonportable or erroneous
>program construct, of erroneous data, or of indeterminately
>valued objects, for which this International Standard
>imposes no requirements. Permissibl
On Sat, 18 Jun 2005, Paul Schlie wrote:
> > You appear to have confused unspecified behavior (where the possibilities
> > are bounded) and undefined behavior (where the possibilities are
> > unbounded). On *undefined* behavior (such as signed integer overflow),
> > *this International Standard im
Sorry, yes the quote below defines unspecified, not undefined behavior.
Now more correctly:
[#1] Behavior, upon use of a nonportable or erroneous
program construct, of erroneous data, or of indeterminately
valued objects, for which this International Standard
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
> On Sat, 18 Jun 2005, Paul Schlie wrote:
>
>> Maybe I didn't phrase my statement well; I fully agree with the cited
>> paragraph above which specifically says a program containing unspecified
>> behavior "shall be a correct program and act in ac
On Sat, 18 Jun 2005, Paul Schlie wrote:
> Maybe I didn't phrase my statement well; I fully agree with the cited
> paragraph above which specifically says a program containing unspecified
> behavior "shall be a correct program and act in accordance with
> 5.1.2.3". Which specifies program ex
> Mike Stump wrote:
>> Paul Schlie wrote:
>> - If the semantics of an operation are "undefined", I'd agree; but if
>> control is returned to the program, the program's remaining specified
>> semantics must be correspondingly obeyed, including the those which
>> may utilize the resulting value
Dale Johannesen wrote:
2 NOTE Possible undefined behavior ranges from ignoring the situation
completely with
unpredictable results, to behaving during translation or program
execution in a documented
manner characteristic of the environment (with or without the issuance
of a diagnostic messag
On Friday, June 17, 2005, at 05:59 PM, Paul Schlie wrote:
- If the semantics of an operation are "undefined", I'd agree; but if
control is returned to the program, the program's remaining specified
semantics must be correspondingly obeyed, including the those which
may utilize the resultin
Paul Schlie wrote:
(As there's nothing in the standard which enables an implementation
to subsequently disregard the resulting value of an implementation
specific operation from the best I can tell; although would welcome
someone pointing out where specifically it's allowed. As unless
On Jun 17, 2005, at 5:59 PM, Paul Schlie wrote:
From: Andrew Pinski <[EMAIL PROTECTED]>
On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
["undefined" only provides liberties within the constrains of what
is specifically specified as being undefined, but none beyond
that.]
That is not tr
> From: Andrew Pinski <[EMAIL PROTECTED]>
> On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
>
>> ["undefined" only provides liberties within the constrains of what
>> is specifically specified as being undefined, but none beyond that.]
>
> That is not true. Undefined means it can run "rm /"
On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
["undefined" only provides liberties within the constrains of what
is specifically specified as being undefined, but none beyond that.]
That is not true. Undefined means it can run "rm /" if you ever invoke
the undefined code.
Thanks,
Andr
> From: Diego Novillo <[EMAIL PROTECTED]>
> On Fri, Jun 17, 2005 at 02:28:58PM -0400, Paul Schlie wrote:
>
>> int x;
>> volatile int v;
>>
>> x = (v ? 0 : INT_MAX) + 1; // [1, INT_MAX] (without -fwrapv)
>>
>> if (x <= 0) // Which may be erroneously
>> printf("%i is <= 0.",
On Fri, Jun 17, 2005 at 02:28:58PM -0400, Paul Schlie wrote:
> int x;
> volatile int v;
>
> x = (v ? 0 : INT_MAX) + 1; // [1, INT_MAX] (without -fwrapv)
>
> if (x <= 0) // Which may be erroneously
> printf("%i is <= 0.", x); // optimized away, with this.
> else
> print
Paul Schlie wrote:
They need not wrap around. People that are actually on the C standards
committee have told you this multiple times.
Yes, and may clearly produce erroneous results if the value ranges
are not consistent with the factual behavior of an implementation, i.e.:
Are you li
> They need not wrap around. People that are actually on the C standards
> committee have told you this multiple times.
Yes, and may clearly produce erroneous results if the value ranges
are not consistent with the factual behavior of an implementation, i.e.:
int x;
volatile int v;
x = (v ?
On Fri, Jun 17, 2005 at 12:27:55AM -0400, Paul Schlie wrote:
> Upon a potential integer overflow of either it's min or max range,
> shouldn't the result be set to [min:type-min-value, max:type-max-value],
> without the necessity of any further designations?
>
If you want this behaviour, use -fwra
[#1] The signed C integer types int, long, long long and the
corresponding unsigned types are compatible with LIA-1. If an
implementation adds support for the LIA-1 exceptional values
integer_overflow and undefined, then those types are LIA-1
co
> Paolo Bonsini wrote:
>> Upon a potential integer overflow of either it's min or max range,
>> shouldn't the result be set to [min:type-min-value, max:type-max-value],
>> without the necessity of any further designations?
>
> No.
>
> [10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famo
Paul Schlie wrote:
Upon a potential integer overflow of either it's min or max range,
shouldn't the result be set to [min:type-min-value, max:type-max-value],
without the necessity of any further designations?
No.
[10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famous signed
int ov
69 matches
Mail list logo
