Re: help needed on gcc instruction scheduling with unspec_volatile()

[Ian Lance Taylor]

raja.sal...@iap-online.com writes:

>>> Is there a way to make the instruction has to allocate to run without
>>> using the scheduler for particular instruction ?
>>
>> I don't understand the question.
>
> The target we are using supports parallel instruction execution, Max 7.
> For one cycle, one instruction packet is executed. one packet has max 7
> instructions. so the scheduler is enabled. However, the scheduler enabling
> is not required for some packets. so how we can disable the instruction
> scheduling for particular packets ?

The scheduler in gcc schedules individual machine instructions.  Are
you asking about disabling the scheduler from the source code, or are
you asking about disabling the scheduler for specific instructions?
If you are talking about specific instructions, then you just need to
give them appropriate characteristics.  For example, if an instruction
is defined to use all the functional units, then it will not be
scheduled in any very meaningful way.

Note that gcc's scheduler is not really VLIW aware, and if there are
any constraints on the instructions to put them into a packet those
will have to be implemented in C code in your backend.  This is not a
simple task, but it has been done for some targets, such as the FRV.


>> Nothing is out of scope of the scheduler.  Using unspec_volatile in
>> the RTL template makes the instruction a scheduling barrier and a
>> memory barrier.
>
> Can you give more information or link to understand more about
> unspec_volatile ? The information available in gcc internals is not
> sufficient.

I don't know what to say beyond what is already in the internals
documentation.  I don't know of any more detailed documentation.  If
you ask a more specific question then perhaps somebody can answer it.

Ian

Re: gcc 4.5 ... && 32 build on 64

[Ian Lance Taylor]

"Brian O'Mahoney"  writes:

> Two quick questions:

This message might have been better sent to gcc-h...@gcc.gnu.org.
Please consider taking any followups there.  Thanks.


> (1) Is the feature roadmap for 4.5, 4.6 ... published anywhere

No.  We're not that formal.  Likely major features are LTO, plugins,
and better aliasing.


> (2) What is the recommended way to force 32 bit build on 64 eg 86_64 and will 
> it work with libtool and all. I have a solution but its very ugly!

Compiler with -m32?  Or if you mean that you want a version of gcc
that defaults to 32-bit, try configuring with

--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu

Ian

Re: GCC 4.3.3 Released

[Laurent GUERBY]

On Sun, 2009-02-01 at 12:15 +0100, Richard Guenther wrote:
> The GNU Compiler Collection version 4.3.3 has been released.
> 
> GCC 4.3.3 is a bug-fix release containing fixes for regressions and
> serious bugs in GCC 4.3.2.  This release is available from the
> FTP servers listed at:
> 
>   http://www.gnu.org/order/ftp.html
> 
> Please do not contact me directly regarding questions or comments about
> this release.  Instead, use the resources available from 
> http://gcc.gnu.org.
> 
> As always, a vast number of people contributed to this GCC release -- far
> too many to thank individually!

Unpatched release results on various architectures running linux from
the compile farm:

x86_64=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00081.html
i686  => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00126.html
powerpc   => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00125.html
mipsel=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00210.html
sparc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00168.html
armv5tel  => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00281.html
alpha => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html

I'll try sparc64, powerpc64 and ia64 when the machines are available.

For compile farm users: the installs are available
in /opt/cfarm/release/4.3.3/bin on all machines.

Sincerely,

Laurent
http://gcc.gnu.org/wiki/CompileFarm

geode optimizations

[Carl]

Hi, Im sorry that this is not 100% specific to gcc, however this
mailing list is the last place where I think this knowledge may lie. I
have written some image processing routines in assembly language
making extensive use of MMX, and now I want to start optimizing it,
however I cant for the life of me find any documentation such as the
Intel/AMD optimization manuals for pentium/athlon/opertron cores. I
cant even find much useful information from mailing lists such as this
one, where i was hoping to find it. Anyway, Im no expert in the
matter, however I do understand the concepts of instruction pairing
and pipelining. I know that the geode lx core, which is what we have
for robocup, is non-superscalar. From what I understand the core has
two pipelines, the one to the Integer unit and the other to the
fpu/MMX/3d Now unit. Does this more or less mean that instruction
pairing has no effect? Is it still worth scheduling instructions in a
pattern, such as the 4 - 1 - 1 the intel optimization manual suggests
for its cores? I saw that gcc 4.3 added geode support, and Im hoping
someone will have some better knowledge of the subject. Can anyone
give me any pointers as to what i should be trying to optimize, or
better yet links to documentation or hard benchmarks? Thanks in
advance.

Re: GCC 4.3.3 Released

[Dennis Clarke]

