https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #12 from Paul Eggert ---
Ah, sorry, I am using GCC 6.3.1, whereas __builtin_mul_overflow_p is a GCC
7-ism. Somehow I got it into my head that __builtin_mul_overflow(A,B,C) should
be a constant expression if A, B, are constant express
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #11 from Martin Sebor ---
Right. Because the call to __builtin_mul_overflow in the test case is not a
constant expression, the -Woverflow warning detects the overflow in the
multiplication subexpression that is constant. The __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #10 from Paul Eggert ---
Unfortunately, the patch for Bug#68120 does not seem to have addressed the
problem here. For example, although the following code uses the new feature
enabled by that patch:
int f (void) {
return (__bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #8 from Paul Eggert ---
(In reply to Martin Sebor from comment #7)
> Perhaps what's needed is for GCC to treat the builtins as constant
> expressions when they're invoked with them as operands. If you agree with
> that approach, I s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #7 from Martin Sebor ---
I didn't mean to sound like I was lecturing you, just trying to draw a clear
distinction between the cases.
Perhaps what's needed is for GCC to treat the builtins as constant expressions
when they're invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #6 from Paul Eggert ---
(In reply to Martin Sebor from comment #5)
> This is a valid constant expression
I'm aware of the distinction between constant and other expressions. I'm trying
to give the ordinary user's viewpoint, not the v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #5 from Martin Sebor ---
This is a valid constant expression because 1 is and GCC doesn't warn on the
division by zero:
1 ? 0 : 1 / 0
This is not a constant expression because rand() isn't, and so GCC warns about
the division by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #4 from Paul Eggert ---
(In reply to Martin Sebor from comment #1)
> constant expressions are evaluated during translation
This is not a constant expression. Not that that should matter. For example:
enum { a = (1 ? 0 : 1 / 0) };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #3 from Martin Sebor ---
Yes, the example in footnote is valid because the left operand of the OR
expression is a constant expression with a non-zero value and so the right
operand is not evaluated (even at translation time).
__built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #2 from joseph at codesourcery dot com ---
On Thu, 17 Dec 2015, msebor at gcc dot gnu.org wrote:
> Paul, the way I prefer to look at it is that the C standard says that constant
> expressions are evaluated during translation and when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
13 matches
Mail list logo
