Stack based / zero operand CPU - ZPU

[Øyvind Harboe]

Hi all,

I've implemented a stack based or zero operand CPU, including GCC/gdb toolchain,
eCos operating system support, simulator, HDL implementation, etc.

I'm boldly assuming that a fair number of people on this list might
find this a little
bit fascinating.

It's all open source of course:
http://www.opencores.org/projects.cgi/web/zpu/overview

- the ZPU has 11 instructions, the rest is implemented using microcode(yields
small CPU + small code size).
- the only registers are SP and PC
- 16 or 32 bit datapath
- GCC is very much oriented towards all sorts of register based CPU's. I settled
on exposing stack slots as CPU registers + some other tricks. GCC generates
very decent code(80% of codesize to ARM thumb).
- Cygwin binaries + GCC source code available(of course)
- ++


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

Re: jc1 out of memory error gcc 4.2.2 Linux 64-bit OS

[Andrew Haley]

Harpal Grover writes:
 > Hello all,
 > 
 > I downloaded and built gcc 4.2.2 on my linux box. I have also used the
 > sources to build a cross compiler using Ranjit's Matthews guide.  The
 > build went just fine. I tried to compile my java application and got
 > the following error:
 > 
 > c1: out of memory allocating 4064 bytes after a total of 3909824512 bytes
 > 
 > The specs on my laptop are as follows:
 > Intel Core 2 Duo
 > Suse 10.2 64-bit
 > Linux 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64
 > x86_64 x86_64 GNU/Linux
 > 4 GB Ram
 > 
 > jc1 spiked from 1 gig of memory to close to 4gb, eats up the swap and
 > then finally crashes. Is there any additional information you guys
 > would like me to provide? If so please feel free to let me know and I
 > gladly will.

I want to know what you were trying to compile.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Paolo Bonzini]

Ismail Dönmez wrote:

Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:

Ismail Dönmez <[EMAIL PROTECTED]> writes:

That was just an example, real life testcase shows that problem stems
from autoconf and its config.h. Projects end up defining things like
HAVE_STDLIB_H twice which is not harmful at all but now causes an error
if g++ is used.

Redefinitions with the same replacement list are not an error.


Ok but that still doesn't cover the general use of

#define PACKAGE_NAME foobar


We had to fix it ourselves for libffi as part of switching to autoconf 
2.50+.  The point is that installing config.h headers is broken by 
design -- and this is not something that the GCC community states.  See 
for example


http://www.cygwin.com/ml/automake/2000-10/msg00116.html

"Unfortunately, people are being lulled into a false sense of security,
because installing config.h appears to work while it is an uncommon
practice.  Things will go downhill fast if this becomes common
practice -- imagine the chaos that we would have if gtk.h indirectly
#included a raw (i.e. with rewriting prior to installation) config.h,
which set up a whole bunch of HAVE_foo macros and VERSION's that you
don't want to cope with when you use libgtk.  Even worse what if the
gnome headers installed another conig.h with overlapping and
contradicting macros"

which warned about this already 8 years ago.  Sweet.

Why not fixing the handful of packages with a /^#define PACKAGE/d, 
instead of adding -fpermissive to the 50 users of those broken packages?

Paolo

RE: How to stop gcc from not calling noinline functions

[Dave Korn]

On 14 January 2008 11:03, Hans-Peter Nilsson wrote:

>> Date: Sat, 12 Jan 2008 11:16:23 +0100
>> From: Paolo Bonzini <[EMAIL PROTECTED]>
> 
>>> (Yeah, new attributes "impure" and/or "nonconst" would solve
>>> this, but only for IPA and there's already the existing option
>>> and asm I mentioned.  And if you say different files/compilation
>>> units, I say LTO.)
>> 
>> I think the asm is your best bet.
> 
> I prefer not to bet at all. ;)
> 
> Let's make this:
>  asm ("");
> (asms without input and output operands are volatile, and we're
> also leaving the text empty) in the called function the
> promised, documented way to stop interfunction analysis (like
> currently const/pure) making calls "as it used to be".  Not all
> targets support "weak", and overloading a standard qualifier
> like "volatile" or "extern" seems on second thought too brittle.
> 
> brgds, H-P

  If you wanted to stick to standard C, you could surely force it with a call
