Re: [mem-ssa] Updated documentation

[Ira Rosen]

Hi Diego,

In the example of dynamic partitioning below (Figure 6), I don't understand
why MEM7 is not killed in line 13 and is killed in line 20 later. As far as
I understand, in line 13 'c' is in the alias set, and it's currdef is MEM7,
so it must be killed by the store in line 14. What am I missing?

Thanks,
Ira


a, b, c} q6 points?to {b, c}
CD(v) means that the generated MEM i name is the “current definition” for
v.
LU(v) looks up the “current definition” for v.
The initial SSA name for MEM is MEM7.

1 . . .
2 # MEM8 = VDEF  ) CD(a)
3 a = 2
4
5 # MEM10 = VDEF  ) CD(b)
6 b = 5
7
8 # VUSE  ) LU(b)
9 b.311 = b
10
11 D.153612 = b.311 + 3
12
13 # MEM25 = VDEF  ) CD(a, b, c)
14 *p5 = D.153612
15
16 # VUSE  ) CD(b)
17 b.313 = b
18 D.153714 = 10 ? b.313
19
20 # MEM26 = VDEF  ) CD(b, c)
21 *q6 = D.153714
22
23 # VUSE  ) LU(a)
24 a.415 = a
25
26 # MEM17 = VDEF  ) CD(SFT.2)
27 X.x = a.415
28 return
}

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gerald Pfeifer]

On Tue, 2 Jan 2007, Gabriel Dos Reis wrote:
>|>   for (i = 1; i < m; ++i)
>|> {
>|>   if (i > 0)
>|> bar ();
>|> }
>| Of course, this is an example where either the programmer is doing 
>| something very silly or else is expecting overflow and depending on 
>| wrap semantics, so it seems to me marginal to remove that "if".  My 
>| suggestion would be to issue a warning saying that the test will never 
>| be false, but leaving it in.
> That make sense to me.

I'm worried about our ability to optimize deeply inlined code and things 
like template-heavy C++ code if do skip optimizations like this.

Gerald

Re: gfortran year end status report

[FX Coudert]

Thanks a lot Steve for taking time to prepare and write this mail.

FX

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Guenther]

On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote:


On Dec 31, 2006, at 19:13, Daniel Berlin wrote:
> Note the distinct drop in performance across almost all the benchmarks
> on Dec 30, including popular programs like bzip2 and gzip.
Not so.

To my eyes, the specint 2000 mean went UP by about 1% for the
base -O3 compilation. The peak enabled more unrolling, which
is helped by additional range information provided by absence
of -frwapv.

So, I'd say this run would suggest enabling -fwrapv for
at least -O1 and -O2. Also, note that we never have
focussed on performance with -fwrapv, and it is quite
likely there is quite some improvement possible.

I'd really like using -fwrapv by default for -O, -O[s12].
The benefit of many programs moving from "undefined semantics"
to "implementation-defined semantics, overflow wraps like in
old compilers" far outweighs even an average performance loss
of 2% as seen in specfp.


I would support the proposal to enable -fwrapv for -O[01], but
not for -O2 as that is supposed to be "optimize for speed" and
as -O3 is not widely used to optimize for speed (in fact it may
make code slower).  I'm undecided for -Os but care less about it.

Richard.

Re: gfortran year end status report

[Paul Thomas]

FX Coudert wrote:

Thanks a lot Steve for taking time to prepare and write this mail.

FX


I second that - the only axe that I have to grind about it is that the 
majority of my commits were patches to patches of the same fix :-)


Paul

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Guenther]

On 1/2/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:

Daniel Berlin wrote:

>> Richard Guenther added -fwrapv to the December 30 run of SPEC at
>> 
>> and
>> .
>> Daniel Berlin and Geert Bosch disagreed about how to interpret
>> these results; see .

Thank you for pointing that out.  I apologize for having missed it
previously.

As others have noted, one disturbing aspect of that data is that it
shows that there is sometimes an inverse correlation between the base
and peak flags.  On the FP benchmarks, the results are mostly negative
for both base and peak (with 168.wupwise the notable exception); on the
integer benchmarks it's more mixed.  It would be nice to have data for
some other architectures: anyone have data for ARM/Itanium/MIPS/PowerPC?

So, my feeling is similar to what Daniel expresses below, and what I
think Ian has also said: let's disable the assumption about signed
overflow not wrapping for VRP, but leave it in place for loop analysis.

Especially given:

>> We don't have an exhaustive survey, but of the few samples I've
>> sent in most of code is in explicit overflow tests.  However, this
>> could be an artifact of the way I searched for wrapv-dependence
>> (basically, I grep for "overflow" in the source code).  The
>> remaining code depended on -INT_MIN evaluating to INT_MIN.  The
>> troublesome case that started this thread was an explicit overflow
>> test that also acted as a loop bound (which is partly what caused
>> the problem).

it sounds like that would eliminate most of the problem.  Certainly,
making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
easy thing to do; that's just a guarantee about constant folding.
There's no reason for us not to document that signed arithmetic wraps
when folding constants, since we're going to fold the constant to
*something*, and we may as well pick that answer.

I don't even necessarily think we need to change our user documentation.
 We can just choose to make the compiler not make this assumption for
VRP, and to implement folding as two's-complement arithmetic, and go on
with life.  In practice, we probably won't "miscompile" many
non-conforming programs, and we probably won't miss two many useful
optimization opportunities.

Perhaps Richard G. would be so kind as to turn this off in VRP, and
rerun SPEC with that change?


I can do this.  What I also will do is improve VRP to still fold comparisons
of the for a - 10 > 20 when it knows there is no overflow due to available
range information for a (it doesn't do that right now).  That might eliminate
most of the bad effects of turning on -fwrapv for VRP.  The question is if
we want to assume wrapping semantics for signed ints in VRP then or
if we just not want to assume anything if signed ints happen to wrap?

So, given 'a + 10' with a value range for a being [0, +INF], what should be
the resulting value range?  At the moment with -fno-wrapv we get [10, +INF],
with wrapping semantics we could get ~[-INF+10, 9] (which includes
the range we get with -fno-wrapv).

(I'll do this as I return from yet another short vacation - maybe someone can
beat me on producing the SPEC numbers, a s/flag_wrapv/1/ in VRP should
do it for all places that do not simply call into fold).

Richard.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gabriel Dos Reis]

Gerald Pfeifer <[EMAIL PROTECTED]> writes:

| On Tue, 2 Jan 2007, Gabriel Dos Reis wrote:
| >|>   for (i = 1; i < m; ++i)
| >|> {
| >|>   if (i > 0)
| >|>   bar ();
| >|> }
| >| Of course, this is an example where either the programmer is doing 
| >| something very silly or else is expecting overflow and depending on 
| >| wrap semantics, so it seems to me marginal to remove that "if".  My 
| >| suggestion would be to issue a warning saying that the test will never 
| >| be false, but leaving it in.
| > That make sense to me.
| 
| I'm worried about our ability to optimize deeply inlined code and things 
| like template-heavy C++ code if do skip optimizations like this.

I suspect part of Richard K.'s questions has been to determine, based
on data, what improvements we actually gain from doing that kind of
elimination predicated on undefined-ness of signed integer
arithmetic overflow.  It would be also useful to see how that affects
inlining (for inlining, we may be able to adequately annotate the trees).
I fear I haven't seen any.

-- Gaby

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

[Vladimir Yanovsky]

The testing of the committed patch on the PPC-linux has produced no
regressions relatively to the state that was before the bootstrap
break-up. The same holds for the Andrew's version of the patch. 21
testsuite failures on PPC-linux that were introduced together with the
bootstrap problem has disappeared with this commit.

Vladimir

On 1/1/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:

Hi,
I've commited the following patch that fixes the obvious problem of
calling emit_insn_1 for INSN_LIST argument.  It seems to solve the
problems I can reproduce and it bootstraps x86_64-linux/i686-linux and
Darwin (thanks to andreast).  The patch was preaproved by Ian.  This is
meant as fast fix to avoid bootstrap.  Andrew's optimization still makes
sense as an microoptimization and the nested libcall issue probably
ought to be resolved, but can be dealt with incrementally.

My apologizes for the problems.
Honza

Index: ChangeLog
===
--- ChangeLog   (revision 120315)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2007-01-01  Jan Hubicka  <[EMAIL PROTECTED]>
+
+   * emit-rtl.c (emit_copy_of_insn_after): Do not call copy_insn_1 for
+   INSN_LIST.
+
 2007-01-01  Mike Stump  <[EMAIL PROTECTED]>

