This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ada/21573] 'Valid attribute on enumeration types with holes
- From: "fw at deneb dot enyo dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 May 2005 19:35:32 -0000
- Subject: [Bug ada/21573] 'Valid attribute on enumeration types with holes
- References: <20050514190612.21573.fw@deneb.enyo.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From fw at deneb dot enyo dot de 2005-05-14 19:35 -------
Subject: Re: 'Valid attribute on enumeration types with holes
* pinskia at gcc dot gnu dot org:
> ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 19:09 -------
> It works for me on powerpc-darwin with "4.0.0 20050222".
I've looked at the trees generated by the following three-file test
case (in particular the tree dumps for bug2_p.adb), and they look
fine. Maybe it's an i386 back end issue.
-- Run through gnatchop
with Ada.Unchecked_Conversion;
with Ada.Text_IO; use Ada.Text_IO;
with Bug2_P; use Bug2_P;
procedure Bug2 is
function Convert is new Ada.Unchecked_Conversion (N, T);
begin
if V (Convert (0)) then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Bug2;
package Bug2_P is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
type N is mod 2**8;
function V (X : T) return Boolean;
end Bug2_P;
package body Bug2_P is
function V (X : T) return Boolean is
begin
return X'Valid;
end V;
end Bug2_P;
-- End
The i386 assembly code looks like this:
.type bug2_p__tRP, @function
bug2_p__tRP:
.LFB4:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
movb 8(%ebp), %al
movb 12(%ebp), %dl
cmpb $3, %al
je .L4
jb .L3
cmpb $5, %al
je .L5
cmpb $7, %al
je .L13
testb %dl, %dl
jne .L8
movl $-1, %eax
leave
ret
.p2align 4,,15
.L3:
xorl %eax, %eax
leave
ret
[...]
I'm not very good at reading AT&T syntax, but it appears that for a
first argument of 0, the branch to .L3 is taken, which returns 0
(instead of the expected -1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573