through function pointer, perhaps?  (You might need to make it volatile to
fool IPA.)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

> Date: Sat, 12 Jan 2008 11:16:23 +0100
> From: Paolo Bonzini <[EMAIL PROTECTED]>

> > (Yeah, new attributes "impure" and/or "nonconst" would solve
> > this, but only for IPA and there's already the existing option
> > and asm I mentioned.  And if you say different files/compilation
> > units, I say LTO.)
> 
> I think the asm is your best bet.

I prefer not to bet at all. ;)

Let's make this:
 asm ("");
(asms without input and output operands are volatile, and we're
also leaving the text empty) in the called function the
promised, documented way to stop interfunction analysis (like
currently const/pure) making calls "as it used to be".  Not all
targets support "weak", and overloading a standard qualifier
like "volatile" or "extern" seems on second thought too brittle.

brgds, H-P

Re: How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

> From: "Dave Korn" <[EMAIL PROTECTED]>
> Date: Mon, 14 Jan 2008 11:26:33 -

>   If you wanted to stick to standard C, you could surely force it with a call
> through function pointer, perhaps?  (You might need to make it volatile to
> fool IPA.)

No.  No tricks in the calling function.  To reiterate my main
use: test-cases.  Changing from a direct function call in the
original code to indirect is too much a difference, not to say a
(pointer to) volatile.

brgds, H-P

Re: How to stop gcc from not calling noinline functions

[Jan Hubicka]

> On 14 January 2008 11:03, Hans-Peter Nilsson wrote:
> 
> >> Date: Sat, 12 Jan 2008 11:16:23 +0100
> >> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > 
> >>> (Yeah, new attributes "impure" and/or "nonconst" would solve
> >>> this, but only for IPA and there's already the existing option
> >>> and asm I mentioned.  And if you say different files/compilation
> >>> units, I say LTO.)
> >> 
> >> I think the asm is your best bet.
> > 
> > I prefer not to bet at all. ;)
> > 
> > Let's make this:
> >  asm ("");
> > (asms without input and output operands are volatile, and we're
> > also leaving the text empty) in the called function the
> > promised, documented way to stop interfunction analysis (like
> > currently const/pure) making calls "as it used to be".  Not all
> > targets support "weak", and overloading a standard qualifier
> > like "volatile" or "extern" seems on second thought too brittle.
> > 
> > brgds, H-P
> 
>   If you wanted to stick to standard C, you could surely force it with a call
> through function pointer, perhaps?  (You might need to make it volatile to
> fool IPA.)

My preferred variant would be probably simple increment of global
variable...

Honza
> 
> 
> cheers,
>   DaveK
> -- 
> Can't think of a witty .sigline today

RE: How to stop gcc from not calling noinline functions

[Dave Korn]

On 14 January 2008 11:43, Hans-Peter Nilsson wrote:

>> From: "Dave Korn" <[EMAIL PROTECTED]>
>> Date: Mon, 14 Jan 2008 11:26:33 -
> 
>>   If you wanted to stick to standard C, you could surely force it with a
>> call through function pointer, perhaps?  (You might need to make it
>> volatile to fool IPA.)
> 
> No.  No tricks in the calling function.  To reiterate my main
> use: test-cases.  Changing from a direct function call in the
> original code to indirect is too much a difference, not to say a
> (pointer to) volatile.

  Oops, yes it is, I just re-read your original post; it's the caller, and the
call itself you care about, not what's in the (inlined-or-not) callee.
Apologies.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

[Richard Guenther]

Consider

  struct s { long a : 33; };
  long bar(struct s *x) { return (x->a << 16) >> 16; }
  extern void abort(void);
  int main()
  {
struct s a = { 1u << 31 };

if (bar(&a) != 0)
  abort ();
return 0;
  }

