From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9422 invoked by alias); 25 Oct 2014 21:37:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 9396 invoked by uid 48); 25 Oct 2014 21:37:13 -0000 From: "trippels at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/63645] Incorrect code generation Date: Sat, 25 Oct 2014 21:52: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.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: trippels at gcc dot gnu.org 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: bug_status resolution Message-ID: In-Reply-To: References: 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: 2014-10/txt/msg02005.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63645 Markus Trippelsdorf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Markus Trippelsdorf --- (In reply to M Welinder from comment #5) > You guys are trigger happy. >=20 > > Your union simply takes more space than your GnmExprBinary struct >=20 > Of course it does! The union requires space that is large enough > for its largest member, so having a smaller member is going to be > the case in 99% of unions and the standard has no objections. > If you think otherwise, a reference to the standard would be nice. >=20 > To show that the size difference is irrelevant, simply change > GnmExprBinary to >=20 > typedef struct { > guint8 oper; > int argc; > GnmFunc *func; > } GnmExprBinary; >=20 > whereupon GnmExprBinary, GnmExprFunction, and GnmExpr all take up the > same amount of space. Or adjust your malloc, which is simply too small in your orginal testcase. > We still get this error from valgrind. >=20 > =3D=3D6201=3D=3D Conditional jump or move depends on uninitialised value(= s) > =3D=3D6201=3D=3D at 0x4005F8: test (vvv.c:38) > =3D=3D6201=3D=3D by 0x4004D8: main (vvv.c:49) That is a different issue. You access expr->func.argc and expr->func.func= =20=20 in your if expression. And of course they are uninitialised. >>From gcc-bugs-return-464985-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Oct 25 21:52:32 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 13517 invoked by alias); 25 Oct 2014 21:52:31 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 13474 invoked by uid 48); 25 Oct 2014 21:52:27 -0000 From: "terra at gnome dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/63645] Incorrect code generation Date: Sat, 25 Oct 2014 23:12: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.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: terra at gnome dot org 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: In-Reply-To: References: 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: 2014-10/txt/msg02006.txt.bz2 Content-length: 1185 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #8 from M Welinder --- > That is a different issue. You access expr->func.argc and expr->func.func > in your if expression. And of course they are uninitialised. No, I don't. You see, C has this feature for the && operator that if the first condition is false, then the second is not evaluated. It is in Section 6.5.13 of the standard: 6.5.13 Logical AND operator [...] [#4] Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated. The first condition is false because it compares GNM_EXPR_OP_LT to GNM_EXPR_OP_FUNCALL. These have the values 0 and 1 respectively, which are comfortably within the range of allowed values for type unsigned char. 0 and 1 are not equal, so the == operator (see Section 6.5.9) evaluates to 0. Still thinking about Andrew's suggestion that Valgrind might be at fault. It wouldn't be the first bitfield related problem there.