> On Sun, 2009-02-01 at 12:15 +0100, Richard Guenther wrote:
>> The GNU Compiler Collection version 4.3.3 has been released.
>>
>> GCC 4.3.3 is a bug-fix release containing fixes for regressions and
>> serious bugs in GCC 4.3.2.  This release is available from the
>> FTP servers listed at:
>>
>>   http://www.gnu.org/order/ftp.html
>>
>> Please do not contact me directly regarding questions or comments about
>> this release.  Instead, use the resources available from
>> http://gcc.gnu.org.
>>
>> As always, a vast number of people contributed to this GCC release --
>> far
>> too many to thank individually!
>
> Unpatched release results on various architectures running linux from
> the compile farm:
>
> x86_64=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00081.html
> i686  => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00126.html
> powerpc   => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00125.html
> mipsel=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00210.html
> sparc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00168.html
> armv5tel  => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00281.html
> alpha => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html
>
> I'll try sparc64, powerpc64 and ia64 when the machines are available.

I can probably help you with the Sparc64 requirement. To be precise, do
you need Sun UltraSparc or are you looking for the multicore SPARC64
processor which is a ( slightly ) different beast?

Dennis Clarke
http://www.blastwave.org/

Re: GCC 4.3.3 Released

[Laurent GUERBY]

On Tue, 2009-02-03 at 10:52 -0500, Dennis Clarke wrote:
> > On Sun, 2009-02-01 at 12:15 +0100, Richard Guenther wrote:
> >> The GNU Compiler Collection version 4.3.3 has been released.
> >>
> >> GCC 4.3.3 is a bug-fix release containing fixes for regressions and
> >> serious bugs in GCC 4.3.2.  This release is available from the
> >> FTP servers listed at:
> >>
> >>   http://www.gnu.org/order/ftp.html
> >>
> >> Please do not contact me directly regarding questions or comments about
> >> this release.  Instead, use the resources available from
> >> http://gcc.gnu.org.
> >>
> >> As always, a vast number of people contributed to this GCC release --
> >> far
> >> too many to thank individually!
> >
> > Unpatched release results on various architectures running linux from
> > the compile farm:
> >
> > x86_64=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00081.html
> > i686  => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00126.html
> > powerpc   => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00125.html
> > mipsel=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00210.html
> > sparc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00168.html
> > armv5tel  => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00281.html
> > alpha => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html
> >
> > I'll try sparc64, powerpc64 and ia64 when the machines are available.
> 
> I can probably help you with the Sparc64 requirement. To be precise, do
> you need Sun UltraSparc or are you looking for the multicore SPARC64
> processor which is a ( slightly ) different beast?

Thanks for your offer.

I do have access to a sparc64, in fact it's the same machine that I used
for the sparc (32 bits) report in the farm, but it is down since since
morning and will probably be up again in the next few days.

Sincerely,

Laurent

Re: GCC & OpenCL ?

[Andrey Belevantsev]

Hello,

We at ISP RAS have plans to work in the near future on generating either 
 CUDA source or PTX from C programs (probably with simple OpenMP 
directives).  Of course, we would benefit from the OpenCL infrastructure 
 in GCC if one was available.


Mark Mitchell wrote:

We (CodeSourcery) have been talking to our commercial partners about
implementing OpenCL in GCC and trying to develop/assess the level of
interest.  As others have stated, our theory of operation here would be
to have the compiler depend on a library API that could be implemented
for GPUs or for ordinary multi-core CPUs.  (Just as the libgomp API
could be provided to the compiler without depending on POSIX threads.)
In the case of generating code for GPUs, I am wondering whether the 
backend that produces device assembly for the kernel code will be (in 
your theory) implemented inside GCC, or would that be a third-party 
tool?  Obviously, a library is not enough for a heterogeneous system, or 
am I missing anything from your description?  As I know, e.g. there is 
no device-independent bytecode in the OpenCL standard which such a 
backend could generate.


Andrey

What is the objective of Configure, Make, Make Install?

[rkarthi2k5]

Hi Sir/Mam,

I installed the gcc and  other softwares wlth .tar extension. We
have to do a step by step procedure while installing the  sofware which have
.tar extension. 

 1) First, we have to unzip the file and give ./configure 
 2) Second, we have to give make
 3) Third, we logon to root and give make install.

   My question is, why we are doing the above steps sequentially and
what is actually happend at the each and every steps(configure,make,make
install). What is the objective of Configure, Make, Make Install? I request
u to give elloborate explanation, because i m new to Linux. Waiting for ur
valuable reply.


Thanks and Regards,
Karthikeyan.R
-- 
View this message in context: 
http://www.nabble.com/What-is-the-objective-of-Configure%2C-Make%2C-Make-Install--tp21813282p21813282.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: What is the objective of Configure, Make, Make Install?

[Andrew Haley]

rkarthi2k5 wrote:
> Hi Sir/Mam,

Do not post this to the gcc list, which is for the development of gcc.
I answered your question on the gcc-help list.