where we currently (rightfully so, IMHO) abort.

There are several problems with how we reach to that conclusion.  First
of all, a long bitfield is a GCC extension.  This extension does not
document integer promotion rules for such bitfields, and we indeed do
_not_ perform promotion to long for the argument of the shifts, but
the gimplifier is handed:

  return (long int) ((x->a << 16) >> 16);

which leads to a GIMPLE intermediate language representation with
registers/temporaries of width 31:

  long int D.1546;
   D.1547;
   D.1548;
   D.1549;

  D.1547 = x->a;
  D.1548 = D.1547 << 16;
  D.1549 = D.1548 >> 16;
  D.1546 = (long int) D.1549;
  return D.1546;

where this ILs only sane semantics do NOT match the runtime behavior
of the program (IMHO the only sane semantics is to truncate the
value after D.1548 = D.1547 << 16).

Now we go further and expand is handed basically the original IL again
if you run TER, or the above if not.  But as we do not have modes
for registers that have such irregular precision, simply DImode is
used for all the temporaries and no bitfield reduction operations
are emitted, making the runtime behavior as expected.

So, to conclude, the runtime behavior does neither match the C99
standard (which doesn't specify integer promotions for types that
do not fit in int, but also leaves bitfields of types with rank
bigger than int as implementation defined), nor the only sane
semantics of the tree-ssa IL.

