This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
- From: "tkoenig at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 19 Jan 2007 21:35:35 -0000
- Subject: [Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
- References: <bug-30389-13350@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-19 21:35 -------
In order to fix this, we should know what we would prefer :-)
Constant folding maps a lot of characters (all ASCII
characters > 127, and a lot of control characters) to zero.
In the rest of the library, we treat the A* functions identically
to the non-ASCII versions. For example, we encode
subroutine comp(a, b, t)
implicit none
logical t
character(*) a, b
t = lle(a,b)
end
as
comp (a, b, t, _a, _b)
{
bit_size_type D.994;
<unnamed type> D.995;
bit_size_type D.996;
<unnamed type> D.997;
D.994 = (bit_size_type) (<unnamed type>) _a * 8;
D.995 = (<unnamed type>) _a;
D.996 = (bit_size_type) (<unnamed type>) _b * 8;
D.997 = (<unnamed type>) _b;
*t = _gfortran_compare_string (_a, a, _b, b) <= 0;
}
We also encode
program main
integer i
character(1) c
i = 154
c = achar(i)
end
as
i = 154;
{
char char.0;
char.0 = (char) i;
c[1]{lb: 1 sz: 1} = char.0;
}
So, we could either
a) fix constant folding to ignore the ascii_table and xascii_table
b) fix the library and runtime conversion to honor the ascii_table.
a) is perfectly fine, as long as we document it. I'd vote for it.
Comments?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389