Hi Pierre-Marie, is this really a good idea? If a directory has millions of
files in it (rare, but I've seen it) this may consume a lot of memory. Also, if
using a slow medium like a network file system, reading the entire directory
contents may take a long time. Finally, you aren't really
On 09/26/2017 12:17 PM, Eric Botcazou wrote:
By the way, why not always do this "inlining", even when not optimizing?
Because this generates more bloated code and inferior debugging experience.
This is a trick question, because when you answer "because XYZ" I will then
reply "but XYZ is a
Hi Arno,
it looks like this is in essence inlining the run-time library
routine. In which case, shouldn't you only do it if inlining is
enabled? For example, it seems rather odd to do this if
compiling with -Os.
Actually, measurements showed that this instance of inlining is a
win for both
Hi Pierre-Marie,
On 09/26/2017 11:30 AM, Pierre-Marie de Rodat wrote:
On 09/25/2017 02:47 PM, Duncan Sands wrote:
it looks like this is in essence inlining the run-time library routine. In
which case, shouldn't you only do it if inlining is enabled? For example, it
seems rather odd to do
Hi,
On 09/25/2017 10:54 AM, Pierre-Marie de Rodat wrote:
This patch improves the performance of the code generated by the compiler
for attribute Image when applied to user-defined enumeration types and the
sources are compiled with optimizations enabled.
it looks like this is in essence
Hi,
On 09/25/2017 10:47 AM, Pierre-Marie de Rodat wrote:
The monotonic clock epoch is set to some undetermined time
in the past (typically system boot time). In order to use the
monotonic clock for absolute time, the offset from a known epoch
is calculated and incorporated into timed delay and
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 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
Hi Eric,
On 23/01/16 10:25, Eric Botcazou wrote:
I think we was inlining them with LTO until I installed the patch. Most of
time DECL_STRUCT_FUNCTION == NULL for WPA and thus the original check
testing the flags was disabled. We did not update the EH coddegen during
inlining, so probably we
Hi Arnaud,
On 12/11/15 12:06, Arnaud Charlet wrote:
This change refines the use of the "volatile hammer" to implement the advice
given in RM 13.3(19) by disabling it for object overlays altogether. relying
instead on the ref-all aliasing property of reference types to achieve the
desired
Hi Arnaud,
Index: exp_util.adb
===
--- exp_util.adb(revision 223476)
+++ exp_util.adb(working copy)
@@ -204,6 +204,13 @@
when others = null;
end case;
+ -- Nothing to do for the identifier in
Hi Arnaud,
On 29/07/14 16:02, Arnaud Charlet wrote:
If a procedure or entry has an formal out-parameter of a null-excluding access
type, there is no check applied to the actual before the call. This patch
removes a spurious access check on such parameters on entry calls.
Compiling and
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
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
On 23/01/14 12:42, Michael Witten wrote:
On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands baldr...@free.fr 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
Hi Arnaud,
On 14/10/13 15:29, Arnaud Charlet wrote:
It is now possible to import C++ exceptions and to handle it.
...
Index: exp_prag.adb
===
--- exp_prag.adb(revision 203544)
+++ exp_prag.adb(working copy)
@@
Hi Dehao,
On 31/05/13 00:47, Dehao Chen wrote:
This patch makes more strict check of call args to make sure the
number of args match.
Bootstrapped and passed regression tests.
did you thoroughly test Fortran? The Fortran front-end has long had an
unfortunate tendency to eg declare a
Hi Jakub, I actually committed this patch to mainline earlier today, as it is
trivial, enables my own plugin (dragonegg) to compile against gcc-4.8, and
according to the PR makes some other plugins work with gcc-4.8 too. I will
backport it to the gcc-4.8 branch if no-one objects. But maybe you
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
Hi Arnaud,
The natural way to import a builtin that returns void * is to use
System.Address in Ada, which is in fact an integral type.
how about doing this for formal arguments too and not just the return type?
This would improve optimization by LLVM of calls to standard library functions
Hi Tristan,
On 16/07/12 15:17, Tristan Gingold wrote:
On Jul 16, 2012, at 3:16 PM, Duncan Sands wrote:
Hi Arnaud,
The natural way to import a builtin that returns void * is to use
System.Address in Ada, which is in fact an integral type.
how about doing this for formal arguments too
Hi Tristan,
indeed, for two years already. Is there any reason not to do this for all
functions, rather than just limiting it to builtins?
I don't understand what do you mean. We need to do this implicit conversion
for builtins because they are known by the compiler. Which other functions
Hi Tristan,
Ah, what you want is the use of 'void *' for System.Address.
We didn't choose that because the semantic of System.Address (which includes
arithmetic on the whole address space) doesn't match the void * one.
void* arithmetic of this kind exists, it's a gcc extension to C :)
But,
Hi Tristan,
Ah, what you want is the use of 'void *' for System.Address.
We didn't choose that because the semantic of System.Address (which includes
arithmetic on the whole address space) doesn't match the void * one.
void* arithmetic of this kind exists, it's a gcc extension to C :)
The
PS: That said, I have to admit that using void* for builtins does cover the
most important cases.
Hi,
If ENABLE_BUILD_WITH_CXX is defined, then GCC itself is built with C++,
and we want a C++ signature for functions. If it is not defined, then
GCC itself is not built with C++, and we want (and must have) a C
signature.
I suppose we would decide that fancy_abort always uses a C signature,
My plugin is written in C++. When including headers from gcc-4.6 it wraps them
in 'extern C' to prevent name mangling. Some of the plugin headers include
gcc/system.h which includes the C++ header cstring if it detects the use of a
C++ compiler. As a result cstring routines included this way
Hi Richard,
Uh, I don't think we should do that. Why do we include cstring here anyways?
Ian - you added this include in rev. 167764, I don't think that was proper.
But I'm not sure wrapping a system.h include inside extern C from a C++
plugin is proper either ...
since the plugin needs to
Hi Richard,
As system.h is supposed to only include system headers and do nothing
else it has to be prepared to be included from C++ already, so no extern C
wrapping should be necessary for it.
it defines fancy_abort. Not wrapping system.h in extern C results in
undefined symbol:
Hi Gabriel,
Richard just reminded me that we have two fancy_aborts.
Could you tell which one your code is indirectly using?
the one installed as plugin/include/system.h, which seems to be
gcc/include/system.h. It is used for example in tree.h here:
/* Advance to the next argument. */
Hi Gabriel,
Richard just reminded me that we have two fancy_aborts.
Could you tell which one your code is indirectly using?
the one installed as plugin/include/system.h, which seems to be
gcc/include/system.h.
OK. I think that declaration has to have the C language spec.
Would you prepare
Hi Simon,
Hide all uses of __float128 from Clang.
Brackets _GLIBCXX_USE_FLOAT128 with #ifndef __clang__. Clang does not
currently support the __float128 builtin, and so will fail to process
libstdc++ headers that use it.
if one day clang gets support for this type, won't this still turn
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
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
Hi Eric,
Can you try to extract a testcase (assuming it's just a single case?).
We shouldn't
warn for layout-compatible types (but we may do so if for example struct
nesting differs).
It's more basic than that: for example, we map pointers on the C side to
addresses (integers) on the Ada
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
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
supporting
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
Hi Ludo, I didn't really get it. Why do you want to know whether the compiler
is GCC or not? Presumably because you have several versions of your code,
one version using GCC feature XYZ and the other not using XYZ. If so, the
logically correct (but maybe impractical) approach is to test if the
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
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,
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
Hi Arnaud,
--- exp_ch5.adb (revision 179894)
+++ exp_ch5.adb (working copy)
@@ -3458,6 +3458,20 @@
Statements = Statements (N,
End_Label = End_Label (N)));
+
+ -- The loop parameter's entity must be removed from the loop
+
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
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
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
Hi Arnaud,
Now that gnatmake supports -j0, it's possible to speed up the build of
gnattools during GNAT build by using gnatmake -j0 instead of gnatmake.
This is useful since gnattools is the only target which isn't parallelized
in the Makefile before this change.
this means using as many
Hi Artem,
On 31/08/11 10:27, Artem Shinkarov wrote:
On Wed, Aug 31, 2011 at 12:51 AM, Chris Lattnerclatt...@apple.com wrote:
On Aug 30, 2011, at 10:01 AM, Artem Shinkarov wrote:
The patch at the moment lacks of some examples, but mainly it works
fine for me. It would be nice if i386 gurus
Hi Arnaud, this is a great feature. How does it handle unchecked unions? Will
it warn if you write to a field but only read the value via a different field?
Ciao, Duncan.
GNAT did not issue a warning when assigning to a part of an object, and not
referencing the object later on. Now it does
Hi Eric,
This is the usual problem of volatile accesses not preserved under (heavy)
optimization. In Ada, we can put pragma Volatile on components of composite
types without putting it on the enclosing type itself,
if T is a non-volatile composite type with volatile components, and O is an
===
--- gcc/cp/ChangeLog(revision 173485)
+++ gcc/cp/ChangeLog(working copy)
@@ -1,3 +1,11 @@
+2011-05-31 Duncan Sands baldr...@free.fr
+
+ Backported from 4.6 branch
+ 2011-03-09 Martin Jambor mjam...@suse.cz
+
+ PR
On 31/05/11 08:39, Jakub Jelinek wrote:
On Tue, May 31, 2011 at 08:35:35AM +0200, Duncan Sands wrote:
The following patch backports the one-line fix for PR47714 from the 4.6 branch
to the 4.5 branch. I hit this while working on the dragonegg plugin. OK to
apply?
Yes.
Thanks. Applied
===
--- gcc/ChangeLog (revision 172166)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2011-04-08 Duncan Sands baldr...@free.fr
+
+ * tree.c (array_type_nelts): Bail out if TYPE_MAX_VALUE not set.
+
2011-04-08 Anatoly Sokolov ae...@post.ru
On 09/04/11 17:45, Richard Guenther wrote:
On Sat, Apr 9, 2011 at 1:22 PM, Duncan Sandsbaldr...@free.fr wrote:
I recently changed the dragonegg plugin to use array_type_nelts, and just
got
sent a Fortran testcase that shows that array_type_nelts can crash on array
types coming from Fortran.
Hi Tobias,
Pong. It helps to send Fortran patches also to fortran@ ...
indeed :)
On 30/03/11 16:43, Duncan Sands wrote:
While working on the dragonegg plugin I noticed that the Fortran front-end
declares frexp with the parameters the wrong way round. Instead of
double frexp(double x, int
is a patch (as far
as I can see fntype[4] is only used in declaring the frexp family of functions).
Bootstraps and has no impact on the Fortran testsuite (tested on mainline). OK
to apply on mainline and the 4.5 and 4.6 branches?
Proposed fortran/Changelog entry:
2011-03-30 Duncan Sands baldr
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 of
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 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?-
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?-
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
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
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.
checks pockets...
Bah, no wand... :-)
I noticed while working on the dragonegg plugin that
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 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
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
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,
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
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, not
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
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
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
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)
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
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-bit
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
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
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 so
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
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
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
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
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.
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 version
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,
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 or
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 how
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 veiled. 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 having
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:
if
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)
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 test
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.
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
miscompilation of
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
1 - 100 of 129 matches
Mail list logo