As a solution I propose to

 - document how integral promotion is performed on the implementation
   defined bitfields we allow as a GNU extension.  (4.9, "Integer
   promotion rules are extended for non-standard bit-field types to
   promote to the smallest integer type that can represent all values
   of the bit-field type.")

 - actually perform these integral promotions

 - disallow GIMPLE registers whose precision does not match the
   precision of the underlying mode.  Note that this requires
   BIT_FIELD_REF to allow a resulting type that does not match the
   type of the first operand (but possibly only the same mode).
   [alternatively only disallow arithmetics on such registers]


This all will possibly help to solve PRs 33819 and 33887.

Any thoughts?

Would any of the C frontend maintainers please try to formulate
standards-proof documentation for 4.9?

Thanks,
Richard.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

Monday 14 January 2008 12:34:03 tarihinde Paolo Bonzini şunları yazmıştı:
> Why not fixing the handful of packages with a /^#define PACKAGE/d,
> instead of adding -fpermissive to the 50 users of those broken packages?

That simple fix won't work, there might be installed headers which depend on 
definitions in config.h . This might be broken but there are just too many 
cases to fix. At least gcc should have warned in gcc 4.3 that this will be an 
error in next release and do this in 4.4 instead of breaking stuff en masse.

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: [RFC] porting to gcc-4.3 docs

[Benjamin Kosnik]

> The attached patch makes it clearer to me, does anyone agree?

Please check this in. Thanks Jonathan!

-benjamin

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

[Joseph S. Myers]

On Mon, 14 Jan 2008, Richard Guenther wrote:

>  - document how integral promotion is performed on the implementation
>defined bitfields we allow as a GNU extension.  (4.9, "Integer
>promotion rules are extended for non-standard bit-field types to
>promote to the smallest integer type that can represent all values
>of the bit-field type.")

Once you define bit-fields to have their own types as explained in the C90 
DRs and apparently intended in the C99 textual history, everything about 
integer promotions follows from the standard (via the rules on integer 
promotion rank which assign ranks to all those types).  If you don't 
define that, other issues arise with no existing standard text to resolve 
them, see .

Thus I think we should:

* Admit in the documentation that we really do have extended integer types 
- one signed and one unsigned for each precision for which bit-fields are 
allowed, other than those for which there are standard types.

* Say that bit-fields are assigned such types.

* Make the gimplifier (or a later tree-ssa pass) insert whatever 
conversions / reductions in precision may be needed to produce trees 
acceptable to expand, if you think expand can't handle the special types 
reliably.  In particular, for arithmetic on such types and on all 
conversions to such types.  (Without special types, special code is still 
needed for assignments to bit-fields, no longer handled as conversions.)

* If C1x chooses an approach more like C++ than the C90 DRs to bit-field 
types, then make the C front end act more like the C++ front end does when 
in C1x mode.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

[Richard Guenther]

On Mon, 14 Jan 2008, Joseph S. Myers wrote:

> On Mon, 14 Jan 2008, Richard Guenther wrote:
> 
> >  - document how integral promotion is performed on the implementation
> >defined bitfields we allow as a GNU extension.  (4.9, "Integer
> >promotion rules are extended for non-standard bit-field types to
> >promote to the smallest integer type that can represent all values
> >of the bit-field type.")
> 
> Once you define bit-fields to have their own types as explained in the C90 
> DRs and apparently intended in the C99 textual history, everything about 
> integer promotions follows from the standard (via the rules on integer 
> promotion rank which assign ranks to all those types).  If you don't 
> define that, other issues arise with no existing standard text to resolve 
> them, see .

Can you clarify on the resulting promotions?  As I remember the
standard defines promotions based on the representable values, so
long : 15 gets promoted to int, but long : 33 doesn't get promoted.
In the C++ FE at least we promote to the _declared_ type, that is,
to long in this case.  (Which I find more natural, but may be not
what the standard says).

Now, if you assign a rank to long : 15 (is it the same as int : 15?),
would it still promote to int or would it promote to long or neither?

The question arises when computing the value of say long : 33 i;
i << 16 >> 16.  Is the shift performed in long : 33 type?  Is an
out-of-range value truncated?

> Thus I think we should:
> 
> * Admit in the documentation that we really do have extended integer types 
> - one signed and one unsigned for each precision for which bit-fields are 
> allowed, other than those for which there are standard types.

Fine.

> * Say that bit-fields are assigned such types.

Does behavior change for bit-fields that are standard conforming or
only for implementation defined bit-fields of long.

> * Make the gimplifier (or a later tree-ssa pass) insert whatever 
> conversions / reductions in precision may be needed to produce trees 
> acceptable to expand, if you think expand can't handle the special types 
> reliably.  In particular, for arithmetic on such types and on all 
> conversions to such types.  (Without special types, special code is still 
> needed for assignments to bit-fields, no longer handled as conversions.)

(The problem is that I'm trying to exactly define what it should mean
to the middle-end to for example do a NOP conversion to a bitfield - this
is not at all clear)

Right.  C requests this via a langhook (which C++ doesn't use).  So for
C++ we for example miscompile

extern "C" void abort (void);

struct s
{
  unsigned long long f1 : 40;
  unsigned int f2 : 24;
} sv;

void __attribute__((noinline)) foo(unsigned int i)
{
  unsigned int tmp;
  sv.f2 = i;
  tmp = sv.f2;
  if (tmp != 0)
abort ();
}

int main()
{
  foo (0xff00u);
  return 0;
}

because expand expands

  i.0 = () i;

to nothing.

This inconsistent behavior of the middle-end is IMHO bad.

Richard.

Simple language project...

[Tarmo Pikaro]

Hi !

I've decided to mail to gcc mail list, since I've could find best programming 
language experts in here.

I'm starting to design a new language called 'Simple language'.
I'm searching for people for discussing ideas, designing, brainstorming and/or 
making pc side code.

Here is web site: http://simplelanguage.wikidot.com/start
>From it you can find power point slides which would tell you more about where 
>I'm targetting at.

You can freely contact me over mail, phone or by icq.
If you know some related web site or place/forum which could assist in 'Simple 
language' creation, please
let me know. I've already got some links from several sources.
 
--
Have a nice day!
Tarmo.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

gcc-4.1-20080114 is now available

[gccadmin]

Snapshot gcc-4.1-20080114 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080114/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 131535

You'll find:

gcc-4.1-20080114.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20080114.tar.bz2 C front end and core compiler

gcc-ada-4.1-20080114.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20080114.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20080114.tar.bz2  C++ front end and runtime

gcc-java-4.1-20080114.tar.bz2 Java front end and runtime

gcc-objc-4.1-20080114.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20080114.tar.bz2The GCC testsuite

Diffs from 4.1-20080107 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

New ICE on gcc.dg/pr34233.c for MIPS...

[David Daney]

Between r131315 and r131326 I started getting an ICE on mipsel-linux for 
gcc.dg/pr34233.c.


See:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00144.html
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00204.html

David Daney

Re: jc1 out of memory error gcc 4.2.2 Linux 64-bit OS

[Harpal Grover]

On Jan 14, 2008 5:09 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>
> Harpal Grover writes:
>  > Hello all,
>  >
>  > I downloaded and built gcc 4.2.2 on my linux box. I have also used the
>  > sources to build a cross compiler using Ranjit's Matthews guide.  The
>  > build went just fine. I tried to compile my java application and got
>  > the following error:
>  >
>  > c1: out of memory allocating 4064 bytes after a total of 3909824512 bytes
>  >
>  > The specs on my laptop are as follows:
>  > Intel Core 2 Duo
>  > Suse 10.2 64-bit
>  > Linux 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64
>  > x86_64 x86_64 GNU/Linux
>  > 4 GB Ram
>  >
>  > jc1 spiked from 1 gig of memory to close to 4gb, eats up the swap and
>  > then finally crashes. Is there any additional information you guys
>  > would like me to provide? If so please feel free to let me know and I
>  > gladly will.
>
> I want to know what you were trying to compile.
>
> Andrew.

Hello

I am trying to compile a java app. I don't have the script in front of
me that i am using because I am at a client's office right now. The
jist of
the command line is as follows:

gcj -O -fjni -s -main=main.App --classpath=x1.jar x2.jar x3.jar x4.jar
x5.jar x6.jar x7.jar x8.jar -o scln.exe class1.java class2.java
class3.java ... class125.java -ly -ldz

So, this was fine compiling on Windows using a Native Cross Compiler
provided by Mohan Embar on a 32 bit processor. After upgrading my
hardware to a 64 bit processor, things were not working as pleasant as
I was hoping for. After some deliberation, I decided to build a cross
compiler on Linux using Ranjit Matthews tutorial.

Long story short, I contacted Ranjit and Marco Trudel on this matter,
and they have encouraged me to take this matter into my own hands. So
I am going to get started on debugging this issue tonight. I have been
looking for a good excuse to get involved in development for gcc for
sometime now and this is a good time.

Marco has confirmed this issue seems to be isolated to 64 bit
processors. I am new to this, so from my understanding gdb is the
debugging tool i am going to
want to use. As for IDE, what do you recommend? You must keep in mind
I am quite spoiled by such IDE's as Eclipse and Borland :P, so I
though KDevelop may be suit my needs? And any advice, or direction is
gladly welcomed.

Thanks

-- 
Harpal Grover
President
Harpal Grover Consulting Inc

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

[Alexandre Oliva]

On Jan 14, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:

> The question arises when computing the value of say long : 33 i;
> i << 16 >> 16.  Is the shift performed in long : 33 type?  Is an
> out-of-range value truncated?

If truncation makes any difference, then there must have been
overflow, which invokes undefined behavior, which means we don't need
to worry about reducing the bitfield regardless of promotion.

If you make it 'unsigned long i:33', then promotion becomes relevant.
It might still be the case that the shift is performed on the
full-width unsigned long, and then converted back to the narrower
bitfield type for the assignment.

>   i.0 = () i;

This triggers precisely the error described in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887#c18

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

[Joseph S. Myers]

On Mon, 14 Jan 2008, Richard Guenther wrote:

> Can you clarify on the resulting promotions?  As I remember the
> standard defines promotions based on the representable values, so
> long : 15 gets promoted to int, but long : 33 doesn't get promoted.
> In the C++ FE at least we promote to the _declared_ type, that is,
> to long in this case.  (Which I find more natural, but may be not
> what the standard says).

Types (including the bit-field width as part of the type) narrower than 
int are promoted based on representable values (so to int).  Types wider 
than int are left unchanged by the promotions.

> Now, if you assign a rank to long : 15 (is it the same as int : 15?),

They are the same; we only provide a single signed and a single unsigned 
bit-field type of each width.  (For int : 32, or other cases where the 
width is the full width of the declared type, we used the declared type; 
for cases where the width is that of a narrower standard type, we use that 
narrower standard type, with c_build_bitfield_integer_type determining 
preferences among types of the same width.)

> would it still promote to int or would it promote to long or neither?

To int, because int can represent all the values.

> The question arises when computing the value of say long : 33 i;
> i << 16 >> 16.  Is the shift performed in long : 33 type?  Is an
> out-of-range value truncated?

Performed in long : 33, according to the rules for shifts defined in 
implement-c.texi (which define some cases ISO C leaves 
implementation-defined, and one that's implementation-defined in C90 but 
undefined in C99.)

Arithmetic also follows the usual ISO C rules (e.g. signed overflow 
undefined, subject to -fwrapv making it modulo; unsigned overflow modulo).  
Arithmetic in narrow bit-field types e.g. int:25 won't appear at the 
language level any more than arithmetic in short does, because both get 
promoted to int.

> > * Say that bit-fields are assigned such types.
> 
> Does behavior change for bit-fields that are standard conforming or
> only for implementation defined bit-fields of long.

I don't believe anything is abservable for int and unsigned int (or _Bool) 
bit-fields about the types chosen, beyond the promotions and questions of 
whether certain out-of-range floating point to bit-field conversions are 
defined.  (There are however testcases in the GCC testsuite for e.g. 
diagnostics of out-of-range initializers that get implicitly converted to 
the bit-field type, such as storing 1 in a signed int : 1 bit-field that 
can only hold 0 and -1.)

> > * Make the gimplifier (or a later tree-ssa pass) insert whatever 
> > conversions / reductions in precision may be needed to produce trees 
> > acceptable to expand, if you think expand can't handle the special types 
> > reliably.  In particular, for arithmetic on such types and on all 
> > conversions to such types.  (Without special types, special code is still 
> > needed for assignments to bit-fields, no longer handled as conversions.)
> 
> (The problem is that I'm trying to exactly define what it should mean
> to the middle-end to for example do a NOP conversion to a bitfield - this
> is not at all clear)

The conversions between integer types should I think be defined in GIMPLE 
to follow the same rules as the C language conversions, documented in 
implement-c.texi for cases ISO C leaves implemenation-defined: that is, 
always reducing modulo 2^N to fit within the range of the type (except for 
conversions to _Bool).

> Right.  C requests this via a langhook (which C++ doesn't use).  So for
> C++ we for example miscompile

C++ probably should not have started using these types without also using 
the langhook.  (There may also be bugs in expand where the langhook is 
inadequate, and of course we should aim for the semantics of GIMPLE to be 
defined without needing such a langhook.)

As a general principle, very little before the RTL stages should care 
about machine modes; code that cares about them may be using them as a 
proxy for precision that goes wrong in the presence of bit-field types, 
and in any case they seem like the wrong level of abstraction for the 
earlier stages of the compiler.  At expand stage at the latest, the full 
set of types (possibly including bit-field types such as long:33, or Ada 
types with unusual ranges, or other such constructs) then needs to be 
mapped onto the lower level machine modes of RTL (at which point many 
operations also lose the signed/unsigned distinction).  Whether this is 
done at expand, at gimplification or somewhere inbetween may depend on 
whether we think the tree optimizers can usefully optimize arithmetic on 
special types before lowering, or whether they should be optimizing 
arithmetic after lowering (with extra shift/mask operations inserted), or 
both.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Simple language project...

[Ben Elliston]

> I'm starting to design a new language called 'Simple language'.

They rarely are, though.  :-)

> I'm searching for people for discussing ideas, designing, brainstorming 
> and/or making pc side code.

This is the wrong mailing list for this topic.  This list is used to
discuss the development of GCC.  Please try posting to a programming
language mailing list or, perhaps, comp.compilers.

Thanks, Ben