UNITS vs. BYTES

[Adrian Prantl]

Hello everybody,

I am currently working on creating a new gcc backend for a word-addressable
machine with 24-Bit general purpose registers.
While doing so I came across a few inconsistencies regarding the usage of the
BITS_PER_UNIT Macro. (and UNITS_PER_WORD, in a related story)

Apparently a lot of places in the gcc sources use the concept of a UNIT
where they actually mean an 8-Bit Byte and vice versa. (often in the form
of bytelen*BITS_PER_UNITS in order to calculate some size in BITS)

generic example from genmodes.c:

>static void
>emit_mode_precision (void)
>{
>  int c;
>  struct mode_data *m;
>
>  print_decl ("unsigned short", "mode_precision", "NUM_MACHINE_MODES");
>
>  for_all_modes (c, m)
>if (m->precision != (unsigned int)-1)
>  tagged_printf ("%u", m->precision, m->name);
>else
>  tagged_printf ("%u*BITS_PER_UNIT", m->bytesize, m->name);
> 
>  print_closer ();
>}

So my question is, what is the best thing for me to do? If I simply replace
those instances with constant 8 it generates the correct code, but that does
not seem like a clean solution to me.
Another question is whether there is actually a need to carry around the two
concepts of BYTES and UNITS anyway. It seems that for most backends those
are of the same size anyway, and for the other backends it would be much
easier if there were only UNITS.

thanks a lot,
Adrian

Re: UNITS vs. BYTES

[Hans-Peter Nilsson]

On Fri, 11 Nov 2005, Adrian Prantl wrote:
> Hello everybody,
>
> I am currently working on creating a new gcc backend for a word-addressable
> machine with 24-Bit general purpose registers.

If the smallest unit you can address, the one between
address N and N+1, is a "word" then the unit must be a "word".
(You don't say the size of this "word" but from the context it
seems the size of your registers, 24 bits.)

Then you have to adjust (generalize) the gcc sources which has
bitrotted slightly to assume a unit is an 8-bit-byte, i.e.
likely the inconsistency you see.

It'd be best if/when you submit your GCC port to include newlib,
simulator and binutils ports (so everyone can regression-test
without hardware using only FSF sources) to reduce the risk of
future GCC bitrot in this area.

Thanks.

brgds, H-P

Re: UNITS vs. BYTES

[Paolo Bonzini]

Adrian Prantl wrote:

Hello everybody,

I am currently working on creating a new gcc backend for a word-addressable
machine with 24-Bit general purpose registers.
While doing so I came across a few inconsistencies regarding the usage of the
BITS_PER_UNIT Macro. (and UNITS_PER_WORD, in a related story)

Apparently a lot of places in the gcc sources use the concept of a UNIT
where they actually mean an 8-Bit Byte and vice versa. (often in the form
of bytelen*BITS_PER_UNITS in order to calculate some size in BITS)


Old alphas are word-addressable, but still they had BITS_PER_UNIT == 8.

Or you may want to look at the c4x back-end, which has

/* Note the ANSI C standard requires sizeof(char) = 1.  On the C[34]x
   all integral and floating point data types are stored in memory as
   32-bits (floating point types can be stored as 40-bits in the
   extended precision registers), so sizeof(char) = sizeof(short) =
   sizeof(int) = sizeof(long) = sizeof(float) = sizeof(double) = 1.  */

#define BITS_PER_UNIT   32
#define UNITS_PER_WORD  1

Paolo

[gfortran] Second try: Problem parsing hexadecimal constants?

[Ioannis E. Venetis]

I sent this message about a week ago, but didn't get any response. So, I 
try again. My question is whether this is a bug of gfortran and if I 
should open a bug report about it. I haven't found this in Bugzilla.


Thank you!



Dear all,

Firstly, let me say that I don't know that much about Fortran, but I use 
a source-code transformation tool that creates Fortran 77 code, which I 
feed to gfortran.


During this last stage, gfortran seems to have some problems to parse 
hexadecimal constants. I managed to reduce the problem to this very 
simple code:


TEST.f:

PROGRAM HEX_TEST

INTEGER(4) MASK

MASK = 'c0'X

END