* configure.ac (HAVE_GAS_LITERAL16): Add autoconf check for
Index: emit-rtl.c
===
--- emit-rtl.c  (revision 120313)
+++ emit-rtl.c  (working copy)
@@ -5302,7 +5302,7 @@ emit_copy_of_insn_after (rtx insn, rtx a
else
  REG_NOTES (new)
   = gen_rtx_INSN_LIST (REG_NOTE_KIND (link),
-copy_insn_1 (XEXP (link, 0)),  REG_NOTES (new));
+XEXP (link, 0),  REG_NOTES (new));
   }

   /* Fix the libcall sequences.  */

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Kenner]

> I can do this.  What I also will do is improve VRP to still fold comparisons
> of the for a - 10 > 20 when it knows there is no overflow due to available
> range information for a (it doesn't do that right now).

I thought fold-const.c optimizes that right now and has been for a long time?
If that's the case, I don't see why we should change it: we have absolutely
no evidence of legacy code that would be affected and it's quite common due
to macro substitution.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Kenner]

> | >|>   for (i = 1; i < m; ++i)
> | >|> {
> | >|>   if (i > 0)
> | >|> bar ();
> | >|> }
>
> I suspect part of Richard K.'s questions has been to determine, based
> on data, what improvements we actually gain from doing that kind of
> elimination predicated on undefined-ness of signed integer
> arithmetic overflow.  It would be also useful to see how that affects
> inlining (for inlining, we may be able to adequately annotate the trees).
> I fear I haven't seen any.

Or even NOT based on data: even a list of those optimizations that VRP does
when it can assume no overflow that it couldn't do otherwise.  It would of
course be nicer to get real data, but even the list would be useful.

However, I have changed my mind on the particular case above, mostly due to
the argument about macros and that, in this case, the loop processing will
already assume that "i" doesn't overflow. Since it will make that assumption,
there's no reason for VRP not to as well.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Robert Dewar]

Richard Guenther wrote:

On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote:

 specfp.


I would support the proposal to enable -fwrapv for -O[01], but
not for -O2 as that is supposed to be "optimize for speed" and
as -O3 is not widely used to optimize for speed (in fact it may
make code slower).  I'm undecided for -Os but care less about it.


I think it is a bad idea for the optimization levels to deal with
anything other than optimization. -fwrapv is not about optimization,
it is about changing the language semantics.

So this proposal would be tantamount to implementing a different
language at -O1 and -O2, and having -O2 change the formal
semantic interpretation of the program. That seems a very
bad idea to me.

It is one thing to have different optimization levels do different
amounts of optimization that in practice may have more or less
effect on non-standard programs. It is quite another to guarantee
at a formal semantic level wrapping at -O1 and not -O2.

If we decide to avoid some optimizations at -O1 in this area,
that's fine, but it should not be done by enabling -fwrapv as
one of the (presumably documented) flags included in -O1.

Instead I would just do this silently without the guarantee.

And I continue to favor the compromise approach where loop
optimization can use undefinedness of overflow in dealing
with loop invariants, but we don't by default take advantage
of undefinedess elsewhere.

Then we have two switches:

-fstandard

which allows all optimizations (name can be changed, I
don't care about the name)

-fwrapv

which changes the semantics to require wrapping in
all cases (including loops)

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Kenner]

> Then we have two switches:
> 
> -fstandard
> 
> which allows all optimizations (name can be changed, I
> don't care about the name)
> 
> -fwrapv
> 
> which changes the semantics to require wrapping in
> all cases (including loops)

What about -fno-wrapv for the first?

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Robert Dewar]

Richard Kenner wrote:

Then we have two switches:

-fstandard

which allows all optimizations (name can be changed, I
don't care about the name)

-fwrapv

which changes the semantics to require wrapping in
all cases (including loops)


What about -fno-wrapv for the first?


Possible .. my view was that it is probably not necessary
to distinguish the various subcases which arise now or in
the future of aggressive optimization opportunities based
on assumption of strict standard semantics.

For example, for me in -fstandard, I would tolerate the
"dewar password check example" being optimized to remove
the password check.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Robert Dewar]

Richard Kenner wrote:


What about -fno-wrapv for the first?


Actually I don't like this.

Why? Because it seems weird to have a flag that you
can turn on and off, but the default is neither on
nor off.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Paul Schlie]

> Robert Dewar wrote:
> ...
> I think it is a bad idea for the optimization levels to deal with
> anything other than optimization. -fwrapv is not about optimization,
> it is about changing the language semantics.
> 
> So this proposal would be tantamount to implementing a different
> language at -O1 and -O2, and having -O2 change the formal
> semantic interpretation of the program. That seems a very
> bad idea to me.
> ...

Yes, it would be laudable for GCC to adopt the principle that whatever
language semantics are chosen in absents of optimization should be
preserved through -O2 by default; although may be explicitly overridden
as may be desired by the user.

Further as this may be target specific, for target machine implementations
which inherently support trapping on overflow (or null pointer dereference);
GCC may correspondingly then enable through -O2 optimizations presuming the
same; but by principle not otherwise for targets for which GCC does not
factually support these semantics.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Robert Dewar]

Paul Schlie wrote:


So this proposal would be tantamount to implementing a different
language at -O1 and -O2, and having -O2 change the formal
semantic interpretation of the program. That seems a very
bad idea to me.
...


Yes, it would be laudable for GCC to adopt the principle that whatever
language semantics are chosen in absents of optimization should be
preserved through -O2 by default; although may be explicitly overridden
as may be desired by the user.


Note Paul that I think you may be confusing what I say, when I talk
about language semantics, I am talking about the formal semantics of
the language, which may well have non-deterministic, undefined, or
implementation defined elements. I am NOT talking about preserving
observed behavior. You have rather consistently confused the two.


Further as this may be target specific, for target machine implementations
which inherently support trapping on overflow (or null pointer dereference);
GCC may correspondingly then enable through -O2 optimizations presuming the
same; but by principle not otherwise for targets for which GCC does not
factually support these semantics.


No, that's completely wrong, overflow is undefined in the semantics, so
preserving undefined semantics has nothing whatever with preserving
observed behavior for these programs with undefined semantics. Here
is exactly where you are confusing behavior with semantics.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Guenther]

On 1/2/07, Robert Dewar <[EMAIL PROTECTED]> wrote:

Richard Guenther wrote:
> On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote:
  specfp.
>
> I would support the proposal to enable -fwrapv for -O[01], but
> not for -O2 as that is supposed to be "optimize for speed" and
> as -O3 is not widely used to optimize for speed (in fact it may
> make code slower).  I'm undecided for -Os but care less about it.

I think it is a bad idea for the optimization levels to deal with
anything other than optimization. -fwrapv is not about optimization,
it is about changing the language semantics.

So this proposal would be tantamount to implementing a different
language at -O1 and -O2, and having -O2 change the formal
semantic interpretation of the program. That seems a very
bad idea to me.


We do that with -fstrict-aliasing, which also changes language semantics.
-fstrict-aliasing is disabled for -O0 and -O1 and enabled for -O[23s].


It is one thing to have different optimization levels do different
amounts of optimization that in practice may have more or less
effect on non-standard programs. It is quite another to guarantee
at a formal semantic level wrapping at -O1 and not -O2.

If we decide to avoid some optimizations at -O1 in this area,
that's fine, but it should not be done by enabling -fwrapv as
one of the (presumably documented) flags included in -O1.

Instead I would just do this silently without the guarantee.

And I continue to favor the compromise approach where loop
optimization can use undefinedness of overflow in dealing
with loop invariants, but we don't by default take advantage
of undefinedess elsewhere.


I fear this is not as easy as it sounds, as loop optimizers (and basically
every optimizer) calls back into fold to do simplifications to for example
predicates it tries to prove.  Unless you change this by either duplicating
these parts of fold or putting logic into fold that checks
current_pass == loop_optimizer
you will not catch those cases.

Also all of VRP, loop optimizers and fold do comparison simplification which
benefits from signed overflow undefinedness the most (note that this is another
area of cleanup I'm likely to touch in not too distant future).


Then we have two switches:

-fstandard

which allows all optimizations (name can be changed, I
don't care about the name)

-fwrapv

which changes the semantics to require wrapping in
all cases (including loops)


How do these switches implement your proposal?  "All optimiations" sounds
like the -fno-wrapv case we have now.

Richard.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Robert Dewar]

Richard Guenther wrote:


We do that with -fstrict-aliasing, which also changes language semantics.
-fstrict-aliasing is disabled for -O0 and -O1 and enabled for -O[23s].


Yes, and as others have said, this is a bad precedent, and should
not be followed further. Inclusion of -fwrapv would be much worse,
since this has clearly and precisely defined semantics. In the
case of -fno-strict-aliasing, it is more like disabling an
optimization, since as far as I know there is no clear semantic
meaning for this flag (i.e. a meaning that could be expressed
formally at the level of the standard easily).


How do these switches implement your proposal?  "All optimiations" sounds
like the -fno-wrapv case we have now.


In a couple of ways:

First it can include semantics other than wrapping
Second, it allows completely unfettered optimization (see
password example), which I think no one would want to do
by default.


Richard.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Kenner]