Andrew.

Re: GCC 4.3.3 Released

[Dennis Clarke]

>> > I'll try sparc64, powerpc64 and ia64 when the machines are available.
>>
>> I can probably help you with the Sparc64 requirement. To be precise, do
>> you need Sun UltraSparc or are you looking for the multicore SPARC64
>> processor which is a ( slightly ) different beast?
>
> Thanks for your offer.
>
> I do have access to a sparc64, in fact it's the same machine that I used
> for the sparc (32 bits) report in the farm, but it is down since since
> morning and will probably be up again in the next few days.

I am always a very careful with the 32-bit Sparc build because I often end
up with a 32-bit gcc but the ABI says SPARC V8PLUS or some such.

Thus I use a genuine old old Sparc to build GCC with.

# uname -a
SunOS fossil 5.8 Generic_117350-56 sun4m sparc SUNW,SPARCstation-20

# isalist -v
sparcv8 sparcv8-fsmuld sparcv7 sparc

# file /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc
/opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc:   ELF 32-bit MSB executable
, dynamically linked, not stripped

see the "SPARC Version 1" there?  That is my assurance that this will work
on everything from old Sparc to the latest Niagara procs. It won't be fast
.. but it will work.

# /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /export/nfs/build/gnu/GCC/gcc-4.3.3/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-cpu=v7 --enable-threads=posix --enable-nls --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --enable-shared --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
--enable-languages=c,c++,f95,objc,ada --enable-bootstrap
Thread model: posix
gcc version 4.3.3 (GCC)

Dennis

Re: [AVX]: Update x86-64 psABI for aggregates with __m256

[H.J. Lu]

On Sun, Feb 1, 2009 at 11:44 AM, H.J. Lu  wrote:
> Hi,
>
> We like to update x86-64 psABI to pass aggregates of 32 bytes with
> single __m256 field
> in AVX registers, instead of memory. However, finding the proper
> wording seems tricky.
> Here is what I got.  Any comments?
>

Here is the revised proposal. Any comments. I will post a gcc
patch soon.

Thanks.


-- 
H.J.
--- ../trunk/low-level-sys-info.tex 2009-01-28 15:03:11.0 -0800
+++ ./low-level-sys-info.tex2009-02-03 06:57:11.0 -0800
@@ -247,7 +247,8 @@ Intel AVX (Advanced Vector Extensions) p
 are aliased to the respective 128b-bit SSE registers (\reg{xmm0} -
 \reg{xmm15}). For purposes of parameter passing and function return,
 \reg{xmmN} and \reg{ymmN} refer to the same register. Only one of them
-can be used at the same time.
+can be used at the same time.  We use vector register to refer either
+SSE or AVX register.
 
 This subsection discusses usage of each register.  Registers \RBP, \RBX and
 \reg{r12} through \reg{r15} ``belong'' to the calling function and the
@@ -343,10 +344,9 @@ classes are corresponding to \xARCH regi
 \begin{description}
 \item[INTEGER] This class consists of integral types that fit into one of
   the general purpose registers.
-\item[SSE] The class consists of types that fit into a SSE register.
-\item[SSEUP] The class consists of types that fit into a SSE register
-  and can be passed and returned in the most significant half of it.
-\item[AVX] The class consists of types that fit into a AVX register.
+\item[SSE] The class consists of types that fit into a vector register.
+\item[SSEUP] The class consists of types that fit into a vector
+  register and can be passed and returned in the upper bytes of it.
 \item[X87, X87UP] These classes consists of types that will be returned via
   the x87 FPU.
 \item[COMPLEX\_X87] This class consists of types that will be returned
@@ -372,7 +372,9 @@ The basic types are assigned their natur
 \item Arguments of types \code{__float128}, \code{_Decimal128}
   and \code{__m128} are split into two halves.  The least significant
   ones belong to class SSE, the most significant one to class SSEUP.
-\item Arguments of type \code{__m256} are in class AVX.
+\item Arguments of type \code{__m256} are split into four \eightbyte
+  chunks.  The least significant one belongs to class SSE and all the
+  others to class SSEUP.
 \item The 64-bit mantissa of arguments of type \code{long double}
   belongs to class X87, the 16-bit exponent plus 6 bytes of padding
   belongs to class X87UP.
