--- Comment #12 from pinskia at gcc dot gnu dot org 2006-12-19 22:05
---
See also:
http://gcc.gnu.org/ml/gcc/2006-12/msg00459.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245
--- Comment #11 from dcb314 at hotmail dot com 2006-12-19 22:03 ---
(In reply to comment #10)
> Again use -fwrapv and forget about it.
Sigh. This implies using -fwrapv everywhere.
Still relatively expensive - I still don't know where the compiler
is doing the new behaviour.
For an add
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-12-19 17:40
---
Again use -fwrapv and forget about it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dcb314 at hotmail dot com 2006-12-19 16:37 ---
(In reply to comment #8)
> And they expect a lot from our optimizers.
Surely not at the -O2 level ?
I thought folks serious about optimisation used -O3
and / or a bunch of other flags like -fsomething ?
> The problem i
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-12-19 14:30 ---
>
> Is it reasonable and prudent to have tests like "if (n == 0)"
> optimised away at the -O2 optimisation level ?
>
Yes
> We should remember that -O2 is heavily used by lots of
> customers.
And they expect a lo
--- Comment #7 from dcb314 at hotmail dot com 2006-12-19 12:34 ---
(In reply to comment #6)
> In that case, you might want to read the C++ standard text to
> appreciate the facts.
There is a strange sort of echo in this bug report ;->
I accept the point that the code is undefined, acco
--- Comment #6 from gdr at cs dot tamu dot edu 2006-12-18 10:58 ---
Subject: Re: -O2 generates bad code
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| > then it can only be postive
|
| Plausible, but I don't think so.
In that case, you might want to read the C++ standard
--- Comment #5 from gdr at cs dot tamu dot edu 2006-12-18 10:16 ---
Subject: Re: New: -O2 generates bad code
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| I compiled the following C++ code on a x86_64 machine
| without optimisation.
|
| #include
|
| int
| main()
| {
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 09:59 ---
(In reply to comment #3)
> (In reply to comment #1)
> > then it can only be postive
>
> Plausible, but I don't think so.
Again signed type overflow is undefined by the C standard so it can do
anything.
So in this
--- Comment #3 from dcb314 at hotmail dot com 2006-12-18 09:53 ---
(In reply to comment #1)
> then it can only be postive
Plausible, but I don't think so.
The executed code displays a negative number after about
64 iterations, then displays about thirty zeros.
There is one set bit in
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 09:44 ---
Oh you can use -fwrapv if you want signed type overflow to be defined as
wrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-18 09:39 ---
No, this is undefined code.
since n is a signed type, and the starting n is 1 and it is only multiplied by
2, then it can only be postive and never equal to 0 because overflow for signed
types is undefined.
--
pi
12 matches
Mail list logo