> We do that with -fstrict-aliasing, which also changes language semantics.

Well, yes, but not quite in the same way.  Indeed it's rather hard to
describe in what way it changes the language semantics but easier to
describe the effect it has on optimization.  I think -fwrapv is the other
way around.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Guenther]

On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:

> We do that with -fstrict-aliasing, which also changes language semantics.

Well, yes, but not quite in the same way.  Indeed it's rather hard to
describe in what way it changes the language semantics but easier to
describe the effect it has on optimization.  I think -fwrapv is the other
way around.


Well, while the effect of -fstrict-aliasing is hard to describe (TBAA
_is_ a complex
part of the standard), -fno-strict-aliasing rules are simple.  All
loads and stores
alias each other if they cannot be proven not to alias by points-to analysis.

Richard.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Robert Dewar]

Richard Guenther wrote:

On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:

We do that with -fstrict-aliasing, which also changes language semantics.

Well, yes, but not quite in the same way.  Indeed it's rather hard to
describe in what way it changes the language semantics but easier to
describe the effect it has on optimization.  I think -fwrapv is the other
way around.


Well, while the effect of -fstrict-aliasing is hard to describe (TBAA
_is_ a complex
part of the standard), -fno-strict-aliasing rules are simple.  All
loads and stores
alias each other if they cannot be proven not to alias by points-to analysis.


That's an implementation oriented analysis, and indeed it is easy
to say at the implementation level what this means. What is not
easy is to describe the formal semantics of the resulting language
at the level of the standard.


Richard.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Richard Kenner]

> Well, while the effect of -fstrict-aliasing is hard to describe
> (TBAA _is_ a complex part of the standard), -fno-strict-aliasing
> rules are simple.  All loads and stores alias each other if they
> cannot be proven not to alias by points-to analysis.

Yes, the rules are "simple", but are written in terms of OPTIMIZATIONS, not
of language concepts: you can't talk about "points-to-analysis" in a language
standard!

In other words, -fwrapv says that we are modifying the language semantics to
define signed overflows as wrapping and this will have effects on the
optimizer (so the language effect is primary), while -fno-strict-aliasing
says what the optimizer will do and hence how we're modifying the language
(meaning the optimizer effect is primary).

There's isn't that big a difference here, admittedly and I agree that it's
unfortunate that we do this for strict aliasing, but I doing it for -fwrapv
would be even worse for the above reason.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Paul Schlie]

> Richard Kenner wrote:
> ...
> In other words, -fwrapv says that we are modifying the language semantics
> to define signed overflows as wrapping and this will have effects on the
> optimizer (so the language effect is primary), while -fno-strict-aliasing
> says what the optimizer will do and hence how we're modifying the language
> (meaning the optimizer effect is primary).
> ...

> Robert Dewar wrote:
> ...
> Note Paul that I think you may be confusing what I say, when I talk
> about language semantics, I am talking about the formal semantics of
> the language, which may well have non-deterministic, undefined, or
> implementation defined elements. I am NOT talking about preserving
> observed behavior. You have rather consistently confused the two.
> ...
> No, that's completely wrong, overflow is undefined in the semantics, so
> preserving undefined semantics has nothing whatever with preserving
> observed behavior for these programs with undefined semantics. Here
> is exactly where you are confusing behavior with semantics.
> ...

Any any choice/presumption of a signed overflow semantics alters the
languages specification (including the presumption of it's absents) as
it's semantics are undefined.

Given the controversy surrounding the issue is seems rooted in that some
optimizations enabled by default at -O1/O2 modify the expressed semantics
in ways that have been shown to be counterproductive (regardless of their
strictly formal validity), the issue is whether or not such optimizations
should be enabled to by default at these generically specifiable
optimization levels. (for example, first in effect supporting wrapping
semantics in absents of optimization, then presuming their absents during
optimization).

In other words, although the standard enables latitude in these choices,
once an implementation has chosen a set of semantics by way of defining
a mapping to a target's instruction set; should the expressed semantics
be preserved?  Personally the answer is clearly yes within reason, and
only modified by explicit request otherwise through -O2. (As otherwise,
the optimizations are in effect modifying the semantics of the chosen
implementation, which although beneficial in some circumstances, may be
clearly counterproductive in others; although all being strictly
legitimate).

As strict aliasing presumptions may in fact alter the expressed semantics;
this too should arguably only be enabled by explicit request through -O2
to be consistent with the philosophy if adopted.

I appreciate that my views/presumptions may be so inconsistent with the
status quo that they are untenable; and as I feel I've expressed my thoughts
as best I can, I'll leave the issue to rest and hopeful resolution to those
who know better.

[ecj] Fix ArrayStore testsuite failure

[Andrew Haley]

Fixes almost the last gcj test failure on the branch.

Andrew.


2007-01-02  Andrew Haley  <[EMAIL PROTECTED]>

* expr.c (expand_java_arraystore): Make sure we perform a bounds
check at runtime before we perform a type check.

Index: expr.c
===
--- expr.c  (revision 120344)
+++ expr.c  (working copy)
@@ -1127,7 +1127,7 @@
 && TYPE_PRECISION (rhs_type_node) <= 32) ? 
 int_type_node : rhs_type_node);
   tree index = pop_value (int_type_node);
-  tree array_type, array;
+  tree array_type, array, temp, access;
 
   /* If we're processing an `aaload' we might as well just pick
  `Object'.  */
@@ -1149,14 +1149,31 @@
   index = save_expr (index);
   array = save_expr (array);
 
+  /* We want to perform the bounds check (done by
+ build_java_arrayaccess) before the type check (done by
+ build_java_arraystore_check).  So, we call build_java_arrayaccess
+ -- which returns an ARRAY_REF lvalue -- and we then generate code
+ to stash the address of that lvalue in a temp.  Then we call
+ build_java_arraystore_check, and finally we generate a
+ MODIFY_EXPR to set the array element.  */
+
+  access = build_java_arrayaccess (array, rhs_type_node, index);
+  temp = build_decl (VAR_DECL, NULL_TREE, 
+build_pointer_type (TREE_TYPE (access)));
+  java_add_local_var (temp);
+  java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (temp),
+temp, 
+build_address_of (access)));
+
   if (TREE_CODE (rhs_type_node) == POINTER_TYPE)
 {
   tree check = build_java_arraystore_check (array, rhs_node);
   java_add_stmt (check);
 }
   