@@ -407,7 +409,7 @@ The classification of aggregate (structu
 types works as follows:
 
 \begin{enumerate}
-\item If the size of an object is larger than two \eightbytes, or
+\item If the size of an object is larger than four \eightbytes, or
   it contains unaligned fields, it has class MEMORY.
 
 \item If a C++ object has either a non-trivial copy constructor
@@ -424,14 +426,14 @@ types works as follows:
 \item for all the nonstatic data members of its class that are
   of class type (or array thereof), each such class has a
   trivial de/constructor.
-\end{itemize}}
+\end{itemize}},
 it is passed by invisible reference
 (the object is replaced in the parameter list by a pointer that
-has class INTEGER).
+has class INTEGER)
   \footnote{An object with either a non-trivial copy
constructor or a non-trivial destructor cannot be passed by value
because such objects must have well defined addresses.  Similar
-   issues apply when returning an object from a function.}
+   issues apply when returning an object from a function.}.
 
 \item If the size of the aggregate exceeds a single \eightbyte, each is
 classified separately.  Each \eightbyte gets initialized to class NO_CLASS.
@@ -452,7 +454,10 @@ types works as follows:
 \item Then a post merger cleanup is done:
   \begin{enumerate}
   \item If one of the classes is MEMORY, the whole argument is passed in 
memory.
-  \item If SSEUP is not preceeded by SSE, it is converted to SSE.
+  \item If the size of the aggregate exceeds two \eightbytes and the first
+\eightbyte isn't SSE or any other \eightbyte isn't SSEUP, the whole
+argument is passed in memory.
+  \item If SSEUP is not preceded by SSE or SSEUP, it is converted to SSE.
   \end{enumerate}
 \end{enumerate}
 
@@ -470,18 +475,15 @@ left-to-right order) for passing as foll
 available as scratch register means that code in the PLT need not
 spill any registers when computing the address to which control
 needs to be transferred.  \RAX is used to indicate the number of
-SSE arguments passed to a function requiring a variable number of
+vector arguments passed to a function requiring a variable number of
 arguments. \reg{r10} is used for passing a function's static chain
 pointer.}.
 
-\item If the class is SSE, the next available SSE register is used, the
+\item If the class is SSE, the next available ve

Re: GCC & OpenCL ?

[Mark Mitchell]

Andrey Belevantsev wrote:

> Obviously, a library is not enough for a heterogeneous system, or
> am I missing anything from your description?  As I know, e.g. there is
> no device-independent bytecode in the OpenCL standard which such a
> backend could generate.

That's correct.  I was envisioning a proper compiler that would take
OpenCL input and generate binary output, for a particular target, just
as with all other GCC input languages.  That target might be a GPU, or
it might be a multi-core CPU, or it might be a single-core CPU.

Of course, OpenCL also specifies some library functionality; that could
be provided in a library that included hand-written assembly code, or
was generated by some non-GCC tool.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.3.3 Released

[Eric Botcazou]

> I am always a very careful with the 32-bit Sparc build because I often end
> up with a 32-bit gcc but the ABI says SPARC V8PLUS or some such.

On Solaris.  Things are quite different on Linux and other OSes.

> # /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc -v
> Using built-in specs.
> Target: sparc-sun-solaris2.8
> Configured with: /export/nfs/build/gnu/GCC/gcc-4.3.3/configure
> --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
> --with-cpu=v7 --enable-threads=posix --enable-nls --prefix=/opt/csw/gcc4
> --with-local-prefix=/opt/csw --enable-shared --enable-multilib
> --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
> --with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
> --enable-languages=c,c++,f95,objc,ada --enable-bootstrap
> Thread model: posix
> gcc version 4.3.3 (GCC)

You could use --with-cpu=v8 instead of v7.

-- 
Eric Botcazou

Re: GCC & OpenCL ?

[Chris Lattner]

On Feb 3, 2009, at 8:48 AM, Mark Mitchell wrote:


Andrey Belevantsev wrote:


Obviously, a library is not enough for a heterogeneous system, or
am I missing anything from your description?  As I know, e.g. there  
is

no device-independent bytecode in the OpenCL standard which such a
backend could generate.


That's correct.  I was envisioning a proper compiler that would take
OpenCL input and generate binary output, for a particular target, just
as with all other GCC input languages.  That target might be a GPU, or
it might be a multi-core CPU, or it might be a single-core CPU.

Of course, OpenCL also specifies some library functionality; that  
could

be provided in a library that included hand-written assembly code, or
was generated by some non-GCC tool.


That's an interesting and very reasonable approach to start with.   
However, realize that while this will give you ability to run programs  
that use some of the OpenCL language extensions, you won't be able to  
run any real OpenCL apps.  The OpenCL programming model fundamentally  
requires runtime compilation and the kernel-manipulation library APIs  
are a key part of that.


-Chris

Re: GCC & OpenCL ?

[Joseph S. Myers]

On Tue, 3 Feb 2009, Chris Lattner wrote:

