Package: gcc-4.3
Version: 4.3.1-6
Severity: normal
This testcase produces different output depending on whether -O1 or -O2 is
specified. Correct:
# gcc PR1386.c -o pr1386 -O1
PR1386.c: In function ‘main’:
PR1386.c:15: warning: large integer implicitly truncated to unsigned
Package: gcc-4.3
Version: 4.3.1-6
Severity: normal
In C99, _Bool is required to map to one of the unsigned types (6.2.5/6). On
i586, this is 'unsigned char', by ABI. That means that you get eight bits to
the _Bool.
However, GCC rejects the following (admittedly unethical) snippet:
struct S7 {
Processing commands for [EMAIL PROTECTED]:
#
# bts-link upstream status pull for source package gcc-4.1
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user [EMAIL PROTECTED]
Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]).
# remote status report for
#
# bts-link upstream status pull for source package gcc-4.3
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user [EMAIL PROTECTED]
# remote status report for #466948
# * http://gcc.gnu.org/PR35659
# * remote status changed: WAITING - ASSIGNED
usertags 466948 -
#
# bts-link upstream status pull for source package gcc-4.1
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user [EMAIL PROTECTED]
# remote status report for #396745
# * http://gcc.gnu.org/PR29443
# * remote status changed: NEW - RESOLVED
# * remote resolution
On Sun, Jul 20, 2008 at 11:32:28PM -0700, Nick Lewycky wrote:
In C99, _Bool is required to map to one of the unsigned types (6.2.5/6).
Please quote the standard. I read something different there.
However, GCC rejects the following (admittedly unethical) snippet:
struct S7 {
_Bool D :
On Sun, Jul 20, 2008 at 11:14:10PM -0700, Nick Lewycky wrote:
This testcase produces different output depending on whether -O1 or -O2 is
specified.
The testcase is wrong. Please produce a _minimal_ variant, it even shows
the same behaviour without bitfields.
Please explain what exactly the
Loosing kilos fast and safe. http://esf.thedrugsoutlet.eu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LAST_UPDATED: Sat Jul 5 16:51:46 UTC 2008 (revision 137509)
Target: mips-linux-gnu
gcc version 4.2.4 (Debian 4.2.4-3+b1)
Native configuration is mips-unknown-linux-gnu
=== libjava tests ===
Running target unix
FAIL: Invoke_1 execution - source compiled test
FAIL: Invoke_1
LAST_UPDATED: Sat Jul 5 16:51:46 UTC 2008 (revision 137509)
Target: sparc-linux-gnu
gcc version 4.2.4 (Debian 4.2.4-3+b1)
Native configuration is sparc-unknown-linux-gnu
=== libjava tests ===
Running target unix
=== libjava Summary ===
# of expected passes
LAST_UPDATED: Sat Jul 5 23:24:36 UTC 2008 (revision 137511)
Target: mips-linux-gnu
gcc version 4.3.1 (Debian 4.3.1-6+b1)
Native configuration is mips-unknown-linux-gnu
=== libjava tests ===
Running target unix
=== libjava Summary ===
# of expected passes
LAST_UPDATED: Sat Jul 5 23:24:36 UTC 2008 (revision 137511)
Target: sparc-linux-gnu
gcc version 4.3.1 (Debian 4.3.1-6+b1)
Native configuration is sparc-unknown-linux-gnu
=== libjava tests ===
Running target unix
=== libjava Summary for unix ===
# of expected
Processing commands for [EMAIL PROTECTED]:
close 491654
Bug#491654: gcc-4.3: _Bool isn't wide enough.
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Nick Lewycky [EMAIL PROTECTED]
thanks dude
Unknown command or malformed
close 491654
thanks dude
Hi Bastian,
The paragraph talks about how signed types need to map to unsigned
types, and then goes on to talk about _Bool and unsigned types. I
completely misread it as meaning that _Bool had to map to an unsigned
type. You're entirely correct here, sorry for the
14 matches
Mail list logo
