--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-06-29 19:02
---
Docs updated. Committed revision 137254. Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-06-16 16:29
---
Keep this opened until I update the documentation files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-06-15 20:01
---
Subject: Bug 36515
Author: jvdelisle
Date: Sun Jun 15 20:00:41 2008
New Revision: 136821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136821
Log:
2008-06-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-06-15 20:03
---
Subject: Bug 36515
Author: jvdelisle
Date: Sun Jun 15 20:02:58 2008
New Revision: 136822
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136822
Log:
2008-06-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-06-15 20:08
---
Subject: Bug 36515
Author: jvdelisle
Date: Sun Jun 15 20:07:34 2008
New Revision: 136823
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136823
Log:
2008-06-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #1 from kargl at gcc dot gnu dot org 2008-06-12 22:14 ---
Sigh. This has been beaten to death.
-2147483648 is a unary minus operating on the operand 2147483648.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
--- Comment #2 from Walter dot Szeliga at Colorado dot EDU 2008-06-12
22:21 ---
Subject: Re: Integer read from stdin yields a value overflow for a valid
integer.
Sorry, I googled the crap out of it, but didn't find that
explanation. Maybe this should be in the one of the FAQs.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-13 03:04
---
There is no proper way.
Use -2147483647 which is the most negative integer representable in 32 bits.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from Walter dot Szeliga at Colorado dot EDU 2008-06-13
03:09 ---
Subject: Re: Integer read from stdin yields a value overflow for a valid
integer.
OK, thanks. Not that this is something to strive for, but I have some
legacy software that works with G77 (ugh). One
--- Comment #5 from kargl at gcc dot gnu dot org 2008-06-13 03:25 ---
(In reply to comment #3)
There is no proper way.
Use -2147483647 which is the most negative integer representable in 32 bits.
This isn't necessarily true. :)
There are a few options.
1) Add -fno-range-check
--- Comment #6 from kargl at gcc dot gnu dot org 2008-06-13 03:30 ---
As much as I hate -huge()-1, I think this needs to be fix in some
manner. So, I'm re-opening the bug. Jerry et al, if you feel
this should be closed, then please re-close the bug.
--
kargl at gcc dot gnu dot org
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-13 04:19
---
Actually, I was just checking what g77 does and noticed that -fno-range-check
did not do the trick with gfortran as I expected, so Steve beat me to the
punch. For legacy compatibility with g77 I think we should
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-06-13 04:37 ---
So people don't understand that in Fortran types are symmetric? Hasn't they
been symmetric for 20 years now? How can this be for latency programs really?
Maybe gfortran is just the first compiler which enforces
--- Comment #9 from kargl at gcc dot gnu dot org 2008-06-13 05:31 ---
(In reply to comment #8)
So people don't understand that in Fortran types are symmetric? Hasn't they
been symmetric for 20 years now? How can this be for latency programs
really?
Maybe gfortran is just the
15 matches
Mail list logo
