Re: Link tests after GCC_NO_EXECUTABLES
Mark Mitchell <[EMAIL PROTECTED]> writes:
>>> I really think that we ought to compare with what happens with MIPS or
>>> Power and figure out what's different. Are you by any chance
>>> configuring a native compiler, rather than a cross?
>>
>> No native compilers - I don't think the linux nommu memory manager would
>> be very happy about running gcc. Running the testsuite is bad enough.
>
> Yeah, I didn't think so, but I was trying to think about what could be
> different. I've CC'd Richard Sandiford, as I discussed some of the MIPS
> stuff with him at one point.
This may no longer be relevant given the rest of the thread, but for the
record: what you describe is indeed how things used to work before the
libtool upgrade. (Although as Rask points out, linking never actually
failed for "int main () { return 0; }" without a -T option for MIPS;
it just gave a warning that __start was undefined and that the entry
point was being set to some built-in value. I think both Dan and I
thought it should be an error instead, but that didn't fly...)
However, with the libtool upgrade, the shl_load test failed for MIPS
in the same way as it did for Bernd on Blackfin. Rask got around this
by adding a "-T" option for the simulator board in top-level configure.
I still object to this approach for the reasons we discussed before,
but I didn't have time to come up with an alternative of my own,
so I didn't make a fuss. It did at least get an unpatched libstdc++-v3
building again.
If Jie has a patch that gets us around the shl_load failure, I'd be glad
for us to go that route, and go back to not using the -T simulator options,
if that's possible. Especially if we can do it before 4.3 is out, since
4.3 will then keep to the precedent set by earlier releases, and not set
a new precedent of its own.
Richard
Fwd: Errors issued while building GCC
Hello, I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to build GCC. I have successfully installed the 'binutils', but while building GCC below errors are being issued: --cut-- ../.././gcc/config/mips/mips.md:3318:5: missing terminating " character ../.././gcc/config/mips/mips.md:3319: error: stray '\' in program ../.././gcc/config/mips/mips.md:3319: error: syntax error before "n" ../.././gcc/config/mips/mips.md:3321: error: stray '\' in program ../.././gcc/config/mips/mips.md:407: error: initializer element is not constant ../.././gcc/config/mips/mips.md:407: error: (near initialization for `insn_conditions[205]') make[1]: *** [build/insn-conditions.o] Error 1 make[1]: Leaving directory `/home/gcc/host-i686-pc-cygwin/gcc' make: *** [all-gcc] Error 2 --cut-- I am using below procedure to build GCC: 1. Configure the GCC by giving the following command in the directory where GCC package is placed. $ ./configure --target='mipsisa32-elf' --enable-languages=c,c++ -- prefix= is the path where GCC package is to be installed. I am using /usr/local/bin for this. 2. Build the GCC package by $ make all-gcc 3. Install the GCC package by: $ make install-gcc Please help me in rectifying these issues. Thanks and Regards Ankur Gupta Software Engineer ACME Technologies Pvt. Ltd... Noida, India
Re: Link tests after GCC_NO_EXECUTABLES
Joseph S. Myers wrote: > * They only build static libstdc++. > > * --with-newlib is used, either explicitly or implicitly if newlib is > built in a combined tree. (I do not know if it works with --with-newlib > is not used and it's not a combined tree.) > > * configure.ac then checks for --with-newlib and handles it specially by > hardcoding information about the functions present. > > * With --disable-shared, GLIBCXX_ENABLE_SYMVERS disables symbol versioning > instead of trying to do certain link tests it would do if shared libraries > are being built; it also does so if unable to link. > So make sure the build is using --disable-shared if you can't link; if > that still doesn't help, some configure test somewhere may need disabling, > either if unable to link, or if not building shared libraries, or some > other condition. We're doing all that. I think Richard gave the correct answer elsewhere in the thread: it doesn't actually work without hacks on MIPS either. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: Link tests after GCC_NO_EXECUTABLES
Mark Mitchell wrote: > Understood. Out of curiousity, do you eventually build a bfin-uclinux > compiler, once you've built uClibc, or do you just use the bfin-elf > compiler on uClinux? We build up several versions of uClibc with bfin-elf, and then we build two additional separate toolchains: bfin-uclinux and bfin-linux-uclibc. The former produces flat binaries (a very simple binary format), while the latter produces ELF FD-PIC binaries (using the -mfdpic), which behave essentially like normal ELF binaries and support shared libraries and dynamic loading. In the past we used to allow -mfdpic with the bfin-uclinux toolchain, but the gcc build system didn't cope too well and we couldn't get it to build shared libraries for one set of multilibs and not for the other, so we split things up. We also need a bfin-elf toolchain, and while bare hardware applications can't use -mfdpic or -mid-shared-library, in the past it hasn't hurt to provide these multilibs, and it allows us to build up uClibc quite easily. I guess I could try to build up C-only versions of bfin-uclinux and bfin-linux-uclibc first and use them for building uClibc, although I'm certain to get complaints about how the build script suddenly takes so much longer, and it all seems somewhat more complicated than necessary. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: Link tests after GCC_NO_EXECUTABLES
On Wed, Nov 28, 2007 at 08:10:18AM +, Richard Sandiford wrote:
>
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade. (Although as Rask points out, linking never actually
> failed for "int main () { return 0; }" without a -T option for MIPS;
> it just gave a warning that __start was undefined and that the entry
> point was being set to some built-in value. I think both Dan and I
> thought it should be an error instead, but that didn't fly...)
This is the error message (which we still get):
warning: cannot find entry symbol _start; defaulting to 00400040
> However, with the libtool upgrade, the shl_load test failed for MIPS
> in the same way as it did for Bernd on Blackfin. Rask got around this
> by adding a "-T" option for the simulator board in top-level configure.
Not quite; I arranged for configure to add -L and -B options pointing
into the newlib, libgloss and libgloss/cpu directories when configuring
subdirectories, and it happens only if you build newlib. If you get a link
error with the default -T option, there's still no dice. sparc-unknown-elf
is an example of such a target, but most *-elf targets build out of the box
as long as they can find their newlib and libgloss bits.
> I still object to this approach for the reasons we discussed before,
> but I didn't have time to come up with an alternative of my own,
> so I didn't make a fuss. It did at least get an unpatched libstdc++-v3
> building again.
It is not just libstdc++-v3, it is also libgfortran, libobjc, libjava and
libffi. Maybe also libssp and libiberty.
> If Jie has a patch that gets us around the shl_load failure, I'd be glad
> for us to go that route, and go back to not using the -T simulator options,
> if that's possible. Especially if we can do it before 4.3 is out, since
> 4.3 will then keep to the precedent set by earlier releases, and not set
> a new precedent of its own.
I'm not against it in principle, but in practice, configuring target
libraries without linking is very fragile and has been broken more often
than not. Unless someone voluteers to battle with autoconf and libtool every
time it breaks, I'd very much prefer to keep the -L and -B options.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
RE: Errors issued while building GCC
On 28 November 2007 10:29, Ankur Gupta wrote:
> Hello,
>
> I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to
> build GCC. I have successfully installed the 'binutils', but while building
> GCC below errors are being issued:
These kinds of minor issues in building or using the compiler really belong
on the gcc-help list; this list is intended for ongoing development work on
the internals of the compiler itself. However, since you're here...
> --cut--
> ../.././gcc/config/mips/mips.md:3318:5: missing terminating " character
> ../.././gcc/config/mips/mips.md:3319: error: stray '\' in program
> ../.././gcc/config/mips/mips.md:3319: error: syntax error before "n"
> ../.././gcc/config/mips/mips.md:3321: error: stray '\' in program
I believe you have got stray CR-LF line endings on your source code; this is
a fairly common problem on Cygwin if you use a non-Cygwin gui program such as
WinZIP etc. to unpack the GCC source archive. If that's what you did, don't:
windows GUIs tend to want to convert LF line endings to CR-LF. Use Cygwin's
'tar' utility to unpack the archive instead, like so
tar xvjf gcc-${ver}.tar.bz2
(or use 'tar xvzf' if you are unpacking a .tar.gz file instead).
If it's not because you used a gui to unpack the tarball, it's probably
because you're using text-mode mountpoints; come and discuss it on the cygwin
list if so.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Errors issued while building GCC
On 28/11/2007, Ankur Gupta <[EMAIL PROTECTED]> wrote: > Hello, > > I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to > build GCC. I have successfully installed the 'binutils', but while building > GCC below errors are being issued: > Do you mean that you are going to work on improving GCC or that you are going to use GCC? For the former you need a copyright assignment. For the latter, this list is about developing GCC, so please use [EMAIL PROTECTED] instead. If it is an important project, your company may be better off contracting commercial support (this is well-intentioned advice, I don't provide such support and I don't work for any company that does, I am just a volunteer). Actually, I wanted to provide some examples, but I couldn't easily find a list of companies providing commercial support for GCC. Shouldn't we have such a list in the website in a prominent place? Cheers, Manuel.
Re: Errors issued while building GCC
-- Forwarded message -- From: Ankur Gupta <[EMAIL PROTECTED]> Date: Nov 28, 2007 6:44 PM Subject: Re: Errors issued while building GCC To: Manuel López-Ibáñez <[EMAIL PROTECTED]> Thanks for your response, Manuel. No, we aren't going to improve GCC. We are just studying abt GCC currently. Anyways my problem has been solved. I had also seen list of companies providing commercial support for GCC, but i couldnt recall the website at this time..will look for that. Thanks. On Nov 28, 2007 6:11 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > On 28/11/2007, Ankur Gupta <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to > > build GCC. I have successfully installed the 'binutils', but while building > > GCC below errors are being issued: > > > > Do you mean that you are going to work on improving GCC or that you > are going to use GCC? For the former you need a copyright assignment. > For the latter, this list is about developing GCC, so please use > [EMAIL PROTECTED] instead. If it is an important project, your > company may be better off contracting commercial support (this is > well-intentioned advice, I don't provide such support and I don't work > for any company that does, I am just a volunteer). > > Actually, I wanted to provide some examples, but I couldn't easily > find a list of companies providing commercial support for GCC. > Shouldn't we have such a list in the website in a prominent place? > > Cheers, > > Manuel. >
Re: Link tests after GCC_NO_EXECUTABLES
On Wed, Nov 28, 2007 at 08:10:18AM +, Richard Sandiford wrote:
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade. (Although as Rask points out, linking never actually
> failed for "int main () { return 0; }" without a -T option for MIPS;
> it just gave a warning that __start was undefined and that the entry
> point was being set to some built-in value. I think both Dan and I
> thought it should be an error instead, but that didn't fly...)
It didn't violently not-fly either; I think we persuaded everyone, but
I haven't been back to submit the obvious patch at the end of that
thread yet.
--
Daniel Jacobowitz
CodeSourcery
Re: Errors issued while building GCC
On 28/11/2007, Dave Korn <[EMAIL PROTECTED]> wrote: > On 28 November 2007 10:29, Ankur Gupta wrote: > > > Hello, > > > > I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to > > build GCC. I have successfully installed the 'binutils', but while building > > GCC below errors are being issued: > > These kinds of minor issues in building or using the compiler really belong > on the gcc-help list; this list is intended for ongoing development work on > the internals of the compiler itself. However, since you're here... I humbly think this encourages the wrong behaviour. People that don't bother to look for the correct list, typically don't bother to edit the CC fields, so you end up with their replies in gcc again. This case is even worse, since he posted to both lists! And he got the answer here, so he actually was right doing what he did. I would like to propose that, as a rule of thumb, if you wish to answer the question, first check the gcc-help archives whether it has been answered already, if not, then the answer must be posted to gcc-help and never to the gcc list. Of course this doesn't apply if you reply but don't answer the question. Cheers, Manuel.
Re: Reg: -fdump-translation-unit for "C"
hi All, Sorry for my earlier mail. I had to install libc6-dev for GCC. Figured it out very late. Now it works. --thanks for you patience, Praveen On 11/27/07, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote: > On Nov 27, 2007 7:42 PM, Praveen D V <[EMAIL PROTECTED]> wrote: > > hi, > > I was earlier using 3.x.x version where I used -fdump-translation-unit to > dump > > "typedef" tree. Recently I upgraded to 4.1.x version, unfortunately, > > that doesn't > > dump the tree any more. From documentation, it mentions it is for > > "C++". I need it > > for "C". > > It is a very useful utility. Are there any other options that replace > > -fdump-translation-unit? > > -fdump-tree-all dumps all the trees you want. What is that you are > looking for in the tree ? > > And this is more a question for gcc-help@ rather than gcc@ . > > cheers > Ramana > > > > --thanks, Praveen > > > > > > -- > Ramana Radhakrishnan >
RE: Errors issued while building GCC
On 28 November 2007 13:30, Manuel López-Ibáñez wrote: > On 28/11/2007, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 28 November 2007 10:29, Ankur Gupta wrote: >> >>> Hello, >>> >>> I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to >>> build GCC. I have successfully installed the 'binutils', but while >>> building GCC below errors are being issued: >> >> These kinds of minor issues in building or using the compiler really >> belong on the gcc-help list; this list is intended for ongoing development >> work on the internals of the compiler itself. However, since you're >> here... > > I humbly think this encourages the wrong behaviour. People that don't > bother to look for the correct list, typically don't bother to edit > the CC fields, so you end up with their replies in gcc again. This > case is even worse, since he posted to both lists! And he got the > answer here, so he actually was right doing what he did. > > I would like to propose that, as a rule of thumb, if you wish to > answer the question, first check the gcc-help archives whether it has > been answered already, if not, then the answer must be posted to > gcc-help and never to the gcc list. Of course this doesn't apply if > you reply but don't answer the question. Well, I appreciate your point, but as long as I'm going to be sending an essentially content-free post redirecting the OP to the correct list, it seems a little unkind to not mention something that I'm aware of that could send them away happy. And if I saw a cross-post, I'd trim gcc@ and only reply in gcc-help@, but this was a multi-post and I didn't see the gcc-help posting. You're right of course that I could have checked the gcc-help archive before replying and I'll try and remember to do that in future. cheers, DaveK -- Can't think of a witty .sigline today
Re: Link tests after GCC_NO_EXECUTABLES
Richard Sandiford wrote:
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade.
I see. Thanks for explaining; that puts to rest my vain hope that there
was some simple thing we could do to fix this for Blackfin.
> However, with the libtool upgrade, the shl_load test failed for MIPS
> in the same way as it did for Bernd on Blackfin. Rask got around this
> by adding a "-T" option for the simulator board in top-level configure.
> I still object to this approach for the reasons we discussed before
If I'm understanding correctly:
* You, Benjamin, and I think the previous behavior was best.
* Bernd is flexible, as long as it works.
* Rask prefers the new behavior because he thinks it will be more robust.
Rask, we may have to agree to disagree, as it's clear we both understand
the pros and cons. I agree that making things link is more likely to
work, in the sense that it puts a lower burden on run-time library
configure scripts -- but I also think it increases the risk that the
configure scripts get the wrong answer. And, in some cases, there isn't
any way to get a bare-metal toolchain to link; the necessary bits may be
outside Newlib itself and provided only by the end user.
> If Jie has a patch that gets us around the shl_load failure, I'd be glad
> for us to go that route, and go back to not using the -T simulator options,
> if that's possible.
Bernd kindly forwarded Jie's patch. Unfortunately, it checks
$cross_compile, which means that native and cross compilers will
configure differently, so I don't think we can use that directly.
However, I think there's a solution. In particular, on
libstdc++-v3/configure.ac, we do:
AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL
The AC_LIBTOOL_DLOPEN call enables checking for dlopen support in
libtool. The libtool documentation says:
Enable checking for dlopen support. This macro should be used if
the package makes use of the `-dlopen' and `-dlpreopen' flags,
otherwise libtool will assume that the system does not support
dlopening. The macro must be called *before* `AC_PROG_LIBTOOL'.
But, for a bare-metal toolchain, I don't think we need that. So, I'm
guessing that:
if test "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
fi
will fix the problem. (We already have checks for $with_newlib
elsewhere in configure.ac, so I think this is in the same spirit, though
a libstdc++ maintainer would of course be best to review the patch.)
Bernd, Richard, Rask, would one of you be willing to explore that route?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
gnat1 huge time
Hi, I am trying to get the SVN head built locally again and back at work on the GNAT/RTEMS work I was doing. Unfortunately, I have tripped across something that is quite bad. Compiling on Linux x86 targeting the PowerPC or SPARC leads to a huge compilation time on a single file. joel 27918 27917 98 08:18 pts/11 02:46:24 /home/joel/work-gnat/svn/b-gcc2-powerpc/./gcc/gnat1 -quiet -nostdinc -dumpbase g-catiio.adb -O2 -W -Wall -g -gnatpg -gnatO g-catiio.o g-catiio.adb -o /tmp/cch0iMng.s Here is the same process in top: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 27918 joel 20 0 106m 95m 10m R 100 9.6 170:37.92 gnat1 This is with a PowerPC build. The SPARC eventually finished in an over night build so I don't know how long it took. It doesn't appear to be thrashing on memory. Just CPU time. I attached to the gnat1 process in gdb and got this back trace: (gdb) bt #0 0x083f0231 in bitmap_elt_ior (dst=0xc60, dst_elt=0xc4170d0, dst_prev=0xafc2144, a_elt=0xc4170d0, b_elt=0xb1d551c, changed=0 '\0') at ../../gcc/gcc/bitmap.c:1404 #1 0x083f03af in bitmap_ior_into (a=0xc60, b=0xc6822f8) at ../../gcc/gcc/bitmap.c:1511 #2 0x0842361e in df_live_confluence_n (e=0x42126e88) at ../../gcc/gcc/df-problems.c:1524 #3 0x0841d8b5 in df_worklist_propagate_forward (dataflow=0xade6c60, bb_index=1284, bbindex_to_postorder=0xc6d4050, pending=0xaf65f4c, considered=0xc651eb8) at ../../gcc/gcc/df-core.c:875 #4 0x0841dfa8 in df_worklist_dataflow (dataflow=0xade6c60, blocks_to_consider=0xaf65618, blocks_in_postorder=0xacd75d0, n_blocks=1746) at ../../gcc/gcc/df-core.c:999 #5 0x0841e17b in df_analyze_problem (dflow=0xade6c60, blocks_to_consider=0xaf65618, postorder=0xacd75d0, n_blocks=1746) at ../../gcc/gcc/df-core.c:1060 #6 0x0841e50e in df_analyze () at ../../gcc/gcc/df-core.c:1150 #7 0x08c48e6c in if_convert () at ../../gcc/gcc/ifcvt.c:4045 #8 0x08c49091 in rest_of_handle_if_conversion () at ../../gcc/gcc/ifcvt.c:4124 #9 0x086430ef in execute_one_pass (pass=0x8f19200) at ../../gcc/gcc/passes.c:1118 #10 0x08643239 in execute_pass_list (pass=0x8f19200) at ../../gcc/gcc/passes.c:1171 ---Type to continue, or q to quit--- #11 0x08643255 in execute_pass_list (pass=0x8f13080) at ../../gcc/gcc/passes.c:1172 #12 0x08792fa9 in tree_rest_of_compilation (fndecl=0x40048480) at ../../gcc/gcc/tree-optimize.c:404 #13 0x08a1006b in cgraph_expand_function (node=0x400bd300) at ../../gcc/gcc/cgraphunit.c:1151 #14 0x08a101fc in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1214 #15 0x08a1080d in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1421 #16 0x080a549d in gnat_write_global_declarations () at ../../gcc/gcc/ada/utils.c:4024 #17 0x08705647 in compile_file () at ../../gcc/gcc/toplev.c:1055 #18 0x0870706e in do_compile () at ../../gcc/gcc/toplev.c:2245 #19 0x087070d0 in toplev_main (argc=15, argv=0xbf8d1484) at ../../gcc/gcc/toplev.c:2277 #20 0x083daa6e in main (argc=Cannot access memory at address 0xff3a ) at ../../gcc/gcc/main.c:35 (gdb) Single stepping for a while, I didn't see it get up the call chain farther than df_worklist_propagate_forward before it descended again. Any ideas? --joel
Re: why are stl template classes not mangled as other classes andtemplates
On Tuesday 27 November 2007 15:50, Andreas Schwab wrote: > Stephane Hockenhull <[EMAIL PROTECTED]> writes: > > now, if only someone actually knew where in the g++ source code the > > special case for std::string is > > grep is your friend. Look for find_substitution in cp/mangle.c. > > Andreas. something just occured to me ... the std::string template is not compiled into the .s file are those templates pre-compiled into some "magical" hidden library? I could not find them in my gcc installations both native and i386-unknown-elf grep 'ZNSs7replaceEmmRKSs' * -R didnt find anything (compressed?). where is that template instanciated ? -- Stephane Hockenhull SSC-Studios.com
RE: why are stl template classes not mangled as other classes andtemplates
On 28 November 2007 17:33, Stephane Hockenhull wrote: > something just occured to me ... the std::string template is not compiled > into the .s file > > are those templates pre-compiled into some "magical" hidden library? > I could not find them in my gcc installations both native and > i386-unknown-elf > > grep 'ZNSs7replaceEmmRKSs' * -R > > didnt find anything (compressed?). > > where is that template instanciated ? The instantiations end up in the .o files of your project when you compile, not in the compiler or its support libraries. Does this page: http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html#Template-Instant iation answer the question for you? cheers, DaveK -- Can't think of a witty .sigline today
Re: why are stl template classes not mangled as other classes andtemplates
On Wed, Nov 28, 2007 at 01:56:58PM -0500, Stephane Hockenhull wrote: > hence my question: where is it? In libstdc++. You have to link with libstdc++ to use the STL, for many reasons including this one. -- Daniel Jacobowitz CodeSourcery
Re: why are stl template classes not mangled as other classes andtemplates
On Wednesday 28 November 2007 12:35, Dave Korn wrote: > On 28 November 2007 17:33, Stephane Hockenhull wrote: > > something just occured to me ... the std::string template is not compiled > > into the .s file > > > > are those templates pre-compiled into some "magical" hidden library? > > I could not find them in my gcc installations both native and > > i386-unknown-elf > > > > grep 'ZNSs7replaceEmmRKSs' * -R > > > > didnt find anything (compressed?). > > > > where is that template instanciated ? > > The instantiations end up in the .o files of your project when you > compile, not in the compiler or its support libraries. Does this page: > > http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html#Template-Inst >ant iation > > answer the question for you? > > > cheers, > DaveK no, it does not. I know templates *NORMALLY* end up in the .s file after the compilation pass then the .o file after the assembly pass. if you actually read my email I said : > > the std::string template is > NOT < compiled into the .s file g++ does not seem to put the std::string template's code into the .o file like the other templates. it seem to NOT be instanciated in the .o file. I guess it would make sense to have the std::string class compiled once instead of in every file since its used everywhere, that would greatly speed up compile time but would cause problem in my case. I have the .s file right here and there is no assembly code for the std::string template's instance at all. my other templates are there, just not std::string. hence my question: where is it? and, if it IS precompiled, can I force g++ to compile td::string every time to see if that fixes the problem? -- Stephane Hockenhull SSC-Studios.com
RE: why are stl template classes not mangled as other classes andtemplates
On 28 November 2007 18:57, Stephane Hockenhull wrote: > if you actually read my email Of course I read your email. > I said : >>> the std::string template is > NOT < compiled into the .s >>> file Well, yes, but you also said they weren't anywhere else either. So it wasn't entirely unreasonable of me to assume that one of those two statements was incorrect and they both needed verifying. cheers, DaveK -- Can't think of a witty .sigline today
Re: Link tests after GCC_NO_EXECUTABLES
Mark Mitchell <[EMAIL PROTECTED]> writes:
> However, I think there's a solution. In particular, on
> libstdc++-v3/configure.ac, we do:
>
> AC_LIBTOOL_DLOPEN
> AM_PROG_LIBTOOL
>
> The AC_LIBTOOL_DLOPEN call enables checking for dlopen support in
> libtool. The libtool documentation says:
>
> Enable checking for dlopen support. This macro should be used if
> the package makes use of the `-dlopen' and `-dlpreopen' flags,
> otherwise libtool will assume that the system does not support
> dlopening. The macro must be called *before* `AC_PROG_LIBTOOL'.
>
> But, for a bare-metal toolchain, I don't think we need that. So, I'm
> guessing that:
>
> if test "x${with_newlib}" != "xyes"; then
> AC_LIBTOOL_DLOPEN
> fi
>
> will fix the problem. (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)
>
> Bernd, Richard, Rask, would one of you be willing to explore that route?
Sure, thanks for the suggestion. I've built binutils with _start warning
turned into an error, so I'll see how far I get.
Richard
Re: why are stl template classes not mangled as other classes andtemplates
On Wednesday 28 November 2007 14:01, 'Daniel Jacobowitz' wrote: > On Wed, Nov 28, 2007 at 01:56:58PM -0500, Stephane Hockenhull wrote: > > hence my question: where is it? > > In libstdc++. You have to link with libstdc++ to use the STL, for > many reasons including this one. is there a way to disable this behaviour for stl templates and have them compiled every time? I can't find a command line option for it. this breaks C++ code using the STL when -fleading-underscore is used, other templates compile and link just fine. -- Stephane Hockenhull SSC-Studios.com
Re: why are stl template classes not mangled as other classes andtemplates
On Wednesday 28 November 2007 14:01, 'Daniel Jacobowitz' wrote: > On Wed, Nov 28, 2007 at 01:56:58PM -0500, Stephane Hockenhull wrote: > > hence my question: where is it? > > In libstdc++. You have to link with libstdc++ to use the STL, for > many reasons including this one. ar x ../libstdc++.a grep 'ZNSs7replaceEmmPKc' *.o does not find any matches. -- Stephane Hockenhull SSC-Studios.com
Function specific optimizations call for discussion
One of the things that I've been interested in is adding support to GCC to compile individual functions with specific target options. I first presented a draft at the Google mini-summit, and then another draft at the GCC developer summit last July. In the x86 world this would mean saying that an individual function can use SSE5 instructions or SSE4.1 instructions. This would simplify things for people who need to write high performance libraries that run on different architectures, and need to be optimal on each platform. Ultimately, the goal is to allow hotspot functions to be compiled several times with different target specific optimizations. I would welcome any thoughts or suggestions about this proposal. The proposal is at: http://gcc.gnu.org/wiki/FunctionSpecificOpt Part of the infrastructure work for doing this is already addressed in function adaption project and we will work together with that team: http://gcc.gnu.org/wiki/functionAdaptation One of the things that I have considered and not added to the current proposal is to change most of the -f, -O, -W options for a function. This would be relatively simple to add once the infrastructure is in place, but it can really complicate things, since various optimizations depend on other optimizations having been done. Similarly, the -mtune= and -march= options can overly complicate matters. In addition, attribute(cold) and attribute(hot) will set the optimization level to -Os and -O3. I will be away on vacation from December 3-8th, and not reading mail during that time. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: Link tests after GCC_NO_EXECUTABLES
On Wed, Nov 28, 2007 at 08:15:56AM -0800, Mark Mitchell wrote:
>
> If I'm understanding correctly:
>
> * You, Benjamin, and I think the previous behavior was best.
>
> * Bernd is flexible, as long as it works.
>
> * Rask prefers the new behavior because he thinks it will be more robust.
>
> Rask, we may have to agree to disagree, as it's clear we both understand
> the pros and cons. I agree that making things link is more likely to
> work, in the sense that it puts a lower burden on run-time library
> configure scripts -- but I also think it increases the risk that the
> configure scripts get the wrong answer.
Here's a detail I'm missing. If you configure --with-newlib (or get it
implicitly) and then link with something else when using the toolchain, then
the answers will be wrong, but I don't see how that's any worse than
assuming a set of hard coded link test results.
> And, in some cases, there isn't
> any way to get a bare-metal toolchain to link; the necessary bits may be
> outside Newlib itself and provided only by the end user.
That's not in itself a problem; you could supply --with-sysroot assuming
you have all the necessary parts built already. It's only when you need GCC
to build those other parts needed to link that it becomes a mess. At the
moment, --with-newlib is a special case in that it allows you to configure
and build a newlib target from scratch with just "configure ...; make" while
e.g. glibc and uClibc targets need a more elaborate process, including
building GCC twice in many cases, and perhaps installing intermediate
libraries to satisfy link tests. A more general --with-libc=dirname option
would configure and build in "dirname", then configure libstdc++ etc. with a
"-B dirname" option to make link tests work.
> But, for a bare-metal toolchain, I don't think we need that. So, I'm
> guessing that:
>
> if test "x${with_newlib}" != "xyes"; then
> AC_LIBTOOL_DLOPEN
> fi
>
> will fix the problem.
How about an explicit option --without-link-tests, --disable-link-tests
or something like that? Most people don't test on bare-metal targets and
won't notice if they break, but given an explicit option to turn off link
tests, you could make it a requirement to test that configure works with
link tests disabled before checking in changes to configure.{ac,in}.
> (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)
I have a feeling it would be more robust to simulate the link tests
inside the autoconf/libtool macros themselves as opposed to explicitly
avoiding them in each and every configure.{ac,in}. Supply an option
--simulate-link-tests=file_with_results with the default being no and be
happy. A bit like having created config.cache by hand before configuring, I
suppose.
> Bernd, Richard, Rask, would one of you be willing to explore that route?
I see that Richard has already started, so I'll leave it to him.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
Re: why are stl template classes not mangled as other classes ?andtemplates
On Wed, Nov 28, 2007 at 03:38:50PM -0500, Stephane Hockenhull wrote: > On Wednesday 28 November 2007 14:01, 'Daniel Jacobowitz' wrote: > > On Wed, Nov 28, 2007 at 01:56:58PM -0500, Stephane Hockenhull wrote: > > > hence my question: where is it? > > > > In libstdc++. You have to link with libstdc++ to use the STL, for > > many reasons including this one. > > is there a way to disable this behaviour for stl templates and have them > compiled every time? No. You must link to libstdc++. More than this will break at runtime if you do not, e.g. streams. > this breaks C++ code using the STL when -fleading-underscore is used, other > templates compile and link just fine. This does not make sense. Compile libstdc++ with -fleading-underscore if that's the problem. You need to get libgcc too. -- Daniel Jacobowitz CodeSourcery
Testsuite infrastructure for comparing outputs
Hi, In a recent update of the page http://gcc.gnu.org/wiki/Graphite I left the "Testing Lambda and Graphite frameworks" part in the open tasks. One of the subitems of this task is: "Add expect scripts for comparing outputs of testcases compiled with different options. For instance compare output of a program compiled with "-O2" versus "-O2 -fgraphite"." Are there already such scripts that we could use? I suspect that the answer is not yet. Thanks, Sebastian -- AMD - GNU Tools
Re: why are stl template classes not mangled as other classes andtemplates
On 11/28/07, Stephane Hockenhull <[EMAIL PROTECTED]> wrote: > is there a way to disable this behaviour for stl templates and have them > compiled every time? > > I can't find a command line option for it. It is a source level option. Remove all the use of "extern template" in the headers of libstdc++. -- Pinski
Re: svn trunk reaches nearly 1 GiB!!! That massive!!!
"J.C. Pizarro" <[EMAIL PROTECTED]> a écrit dans le message de news:[EMAIL PROTECTED] > $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc > $ du -s . > 1044451 . > $ > > It's 1'069'517'824 characters made from keyboards and generators!!! > > That massive!!! And slower checkout after several minutes!!! > > Is not there any another solution to reduce this massive quantity > for the most recent part of the trunk of the tree instead of full trunk? > >J.C.Pizarro > Hi, if you are not interested in the whole gcc, have a look at http://gcc.gnu.org/wiki/SvnSetup under section "Optimize disk usage". Doing this, you won't get the whole repository but it makes things go *much* faster when tweaked correctly. CJ
Re: why are stl template classes not mangled as other classes andtemplates
On 28/11/2007, Stephane Hockenhull <[EMAIL PROTECTED]> wrote: > On Wednesday 28 November 2007 14:01, 'Daniel Jacobowitz' wrote: > > On Wed, Nov 28, 2007 at 01:56:58PM -0500, Stephane Hockenhull wrote: > > > hence my question: where is it? > > > > In libstdc++. You have to link with libstdc++ to use the STL, for > > many reasons including this one. > > is there a way to disable this behaviour for stl templates and have them > compiled every time? > > I can't find a command line option for it. > > this breaks C++ code using the STL when -fleading-underscore is used, other > templates compile and link just fine. IIRC, -D_GLIBCXX_EXTERN_TEMPLATE=0 might work, but it's neither documented nor supported. Jon
Re: why are stl template classes not mangled as other classes andtemplates
On Wednesday 28 November 2007 16:25, Andrew Pinski wrote: > On 11/28/07, Stephane Hockenhull <[EMAIL PROTECTED]> wrote: > > is there a way to disable this behaviour for stl templates and have them > > compiled every time? > > > > I can't find a command line option for it. > > It is a source level option. Remove all the use of "extern template" > in the headers of libstdc++. > > -- Pinski YES! works! thank you very much! there is a define to disable them in bunch: _GLIBCXX_EXTERN_TEMPLATE g++ -c -save-temps -fleading-underscore -D_GLIBCXX_EXTERN_TEMPLATE=0 test.cpp -o test.o templates get compiled in just fine, with correct underscore, no need to recompile libstdc++ *drops on the floor side-walking in circle whooping a la Homer S.* I added a comment to bug for the work around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166 but left it unconfirmed, should it be closed, just documented, or the feature automatically disabled if someone overrides the platform's default prefix rule ?? -- Stephane Hockenhull SSC-Studios.com
Re: why are stl template classes not mangled as other classes andtemplates
On Wednesday 28 November 2007 17:24, Jonathan Wakely wrote: > On 28/11/2007, Stephane Hockenhull <[EMAIL PROTECTED]> wrote: > > On Wednesday 28 November 2007 14:01, 'Daniel Jacobowitz' wrote: > > > On Wed, Nov 28, 2007 at 01:56:58PM -0500, Stephane Hockenhull wrote: > > > > hence my question: where is it? > > > > > > In libstdc++. You have to link with libstdc++ to use the STL, for > > > many reasons including this one. > > > > is there a way to disable this behaviour for stl templates and have them > > compiled every time? > > > > I can't find a command line option for it. > > > > this breaks C++ code using the STL when -fleading-underscore is used, > > other templates compile and link just fine. > > IIRC, -D_GLIBCXX_EXTERN_TEMPLATE=0 might work, but it's neither > documented nor supported. > > Jon thanks, found it grepping for "extern template" it does work, worst case if it breaks again we'll stick with the gcc version we're currently using until we find some work around :P -- Stephane Hockenhull SSC-Studios.com
gcc-4.2-20071128 is now available
Snapshot gcc-4.2-20071128 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071128/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 130499 You'll find: gcc-4.2-20071128.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20071128.tar.bz2 C front end and core compiler gcc-ada-4.2-20071128.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20071128.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20071128.tar.bz2 C++ front end and runtime gcc-java-4.2-20071128.tar.bz2 Java front end and runtime gcc-objc-4.2-20071128.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20071128.tar.bz2The GCC testsuite Diffs from 4.2-20071121 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: Errors issued while building GCC
> Actually, I wanted to provide some examples, but I couldn't easily > find a list of companies providing commercial support for GCC. > Shouldn't we have such a list in the website in a prominent place? This is explained in the gcc/SERVICE file. Cheers, Ben
Re: Link tests after GCC_NO_EXECUTABLES
Rask Ingemann Lambertsen wrote:
>Here's a detail I'm missing. If you configure --with-newlib (or get it
> implicitly) and then link with something else when using the toolchain, then
> the answers will be wrong, but I don't see how that's any worse than
> assuming a set of hard coded link test results.
The issue isn't just Newlib; it's the "BSP" (crt0, system-call
implementations, etc.) that you might have in your individual system.
Some BSPs add considerable functionality beyond that provided by Newlib
itself, and we don't want libstdc++ to detect and rely on that.
>How about an explicit option --without-link-tests, --disable-link-tests
> or something like that? Most people don't test on bare-metal targets and
> won't notice if they break, but given an explicit option to turn off link
> tests, you could make it a requirement to test that configure works with
> link tests disabled before checking in changes to configure.{ac,in}.
That's a reasonable idea, but as Joseph said, for GNU/Linux (and other
"hosted" platforms, presumably), we've decided we do need to do links,
so on those platforms, --without-link-tests would probably result in
broken libraries.
>I have a feeling it would be more robust to simulate the link tests
> inside the autoconf/libtool macros themselves as opposed to explicitly
> avoiding them in each and every configure.{ac,in}. Supply an option
> --simulate-link-tests=file_with_results with the default being no and be
> happy.
We would still need to hard-code things. For example, we want libstdc++
to call functions that are in Newlib (but might not be in other C
libraries). So, libstdc++ has to have some way of asking whether the
function is in the C library, whether by linking, having the answer
hard-coded, or doing some other kind of probe (running nm?).
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Bug in builtins.def, the execve.
builtins.def:635: DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECVE, "execve", BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING, ATTR_NOTHROW_LIST) Is it BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING a weird bug? The correct const symbol is BT_FN_INT_CONST_STRING_PTR_CONST_STRING Please, to revise the builtins const symbols from execl, execlp, execle, execv, execvp and execve because they use different const symbols for co-similar exec?* J.C.Pizarro
Describing commercial support on our website
On 29/11/2007, Ben Elliston <[EMAIL PROTECTED]> wrote: > > Actually, I wanted to provide some examples, but I couldn't easily > > find a list of companies providing commercial support for GCC. > > Shouldn't we have such a list in the website in a prominent place? > > This is explained in the gcc/SERVICE file. > Perhaps we should have that link in our website + a list specific to GCC. By the way, the link is broken. The correct link seems to be http://www.fsf.org/resources/service I can send a patch, but I think it would be better if we linked to our own http://gcc.gnu.org/support page and from there to wherever the FSF wants us to link. That way we could include and update ourselves the information specific to gcc. Cheers, Manuel.
Re: Bug in builtins.def, the execve. don't use execle, use execel.
On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote: > builtins.def:635: DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECVE, > "execve", BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING, > ATTR_NOTHROW_LIST) > > Is it BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING > a weird bug? > > The correct const symbol is BT_FN_INT_CONST_STRING_PTR_CONST_STRING I'm sorry, after reading deeply it, i found that it's not a bug. The more weird thing was "..." in middle of the C's stack from int execle(const char *path, const char *arg, ..., char * const envp[]); extracted from "man execle". DEF_EXT_LIB_BUILTIN (BUILT_IN_EXECLE, "execle", BT_FN_INT_CONST_STRING_CONST_STRING_VAR, ATTR_NOTHROW_SENTINEL_1) It shows that SENTINEL and 1 are the unique representation different to the rest. It's better to say to the programmers "don't use execle because it manipulates badly the C's stack" It's posible that execle can be dangerous as the SSP's canary can be flawed. Why don't they correct the below specification to use? int execel(const char *path, const char *arg, char * const envp[], ...); instead of flawed int execle(const char *path, const char *arg, ..., char * const envp[]); > Please, to revise the builtins const symbols from > execl, execlp, execle, execv, execvp and execve > because they use different const symbols for co-similar exec?* J.C.Pizarro
Re: Testsuite infrastructure for comparing outputs
On Wed, 2007-11-28 at 15:00 -0600, Sebastian Pop wrote: > Hi, > > In a recent update of the page http://gcc.gnu.org/wiki/Graphite I left > the "Testing Lambda and Graphite frameworks" part in the open tasks. > One of the subitems of this task is: > > "Add expect scripts for comparing outputs of testcases compiled with > different options. For instance compare output of a program compiled > with "-O2" versus "-O2 -fgraphite"." > > Are there already such scripts that we could use? I suspect that the > answer is not yet. I'm not sure what you mean. Would it be enough to add -fgraphite to TORTURE_OPTIONS when you run the existing execute tests? Janis
Re: Testsuite infrastructure for comparing outputs
On Nov 28, 2007 6:36 PM, Janis Johnson <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2007-11-28 at 15:00 -0600, Sebastian Pop wrote:
> > Hi,
> >
> > In a recent update of the page http://gcc.gnu.org/wiki/Graphite I left
> > the "Testing Lambda and Graphite frameworks" part in the open tasks.
> > One of the subitems of this task is:
> >
> > "Add expect scripts for comparing outputs of testcases compiled with
> > different options. For instance compare output of a program compiled
> > with "-O2" versus "-O2 -fgraphite"."
> >
> > Are there already such scripts that we could use? I suspect that the
> > answer is not yet.
>
> I'm not sure what you mean. Would it be enough to add -fgraphite to
> TORTURE_OPTIONS when you run the existing execute tests?
>
Sorry for not being clear.
I want to compile twice a testcase once with an option turned on, and
another time without that option: this produces two executables. Then
I want to compare the outputs of the two executables as they should be
the same with and without the transformation. Here is an example:
gcc -O2 -fgraphite file.c -o ./a
gcc -O2 -fno-graphite file.c -o ./b
./a > output.a
./b > output.b
diff output.a output.b
And there should be no difference between the outputs.
My question was whether we have an infrastructure in the gcc testsuite
that allows to specify the flags to compare, something like:
/* { dg-same-output "-O2 -fgraphite" "-O2 -fno-graphite" } */
that would trigger the above commands and succeed when the outputs are
identical.
Sebastian
--
AMD - GNU Tools
Re: Function specific optimizations call for discussion
On Nov 29, 2007 2:27 AM, Michael Meissner <[EMAIL PROTECTED]> wrote: > One of the things that I've been interested in is adding support to GCC to > compile individual functions with specific target options. I first presented > a > draft at the Google mini-summit, and then another draft at the GCC developer > summit last July. > > In the x86 world this would mean saying that an individual function can use > SSE5 instructions or SSE4.1 instructions. This would simplify things for > people who need to write high performance libraries that run on different > architectures, and need to be optimal on each platform. Ultimately, the goal > is to allow hotspot functions to be compiled several times with different > target specific optimizations. I would welcome any thoughts or suggestions > about this proposal. > > The proposal is at: > http://gcc.gnu.org/wiki/FunctionSpecificOpt Regarding the static constructors/destructors, we can version them as well. In case a person wishes to annotate them, he can use: __attribute__(sse4a) or change the constructor function name to name__v__sse4a__ or so. He can safely assume that it won't execute if the feature bit isn't present. We would simply ret if the feature bit isn't supported. Multiple attributes are supported for any function, and it shouldnt be a problem :-) This means the detection of features would be done before the program's actual execution. > > Part of the infrastructure work for doing this is already addressed in > function > adaption project and we will work together with that team: > http://gcc.gnu.org/wiki/functionAdaptation > > One of the things that I have considered and not added to the current proposal > is to change most of the -f, -O, -W options for a function. This would be > relatively simple to add once the infrastructure is in place, but it can > really > complicate things, since various optimizations depend on other optimizations > having been done. Similarly, the -mtune= and -march= options can overly > complicate matters. > As for setting -f, there are flags like: stack-protector-all which can not be set at a function level. The problem happens when a flag is set to 0/1 (not 2) and is valid for a whole compilation unit.. (It might be there, I'm saying); We should clearly split the common.opt/annotate it with the required information so we can determine which ones can not be unset when set or vice-versa. The warn/optimization levels would inherit/differenciate from the parent settings (compilation unit or enclosing function). > In addition, attribute(cold) and attribute(hot) will set the optimization > level > to -Os and -O3. > It might be possible that he wishes to optimize for size (not inline function calls/unroll loops, for instance) but he might want it versioned; . Versioning will increase text size only if all versions are loaded during runtime. > I will be away on vacation from December 3-8th, and not reading mail during > that time. > > -- > Michael Meissner, AMD > 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA > [EMAIL PROTECTED] > > > -- Karthik
