headers
Alexandre Oliva | 1 Apr 2009 01:37
Picon
Favicon

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

On Mar 13, 2009, Paolo Bonzini <bonzini <at> gnu.org> wrote:

> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.

FR-V non-vector shifts truncate a register shift count to 5 bits; it's
from the ISA specs, it doesn't appear that the same truncation is
applied to 10- or 12-bit immediate shift operands.  Vector shifts
truncate the 6-bit immediate shift count to 4 bits.

--

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer
Permalink | Reply | 0 comments |
headers
Joseph S. Myers | 1 Apr 2009 02:52

stdint.h type information needed

GCC now supports providing the header <stdint.h> (required by C99 of 
freestanding implementations) and having information within the compiler 
about the types used in this header.  For further discussion of this and 
its benefits, see 
<http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00305.html>.

Right now, the information is present in GCC for targets using glibc or 
uClibc, bare-metal and RTEMS targets (which are taken to use newlib's 
default stdint.h types) and Solaris targets.  To get the full benefits of 
this support, the information needs adding for all OSes supported by GCC.  
This is information about all the types C99 specifies for <stdint.h>, plus 
sig_atomic_t whose limits go in that header.

To add information for a target OS, put definitions such as those in 
glibc-stdint.h, newlib-stdint.h or sol2.h in a suitable target header, and 
set use_gcc_stdint in config.gcc.  It should be set to "wrap" if the 
system has its own stdint.h header, or "provide" if it doesn't.  (There 
might be special cases when some other arrangement is needed, but I expect 
those two generally to suffice.)  Make sure the new c99-stdint-*.c tests 
pass; if they show up bugs in the system's stdint.h header (as wrapped by 
GCC with the "wrap" setting) then report those upstream and fix them in 
GCC with fixincludes.

If the system does not have stdint.h, then suitable types may be found in 
one of the following places:

* A later OS version.

* inttypes.h (some systems have headers from C9x drafts that had only 
inttypes.h and not stdint.h).
(Continue reading)

Permalink | Reply | 14 comments |
headers
DJ Delorie | 1 Apr 2009 03:22
Picon
Favicon

Re: stdint.h type information needed


DJGPP has its own <stdint.h>, at least in DJGPP 2.04.
Permalink | Reply | 7 comments |
headers
Joseph S. Myers | 1 Apr 2009 03:57

Re: stdint.h type information needed

On Tue, 31 Mar 2009, DJ Delorie wrote:

> DJGPP has its own <stdint.h>, at least in DJGPP 2.04.

I expect most of the OSes listed do; the types should still be entered 
into GCC (so the Fortran front end can know them, for example), and 
use_gcc_stdint set to "wrap" unless there is a particular problem with 
using GCC's version in freestanding mode.  If the OS has its own copy, you 
can just go there to determine the types to enter into the appropriate 
tm.h header, instead of needing to try the other sources I listed.

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Permalink | Reply | 6 comments |
headers
DJ Delorie | 1 Apr 2009 04:12
Picon
Favicon

Re: stdint.h type information needed


> I expect most of the OSes listed do; the types should still be entered 
> into GCC (so the Fortran front end can know them, for example), and 

Well, I'm not a big fan of duplicating information, but if that's what
you want to do, here it is.  Enjoy.

/* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2002 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details */
#ifndef __dj_stdint__h_
#define __dj_stdint__h_

