On Mar 13, 2014, at 11:36, Eric Botcazou ebotca...@adacore.com wrote:
This fixes a flaw in the mechanism implemented to register modes and types
declared in the back-end with the front-end. The mechanism was implicitly
making the assumption that it is possible to deduce the size of a FP mode
On Feb 6, 2013, at 05:10, Kai Tietz ktiet...@googlemail.com wrote:
this patch fixes an issue about recursice LN_S for mingw-host. The
issue was already addressed by autotools, but an upgrade of version
isn't suitable right now.
For further information see the bug-report PR 52122.
On Mar 17, 2011, at 20:35, H.J. Lu wrote:
- substitutions of likely-spilled regs, reload might die.
+ substitutions of likely-spilled regs, reload might die. Never
+ combine asm statement.
This has to be statements, a plural.
-Geert
On Apr 9, 2012, at 23:03, Mike Stump wrote:
I'd like to remove execute permissions for:
gcc/ada/*.adb
Ok?
Sure. What about *.ads?
-Geert
On Apr 10, 2012, at 1:45, Mike Stump mikest...@comcast.net wrote:
I assume that was a friendly, please feel free to fix *.ads as well.
Yes, sorry for the terse email. I wasn't quite sure if your message implied
there was only an issue with *.adb or not and wasn't in a position to check at
On Jul 23, 2012, at 10:32, Iain Sandoe wrote:
Looks good to me, go ahead, although I'm a bit surprised that you got an
error,
can you clarify what error you got?
IIRC, that the flag was undefined.
If it's important I can revert the fix in my local tree and re-build.
Iaim
No need to do
On Jul 23, 2012, at 10:24, Iain Sandoe wrote:
This patch implements a check in the runtime library that determines whether
the current target supports the atomic primitives up to 64 bits.
If I understand the name of the flag, it looks like an all or nothing for
atomic primitives?
is that
On Jul 23, 2012, at 10:45, Arnaud Charlet wrote:
No, as we agreed and discussed, the flag does NOT have to be defined for all
versions of system.ads, so this is a bug that needs to be fixed (precisely
for the issue raised here: we don't want unknown or new ports to be broken
by default).
On Jul 23, 2012, at 11:21, Geert Bosch wrote:
On Jul 23, 2012, at 10:45, Arnaud Charlet wrote:
No, as we agreed and discussed, the flag does NOT have to be defined for all
versions of system.ads, so this is a bug that needs to be fixed (precisely
for the issue raised here: we don't want
On Nov 19, 2011, at 18:46, Diego Novillo wrote:
Committed to wwwdocs.
BTW, I had taken the liberty to add a link to gcc.gnu.org/wiki
under the header Events. I also removed some 2010 events, as
they seemed stale now. Feel free to change if necessary.
-Geert
On Feb 11, 2012, at 05:37, Eric Botcazou wrote:
The polymorphism pointer/address indeed proves to be problematic in certain
circumstances (e.g. it breaks on m68k, see PR ada/48835). My understanding
is
that using pointers in Ada is heavyweight, hence the choice of an integer for
On Jan 10, 2012, at 14:28, Eric Botcazou wrote:
2012-01-10 Eric Botcazou ebotca...@adacore.com
* gimple.h (gimplify_body): Remove first argument.
* gimplify.c (copy_if_shared): Add DATA argument. Do not create the
pointer set here, instead just pass DATA to walk_tree.
On Jun 27, 2011, at 19:00, David Miller da...@davemloft.net wrote:
V8 can only reorder stores, that's why it only has a 'stbar'
instruction. I'm not so sure I agree with trying to paper over the
fact that someone has compiled code for v8 that's going to run on a v9
cpu.
That's not the
On Jun 27, 2011, at 19:53, David Miller wrote:
I'm trying to find the part of the v8 manual that says there is
a situation where we should use stbar and a ldstub to implement
proper memory barriers. In particular I'm looking in Appendix J,
Programming with the memory models. Where is the
On Jun 27, 2011, at 22:45, David Miller wrote:
From: Geert Bosch bo...@adacore.com
Date: Mon, 27 Jun 2011 22:21:47 -0400
On Jun 27, 2011, at 19:53, David Miller wrote:
Adding a ldstub here is going to be really expensive, on UltraSparc
that can be 36+ cycles even on a cache hit.
Yes
On Apr 19, 2013, at 17:31, Andi Kleen a...@firstfloor.org wrote:
Later on I think it's better to either always use large hash tables
(virtual memory is cheap) or to dynamically size them based on a
estimate of the available types.
That logic doesn't really work for hash tables. Assuming the
16 matches
Mail list logo
