I'm going to use an asm ().
Yeah, an asm volatile ( : : r (x) : ) should please GCC and still be
portable to different platforms.
Paolo
On 2/11/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
I'm going to use an asm ().
Yeah, an asm volatile ( : : r (x) : ) should please GCC and still be
portable to different platforms.
I thought using an asm () for each port to cause an exception specific
for that port. Such that divide-by-zero
Hi,
Division by zero is undefined. We chose to keep it:
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01068.html
But now gcc seems to optimize it away. For the following function:
$ cat t.c
#include limits.h
void foo (int rc)
{
int x = rc / INT_MAX;
x = 4 / x;
}
$ gcc -O2 -S t.c
$ cat t.s
Jie Zhang [EMAIL PROTECTED] writes:
But now gcc seems to optimize it away. For the following function:
$ cat t.c
#include limits.h
void foo (int rc)
{
int x = rc / INT_MAX;
x = 4 / x;
}
I believe we still keep division by zero in general. In your example
it gets optimized away
--- Comment #3 from patchapp at dberlin dot org 2007-01-16 00:57 ---
Subject: Bug number PR 21438
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01166.html
--
) }; by
setting TREE_OVERFLOW. We could do the same for 1/0 and we just don't emit an
overflow warning but a division by zero one. But this could be tricky.
However, an alternative would be to prevent the folding for this specific case,
so the resulting tree is not constant. We could try to detect this when
--- Comment #6 from manu at gcc dot gnu dot org 2006-12-03 21:02 ---
(In reply to comment #3)
Hi Manual,
Manuel (or Manu) http://en.wikipedia.org/wiki/Manuel
not manual: http://en.wikipedia.org/wiki/Manual
:-)
The real issue is that OPT_Wdiv_by_zero needs to be enabled by
--- Comment #7 from joseph at codesourcery dot com 2006-12-03 21:05 ---
Subject: Re: integer division by zero in subexpression should
be overflow
On Sun, 3 Dec 2006, manu at gcc dot gnu dot org wrote:
The real issue is that OPT_Wdiv_by_zero needs to be enabled by -pedantic
;
Next, fold_build2_stat uses build2_stat to construct a valid tree node
(code=TRUNC_DIV_EXPR) but I don't see anything that can be used to detect that
there was a division by zero.
Finally, that tree node is simply omitted when folding 0*expr .
I really don't see how TREE_OVERFLOW could help here
:
case ROUND_DIV_EXPR:
case EXACT_DIV_EXPR:
/* Floating point division by zero is a legitimate way to obtain
infinities and NaNs. */
if (skip_evaluation == 0 integer_zerop (op1))
warning (OPT_Wdiv_by_zero, division by zero);
Likewise, there are several
EXACT_DIV_EXPR:
/* Floating point division by zero is a legitimate way to obtain
infinities and NaNs. */
if (skip_evaluation == 0 integer_zerop (op1))
warning (OPT_Wdiv_by_zero, division by zero);
Likewise, there are several references to OPT_Wdiv_by_zero in cp
--- Comment #4 from pinskia at physics dot uc dot edu 2006-12-01 03:32
---
Subject: Re: integer division by zero in subexpression should be overflow
Hi Manual,
This needs to be handled in the front-ends, and in fact is already handled
^
should
by the front-ends
--- Comment #5 from roger at eyesopen dot com 2006-12-01 04:04 ---
This needs to be handled in the front-ends...
^ should
^^ can only be
I was thinking of a slightly weaker form of need/must.
But there are two issues here. The division by zero is one
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-29 05:59 ---
Just a further note here, divide by 0 is undefined behavior as defined by the C
standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
***
*** 300,308
select 1/0::int8;
ERROR: division by zero
select 1::int2/0;
! ERROR: division by zero
select 1/0::int2;
! ERROR: division by zero
select 1::numeric/0;
ERROR: division by zero
select 1/0::numeric;
--- 300,310
select 1/0::int8;
ERROR: division
--- Comment #1 from tiamat at komi dot mts dot ru 2006-11-24 10:31 ---
Created an attachment (id=12681)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12681action=view)
preprocessed file test.i
$ gcc -v -save-temps -O3 test.c
Using built-in specs.
Target: sparc-linux-gnu
Configured
--- Comment #2 from schwab at suse dot de 2006-11-24 10:34 ---
Your program is invoking undefined behaviour. You should not perform the
division if the divisor is zero.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:37
---
Subject: Bug 19904
Author: jvdelisle
Date: Wed Jun 28 05:36:08 2006
New Revision: 115048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115048
Log:
2006-06-27 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:40
---
Subject: Bug 19904
Author: jvdelisle
Date: Wed Jun 28 05:39:07 2006
New Revision: 115049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115049
Log:
2006-06-27 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:52
---
Fixed on 4.1 branch now.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-06-18 06:42
---
Subject: Bug 19904
Author: jvdelisle
Date: Sun Jun 18 06:42:26 2006
New Revision: 114753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114753
Log:
2006-06-18 Jerry DeLisle [EMAIL PROTECTED]
PR
Summary|Division by zero leads to |[4.1 Only] Division by zero
|error |leads to error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-06-08 01:10
---
This bug is related to 19310
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2006-01-11 13:02 ---
Subject: Bug 23109
Author: bonzini
Date: Wed Jan 11 13:02:18 2006
New Revision: 109578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109578
Log:
gcc:
2006-01-11 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #16 from bonzini at gnu dot org 2006-01-11 14:29 ---
Subject: Bug 23109
Author: bonzini
Date: Wed Jan 11 14:29:29 2006
New Revision: 109586
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109586
Log:
gcc:
2006-01-11 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #17 from bonzini at gnu dot org 2006-01-11 14:30 ---
patch committed to 4.1 too
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-16 14:12 ---
Is this bug going anywhere???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-16 14:16
---
Nobody reviewed the patch AFAIK. Still the patch hasn't caused any problems
sofar in the SUSE compiler.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from bonzini at gcc dot gnu dot org 2005-11-16 14:46
---
I have little hope of seeing this reviewed before the branch. But it should be
put in 4.2 very early so that we backport it well before 4.1.0 is released.
BTW I think that 23948 and 24123 are way more severe
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-11-03 10:05
---
Note that while PR23948 could be fixed by hacking the current recip pass so
that it inserts the division into another basic block, this is not true of this
bug.
--
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-11-01 22:00 ---
It is a showstopper, but a patch has been ready for months... I admit the
patch is non-trivial, but the testcases are comprehensive.
Maybe it's best to wait until the branch and backport it a week later. But I
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-01 22:17
---
Note that the patch is in the suse compiler since three weeks now without a
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:20
---
This is a serious wrong-code problem; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-10-14 12:00 ---
I'm not sure this is really fixed.
With this test case,
float a = g();
printf (%g\n, a);
printf (%g\n, 2 / a);
printf (%g\n, 3 / a);
the division is inserted before the *first* printf, while I believe it should
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-14 12:13 ---
Yes, I think so. You don't even need printf, but any observable side-effect,
like a store to a global will do.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu dot |bonzini at gcc dot gnu dot
|org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-01
08:53 ---
Subject: Bug 23109
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-01 08:53:00
Modified files:
gcc: ChangeLog tree-ssa-loop-im.c
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-01
08:54 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
The attached code crashes on a division by zero when compiled as follows:
dogbert gcc -O1 -funsafe-math-optimizations -ftrapping-math b.c
dogbert a.out
Floating exception
dogbert gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gcc410
--- Additional Comments From p dot van-hoof at qub dot ac dot uk
2005-07-28 10:42 ---
Created an attachment (id=9377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9377action=view)
code that causes the crash
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-28
14:47 ---
Indeed unsafe-math-optimization is not the only precondition for this
transformation.
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-28
15:01 ---
I have a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
wrong|[4.1 Regression] compiler
|code leading to spurious|generates wrong code leading
|division by zero|to spurious division by zero
||with -funsafe-math
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-14
08:30 ---
Fixed by Nathan's patch for PR 20789.
Fixed already on mainline and 3.4 branch.
The patch will be applied to the 4.0 branch once GCC 4.0.1 is out.
So closing as fixed.
--
What|Removed
--
What|Removed |Added
Target Milestone|3.4.4 |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17323
GCC is supposed to suppress division by zero warnings when floating point.
However the warning is based on the lexical form, i.e. the unpromoted type. I
suggest it should depend on the promoted type.
float f[] = {
1.0f/0.0f, // No warning
1.0f/0 // Warning (and diagnostic
EXACT_DIV_EXPR:
/* Floating point division by zero is a legitimate way to obtain
infinities and NaNs. */
- if (warn_div_by_zero skip_evaluation == 0 integer_zerop (op1))
+ if (warn_div_by_zero skip_evaluation == 0
+ integer_zerop (op1) code0 != REAL_TYPE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-07
18:20 ---
Hmm, I wonder why C++ warns though:
t.c:2: warning: division by zero in '1.0e+0f / 0.'
t.c:3: warning: division by zero in '1.0e+0f / 0'
--
What|Removed |Added
The test
enum e { E = 0 * (1 / 0) };
should yield an error with -pedantic-errors. Not a regression.
--
Summary: integer division by zero in subexpression should be
overflow
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
21:18 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11
13:50 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-02-11 17:10 ---
Gfortran is a Fortran 95 compiler, and AFAIK gfortran's behavior conforms
to the Fortran 95 standard, because it has no allowance for floating point
exception. Someday, gfortran may/will
--- Additional Comments From schnetter at aei dot mpg dot de 2005-02-11
17:17 ---
Actually, gfortran handles nans correctly (according to the IEEE standard) in
all other cases. I can e.g. generate a nan through the expression a/b, if I
only hide from the compiler the fact that b is
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-02-11 17:44 ---
You are probably right that my example does not conform to the standard,
because I don't use equilance() and I whipped up the example in a minute
without inspection of its conformance.
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
message is:
mmm.cc: In instantiation of 'A0':
mmm.cc:7: instantiated from here
mmm.cc:3: warning: division by zero in '8 / 0'
g++: Internal error: Segmentation fault (program cc1plus)
The ICE appears with 3.4.0. Before I get the following error message:
mmm.cc: In instantiation of `A0':
mmm.cc:7
301 - 358 of 358 matches
Mail list logo
