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)
@@ -575
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 ju
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 effect.
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,
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,
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 inlini
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
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 pe
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 com
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 a
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 function
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 executing
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
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: _Z11fanc
Hi Gabriel,
it defines fancy_abort. Not wrapping system.h in extern C results in
undefined symbol: _Z11fancy_abortPKciS0_
when loading the plugin.
If you want fancy_abort to have a C language specification, that is
what you should declare as such.
my code isn't using fancy_abort directly,
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. */
static
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,
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,
b
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
sinc
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 and
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 i
PS: That said, I have to admit that using void* for builtins does cover the
most important cases.
Hi Arnaud,
--- s-atopri.adb(revision 189768)
+++ s-atopri.adb(working copy)
@@ -31,6 +31,58 @@
package body System.Atomic_Primitives is
+ --
+ -- Lock_Free_Read_8 --
+ --
...
+ --
+ -- Lock_Free_Read_16
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 ever
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 s
Hi Artem,
On 31/08/11 10:27, Artem Shinkarov wrote:
On Wed, Aug 31, 2011 at 12:51 AM, Chris Lattner 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 could look into the w
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 proc
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
+
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 side.
===
--- gcc/cp/ChangeLog(revision 173485)
+++ gcc/cp/ChangeLog(working copy)
@@ -1,3 +1,11 @@
+2011-05-31 Duncan Sands
+
+ Backported from 4.6 branch
+ 2011-03-09 Martin Jambor
+
+ PR tree-optimization/47714
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 as
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
ob
Hi Eric, this looks like a nice improvement. I noticed this mysterious undef
though - what is it for?
+#undef MOVE_FROM_FIELD_LIST_TO
Ciao, Duncan.
Hi Eric,
Not clear what kind of answer you're expecting. To cancel the previous define?
I somehow failed to see the define. Sorry for the noise.
Ciao, Duncan.
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
Ping?
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 *exp);
it is declared as
double frexp(int *exp, double x);
This is fairly
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
Hi Tobias,
I do, so that's not a problem. By the way I just noticed that the arguments to
the scalbn functions also seem to be the wrong way round:
here's a gcc-4.5 patch which fixes: (1) the comment for fntype[2], (2) the
prototypes for the frexp family and (3) the prototypes for the scalbn f
Hi Tobias,
here's a gcc-4.5 patch which fixes: (1) the comment for fntype[2], (2) the
prototypes for the frexp family and (3) the prototypes for the scalbn family.
I checked all uses of all of the function types declared here and all the rest
seem to be correct. I also took a look at an example
Hi Basile,
By the way, this patch is enough for the MELT plugin (which probably
is the only plugin needing GTY).
the dragonegg plugin also uses GTY, but only in a very mild way.
Ciao, Duncan.
/ChangeLog
===
--- gcc/ChangeLog (revision 172166)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2011-04-08 Duncan Sands
+
+ * tree.c (array_type_nelts): Bail out if TYPE_MAX_VALUE not set.
+
2011-04-08 Anatoly Sokolov
* doc/tm.texi.in (ASM_
On 09/04/11 17:45, Richard Guenther wrote:
On Sat, Apr 9, 2011 at 1:22 PM, Duncan Sands 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. The array type in
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 so
46 matches
Mail list logo