~ $ gfortran -c TEST.f
 In file TEST.f:5


  MASK = 'c0'X
 1
Error: Unclassifiable statement at (1)



If, however, I make the following change:

MASK = X'c0'

the program compiles correctly. I remember that I used this tool with 
g77 too and that I had no problem. Either form of a hexadecimal constant 
was accepted. The same holds for the Intel compiler.


Is this a bug of gfortran or some kind of extension that is not supported?

~ $ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure 
--prefix=/home/iev/apps/gcc-4.0.2 --enable-languages=c,c++,f95 
--enable-shared --enable-threads=posix --disable-checking 
--with-system-zlib --enable-__cxa_atexit --disable-libgcj --disable-nls

Thread model: posix
gcc version 4.0.2

Best regards,

Ioannis

CSiBE compile time improvement

[Steven Bosscher]

Hi,

Something fixed something:
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux

Obviously there's no reason to complain.  But does anyone know where
this came from?

Gr.
Steven

Re: CSiBE compile time improvement

[Andrew Pinski]

> 
> Hi,
> 
> Something fixed something:
> http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux
> 
> Obviously there's no reason to complain.  But does anyone know where
> this came from?

Actually only i686-linux is different.  All the rest of the targets are still 
high.

-- Pinski

Re: UNITS vs. BYTES

[Ian Lance Taylor]

Adrian Prantl <[EMAIL PROTECTED]> writes:

> Another question is whether there is actually a need to carry around the two
> concepts of BYTES and UNITS anyway. It seems that for most backends those
> are of the same size anyway, and for the other backends it would be much
> easier if there were only UNITS.

That is a real question, one which is hard to answer because there are
so few machines with BITS_PER_UNIT != 8.  Another way to put the
question is: what is the size of QImode?  At the moment, QImode is the
mode with the size of a unit.  That is, if BITS_PER_UNIT is 16, then
QImode is 16 bits.  I developed a backend with BITS_PER_UNIT == 16 and
INT_TYPE_SIZE == 16, which then means that the basic operations are
addqi3, mulqihi3, etc.  It all works fine, but it looks odd to
experienced gcc developers.

In other words, in practice the way to make everything work is to
assume that BYTES and UNITS are the same size.  So then why do we ever
use the term 'byte'?

The alternative is to carefully distinguish them.  That implies making
QImode always be 8 bits, and using the now-standard definition of
'byte' as an 8-bit value (in my youth, the size of a 'byte' varied
from machine to machine).

I don't know what the best approach is, but I do know that it will
only be answered if there is a fully supported contributed backend for
a word-addressable machine.

Ian

Using Alias analysis

[drizzle drizzle]

Hi .
   I want to use gcc's alias analysis in a standalone way. What I
observe is that a lot of the information is hidden because of
additional temporaries that have been generated. Can any one suggest
as to if there is a simple workaround to this ?

 To illustrate what I am saying

 for a stmt
 heap_ptr= (int**) malloc the alias analysis tells me D.1072 points to
malloc and heap_ptr points to anything.  I would have liked to see
heap_ptr points to malloc.


 Any way I can get that information.
 I would appreciate any idea/suggestions ...
 dz

strange result when compiling w/ -fpreprocessed but w/out -fdumpbase

[Joern RENNECKE]

When you compile a file that contains a line directive, e.g.:

# 1 "../../libgcc2.c"
int f ()
{
 return 0;
}

using the -fpreprocessed option to cc1, but without -fdumpbase, the base 
filename of the
line number directive us used both for the assembly output file and for 
debugging dumps
from -da.  This can be rather confusing when you can't find neither 
output file nor debugging
dumps in the current directory.  And at the least, the -fpreprocessed 
documentation is wrong
when it states that this option is implicit when the file ends in .i; 
this effect of -fpreprocesed

only appears when the option is actually passed to cc1.

Re: Using Alias analysis

[Daniel Berlin]

On Fri, 2005-11-11 at 19:33 +, drizzle drizzle wrote:
> Hi .
>I want to use gcc's alias analysis in a standalone way. What I
> observe is that a lot of the information is hidden because of
> additional temporaries that have been generated. Can any one suggest
> as to if there is a simple workaround to this ?
> 
>  To illustrate what I am saying
> 
>  for a stmt
>  heap_ptr= (int**) malloc the alias analysis tells me D.1072 points to
> malloc and heap_ptr points to anything