> On Feb 3, 2009, at 8:48 AM, Mark Mitchell wrote:
> 
> > Andrey Belevantsev wrote:
> > 
> > > Obviously, a library is not enough for a heterogeneous system, or
> > > am I missing anything from your description?  As I know, e.g. there is
> > > no device-independent bytecode in the OpenCL standard which such a
> > > backend could generate.
> > 
> > That's correct.  I was envisioning a proper compiler that would take
> > OpenCL input and generate binary output, for a particular target, just
> > as with all other GCC input languages.  That target might be a GPU, or
> > it might be a multi-core CPU, or it might be a single-core CPU.
> > 
> > Of course, OpenCL also specifies some library functionality; that could
> > be provided in a library that included hand-written assembly code, or
> > was generated by some non-GCC tool.
> 
> That's an interesting and very reasonable approach to start with.  However,
> realize that while this will give you ability to run programs that use some of
> the OpenCL language extensions, you won't be able to run any real OpenCL apps.
> The OpenCL programming model fundamentally requires runtime compilation and
> the kernel-manipulation library APIs are a key part of that.

Naturally the GCC implementation would include both host-side and 
target-side libraries, where the host-side library includes all the APIs 
that execute the compiler and the target-side library is like libgcc / 
libstdc++ / libgfortran / libgomp / ... and provides implementations of 
the built-in functions (when it makes sense for them to generate 
out-of-line calls) and any other runtime support needed for the language.  
(There are however probably cases when it makes sense to build the 
host-side library for the target as well as for the host - i.e. to build 
it for systems where the compiler itself is not being built, with the 
expectation that the kernels will either be built ahead of execution or be 
built via running the compilers remotely.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC 4.3.3 Released

[rkiesling]

Dennis Clarke:
[ Charset ISO-8859-1 converted... ]
> 
> >> > I'll try sparc64, powerpc64 and ia64 when the machines are available.
> >>
> >> I can probably help you with the Sparc64 requirement. To be precise, do
> >> you need Sun UltraSparc or are you looking for the multicore SPARC64
> >> processor which is a ( slightly ) different beast?
> >
> > Thanks for your offer.
> >
> > I do have access to a sparc64, in fact it's the same machine that I used
> > for the sparc (32 bits) report in the farm, but it is down since since
> > morning and will probably be up again in the next few days.
> 
> I am always a very careful with the 32-bit Sparc build because I often end
> up with a 32-bit gcc but the ABI says SPARC V8PLUS or some such.
> 
> Thus I use a genuine old old Sparc to build GCC with.

A 64-bit build would require a cross compilation, or perhaps I missed 
something?  I need to tell gmp's ./configure that --build=sparc first, due 
to the old old 32-bit bundled compiler, and also --disable-multilib to
build GCC.  

On an (possibly) off-topic note, it seems that gmp requires GNU ld, but GCC 
needs the native ld.  I haven't ben able to pin down where in the build
process that the libs and the compiler suddenly require the 32-bitness.  

This on a sparc64 with a new install of Solaris10 (seems yet to
require /usr/bin/ksh as the login shell and the addition of GNU sed).

-- 
Ctalk Home Page: http://www.ctalklang.org

Re: GCC 4.3.3 Released

[Eric Botcazou]

> On an (possibly) off-topic note, it seems that gmp requires GNU ld, but GCC
> needs the native ld.

Neither is supposed to be true (and I've built GMP with Sun ld and GCC with 
GNU ld many times).

-- 
Eric Botcazou

Re: GCC 4.3.3 Released

[rkiesling]

> > On an (possibly) off-topic note, it seems that gmp requires GNU ld, but GCC
> > needs the native ld.
> 
> Neither is supposed to be true (and I've built GMP with Sun ld and GCC with 
> GNU ld many times).

I didn't take notes, and you wouldn't find my configuration very
useful (much symlinking to the bundled GNU utilities) so I won't add
anything to the information about the two disparate build chains

-- 
Ctalk Home Page: http://www.ctalklang.org

Re: Plugin API Comments

[Sean Callanan]

Rather than invent a new quoting syntax, why not just split the
arguments up?  If each a plugin has a name, you could use that name in
subsequent -f arguments.  E.g., if the name of the plugin in
"plugin.so" is "foo", perhaps:

   -fplugin=/path/to/plugin.so -ffoo-arg1=value1 -ffoo-arg2=value2

The actual spelling could be "-fplugin-$NAME-arg" if you think the
above is too likely to clash with already existing (or future)
argument names.


Tom's idea is similar to precedent.  GCC already has the -Wl flag;  
maybe we could just use a similar mechanism?  From the man page:

--
-Wl,option
   Pass option as an option to the linker.  If option  
contains commas,

   it is split into multiple options at the commas.
--
So perhaps we could do something like
--
-Wplugin-$NAME,arg=value

If we require a one-to-one correspondence between -Wplugin parameters  
and parameters passed to the plugin, then this resolves both the issue  
of identifying which parameter maps to which argument, and also the  
problem of pathnames with odd characters.


Sean

Re: GCC & OpenCL ?

[Ross Ridge]

Mark Mitchell writes:
>That's correct.  I was envisioning a proper compiler that would take
>OpenCL input and generate binary output, for a particular target, just
>as with all other GCC input languages.  That target might be a GPU, or
>it might be a multi-core CPU, or it might be a single-core CPU.

I have a hard time seeing why this would be all that worthwhile.
Since the instruction sets for AMD, NVIDIA or current Intel GPUs are
trade scretes, GCC won't be able to generate binary output for them.
OpenCL is designed for heterogenous systems, compiling for multi-core or
single-core CPUs would only be useful as a cheap fallback implementation.
This limits a GCC-based OpenGL implementation to achieving it's primary
purpose with just Cell processors and maybe Intel's Larrabee.  Is that
what you envision?  Without AMD/NVIDIA GPU support it doesn't sound all
that useful to me.

Ross Ridge

Re: GCC & OpenCL ?

[Basile STARYNKEVITCH]

Ross Ridge wrote:

Mark Mitchell writes:
  

That's correct.  I was envisioning a proper compiler that would take
OpenCL input and generate binary output, for a particular target, just
as with all other GCC input languages.  That target might be a GPU, or
it might be a multi-core CPU, or it might be a single-core CPU.



I have a hard time seeing why this would be all that worthwhile.
Since the instruction sets for AMD, NVIDIA or current Intel GPUs are
trade scretes, GCC won't be able to generate binary output for them.


It seems to me that some specifications seems to be available. I am not 
a GPU expert, but 
http://developer.amd.com/documentation/guides/Pages/default.aspx 
contains a R8xx Family Instruction Set Archictectire document at 
http://developer.amd.com/gpu_assets/r600isa.pdf and at a very quick 
first glance (perhaps wrongly) I feel that it could be enough to design 
& write a code generator for it.


But I may be wrong.

I still hope that some GPU specifications would become open.


Of course, if not enough specifications are available, I cannot imagine 
how GCC could compile kernel OpenCL functions.
(even the future GCC plugins are expected to make proprietary extensions 
legally impossible, or at least difficult).


Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant plus de 4000 adhérents http://www.april.org

new GCC mirror site

[Ádám Rák]

Dear gcc.gnu.org

I mirrored the ftp://gcc.gnu.org/pub/gcc to

http://robotlab.itk.ppke.hu/gcc

country: Hungary
city: Budapest

contact:
name: Adam Rak (Ádám Rák)
e-mail: neur...@gmail.com

The mirror is updated daily. I can configure it to be more frequent if
you require.

Best wishes:
Ádám Rák

Re: GCC & OpenCL ?

[Ross Ridge]

Basile STARYNKEVITCH writes:
>It seems to me that some specifications
>seems to be available. I am not a GPU expert, but
>http://developer.amd.com/documentation/guides/Pages/default.aspx
>contains a R8xx Family Instruction Set Archictectire document at
>http://developer.amd.com/gpu_assets/r600isa.pdf and at a very quick
>first glance (perhaps wrongly) I feel that it could be enough to design &
>write a code generator for it.

Oh, ok, that makes a world of difference.  Even with just AMD GPU
support a GCC-based OpenCL implementation becomes a lot more practical.

Ross Ridge

Re: Plugin API Comments

[Manuel López-Ibáñez]

2009/2/3 Sean Callanan :
> --
> -Wl,option
>   Pass option as an option to the linker.  If option contains
> commas,
>   it is split into multiple options at the commas.
> --
> So perhaps we could do something like
> --
> -Wplugin-$NAME,arg=value
>

I apologise if this sounds bikeshedding, but the "W", in -Wl is just
historical, it doesn't have any meaning as far as I know. And not all
options of gcc must start by either -f or -W. So please use just
-plugin, or, following your proposal:

-plugin=$NAME,arg1=value1,arg2=value2

Let -Wplugin be something that warns about plugins, whatever that may
mean in the future.

Cheers,

Manuel.

Re: PR 39076 Backport a patch for GCC 4.3

[Mark Mitchell]

Ramana Radhakrishnan wrote:
> Hi Mark,
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076 appears to be an
> reappearance of the failure reported originally at
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html . and detailed
> discussion in the thread that ends at
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00907.html .
> 
> Is it ok to backport this patch into gcc-4.3 after regression testing?

Yes.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GCC & OpenCL ?

[Albert Cohen]

Ross Ridge wrote:

Basile STARYNKEVITCH writes:

It seems to me that some specifications
seems to be available. I am not a GPU expert, but
http://developer.amd.com/documentation/guides/Pages/default.aspx
contains a R8xx Family Instruction Set Archictectire document at
http://developer.amd.com/gpu_assets/r600isa.pdf and at a very quick
first glance (perhaps wrongly) I feel that it could be enough to design &
write a code generator for it.


Oh, ok, that makes a world of difference.  Even with just AMD GPU
support a GCC-based OpenCL implementation becomes a lot more practical.

Ross Ridge


I am also interested in working on OpenCL support for GCC, for several 
reasons.


1. This would be a way to increase accessibility of OpenCL to a wider 
set of users, programming environments (and source languages), and 
target platforms, including embedded ones (think of ARM/NVidia Tigra).


2. It would make good use of the high-level optimizations building up in 
GCC, including LTO (for specialization purposes, something LLVM is great 
at, but which could be done at a much larger scale in GCC), Graphite, 
automatic vectorization for Larrabee-like SIMD architectures mixing 
vectors and threads, etc.


3. Certainly a great step towards automatic parallelization for 
heterogeneous architectures, and research in performance portability in 
general.


Those 3 reasons (and there may be others) advocate for a front-end and 
middle-end awareness about OpenCL, not only library stuff, and certainly 
advocate for doing it in GCC rather than anywhere else.


I think the killer argument for GCC support of OpenCL is Larrabee, and 
heterogeneous multicores in general. GCC must see those architectures as 
one single target with multiple sub-targets. This may become a survival 
issue within a couple of years.


A side question is whether GCC should become 
single-source-multiple-target compiler, where a single compilation unit 
can lead to code generated on multiple ISAs. Note that this is not out 
of reach at all, since a short-cut exists, with attributes guarding the 
code generation of some functions or variable declarations, allowing to 
generate code only for a given target at a time.  Several people tried 
it, and it does not require reworking any machine description, although 
multiple runs of cc1/... would still be necessary.


Feedback welcome!

Albert Cohen

Re: GCC & OpenCL ?

[Ross Ridge]

Ross Ridge wrote:
> Oh, ok, that makes a world of difference.  Even with just AMD GPU
> support a GCC-based OpenCL implementation becomes a lot more practical.

Michael Meissner writes:
>And bear in mind that x86's with GPUs are not the only platform of interest

I never said anything about x86's and I already mentioned the Cell.
Regardless, I don't think an GCC-based OpenCL implementation that didn't
target GPUs would be that useful.

Ross Ridge

Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

[Kai Henningsen]

On Sun, Feb 1, 2009 at 04:06, Sean Callanan  wrote:

> We also have a magic argument called FILE that lets you load arguments from
> a file.

That's what @ arguments are for. Which argues for not concatenating arguments.

Would it be a problem to do

-plugin=myplugin -plugin-myplugin-arg1=stuff -plugin-myplugin-someflag ...

(finding /some/path/myplugin.so or C:\some\path\myplugin.dll in the
plugin search path)?

Re: Plugin API Comments

[Tom Tromey]

> "Sean" == Sean Callanan  writes:

>> (3) The -fplugin-arg argument is one way to do arguments.  We do it as
>>   -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:...

Benjamin> I'm a little worried about the colon separator. Windows file
Benjamin> paths may legally have colons. Is there some separator
Benjamin> character (semicolon?)  which is not part of a path on any
Benjamin> platform? Perhaps we shouldn't worry about it since
Benjamin> -rdynamic doesn't work on Windows anyway.

Sean> Agreed.  OS X paths can include semicolons, though.  This is
Sean> something we need to think about.

Rather than invent a new quoting syntax, why not just split the
arguments up?  If each a plugin has a name, you could use that name in
subsequent -f arguments.  E.g., if the name of the plugin in
"plugin.so" is "foo", perhaps:

-fplugin=/path/to/plugin.so -ffoo-arg1=value1 -ffoo-arg2=value2

The actual spelling could be "-fplugin-$NAME-arg" if you think the
above is too likely to clash with already existing (or future)
argument names.

I wanted to mention this idea, but since I know this is an area prone
to bikeshedding I don't intend to argue strongly for it.

Tom

PR 39076 Backport a patch for GCC 4.3

[Ramana Radhakrishnan]

Hi Mark,

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076 appears to be an
reappearance of the failure reported originally at
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html . and detailed
discussion in the thread that ends at
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00907.html .

Is it ok to backport this patch into gcc-4.3 after regression testing?


cheers
Ramana

Re: GCC & OpenCL ?

[Andrew Pinski]

On Tue, Feb 3, 2009 at 2:25 PM, Michael Meissner
 wrote:
> And bear in mind that x86's with GPUs are not the only platform of interest.

Even x86 with the SPRUS engine is a platform of interest for some
companies (not me but you get the idea).

-- Pinski

Re: GCC & OpenCL ?

[Joseph S. Myers]

On Tue, 3 Feb 2009, Ross Ridge wrote:

> Mark Mitchell writes:
> >That's correct.  I was envisioning a proper compiler that would take
> >OpenCL input and generate binary output, for a particular target, just
> >as with all other GCC input languages.  That target might be a GPU, or
> >it might be a multi-core CPU, or it might be a single-core CPU.
> 
> I have a hard time seeing why this would be all that worthwhile.
> Since the instruction sets for AMD, NVIDIA or current Intel GPUs are
> trade scretes, GCC won't be able to generate binary output for them.
> OpenCL is designed for heterogenous systems, compiling for multi-core or
> single-core CPUs would only be useful as a cheap fallback implementation.
> This limits a GCC-based OpenGL implementation to achieving it's primary
> purpose with just Cell processors and maybe Intel's Larrabee.  Is that
> what you envision?  Without AMD/NVIDIA GPU support it doesn't sound all
> that useful to me.

The AMD instruction sets now have public documentation.  Other 
manufacturers may well follow suit, especially if enough people caring 
about free software and open documentation choose which GPU to buy on such 
a basis (which is obviously a personal choice for them).

In any case, public documentation is not required.  There are many 
examples of free software developed by a developer who has documentation 
provided under an NDA that allows the release of free software embodying 
certain information from that documentation (this is common for device 
drivers if there is no manual with just the information relevant for 
device drivers, just an NDA manual with much more internal information 
about the device).  So as per the policy established at 
, a GPU manufacturer 
could provide privately the information required to create a GCC port for 
their GPU without releasing their documentation publically (much as 
releasing that documentation publically would have obvious advantages to 
the community).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC & OpenCL ?

[Michael Meissner]

On Tue, Feb 03, 2009 at 04:37:55PM -0500, Ross Ridge wrote:
> 
> Basile STARYNKEVITCH writes:
> >It seems to me that some specifications
> >seems to be available. I am not a GPU expert, but
> >http://developer.amd.com/documentation/guides/Pages/default.aspx
> >contains a R8xx Family Instruction Set Archictectire document at
> >http://developer.amd.com/gpu_assets/r600isa.pdf and at a very quick
> >first glance (perhaps wrongly) I feel that it could be enough to design &
> >write a code generator for it.
> 
> Oh, ok, that makes a world of difference.  Even with just AMD GPU
> support a GCC-based OpenCL implementation becomes a lot more practical.

And bear in mind that x86's with GPUs are not the only platform of interest.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

Re: GCC & OpenCL ?

[Michael Meissner]

On Tue, Feb 03, 2009 at 09:40:20AM -0800, Chris Lattner wrote:
> 
> On Feb 3, 2009, at 8:48 AM, Mark Mitchell wrote:
> 
> >Andrey Belevantsev wrote:
> >
> >>Obviously, a library is not enough for a heterogeneous system, or
> >>am I missing anything from your description?  As I know, e.g. there  
> >>is
> >>no device-independent bytecode in the OpenCL standard which such a
> >>backend could generate.
> >
> >That's correct.  I was envisioning a proper compiler that would take
> >OpenCL input and generate binary output, for a particular target, just
> >as with all other GCC input languages.  That target might be a GPU, or
> >it might be a multi-core CPU, or it might be a single-core CPU.
> >
> >Of course, OpenCL also specifies some library functionality; that  
> >could
> >be provided in a library that included hand-written assembly code, or
> >was generated by some non-GCC tool.
> 
> That's an interesting and very reasonable approach to start with.   
> However, realize that while this will give you ability to run programs  
> that use some of the OpenCL language extensions, you won't be able to  
> run any real OpenCL apps.  The OpenCL programming model fundamentally  
> requires runtime compilation and the kernel-manipulation library APIs  
> are a key part of that.

Yes, but you need to get to the basic level before you get to the runtime
compilation and kernel manipulation.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

unspec_volatile() RTL template

[raja . saleru]

Hi,

Can anybody explain about the unspec_volatile() rtl template usage, sample
example and the purpose of it.

Thanks and Regards
Raja Saleru

gnu gcc 3.4.6 debug procedure

[raja . saleru]

Hi,

I am using the gcc version 3.4.6. It is cross built for one of the ARM
based target. I would like to build the gcc in debug mode and step by step
debug the code.

The gcc/configure has "-g -O2" option. but if I run through debugger, the
source files of the entire gcc are not visible.

somebody can explain the procedure for gcc debugging ?

Thanks and Regards
Raja Saleru

Re: unspec_volatile() RTL template

[Ian Lance Taylor]

raja.sal...@iap-online.com writes:

> Can anybody explain about the unspec_volatile() rtl template usage, sample
> example and the purpose of it.

unspec_volatile is documented in the gcc internals manual.  There are
many examples of using it in the existing gcc backends.  The purpose
is to permit describing instructions which can not be adequately
expressed in RTL, such as the x86 cld instruction.


> somebody can explain the procedure for gcc debugging ?

http://gcc.gnu.org/wiki/DebuggingGCC


The mailing list gcc@gcc.gnu.org is intended for use by the gcc
developers.  Please consider taking general questions to the mailing
list gcc-h...@gcc.gnu.org.  Thanks.

Ian