Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote: > On 08/12/2013 09:09 AM, Peter Zijlstra wrote: > >> > >> On the majority of architectures, including x86, you cannot simply copy > >> a piece of code elsewhere and have it still work. > > > > I thought we used -fPIC which would allow just that. > > > > Doubly wrong. The kernel is not compiled with -fPIC, nor does -fPIC > allow this kind of movement for code that contains intramodule > references (that is *all* references in the kernel). Since we really > doesn't want to burden the kernel with a GOT and a PLT, that is life. OK. never mind then..
gfortran-dg-runtest, torture options
Hi! I noticed something strange in the libgomp testresults (but not necessarily specific to libgomp): an "arbitrary" set of the Fortran execution tests are run just for -O, and others for each of the full set of torture options: -O0, -O1, -O2, and so on. After some time I realized it's the set of tests that contain an explicit »dg-do run« directive that are run for all torture levels, and the tests that inherit the default »set dg-do-what-default run« from libgomp/testsuite/lib/libgomp.exp are only run for -O. This is coming from the special handling in gcc/testsuite/lib/gfortran-dg.exp:gfortran-dg-test (which seems to be present approximately "forever"). Should this consider the dg-do-what-default case, too? Why is torture testing done only for execution tests? And, why only for Fortran? Is this behavior generally intentional -- of course, bigger testing coverage is nice, but this seems a bit arbitrary to me? Grüße, Thomas pgpNAdkY9F_32.pgp Description: PGP signature
Re: [RFC] gcc feature request: Moving blocks into sections
> On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote: >> Since we really doesn't want to... Ow. Can't believe I wrote that. -hpa
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, 13 Aug 2013 07:46:46 -0700 "H. Peter Anvin" wrote: > > On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote: > >> Since we really doesn't want to... > > Ow. Can't believe I wrote that. > All your base are belong to us! -- Steve
converting rtx object to the assembly instruction.
Is there a simple way to convert rtx object to the assemble insutruction? Ideally I would like to have function something like: const char *rtx2asm(rtx insn); returning a string with the asm instruction for the insn. Closest thing that I found is the final_scan_insn function in final.c but unfortunatelly it outputs the asm string to the file so it makes it not usefull for my purposes. Thanks, Viktor.
Re: HAVE_ATTR_enabled mishandling?
On 13-08-12 11:13 AM, Chung-Ju Wu wrote: Hi, Vladimir, Apparently the issue that David mentioned has already been fixed earlier: http://gcc.gnu.org/r198344 2013-04-26 Vladimir Makarov ... * lra-constraints.c (curr_insn_set): New. ... (process_alt_operands): Use it. Use #if HAVE_ATTR_enabled instead of #ifdef. Add code to remove cycling. ... However, such change is only applied on trunk but not on 4.8 branch. Since 4.8 branch is still open and this issue seems to be a bug, perhaps it is a good idea to backport this part. What do you think? :) I guess it is worth to do. It should be safe so no any objections for this.
GCC for Android Shell
Hi, Can we send me the compiled gcc and gcc for Android Shell (armeabi). I would like to have data after uncpack with a minimum size 50 MB. Sory my bad English.
Re: gfortran-dg-runtest, torture options
On 08/13/2013 04:06 AM, Thomas Schwinge wrote: > Hi! > > I noticed something strange in the libgomp testresults (but not > necessarily specific to libgomp): an "arbitrary" set of the Fortran > execution tests are run just for -O, and others for each of the full set > of torture options: -O0, -O1, -O2, and so on. After some time I realized > it's the set of tests that contain an explicit »dg-do run« directive that > are run for all torture levels, and the tests that inherit the default > »set dg-do-what-default run« from libgomp/testsuite/lib/libgomp.exp are > only run for -O. This is coming from the special handling in > gcc/testsuite/lib/gfortran-dg.exp:gfortran-dg-test (which seems to be > present approximately "forever"). Should this consider the > dg-do-what-default case, too? Why is torture testing done only for > execution tests? And, why only for Fortran? Is this behavior generally > intentional -- of course, bigger testing coverage is nice, but this seems > a bit arbitrary to me? You're right, it looks odd, but I can't say whether it's right or wrong. Sometimes these things just grow over the years. Fortran people might want to take a closer look to see how they want the tests to be run now. gfortran.fortran-torture/compile has torture tests for Fortran compiles, and C has torture tests for both compile and execute in a couple of places. Janis
Re: converting rtx object to the assembly instruction.
Viktor Pobedin writes: > Is there a simple way to convert rtx object to the assemble > insutruction? Ideally I would like to have function something like: > const char *rtx2asm(rtx insn); > returning a string with the asm instruction for the insn. > > Closest thing that I found is the final_scan_insn function in final.c > but unfortunatelly it outputs the asm string to the file so it makes it > not usefull for my purposes. Yeah, I'm afraid that's all there is. Richard
Re: GCC for Android Shell
On 13 August 2013 18:27, Piotr Miłek wrote: > Hi, > Can we send me the compiled gcc and gcc for Android Shell (armeabi). I > would like to have data after uncpack with a minimum size 50 MB. Sory > my bad English. This question is off-topic for this mailing list, questions about using and installing GCC should be sent to gcc-h...@gcc.gnu.org. The GCC project does not provide compiled versions of GCC. You can get source code from GCC, but you need to get compiled versions from elsewhere, maybe from the Android project.
Re: fatal error: gnu/stubs-32.h: No such file
(catching up on old email) On Jul 8, 2013, Gabriel Dos Reis wrote: > On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski wrote: >> On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis >> wrote: >>> On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely >>> wrote: On 7 July 2013 21:33, Gabriel Dos Reis wrote: > How about not enabling multi lib build by default on targets we now that > will fail anyway? I have the suspicion this problem is unique to > openSUSE, > so we can take care of that. >> I think disable multilib by default is a mistake and is a broken >> choice for broken distros which don't install the 32bit development by >> default when you install the development part. > Why do you think it is a broken choice? > Personally, I don't see anything broken with that. The world we are > in today is very different from a decade ago. More than a decade ago, > a multilib build by default -probably- made sense; I don't see that today. Heh. Back in 1999, I had a patch accepted that disabled the 64-bit multilibs on mips*-*-* if we couldn't link a trivial program due to missing 64-bit libraries on an IRIX5 box I used to have access to for GCC testing back then. It is a very different world indeed: now it's the 32-bit libs that are frequently not available ;-) trunk rev 26355, git commit a48ef8ee5c527137faa2aec5b9101ad63d41fbd6, if anyone's interested. FWIW, that patch was removed at a later point, for reasons I no longer recall. It surely didn't meet all the requirements mentioned in this thread. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