You shouldn't see this, and in fact, i don't.

#include 
int
main ()
{

int **fooptr;
fooptr = (int **)malloc (sizeof (int *));
  return 0;
}

gives

main ()
{
  intD.0 * * fooptrD.1403;
  intD.0 D.1405;
  voidD.28 * D.1404;

  # BLOCK 0
  # PRED: ENTRY (fallthru)
  #   HEAP.5D.1417_6 = V_MAY_DEF ;
  D.1404_1 = malloc (4);
  fooptrD.1403_2 = (intD.0 * *) D.1404_1;
  D.1405_3 = 0;
  return D.1405_3;
  # SUCC: EXIT

}

D.1404_1 = { HEAP.5 }
HEAP.5 = { ANYTHING }
fooptr_2 = { HEAP.5 }


IE we say that fooptr_2 points to HEAP.




> .  I would have liked to see
> heap_ptr points to malloc.
> 

Uh, 
> 
>  Any way I can get that information.
>  I would appreciate any idea/suggestions ...
>  dz

Re: non-ambiguous typedefs

[Mark Mitchell]

Gabriel Dos Reis wrote:

> Plain compiler bug.  I'm not aware of any existing report to that
> effect, though GCC/g++ currently is completely confused when it sees
> apparently ambiguous declarations, and would report non-existent
> declaration.  That needs fixing.

I have a patch-in-progress for the fact that ambiguous declarations are
reported as non-existant.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: [gfortran] Second try: Problem parsing hexadecimal constants?

[Mike Stump]

On Nov 11, 2005, at 8:18 AM, Ioannis E. Venetis wrote:
I sent this message about a week ago, but didn't get any response.  
So, I try again.


Please don't.  Imagine this list is about 100x more costly than  
filing a bug report, even if the bug report is wrong.


If you want to discuss what a valid fortran or not, try  
comp.lang.fortran or some other forum.  In fact, all the gcc folks  
that do fortran hang out on a completely different list than this  
list, so you're not even close to being on the right list.

Re: i686-pc-cygwin crash gcc-4.0 branch

[Bobby McNulty]

Brian Dessent wrote:

Brian Dessent wrote:



/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/i
nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H
-I. -I../.
./../../gcc-4_0-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c
../../../../gcc-4
_0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o
In file included from
../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c:
32:
../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error:
conflicti
ng types for 'ieee_double_shape_type'


It looks like what is happening is BYTE_ORDER isn't getting defined
correctly.  This is supposed to be taken care of by the sys/param.h
header of the target, which Cygwin does provide correctly.  It looks
like for some reason gcc isn't picking this up in your case.  Are you
doing a native or a cross?  What configure options are you using?



This is caused by this change:
. 
This modified include/endian.h to only conditionally define BYTE_ORDER

etc. if __USE_BSD is defined, whereas before in newlib's
machine/endian.h

they were defined unconditionally.

Thus if you build gcc with the 1.5.18 version of cygwin and its headers
you don't run into this, but if you try to use a snapshot that contains
this change you get the above error.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




I nuked my cygwin, and started over again.
Used svn to get the trunk of gcc.
I have a snapshot gcc 4.0, but I am not building it.
Anyway, compiling just with the 1.5.18 cygwin dll solved.
Since this is just staying on the cutting edge of programming, I am only 
going to use release cygwin1.dll.

Waiting for cygwin 1.5.19
Bobby.
It worked. trunk is able to compile again in Cygwin.

darwin building ppc64 libjava?

[Mike Stump]

Anyone else seeing:

ld64 failed: bl out of range (57687405 max is +/-16M) from  
___ieee754_pow in .libs/libgcj.lax/libfdlibm.a/e_pow.o to _L4  
in .libs/libgcj.7.0.0.dylib

/usr/bin/libtool: internal link edit command failed
make[5]: *** [libgcj.la] Error 1
make[5]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
apple-darwin8.2.0/ppc64/libjava'

