Re: Serious code generation/optimisation bug (I think)
On 30 Jan 2009, at 05:11, Ross Smith wrote: Zoltán Kócsi wrote: On Thu, 29 Jan 2009 08:53:10 + Andrew Haley wrote: We're talking about gcc on ARM. gcc on ARM uses 0 for the null pointer constant, therefore a linker cannot place an object at address zero. All the rest is irrelevant. Um, the linker *must* place the vector table at address zero, because the ARM, at least the ARM7TDMI fetches all exception vectors from there. Dictated by the HW, not the compiler. This sounds like a genuine bug in gcc, then. As far as I can see, Andrew is right -- if the ARM hardware requires a legitimate object to be placed at address zero, then a standard C compiler has to use some other value for the null pointer. The ARM exception table looks like this: 0x Reset 0x0004 Undefined instruction 0x0008 Software interrupt 0x000C Prefetch Abort 0x0010 Data Abort 0x0014 Reserved 0x0018 IRQ 0x001C FIQ so only the reset vector is at 0. -- Andy Armstrong, Hexten
Re: Serious code generation/optimisation bug (I think)
Ross Smith wrote: This sounds like a genuine bug in gcc, then. As far as I can see, Andrew is right -- if the ARM hardware requires a legitimate object to be placed at address zero, then a standard C compiler has to use some other value for the null pointer. That's not quite the story. It's not a bug, it just means that the vector table at location zero is not a legitimate object from C's point of view. You might be able to fool incorrect C code into accessing it, but strictly the result of this decision is that you have to use machine language to access this table (which is not so unreasonable, any code accessing this table will presumably be highly machine dependent). It might be a good idea to make null be other than zero, but I somewhat suspect that in practice incorrect C code may well assume that null is zero in various contexts, since this expectation is rather strongly ingrained from experience. (sort of like implementing local variables on a stack for fortran-77. The standard was carefully written to accomodate this, but many fortran programs assumed static allocation, and in fact one of the reasons that fortran was annoying on the B5500 was that it used an Algol-60 like stack implementation -- not surprising given the architecutre -- and although this was correct, it caused many existing fortran programs to fail). -- Ross Smith
Re: Serious code generation/optimisation bug (I think)
Andy Armstrong wrote: The ARM exception table looks like this: 0x Reset 0x0004 Undefined instruction 0x0008 Software interrupt 0x000C Prefetch Abort 0x0010 Data Abort 0x0014 Reserved 0x0018 IRQ 0x001C FIQ so only the reset vector is at 0. Right, so the reset vector cannot be regarded as a legitimate C object.
Re: Serious code generation/optimisation bug (I think)
> This sounds like a genuine bug in gcc, then. As far as I can see, > Andrew is right -- if the ARM hardware requires a legitimate object > to be placed at address zero, then a standard C compiler has to use > some other value for the null pointer. I think changing that would cause more trouble than gain. The processors where 0 is a legitimate object for pointer dereference are mostly the embedded cores without MMU (e.g. ARM7TDMI based controllers, m68k family controllers, AVR, 68HC1x and alike). Some of these do actually utilise their entire address space, such as the 68HC11 or the AVR, so there is no address whatsoever that is not a valid one. Therefore, you can not define a standard-compliant NULL pointer, unless you define the pointer to something wider than 16 bits and make the long the smallest int that can store a pointer. In that case, it would be easier just simply drop those processor families as targets, as the generated code would be unusable in practice. In fact, on a naked CPU core in an unknown hardware configuration, without an MMU you can not define a NULL pointer that is guaranteed to never point to a valid datum or function, simply becase as far as the processor is concerned, every address in it entire address space is valid. Since the compiler can not possibly know what address is used by the surrounding hardware and what isn't, it can not guarantee what the standard demands. That, I think, is a problem with the standard and not with the compiler. On such targets 0 for NULL is just as good a choice as any other. Actually better, especially because that is the choice that makes the conversion between a pointer and an integer a no-op, saving both code space and execution time. On such target environment the user has to learn (as I had to) to ask the compiler not to strictly conform to the standard and not to infer from a dereference operation that the pointer is not NULL. Zoltan
Solve transitive closure issue in modulo scheduling
Hello, I try to make modulo scheduling work more efficiently for our VLIW target. I found one serious issue that prevents current SMS algorithm from achieving high IPC is so-called "transitive closure" problem, where scheduling window is only calculated using direct predecessors and successors. Because SMS is not an iterative algorithm, this may cause failures in finding a valid schedule. Without splitting rows, some simple loops just cannot be scheduled not matter how big the II is. With splitting rows, schedule can be found, but only at bigger II. GCC wiki (http://gcc.gnu.org/wiki/SwingModuloScheduling) lists this as a TODO. Is there any work going on about this issue (the last wiki update was one year ago)? If no one is working on it, I plan to do it. My idea is to use the MinDist algorithm described in B. Rau's classic paper "iterative modulo scheduling" (http://www.hpl.hp.com/techreports/94/HPL-94-115.html). The same algorithm can also be used to compute better RecMII. The biggest concern is complexity of computing MinDist matrix, which is O(N^3). N is number of nodes in the loop. I remember somewhere GCC coding guide says "never write quadratic algorithm" :-) Is this an absolute requirement? If yes, I will keep it as our target-specific code (we are less concerned about compilation time). Otherwise, I will try to make it more generic to see if it can make into mainline in 4.5. Any comments? Cheers, Bingfeng Mei Broadcom UK
GCC & OpenCL ?
Hello All,
OpenCL http://www.khronos.org/opencl/ is a new standard proposing an API
for GPUs (targetting vector processing on heterogenous systems, like GPU
+ CPU). It suggests some restricted & specialized C dialect to code
"kernel" functions (kernel in OpenCL means running on the GPU).
Is there any branch or experimental code for adding OpenCL into GCC?
I suppose that some people are already working on that, but I didn't
find easily precise references.
Any clues, insights, contacts on these items?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
[strict-aliasing] incorrect warning with g++-current in STL
refix=/usr/local/gcc_current --enable-shared --enable-threads=posix --enable-checking=release --enable-__cxa_atexit --enable-version-specific-runtime-libs --enable-languages=c,c++ --no-create --no-recursion Thread model: posix gcc version 4.4.0 20090130 (experimental) [trunk revision 143790] (GCC) # uname -a Linux localhost.localdomain 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 19:19:45 EST 2008 i686 i686 i386 GNU/Linux
Re: [strict-aliasing] incorrect warning with g++-current in STL
Дмитрий Дьяченко wrote: > Hello, g++-current ( [trunk revision 143790] ) produce incorrect > warning. Need I file bug-report? > No need, thanks, we have already middle-end/38937. If you want, you can add to it your testcase, useful in order to better test the patch linked therein on i686-linux (and x86_64-linux) too. I'm going to do that, by the way... Paolo.
Re: New GCC Runtime Library Exception: not fit for purpose
On Thu, Jan 29, 2009 at 04:34:09AM -0800, Joern Rennecke wrote: > Quoting Ian Lance Taylor : > > I'm not sure what your point is here. newlib is not under the GPL in > > any case. It is not affected by the gcc runtime library license. > > The old runtime library exception allowed you to distribute binaries that > both include pieces of the gcc runtime and arbitrary pieces of newlib, > without requiring the distribution to be under the terms of the GPL. > I.e. your could link non-GPL code against both the gcc runtime and newlib > and distribute it. > The new license does not allow this unless all parts included from newlib > are written in a high level language AND use the gcc runtime. Please quote the part of the license that you believe says this. I think that you are mistaken.
Re: New GCC Runtime Library Exception: not fit for purpose
Quoting Joe Buck : On Thu, Jan 29, 2009 at 04:34:09AM -0800, Joern Rennecke wrote: Quoting Ian Lance Taylor : > I'm not sure what your point is here. newlib is not under the GPL in > any case. It is not affected by the gcc runtime library license. The old runtime library exception allowed you to distribute binaries that both include pieces of the gcc runtime and arbitrary pieces of newlib, without requiring the distribution to be under the terms of the GPL. I.e. your could link non-GPL code against both the gcc runtime and newlib and distribute it. The new license does not allow this unless all parts included from newlib are written in a high level language AND use the gcc runtime. Please quote the part of the license that you believe says this. I think that you are mistaken. The requirement to use the gcc runtime arises out of the definition of Independent Modules and the wording in the exception that only mentions combining the gcc runtime with Independent Modules. Ian is arguing that the clause means more than it says, i.e. also allows combination with code that is not an Independent Module. I don't agree with that interpretation, but we seem to agree on that it would be helpful if the definition of Independent Module would include modules that are completely independent of the gcc runtime. The requirement that all included parts would have to be written in a high level language is more explicit; all the code linked in from newlib is Target Code, and for the combination the gcc runtime with Indpendent Modules to be covered by the exception all the Target Code must have been generated by Eligible Compilation Processes. The defintion of Eligible Compilation Process is such that, even if you could construe that something suitable for labeling a compilation process has been taking place, it can only apply to code that is expressed in a high-level, non-intermediate language. I.E. that's th defintion of Target Code, defintion of Eligible Compilation Process, and the wording of the Grant of Additional Permission. Note that the way the exception is written, not only must all parts included from newlib be written / generated in a high level language, but also all parts included from the gcc runtime.
GCC Runtime Library Exception
After the e-mail flurry, here is my personal summary of the issues regarding the GCC Runtime Library Exception (http://www.gnu.org/licenses/gcc-exception.html). I personally think that this includes all the substantive issues which were raised, though I understand that others may disagree. * The definition of "Independent Module" does not appear to include source code which neither requires the runtime library nor makes use of an interface provided by the runtime library. This applies to a lot of source code, such as code written originally in assembler. It does not seem to be a goal of the exception to restrict the combination of the GCC runtime library with source code which does not use the library, provided of course that the source code in question is compiled via an Eligible Compilation Process. Therefore, it would seem useful to clarify that arbitrary source code which is not based on the runtime library, does not use the runtime library, and indeed has nothing to do with the runtime library at all, fits the definition of an Independent Module. * The gcj compiler, which is part of gcc, can compile Java byte code into machine code. It is normal practice to generate the Java byte code using a Java compiler which is not GPL compatible. That is, the Java source code is compiled into Java byte code via a non-GPL compiler, and then gcj is used to compile the Java byte code into machine code. However, Java byte code is probably not a "high-level, non-intermediate language". Therefore, this combination of compilers is not an Eligible Compilation Process. This means in effect that any binary generated in this way by gcj does not fall under the Runtime Library Exception. This does not seem to be a desirable consequence, as it severely limits the cases in which gcj may be used. One way to resolve this might be to say that a compilation process is Eligible so long as the input to GCC was produced exclusively using programs which are not themselves derived from GCC. I don't think that this approach would weaken the goals of the runtime library exception. Another way to resolve this might be to simply declare that for the purposes of the exception, Java byte code is treated as a high-level, non-intermediate language. I think this would be an acceptable minimal approach, since there will always be very few examples of intermediate representations which gcc can compile but which are not generated by gcc. * People raised questions about LLVM byte code or GIMPLE byte code. In both cases it is normal for a tool to generate byte code, and then for a compiler to compile that byte code into machine code. The case of GIMPLE byte code seems clear to me: if the GIMPLE byte code is generated by GCC, and then modified by a non-GPL-compatible tool, then we do not want to permit the exception to apply. While it is conceivable that other people will someday write tools other than GCC which generate GIMPLE byte code, it remains the case that GIMPLE is defined by GCC, and I don't see any reason to apply the runtime library exception if the tools which generate the GIMPLE byte code are not GPL compatible. LLVM byte code is generated by LLVM, not gcc. The question here is whether it is desirable to permit using LLVM to generate LLVM byte code and to then use GCC to turn that byte code into machine code. (It will not be desirable to apply the exception if GCC is someday used to generate LLVM byte code, nor if LLVM is someday used as an optimization plugin to GCC). This question is hypothetical, as I don't know of any plans to create such a tool. Moreover, LLVM is in any case licensed under a GPL-compatible license. That said, LLVM byte code is clearly documented, is higher level than assembly code,and some people write it by hand. Should it be treated as a "high-level, non-intermediate language" or not? If the Java byte code issue is addressed by saying that the compilation process is Eligible so long as the input to GCC was produced exclusively using programs which are not themselves derived from GCC, then this issue is moot. Otherwise, it may possibly to useful to try to clarify the difference between a "compiler intermediate representation" and a "high-level, non-intermediate language." Or, since this issue remains hypothetical, it may be preferable to address it on a case-by-case basis. Hope this helps. Ian
Re: GCC Runtime Library Exception
Ian Lance Taylor wrote: > LLVM byte code is generated by LLVM, not gcc. The question here is > whether it is desirable to permit using LLVM to generate LLVM byte > code and to then use GCC to turn that byte code into machine code. > (It will not be desirable to apply the exception if GCC is someday > used to generate LLVM byte code, nor if LLVM is someday used as an > optimization plugin to GCC). This question is hypothetical, as I > don't know of any plans to create such a tool. Isn't llvm-gcc such a tool? It generates LLVM byte code, and it is, I'm pretty sure, a derivate of GCC. Sebastian
Re: GCC Runtime Library Exception
Sebastian Redl writes: > Ian Lance Taylor wrote: >> LLVM byte code is generated by LLVM, not gcc. The question here is >> whether it is desirable to permit using LLVM to generate LLVM byte >> code and to then use GCC to turn that byte code into machine code. >> (It will not be desirable to apply the exception if GCC is someday >> used to generate LLVM byte code, nor if LLVM is someday used as an >> optimization plugin to GCC). This question is hypothetical, as I >> don't know of any plans to create such a tool. > Isn't llvm-gcc such a tool? It generates LLVM byte code, and it is, I'm > pretty sure, a derivate of GCC. I mean that there are, so far as I know, no plans to change GCC to read LLVM byte code and produce assembler code. Ian
Re: GCC & OpenCL ?
On Fri, Jan 30, 2009 at 03:08:47PM +0100, Basile STARYNKEVITCH wrote: > Hello All, > > OpenCL http://www.khronos.org/opencl/ is a new standard proposing an API > for GPUs (targetting vector processing on heterogenous systems, like GPU > + CPU). It suggests some restricted & specialized C dialect to code > "kernel" functions (kernel in OpenCL means running on the GPU). > > Is there any branch or experimental code for adding OpenCL into GCC? > > I suppose that some people are already working on that, but I didn't > find easily precise references. > > Any clues, insights, contacts on these items? I am just starting to think about adding OpenCL support into future versions of GCC, as it looks like a useful way of programming highly parallel type systems, particularly with hetrogeneous processors. At this point, I am wondering what kind of interest people have in working together on OpenCL in the GCC compiler? I realize Apple is putting a lot of work into OpenCL on the LLVM compiler, but I think a parallel implementation in the classic GCC compiler would reach a lot of users. I'm curious how many users would consider using OpenCL if it was available in GCC, and whether there are other people intereested in working on it. Note, at present, I have not scoped out the work -- I am trying to guage what the interest level would be. Off hand, I think the first stage is to get OpenCL to work in a homogeneous multi-core system before diving into the hetrogeneous systems. It is obvious to me, that a GCC based OpenCL system should support various systems in development, including homogeneous systems, pcs with add-on graphic processors, combination systems like the Cell systems, and be flexible enough for new systems coming down the pike. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: GCC & OpenCL ?
Michael Meissner wrote: > I am just starting to think about adding OpenCL support into future > versions of GCC, as it looks like a useful way of programming highly > parallel type systems, particularly with hetrogeneous processors. At > this point, I am wondering what kind of interest people have in > working together on OpenCL in the GCC compiler? I'm personally less interested in OpenCL (maybe because I don't know it yet so well - I just have head of it). However, I wonder whether one can create some infrastructure in GCC which can also be used by other parts. Or at least I assume one needs to have some library which somehow provides the communication and common routines for that. And at least for non-shared memory this library support could be of interest for Fortran 2008's coarrays and for UPC. (I don't know what the plans for UPC support in GCC; there exists patches on top of GCC 4.2 but seemingly there is no plan of merging it. I also don't know how big the demand is. For Fortran, I think there is some demand already since Cray and g95 support it - and there is the intention to implement it in gfortran and ifort.) (It would also be cool if one could get Fortran work in heterogenous environements such as GPUs, but I don't see how Fortran/coarrays fit into the OpenCL ideas.) Tobias
gcc-4.4-20090130 is now available
Snapshot gcc-4.4-20090130 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090130/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 143809 You'll find: gcc-4.4-20090130.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090130.tar.bz2 C front end and core compiler gcc-ada-4.4-20090130.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090130.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090130.tar.bz2 C++ front end and runtime gcc-java-4.4-20090130.tar.bz2 Java front end and runtime gcc-objc-4.4-20090130.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090130.tar.bz2The GCC testsuite Diffs from 4.4-20090123 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: New GCC Runtime Library Exception
On Wed, 28 Jan 2009, Mark Mitchell wrote: > Joseph S. Myers wrote: >> Will the transition to use GPLv3+exception need to be made on release >> branches before any more releases are made from them (so that if anyone >> should volunteer to the SC to make any further 4.2 releases, before the >> point at which I propose to close 4.2 branch in the absence of such a >> volunteer, they will need to ensure the transition patch is backported)? > We should just update the licenses on the trunk. The change from GPLv2 > to GPLv3 in the midst of the 4.2.x release cycle was confusing to > people. I see no reason to do that again. This matches my understanding as well. I do believe that GCC 4.4 should be released with this new license; does this match your understanding? Gerald
Re: New GCC Runtime Library Exception
Gerald Pfeifer wrote: >> We should just update the licenses on the trunk. The change from GPLv2 >> to GPLv3 in the midst of the 4.2.x release cycle was confusing to >> people. I see no reason to do that again. > > This matches my understanding as well. I do believe that GCC 4.4 should > be released with this new license; does this match your understanding? Yes, definitely. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
MIPS64 -msym32 and DWARF2_ADDR_SIZE
-msym32 changes DWARF's address_size from 64 bits to 32 bits. This means that while symbols are 64-bit (due to ELF64), target addresses in the debug info are 32-bit. There is support for this in DWARF of course in fact you can specify different address_size for each compilation unit which nicely maps with -msym32 being link-compatible with regular N64 objects. However, this asymmetry exposed several bugs in binutils. Also, as I just discovered today, dwarfdump (libdwarf) has no support for changing the address_size between compilation units and in fact derives address_size from the ELF class (ELF64/ELF32). (Obviously, that's a bug in libdwarf.) So my question is whether the saving in the size of the debug info with -msym32 is really worth the trouble here or should we just start generating 64-bit addresses with -msym32? Adam
GCC Plug-in Framework ready to port
Dear mailing list: My research group (the High-Confidence Operating Systems group at Stony Brook University; home page http://www.fsl.cs.sunysb.edu/hcos/) continues to use a modified branch of Subversion GCC that hosts plug-ins written in C, C++, and (with a little work) Python. We published a GCC Summit paper on this, called "Extending GCC with Modular GIMPLE Optimizations" (Callanan, Dean, and Zadok). We have developed a variety of plug-ins, including: - A GIMPLE virtual machine, developed by another team at the university, - A generic run-time AOP architecture, currently in preparation, - Bounds-checkers and execution tracers, and more. We are willing to contribute the effort necessary to integrate this system into the current main-line GCC, and feel that it is simple and general enough that many other systems could be built on top of it. We've been off the ML for some time, but we're still out there. Is this something that is wanted, or have we been overtaken by events and should be porting to someone else's implementation? Sincerely, Sean Callanan
Re: Creating imaginary inf/nan in GCC
From: "Tobias Burnus" Hi Kaveh, Kaveh R. GHAZI wrote: I'm trying to create complex number expressions that contain inf or nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I). If it does not need to be C (e.g. to try MPC in the middle end), you could use Fortran: ! compile with gfortran -fno-range-check complex :: z z = cmplx(0.0, 0.0/0.0) print *, z end Tobias Thanks, I do want to test the middle-end. However I need to do more than just create the complex expression. I also have to pass it to a builtin that evaluates using MPC like __builtin_csin(). The fortran frontend evaluates complex transcendentals in fortran/simplify.c, not in the middle-end. So it wouldn't test what I want AFAICT. It's not a big deal, the nan cases are error paths that should *avoid* folding via MPC. Regards, --Kaveh
-L on AIX
Lets suppose I build GNU's sed using gcc 4.2.0 on AIX. At link time, the flag -L/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/../../.. is passed along with -L/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0 to ld. sed links and runs fine. In the executable, this list of paths is kept and is the default search path for shared libraries. It can be overridden with the LIBPATH environment variable but often that brings up more issues than it solves. As it is now, it requires the user of sed to have not only gcc's libraries installed but the 4.2.0 version of the libraries. And, if you ask ldd to dump out the libraries that sed uses, it actually does not use any gcc libraries. But if the /usr/local/lib/gcc/powerpc-ibm- aix5.3.0.0/4.2.0 directory is gone, then the loader can't find libintl.a in /usr/local/lib and sed won't execute. Looking at the code, it appears like spec_path might be a good place to collapse these paths and remove the ..'s. Is this a good idea? Thanks, Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