#ifdef __cplusplus
extern "C" {
#endif

#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
  || !defined(__STRICT_ANSI__)

typedef signed char int_least8_t;
typedef unsigned char uint_least8_t;
typedef signed char int_fast8_t;
typedef unsigned char uint_fast8_t;
typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef signed short int int_least16_t;
typedef unsigned short int uint_least16_t;
typedef signed int int_fast16_t;
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ryan Hill | 1 Apr 2009 04:41
Picon
Favicon
Gravatar

Re: [PPL-devel] PPL broken for Canadian-cross builds

On Sun, 29 Mar 2009 14:11:37 -0500
Sebastian Pop <sebpop <at> gmail.com> wrote:

> I committed the attached fix to the cloog-ppl repo, and I will prepare
> a new tar.gz for the gcc infrastructure.

Is changing the contents of the tarball without changing the name going
to be a habit or just something we'll have to live with until release?
It wrecks havoc with our (Gentoo's) manifest system and I'll have to
host a copy here if it's going to continue to be modified without a
version bump.

--

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets  <at>  gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
Permalink | Reply | 2 comments |
headers
David Edelsohn | 1 Apr 2009 05:04
Picon

Revised GCC Runtime Library Exception

The revised GCC Runtime Library Exception now is published on the FSF website:

http://www.gnu.org/licenses/gcc-exception.html

The FSF carefully considered the comments and concerns of the
community about the terminology and hopes that this new text clarifies
the permissions in conjunction with the FAQ.  The FAQ will continue to
expand to clarify the exception.

David
Permalink | Reply | 0 comments |
headers
Sebastian Pop | 1 Apr 2009 07:02
Picon
Gravatar

Re: [PPL-devel] PPL broken for Canadian-cross builds

On Tue, Mar 31, 2009 at 21:41, Ryan Hill <dirtyepic <at> gentoo.org> wrote:
> On Sun, 29 Mar 2009 14:11:37 -0500
> Sebastian Pop <sebpop <at> gmail.com> wrote:
>
>> I committed the attached fix to the cloog-ppl repo, and I will prepare
>> a new tar.gz for the gcc infrastructure.
>
> Is changing the contents of the tarball without changing the name going
> to be a habit or just something we'll have to live with until release?

Sorry to not have paid attention to this: Joseph Myers already warned
me about this.

> It wrecks havoc with our (Gentoo's) manifest system and I'll have to
> host a copy here if it's going to continue to be modified without a
> version bump.
>

I will call the next package cloog-ppl-0.15.2.tar.gz
Would that work for you?

Sebastian
Permalink | Reply | 1 comment |
headers
Ryan Hill | 1 Apr 2009 07:09
Picon
Favicon
Gravatar

Re: [PPL-devel] PPL broken for Canadian-cross builds

On Wed, 1 Apr 2009 00:02:43 -0500
Sebastian Pop <sebpop <at> gmail.com> wrote:

> On Tue, Mar 31, 2009 at 21:41, Ryan Hill <dirtyepic <at> gentoo.org> wrote:
> > On Sun, 29 Mar 2009 14:11:37 -0500
> > Sebastian Pop <sebpop <at> gmail.com> wrote:
> >
> >> I committed the attached fix to the cloog-ppl repo, and I will
> >> prepare a new tar.gz for the gcc infrastructure.
> >
> > Is changing the contents of the tarball without changing the name
> > going to be a habit or just something we'll have to live with until
> > release?
> 
> Sorry to not have paid attention to this: Joseph Myers already warned
> me about this.
> 
> > It wrecks havoc with our (Gentoo's) manifest system and I'll have to
> > host a copy here if it's going to continue to be modified without a
> > version bump.
> >
> 
> I will call the next package cloog-ppl-0.15.2.tar.gz
> Would that work for you?

You bet.  Thanks!

--

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
(Continue reading)

Permalink | Reply | 0 comments |
headers
DJ Delorie | 1 Apr 2009 07:11
Picon
Favicon

Re: bitfields: types vs modes?


So... can I/we move forward on this?  Or will such a change be
rejected?

BTW, Since sending this I discovered that gcc treats these
differently wrt TARGET_NARROW_VOLATILE_BITFIELD:

volatile struct
{
  unsigned int a:8;
  unsigned int b:24;
} t1;

volatile struct
{
  unsigned int a:7;
  unsigned int b:25;
} t2;

t1.a will be accessed as a byte regardless of the target's
preferences, whereas t2.c follows the target preferences.

> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode.  The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
> 
> However, gcc has a very simplistic heuristic for deciding what mode to
> use to access bitfields in structures - it uses either the biggest or
> smallest mode practical.  This offers the programmer no way to tell
(Continue reading)

Permalink | Reply | 13 comments |

Gmane