Re: [Ada] Fix PR ada/51483
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 from its precision and alignment; that's wrong in the general case, although exceptions to the rule are quite rare (typically for an IEEE extended mode). Thanks, Eric! -Geert
Re: [PATCH 6/9] Add --param tunables for the initial size of the type merging hash tables
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 hash keys as close to random (as they should be), there is no locality of reference, so most/all of the hash table will be part of the working set: hash tables don't just use virtual memory, they use real memory. A very sparsely populated hash table may end up wasting most of each VM page to just store a few hashed values. Bad for locality, and bad for performance. -Geert
Re: [patch libada]: PR target/52122
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. ChangeLog libada/ PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Patch see at http://gcc.gnu.org/bugzilla/attachment.cgi?id=29176 OK. -Geert
Re: [Ada] Lock-free implementation of protected objects
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 that. Indeed, the flag must be defined for all versions of system.ads. Please apply the patch, it really seems to be just an oversight. I'd consider this could even have been fixed under the obvious rule. Thanks very much, Iain! -Geert
Re: [Ada] Lock-free implementation of protected objects
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 a consequence of the language definition, or simply that it isn't worth spending a lot of effort on 32 bit machines? There is nothing related to the language definition here, as these are not standardized packages, but part of the implementation. Attempts to use them directly from user programs will result in warnings. There are a few issues. We really don't want to have different versions of the spec for different targets. Rather, we'd have functions that either raise an exception or use a lock-based implementation if the target lacks the required capabilities. The system-specific boolean is a mostly a method that allows us to switch off our use of lock-free protected types on a per system basis. This avoids unnecessary instability in less commonly used platforms while we're enhancing this new capability. IIUC, all ports are supposed to implement the atomic built-ins. If they are not supported in hardware, there should be a library function for it that uses locking. The problem we're trying to address is builds failing because of undefined references to __atomic_* functions. I could also have used __atomic_always_lock_free, which is better in many ways, but we also need to know in the front end what expansion to use for protected types. My initial thought was to just have the front end build some trees calling __atomic_always_lock_free and see if they fold to True. However, this was considered undesirable. The alternative would be to have the front end call can_compare_and_swap_p(), but that would have the front end depend on rtl.h, which even I understand is bad. Probably can_compare_and_swap_p() should be moved to a better place, so the front end can use it directly. As I felt it was important to address the failures quickly, we used the current approach. -Geert
Re: [Ada] Lock-free implementation of protected objects
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). Having a default can't work, as s-atopri.adb needs access to the flag. Only the front end itself can use a default, not the run time. -Geert
Re: [Ada] Lock-free implementation of protected objects
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 unknown or new ports to be broken by default). Having a default can't work, as s-atopri.adb needs access to the flag. Only the front end itself can use a default, not the run time. While currently the flag is needed, I agree with you that this is undesirable. The only way to avoid this is to have a type attribute, such as T'Atomic_Always_Lock_Free that is statically True if T is known to be supported for atomic operations. This would be similar to the atomic built-in __atomic_always_lock_free function, but initially based on the value of the system constant (as well as size/alignment of the type). Eventually, we should be able to query this directly from the back end. Regardless, the situation as of now is that system.ads must define the flag, so right now Iain's patch is correct and fixes a build failure. As soon as the attribute is implemented, we can remove the system flags on systems where it is set to False. -Geert
Re: execute permissions in ada
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 that time. -Geert
Re: execute permissions in ada
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
Re: [Ada] Do not pass -Werror during linking
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 System.Address; and I'm reluctant to enter the type morphing business in gigi. There are two issues: - In the Ada front end and run time, we rely on Address being an unsigned type, so we can do address arithmetic. Ada doesn't have the notion of pointer arithmetic. - Access types (pointers) in Ada carry not only carry the address, but also the bounds in case of unconstrained types (as you well know) I agree it doesn't fit well to do that, and seems pointless as one cannot dereference Address anyway, so we have conversions where needed. But we could investigate changing System.Memory to use an access type instead of System.Address. It's a compiler unit so the impact should be limited, and at least this would solve the m68k problem. Probably for Convention C, we should convert Address to *void. So, for function Alloc (Size : size_t) return System.Address; pragma Export (C, Alloc, __gnat_malloc); we probably should do this replacement and add the necessary type conversions. That would seem to be how this was intended. However, I'm not sure how much of an earthquake this would be in gigi. -Geert
Re: [patch] Fix crash on function returning variable-sized array
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. The new void *data pointer could use a comment on what it is and how it's used. -Geert
Re: [wwwdocs/news] Add link to GNU Tools Cauldron 2012
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
Re: [RFC] Fix full memory barrier on SPARC-V8
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 issue. While it is true that all stores will be submitted in order , this does not guarantee store-load consistency. In particular on a multiprocessor, each individual processor has it's own store buffers and cannot see what is in the other CPUs store buffet. In the end all stores will be committed to memory in a sequential order, but that is not sufficient. The use of a load-store instruction is needed to achieve a full barrier. The SPARC architecture manuals describe this in detail. -Geert
Re: [RFC] Fix full memory barrier on SPARC-V8
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 description? See J.7, and study why the store instructions are replaces by SWAP. Adding a ldstub here is going to be really expensive, on UltraSparc that can be 36+ cycles even on a cache hit. Yes, synchronization in multi-CPU systems is expensive. If it's really cheap, you're probably doing something wrong. Also, the more I think about it, the issue really is that one is trying to run v8 code on a v9 cpu. Double no: 1. No, my primary concern is about v8 code running on multiprocessor systems implementing the SPARC v8 architecture (LEON3 in particular) 2. No, a SPARCv8 compliant binary should run correctly on both SPARCv8 and SPARCv9. The entire raison-d'être for the SPARC architecture is so we can write code based on the architecture, and have it run correctly on all implementations. -Geert
Re: [RFC] Fix full memory barrier on SPARC-V8
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, synchronization in multi-CPU systems is expensive. If it's really cheap, you're probably doing something wrong. First, I fundamentally disagree with this assertion. The reason proper memory barriers exist is so that you don't need nonsense like these proposed atomics to get proper memory operation ordering. Sorry, I see now I phrased this poorly, no offense intended. We both agree that with TSO there is never a need for any STBAR instructions on SPARCv8. The point is that TSO is not sufficient for strong consistency. The reason for this is the existence of write buffers (see fig 6.1, or K-1 of the SPARC v8 architecture manual). In particular, note the CPU-local bypass from the store buffer. Two processors both storing a value X in location Y and then reading from Y might each see their own value. In the end, one will reach memory first and the stores will be ordered there. The load-store instructions are necessary to ensure the store will be seen by the memory system before subsequent loads can use them. The main issue is that SPARC's TSO does not guarantee Store-Load ordering. So, only by issuing a SWAP(A) or LDSTUB(A) instruction can total ordering of all loads and stores be guaranteed. A proper membar on your v9 test system is orders of magnitude cheaper than this stbar+ldstub business. That's true, but membar is a SPARC v9 instruction. The issue Eric and I are addressing is only about SPARCv8. \You then go on to speak about LEON, does LEON implement PSO? No, I'm not talking about PSO anywhere or SPARCv9 anywhere. Just plain old SPARCv8, using the TSO model. This requires a load-store instruction to guarantee a full memory barrier. I'm not making this up, that is why I refer to the examples in the SPARC v8 architecture manual that specifically state that SWAP instructions need to be used instead of store instructions to make Dekker's algorithm work. -Geert
Re: PATCH: PR rtl-optimization/47502: Never combine asm statement
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
