* [Bug c/59264] Incorrect order of execution on increament/decrement operator
2013-11-23 16:59 [Bug c/59264] New: Incorrect order of execution on increament/decrement operator smaheshs41 at gmail dot com
@ 2013-11-23 17:05 ` redi at gcc dot gnu.org
2013-11-23 17:06 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2013-11-23 17:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Your code has undefined behaviour because it modifies the same variables more
than once between sequence points.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/59264] Incorrect order of execution on increament/decrement operator
2013-11-23 16:59 [Bug c/59264] New: Incorrect order of execution on increament/decrement operator smaheshs41 at gmail dot com
2013-11-23 17:05 ` [Bug c/59264] " redi at gcc dot gnu.org
@ 2013-11-23 17:06 ` redi at gcc dot gnu.org
2013-11-23 17:54 ` ebotcazou at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2013-11-23 17:06 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 8048 bytes --]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Instead of reporting a bug, try turning warnings on and fixing them, the
compiler tells you what's wrong with your code:
t.c:2:6: warning: return type of âmainâ is not âintâ [-Wmain]
void main()
^
t.c: In function âmainâ:
t.c:5:3: warning: operation on âiâ may be undefined [-Wsequence-point]
i=++i + ++i + i++;
^
t.c:5:3: warning: operation on âiâ may be undefined [-Wsequence-point]
t.c:5:3: warning: operation on âiâ may be undefined [-Wsequence-point]
t.c:8:3: warning: operation on âiâ may be undefined [-Wsequence-point]
i=i++ + ++i + ++i;
^
t.c:8:3: warning: operation on âiâ may be undefined [-Wsequence-point]
t.c:8:3: warning: operation on âiâ may be undefined [-Wsequence-point]
t.c:11:3: warning: operation on âiâ may be undefined [-Wsequence-point]
i=++i + i++ + ++i;
^
t.c:11:3: warning: operation on âiâ may be undefined [-Wsequence-point]
t.c:11:3: warning: operation on âiâ may be undefined [-Wsequence-point]
>From gcc-bugs-return-435646-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 23 17:13:59 2013
Return-Path: <gcc-bugs-return-435646-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5273 invoked by alias); 23 Nov 2013 17:13:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5250 invoked by uid 55); 23 Nov 2013 17:13:55 -0000
From: "smaheshs41 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59264] Incorrect order of execution on increament/decrement operator
Date: Sat, 23 Nov 2013 17:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: smaheshs41 at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59264-4-ckLinwrcD7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59264-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59264-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02423.txt.bz2
Content-length: 2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
--- Comment #3 from Mahesh S <smaheshs41 at gmail dot com> ---
but it gets executed correctly for 1st condition why not for 2nd and 3rd
On Sat, Nov 23, 2013 at 10:36 PM, redi at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
>
> Jonathan Wakely <redi at gcc dot gnu.org> changed:
>
> What |Removed |Added
>
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED |RESOLVED
> Resolution|--- |INVALID
>
> --- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> Instead of reporting a bug, try turning warnings on and fixing them, the
> compiler tells you what's wrong with your code:
>
> t.c:2:6: warning: return type of âmainâ is not âintâ [-Wmain]
> void main()
> ^
> t.c: In function âmainâ:
> t.c:5:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> i=++i + ++i + i++;
> ^
> t.c:5:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> t.c:5:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> t.c:8:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> i=i++ + ++i + ++i;
> ^
> t.c:8:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> t.c:8:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> t.c:11:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> i=++i + i++ + ++i;
> ^
> t.c:11:3: warning: operation on âiâ may be undefined [-Wsequence-point]
> t.c:11:3: warning: operation on âiâ may be undefined [-Wsequence-point]
>
> --
> You are receiving this mail because:
> You reported the bug.
>
>From gcc-bugs-return-435647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 23 17:37:38 2013
Return-Path: <gcc-bugs-return-435647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15105 invoked by alias); 23 Nov 2013 17:37:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15059 invoked by uid 48); 23 Nov 2013 17:37:32 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/58314] SH4 error: 'asm' operand requires impossible reload
Date: Sat, 23 Nov 2013 17:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-58314-4-Zt6tTnFi3q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58314-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58314-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02424.txt.bz2
Content-length: 1128
http://gcc.gnu.org/bugzilla/show_bug.cgi?idX314
--- Comment #14 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 31283
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id1283&actioníit
re-work movqi / movhi insns
The attached patch seems to fix the problem.
It removes the questionable reg_reg pattern and allows the *movqi / *movhi
pattern to match any memory address. However, instead of using the "m" memory
constraint, "Sdd" (displacement address mode only) and "Snd" (any address mode
except displacement) are used, so that the R0 reg "z" constraint can be used
appropriately.
The "Snd" memory constraint had to be fixed for this to work. Some other minor
changes were required for calculating the proper *movqi / *movhi insn size
(which depends on the size of the displacement constant).
CSiBE doesn't show any regressions regarding displacement addressing modes for
SH4 and SH2A and the test cases for this PR compile fine for me.
Although not fully tested yet, could you guys please have a look at it?
Christian, does it fix your Linux build problems, or are there still more / new
ones?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/59264] Incorrect order of execution on increament/decrement operator
2013-11-23 16:59 [Bug c/59264] New: Incorrect order of execution on increament/decrement operator smaheshs41 at gmail dot com
2013-11-23 17:05 ` [Bug c/59264] " redi at gcc dot gnu.org
2013-11-23 17:06 ` redi at gcc dot gnu.org
@ 2013-11-23 17:54 ` ebotcazou at gcc dot gnu.org
2013-11-24 8:52 ` smaheshs41 at gmail dot com
2013-11-24 9:14 ` ebotcazou at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2013-11-23 17:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu.org
--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> but it gets executed correctly for 1st condition why not for 2nd and 3rd
Both executions are correct since the code has undefined behavior.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/59264] Incorrect order of execution on increament/decrement operator
2013-11-23 16:59 [Bug c/59264] New: Incorrect order of execution on increament/decrement operator smaheshs41 at gmail dot com
` (2 preceding siblings ...)
2013-11-23 17:54 ` ebotcazou at gcc dot gnu.org
@ 2013-11-24 8:52 ` smaheshs41 at gmail dot com
2013-11-24 9:14 ` ebotcazou at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: smaheshs41 at gmail dot com @ 2013-11-24 8:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
--- Comment #5 from Mahesh S <smaheshs41 at gmail dot com> ---
[Bug c/59264] Incorrect order of execution on increament/decrement operator
But it works correctly in Turbo C and Borland C compiler why not in gcc
On Sat, Nov 23, 2013 at 11:23 PM, ebotcazou at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
>
> Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
>
> What |Removed |Added
>
> ----------------------------------------------------------------------------
> CC| |ebotcazou at gcc dot
> gnu.org
>
> --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > but it gets executed correctly for 1st condition why not for 2nd and 3rd
>
> Both executions are correct since the code has undefined behavior.
>
> --
> You are receiving this mail because:
> You reported the bug.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/59264] Incorrect order of execution on increament/decrement operator
2013-11-23 16:59 [Bug c/59264] New: Incorrect order of execution on increament/decrement operator smaheshs41 at gmail dot com
` (3 preceding siblings ...)
2013-11-24 8:52 ` smaheshs41 at gmail dot com
@ 2013-11-24 9:14 ` ebotcazou at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2013-11-24 9:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> But it works correctly in Turbo C and Borland C compiler why not in gcc
Well, the point is precisely that all executions, Turbo C, Borland C or GCC,
are equally correct, since the code has undefined behavior...
^ permalink raw reply [flat|nested] 6+ messages in thread