-  array = build_java_arrayaccess (array, rhs_type_node, index);
-  java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (array), array, rhs_node));  
+  java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (access), 
+build1 (INDIRECT_REF, TREE_TYPE (access), temp),
+rhs_node));  
 }
 
 /* Expand the evaluation of ARRAY[INDEX]. build_java_check_indexed_type makes 

gcc-4.2-20070102 is now available

[gccadmin]

Snapshot gcc-4.2-20070102 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 120347

You'll find:

gcc-4.2-20070102.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20070102.tar.bz2 C front end and core compiler

gcc-ada-4.2-20070102.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20070102.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20070102.tar.bz2  C++ front end and runtime

gcc-java-4.2-20070102.tar.bz2 Java front end and runtime

gcc-objc-4.2-20070102.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20070102.tar.bz2The GCC testsuite

Diffs from 4.2-20061226 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Mark Mitchell]

Richard Guenther wrote:

>> Perhaps Richard G. would be so kind as to turn this off in VRP, and
>> rerun SPEC with that change?
> 
> I can do this.

Thank you very much!

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Geert Bosch]

On Jan 1, 2007, at 21:14, Ian Lance Taylor wrote:

[...]
extern void bar (void);
void
foo (int m)
{
  int i;
  for (i = 1; i < m; ++i)
{
  if (i > 0)
bar ();
}
}

Here the limit for i without -fwrapv becomes (1, INF].  This enables
VRP to eliminate the test "i > 0".  With -fwrapv, this test of course
can not be eliminated.  VRP is the only optimization pass which is
able to eliminate that test.


We should be able to optimize this even for -fwrapv.
For i = 0, the loop will not execute at all, for other
i, execution will stop when i == m, after m - 1 executions
of the loop body. The condition i > 0 will never be true,
regardless of -fwrapv as there won't be overflow.

  -Grt

-pg problem

[Adam Sulmicki]

hello,
can someone help me understand what is going on?

are the -p and -pg options supposed to work?



# gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)


the C fragment (from menu.c of mplayer)

#define BUF_MIN 128
#define BUF_MAX BUF_STEP*1024
int menu_init(char* cfg_file) {
  char* buffer = NULL;
  int bl = BUF_STEP, br = 0;
  int f, fd;
#ifndef HAVE_FREETYPE
  if(vo_font == NULL)
return 0;
#endif



# cc -c -I. -I.. -Wdeclaration-after-statement  -march=pentium2
-mtune=pentium2 -pipe -ffast-math -ggdb  -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -pthread
-I/usr/include/kde/artsc -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -o menu.o menu.c
-save-temps
cc: warning: -pipe ignored because -save-temps specified
cc: warning: -pipe ignored because -save-temps specified

# objdump -S -D menu.o -G -C -t -x | less

03a5 :

/// This will build the menu_defs list from the cfg file
#define BUF_STEP 1024
#define BUF_MIN 128
#define BUF_MAX BUF_STEP*1024
int menu_init(char* cfg_file) {
 3a5:   55  push   %ebp
 3a6:   89 e5   mov%esp,%ebp
 3a8:   83 ec 38sub$0x38,%esp
  char* buffer = NULL;
 3ab:   c7 45 e8 00 00 00 00movl   $0x0,0xffe8(%ebp)
  int bl = BUF_STEP, br = 0;
 3b2:   c7 45 ec 00 04 00 00movl   $0x400,0xffec(%ebp)
 3b9:   c7 45 f0 00 00 00 00movl   $0x0,0xfff0(%ebp)
  int f, fd;
#ifndef HAVE_FREETYPE
  if(vo_font == NULL)
return 0;
#endif


now repeat above with extra "-p" flag

# cc -c -I. -I.. -Wdeclaration-after-statement  -march=pentium2
-mtune=pentium2 -pipe -ffast-math -ggdb  -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -pthread
-I/usr/include/kde/artsc -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -o menu.o menu.c
-save-temps -p
cc: warning: -pipe ignored because -save-temps specified
cc: warning: -pipe ignored because -save-temps specified

# objdump -S -D menu.o -G -C -t -x | less

/// This will build the menu_defs list from the cfg file
#define BUF_STEP 1024
#define BUF_MIN 128
#define BUF_MAX BUF_STEP*1024
int menu_init(char* cfg_file) {
 3aa:   55  push   %ebp
 3ab:   89 e5   mov%esp,%ebp
 3ad:   83 ec 38sub$0x38,%esp
 3b0:   e8 00 00 00 00  call   3b5 
3b1: R_386_PC32 .bss
  char* buffer = NULL;
 3b5:   c7 45 e8 00 00 00 00movl   $0x0,0xffe8(%ebp)
  int bl = BUF_STEP, br = 0;
 3bc:   c7 45 ec 00 04 00 00movl   $0x400,0xffec(%ebp)
 3c3:   c7 45 f0 00 00 00 00movl   $0x0,0xfff0(%ebp)
  int f, fd;
#ifndef HAVE_FREETYPE
  if(vo_font == NULL)
return 0;
#endif

now WTF is the line 3b0 ???
ideas?





--
Adam Sulmicki
http://www.eax.com  The Supreme Headquarters of the 32 bit registers

Re: -pg problem

[Ian Lance Taylor]

Adam Sulmicki <[EMAIL PROTECTED]> writes:

>  can someone help me understand what is going on?
> 
>  are the -p and -pg options supposed to work?

This question is not appropriate for gcc@gcc.gnu.org, which is a
mailing list for gcc developments.  It is appropriate for
[EMAIL PROTECTED]

-p does work on GNU/Linux systems.

>   3b0:   e8 00 00 00 00  call   3b5 
>  3b1: R_386_PC32 .bss

That is presumably the call to mcount which records the profiling
information.

Ian

Re: -pg problem

[Adam Sulmicki]

On Tue, 2 Jan 2007, Ian Lance Taylor wrote:


Adam Sulmicki <[EMAIL PROTECTED]> writes:


 can someone help me understand what is going on?

 are the -p and -pg options supposed to work?


This question is not appropriate for gcc@gcc.gnu.org, which is a
mailing list for gcc developments.  It is appropriate for
[EMAIL PROTECTED]

-p does work on GNU/Linux systems.


  3b0:   e8 00 00 00 00  call   3b5 
 3b1: R_386_PC32 .bss


That is presumably the call to mcount which records the profiling
information.


except that :

# grep mcount menu.c
static int mcount = 0;


--
Adam Sulmicki
http://www.eax.com  The Supreme Headquarters of the 32 bit registers

Re: -pg problem

[Adam Sulmicki]

 can someone help me understand what is going on?

 are the -p and -pg options supposed to work?


This question is not appropriate for gcc@gcc.gnu.org, which is a
mailing list for gcc developments.  It is appropriate for
[EMAIL PROTECTED]


I apologize for this.


-p does work on GNU/Linux systems.


  3b0:   e8 00 00 00 00  call   3b5 
 3b1: R_386_PC32 .bss


That is presumably the call to mcount which records the profiling
information.


except that :

# grep mcount menu.c
static int mcount = 0;


Just to wrap things up. I have renamed all occurences of "mcount" in 
sources to something else, and the program does not crash anymore.


Thanks a lot for help!

--
Adam Sulmicki
http://www.eax.com  The Supreme Headquarters of the 32 bit registers

Re: identifing free() in tree-ssa

[Basile STARYNKEVITCH]

On Tue, Jan 02, 2007 at 02:30:45PM -0700, Roger Sayle wrote:
> 
> I think recognizing "free" as a built-in (without an intrinsic) is the
> correct way to go.  In theory, all of the functions listed in
> cp/cfns.gperf should be defined via builtins.def, but unfortunately
> the compile-time (and memory) overhead of constructing a large number of
> builtins at run-time is already noticeable.  Hence, we only define
> those that are most useful [even though I'd like to optimize away calls
> to qsort where n is a compile-time constant zero or one! :-)]
> 
> If anyone has any ideas on how best these builtins can be constructed
> statically and/or lazily, conveniently for those front-ends that can
> benefit from them, I'd be very interested in suggestions.  

Maybe, instead of using built-ins, we could extend the __attribute__
facility for functions (and expect the libc developers to progressively use
them). Eg

   void free(void*) __attribute((pointer_invalid(1)));

would mean that argument #1 of function free is pointer which is invalidated
by the function. Or maybe a pragma for that

Of course, the challenge is then how to have lots of attributes, and not
slow down the compiler... I don't know yet if adding hundreds on definitions
inside gcc/builtin-attrs.def would slow down the compiler.

IMHO, adding new attributes would permit future library developers to
annotate their header files appropriately. This would be more powerful than
understanding only a given standard symbol like free. Of course, the cost of
attributes is that to use them effectively we depend upon library developers
using them actually in their headers.

Happy new year 2007 to everyone.



-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/ 
email: basilestarynkevitchnet mobile: +33 6 8501 2359 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Retiring IPA-branch

[Jan Hubicka]

Hi,
thanks to Diego, Andrew (MacLeod), Daniel and Roger's effort on
reviewing IPA branch merge patches, I hope to commit after re-testing
the patch to enable IPA-SSA today. This means that the main part of
IPA-branch has been merged.  There are still features on IPA branch that
I hope to follow shortly (in particular the pre-inline local
optimization, IP-CP on SSA form by Razya and aliasing by Olga), but
those are all rather localized changes.

I would hope to retire that branch, since it has gained a lot of
dust and also a lot of things has been renamed while merging to mainline
making it outdated. Because the branch is actually used as base for
other development, I would like to ask if there is need for some kind of
"transition plan" to mainline.  If so, I can merge mainline into the
branch and remove most of no longer needed stuff, if it seems to make
things easier or do something else. I will be also happy to help with
any problems with updating the code to mainline implementation or,
naturally, solving any issues that appears with the merge.

At the end of stage 1 I would also like to open new branch targeted to
further improvements and cleanups of IPA infrastructure that can
co-exist in parallel with LTO branch solving other aspects we need to
address before getting useable link time optimization.  Issues I would
like to deal with are the further cleanups to make writting IPA passes
more convenient, probably finally solve the multiple declaration
problems on C and fortran frontend (if not done in mainline before
that), write some basic easy IPA passes (such as removing of unused
arugments and return values, some basic argument passing simplificaiton
and similar cheap stuff) and solve as many of scalability issues as
possible.  Again everyone is welcome to help and hope I didn't
discougrated from that by missing stage1 of 4.2 and thus delaying whole
ipa-branch project by a year. I really didn't anticipated the 4.2
schedule to be so delayed and I had problems justify all the changes in
late stage1 of 4.2 without having enought code developed to take
advantage of them.

Honza

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Diego Novillo]

Mark Mitchell wrote on 01/01/07 14:46:


What a thread this has turned out to be.


Indeed.

In general, I'm not too thrilled with the idea of disabling
transformations for the sake of non-conforming code.  However, I would
not mind a -fconforming flag similar to -fstrict-aliasing.



I haven't yet seen that anyone has actually tried the obvious: run SPEC
with and without -fwrapv.  Would someone please do that?  Or, pick your
favorite high-performance application and do the same.  But, let's get
some concrete data as to how much this optimization helps.


On x86_64:

SPEC2000int is almost identical.
SPEC2000fp shows a -6% drop when using -fwrapv.


-
  HARDWARE
  
CPU: Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz
CPU MHz: 2128.001
FPU: Integrated
 CPU(s) enabled: 2
Secondary Cache: 2048 KB
 Memory: 2053792 kB


  SOFTWARE
  
   Operating System: Linux 2.6.18-1.2868.fc6
   Compiler: GNU C version 4.3.0 20070101 (experimental) (x86_64-unknow
n-linux-gnu)

   NOTES
   -
Base is -O2 -march=nocona -mtune=generic -fwrapv
Peak is -O2 -march=nocona -mtune=generic


   SPEC CINT2000 Summary

Estimated Estimated
  Base  Base  Base  Peak  Peak  Peak
  BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
              
  164.gzip  1400  1271099* 1400  1271106*
  175.vpr   1400  1141227* 1400  1161209*
  176.gcc   X X
  181.mcf   1800  195 921* 1800  194 927*
  186.crafty1000  48.7  2054* 1000  48.2  2076*
  197.parser1800  197 915* 1800  195 923*
  252.eon   1300  64.7  2011* 1300  64.8  2005*
  253.perlbmk   X X
  254.gap   1100  64.9  1696* 1100  65.3  1685*
  255.vortexX X
  256.bzip2 1500  1081384* 1500  1081395*
  300.twolf 3000  1691771* 3000  1691775*
  Est. SPECint_base2000 1391
  Est. SPECint20001394



   SPEC CFP2000 Summary

Estimated Estimated
  Base  Base  Base  Peak  Peak  Peak
  BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
              
  168.wupwise   1600 1031547* 1600  88.3  1812*
  171.swim  3100 1522033* 3100 1452131*
  172.mgrid 1800 193 935* 1800 1311376*
  173.applu 2100 1951076* 2100 1881116*
  177.mesa  1400  71.1  1968* 1400  71.3  1964*
  178.galgel2900 1072699* 2900  99.1  2927*
  179.art   2600  96.7  2689* 2600  94.6  2749*
  183.equake1300  69.0  1884* 1300  67.1  1939*
  187.facerec   1900 1491273* 1900 1461302*
  188.ammp  2200 1701292* 2200 1681312*
  189.lucas 2000 1021965* 2000  98.7  2025*
  191.fma3d 2100 1951079* 2100 1921092*
  200.sixtrack  1100 199 553* 1100 198 556*
  301.apsi  2600 2081248* 2600 1961329*
  Est. SPECfp_base2000  1463
  Est. SPECfp2000 1560

-

[autovect] autovect-branch reopened from latest trunk

[Victor Kaplansky]

I've reopened a new branch autovect-branch, taken off the trunk as of
today.
The branchpoint revision is 120362.  The old branch went way out of synch
with mainline so I've moved it to branches/dead/old-autovect-branch in svn
repository.

New autovect-branch has initialized merge tracking support for svnmerge.py
tool to facilitate merges from trunk in future.

-- Victor

Re: running bprob.exp tests in a cross-testing environment

[Adam Nemet]

Ben Elliston <[EMAIL PROTECTED]> writes:
> I see a couple of solutions, but would like to discuss them here before
> working on a patch:
>
> 1. have the bprob.exp test driver create the appropriate directory
>tree on the target (and remove it when finished); or
>
> 2. set GCOV_PREFIX when running the test case so that the home
>directory on the target is prefixed.  The test harness would
>need to also prefix the .gcda filename when fetching the data
>file from the target.

If it is not too late I'd prefer the latter.  If I understand the
problem correctly the former would still fail if the test user is not
privileged enough to recreate the directory structure under /.

Thanks for working on this.

Adam

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Paul Eggert]

Ian Lance Taylor <[EMAIL PROTECTED]> writes:

> I don't think -frisky is a good name for that option.

Aaaaww.  Nobody will remember boring and forbidding option names like
-fstrict or -fstandard.  Everybody will remember -frisky.  Where's
your sense of pun and -foetry?

Anyway, thanks for your summary of the current situation.  I've
written up something along those lines nin the Autoconf manual and
will CC: it to the gcc list (in a separate message) for everybody's
wise review.  One question, though:

> 3) We perform algebraic simplifications based on the assumption that
>signed arithmetic in the program never overflows.  We can safely
>translate ((X * 10) / 5) to (X / 2) because we assume that X * 10
>will not overflow.

In practice, I've noticed that this optimization is not done if
X * 10 is put into a temporary first.  E.g.:

   #include 
   #include 
   int i = INT_MAX / 2000 + 1;

   int
   main (void)
   {
 int i2000 = i * 2000;
 printf ("%d %d\n", i, i2000 / 1000);
   }

does not rewrite i2000 / 1000 to i * 2 on any of the compilers I have
ready access to.

This assumption that wraparound can be assumed for values put into
explicit temporaries has been documented in the Autoconf manual for
some little time.  Obviously the assumption relies on a common
extension to the C standard; do you think that's a reasonably safe
assumption these days?

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gabriel Dos Reis]

Diego Novillo <[EMAIL PROTECTED]> writes:

| Mark Mitchell wrote on 01/01/07 14:46:
| 
| > What a thread this has turned out to be.
| >
| Indeed.
| 
| In general, I'm not too thrilled with the idea of disabling
| transformations for the sake of non-conforming code.  However, I would
| not mind a -fconforming flag similar to -fstrict-aliasing.
  
Yes, we need a flag of some sort.  

However, a C implementation with LIA-1 semantics is just as conforming
and standard as a C implementation without it.  So, we must be careful
about what we hide behind the flags and what we want it to convey.

-- Gaby

Autoconf manual's coverage of signed integer overflow & portability

[Paul Eggert]

Today I updated the Autoconf manual to contain the following
description of the current situation with signed integer overflow.
This section of the manual is intended to advise programmers what to
do about portable C programs in this area.

I think some discussion along these lines also belongs in the GCC
manual.  As I understand it, though, some of the GCC developers are
loath to make any promises about GCC's behavior on signed overflow, so
the exact wording might be controversial.

Eventually I'd like to add better support for -fwrapv and the like to
Autoconf, but that can wait for further thought and experimentation.

Comments are welcome of course.

--

@node Integer Overflow
@section Integer Overflow
@cindex integer overflow
@cindex overflow, signed integer
@cindex signed integer overflow
@cindex wraparound arithmetic

Many portable C programs assume that signed integer overflow wraps
around reliably using two's complement arithmetic.  Yet the C standard
says that program behavior is undefined on overflow, and in a few cases
C programs do not work on some modern implementations because their
overflows do not wrap around as their authors intended.  Conversely, in
at least one common case related to overflow, the C standard requires
behavior that is commonly not implemented.

@menu
* Integer Overflow Basics::  Why integer overflow is a problem
* Signed Overflow Examples:: Examples of code assuming wraparound
* Optimization and Wraparound::  Optimizations that break uses of wraparound
* Signed Overflow Advice::   Practical advice for signed overflow issues
* Signed Integer Division::  @code{INT_MIN / -1} and @code{INT_MIN % -1}
@end menu

@node Integer Overflow Basics
@subsection Basics of Integer Overflow
@cindex integer overflow
@cindex overflow, signed integer
@cindex signed integer overflow
@cindex wraparound arithmetic

In languages like C, unsigned integer overflow reliably wraps around
modulo the word size.  This is guaranteed by the C standard and is
portable in practice, unless you specify aggressive optimization options
suitable only for special applications.

In contrast, the C standard says that signed integer overflow leads to
undefined behavior where a program can do anything, including dumping
core or overrunning a buffer.  The misbehavior can even precede the
overflow.  Such an overflow can occur during addition, subtraction,
multiplication, division, and left shift.

Despite this requirement of the standard, many C programs and Autoconf
tests assume that signed integer overflow silently wraps around modulo a
power of two, using two's complement arithmetic, so long as you cast the
resulting value to a signed integer type or store it into a signed
integer variable.  If you use conservative optimization flags, such
programs are generally portable to the vast majority of modern
platforms, with a few exceptions discussed later.

For historical reasons the C standard also allows implementations with
ones' complement or signed magnitude arithmetic, but it is safe to
assume two's complement nowadays.

@node Signed Overflow Examples
@subsection Examples of Code Assuming Wraparound Overflow
@cindex integer overflow
@cindex overflow, signed integer
@cindex signed integer overflow
@cindex wraparound arithmetic

There has long been a tension between what the C standard requires for
signed integer overflow, and what C programs commonly assume.  The
standard allows aggressive optimizations based on assumptions that
overflow never occurs, but many practical C programs rely on overflow
wrapping around.  These programs do not conform to the standard, but
they commonly work in practice because compiler writers are
understandably reluctant to implement optimizations that would break
many programs, unless perhaps a user specifies aggressive optimization.

The C Standard says that if a program has signed integer overflow its
behavior is undefined, and the undefined behavior can even precede the
overflow.  To take an extreme example:

@c Inspired by Robert Dewar's example in
@c  (2007-01-01).
@example
if (password == expected_password)
  allow_superuser_privileges ();
else
  printf ("%d password mismatches\n", counter++);
@end example

@noindent
If @code{counter} is an @code{int} and a compiler can deduce that
@code{counter == INT_MAX} or that @code{counter} previously overflowed,
the C standard allows the compiler to optimize away the password test
and generate code that allows superuser privileges unconditionally.

Despite this requirement by the standard, it has long been common for C
code to assume wraparound arithmetic after signed overflow, and all
known practical C implementations support some C idioms that assume
wraparound signed arithmetic, even if the idioms does not conform
strictly to the standard.  If your code looks like the following
examples it will almost surely work with real-world compilers.

Here is an example derived fro

Re: Autoconf manual's coverage of signed integer overflow & portability

[Richard Kenner]

A few comments:

> Many portable C programs assume that signed integer overflow wraps around
> reliably using two's complement arithmetic.

I'd replace "portable C programs" with "widely-used C programs".  The normal
use of "portable" means that it conforms to the standard.

> Conversely, in at least one common case related to overflow, the C standard
> requires behavior that is commonly not implemented.

To what does this refer, the (x * 10 / 5) case?

> In languages like C, unsigned integer overflow reliably wraps around modulo
> the word size.

You mean modulo 2 ** word size.

> This is guaranteed by the C standard and is portable in practice, unless
> you specify aggressive optimization options suitable only for special
> applications.

Not sure what the ", unless" part means.  Any conforming C compiler must
support this, so there's no need to qualify by that clause or even "in
practice".  This is portable and supported by all C compilers, period.

> Ideally the safest approach is to avoid signed integer overflow
> entirely.  For example, instead of multiplying two signed integers, you
> can convert them to unsigned integers, multiply the unsigned values,
> then test whether the result is in signed range.
> 
> Rewriting code in this way will be inconvenient, though, particularly if
> the signed values might be negative.  Also, it will probably hurt
> performance.  

Why would it hurt performance?  Conversions between signed and unsigned are
noops and signed and unsigned arithmetic generate identical instructions.
You should get exactly the same generated code by doing this.  And if you
bury it in macros, it isn't even particularly inconvenient.

> If your code uses an expression like @code{(i * 2000) / 1000} and you
> actually want the multiplication to wrap around reliably, put the
> product into a temporary variable and divide that by 1000.  This
> inhibits the algebraic optimization on many platforms.

I'd be dubious about including this.  Basically the only reason GCC doesn't
optimize the temporary variable case is because there's no tree-level
combiner.  But there will be some day.  Also, the out-of-ssa pass could
presumably do this.  With gimplification, there's very little difference for
most optimizers (except the constant folder, which just so happens to be the
relevant one here) between temporaries in user code and those created by the
gimplifier.

The chance of somebody actually neededing wraparound semantics on such an
expressions strikes me as vanishingly small and if they do need it, the ought
to be able to figure out valid ways of writing it to get it.

Re: Autoconf manual's coverage of signed integer overflow & portability

[Andrew Pinski]

> 
> Today I updated the Autoconf manual to contain the following
> description of the current situation with signed integer overflow.
> This section of the manual is intended to advise programmers what to
> do about portable C programs in this area.
> 
> I think some discussion along these lines also belongs in the GCC
> manual.  As I understand it, though, some of the GCC developers are
> loath to make any promises about GCC's behavior on signed overflow, so
> the exact wording might be controversial.
> 
> Eventually I'd like to add better support for -fwrapv and the like to
> Autoconf, but that can wait for further thought and experimentation.
> 
> Comments are welcome of course.

Really this should be documented in the C books people learn from.  This
problem is that those books don't talk about these undefined behavior at 
all.  Aliasing has the same issue.  So does sequence points.  New code
should not be punished because the standard books that people learn from
are all broken.  I can tell you most C/C++ books don't talk any undefined
behavior at all.

Also most C++ books don't talk much about namelookup in templates either
which is the other highly reported non bug to GCC.

-- Pinski

Re: Autoconf manual's coverage of signed integer overflow & portability

[Paul Eggert]

[EMAIL PROTECTED] (Richard Kenner) writes:

> A few comments:

Thanks for the quick review.

>> Many portable C programs assume that signed integer overflow wraps around
>> reliably using two's complement arithmetic.
>
> I'd replace "portable C programs" with "widely-used C programs".  The normal
> use of "portable" means that it conforms to the standard.

I was looking for an adjective that mean the programs work on a wide
variety of platforms, and "portable" seems more appropriate than
"widely-used".

To my mind "portable" means "can be transported", which is a broader
category than "conforms to a standard".  For example,
 mentions both ISO standards and
GCC as alternative methods of producing portable software.  (It also
mentions Autoconf!  Wikipedia rules. :-)

>> Conversely, in at least one common case related to overflow, the C standard
>> requires behavior that is commonly not implemented.
>
> To what does this refer, the (x * 10 / 5) case?

No, INT_MIN % -1.  Thanks, I'll reword it.

>> This is guaranteed by the C standard and is portable in practice, unless
>> you specify aggressive optimization options suitable only for special
>> applications.
>
> Not sure what the ", unless" part means.

I was referring to the aggressive optimization options mentioned in
the earlier thread for non-GCC compilers, which result in
nonconforming (but presumably faster) implementations where unsigned
overflow does not wrap around reliably.

>> Rewriting code in this way will be inconvenient, though, particularly if
>> the signed values might be negative.  Also, it will probably hurt
>> performance.  
>
> Why would it hurt performance?

Lots of reasons, e.g., when the type in question isn't apriori known
(it's off_t, say) and you have to substitute a possibly-wider unsigned
type without a lot of Autoconf magic that most people won't bother
with.  However, I'll tone down the wording.

> if you bury it in macros, it isn't even particularly inconvenient.

Even for off_t and so forth?  I'll have to see that

>> If your code uses an expression like @code{(i * 2000) / 1000} and you
>> actually want the multiplication to wrap around reliably, put the
>> product into a temporary variable and divide that by 1000.  This
>> inhibits the algebraic optimization on many platforms.
>
> I'd be dubious about including this.

Yes, I was a bit dubious too, which is why I asked.  But...

> The chance of somebody actually neededing wraparound semantics on such an
> expressions strikes me as vanishingly small

I'm afraid it's not that small, as that method (assigning to a
temporary so that the compiler doesn't over-optimize due to signed
overflow assumptions) is used in many real-world applications, partly
because it works, and partly I suppose by analogy from 'double'.
(Sigh.  Now you'll probably want me to go find instances of that, too.
Do I get extra points for finding an instance in GCC?  :-)

Re: Autoconf manual's coverage of signed integer overflow & portability

[Russell Shaw]

Richard Kenner wrote:

A few comments:


Many portable C programs assume that signed integer overflow wraps around
reliably using two's complement arithmetic.


I'd replace "portable C programs" with "widely-used C programs".  The normal
use of "portable" means that it conforms to the standard.


Conversely, in at least one common case related to overflow, the C standard
requires behavior that is commonly not implemented.


To what does this refer, the (x * 10 / 5) case?


In languages like C, unsigned integer overflow reliably wraps around modulo
the word size.


You mean modulo 2 ** word size.


This is guaranteed by the C standard and is portable in practice, unless
you specify aggressive optimization options suitable only for special
applications.


Not sure what the ", unless" part means.  Any conforming C compiler must
support this, so there's no need to qualify by that clause or even "in
practice".  This is portable and supported by all C compilers, period.


Ideally the safest approach is to avoid signed integer overflow
entirely.  For example, instead of multiplying two signed integers, you
can convert them to unsigned integers, multiply the unsigned values,
then test whether the result is in signed range.

Rewriting code in this way will be inconvenient, though, particularly if
the signed values might be negative.  Also, it will probably hurt
performance.  


Why would it hurt performance?  Conversions between signed and unsigned are
noops and signed and unsigned arithmetic generate identical instructions.
You should get exactly the same generated code by doing this.  And if you
bury it in macros, it isn't even particularly inconvenient.


If your code uses an expression like @code{(i * 2000) / 1000} and you
actually want the multiplication to wrap around reliably, put the
product into a temporary variable and divide that by 1000.  This
inhibits the algebraic optimization on many platforms.


I'd be dubious about including this.  Basically the only reason GCC doesn't
optimize the temporary variable case is because there's no tree-level
combiner.  But there will be some day.  Also, the out-of-ssa pass could
presumably do this.  With gimplification, there's very little difference for
most optimizers (except the constant folder, which just so happens to be the
relevant one here) between temporaries in user code and those created by the
gimplifier.

The chance of somebody actually neededing wraparound semantics on such an
expressions strikes me as vanishingly small and if they do need it, the ought
to be able to figure out valid ways of writing it to get it.


Wrap-around is very useful for digital signal processing.

If the intermediate results of a digital filter wraps around but the final
result is in range, you'll still get the correct answer.

I use these wrap-around semantics all the time. Desktop pc programmers may
never use it, but embedded system and dsp programmers will.

Re: Autoconf manual's coverage of signed integer overflow & portability

[Andrew Pinski]

> 
> Wrap-around is very useful for digital signal processing.

Saturation is also very useful for DSPs.  

This is why for embedded C[1], they are adding types which the
user is able to decide which behavior they want instead of
just being undefined.

Let me make the point that signed overflow has been undefined since
before the C standard was finialized and in fact there is a nice
paper/book called "C Traps and Pitfalls[2]" which mentions all of this
back in 1988.

Thanks,
Andrew Pinski

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1021.pdf

[2] http://www.literateprogramming.com/ctraps.pdf

Re: Autoconf manual's coverage of signed integer overflow & portability

[Richard Kenner]

> >> Many portable C programs assume that signed integer overflow wraps around
> >> reliably using two's complement arithmetic.
> >
>
> I was looking for an adjective that mean the programs work on a wide
> variety of platforms, and "portable" seems more appropriate than
> "widely-used".

Maybe just say what you mean, then:  "Many C programs that work on a wide
variety of platforms assume that ..."

> To my mind "portable" means "can be transported", which is a broader
> category than "conforms to a standard".  For example,
>  mentions both ISO standards and
> GCC as alternative methods of producing portable software.  

Which means that, at best, "portable" is ambiguous.  To me, however, I'd
associate it with conformance, so that it would mean "can be transported
due to compliance with a standard".  Since you are looking for a specific
meaning, I suggest simply saying that meaning rather that trying to find
a word to summarize it and run the risk of it meaning different things
to different people.

> I was referring to the aggressive optimization options mentioned in
> the earlier thread for non-GCC compilers, which result in
> nonconforming (but presumably faster) implementations where unsigned
> overflow does not wrap around reliably.

I'd suggest making it clearer that any such compiler that did that is
noncomforming.

> Lots of reasons, e.g., when the type in question isn't apriori known
> (it's off_t, say) and you have to substitute a possibly-wider unsigned
> type without a lot of Autoconf magic that most people won't bother
> with. 

True.  However, I have to say that the idea of having a program in which
off_t values overflow is scary, to say the least!  It strikes me as very
bad programming practice.

> >> If your code uses an expression like @code{(i * 2000) / 1000} and you
> >> actually want the multiplication to wrap around reliably, put the
> >> product into a temporary variable and divide that by 1000.  This
> >> inhibits the algebraic optimization on many platforms.
> >
> > The chance of somebody actually neededing wraparound semantics on such an
> > expressions strikes me as vanishingly small
> 
> I'm afraid it's not that small, as that method (assigning to a
> temporary so that the compiler doesn't over-optimize due to signed
> overflow assumptions) is used in many real-world applications, partly
> because it works, and partly I suppose by analogy from 'double'.

I'm not talking about the METHOD here, but about the likelihood that somebody
would actually WANT to compute the value ((i * 2000) mod 2**32) / 1000.

As to the method, however, I disagree with suggesting it because the
difference between compiler-generated temporaries and user temporaries is
getting smaller and smaller. I don't think it's worked for 'double' in years.

Re: Autoconf manual's coverage of signed integer overflow & portability

[Robert Dewar]

Richard Kenner wrote:

A few comments:


Many portable C programs assume that signed integer overflow wraps around
reliably using two's complement arithmetic.


I'd replace "portable C programs" with "widely-used C programs".  The normal
use of "portable" means that it conforms to the standard.


Actually the use of portable here is quite appropriate, it emphasizes
that such programs in general are pretty portable *despite* the fact
that they do not conform to the standard.

Re: Autoconf manual's coverage of signed integer overflow & portability

[Paul Eggert]

Andrew Pinski <[EMAIL PROTECTED]> writes:

> Let me make the point that signed overflow has been undefined since
> before the C standard was finialized and in fact there is a nice
> paper/book called "C Traps and Pitfalls[2]" which mentions all of this
> back in 1988.

C Traps and Pitfalls, like K&Rv2, is derived from a draft of the C89
standard and was intended to match the final C89 standard closely.  It
is therefore not a reliable source of information about traditional C.

K&Rv1 is a better source, and as David Daney reports in

it said that integer overflow handling was machine-dependent
and that all existing implementations ignored overflows.
This corresponds to existing practice at the time,
which was that signed overflow wrapped; but clearly
there was an attempt to allow other implementations.

Compiler writers have been trying to drag C users away from C's
traditional wrapping semantics ever since C89 came out, but they
haven't been all that succesful yet.

Re: Autoconf manual's coverage of signed integer overflow & portability

[Paul Eggert]

[EMAIL PROTECTED] (Richard Kenner) writes:

>> >> Many portable C programs assume that signed integer overflow wraps around
>> >> reliably using two's complement arithmetic.
>> >
>>
>> I was looking for an adjective that mean the programs work on a wide
>> variety of platforms, and "portable" seems more appropriate than
>> "widely-used".
>
> Maybe just say what you mean, then:  "Many C programs that work on a wide
> variety of platforms assume that ..."

That's too long!  I'll prepend an "In practice" instead.

> I'd suggest making it clearer that any such compiler that did that is
> noncomforming.

OK, I'll throw in a "nonstandard".

> I have to say that the idea of having a program in which
> off_t values overflow is scary

It's easy to arrange with (for example) GNU dd, which lets you specify
both the start offset and the count, and the user can make the start
as large as they like.  On an older platform with 32-bit off_t I
encountered off_t overflow myself, in a practical application.

Reliable system programs typically have to deal with signed overflows
in basic system types; it's just part of life.  It's not that scary
once you get used to it.

> As to the method, however, I disagree with suggesting it because the
> difference between compiler-generated temporaries and user temporaries is
> getting smaller and smaller. I don't think it's worked for 'double' in years.

OK, I'll suggest using unsigned instead.

Re: Autoconf manual's coverage of signed integer overflow & portability

[Russell Shaw]

Paul Eggert wrote:

Andrew Pinski <[EMAIL PROTECTED]> writes:


Let me make the point that signed overflow has been undefined since
before the C standard was finialized and in fact there is a nice
paper/book called "C Traps and Pitfalls[2]" which mentions all of this
back in 1988.


C Traps and Pitfalls, like K&Rv2, is derived from a draft of the C89
standard and was intended to match the final C89 standard closely.  It
is therefore not a reliable source of information about traditional C.

K&Rv1 is a better source, and as David Daney reports in

it said that integer overflow handling was machine-dependent
and that all existing implementations ignored overflows.
This corresponds to existing practice at the time,
which was that signed overflow wrapped; but clearly
there was an attempt to allow other implementations.

Compiler writers have been trying to drag C users away from C's
traditional wrapping semantics ever since C89 came out, but they
haven't been all that succesful yet.


And replace it with what?

Re: [autovect] autovect-branch reopened from latest trunk

[Dorit Nuzman]

>
> I've reopened a new branch autovect-branch, taken off the trunk as of
> today.
> The branchpoint revision is 120362.  The old branch went way out of synch
> with mainline so I've moved it to branches/dead/old-autovect-branch in
svn
> repository.
>
> New autovect-branch has initialized merge tracking support for
svnmerge.py
> tool to facilitate merges from trunk in future.
>

thanks, Victor.

For the record, the stuff in the old autovect-branch that didn't get to
mainline yet includes omega datadeps (which moved to the graphite branch),
elimination of redundant casts (that would be implemented differently
anyhow - as something like a tree-combine), and call site versioning (which
will be submitted to 4.3).

dorit

> -- Victor
>

Re: Autoconf manual's coverage of signed integer overflow & portability

[Paul Eggert]

Here are further patches I checked into the Autoconf documentation to
reflect today's comments (some of which I received privately).  Thanks
to all of you.  The trickiest bit was documenting one simple way to
reliably detect overflow without converting to unsigned and back.
(At least, I hope it's reliable)

2007-01-02  Paul Eggert  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Integer Overflow): Revised based on today's
feedback.  The most important changes document what happens when
you convert an out-of-range value to a signed integer type, and
say that (sum < a) != (b < 0) reliably detects overflow when sum =
a + b.

--- doc/autoconf.texi   2 Jan 2007 23:06:07 -   1.1122
+++ doc/autoconf.texi   3 Jan 2007 07:18:35 -
@@ -14954,12 +14954,12 @@ the programs work well enough in practic
 @cindex signed integer overflow
 @cindex wraparound arithmetic

-Many portable C programs assume that signed integer overflow wraps
+In practice many portable C programs assume that signed integer overflow wraps
 around reliably using two's complement arithmetic.  Yet the C standard
 says that program behavior is undefined on overflow, and in a few cases
 C programs do not work on some modern implementations because their
-overflows do not wrap around as their authors intended.  Conversely, in
-at least one common case related to overflow, the C standard requires
+overflows do not wrap around as their authors expected.  Conversely, in
+signed integer remainder, the C standard requires overflow
 behavior that is commonly not implemented.

 @menu
@@ -14977,9 +14977,11 @@ behavior that is commonly not implemente
 @cindex signed integer overflow
 @cindex wraparound arithmetic

-In languages like C, unsigned integer overflow reliably wraps around
-modulo the word size.  This is guaranteed by the C standard and is
-portable in practice, unless you specify aggressive optimization options
+In languages like C, unsigned integer overflow reliably wraps around;
+e.g., @code{UINT_MAX + 1} yields zero.
+This is guaranteed by the C standard and is
+portable in practice, unless you specify aggressive,
+nonstandard optimization options
 suitable only for special applications.

 In contrast, the C standard says that signed integer overflow leads to
@@ -15000,6 +15002,12 @@ For historical reasons the C standard al
 ones' complement or signed magnitude arithmetic, but it is safe to
 assume two's complement nowadays.

+Also, overflow can occur when converting an out-of-range value to a
+signed integer type.  Here a standard implementation must define what
+happens, but this might include raising an exception.  In practice all
+known implementations support silent wraparound in this case, so you need
+not worry about other possibilities.
+
 @node Signed Overflow Examples
 @subsection Examples of Code Assuming Wraparound Overflow
 @cindex integer overflow
@@ -15038,7 +15046,7 @@ and generate code that allows superuser 
 Despite this requirement by the standard, it has long been common for C
 code to assume wraparound arithmetic after signed overflow, and all
 known practical C implementations support some C idioms that assume
-wraparound signed arithmetic, even if the idioms does not conform
+wraparound signed arithmetic, even if the idioms do not conform
 strictly to the standard.  If your code looks like the following
 examples it will almost surely work with real-world compilers.

@@ -15060,7 +15068,7 @@ signed overflow when computing the most 
 overflows) or a value near an extreme integer (the first @code{+}
 overflows).

-Here is another example, taken from the 7th Edition implementation of
+Here is another example, derived from the 7th Edition implementation of
 @code{rand} (1979-01-10).  Here the programmer expects both
 multiplication and addition to wrap on overflow:

@@ -15186,7 +15194,7 @@ can convert them to unsigned integers, m
 then test whether the result is in signed range.

 Rewriting code in this way will be inconvenient, though, particularly if
-the signed values might be negative.  Also, it will probably hurt
+the signed values might be negative.  Also, it may hurt
 performance.  Using unsigned arithmetic to check for overflow is
 particularly painful to do portably and efficiently when dealing with an
 integer type like @code{uid_t} whose width and signedness vary from
@@ -15198,6 +15206,10 @@ Hence it is often useful to maintain non
 wraparound on overflow, instead of rewriting the code.  The rest of this
 section attempts to give practical advice for this situation.

+If your code wants to detect signed integer overflow in @code{sum = a +
+b}, it is generally safe to use an expression like @code{(sum < a) != (b
+< 0)}.
+
 If your code uses a signed loop index, make sure that the index cannot
 overflow, along with all signed expressions derived from the index.
 Here is a contrived example of problematic code with two instances of
@@ -15218,9 +15230,8 @@ transform the two c

Re: Autoconf manual's coverage of signed integer overflow & portability

[Andrew Pinski]

> 
> [EMAIL PROTECTED] (Richard Kenner) writes:
> 
> >> >> Many portable C programs assume that signed integer overflow wraps 
> >> >> around
> >> >> reliably using two's complement arithmetic.
> >> >
> >>
> >> I was looking for an adjective that mean the programs work on a wide
> >> variety of platforms, and "portable" seems more appropriate than
> >> "widely-used".
> >
> > Maybe just say what you mean, then:  "Many C programs that work on a wide
> > variety of platforms assume that ..."
> 
> That's too long!  I'll prepend an "In practice" instead.

What about this:
Old C programs that written against the C standard depend on signed
overflow being defined as wrapping.

And then reference the paper, "C traps and pitfalls" (which by the way
was written by the founder of ADL for C++).

I will post a patch to add a link to that paper to the GCC readings page
sometime tomorrow (http://gcc.gnu.org/readings.html).

I hope people learn from their mistakes in the past for depening on this
behavior and actually instead of changing GCC, people fix up their code.
I also hope programs written after 1989 don't depend on this behavior
and we can just declare as them as being broken.  If people when learning
C, don't really learn C, then their code is broken.  I hope people
don't come who don't know C, come to us to ask if we could change GCC
to do something which would hurt performance of their code, just because
they don't know the language they are writting in.  Now we can provide
options for them to allow them to work by making those options default
is wrong.  This is why I am agrueing against even changing VRP, as it
punishes people who don't depend on overflow being wrapping.  Ian's
change in fact punishes people's code who does not depend on that
as it is causes compile time slow down (and an increase of memory usage
inside GCC itself)  which people will complain about.

Thanks,
Andrew Pinski

Re: Autoconf manual's coverage of signed integer overflow & portability

[Andrew Pinski]

> 
> Here are further patches I checked into the Autoconf documentation to
> reflect today's comments (some of which I received privately).  Thanks
> to all of you.  The trickiest bit was documenting one simple way to
> reliably detect overflow without converting to unsigned and back.
> (At least, I hope it's reliable)

Again there is no reliable way without using unsigned.  Some targets
in the future actually do saturation instead of wrapping so detecting
it in way you think is portable and reliable is actually not going
to detect it on those targets.  This is what I have been trying to
say for all my emails.

I would like to say the one thing I have not heard through this
discussion is the real reason why the C standards comittee decided
signed overflow as being undefined.  All I can think of is they were
thinking of target that do saturation for plus/minus but wrapping for
multiplications/divide or even targets that trap for some overflow cases
(like x86) but not others.

Also I think GCC still has a bug with respect of -fwrapv anyways on x86.
Take:

int f(int x, int y)
{
  return x/y;
}

int main(void)
{
  return f(0x8000, -1);
}


This will always cause a trap on x86, even with -fwrapv so really
-fwrapv has a bug on x86.  I will file this bug sometime later
tomorrow.  Oh and fixing this bug will actually slow down users
of -fwrapv even more than what it is currently does because
you can no longer use the div instruction.  So even recommending
-fwrapv for those people who depend on signed overflow is wrong.


Thanks,
Andrew Pinski