Hook in and discuss
http://gcc.gnu.org/ml/gcc/2010-11/msg00232.html
Ian Lance Taylor schrieb:
Georg Johann Lay writes:
Suppose an backend implements some unspec_volatile (UV) and has a
destinct understanding of what it should be.
If other parts of the compiler don't know exactly what to do, it's a
potential source of trouble.
- "May I schedule across the un
Implementation as outlined as in
http://gcc.gnu.org/ml/gcc/2010-11/msg00222.html
Georg Johann Lay writes:
> Suppose an backend implements some unspec_volatile (UV) and has a
> destinct understanding of what it should be.
>
> If other parts of the compiler don't know exactly what to do, it's a
> potential source of trouble.
>
> - "May I schedule across the unspec_volatile (UV)
Suppose an backend implements some unspec_volatile (UV) and has a
destinct understanding of what it should be.
If other parts of the compiler don't know exactly what to do, it's a
potential source of trouble.
- "May I schedule across the unspec_volatile (UV) or not?"
- "May I move the UV from
Georg Johann Lay writes:
> Is there a policy/agreement on how to deal with vendor specific dwarf?
I think we're more or less happy to generate GNU specific DWARF where
necessary, although the general rule is to try to get it into the
standard.
As far as I know we don't currently generate DWARF
Alain Ketterlin writes:
> When compiling at -O2 and -O3 optimization, I've found several
> instances of routines ending with:
>
> retq
> jmp
>
> with no branch pointing to the jmp instruction. Is there any specific
> reason for such code? Is there a way to avoid this?
>
> This is gcc 4.4.5, as i
Is there a policy/agreement on how to deal with vendor specific dwarf?
When compiling at -O2 and -O3 optimization, I've found several instances
of routines ending with:
retq
jmp
with no branch pointing to the jmp instruction. Is there any specific
reason for such code? Is there a way to avoid this?
This is gcc 4.4.5, as installed on Ubuntu 10.10, compiling t
On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
> Currently we build the Java frontend and libjava by default. At the GCC
> Summit we raised the question of whether should turn this off, thus only
> building it when java is explicitly selected at configure time with
> --enable-languages
Snapshot gcc-4.5-2010 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-2010/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Nov 10, 2010 at 01:00:49PM +0100, David Brown wrote:
> Would it be possible to use the named address space syntax to
> implement reverse-endian data? Conversion between little-endian and
> big-endian data structures is something that turns up regularly in
> embedded systems, where you migh
roy rosen writes:
> If I have two insns:
> r2 = r3
> r3 = r4
> It seems to me that the dependency analysis creates a dependency
> between the two and prevent parallelization. Although there is a
> dependency (because of r3) I want GCC to parallelize them together.
> Since if the insns are process
Diego Novillo writes:
> I believe that Ian Taylor had some tutorial notes on writing front
> ends. Ian, am I dreaming again?
The ntoes are in my summit paper which can be found at
http://gcc.gnu.org/wiki/summit2010 . The paper is "The Go frontend for
GCC."
Ian
Nice. Thanks for doing this. If it's not already there, could you
add a link to this in http://gcc.gnu.org/wiki/GettingStarted ?
Sure, Phil (Herron) and I could post it there. Ideally, we should also
have a more-or-less thorough documentation in the gcc internals document
about howto im
On Thu, Nov 11, 2010 at 10:26, Andi Hellmund wrote:
> Hey Tom,
>
>> You need to define a lang_tree_node type, even if its empty. See
>> the lto frontend example.
>
> You could also look at this site
> (http://code.redbrain.co.uk/cgit.cgi/gcc-dev/tree/gcc/gcalc?h=documentation).
Nice. Thanks for
If I have two insns:
r2 = r3
r3 = r4
It seems to me that the dependency analysis creates a dependency
between the two and prevent parallelization. Although there is a
dependency (because of r3) I want GCC to parallelize them together.
Since if the insns are processed together the old value of r3 is
Hey Tom,
You need to define a lang_tree_node type, even if its empty. See
the lto frontend example.
You could also look at this site
(http://code.redbrain.co.uk/cgit.cgi/gcc-dev/tree/gcc/gcalc?h=documentation).
It contains the front-end code for a very simple front-end showing the
general/ex
On Thu, Nov 11, 2010 at 09:47, Merrick, Thomas
wrote:
> libbackend.a(coverage.o):(.rodata+0x20): undefined reference to
> `gt_ggc_mx_lang_tree_node'
> libbackend.a(coverage.o):(.rodata+0x24): undefined reference to
> `gt_pch_nx_lang_tree_node'
> libbackend.a(dbxout.o):(.rodata+0x180): undefined
On Thu, Nov 11, 2010 at 3:47 PM, Merrick, Thomas
wrote:
> I would like to resurrect the PL/1 frontend which appears to have stopped
> development about 3 years ago. I plan to start with the preprocessor, which
> is a PL/1 subset interpreter.
>
> First of all, is this the correct list to ask que
I would like to resurrect the PL/1 frontend which appears to have stopped
development about 3 years ago. I plan to start with the preprocessor, which is
a PL/1 subset interpreter.
First of all, is this the correct list to ask questions about writing a
frontend? I plan on using GCC 4.5.1 and m
On 11/11/2010 10:26, Georg Johann Lay wrote:
David Brown schrieb:
On 09/11/10 18:45, Georg Lay wrote:
David Brown schrieb:
...
May I say I think it's great that you are looking into this? Program
space access on the AVR was the first thing I thought of when I heard of
the concept of named ad
David Brown schrieb:
> On 09/11/10 18:45, Georg Lay wrote:
>> David Brown schrieb:
...
>>> May I say I think it's great that you are looking into this? Program
>>> space access on the AVR was the first thing I thought of when I heard of
>>> the concept of named address spaces in C.
>>
>> It's grea
./config-guess:
i686-pc-linux-gnu
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/opt/gcc
Thread model: posix
gcc version 4.
24 matches
Mail list logo
