Re: dragonegg in FSF gcc?
Hi Jonathan, egcs code was always license-compatible with GCC and was always assigned to the FSF The difference is quite significant. both dragonegg and LLVM are license-compatible with GCC. The dragonegg code is licensed under GPLv2 or later, while LLVM is licensed under the University of Illinois/NCSA Open Source License, which is GPL compatible according to http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses The dragonegg plugin, being a combination of these plus GCC, is therefore GPLv3. You are of course quite right that neither LLVM nor dragonegg has its copyright assigned to the FSF. Ciao, Duncan.
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote: > On 12 April 2010 00:38, Dave Korn wrote: > > On 11/04/2010 22:42, Manuel López-Ibáñez wrote: > > > >> [ ... ] lack of test results in some platforms does not mean > >> that GCC developers are uninterested on supporting those platforms and > >> much less that they are against supporting those platforms. The GCC > >> community haven't forbidden anyone from contributing to support any > >> platform in GCC. > > > > I don't know who you're talking to, but it sure isn't to me or about > > anything remotely like anything I said. Put your straw man away. > > I am just trying to negate what a casual reader might conclude from > Jack's original comment about gnulinux mono-culture and your analysis. > I understand that you (and perhaps even Jack) do not actually mean to > say that but the above sentiment is out there, specially among > bsd/darwin users, so let's try not to reinforce it. > > Cheers, > > Manuel. Manuel, What I meant to say was that the reality of the situation is that 90%+ of the code (by line) is probably created by paid employees and the way things have shaken out has placed the bulk of those on linux. So FSF gcc will have to go out of its way to try to limit the monoculture tendencies that this will naturally cause. The llvm project has this issue probably less for linux than for other surviving platforms (like Solaris, etc). Jack
Re: dragonegg in FSF gcc?
Jack Howarth wrote: Manuel, What I meant to say was that the reality of the situation is that 90%+ of the code (by line) is probably created by paid employees and the way things have shaken out has placed the bulk of those on linux. Just a note, AdaCore is certainly not Linux-only-centric :-)
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth wrote: > On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote: >> On 12 April 2010 00:38, Dave Korn wrote: >> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote: >> > >> >> [ ... ] lack of test results in some platforms does not mean >> >> that GCC developers are uninterested on supporting those platforms and >> >> much less that they are against supporting those platforms. The GCC >> >> community haven't forbidden anyone from contributing to support any >> >> platform in GCC. >> > >> > I don't know who you're talking to, but it sure isn't to me or about >> > anything remotely like anything I said. Put your straw man away. >> >> I am just trying to negate what a casual reader might conclude from >> Jack's original comment about gnulinux mono-culture and your analysis. >> I understand that you (and perhaps even Jack) do not actually mean to >> say that but the above sentiment is out there, specially among >> bsd/darwin users, so let's try not to reinforce it. >> >> Cheers, >> >> Manuel. > > Manuel, > What I meant to say was that the reality of the situation is > that 90%+ of the code (by line) is probably created by paid > employees and the way things have shaken out has placed the bulk > of those on linux. So FSF gcc will have to go out of its way to > try to limit the monoculture tendencies that this will naturally > cause. The llvm project has this issue probably less for linux > than for other surviving platforms (like Solaris, etc). Err, well. I do not see how most of the code is OS specific anyway - there is _very_ little code in GCC that is OS specific. Richard. > Jack > >
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote: > On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth > wrote: > > On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote: > >> On 12 April 2010 00:38, Dave Korn wrote: > >> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote: > >> > > >> >> [ ... ] lack of test results in some platforms does not mean > >> >> that GCC developers are uninterested on supporting those platforms and > >> >> much less that they are against supporting those platforms. The GCC > >> >> community haven't forbidden anyone from contributing to support any > >> >> platform in GCC. > >> > > >> > I don't know who you're talking to, but it sure isn't to me or about > >> > anything remotely like anything I said. Put your straw man away. > >> > >> I am just trying to negate what a casual reader might conclude from > >> Jack's original comment about gnulinux mono-culture and your analysis. > >> I understand that you (and perhaps even Jack) do not actually mean to > >> say that but the above sentiment is out there, specially among > >> bsd/darwin users, so let's try not to reinforce it. > >> > >> Cheers, > >> > >> Manuel. > > > > Manuel, > > What I meant to say was that the reality of the situation is > > that 90%+ of the code (by line) is probably created by paid > > employees and the way things have shaken out has placed the bulk > > of those on linux. So FSF gcc will have to go out of its way to > > try to limit the monoculture tendencies that this will naturally > > cause. The llvm project has this issue probably less for linux > > than for other surviving platforms (like Solaris, etc). > > Err, well. I do not see how most of the code is OS specific > anyway - there is _very_ little code in GCC that is OS specific. > > Richard. Richard, Except for LTO (for which dragon-egg represents a way around since we can use the llvm's libLTO with that). In fact, dragon-egg should be welcomed as a way to directly compare the two approaches to LTO from within a single compiler (and perhaps prove FSF gcc's choice superior). Jack > > > Jack > > > >
Re: dragonegg in FSF gcc?
On 12/04/2010 07:47, Manuel López-Ibáñez wrote: > On 12 April 2010 00:38, Dave Korn wrote: >> On 11/04/2010 22:42, Manuel López-Ibáñez wrote: >> >>> [ ... ] lack of test results in some platforms does not mean >>> that GCC developers are uninterested on supporting those platforms and >>> much less that they are against supporting those platforms. The GCC >>> community haven't forbidden anyone from contributing to support any >>> platform in GCC. >> I don't know who you're talking to, but it sure isn't to me or about >> anything remotely like anything I said. Put your straw man away. > > I am just trying to negate what a casual reader might conclude from > Jack's original comment about gnulinux mono-culture and your analysis. > I understand that you (and perhaps even Jack) do not actually mean to > say that but the above sentiment is out there, specially among > bsd/darwin users, so let's try not to reinforce it. I had never even heard such a suggestion, and wouldn't have known it was out there if you hadn't raised it! Could anyone really believe that without being a grade A tinfoil-hat wearing crazy? More precisely, could anyone capable of the kind of rational thought processes that they'd need to have in order to be able to make any kind of contribution to the GCC project really believe that? I'm not convinced that we need to worry much about what generic non-contributing internet kooks, trolls and idiots think. Nope, as far as I'm concerned, there's a preponderance of gnu-linux-centricity just because that's where most of the people who can be bothered to contribute are at, and if other platforms feel neglected, there's absolutely nothing to stop them stepping up to the plate and getting involved. Heh, I work on Windows, if any OS was getting excluded for political reasons I surely ought to be the first to know! As Richard points out elsethread, GCC is not very OS specific. There *is* occasionally some tendency towards all-the-world's-an-ELF-ism, although even that isn't any deliberate policy but just the result of people not being aware of the attributes of other platforms or the semantic differences between their otherwise-similar concepts. LTO is the first big example, but there are numerous minor things that rely implicitly on such features as (e.g.) leaving undefined references to be resolved at load-time. (Yes, it makes vague linkage a right PITA not being able to do that, sigh. Don't think we'll ever be able to avoid violating the ODR with typeinfos on Windows and having to rely on full name-string comparisons always.) cheers, DaveK
i386 SSE Test Question
Hi, I was testing i386-rtems4.10 and 225 tests failed on the target because it does not have any SSE flavor. It is the last failures in http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00954.html FAIL: gcc.target/i386/sse-10.c execution test FAIL: gcc.target/i386/sse-11.c execution test . FAIL: gcc.target/i386/sse3-movshdup.c execution test FAIL: gcc.target/i386/sse3-movsldup.c execution test ... FAIL: gcc.target/i386/vperm-v4sf-1.c execution test FAIL: gcc.target/i386/vperm-v4si-1.c execution test A while back, some tests had run-time checks added to ensure they were on a CPU with the proper support. Are these tests doing that or is there another issue? Thanks. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: i386 SSE Test Question
On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill wrote: > Hi, > > I was testing i386-rtems4.10 and 225 > tests failed on the target because it > does not have any SSE flavor. It is > the last failures in > > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00954.html > > FAIL: gcc.target/i386/sse-10.c execution test > FAIL: gcc.target/i386/sse-11.c execution test > . > FAIL: gcc.target/i386/sse3-movshdup.c execution test > FAIL: gcc.target/i386/sse3-movsldup.c execution test > ... > FAIL: gcc.target/i386/vperm-v4sf-1.c execution test > FAIL: gcc.target/i386/vperm-v4si-1.c execution test > > > A while back, some tests had run-time > checks added to ensure they were on a > CPU with the proper support. Are these > tests doing that or is there another > issue? They do it via sse2-check.h and cpuid.h. Try to figure out why that doesn't work for your CPU (which is ...?) Richard. > Thanks. > > -- > Joel Sherrill, Ph.D. Director of Research& Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > > >
Re: dragonegg in FSF gcc?
On 12 April 2010 16:18, Dave Korn wrote: > > Could anyone really believe that without being a grade A tinfoil-hat wearing > crazy? More precisely, could anyone capable of the kind of rational thought Then, you do not read LWN comments, OS news or BSD mailing lists. You probably do well for your sanity ;-). But I do not think they are crazy, trolls or idiots, just uninformed, misinformed, disfranchised or unwilling to understand. The fact is that it is (perceived as) more difficult to contribute to GCC than LLVM/Clang for the reasons we all know already. And the LLVM/Clang project has done an excellent job at presenting itself as an alternative to GCC for those "neglected" platforms. I am not saying this in a negative tone. I honestly think GCC could learn a lot about marketing and usability details from LLVM. Cheers, Manuel.
Re: i386 SSE Test Question
On 04/12/2010 09:05 AM, Richard Guenther wrote: On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill wrote: Hi, I was testing i386-rtems4.10 and 225 tests failed on the target because it does not have any SSE flavor. It is the last failures in http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00954.html FAIL: gcc.target/i386/sse-10.c execution test FAIL: gcc.target/i386/sse-11.c execution test . FAIL: gcc.target/i386/sse3-movshdup.c execution test FAIL: gcc.target/i386/sse3-movsldup.c execution test ... FAIL: gcc.target/i386/vperm-v4sf-1.c execution test FAIL: gcc.target/i386/vperm-v4si-1.c execution test A while back, some tests had run-time checks added to ensure they were on a CPU with the proper support. Are these tests doing that or is there another issue? They do it via sse2-check.h and cpuid.h. Try to figure out why that doesn't work for your CPU (which is ...?) qemu with no cpu argument specified. So qemu32. It does run OK when I change the cpu model to 486 or pentium. cpu_id returns this for the qemu32 cpu model (test fails) a=0x633 b=0x800 c=0x1 d=0x781abfd this for the 486 model (test works) a=0x0 b=0x0 c=0x0 d=0x0 this for pentium (test works) a=0x543 b=0x800 c=0x0 d=0x8001bf and this for "coreduo" (test fails) a=0x6e8 b=0x800 c=0x9 d=0x789fbff Is qemu reporting that it supports SSE and not doing a good enough job to make gcc happen? --joel Richard. Thanks. -- Joel Sherrill, Ph.D. Director of Research&Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: i386 SSE Test Question
On Mon, Apr 12, 2010 at 09:47:04AM -0500, Joel Sherrill wrote: > qemu with no cpu argument specified. So qemu32. > It does run OK when I change the cpu model to 486 > or pentium. > > Is qemu reporting that it supports SSE and not doing a good > enough job to make gcc happen? I think that's quite likely. -Nathan
Re: i386 SSE Test Question
On Mon, Apr 12, 2010 at 7:47 AM, Joel Sherrill wrote: > On 04/12/2010 09:05 AM, Richard Guenther wrote: >> >> On Mon, Apr 12, 2010 at 4:00 PM, Joel Sherrill >> wrote: >> >>> >>> Hi, >>> >>> I was testing i386-rtems4.10 and 225 >>> tests failed on the target because it >>> does not have any SSE flavor. It is >>> the last failures in >>> >>> http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00954.html >>> >>> FAIL: gcc.target/i386/sse-10.c execution test >>> FAIL: gcc.target/i386/sse-11.c execution test >>> . >>> FAIL: gcc.target/i386/sse3-movshdup.c execution test >>> FAIL: gcc.target/i386/sse3-movsldup.c execution test >>> ... >>> FAIL: gcc.target/i386/vperm-v4sf-1.c execution test >>> FAIL: gcc.target/i386/vperm-v4si-1.c execution test >>> >>> >>> A while back, some tests had run-time >>> checks added to ensure they were on a >>> CPU with the proper support. Are these >>> tests doing that or is there another >>> issue? >>> >> >> They do it via sse2-check.h and cpuid.h. Try to figure out why >> that doesn't work for your CPU (which is ...?) >> >> > > qemu with no cpu argument specified. So qemu32. > It does run OK when I change the cpu model to 486 > or pentium. > > cpu_id returns this for the qemu32 cpu model (test fails) > > a=0x633 b=0x800 c=0x1 d=0x781abfd > > this for the 486 model (test works) > > a=0x0 b=0x0 c=0x0 d=0x0 > > this for pentium (test works) > > a=0x543 b=0x800 c=0x0 d=0x8001bf > > and this for "coreduo" (test fails) > > a=0x6e8 b=0x800 c=0x9 d=0x789fbff > > Is qemu reporting that it supports SSE and not doing a good > enough job to make gcc happen? > I think your qemu lied. It reports SSE in cpuid, but it doesn't support it. -- H.J.
Re: dragonegg in FSF gcc?
If the dragonegg and/or LLVM copyright was assigned to the FSF, which is a prerequisit for anything included in GCC and not what license the program is under currently, then I'm quite sure that the GCC maintainers would be more than happy to include both.
Re: i386 SSE Test Question
On 04/12/2010 09:56 AM, Nathan Froyd wrote: On Mon, Apr 12, 2010 at 09:47:04AM -0500, Joel Sherrill wrote: qemu with no cpu argument specified. So qemu32. It does run OK when I change the cpu model to 486 or pentium. Is qemu reporting that it supports SSE and not doing a good enough job to make gcc happen? I think that's quite likely. I've changed my script to run it with "-cpu 486" and started another run. In a few hours, there should be an updated run. Thanks. --joel -Nathan
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 11:00:13AM -0400, Alfred M. Szmidt wrote: > If the dragonegg and/or LLVM copyright was assigned to the FSF, which > is a prerequisit for anything included in GCC and not what license the > program is under currently, then I'm quite sure that the GCC > maintainers would be more than happy to include both. I don't think anyone was proposing llvm be added to FSF gcc but rather just dragon-egg (so the interfaces to FSF gcc could be kept updated more easily). The dependency on llvm would be treated as any other (ppl, cloog, gmp, etc) and the user would have to provide their own copy out of tree (although an in-tree build could be supported). Jack
Re: Error while building GCC 4.5 (MinGW)
Thanks for the prompt reply and suggestions. I checked the config.log as per your suggestion. >> Check the config.log file for details. A successful build should show >> something like this >> configure:5634: checking for the correct version of the gmp/mpfr/mpc >> libraries >> configure:5665: gcc -o conftest -g -O2 conftest.c -lmpc -lmpfr >> -lgmp >&5 >> configure:5665: $? = 0 >> configure:5666: result: yes >>Your file should have an error here. Please check the following relevant information present in the config.log as follows: = config.log == configure:5615: $? = 0 configure:5616: result: yes configure:5634: checking for the correct version of the gmp/mpfr/mpc libraries configure:5665: i386-pc-mingw32msvc-gcc -o conftest.exe -O2 -I/home/foo/mpc/prefix//include -I/home/foo/mpc/prefix//include -I/home/foo/mpc/prefix//includeconftest.c -L/home/foo/mpc/prefix//lib -L/home/foo/mpc/prefix//lib -L/home/foo/mpc/prefix//lib -lmpc -lmpfr -lgmp >&5 /tmp/ccYkD69D.o:conftest.c:(.text+0x25): undefined reference to `_mpfr_init' /tmp/ccYkD69D.o:conftest.c:(.text+0x2d): undefined reference to `_mpfr_init' /tmp/ccYkD69D.o:conftest.c:(.text+0x43): undefined reference to `_mpfr_atan2' /tmp/ccYkD69D.o:conftest.c:(.text+0x55): undefined reference to `_mpfr_erfc' /tmp/ccYkD69D.o:conftest.c:(.text+0x6c): undefined reference to `_mpfr_subnormalize' /tmp/ccYkD69D.o:conftest.c:(.text+0x79): undefined reference to `_mpfr_clear' /tmp/ccYkD69D.o:conftest.c:(.text+0x84): undefined reference to `_mpfr_clear' /tmp/ccYkD69D.o:conftest.c:(.text+0x95): undefined reference to `_mpc_init2' /tmp/ccYkD69D.o:conftest.c:(.text+0xab): undefined reference to `_mpc_set_ui_ui' /tmp/ccYkD69D.o:conftest.c:(.text+0xbd): undefined reference to `_mpc_cosh' /tmp/ccYkD69D.o:conftest.c:(.text+0xd3): undefined reference to `_mpc_pow' /tmp/ccYkD69D.o:conftest.c:(.text+0xe5): undefined reference to `_mpc_acosh' /tmp/ccYkD69D.o:conftest.c:(.text+0xed): undefined reference to `_mpc_clear' collect2: ld returned 1 exit status configure:5665: $? = 1 configure:5669: result: no configure:5690: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations. Source code for these libraries can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP, MPFR and/or MPC from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages. = config.log == The mingw toolchain was successfully built with earlier versions(gcc-4.5-20091105). However, the above problem is faced after introduction of "MPC" libraries. Please let me know if there are any particular steps to be followed to build mingw toolchain with mpc libraries. Regards, Brew --- On Fri, 4/9/10, Jim Wilson wrote: > From: Jim Wilson > Subject: Re: Error while building GCC 4.5 (MinGW) > To: "Name lastlong" > Cc: gcc@gcc.gnu.org > Date: Friday, April 9, 2010, 11:48 PM > On 04/08/2010 07:21 AM, Name lastlong > wrote: > > > =error > > checking for the correct version of the gmp/mpfr/mpc > libraries... no > > configure: error: Building GCC requires GMP 4.2+, MPFR > 2.3.1+ and MPC 0.8.0+. > > > error > > Check the config.log file for details. A successful > build should show something like this > configure:5634: checking for the correct version of the > gmp/mpfr/mpc libraries > configure:5665: gcc -o conftest -g -O2 > conftest.c -lmpc -lmpfr -lgmp >&5 > configure:5665: $? = 0 > configure:5666: result: yes > > Your file should have an error here. > > Jim >
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth wrote: >> Err, well. I do not see how most of the code is OS specific >> anyway - there is _very_ little code in GCC that is OS specific. >> >> Richard. > > Richard, > Except for LTO (for which dragon-egg represents a way around > since we can use the llvm's libLTO with that). No, LTO is in fact not very OS specific at all. Just because your favorite platform isn't supported, does not mean that something in GCC is linux-specific. LTO works on all targets with ELF binaries, and patches exist to make it work with COFF binaries too. You could add MACH-O support, it shouldn't be very difficult to do if you can follow Dave's example. But instead you go to LLVM, which is, bottom line, not a solution for GCC -- and that's what this thread is all about to me. Ciao! Steven
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 05:45:52PM +0200, Steven Bosscher wrote: > On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth > wrote: > >> Err, well. I do not see how most of the code is OS specific > >> anyway - there is _very_ little code in GCC that is OS specific. > >> > >> Richard. > > > > Richard, > > Except for LTO (for which dragon-egg represents a way around > > since we can use the llvm's libLTO with that). > > No, LTO is in fact not very OS specific at all. Just because your > favorite platform isn't supported, does not mean that something in GCC > is linux-specific. LTO works on all targets with ELF binaries, and > patches exist to make it work with COFF binaries too. You could add > MACH-O support, it shouldn't be very difficult to do if you can follow > Dave's example. > > But instead you go to LLVM, which is, bottom line, not a solution for > GCC -- and that's what this thread is all about to me. I have opened PR43729, "MachO LTO support needed for darwin", to discuss this. Can you point me at Dave's previous patches that added LTO-suppport to a non-ELF platform? Also, I was unaware that this feat had been performed on a target which both is non-ELF and non-binutils. Jack > > Ciao! > Steven
Re: dragonegg in FSF gcc?
On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth wrote: > I have opened PR43729, "MachO LTO support needed for darwin", to discuss > this. Can you point me at Dave's previous patches that added LTO-suppport > to a non-ELF platform? I've linked your new PR to the existing "LTO doesn't work on non-ELF platform" PR. We even discussed Mach-O already there. > Also, I was unaware that this feat had been performed > on a target which both is non-ELF and non-binutils. AFAIK cygwin also uses binutils, but no changes are needed to make LTO work with the collect2 approach (Dave is that correct?). Ciao! Steven
Release novops attribute for external use?
Hello, One of our engineers requested a feature so that compiler can avoid to re-load variables after a function call if it is known not to write to memory. It should slash considerable code size in our applications. I found the existing "pure" and "const" cannot meet his requirements because the function is optimized out if it doesn't return a value. I almost started to implement a new attribute in our own port, only to find out "novops" attribute is exact what we want. Why "novops" is only limited to internal use? Does it has any other implication? Could we release this attribute for external use as well? Thanks, Bingfeng Mei
Re: Release novops attribute for external use?
On 04/12/2010 05:27 PM, Bingfeng Mei wrote: > Hello, > One of our engineers requested a feature so that > compiler can avoid to re-load variables after a function > call if it is known not to write to memory. It should > slash considerable code size in our applications. I found > the existing "pure" and "const" cannot meet his requirements > because the function is optimized out if it doesn't return > a value. If a function doesn't write to memory and it doesn't return a value, what is the point of calling it? Andrew.
Is nonoverlapping_memrefs_p wrong for unknown offsets?
We recently tracked down an aliasing bug in gcc-4.4.3 (found by our
TILE-Gx back end, not yet ready to contribute), and we wanted to make
sure the fix is right.
try_crossjump_bb identifies some common insns in SPEC2000.eon and uses
merge_memattrs to merge them. To do so, it has to unify their
aliasing data such that any insn that aliased either of the original
insns aliases the merged insn. In our case we have two
identical-looking insns that are actually referencing different stack
spill slots, so their MEM_OFFSETs are different. merge_memattrs
correctly NULLs out the MEM_OFFSET of the merged insn to indicate it's
not sure what the offset is, although it leaves a non-NULL MEM_SIZE:
else if (MEM_OFFSET (x) != MEM_OFFSET (y))
{
set_mem_offset (x, 0);
set_mem_offset (y, 0);
}
Later, nonoverlapping_memrefs_p decides that this merged insn does not
alias another spill slot insn (one which has a valid MEM_OFFSET), but
in fact they do alias. The scheduler then creates an incorrect schedule.
The bug seems to be that nonoverlapping_memrefs_p does not
conservatively assume that a NULL MEM_OFFSET can alias any offset,
despite comments to the contrary. Instead it essentially treats it
like a known offset of zero. We don't understand why it doesn't just
give up if the references have the same base but one of the offsets is
unknown. A minimal patch to do so would look like this, but if this
is correct, then code after this short-circuit can be simplified,
yielding a larger patch (which I could produce):
--- //tilera/branch/gcc/tools/gcc/gcc/alias.c 2010/04/12 10:29:48
+++ //tilera/branch/gcc/tools/gcc/gcc/alias.c 2010/04/12 10:36:35
@@ -2150,6 +2150,11 @@
: MEM_SIZE (rtly) ? INTVAL (MEM_SIZE (rtly)) :
-1);
+ /* If we don't have an offset for both memrefs, we have to assume they can
+ be anywhere in the DECL's MEM. */
+ if (!moffsetx || !moffsety)
+return 0;
+
/* If we have an offset for either memref, it can update the values computed
above. */
if (moffsetx)
-Mat
missing plugin headers
On darwin, we are missing a required header file in the /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include/config installation directory. The file gcc/config/darwin-sections.def needs to be installed in plugin/include/config. What is the 'correct' way to achieve this (short of resorting to appending it to tm_file in gcc/config.gcc)? Thanks in advance for any advice. Jack
Re: Deprecation of -I- and -iquote
> "Rodolfo" == Rodolfo Lima writes: Rodolfo> I wonder what's the current state of -I- vs. -iquote, is there anyone Rodolfo> interested in fixing the fact that -iquote doesn't replace -I- Rodolfo> functionality, needed for out-of-source precompiled header utilization? AFAIK the patch is still waiting for a review. I don't know what the hangup is. Perhaps it needs more frequent pings. Tom
Re: Is nonoverlapping_memrefs_p wrong for unknown offsets?
On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter wrote:
> try_crossjump_bb identifies some common insns in SPEC2000.eon and uses
> merge_memattrs to merge them. To do so, it has to unify their
> aliasing data such that any insn that aliased either of the original
> insns aliases the merged insn. In our case we have two
> identical-looking insns that are actually referencing different stack
> spill slots, so their MEM_OFFSETs are different. merge_memattrs
> correctly NULLs out the MEM_OFFSET of the merged insn to indicate it's
> not sure what the offset is, although it leaves a non-NULL MEM_SIZE:
>
> else if (MEM_OFFSET (x) != MEM_OFFSET (y))
> {
> set_mem_offset (x, 0);
> set_mem_offset (y, 0);
> }
>
> Later, nonoverlapping_memrefs_p decides that this merged insn does not
> alias another spill slot insn (one which has a valid MEM_OFFSET), but
> in fact they do alias. The scheduler then creates an incorrect schedule.
Sounds like http://gcc.gnu.org/PR42509 -- does that help?
Ciao!
Steven
Re: Is nonoverlapping_memrefs_p wrong for unknown offsets?
Great, thanks -- I should have re-checked bugzilla after we tracked
this down.
We also noticed a few minor performance issues along the way.
It would be better if merge_memattrs did a min/max thing with
offset/size to choose an offset and size that encompass both original
references, rather than giving up on the offset altogether when the
offsets don't match exactly.
Also, flow_find_cross_jump coarsens the aliasing information as it
scans, so even if it gives up because it doesn't find enough insns to
merge, the aliasing data is lost. We implemented a split of the scan
from the actual destructive merging.
-Mat
Steven Bosscher writes:
> On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter wrote:
> > try_crossjump_bb identifies some common insns in SPEC2000.eon and uses
> > merge_memattrs to merge them. To do so, it has to unify their
> > aliasing data such that any insn that aliased either of the original
> > insns aliases the merged insn. In our case we have two
> > identical-looking insns that are actually referencing different stack
> > spill slots, so their MEM_OFFSETs are different. merge_memattrs
> > correctly NULLs out the MEM_OFFSET of the merged insn to indicate it's
> > not sure what the offset is, although it leaves a non-NULL MEM_SIZE:
> >
> > else if (MEM_OFFSET (x) != MEM_OFFSET (y))
> > {
> > set_mem_offset (x, 0);
> > set_mem_offset (y, 0);
> > }
> >
> > Later, nonoverlapping_memrefs_p decides that this merged insn does not
> > alias another spill slot insn (one which has a valid MEM_OFFSET), but
> > in fact they do alias. The scheduler then creates an incorrect schedule.
>
> Sounds like http://gcc.gnu.org/PR42509 -- does that help?
>
> Ciao!
> Steven
Re: Error while building GCC 4.5 (MinGW)
On Mon, 2010-04-12 at 08:34 -0700, Name lastlong wrote: > Please check the following relevant information present in the config.log > as follows: Now that you can see what is wrong, you should try to manually reproduce the error. Check the libraries to see if they are OK, and if the right versions of the libraries are being linked in. Look to see where the undefined references are coming from. Etc. > Please let me know if there are any particular steps to be followed to build > mingw toolchain with mpc libraries. I have no idea. I haven't built a mingw toolchain anytime recently. Jim
RE: dragonegg in FSF gcc?
> -Original Message- > From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com] > Sent: Monday, April 12, 2010 8:27 AM > To: Dave Korn > Cc: Jack Howarth; Steven Bosscher; Duncan Sands; gcc@gcc.gnu.org > Subject: Re: dragonegg in FSF gcc? > > The fact is that it is (perceived as) more difficult to contribute to > GCC than LLVM/Clang for the reasons we all know already. And the > LLVM/Clang project has done an excellent job at presenting itself as > an alternative to GCC for those "neglected" platforms. I am not saying > this in a negative tone. I honestly think GCC could learn a lot about > marketing and usability details from LLVM. >From my perspective (and someone correct me if I'm wrong) it is easier for >LLVM to do such marketing and focus on usability details because they seem to >have a central driver to the project, whether person/group >(founder(s)/champion(s)). GCC is, what I would call, aggressively >decentralized; Who would do such marketing? Who decides what marketing to do? >Who decides the usability details? Who would work on it? GCC is the epitome of >the saying "If you want something done, do it yourself." There is no central >authority who can, or will, make a decision about this. There is a Steering >Committee for GCC, but as they keep saying at the GCC Summits, their power and >scope is very limited. Eric Weddington
Re: dragonegg in FSF gcc?
On 12/04/2010 17:03, Steven Bosscher wrote: > On Mon, Apr 12, 2010 at 5:59 PM, Jack Howarth wrote: > >> I have opened PR43729, "MachO LTO support needed for darwin", to discuss >> this. Can you point me at Dave's previous patches that added LTO-suppport >> to a non-ELF platform? > > I've linked your new PR to the existing "LTO doesn't work on non-ELF > platform" PR. We even discussed Mach-O already there. > >> Also, I was unaware that this feat had been performed >> on a target which both is non-ELF and non-binutils. > > AFAIK cygwin also uses binutils, but no changes are needed to make LTO > work with the collect2 approach (Dave is that correct?). Binutils for COFF targets needed a patch to allow sections to be byte-aligned and byte-packed, as it wasn't originally possible to use any alignment directive to reduce the section alignment below the default, and the zip-compressed data sections need to be exactly sized to the data they contain rather than padded up to the default section alignment of 4. If MachO can do that already, it won't need any changes. Or it could be fixed in GCC by modifying the format of the compressed sections to be self-describing w.r.t valid data length in some way - this would probably be the better thing to do in the long run. cheers, DaveK
Re: Release novops attribute for external use?
On 12/04/2010 17:33, Andrew Haley wrote: > On 04/12/2010 05:27 PM, Bingfeng Mei wrote: >> Hello, >> One of our engineers requested a feature so that >> compiler can avoid to re-load variables after a function >> call if it is known not to write to memory. It should >> slash considerable code size in our applications. I found >> the existing "pure" and "const" cannot meet his requirements >> because the function is optimized out if it doesn't return >> a value. > > If a function doesn't write to memory and it doesn't return a > value, what is the point of calling it? Delay-loop! That's about the only thing I can think of anyway :-) cheers, DaveK
Re: Release novops attribute for external use?
On 04/12/2010 07:22 PM, Dave Korn wrote: > On 12/04/2010 17:33, Andrew Haley wrote: >> On 04/12/2010 05:27 PM, Bingfeng Mei wrote: >>> Hello, >>> One of our engineers requested a feature so that >>> compiler can avoid to re-load variables after a function >>> call if it is known not to write to memory. It should >>> slash considerable code size in our applications. I found >>> the existing "pure" and "const" cannot meet his requirements >>> because the function is optimized out if it doesn't return >>> a value. >> >> If a function doesn't write to memory and it doesn't return a >> value, what is the point of calling it? > > Delay-loop! That's about the only thing I can think of anyway :-) I was thinking about non-memory-mapped I/O, a la x86 I/O ports. But yeah. :-) Andrew.
Re: GCC-TM dependency build
On 04/09/2010 03:16 PM, Jonathan Wakely wrote: Is the only C++ header that causes a problem? is exactly equivalent to because it only declares macros, which are not in namespace std anyway. So if that's the only problem, using instead of would solve it. No, we also use , so avoiding the C wrapper headers doesn't really help. r~
Re: Release novops attribute for external use?
On 12/04/2010 19:04, Andrew Haley wrote: > I was thinking about non-memory-mapped I/O, a la x86 I/O ports. I've always thought that was a bad misnomer. Isn't it just an alternative memory-mapped address space pretty much like main memory (regardless that the mapped devices may have some fairly non-standard characteristics)? Certainly from the compiler's point of view it's got to count as "memory"; it's somewhere values come from and go to and are "externally visible". cheers, DaveK
Re: Deprecation of -I- and -iquote
Tom Tromey wrote: > AFAIK the patch is still waiting for a review. I don't know what the > hangup is. Perhaps it needs more frequent pings. So, whoever is responsible for this, please step forward :) I'll test the patch when I get home, but I have no knowledge of gcc's internals to make a thorough check. The message gcc output, saying that -iquote should be used instead of -I- is just plain wrong. Seeing that 4.5.0 release is just around the corner, is it feasible to have this patch committed into 4.5 branch? Best regards, Rodolfo Lima
Re: Error while building GCC 4.5 (MinGW)
On 12/04/2010 16:34, Name lastlong wrote: > = config.log == > configure:5615: $? = 0 > configure:5616: result: yes > configure:5634: checking for the correct version of the gmp/mpfr/mpc libraries > configure:5665: i386-pc-mingw32msvc-gcc -o conftest.exe -O2 > -I/home/foo/mpc/prefix//include -I/home/foo/mpc/prefix//include > -I/home/foo/mpc/prefix//includeconftest.c -L/home/foo/mpc/prefix//lib > -L/home/foo/mpc/prefix//lib -L/home/foo/mpc/prefix//lib -lmpc -lmpfr -lgmp >&5 > /tmp/ccYkD69D.o:conftest.c:(.text+0x25): undefined reference to `_mpfr_init' > /tmp/ccYkD69D.o:conftest.c:(.text+0x2d): undefined reference to `_mpfr_init' > /tmp/ccYkD69D.o:conftest.c:(.text+0x43): undefined reference to `_mpfr_atan2' > /tmp/ccYkD69D.o:conftest.c:(.text+0x55): undefined reference to `_mpfr_erfc' > /tmp/ccYkD69D.o:conftest.c:(.text+0x6c): undefined reference to > `_mpfr_subnormalize' > /tmp/ccYkD69D.o:conftest.c:(.text+0x79): undefined reference to `_mpfr_clear' > /tmp/ccYkD69D.o:conftest.c:(.text+0x84): undefined reference to `_mpfr_clear' > /tmp/ccYkD69D.o:conftest.c:(.text+0x95): undefined reference to `_mpc_init2' > /tmp/ccYkD69D.o:conftest.c:(.text+0xab): undefined reference to > `_mpc_set_ui_ui' > /tmp/ccYkD69D.o:conftest.c:(.text+0xbd): undefined reference to `_mpc_cosh' > /tmp/ccYkD69D.o:conftest.c:(.text+0xd3): undefined reference to `_mpc_pow' > /tmp/ccYkD69D.o:conftest.c:(.text+0xe5): undefined reference to `_mpc_acosh' > /tmp/ccYkD69D.o:conftest.c:(.text+0xed): undefined reference to `_mpc_clear' > collect2: ld returned 1 exit status > configure:5665: $? = 1 > configure:5669: result: no This just looks like your mpfr and mpc libraries are completely busted. Cut and paste the command-line into a shell, and add "-v -Wl,-v -Wl,-Map,out.map". Take a look at the linker output and make sure it's linking against the mpc and mpfr library files that you expect it to be; take a look at those files with "nm" to see what symbols they define. This is /probably/ not a GCC bug, so maybe we should move it to the gcc-help list if something doesn't show up in the next round or two of debugging. cheers, DaveK
post linker phase - How To?
On Darwin we follow the collect2 phase with a call to dsymutil which post-processes the object to collect debug info into a separate module. At present this is done by tricking the driver into calling ld followed by dsymutils by appending the dsymutils call onto the end of LINK_COMMAND_SPEC. up to now that's been satisfactory -- but now we might need to change things .. either: (a) put a wrapper around the system-provided binary or (b) provide a replacement. Of course, I could do this completely outside the gcc scenario .. just tell the User "Oh, BTW you need to install XYZ to make this work"... I'd like to make it easier for them .. So... If I want to install a script (wrapper) that will end up installed in the same dir as gcc-xyz ... 1/ where do I put that in the GCC source tree? 2/ what do I need to modify in the mechanics to arrange it to get installed? Or: If I want to create a new post-collect phase --- is that already MACRO- ized in gcc or is that a Bigger Job ;-) ?? Iain
Re: Is nonoverlapping_memrefs_p wrong for unknown offsets?
On Mon, Apr 12, 2010 at 7:38 PM, Mat Hostetter wrote: > Also, flow_find_cross_jump coarsens the aliasing information as it > scans, so even if it gives up because it doesn't find enough insns to > merge, the aliasing data is lost. We implemented a split of the scan > from the actual destructive merging. Yes, I've noticed that before, too. Could you post your patch to gcc-patc...@gcc.gnu.org, if you have the necessary paperwork in place? Ciao! Steven
Re: Release novops attribute for external use?
On Mon, Apr 12, 2010 at 07:47:31PM +0100, Dave Korn wrote: > On 12/04/2010 19:04, Andrew Haley wrote: > > > I was thinking about non-memory-mapped I/O, a la x86 I/O ports. > > I've always thought that was a bad misnomer. Isn't it just an alternative > memory-mapped address space pretty much like main memory (regardless that the > mapped devices may have some fairly non-standard characteristics)? Certainly > from the compiler's point of view it's got to count as "memory"; it's > somewhere values come from and go to and are "externally visible". Then you can think about it as "does not alias any non-device memory", or any number of variants on that. -- Daniel Jacobowitz CodeSourcery
Re: may_be_unaligned_p bug?
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
> Index: tree-ssa-loop-ivopts.c
> ===
> --- tree-ssa-loop-ivopts.c(revision 158148)
> +++ tree-ssa-loop-ivopts.c(working copy)
> @@ -1537,16 +1537,18 @@ may_be_unaligned_p (tree ref, tree step)
>
>if (mode != BLKmode)
> {
> - double_int mul;
> - tree al = build_int_cst (TREE_TYPE (step),
> -GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT);
> + unsigned mode_align = GET_MODE_ALIGNMENT (mode);
>
> - if (base_align < GET_MODE_ALIGNMENT (mode)
> - || bitpos % GET_MODE_ALIGNMENT (mode) != 0
> - || bitpos % BITS_PER_UNIT != 0)
> + if (base_align < mode_align
> + || (bitpos % mode_align) != 0
> + || (bitpos % BITS_PER_UNIT) != 0)
> return true;
>
> - if (!constant_multiple_of (step, al, &mul))
> + if (toffset
> + && (highest_pow2_factor (toffset) * BITS_PER_UNIT) < mode_align)
> + return true;
> +
> + if ((highest_pow2_factor (step) * BITS_PER_UNIT) < mode_align)
> return true;
> }
>
Re: dragonegg in FSF gcc?
Weddington, Eric wrote: From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com] The fact is that it is (perceived as) more difficult to contribute to GCC than LLVM/Clang for the reasons we all know already. From my perspective (and someone correct me if I'm wrong) it is easier for LLVM to do such marketing and focus on usability details because they seem to have a central driver to the project, whether person/group (founder(s)/champion(s)). GCC is, what I would call, aggressively decentralized; Who would do such marketing? Who decides what marketing to do? Who decides the usability details? Who would work on it? GCC is the epitome of the saying "If you want something done, do it yourself." There is no central authority who can, or will, make a decision about this. There is a Steering Committee for GCC, but as they keep saying at the GCC Summits, their power and scope is very limited. Well, it is an open question (at least to me) whether you *want* a central driver. In late 2003, three national laboratories in the US wrote up a position paper on their needs in Fortran-land, and lamented the lack of a free Fortran compiler (they noted that there was g77, but it wasn't up to speed in Fortran-95 land, which they needed). This was my reply: http://gcc.gnu.org/ml/fortran/2003-11/msg00052.html With that answer, I essentially tossed $ 5 million away (the amount they estimated to be needed for a free Fortran 95 compiler, because, in a followup mail, I said "Anyway, we will produce a Fortran 95 compiler, regardless." -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: may_be_unaligned_p bug?
> I can confirm this fixes my test case. Had I known about > highest_pow2_factor() I might have come up with this myself ;-) OK, I'll do some testing with it tomorrow. Which GCC versions are affected? -- Eric Botcazou
Re: may_be_unaligned_p bug?
> OK, I'll do some testing with it tomorrow. Which GCC versions are affected? I tested trunk and an old 4.2.1 internal branch, and found the bug on both, so anything in between would be affected too. It goes back at least to this patch, which mostly fixed the bug: 2008-02-19 Christian Bruel Zdenek Dvorak * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Check step alignment. (our 4.2.1 branch, plus the above patch, plus your patch, works)
Re: specs question.
IainS writes:
> what is the expected behavior of ?
>
> %{.c|.cc|.for|.F90: foo }
>
> .. as I read gcc/gcc.c I would expect to get "foo" for command lines
> with files with these suffixes:
> .c
> .cc
> .for
> .F90
>
> but not otherwise (since it says . binds more strongly than |) ;
That sounds right to me. Do you see something different?
Ian
Re: post linker phase - How To?
IainS writes: > If I want to install a script (wrapper) that will end up installed in > the same dir as gcc-xyz ... > > 1/ where do I put that in the GCC source tree? Either in the gcc subdirectory or in some other top level subdirectory. > 2/ what do I need to modify in the mechanics to arrange it to get > installed? You just need to install it when "make install" is run. But note that gcc-xyx is normally installed in the bin directory $(bindir). That is the right place to install programs which you expect the user to run directly. If this program will only ever be run by the gcc driver, then you should install it in either the directory where cc1 is installed, $(libsubdir), or in the directory where helper tools like a cross-assembler are installed, $(tooldir). A program which is installed in $(libsubdir) would normally live in the gcc subdirectory. A program which is installed in $(tooldir) could live anywhere; see, e.g., the binutils Makefiles for how to install there. > Or: > If I want to create a new post-collect phase --- is that already > MACRO- > ized in gcc or is that a Bigger Job ;-) ?? As far as I know there is currently no post-collect phase. Ian
Re: specs question.
On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:
IainS writes:
what is the expected behavior of ?
%{.c|.cc|.for|.F90: foo }
.. as I read gcc/gcc.c I would expect to get "foo" for command lines
with files with these suffixes:
.c
.cc
.for
.F90
but not otherwise (since it says . binds more strongly than |) ;
That sounds right to me. Do you see something different
yeah .. we use it in Darwin's dsymutil spec.
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
o:a.out"
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}\n"
if you put "-lm" on the c/l dsymutil doesn't get called.
Almost as if ".m" was being treated as a regex rather than a
suffix... (but I don't think that's the whole story).
and I find that if I put .for|.f90 etc it makes no difference to
fortran getting debugged...
---
... if I take away the %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: }
It all works as expected...
I looked at the code (briefly) that parses the %{ } but it needs some
time to digest what's going on - so I thought asking would be a good
plan ;-)
Iain
Re: dragonegg in FSF gcc?
"Weddington, Eric" writes: >From my perspective (and someone correct me if I'm wrong) it is >easier for LLVM to do such marketing and focus on usability details >because they seem to have a central driver to the project, whether >person/group (founder(s)/champion(s)). GCC is, what I would call, >aggressively decentralized; Who would do such marketing? Who decides >what marketing to do? Who decides the usability details? Who would >work on it? GCC is the epitome of the saying "If you want something >done, do it yourself." There is no central authority who can, or >will, make a decision about this. There is a Steering Committee for >GCC, but as they keep saying at the GCC Summits, their power and >scope is very limited. Having a central driver would certainly help--though only to the extent that anybody listened. I have seen people complain that the gcc developers are ornery and difficult to work with. I've been reading the mailing lists with that in mind, and I actually don't see that very much. However, it only takes a very small number of mean-spirited messages to give that impression. What I do see is that relatively few gcc developers take the time to reach out to new people and help them become part of the community. I also see a lot of external patches not reviewed, and I see a lot of back-and-forth about patches which is simply confusing and offputting to those trying to contribute. Joining the gcc community requires a lot of self-motivation, or it takes being paid enough to get over the obstacles. There is also the matter of the old code base, the lack of a clean separation between passes, and, most important, weak internal documentation. For example, in my view of internal documentation: How to write a new backend: good. Details of RTL IR: adequate. Details of GIMPLE IR: poor. Details of tree IR: poor. How to write a new optimization pass: poor. How to write a new frontend: nonexistent. General overview of compiler source: nonexistent. Overview of internal compiler datastructures: nonexistent. I am as responsible for this state of affairs as anybody. Ian
Re: post linker phase - How To?
On 12 Apr 2010, at 23:30, Ian Lance Taylor wrote: IainS writes: If I want to install a script (wrapper) that will end up installed in the same dir as . If this program will only ever be run by the gcc driver, then you should install it in either the directory where cc1 is installed, $(libsubdir), This is the right place, at least for a wrapper... If we make a stand-alone replacement (one day) then maybe that could be put in $(bindir) I take it that, when called from a spec, any program in $(libsubdir) will get the right path by the automagic built into the compiler? Or: If I want to create a new post-collect phase --- is that already As far as I know there is currently no post-collect phase. This would be tidier than riding on the back of the LINK_COMMAND_SPEC. Any perception of the difficulty factor (1:10)..? Iain
Re: specs question.
IainS writes:
> yeah .. we use it in Darwin's dsymutil spec.
>
> %{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
> %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
>%{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
> o:a.out"
> %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}\n"
>
>
> if you put "-lm" on the c/l dsymutil doesn't get called.
Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver. It doesn't know the source
language of a .o file. So if you are linking, and passing .o files,
then this approach won't work.
Ian
Re: post linker phase - How To?
IainS writes: > I take it that, when called from a spec, any program in $(libsubdir) > will get the right path by the automagic built into the compiler? Yes. >>> Or: >>> If I want to create a new post-collect phase --- is that already >> As far as I know there is currently no post-collect phase. > > This would be tidier than riding on the back of the LINK_COMMAND_SPEC. > Any perception of the difficulty factor (1:10)..? This is so special purpose that I would be inclined to just add to LINK_COMMAND_SPEC if that can be made to work. Otherwise you will have to add a bunch of machinery to gcc.c that nothing else will ever use. Ian
Re: specs question.
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
IainS writes:
yeah .. we use it in Darwin's dsymutil spec.
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
o:a.out"
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}\n"
if you put "-lm" on the c/l dsymutil doesn't get called.
Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver. It doesn't know the source
language of a .o file. So if you are linking, and passing .o files,
then this approach won't work.
well, my first question to myself was 'why are there not ".o" and ".a"
in the list?' ;))
There are two aspects to this ...
1/ the fact that this is probably not the right thing to do in that
spec - easily solved by deleting it..
2/ The weird effect where putting -lm on the c/l causes the
substitution to fail - which hints at a deeper problem.
FWIW I couldn't (quickly) find any other spec using that syntax - so
perhaps it's not important.
cheers,
Iain
Re: specs question.
IainS writes:
> FWIW I couldn't (quickly) find any other spec using that syntax - so
> perhaps it's not important.
There is an example of in java/lang-specs.h.
%{.class|.zip|.jar|!fsyntax-only:jc1 ...
Ian
Re: specs question.
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
if you put "-lm" on the c/l dsymutil doesn't get called.
Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver. It doesn't know the source
language of a .o file. So if you are linking, and passing .o files,
then this approach won't work.
(I saw your post about java .. I wasn't grepping the right things .. )
Since we're tagged onto the LINK_COMMAND_SPEC - this will get
evaluated whenever that does.
... (not 100% sure when that is - when the driver is invoked or when
the collect phase is invoked.. ).
.. also in_files and out_files can exhibit gotchas (e.g. anything
beginning -l isn't eligible for treatments like %
---
It clearly depends on something no-obvious.
gcc hello.c -g -o hc => dsymutils gets run (not expected from the
syntax, assuming that sources are irrelevant)
gcc hello.o -g -o hc => no dsymutils (expected from the absence of
'.o' in the list)
gcc hello.c -g -o hc -lm => no dsymutils... (not at all expected ... )
adding .for to the list does not result in dsymutils getting run ..
(expected by similarity, but not by logic)
removing the whole of the bracketed list - results in all of those
cases working.
I think the right local solution is to remove the expression (I'll run
that by Mike Stump)...
I'm pursuing this in case there's a latent bug that should be reported.
cheers,
Iain
