[URGENT] GCC 4.0 Nomination
Folks, GCC 4.0 has been shortlisted in this year's Linux Awards: * http://www.linuxawards.co.uk/content/view/14/40/ * Best Linux/Open Source Developer Tool. BUT...none of the folks in the office can apparently contact anyone about being available to attend the dinner next week in London, UK. Can someone suitably involved with the project urgently contact either myself or (preferably) Maggie Meer <[EMAIL PROTECTED]> about this? Cheers! Jon. pgpaFrQRsJT0A.pgp Description: PGP signature
Re: [URGENT] GCC 4.0 Nomination
On Sun, Oct 02, 2005 at 04:50:41PM +0100, Andrew Haley wrote: jcm>> GCC 4.0 has been shortlisted in this year's Linux Awards: jcm>> * http://www.linuxawards.co.uk/content/view/14/40/ > Going from the mailing lists there are about ten of us heavily > involved in gcc here in the UK. I'm not sure how you'd choose > someone, given that gcc is a collective effort. Absolutely. This is the situation and we're very much aware that none of the projects which have been nominated for Wednesday's Awards are one man bands - you'll see we have others like Eclipse, Mozilla, etc. etc. all in there and all of them are multinational efforts. But we need to find someone who is comfortable to accept the award on behalf of the team - otherwise GCC will be the only project which is not represented at the event. We understand the value of GCC (do a Google search on my name for example) and just want to give recognition. Jon. pgpqPOlHjHyQ7.pgp Description: PGP signature
Re: [URGENT] GCC 4.0 Nomination
On Tue, Oct 04, 2005 at 01:00:53PM +0100, Joern RENNECKE wrote: > I could make it there, but I'd have to leave shortly after 11 p.m., > since the last > train from paddington to bristol goes at half past eleven. That would be fine. I've spoken to the organisers and have had you added to the list of people attending the dinner. They suggest that you go to the stand of our magazine - Linux User & Developer - during the afternoon and pick up your pass or just turn up at 19:00 for the ceremony. It's a black tie event and apparently that means we have to wear a suit or something (I've got to go and dig one out myself tonight). Jon.
Re: ARM summit at Plumbers 2011
On Tue, 2011-08-23 at 17:11 +0100, Steve McIntyre wrote: > UPDATE: we've not had many people confirm interest in this event yet, > which is a shame. If you would like to join us for this session, > please reply and let me know. If we don't get enough interest by the > end of Sunday (28th August), then we'll have to cancel the meeting. I'm obviously confirming, but I'll repeat that for the record. My interests here include helping to lead up Fedora's ARMv7 efforts, but also wider ARM platform standardization (boot, device enumeration, multi-arch, ABI, kernel consolidation, and many other things). If there's at least representation from a few of the distros (as it seems is the case at this point) then I think it's worthwhile having the formal slots. Nothing is lost in so doing. In any case, many discussions will take place if we have the opportunity to do so. Jon.
__sync_sychronize on ARM
Greetings, I have been trying to help diagnose a failure to build in the icu package for Fedora on ARM systems, with gcc 4.7. I should very much like to know the answer to a few questions, so that I can help fix this. I would like to say at the outset that I believe I am a reasonably competent programmer, but I am not (yet perhaps) a gcc hacker, though I certainly enjoy any such opportunity to get to know its internals more. I understand more of the theory than the implementation of compilers :) The __sync_synchronize "legacy" sync function is intended to be used to perform an expensive data memory barrier operation. It is defined within libgcc in such a way that I *believe* means that, on most architectures, it is replaced with an inline assembly code emitted that performs a sync operation. On ARM, and some other architectures with mixed ISAs wherein there may not be a sync function nor one way to do this, this function (__sync_synchronize) can be a real function call. In that case, it might cause inline assembly generation, or e.g. call a kernel VDSO helper. The icu package contains a direct call to __sync_sychronize, especially in the iotest test cases. I believe that this compiles fine on x86 because there is no function call. However, on ARM, the code fails to link because the __sync_synchronize function is HIDDEN and not exported (or so goes my understanding - is that correct?). I am drawing a blank, though, on how this differs from earlier versions of gcc such as 4.6 (aside from a slight difference in the macro used to make it available), and whether it is indeed the case that this function should be made available within libgcc for direct linking? In other words, I do not know whether there is a bug here in gcc or whether icu needs changing. It seems that there are newer, less expensive sync operations that perhaps ought to be used instead, but I don't have the full context. Please forgive my lack of understanding of gcc intrinsics, and atomics. I would very much like to learn more about the internal implementation and I look forward to whatever information you can share with me. If you would like more information, I can happily provide it in the morning. It is very late here, but I wanted to start this thread asap. We are trying to fix icu so that we can continue to build Fedora 17 for ARM systems. Thanks very much, Jon.
Re: __sync_sychronize on ARM
Hi Ramana, Thanks very much for getting back to me! On Mon, 2012-01-30 at 08:50 +, Ramana Radhakrishnan wrote: > On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote: > > The __sync_synchronize "legacy" sync function is intended to be used to > > perform an expensive data memory barrier operation. It is defined within > > libgcc in such a way that I *believe* means that, on most architectures, > > it is replaced with an inline assembly code emitted that performs a sync > > operation. On ARM, and some other architectures with mixed ISAs wherein > > there may not be a sync function nor one way to do this, this function > > (__sync_synchronize) can be a real function call. In that case, it might > > cause inline assembly generation, or e.g. call a kernel VDSO helper. > > On ARM we don't have a kernel VDSO You're right of course! I was confusing the VDSO-like user mode mapped helpers (Documentation/arm/kernel_user_helpers.txt) with full VDSO. I apologize for my mistake. Nonetheless, I believe for the purposes of this thread, we can consider the behavior I described roughly consistent with reality, because a kernel helper will be called in a VDSO-like way. > sync_synchronize for older versions of > the architecture ( anything prior to armv6k) should result in a call > to sync_synchronize > in libgcc.a which should take care of calling the kernel helper function. This is what's confusing me :) Is one supposed (from some random source) to be calling __sync_synchronize or sync_synchronize? Convention suggests the latter, but I was sufficiently confused by the aliasing of the names in the source vs. the documentation, so I'd like to ask you :) > Therefore I'm assuming this is a breakage you face when building for > armv5te It is indeed. Thanks for noting that. > > The icu package contains a direct call to __sync_sychronize, especially > > in the iotest test cases. I believe that this compiles fine on x86 > > because there is no function call. However, on ARM, the code fails to > > link because the __sync_synchronize function is HIDDEN and not exported > > (or so goes my understanding - is that correct?). > > No, the HIDDEN shouldn't cause a link failure in this case - you > should be able to pull this > in when you link against the static libgcc where this should be defined. > > I don't know what your linker command line is so maybe that's a place > to start investigating from. Thanks! You're the second person to suggest that, so I'll look some more. Could you let me know about the correct function name, above? Appreciate the help. Jon.
RESOLVED - Re: __sync_sychronize on ARM
Hello everyone, Just a quick followup. This problem is now resolved. There is no breakage in gcc, just a problem in the Fedora icu package. That package contains some sed scripts in the "SPEC" (build description meta) file that intentionally were munging the Makefiles used to build ICU such that "nostdlib" was being given to gcc and it was never using libgcc. The intention of the person who made this change apparently was to prevent linking the standard math library into icu, but unfortunately a rather unusual solution was chosen. On some systems, one can almost get away with this because __sync_synchronize happens to be implemented in such a fashion that it is optimized into inline emitted assembly. On ARM, that isn't the case. In addition, it is likely that telling GCC not to link in core libraries like libgcc will lead to other breakage later. I have requested the package be fixed to remove the sed scripts and have temporarily (just to solve our problem in the Fedora ARM community) had "-lgcc" added to the linker flags as a very hackish solution for today. Thanks for the replies, and I apologize for the noise. I have learned a great deal about gcc atomics over the past few days. I have also learned that debugging packages requires that you build the package *exactly* as it is in the spec file, not just by running configure/make as therein ;) Jon.
Re: gets is not too dangerous
On Thu, 2006-08-31 at 17:52 -0400, Miguel Angel Champin Catalan wrote: > We are students of computer sciences in the Santa Maria University, > Chile. We just want to know if the function "gets" it's too dangerous > for a warning. The fact is that our teacher's assistant give us a > homework, and one restriction was to use gcc to compile our code, > without warnings. As others said, it's not GCC directly giving you the warning. But nonetheless, it's good to understand where your logic is flawed. > We ask you for a simple explanation (if it's possible) about our > warning, telling that "gets" is not too dangerous, because in our case, > works perfectly, under some restrictions obviously. Simply reading the man page states: No check for buffer overrun is performed (see BUGS below). Hopefully, you know what a buffer overrun/overflow is and understand why it is therefore a very bad idea to be using gets even in academic work. Cheers! Jon.
