Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 08, 2013 at 12:55:15AM -0500, Gabriel Dos Reis wrote: > Personally, I don't see anything broken with that. The world we are > in today is very different from a decade ago. More than a decade ago, > a multilib build by default -probably- made sense; I don't see that today. But having multilib enabled by default on x86_64 is simply very highly desirable, checking that you have a (minimal, for gcc you pretty much only need glibc and libgcc development stuff) 32-bit environment is just one of the many items you need to check before you start building gcc. You also need gmp, mpfr, mpc development (headers+libraries), flex, bison, texinfo, ..., lots of this isn't installed by default. Jakub
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 8, 2013 at 2:13 AM, Jakub Jelinek wrote: > On Mon, Jul 08, 2013 at 12:55:15AM -0500, Gabriel Dos Reis wrote: >> Personally, I don't see anything broken with that. The world we are >> in today is very different from a decade ago. More than a decade ago, >> a multilib build by default -probably- made sense; I don't see that today. > > But having multilib enabled by default on x86_64 is simply very highly > desirable, checking that you have a (minimal, for gcc you pretty much only > need glibc and libgcc development stuff) 32-bit environment is just > one of the many items you need to check before you start building gcc. > You also need gmp, mpfr, mpc development (headers+libraries), flex, bison, > texinfo, ..., lots of this isn't installed by default. But the situation is not the same. These tools are checked at configuration time, and the builder is let known in no uncertain terms that something is missing. If you don't have gmp or mfr installed, configure will let you know, loudly complains, and won't budge until you install the required tools. The subject is very different. -- Gaby
Re: fatal error: gnu/stubs-32.h: No such file
On 07/08/2013 06:17 AM, Gabriel Dos Reis wrote: > On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely wrote: >> On 7 July 2013 21:33, Gabriel Dos Reis wrote: >>> How about not enabling multi lib build by default on targets we now that >>> will fail anyway? I have the suspicion this problem is unique to openSUSE, >>> so we can take care of that. >> >> I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu >> users have asked about the same thing on the gcc-help list. > > Ha, if it is that spread then we might have even more reasons to > have it work more generally, for example, by disabling multilib by default. That would, as they saying goes, be to throw the baby out with the bathwater. Andrew.
Re: fatal error: gnu/stubs-32.h: No such file
On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote: > I strongly disagree. We (GCC) are at fault here. We implicitly > enable a feature at configure time without knowing its builds > will succeed (despite having repeated reports that it does often > fail) without much input from the builder (who might be ignorant of > real reason of failures.) That's better than silently disable multilib builds so that the user doesn't know until the build is complete. It's better to abort early. Andrew.
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 8, 2013 at 3:43 AM, Andrew Haley wrote: > On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote: >> I strongly disagree. We (GCC) are at fault here. We implicitly >> enable a feature at configure time without knowing its builds >> will succeed (despite having repeated reports that it does often >> fail) without much input from the builder (who might be ignorant of >> real reason of failures.) > > That's better than silently disable multilib builds so that the > user doesn't know until the build is complete. I don't think this is what is being proposed. > It's better to abort early. it is, as the saying goes, drowning the baby because we want to keep the water. -- Gaby > > Andrew. >
Re: List of typos.
On 8 July 2013 01:29, Ryan Hill wrote: > On Sun, 07 Jul 2013 21:57:05 +0200 > Oleg Endo wrote: > > >> - // Randomize the colour, just for asthetics =) >> + // Randomize the colour, just for aesthetics =) >> >> -> missed 'color' (in a couple of places actually) > > Because that's the correct way of spelling colour. Similarly for cancelled and behaviours in the patch, but the GCC conventions do say to use American spelling not British. I tend to forget that when I'm writing comments and docs, but we should probably accept patches to "correct" things when found.
[PATCH 0/6] Contributing new target port: Andes 'nds32'.
Hi, GCC Steering Committee, reviewers, and developers, On behalf of Andes Technology Corp., we are submitting a new port 'nds32' for GCC contribution. In this contribution, we use the design and strategy as modern as possible, such as having LRA enabled and taking soft-fp as our software floating point library. None of general gcc code is required to be changed for this nds32 port. We have already signed FSF agreement and are proposing Shiva Chen and myself (Chung-Ju Wu), both of Andes compiler engineers, as nds32 port maintainers: Index: MAINTAINERS === --- MAINTAINERS (revision 200655) +++ MAINTAINERS (working copy) @@ -87,6 +87,8 @@ mn10300 port Jeff Lawl...@redhat.com mn10300 port Alexandre Oliva aol...@redhat.com moxie port Anthony Green gr...@moxielogic.com +nds32 port Chung-Ju Wu jasonw...@gmail.com +nds32 port Shiva Chen shiva0...@gmail.com pdp11 port Paul Koning n...@arrl.net picochip port Daniel Towner d...@picochip.com rl78 port DJ Delorie d...@redhat.com A series of patches have been posted on gcc-patches: [PATCH 1/6] Andes nds32: configure settings for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00269.html [PATCH 2/6] Andes nds32: machine description of nds32 porting. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00270.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00271.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00272.html [PATCH 3/6] Andes nds32: libgcc of nds32 porting. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00273.html [PATCH 4/6] Andes nds32: testsuite modifications for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00274.html [PATCH 5/6] Andes nds32: documentation for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00276.html [PATCH 6/6] Andes nds32: wwwdoc for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00277.html A brief overview of changed files is as below: [gcc-svn: contrib/] * config-list.mk [gcc-svn: gcc/] * config.gcc * config/nds32/* * common/config/nds32/* * doc/invoke.texi * doc/md.texi * doc/install.texi * doc/extend.texi [gcc-svn: libgcc/] * config.host * config/nds32/* [gcc-svn: gcc/testsuite/] * g++.dg/other/PR23205.C * g++.dg/other/pr23205-2.C * gcc.dg/20020312-2.c * gcc.dg/builtin-apply2.c * gcc.dg/lower-subreg-1.c * gcc.dg/sibcall-3.c * gcc.dg/sibcall-4.c * gcc.dg/stack-usage-1.c * gcc.dg/torture/pr37868.c * gcc.dg/torture/stackalign/builtin-apply-2.c * gcc.dg/tree-ssa/20040204-1.c * gcc.dg/tree-ssa/forwprop-28.c * gcc.dg/tree-ssa/pr42585.c * gcc.dg/tree-ssa/sra-12.c * gcc.dg/ucnid-11.c * gcc.dg/ucnid-2.c * gcc.dg/ucnid-3.c * lib/target-supports.exp [wwwdoc-cvs: htdocs/] * backends.html * readings.html * gcc-4.9/changes.html In addition, here are some standard requirement we have made for contribution: 1. Add nds32le-elf and nds32be-elf into contrib/config-list.mk. 2. We follow the -2013 range convention in copyright description. 3. Using a native compiler from current GCC trunk (20130704, Rev.200655), the nds32 port can be built cleanly with --enable-werror-always on both 32-bit and 64-bit host. 4. The nds32 test results have been posted on gcc-testresults: 32-bit host: v2, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00378.html v3, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00380.html 64-bit host: v2, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00379.html v3, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00381.html For completeness of Andes nds32 toolchain, we also proposed nds32 contribution for other packages [1]-[3] on corresponding mailing list. And the nds32 target for packages [4] and [5] are previously merged into master on 2011.10 and 2013.06, respectively. We sincerely hope that the nds32 target will be available in GCC 4.9. Your reviews and comments are very important to us for making this contribution better. Thanks for your time to review our contribution. Best regards, jasonwucj [1] binutils: http://sourceware.org/ml/binutils/2013-07/msg00062.html [2] gdb: http://sourceware.org/ml/gdb-patches/2013-07/msg00223.html [3] newlib: http://sourceware.org/ml/newlib/2013/msg00525.html [4] u-boot: http://lists.denx.de/pipermail/u-boot/2011-October/106467.html [5] openocd: http://openocd.zylin.com/1259
put ELF reloc section against section with template function instantiation in the same COMDAT group
Hi, all. First off, I know that I'm posting to GCC list :-) And I'm looking for competent opinions. I'm working on CLang/LLVM issue [1]. Clang doesn't put section with relocation entries against section with templated function instantiation in the same COMDAT group. AFAIK GCC does not do it too, Solaris CC does. Is GCC's behavior intentional? Does GCC rely on the linker? I'm not sure what questions are correct, so appreciate any comments . [1] http://llvm.org/bugs/show_bug.cgi?id=12843
Re: List of typos.
On Sun, Jul 07, 2013 at 07:54:34PM +0200, Georg-Johann Lay wrote:
> Ondrej Bilka schrieb:
>
> >http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
>
> This is wrong:
>
> @@ -10834,7 +10834,7 @@ avr_convert_to_type (tree type, tree expr)
> XOP[2] # Bytes to copy
>
> Return TRUE if the expansion is accomplished.
> - Return FALSE if the operand compination is not supported. */
> + Return FALSE if the operand compilation is not supported. */
>
> Should be "combination" not "compilation".
>
>
> index 406617f..c7a7f7b 100644
> --- a/gcc/config/frv/frv-opts.h
> +++ b/gcc/config/frv/frv-opts.h
> @@ -1,4 +1,4 @@
> -/* Frv option-handling defitions.
> +/* Frv option-handling deviations.
>
> Should be "definitions" instead of "deviations".
>
>
> -/* Expand SYMBOL into its corresponding far-addresse symbol.
> +/* Expand SYMBOL into its corresponding far-addressee symbol.
>
> Is this correct or should be "far-address"?
>
>
> @@ -5336,7 +5336,7 @@ pa_print_operand (FILE *file, rtx x, int code)
> && GET_CODE (XEXP (XEXP (x, 0), 1)) == REG)
> {
> /* Because the REG_POINTER flag can get lost during reload,
> - pa_legitimate_address_p canonicalizes the order of the
> + pa_legitimate_address_p canonizes the order of the
>
> I am not sure about this one and many others. "canonicalize" sounds
> ok to me, so does "canonicalization". "canonize" sounds odd to me.
> For example the following which should change none or both:
>
> -/* Canonicalize the filename NAME by canonicalizing directory
> +/* Canonicalize the filename NAME by canonizing directory
>
> - * Unique vinsn derivates from CALL, ASM, JUMP (for a while) and other
> + * Unique vinsn derivatives from CALL, ASM, JUMP (for a while) and other
>
> Shouldn't this be "derives"?
>
>
> - /* Merge c_expres found or unify live register sets from different
> + /* Merge c_express found or unify live register sets from different
>
> Some lines above in sel-sched.c there is "C_EXPRes". Again, change
> none or both (none seems fine here):
>
oops it was bug, fixed.
>
> - /* Test exponentials and their signs. A buggy lexer is more likely
> + /* Test exponential and their signs. A buggy lexer is more likely
>
> Should both be plural or singular. "exponents" sounds good to me.
>
it is also in string bellow so probably we need change or keep both.
>
> - Roger Sayle <...@eyesopen.com>
> + Roger Sayle <...@eyes open.com>
>
> Don't change email addresses!
bug, fixed
Re: List of typos.
On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote: > On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote: > > Ondrej Bilka schrieb: > > > > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch > > I fixed most comments, put it here so you can diff these two files. http://kam.mff.cuni.cz/~ondra/gcc_misspell_fixed.patch > > BASE must be either a declaration or a memory reference that has correct > - alignment ifformation embeded in it (e.g. a pre-existing one in SRA). */ > + alignment ifformation embedded in it (e.g. a pre-existing one in SRA). */ > > -> missed 'information' I guess... > This fixes only a-e. These are probably incomplete as I needed to exclude lot of names that are variable names etc. I did selectin based on following file: http://kam.mff.cuni.cz/~ondra/gcc_misspells > > > - http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algoritms > + http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algorithms > > both links do 404 anyway ;) > could you find what this was? I need to add another filter not touch html which I will do probably tomorrow. > > - // Randomize the colour, just for asthetics =) > + // Randomize the colour, just for aesthetics =) > > -> missed 'color' (in a couple of places actually) > Wa- not on my list because my aspell thinks its valid.
Re: List of typos.
On Mon, Jul 08, 2013 at 10:29:17AM +0100, Jonathan Wakely wrote: > On 8 July 2013 01:29, Ryan Hill wrote: > > On Sun, 07 Jul 2013 21:57:05 +0200 > > Oleg Endo wrote: > > > > > >> - // Randomize the colour, just for asthetics =) > >> + // Randomize the colour, just for aesthetics =) > >> > >> -> missed 'color' (in a couple of places actually) > > > > Because that's the correct way of spelling colour. > > Similarly for cancelled and behaviours in the patch, but the GCC > conventions do say to use American spelling not British. I tend to > forget that when I'm writing comments and docs, but we should probably > accept patches to "correct" things when found. If somebody want to take care of that he can use following commands and write replacement list: git grep "/[/*].*\w\wour[ .,]" > our git grep "/[/*].*\w[^aw]ise[ .,]" > ise They produce 131 and 171 lines so this also takes bit of work.
Re: put ELF reloc section against section with template function instantiation in the same COMDAT group
On Mon, Jul 8, 2013 at 4:35 AM, Игорь Пашев wrote: > Hi, all. > > First off, I know that I'm posting to GCC list :-) > And I'm looking for competent opinions. > > I'm working on CLang/LLVM issue [1]. > Clang doesn't put section with relocation entries against section > with templated function instantiation in the same COMDAT group. > AFAIK GCC does not do it too, Solaris CC does. > > Is GCC's behavior intentional? Does GCC rely on the linker? I think GCC's behavior is depend on the assembler which is being used. So if you used Sun's assembler it would have placed it in the same COMDAT group. Meaning this is really a GNU binutils issue rather than a GCC one. Thanks, Andrew Pinski > > I'm not sure what questions are correct, so appreciate any comments . > > > > [1] http://llvm.org/bugs/show_bug.cgi?id=12843
Re: fatal error: gnu/stubs-32.h: No such file
Hi, On Sun, Jul 7, 2013 at 10:19 PM, Andrew Pinski wrote: > I think disable multilib by default is a mistake and is a broken > choice for broken distros which don't install the 32bit development by > default when you install the development part. If a distro does something that you consider wrong, you would have their many clients suffer? When there's a simple test to see if the platform can support multilib? That is not very friendly. Not friendly at all. > > I think the problem is still in the distros rather than GCC. > > I strongly disagree. We (GCC) are at fault here. We implicitly > enable a feature at configure time without knowing its builds > will succeed (despite having repeated reports that it does often > fail) without much input from the builder (who might be ignorant of > real reason of failures.) Usually we do the opposite. Making the innocent suffer inscrutible failures because you think that many mass distributions are wrong? That is wrong. I agree whole heartedly with Gaby. > But having multilib enabled by default on x86_64 is simply very highly > desirable, REMEMBER: we are talking about having a multilib enableable test in the configure. If it fails, then it is not enabled by default. This is not rocket science. > If you don't have gmp or mfr installed, > configure will let you know, loudly complains, and won't budge until > you install the required tools Exactly. > > It's better to abort early. > > it is, as the saying goes, drowning the baby because we want to > keep the water. :-D It is punishing the innocent by failing the build with inscrutible error messages. Sounds like baby drowning to me... Please add a multilib-able test to configure. Thank you.
Re: put ELF reloc section against section with template function instantiation in the same COMDAT group
2013/7/8 Andrew Pinski : > I think GCC's behavior is depend on the assembler which is being used. > So if you used Sun's assembler it would have placed it in the same > COMDAT group. Meaning this is really a GNU binutils issue rather than > a GCC one. Thank you. I believe GCC on Solaris is using GNU as and Sun ld, don't know about Sun CC. I would appreciate if anyone could explain what is the impact of including or not including relocation entries in the same COMDAT group.
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 08, 2013 at 08:11:03AM -0700, Bruce Korb wrote: > > But having multilib enabled by default on x86_64 is simply very highly > > desirable, > > REMEMBER: we are talking about having a multilib enableable test in > the configure. If it fails, then it is not enabled by default. This is not > rocket science. It isn't that trivial though, would you do this for native linux configurations only (or how would you handle crosses?), what about --with-sysroot configurations where the system compiler might e.g. not support sysroots, what if the system compiler isn't gcc, or what if it is gcc, but doesn't support multilibs, yet the newly built gcc would be capable of supporting that? So maybe for native configuration without --with-sysroot if system compiler is gcc and a configure test can be compiled successfully when not using any headers with a non-primary multilib option, but a test including some well known glibc header like stdlib.h would fail with an error, error out (silently disabling multilibs would look wrong to me, given that it would be a very problematic heuristics only working sometimes). But, the next question is how to find out what multilib options to pass, if system compiler is gcc, it can check --print-multilib and derive that info from it, but do you have a guarantee that the system gcc multilib support matches the to be built compiler's multilib (e.g., you can have system gcc built on ppc* to default to -m32 and have -m64 as non-default multilib option and configure new gcc to do it the other way around, etc.). Do you still think it is that trivial? Far easier would be if not inhibit_libc to try to compile some trivial program using say stdlib.h include in libgcc configure and error out there, if it isn't for the primary multilib hint that either development support for the non-primary multilib needs to be installed or --disable-multilib used in configure. That would have the disadvantage that the error would show up only after at least first stage of gcc has been built, but would be more reliable. Jakub
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 8, 2013 at 8:24 AM, Jakub Jelinek wrote: > Far easier would be if not inhibit_libc to try to compile some trivial > program using say stdlib.h include in libgcc configure and error out there, > if it isn't for the primary multilib hint that either development support > for the non-primary multilib needs to be installed or --disable-multilib > used in configure. That would have the disadvantage that the error would > show up only after at least first stage of gcc has been built, but would be > more reliable. Any solution other than an explanation-less "fatal error: gnu/stubs-32.h: No such file" is fine. There is no way to translate that message into "Either --disable-multilib or else install glibc 32 bit development" without coming up with the right Googling terms. I managed to futz around until I figured out the missing package. It was a day later that I found out it was all about multilib. Putting people through such a gauntlet just because you think a distro ought to have included glibc 32 bit development as part of a development package is not appropriate. So I see several choices. Primarily, assume that more often than not, builds are not cross builds, thus if multi-lib is not supported, likely the build will fail on the multilib part. Therefore, disable it _by default_. The user has to override, even if they are doing a cross build for a platform with multi-lib. The user alters the default if the host platform does not support it. But anything at all, as long as the way forward is explicit and does not involve Google.
Re: fatal error: gnu/stubs-32.h: No such file
On Jul 8, 2013 4:39 PM, "Bruce Korb" wrote: > > Any solution other than an explanation-less "fatal error: > gnu/stubs-32.h: No such file" > is fine. There is no way to translate that message into > "Either --disable-multilib or else install glibc 32 bit development" > without coming up with the right Googling terms. I added http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h to improve things slightly. I don't think http://gcc.gnu.org/install/prerequisites.html mentions it so a patch to install.texi might be appropriate.
Re: fatal error: gnu/stubs-32.h: No such file
On 07/08/13 10:27, Jonathan Wakely wrote: I added http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h to improve things slightly. Ever so, but thank you. Ultimately, searching for just "stubs-32.h" will take you there and not require you to wade through too much chaff. You're still Googling instead of reading "you need to disable multilib or install a 32 bit development package", but it is ever so slightly better now. I don't think http://gcc.gnu.org/install/prerequisites.html mentions it so a patch to install.texi might be appropriate. That would be good. Speaking of, the fixinclude directory has been moved from fixincl to fixincludes. _That_, surely, is pretty inconsequential
Re: List of typos.
On Mon, 2013-07-08 at 16:12 +0200, Ondřej Bílka wrote: > On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote: > > On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote: > > > Ondrej Bilka schrieb: > > > > > > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch > > > > I fixed most comments, put it here so you can diff these two files. > http://kam.mff.cuni.cz/~ondra/gcc_misspell_fixed.patch > > > > > > > BASE must be either a declaration or a memory reference that has correct > > - alignment ifformation embeded in it (e.g. a pre-existing one in SRA). > > */ > > + alignment ifformation embedded in it (e.g. a pre-existing one in SRA). > > */ > > > > -> missed 'information' I guess... > > > > This fixes only a-e. These are probably incomplete as I needed to > exclude lot of names that are variable names etc. > > I did selectin based on following file: > http://kam.mff.cuni.cz/~ondra/gcc_misspells > > > > > > - http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algoritms > > + http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algorithms > > > > both links do 404 anyway ;) > > > could you find what this was? I need to add another filter not touch > html which I will do probably tomorrow. It seems the original article is gone. At least I can't find it easily (the patch that added the link is from 2001...). It's about Fibonacci Heaps so there's plenty of material out there on the net. The paper mentioned in the comment can be found rather easily: http://www.cs.princeton.edu/courses/archive/fall03/cs528/handouts/fibonacci%20heaps.pdf However, maybe it's better to replace the DDJ link with this http://en.wikipedia.org/wiki/Fibonacci_heap Cheers, Oleg
Re: [PATCH] fix typos mandated by conventions.
On Mon, 8 Jul 2013, Ondrej Bilka wrote: > Hi now, when I have infrastructure ready I made another patch (its 500kb so > link not to overload list). It is here; > http://kam.mff.cuni.cz/~ondra/gcc_misspell_conventions.patch > > It uses dictionary made by reading gcc conventions. > http://gcc.gnu.org/codingconventions.html As explained on that page, certain files and directories come from upstream and so it is inappropriate to apply GCC-specific conventions to them, or to fix any typos locally rather than upstream. In particular, you should not be patching boehm-gc or zlib. intl is also externally maintained code so again should not be patched for this issue; likewise libdecnumber and libffi (libdecnumber and libffi may get local patches, but only when needed to fix bugs, not simply for GCC-specific conventions). libiberty is shared with other projects so it's not clear that GCC-specific conventions should apply there; you need to discuss changes there in conjunction with the other projects. libjava/classpath and libjava/libltdl are also externally maintained. libquadmath code comes from glibc so unless the code in question is GCC-specific, do not apply GCC conventions to it. It's possible that the changes do make sense for the other projects, in that the GCC conventions are supposed to have good reasons behind them. But, you should raise the issues with those projects separately and if patches are desired only then produce patches relative to current upstream versions of those projects. It is not generally desirable to apply such cleanups to testcases. -- Joseph S. Myers jos...@codesourcery.com