make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
apple-darwin8.2.0/ppc64/libjava'

make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
apple-darwin8.2.0/libjava'

make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
apple-darwin8.2.0/libjava'

make[1]: *** [all-target-libjava] Error 2

?

mrs $ find . -name \*.o | xargs nm -m | grep _L4
 (undefined) external _L4
 (undefined) external _L4
 (undefined) external _L4
 (undefined) external _L4

Re: darwin building ppc64 libjava?

[Andrew Pinski]

> 
> Anyone else seeing:
> 
> ld64 failed: bl out of range (57687405 max is +/-16M) from  
> ___ieee754_pow in .libs/libgcj.lax/libfdlibm.a/e_pow.o to _L4  
> in .libs/libgcj.7.0.0.dylib
> /usr/bin/libtool: internal link edit command failed
> make[5]: *** [libgcj.la] Error 1
> make[5]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
> apple-darwin8.2.0/ppc64/libjava'
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
> apple-darwin8.2.0/ppc64/libjava'
> make[3]: *** [multi-do] Error 1
> make[3]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
> apple-darwin8.2.0/libjava'
> make[2]: *** [all-multi] Error 2
> make[2]: Leaving directory `/Volumes/mrs3/net/gcc-darwin/powerpc- 
> apple-darwin8.2.0/libjava'
> make[1]: *** [all-target-libjava] Error 2
> 
> ?
> 
> mrs $ find . -name \*.o | xargs nm -m | grep _L4
>   (undefined) external _L4
>   (undefined) external _L4
>   (undefined) external _L4
>   (undefined) external _L4

I thought this was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00735.html

If it is not please file a bug plus the preprocessed source
for e_pow.i as it is just a C file.

Thanks,
Andrew Pinski

Re: i686-pc-cygwin crash gcc-4.0 branch

[Brian Dessent]

Bobby McNulty wrote:

> Since this is just staying on the cutting edge of programming, I am only
> going to use release cygwin1.dll.
> Waiting for cygwin 1.5.19

FYI, http://cygwin.com/ml/cygwin-cvs/2005-q4/msg00072.html

Re: darwin building ppc64 libjava?

[Mike Stump]

On Nov 11, 2005, at 4:15 PM, Andrew Pinski wrote:

I thought this was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00735.html


Thanks, I'm sure it was...  (updating and rebuilding now)

Re: [RFC] PR C++/24138

[Mark Mitchell]

Aldy Hernandez wrote:

> (Frustratingly, max_index above yields false on integer_all_onesp(), but
> we can tackle that once we can agree what to do here.)
> 
> Is it ok to special case max_index being -1?

Definitely.

This problem appears in various places; we represent array bounds using
a number of the same precision as the set of valid indices, so edge-case
representations require a little special handling.  (Of course, that
whole function is busted if we get an array of a size that can't be
represented in a HOST_WIDE_INT, but that's not your problem...)

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Null pointer check elimination

[David Daney]

Thanks Anthony.  This has been bothering me for quite some time.

Anthony Green wrote:

Our compiler inlines many null pointer tests because the language
requires that we throw NullPointerExeceptions in certain cases that can
only be detected through explicit tests.

What's frustrating is that there are many cases where we're testing the
nullness of a function return value that we know can never be null.  For
instance, the result of string appends can never be null.  Neither can
object allocations.


See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24242



The attached experimental patch detects one special instance of a
non-null function result (gnu.gcj.runtime.StringBuffer.append()), and
marks it as being non-null.  GCC's value range propagation code then
magically eliminates any redundant null pointer checks.


I think all methods returning a reference in 
gnu.gcj.runtime.StringBuffer, java.lang.StringBuffer, 
java.lang.StringBuilder fall into this category.




Eventually we should manually mark certain function DECLs as
not-returning-null instead of my kludgy test for this one case.  I don't
know if/when I can get to that.  Perhaps somebody else can take it from
here.


Looks like all the bits in struct tree_common are used up.

Q: Would it make sense to add a flag to struct tree_decl_common to 
indicate !zero, set it using an attribute, (and automatically in  the 
java front-end for the cases above), and then test for it in tree-vrp.c 
similar to below?




In any case, here's a patch Diego and I came up with.  It will eliminate
null-pointer checks related to the string concatenation operator (foo =
"blah" + bar).

(Thanks Diego!)

AG






Index: tree-vrp.c
===
--- tree-vrp.c  (revision 106799)
+++ tree-vrp.c  (working copy)
@@ -2216,6 +2216,42 @@ infer_value_range (tree stmt, tree op, e
   if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (op))
 return false;
 
+  /* Is this a function call that is guaranteed not to

+ return null?  */
+  if (TREE_CODE (stmt) == MODIFY_EXPR
+  && op == TREE_OPERAND (stmt, 0)
+  && TREE_CODE (TREE_TYPE (stmt)) == POINTER_TYPE
+  && TREE_CODE (TREE_OPERAND (stmt, 1)) == CALL_EXPR)
+{
+  /* Ok, we know we have an assignment from a function
+call returning a pointer.  Now - for testing purposes
+- I'm just going to hard-code a test for a specific
+java method known not to return null. */
+  
+  tree node = TREE_TYPE (TREE_TYPE (stmt));

+  if (TREE_CODE (node) == RECORD_TYPE
+ && TYPE_NAME (node)
+ && TREE_CODE (TYPE_NAME (node)) == TYPE_DECL
+ && DECL_NAME (TYPE_NAME (node))
+ && strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (node))),
+"gnu.gcj.runtime.StringBuffer") == 0)
+   {
+	  tree function = 
+	TREE_OPERAND (TREE_OPERAND (TREE_OPERAND (stmt, 1), 0), 0);
+	  
+	  if (TREE_CODE (function) == FUNCTION_DECL

+ && DECL_NAME (function)
+ && strcmp (IDENTIFIER_POINTER (DECL_NAME (function)),
+"append") == 0)
+   {
+ puts ("WOOHOO!");
+ *val_p = build_int_cst (TREE_TYPE (op), 0);
+ *comp_code_p = NE_EXPR;
+ return true;
+   }
+   }
+}
+  
   /* Similarly, don't infer anything from statements that may throw

  exceptions.  */
   if (tree_could_throw_p (stmt))
@@ -2734,6 +2770,28 @@ find_assert_locations (basic_block bb)
}
}
 
+  /* Some assignments may compute values that guarantee certain

+known ranges to their LHS.  */
+  FOR_EACH_SSA_TREE_OPERAND (op, stmt, i, SSA_OP_DEF)
+   {
+ tree value;
+ enum tree_code comp_code;
+
+ /* If OP is used only once, namely in this STMT, don't
+bother creating an ASSERT_EXPR for it.  */
+ if (has_single_use (op))
+   continue;
+
+ /* If OP is used in such a way that we can infer a value
+range for it, and we don't find a previous assertion for
+it, create a new assertion location node for OP.  */
+ if (infer_value_range (stmt, op, &comp_code, &value))
+   {
+ register_new_assert_for (op, comp_code, value, bb, NULL, si);
+ need_assert = true;
+   }
+   }
+
   /* Remember the last statement of the block.  */
   last = stmt;
 }

Re: Null pointer check elimination

[Ian Lance Taylor]

David Daney <[EMAIL PROTECTED]> writes:

> > Eventually we should manually mark certain function DECLs as
> > not-returning-null instead of my kludgy test for this one case.  I don't
> > know if/when I can get to that.  Perhaps somebody else can take it from
> > here.
> 
> Looks like all the bits in struct tree_common are used up.
> 
> Q: Would it make sense to add a flag to struct tree_decl_common to
> indicate !zero, set it using an attribute, (and automatically in  the
> java front-end for the cases above), and then test for it in
> tree-vrp.c similar to below?

This should be done using an attribute, yes.  If this is going to be
tested frequently enough, it would make sense to add a bit to struct
tree_function_decl (I don't see any reason to put it in struct
tree_decl-common) (there is currently room for one more bit in
tree_function_decl on a machine which requires 16-bit alignment, or 17
more bits on a machine which requires 32-bit alignment).  Note that it
is also possible to simply store the attribute on DECL_ATTRIBUTES and
look it up using lookup_attribute.

Ian