> > for this specific function (vrp_int_const_binop), I'm issuing a
> > warning inside the else-if branch that tests for the overflowed
> > result. I'm unclear why that is a false positive since the result is
> > known to overflow. Could you elaborate?
>
> Well, we use that function to do arith
On Sunday 31 December 2006 16:19, Richard Kenner wrote:
> > If done in unsigned, this won't lead to any optimization, as unsigned
> > arithmetic doesn't have overflows. So, if you write "a - 10" where a
> > is unsigned, the compiler can't assume anything, whereas is a is
> > signed, the compiler ca
> Please does anyone know the answer to the following questions?
>
> 1. The operating system (OS) schedules tasks, but gnat allow us to set
> schedule policies such as Round Robin, then how does gnat tell the OS to
> start doing Round Robin scheduling?
>
> 2. If someone wants to write a new sch
On Tuesday 16 January 2007 16:50, Andrew Haley wrote:
> Roberto Bagnara writes:
> > Andrew Haley wrote:
> > > Roberto Bagnara writes:
> > > >
> > > > Reading the thread "Autoconf manual's coverage of signed integer
> > > > overflow & portability" I was horrified to discover about GCC's
>
Hi Sameer Sinha,
> can any one tell me what is the difference between gcc-ada and
> differnt other compiler for Ada 95 like GNAT GPL, GNAT Pro,
> what is procedure to build only language Ada by using source code og
> gcc-4.1???
they are closely related. There are two groups:
(1) vers
> So we are in better shape than implied above. We have quite
> a reasonable set of stability and regression tests for the
> Ada front end. Given the restrictions on proprietary code
> use, this is about as good as we can do for now. Of course
> it is valuable if people submit more tests to this te
> But Duncan, you were generating a bunch of proprietary
> Ada code recently, if you can get people to be comfortable
> submitting it, possibly in obfuscated form, by all means
> go ahead!
I already started doing this, see
http://gcc.gnu.org/ml/gcc/2006-07/msg00591.html
Duncan.
> Currently for example in fold_sign_changed_comparison we produce
> integer constants that are not inside the range of its type values
> denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example
> consider a type with range [10, 20] and the comparison created by
> the Ada frontend:
>
> i
On Saturday 24 February 2007 14:27:36 Richard Kenner wrote:
> > Sure - I wonder if there is a reliable way of testing whether we face
> > a non-base type in the middle-end. I suppose TREE_TYPE (type) != NULL
> > won't work in all cases... (?)
>
> That's the right way as far as I know.
Note that
> > I noticed while editing gcc files, that there are a lot of *useless*
> > whitespaces at the end of lines or within empty lines, which are getting
> > automatic removed by some *smarter* editors as I am common to use *sigh*.
> > This leads to huge diff files and the real change is getting vei
> in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the
> static chain argument, or NULL. Can someone tell me or reference me to
> what static chain argument is?
It's for nested functions, eg
int parent (int n)
{
int child (int m) { return m * n; }
return child (2);
}
Notice h
On Mon, 2005-03-07 at 10:51 -0500, Robert Dewar wrote:
> Paolo Carlini wrote:
> > Andrew Haley wrote:
> >
> >> F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
> >>
> >>
> > Indeed. My point, basically, is that consistency appear to require the
> > very same behavior for *complex* zer
Hi Chris,
> | Mathematically speaking zero^zero is undefined, so it should be NaN.
> | This already clear for real numbers: consider x^0 where x decreases
> | to zero. This is always 1, so you could deduce that 0^0 should be 1.
> | However, consider 0^x where x decreases to zero. This is always
Hi Robert,
> > It's not true because it's neither true nor false. It's a not well
> > formulated statement. (Mathematically).
>
> I disagree with this, we certainly agree that 0.0 ** negative value
> is undefined, i.e. that this is outside the domain of the ** function,
> and I think normally in
Hi Florian,
> From a mathematical point of view, 0^0 = 1 is the more convenient one
> in most contexts. Otherwise, you suddenly lack a compact notation of
> polynomials (and power series). However, this definition is only used
> in a context were the exponent is an integer, so it's not really
>
Hi Paolo,
> > What we are debating here isn't really maths at all, just the
> > definition which will be most useful and least suprising (and perhaps
> > also what various standards tell us to use).
>
> Also, since we are definitely striving to consistently implement the
> current C99 and C++
Hi Robert,
> Well if you tell me there are people about there implementing cpow
> with log and exp, that's enough for me to decide that Ada should
> continue to stay away (the Ada RM has accuracy requirements that
> would preclude a broken implementation of this kind) :-)
the reference manual all
Hi Robert,
> >>Well if you tell me there are people about there implementing cpow
> >>with log and exp, that's enough for me to decide that Ada should
> >>continue to stay away (the Ada RM has accuracy requirements that
> >>would preclude a broken implementation of this kind) :-)
> >
> >
> > the
> On the one hand, as said above, there is no way of defining 0^0
> using continuity, but on the other hand, many important properties
> remain satisfied if we choose 0^0 = 1 (which is frequently
> adopted, as a convention, by mathematicians). Kahan suggests to
> choose 0^0 = 1.
On Thu, 2005-04-14 at 23:33 +0200, Jason Merrill wrote:
> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote:
> > [Ada standard]
>
> Yep, sounds a lot like C/C++: volatile reads and writes are required to
> have sequential ordering relative to each other, but (outside the c
Hi David,
It looks strange to me that this repository contains these per-gcc
-version auto-generated .inc files; aren't these something that should
just be created at build time?
IIRC I did it this way because to generate these files you need to have the
entire GCC sources, while one of the g
Hi,
It says
// Disable all LTO passes.
(for whatever reason). So try just removing this part - the pass is
already removed.
IIRC it disables passes that run after gimple has been converted to LLVM IR, as
running them would just consume time pointlessly.
Best wishes, Duncan.
Hi Vladimir, thanks for doing this.
The above said about compilation speed is true when GCC front-end is
used for LLVM.
It's not clear to me which GCC front-end you mean. There is llvm-gcc
(based on gcc-4.2) and the dragonegg plugin (the 2.9 version works with
gcc-4.5; the development version
On 07/09/11 17:55, Xinliang David Li wrote:
Why is lto/whole program mode not used in LLVM for peak performance
comparison? (of course, peak performance should really use FDO..)
Assuming Vladimir was using the dragonegg plugin: presumably because it's
a pain: you have to compile everything to a
Why is lto/whole program mode not used in LLVM for peak performance
comparison? (of course, peak performance should really use FDO..)
Thanks for the feedback. I did not manage to use LTO for LLVM as it
described on
http://llvm.org/docs/LinkTimeOptimization.html#lto
I am getting 'file not reco
Hi Basile,
I would like to add destroyable objects into Ggc (the GCC garbage collector,
see files
gcc/ggc*.[ch]).
The main motivation is to permit C++ objects to be garbage collected (I
discussed that
briefly in the Gcc meeting at Google in London): adding destroyable object is a
prerequisite
Hi Gabriel,
I also agree with you that GCC architecture is messy, and that scares newscomer
a lot.
Yes, but the way we improve it isn't, in my opinion, adding more GC.
First we would like to remove complexity, and I do not think we should
start by focusing on storage management until we get
Hi Basile,
But I don't understand how Ggc could be avoided (and I am not sure to
understand how even LLVM can avoid any kind of garbage collection in the
long run).
I doubt LLVM will ever need garbage collection, because the way it is designed
makes memory management easy. I already mentioned
Hi Ludo,
A number of compilers claim to be GCC, without actually being GCC. This
has come to a point where they can hardly be distinguished–until one
actually tries to use them.
this suggests that you shouldn't be testing for GCC, and instead should be
testing for support for particular featu
g that don't support nested
functions, then why bother testing for nested function support? You will
discover the lack of nested function support when your code fails to compile.
Ciao, Duncan.
On 19/01/12 15:39, Ludovic Courtès wrote:
Hi Ducan,
Duncan Sands skribis:
A number of compilers
Hi Ludo,
For ICC, one can test __ICC. For instance, here's what we have in mpfr.h
(for the use of __builtin_constant_p and __extension__ ({ ... })):
#if defined (__GNUC__)&& !defined(__ICC)&& !defined(__cplusplus)
Yeah, but it’s a shame that those compilers define __GNUC__ without
supportin
On 24/01/12 17:32, Joseph S. Myers wrote:
On Thu, 19 Jan 2012, Ludovic Court�s wrote:
It turns out that ICC manages to build a working GCC plug-in, so after
I would say there is some conceptual confusion here (based on this
sentence, without having looked at the autoconf macros you refer to).
On 14/03/10 21:48, Matthias Klose wrote:
On 14.03.2010 13:15, Basile Starynkevitch wrote:
Basile Starynkevitch wrote in
http://lists.debian.org/debian-gcc/2010/03/msg00047.html
Now, one of the issues about MELT & Debian packaging is the fact that
melt-runtime.c (the source of melt.so plugin) u
Hi Basile,
I tend to be quite happy with the idea of dragonegg being a good GCC
plugin, since it is a good illustration of the plugin feature.
I think Jack wasn't suggesting that dragonegg should be changed to not be
a plugin any more. I think he was suggesting that it should live in the gcc
Hi Steven,
I think Jack wasn't suggesting that dragonegg should be changed to not be
a plugin any more. I think he was suggesting that it should live in the gcc
repository rather than the LLVM repository.
So, no offense, but the suggestion here is to make this subversive
(for FSF GCC) plugin
Hi Eric,
As for "negating the efforts of those working on the middle ends and back
ends", would you complain if someone came up with a new register allocator
because it negates the efforts of those who work on the old one? If LLVM
is technically superior, then that's a fact and a good thing, no
Hi David,
The Graphite project and the various GCC targets participate in GCC
development. Helping fix GCC bugs affecting those features, supports
and grows the GCC developer base. There needs to be some mutualistic
relationship. I don't see members of the LLVM community arguing that
they sho
Hi Grigori,
Hope my question will not completely divert the topic of this discussion -
just curious what do you mean by better code? Better execution time, code size,
compilation time?..
this depends on each persons needs of course. The dragonegg plugin makes it
easy for people to see if the
Hi Robert,
b) better behavior for undefined cases
this is one of the problems with using LLVM with the Ada front-end. LLVM makes
pretty aggressive deductions when it sees undefined behaviour, which can result
in (for example) validity checks being removed exactly in the cases when they
are mo
Goes away is a bit strong. In practice, front ends know about their back
ends and are tuned in various ways for things to work well.
Likewise, back-ends are tuned for their front-ends.
Ciao,
Duncan.
Hi Jonathan,
egcs code was always license-compatible with GCC and was always
assigned to the FSF
The difference is quite significant.
both dragonegg and LLVM are license-compatible with GCC. The dragonegg
code is licensed under GPLv2 or later, while LLVM is licensed under the
University of I
Hi Steven,
FWIW, this sounds great and all... but I haven't actually seen any
comparisons of GCC vs. LLVM with DragonEgg. A search with Google
doesn't give me any results.
Can you point out some postings where people actually made a
comparison between GCC and LLVM with DragonEgg?
I gave some
Hi Manuel,
PS: On the other hand, I think that modifying GCC to suit the purposes
of dragonegg or LLVM is a *bad* idea.
my policy has been to only propose GCC patches that are useful to GCC itself.
Well, yesterday I broke this rule and posted a patch that was only of interest
to dragonegg, but
Hi Vladimir, thank you for doing this benchmarking.
Only SPECIn2000 for x86_64 has been compiled fully successfully by
dragonegg. There were a few compiler crashes including some in LLVM
itself for SPECFP2000 and for SPECINT2000 for x86.
Sorry about that. Can you please send me preprocessed c
Hi Vladimir,
Dragonegg does not work with -flto. It generates assembler code on which
gas complaints (a lot of non-assembler code like target data-layout
which are not in comments).
actually it does work with -flto, in an awkward way. When you use -flto
it spits out LLVM IR. You need to use
$ /usr/bin/g++-4.5 -O0 -g -flto -o kfinddialog.o -c kfinddialog.ii
../../kdeui/findreplace/kfinddialog.cpp: In member function ‘RegExpAction’:
../../kdeui/findreplace/kfinddialog.cpp:445:9: internal compiler error: tree
check: expected class ‘type’, have ‘declaration’ (function_decl) in
gen_type_d
Plugin support is enabled by default if it works.
I can confirm this - on my linux box I don't have to explicitly
specify --enable-plugin.
Ciao,
Duncan.
Hi,
> I am looking to transform a tree in SSA form into a representation of it in C.
you can try using LLVM (which uses an IR in SSA form): it has a "C" backend
that squirts out C equivalent to the IR. The resulting C is not very nice to
read though.
Ciao,
Duncan.
PS: This is a cute way of ge
Hi,
> Sorry, I missed to mention that I used an additional option -mpc64 for
> 32-bit GCC4.4. It is not possible to generate SPECFP2000 expected
> results by GCC4.4 without this option. LLVM does not support this
> option. And this option can significantly improve the performance. So
> 32-
Hi Richard,
> -mpc64 sets the x87 floating point control register to not use the 80bit
> extended precision. This causes some x87 floating point operations
> to operate faster and there are no issues with the extra roundings you
> get when storing an 80bit precision register to a 64bit memory loc
Hi,
Some time ago, there was a discussion about integrating LLVM and GCC
[1]. However, with plugin infrastructure in place, could LLVM be
plugged into GCC as an additional optimization plugin?
I plan to start working on an llvm plugin any day now.
Ciao,
Duncan.
Hi Rafael,
There was some talk about it on #gcc. A plugin should be able to see
all the GCC IL, so it should be able to convert it to LLVM. Keeping
the current llvm-gcc interface would require some hacks
*) The plugin will have to call exit to keep gcc's code generation from running.
this wou
Hi,
I don't know is it big or not to have such time spend in RTL parts. But I
think that this RTL part could be decreased if RTL (magically :) would have
smaller footprint and contain less details.
Bah, no wand... :-)
I noticed while working on the dragonegg plugin that replacing gimple ->
On 01/06/10 10:03, Paolo Bonzini wrote:
On 05/31/2010 12:30 PM, 徐持恒 wrote:
I think compiler can and should be host independent, like LLVM.
It is. Changes to code generation depending on the host are considered
to be serious bugs, and have been long before LLVM existed.
Perhaps 徐持恒 meant targ
Hi PeteGarbett,
I see nothing in the GCC 4.5 release notes about
plugin support being language specific, and yet if I using the treehydra
plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra
notes), I get this
I use plugins with Ada all the time, with gcc-4.5, and it works
Hi Basile,
Assuming a plugin (e.g. MELT) add a new pragma using PLUGIN_PRAGMAS, is
this pragma usable from Ada or Fortran code?
I am not very familiar with Ada or Fortran. I believe Ada has some
syntax for pragmas -but do Ada pragma have the same API inside GCC
plugins as C or C++ pragmas?- and
Hi Basile,
Assuming a plugin (e.g. MELT) add a new pragma using PLUGIN_PRAGMAS, is
this pragma usable from Ada or Fortran code?
I am not very familiar with Ada or Fortran. I believe Ada has some
syntax for pragmas -but do Ada pragma have the same API inside GCC
plugins as C or C++ pragmas?- and
A week and a day after the LLVM 2.8 release, I'm pleased to announce
the availability of the corresponding dragonegg release. Get it while
it's hot! http://dragonegg.llvm.org/#gettingrelease
Duncan.
Hi Luke,
a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a
predefined library unit
it looks like you get this error when the compiler can't find a file that it
thinks forms part of the Ada library (this is determined by the name, eg: a
package Ada.XYZ is expected to be part o
Hi Laurent,
On Wednesday 22 February 2006 12:34, Laurent GUERBY wrote:
> On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > > > type T1 is range 0 .. 127;
> > > > > > -- Compiler will choose some type for T'Base, likely to be
> > > > > > -128..127
> > > > > > -- but could be In
> This code only works for one-complement machines, since it assumes a
> symmetric range for Int. It breaks when UI_To_Int returns Integer'First, as
> it did in this case. When it does, the abs produces an erroneous result
> (since checking is disabled). So it almost doesn't matter what it puts
On Tuesday 14 March 2006 03:16, Waldek Hebisch wrote:
> Jeffrey A Law wrote:
> > On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> >
> > > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > > allowed by given type.
> > As long as you're *absolutely* clear that a variabl
> > I think that it is easy for back end to make good use of
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
> >
> > x := y + z * w;
> >
> > where variables y, z and w have values in the interval [0,7] and
> > x have values in [0,1000]. Pascal converts the above to the
> > foll
On Tuesday 21 March 2006 17:15, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
&
On Tuesday 21 March 2006 18:01, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
>
> > Should it be? I was surprised to see that all ranges are initialised
> > to VR_VARYING in the vrp pass, since many types have natural ranges
> > associate
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
&
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
&
On Thursday 23 March 2006 11:31, Eric Botcazou wrote:
> > Hi Jeff, this seems to work nicely - thanks again.
>
> Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64.
Which ones?
Ciao,
Duncan.
On Thursday 23 March 2006 17:14, Andrew Pinski wrote:
>
> On Mar 23, 2006, at 11:10 AM, Richard Guenther wrote:
> >
> >
> > Well - we could hack a new type attribute to specify min/max values...
>
> Or maybe try to using C++ instead since C++ rules for enums are
> different
> than C :).
Well,
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
&
Hi Jeff,
> > By the way, I hacked tree-vrp to start all value ranges for INTEGRAL_TYPE_P
> > variables to [TYPE_MIN, TYPE_MAX]. It certainly helps with eliminating many
> > Ada range checks. Maybe the compiler will even bootstrap :)
> The thing to check will be compile-time performance -- in gen
Hi Jeff,
On Monday 27 March 2006 21:00, Jeffrey A Law wrote:
> On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
>
> > Start by looking at tree-vrp.c:infer_value_range.
> I'm not so sure this is the best place to start.
it seems a good place for adding ASSERT_EXPRs on function return
value
Hi Jeff, thanks for the info.
> > I agree that this kind of special casing by the middle-end is all
> > wrong - the front-end should do it.
> I'd disagree. While it may at first seem useful to have ASSERT_EXPRs
> live through the entire optimization pipeline, they're actually going
> to get in th
On Wednesday 29 March 2006 23:28, Tom Tromey wrote:
> >>>>> "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes:
>
> Duncan> That still leaves the problem of how the Ada front-end tells the
> Duncan> middle-end that a variable is known to be
> > On irc today we were discussing handling 'this' in gcj. We can add an
> > attribute to the argument to mark it as non-null... but strangely
> > there doesn't seem to be a way to mark other local variables as
> > known-non-null -- a curious deficiency.
> It seems to me that for other locals tha
I've started adding a bunch of regression tests to the
Ada dejagnu testsuite (see below for the current state).
I've accumulated these over several years, and almost all
of them have been reported in gcc bugzilla (not many of
these) or to ACT (the funny package names are ACT tracking
numbers).
How
> We are working on a project to add fixed-point arithmetic support to GCC.
> A GCC project description page is available here
> http://gcc.gnu.org/wiki/FixedPointArithmetic
> and we will create a GCC branch in the near future. If you have
> any suggestions or comments, please respond.
I expect
On Friday 22 September 2006 09:38, Arnaud Charlet wrote:
> > > We are working on a project to add fixed-point arithmetic support to GCC.
> > > A GCC project description page is available here
> > > http://gcc.gnu.org/wiki/FixedPointArithmetic
> > > and we will create a GCC branch in the near futur
> I am writing a new GCC front end. One of the features provided by my
> language (CIL) is explicit field layout and size for records.
>
> I don't know if any other languaje supported by GCC provides this
> feature. If that's the case, please point me to it so that I can see how
> to
On Saturday 23 September 2006 17:08, Robert Dewar wrote:
> Duncan Sands wrote:
> >> We are working on a project to add fixed-point arithmetic support to GCC.
> >> A GCC project description page is available here
> >> http://gcc.gnu.org/wiki/FixedPointArithmetic
Hi David,
> At any rate, if you want to bash the strategies of the GNU project,
these lists are the wrong place to go. Try doing it on the Clang list
though I am skeptical that they do not have better things to do as well.
the Clang list is for technical rather than political discussion, as y
On 23/01/14 12:42, Michael Witten wrote:
On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote:
the... list is for technical rather than political discussion
That's just it; that's the whole point.
The *political* aspects are dictating the *technical* aspects.
Not for clang t
Hi Vladimir,
o Comparing LLVM and GCC on Fortran benchmarks. LLVM has no fortran FE and just
quietly call system GCC. So comparison of LLVM and GCC on Fortran benchmarks
means comparison of system GCC and a given GCC.
a few people are working on LLVM based Fortran compilers. I'm not sure how
Hi,
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We build stage1 with the C compiler and then build
stages 2 and 3 with the C++ compiler.
OK.
However, this means that plug-ins must now be built with g++, except
w
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.
Given the above assumption, now I doubt the necessity of accessor
macros or C++ getter/setter method.
Is "tree->code" more dir
Hi Vladimir, thanks for these numbers.
...
Therefore I had to use *Dragonegg* (a GCC plugin which uses LLVM
backend instead of GCC backend) for generation of Fortran benchmarks
by LLVM.
...
I believe such progress is achieved mostly because of a *new RA*
introduced in LLVM 3.0 a
Hi,
> I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
> size have increased significantly (about 40%!), comparing with
> old 4.0.0 when using the -Os option. Same code, same compile-
> and configuration-time options. Binutils are differ
> (2.16.1 vs 2.17.50), though.
what LLVM versi
> LLVM? From what I know llvm-gcc is an alternative for gcc. Are any
> parts of LLVM used in current GCC? None of what I know.
Sorry, I confused my mailing lists and thought you had asked on
the LLVM mailing list. This explains why I didn't understand
your questions :)
Sorry about the noise,
Du
Hi,
> 4.2.3 only failed c380004, c761007, and c953002.
c380004 can be considered to be an expected failure.
It also fails on x86-linux, and this is normal because
the code produced by the front-end (gcc-4.2) can't possibly pass.
Best wishes,
Duncan.
> One of the big changes is that we now recommend the GCC 4.2-based
> front-end,
Another is that it supports Ada (32 bit x86 on linux only for the moment)
and Fortran to some extent. I'm currently adding build instructions for
these two languages to http://llvm.org/docs/CFEBuildInstrs.html (sho
> Another is that it supports Ada (32 bit x86 on linux only for the moment)
> and Fortran to some extent. I'm currently adding build instructions for
> these two languages to http://llvm.org/docs/CFEBuildInstrs.html (should
> be up in a day or two). The release notes detail what works and what
>
>Are there any specific plans for moving llvm-gcc from the
> gcc 4.2 to the gcc 4.3 code base?
I plan to port llvm-gcc to gcc head, since I'm interested in the
Ada front-end and the Ada support in gcc-4.4 is much better than
in gcc-4.2. However I can't say when this will happen, since I
don't
Building gcc from svn today I see the following:
prj-nmsc.adb: In function ‘Prj.Nmsc.Check_Naming_Schemes’:
prj-nmsc.adb:3272: warning: ‘Casing’ may be used uninitialized in this function
...
g-socket.adb: In function ‘GNAT.SOCKETS.SEND_SOCKET’:
g-socket.adb:1786: warning: ‘SIN’ is used uninitiali
> > However if GPLv3 is such a huge issue
> > at Apple, it does make one wonder if llvm will ever see a gcc front-end
> > newer
> > than the current 4.2 one.
>
> The LLVM folks are writing a new frontend anyhow. In the future they
> presumably plan to stop using the gcc frontend. gcc's code is
Hi Tomash,
> moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O0 mmap.c -o mmap
> moonlight:/tmp$ ./mmap
> GCC is the best compiler ever!
> moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O1 mmap.c -o mmap
> moonlight:/tmp$ ./mmap
> Segmentation fault
I don't see this with gcc 4.1
95 matches
Mail list logo
