Re: C/C++ FEs: Do we really need three char_type_nodes?
On Sun, Sep 21, 2008 at 8:34 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Steven Bosscher wrote:
>
>> + if (signed_char)
>> +{
>> + char_type_node = make_signed_type (CHAR_TYPE_SISE);
>> + TYPE_CANONICAL (char_type_node) = signed_char_type_node;
>> +}
>
> I don't think this is a good idea. TYPE_CANONICAL is used for
> type-comparison at the language level, and "char" and "signed char" are
> different types -- even when "char" is signed.
>
> For example:
>
> char* q;
> signed char *p = q;
>
> is not valid without a cast.
char and signed char (if char is signed) are the same types for the
middle-end (but not for the Frontend). To "fix" this we basically
need to "gimplify" types - but this is obviously only possible if the
Frontend is truly finished. Another thing to consider is debug
information which is why I still advocate outputting debug information
for types and decls early (which basically means from the frontends).
Prerequesites for all this is of course that we gimplify unit-at-a-time so
the frontend is finished processing the TU and we can safely munge
its types and decls to whatever we like for the middle-end or LTO
(I believe the LTO branch already does this, so just fixup the char
types there).
Richard.
java: Add new rewite rule for VMCPStringBuilder.toString()
VMCPStringBuilder.toString() relies on backdoor access to a private
constructor for String. We can do this via a native method, but it's
easier and more efficient to add a compiler builtin. This one performs
the transformation:
gnu.java.lang.VMCPStringBuilder.toString(char[],int,int)
--> java.lang.String.toString(char[],int,int)
I've also had to add a new field to the rewrite rules, that of the
destination class, but unless I've made a mistake this won't make
any difference to the existing rules.
Andrew.
2008-09-22 Andrew Haley <[EMAIL PROTECTED]>
* expr.c (rules): Add new rule for
gnu.java.lang.VMCPStringBuilder.toString.
(rewrite_rule.new_classname): New field.
(maybe_rewrite_invocation): Use new_classname field instead of
DECL_CONTEXT (*method_p).
Allow rewrite_arglist to be NULL.
Index: gcc/java/expr.c
===
--- gcc/java/expr.c (revision 140485)
+++ gcc/java/expr.c (working copy)
@@ -2075,6 +2075,7 @@
const char *classname;
const char *method;
const char *signature;
+ const char *new_classname;
const char *new_signature;
int flags;
tree (*rewrite_arglist) (tree arglist);
@@ -2109,20 +2110,27 @@
static rewrite_rule rules[] =
{{"java.lang.Class", "getClassLoader", "()Ljava/lang/ClassLoader;",
-"(Ljava/lang/Class;)Ljava/lang/ClassLoader;",
+"java.lang.Class", "(Ljava/lang/Class;)Ljava/lang/ClassLoader;",
ACC_FINAL|ACC_PRIVATE, rewrite_arglist_getclass},
+
{"java.lang.Class", "forName", "(Ljava/lang/String;)Ljava/lang/Class;",
-"(Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Class;",
+"java.lang.Class",
"(Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Class;",
ACC_FINAL|ACC_PRIVATE|ACC_STATIC, rewrite_arglist_getclass},
+
{"gnu.classpath.VMStackWalker", "getCallingClass", "()Ljava/lang/Class;",
-"(Lgnu/gcj/RawData;)Ljava/lang/Class;",
+"gnu.classpath.VMStackWalker", "(Lgnu/gcj/RawData;)Ljava/lang/Class;",
ACC_FINAL|ACC_PRIVATE|ACC_STATIC, rewrite_arglist_getcaller},
+
{"gnu.classpath.VMStackWalker", "getCallingClassLoader",
"()Ljava/lang/ClassLoader;",
-"(Lgnu/gcj/RawData;)Ljava/lang/ClassLoader;",
+"gnu.classpath.VMStackWalker",
"(Lgnu/gcj/RawData;)Ljava/lang/ClassLoader;",
ACC_FINAL|ACC_PRIVATE|ACC_STATIC, rewrite_arglist_getcaller},
- {NULL, NULL, NULL, NULL, 0, NULL}};
+ {"gnu.java.lang.VMCPStringBuilder", "toString", "([CII)Ljava/lang/String;",
+"java.lang.String", "([CII)Ljava/lang/String;",
+ACC_FINAL|ACC_PRIVATE|ACC_STATIC, NULL},
+
+ {NULL, NULL, NULL, NULL, NULL, 0, NULL}};
/* True if this method is special, i.e. it's a private method that
should be exported from a DSO. */
@@ -2163,20 +2171,25 @@
if (get_identifier (p->method) == method
&& get_identifier (p->signature) == *method_signature_p)
{
- tree maybe_method
- = lookup_java_method (DECL_CONTEXT (*method_p),
+ tree maybe_method;
+ tree destination_class
+ = lookup_class (get_identifier (p->new_classname));
+ gcc_assert (destination_class);
+ maybe_method
+ = lookup_java_method (destination_class,
method,
get_identifier (p->new_signature));
if (! maybe_method && ! flag_verify_invocations)
{
maybe_method
- = add_method (DECL_CONTEXT (*method_p), p->flags,
+ = add_method (destination_class, p->flags,
method, get_identifier (p->new_signature));
DECL_EXTERNAL (maybe_method) = 1;
}
*method_p = maybe_method;
gcc_assert (*method_p);
- *arg_list_p = p->rewrite_arglist (*arg_list_p);
+ if (p->rewrite_arglist)
+ *arg_list_p = p->rewrite_arglist (*arg_list_p);
*method_signature_p = get_identifier (p->new_signature);
*special = integer_one_node;
FAIL: gcc.target/mips/octeon-exts-2.c scan-assembler-times
Hi David, David Daney writes: > gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1 > > Do you know if it is failing universally or only on non-octeon targets? It's failing on little-endian. There is also another test that's failing on 64-bit little-endian. I will submit a patch later. I was just waiting for the other Octeon patches to settle. Thanks for the note. Adam
More floating point problems on the Alpha
[Thanks to all those who responded to my previous problem-report
wrt to the IEEE inexact-flag on the Alpha. We have filed a bug
report for that one.]
Hi there,
we keep finding problems on the Alpha, and we are unsure about
what is going on. I anticipate that the present problem does
not seem to be a compiler issue (except that the -mieee-with-inexact
option promises full compliance with the IEEE floating point
standard). However, I hope some Alpha expert can advise about
how to investigate the issue further.
Here are the details:
$ cat bug.c
#include
float f = 1.4e-45;
double d = 1e-300;
int
main() {
if (1.4e-45f > 1e-300)
printf("compile-time test says 1.4e-45f > 1e-300\n");
if (f < d)
printf("run-time test says 1.4e-45f < 1e-300\n");
return 0;
}
$ gcc -mieee-with-inexact bug.c
$ ./a.out
compile-time test says 1.4e-45f > 1e-300
run-time test says 1.4e-45f < 1e-300
$ gcc -v
Using built-in specs.
Target: alpha-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --with-long-double-128
--enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
$ cat /proc/cpuinfo
cpu : Alpha
cpu model : EV56
cpu variation : 7
cpu revision: 0
cpu serial number :
system type : Rawhide
system variation: Tincup
system revision : 0
system serial number: AY74642662
cycle frequency [Hz]: 399642346 est.
timer frequency [Hz]: 1200.00
page size [bytes] : 8192
phys. address bits : 40
max. addr. space # : 127
BogoMIPS: 705.16
kernel unaligned acc: 0 (pc=0,va=0)
user unaligned acc : 35 (pc=2074c18,va=87)
platform string : AlphaServer 1200 5/400 4MB
cpus detected : 1
cpus active : 1
cpu active mask : 0001
L1 Icache : 8K, 1-way, 32b line
L1 Dcache : 8K, 1-way, 32b line
L2 cache: 96K, 3-way, 64b line
L3 cache: 4096K, 1-way, 64b line
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: Pmode != INT (e.g., SImode)
Michael Eager <[EMAIL PROTECTED]> writes: > Are there any architectures which have Pmode != INT? m32c has Pmode == PSImode, at least with -mcpu=m32c. The r8c/m16c variants have Pmode == HImode == int. > I'm running into a number of problems. Yup! GCC doesn't like ports where sizeof(pointer) != sizeof(some int type). It likes 24 bit registers even less :-P
Re: [PPL-devel] More floating point problems on the Alpha
Roberto Bagnara ha scritto:
> [Thanks to all those who responded to my previous problem-report
> wrt to the IEEE inexact-flag on the Alpha. We have filed a bug
> report for that one.]
>
> Hi there,
>
> we keep finding problems on the Alpha, and we are unsure about
> what is going on. I anticipate that the present problem does
> not seem to be a compiler issue (except that the -mieee-with-inexact
> option promises full compliance with the IEEE floating point
> standard). However, I hope some Alpha expert can advise about
> how to investigate the issue further.
>
> Here are the details:
>
> $ cat bug.c
> #include
>
> float f = 1.4e-45;
> double d = 1e-300;
>
> int
> main() {
>if (1.4e-45f > 1e-300)
> printf("compile-time test says 1.4e-45f > 1e-300\n");
>if (f < d)
> printf("run-time test says 1.4e-45f < 1e-300\n");
>return 0;
> }
>
The problem come from the fact that for astonishing reasons 1.4e-45f is
not seen as 1.4e-45.
So, adding
printf("%g\n", f);
before
return 0;
we get
$ ./a.out
compile-time test says 1.4e-45f > 1e-300
run-time test says 1.4e-45f < 1e-300
2.65249e-315
Note that 2.65249e-315 is not representable in ieee754/iec559 32 bit
floating point.
32 bit floats are emulated on Alpha? There is an huge bug in FP emulation?
--
Abramo Bagnara
Opera Unica Phone: +39.0546.656023
Via Borghesi, 16
48014 Castel Bolognese (RA) - Italy
Re: [PPL-devel] More floating point problems on the Alpha
On Mon, Sep 22, 2008 at 09:56:30PM +0200, Abramo Bagnara wrote: > The problem come from the fact that for astonishing reasons 1.4e-45f is > not seen as 1.4e-45. Why is this astonishing? The smallest positive single-precision IEEE floating point number is roughly 1.175494e-38. Since user-specified numbers are rounded to the closest representable value, 1.4e-45f is a fancy way of typing zero. Double-precision values have much greater dynamic range; DBL_MIN is roughly 2.225074e-308.
Re: m32c: pointer math vs sizetype again
> Does the following fix it? Nope, sorry. I was looking at this code in c-common.c, where the expr is first created, but I don't know what that ends up calling: /* Create the sum or difference. */ if (resultcode == MINUS_EXPR) intop = fold_build1 (NEGATE_EXPR, sizetype, intop); ret = fold_build2 (POINTER_PLUS_EXPR, result_type, ptrop, intop); It's calling NEGATE on an unsigned type, which seems wrong to me.
Re: [PPL-devel] More floating point problems on the Alpha
On Mon, 22 Sep 2008, Joe Buck wrote: > On Mon, Sep 22, 2008 at 09:56:30PM +0200, Abramo Bagnara wrote: > > The problem come from the fact that for astonishing reasons 1.4e-45f is > > not seen as 1.4e-45. > > Why is this astonishing? The smallest positive single-precision IEEE > floating point number is roughly 1.175494e-38. Since user-specified > numbers are rounded to the closest representable value, 1.4e-45f is > a fancy way of typing zero. The smallest subnormal value is approximately 1.40129846e-45F (__FLT_DENORM_MIN__). The obvious conclusion is that subnormal support is broken or disabled on Alpha by default. -- Joseph S. Myers [EMAIL PROTECTED]
Re: C/C++ FEs: Do we really need three char_type_nodes?
Richard Guenther wrote: > char and signed char (if char is signed) are the same types for the > middle-end (but not for the Frontend). Is that desirable? Type-based alias analysis should be able to take advantage of the difference between them; a "char **" and a "signed char **" cannot point at the same thing, for example. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [PPL-devel] More floating point problems on the Alpha
On Mon, Sep 22, 2008 at 09:41:05PM +, Joseph S. Myers wrote: > On Mon, 22 Sep 2008, Joe Buck wrote: > > > On Mon, Sep 22, 2008 at 09:56:30PM +0200, Abramo Bagnara wrote: > > > The problem come from the fact that for astonishing reasons 1.4e-45f is > > > not seen as 1.4e-45. > > > > Why is this astonishing? The smallest positive single-precision IEEE > > floating point number is roughly 1.175494e-38. Since user-specified > > numbers are rounded to the closest representable value, 1.4e-45f is > > a fancy way of typing zero. > > The smallest subnormal value is approximately 1.40129846e-45F > (__FLT_DENORM_MIN__). The obvious conclusion is that subnormal support is > broken or disabled on Alpha by default. OK. I apologize for the noise.
Re: C/C++ FEs: Do we really need three char_type_nodes?
On Mon, Sep 22, 2008 at 8:48 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > >> char and signed char (if char is signed) are the same types for the >> middle-end (but not for the Frontend). > > Is that desirable? Type-based alias analysis should be able to take > advantage of the difference between them; a "char **" and a "signed char > **" cannot point at the same thing, for example. > Should, but currently can't. They will both have alias set 0, last time I checked (about 2 months ago). I imagine if we started actually enforcing strict aliasing between signed char * and char * we'd break even more code and have even more complaints. It's also going to be rare that this is a useful aliasing relationship to disambiguate between.
RFA: emitting .rodata before .text
In trying to make gcc for VAX pass test suites, one of the problems is gcc.c-torture/compile/pr34029-2.c in that the function foo is emitted before .rodata. This mean s & t are undefined and vax--netbsdelf-as doesn't like that. Moving .rodata before .text solves this but I can't see how to force that behavior. Any ideas other than fixing gas to deal with this?
Re: m32c: pointer math vs sizetype again
DJ Delorie <[EMAIL PROTECTED]> writes: >> Does the following fix it? > > Nope, sorry. I was looking at this code in c-common.c, where the expr > is first created, but I don't know what that ends up calling: > > /* Create the sum or difference. */ > if (resultcode == MINUS_EXPR) > intop = fold_build1 (NEGATE_EXPR, sizetype, intop); > > ret = fold_build2 (POINTER_PLUS_EXPR, result_type, ptrop, intop); > > It's calling NEGATE on an unsigned type, which seems wrong to me. NEGATE_EXPR on an unsigned type is fully defined. It's what you should get when you say "unsigned int i, j; ...; i = - j;". I think the problem you are facing may be that POINTER_PLUS_EXPR generally assumes that the right type to use to add to a pointer is sizetype. You may need to make it use a different type, though I'm not sure what that type should be in your case. Ian
Re: C/C++ FEs: Do we really need three char_type_nodes?
On Tue, Sep 23, 2008 at 1:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 8:48 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Richard Guenther wrote: >> >>> char and signed char (if char is signed) are the same types for the >>> middle-end (but not for the Frontend). >> >> Is that desirable? Type-based alias analysis should be able to take >> advantage of the difference between them; a "char **" and a "signed char >> **" cannot point at the same thing, for example. >> > > Should, but currently can't. > They will both have alias set 0, last time I checked (about 2 months ago). > I imagine if we started actually enforcing strict aliasing between > signed char * and char * we'd break even more code and have even more > complaints. > It's also going to be rare that this is a useful aliasing relationship > to disambiguate between. Also note that even if char and signed char are the same to the middle-end (you can convert between them without a conversion) pointers to them need not be the same if they have different alias sets. But I agree with Danny here. Richard.
