Quoting "Joseph S. Myers" :
If you want to have documentation extracted from source files, you need to
engage with the SC and FSF at an early stage to get suitable license
exception wording to permit the relevant text to be used in the manuals as
well as the main (GPL) sources.
I haven't gotten
Hi,
I am working on a micro controller and trying to port gcc(4.3.2) for it.
Not the compiling process runs into the following error:
a.c: In function 'task':
a.c:150: error: unrecognizable insn:
(insn 479 478 320 19 a:381 (set (reg:SI 12 a12)
(plus:SI (mult:SI (reg:SI 9 a9 [204])
Your instruction is likely too specific to be picked up by GCC.
You may use an intrinisc for it.
Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of fanqifei
> Sent: 12 January 2010 12:50
> To: gcc@gcc.gnu.org
> Subject: GCC-How do
2010/1/13 Bingfeng Mei :
> Your instruction is likely too specific to be picked up by GCC.
> You may use an intrinisc for it.
>
> Bingfeng
but insv is a standard pattern name.
the semantics of expression x= (x&0xFF00) | ((i<<16)&0x00FF);
is exactly what insv can do.
I all tried mips gcc cr
OOPs, I don't know that. Anyway, I won't count on GCC to
reliably pick up these complex patterns. In our port, we
implemented clz/ffs/etc as intrinsics though they are present as
standard patterns.
Bingfeng
> -Original Message-
> From: fanqifei [mailto:fanqi...@gmail.com]
> Sent: 13
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> > So, IMO we have two sensible proposals:
> > (a) specify that bits <7:1> must be zero
> > (b) specify that bits <31:1> must be zero
>
> I uploaded sources and object files generated by gcc 4.4, icc 11.1
> and Sun Studio 12 Update 1 at -O to:
>
> http://
Hi,
On Sun, 10 Jan 2010, Dave Korn wrote:
> Ok. So if I had four ints, and I wanted to cast the pointers to char
> and compare them as 16 chars, that would be OK, because the chars would
> alias the ints; but in this case, where they started as chars and I cast
> them to ints, those ints do
On Wed, 13 Jan 2010, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
> > If you want to have documentation extracted from source files, you need to
> > engage with the SC and FSF at an early stage to get suitable license
> > exception wording to permit the relevant text to be used in the manua
Adding and maintaining target hooks is unnecessarily hard at the moment,
because the definition is spread across three places, and these are supposed
to be kept in sync. The code is necessarily kept more or less in sync because
it generally fails to compile or work when it isn't - and if someone
Quoting "Joseph S. Myers" :
Please note that your initial change to implement automatic doc extraction
should not result in any changes to the Texinfo content of the manual.
Such fixes should all go in either before or after the automatic doc
extraction change, but not at the same time; the doc
On Wed, 13 Jan 2010, Joern Rennecke wrote:
> Duplicating all these changes separately by hand seems nigh impossible.
> I think the best approach is then to take the auto-generated tm.texi as
> the new tm.texi, and packages it up as a patch together with the
> struct member / hook name changes that
Hi Jan,
Can you take a look at this patch when you find the time ? This is
being blocked needing an approval from a x86 backend maintainer and
you are the only one listed in the MAINTAINERS file.
Thanks,
-Sriraman.
On Tue, Oct 6, 2009 at 2:56 PM, Paolo Bonzini wrote:
> On 10/01/2009 11:37 P
On Sun, 2010-01-10 at 15:46 +0100, Eric Botcazou wrote:
> > The aliasing rules treat "char" specially because char is a bit like a
> > "poor main's void".
>
> Not symmetrically though, only for the type of the lvalue expression used to
> access the object (C99 6.5.7).
BTW in Ada if one uses addr
We use TLS relocated symbols to create thread-local symbols
in the GCC UPC compiler, and have run into an issue illustrated
by the following program, on a test case that defines a
common symbol in several files, and uses it in a single file.
The following program fails to link, with multiple defs:
Joern Rennecke wrote:
> References: <4ae6e471.4020...@starynkevitch.net>
>
> <4ae70c5e.4050...@starynkevitch.net>
> <84fc9c000910270839v2d9efe0dw829c8647f361c...@mail.gmail.com>
> <4ae7164d.9010...@starynkevitch.net>
> <84fc9c000910270855w736df367qe511d8db280aa...@mail.gmail.com>
> <2dc303d6091027
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
IMHO it would be a godd idea to add the following two configure options to ppl
configure:
--with-gmp-include=DIR GMP include directory
--with-gmp-lib=DIR GMP lib directory
On 64-bit Linux systems you have the libraries in lib64 instead of li
On Wed, Jan 13, 2010 at 14:55, Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> IMHO it would be a godd idea to add the following two configure options to ppl
> configure:
> --with-gmp-include=DIR GMP include directory
> --with-gmp-lib=DIR GMP lib directory
>
> On
> BTW in Ada if one uses address clause to overlay a 16 character string
> and a 4 4-byte integer array (both aliased) which is then accessed what
> can we expect GCC-wise? Are we safe from aliasing related optimizations?
Yes, we use a big hammer to make sure 'Address is immune to these issues.
-
Gary Funck writes:
> We use TLS relocated symbols to create thread-local symbols
> in the GCC UPC compiler, and have run into an issue illustrated
> by the following program, on a test case that defines a
> common symbol in several files, and uses it in a single file.
The only way I know to get
2010/1/13 Bingfeng Mei :
> OOPs, I don't know that. Anyway, I won't count on GCC to
> reliably pick up these complex patterns. In our port, we
> implemented clz/ffs/etc as intrinsics though they are present as
> standard patterns.
>
> Bingfeng
Could you please show me the path of the source code t
On 01/13/10 17:15:10, Ian Lance Taylor wrote:
[...]
> Otherwise TLS variables are generated as definitions rather than as
> common variables.
>
> Why do you want them to be common?
For GCC/UPC compiled programs there are two compilation modes: 1) Each
UPC thread is implemented as a full process,
2010/1/13 fanqifei :
> Hi,
> I am working on a micro controller and trying to port gcc(4.3.2) for it.
> Not the compiling process runs into the following error:
> a.c: In function 'task':
> a.c:150: error: unrecognizable insn:
> (insn 479 478 320 19 a:381 (set (reg:SI 12 a12)
> (plus:SI (mu
22 matches
Mail list logo
