on how to compile gcc-4.6 correctly?
Hi, all, I'm using gentoo distribution (including gmp/mpfr/mpc) that could compile gcc-4.5.0, 4.5.1, and many snapshots correctly, including the recent one gcc-4.5-20100902, but when I tried to compile gcc-4.6, any snapshot version, even recent gcc-4.6-20100904, it always failed, the recent one failure compiling is: ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokdeclarator': ../../gcc-4.6-20100904/gcc/c-decl.c:5533: warning: format not a string literal and no format arguments ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokparms': ../../gcc-4.6-20100904/gcc/c-decl.c:6194: warning: format not a string literal and no format arguments ../../gcc-4.6-20100904/gcc/c-decl.c:7025:64: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_struct': ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: 'ggc_alloc_cleared_lang_type' undeclared (first use in this function) ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: (Each undeclared identifier is reported only once ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: for each function it appears in.) ../../gcc-4.6-20100904/gcc/c-decl.c:7308:62: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_enum': ../../gcc-4.6-20100904/gcc/c-decl.c:7308: error: 'ggc_alloc_cleared_lang_type' undeclared (first use in this function) make: *** [c-decl.o] Error 1 I don't know what happened with that? When I search the 'ggc_alloc_cleared_lang_type' macro, it really doesn't exist in the gcc-4.6-20100904 source, nor under /usr/include, so what is that macro real dependency? the prerequisites page seems not help me, http://gcc.gnu.org/install/prerequisites.html Who have successfully build gcc-4.6 please help me, or have any clue, I have searched that ggc_alloc_cleared_lang_type through google, but didn't find out any meaningful results, please make sure have my email address on cc-list that I can receive your email, because I didn't subscribe such high volume mailing list, Thank you very much, -- Dennis, from Singapore
Re: -fdump-translation-unit considered harmful
> Zack Weinberg <[EMAIL PROTECTED]> writes: > > [...] > > | Me ranting about -fdump-translation-unit had nothing to do with your > | problem, really, it's just that your message reminded me that I was > | going to bring that up. > > I think -fdump-translation-unit should remain. I thereby volunteer to > take any question about it. > > -- Gaby Gaby, I'm trying to use the -fdump-translation-unit option (gcc (GCC) 4.1.0 20050505 (experimental)), but it does not seem to do anything. What's the right way to use it - should I specify any additional switches/options? thanks, --Dennis.
RE: -fdump-translation-unit considered harmful
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, May 13, 2005 12:33 PM > To: Adam Nemet > Cc: Ian Lance Taylor; Dams, Dennis (Dennis); [EMAIL PROTECTED] > Subject: Re: -fdump-translation-unit considered harmful > > Adam Nemet <[EMAIL PROTECTED]> writes: > > | Ian Lance Taylor writes: > | > -fdump-translation-unit doesn't do anything in the C frontend. > | > | Is the patch below OK to update documentation accordingly? Tested > | with make info and make dvi. > > OK. > > Thanks, > > -- Gaby > Have there been any new thoughts/developments on the issue of elevating the current dump facilities (-fdump-translation-unit, and the -fdump-tree functionality) to a more formal API? We're working on a tool for static code analysis (aimed at verification issues and program understanding, rather than compile-time optimization). One kind of input that the tool can handle is the .t00.tu format as produced (for C) by an older version of the tree-ssa (in fact, the ast-optimizer) branch. Still, we had to make a few adjustments to make the dump format more useful - e.g.: * preventing the disposal of trees of function bodies, so that the dump includes all file-level definitions * preventing the insertion of pointer-offsets * adding double quotes around strings, and escaping certain characters in them, so as to make parsing easier It would be great if this behavior could be made part of the current GCC release. But it would be even better if there could be some prior agreement, among those who would be interested, about what a reasonable tree-dump format should look like. And then there are the legal issues - I don't actually know what the conclusion was of the discussions in this thread last Dec./Jan. --dennis.
Questions/Comments regarding my SoC application
Hi! I've applied for Google's Summer of Code 2007 with GCC as mentor organization. I want to make GCC working faster on the algorithmic level. I left out the detailed aims of the project, since i want to discuss them with gcc developers/mentors first. Do you have any suggestions what I should do? Are there any slow algorithms that should be replaced with high priority? Or shall i pick out the goals myself. But then I cannot estimate the expected time for finishing that project, I think you have a better overview in this case... I hope you can help me! Thx a lot, Dennis
Re: Questions/Comments regarding my SoC application
Paolo Bonzini schrieb: Dennis Weyland wrote: Hi! I've applied for Google's Summer of Code 2007 with GCC as mentor organization. I want to make GCC working faster on the algorithmic level. I left out the detailed aims of the project, since i want to discuss them with gcc developers/mentors first. Do you have any suggestions what I should do? Are there any slow algorithms that should be replaced with high priority? Or shall i pick out the goals myself. But then I cannot estimate the expected time for finishing that project, I think you have a better overview in this case... We have a collection of testcases with high number of basic blocks or with huge basic blocks; see for example PR28071. These are good candidates for your work. I would pay attention not only to making GCC faster, but also to making it use less memory. I'm not sure you can achieve asymptotic improvements in this case, though. Good luck! Paolo Hi! Initially I meant to optimize GCC, that includes runtime and memory usage, of course. I could not check my emails for some days now and I suppose it's too late now to alter the application. My question was, if you need information (in the application) about what I will EXACTLY do, or not. And the other question was, if there are special problems that have to be solved and that can also be solved within the Google's Summer of Code timeline. I am a little bit disappointed, that I had only so limited time and moreover no internet connection for some days. I don't know how the mode for accepting applications is, but if there is a chance for me to alter my application, please answer to my two questions from above. I really would like to do some challenging work for GCC and not basic programming or documentation only for other projects... Thanks, Dennis
Re: Questions/Comments regarding my SoC application
Hi! It's a pity that the application process has finished for some days... I was very motivated and have really good skills regarding efficient algorithms, complexity theory and compiler construction, but with not being accepted I would not have enough time for working on GCC since I have to earn money otherwise. Perhaps with a more detailled application my chances would have been better. Now i am only curious which projects have been accepted from GCC... Dennis Paolo Bonzini schrieb: Hi! Initially I meant to optimize GCC, that includes runtime and memory usage, of course. Sure. I meant that we have testcases that are good to test your work on. Profile GCC running them and fix the hotspots: this may show quadratic algorithms, and the like. For example, see the patch and thread at http://permalink.gmane.org/gmane.comp.gcc.patches/137697 I hope this clarifies my earlier message! Paolo
Re: Questions/Comments regarding my SoC application
Hi! That means GOOGLE did not approve my application? I thought it was GCC. How can I get to know why they did not approve me? As far as i know, the mentors can select which projects they want and which not, and not google itsel. but it seems that i was wrong. Well, I already completed one SoC successfully and so it is not that bad. Perhaps I will apply again next year and if, I will apply for GCC. Dennis Ian Lance Taylor schrieb: Dennis Weyland <[EMAIL PROTECTED]> writes: It's a pity that the application process has finished for some days... I was very motivated and have really good skills regarding efficient algorithms, complexity theory and compiler construction, but with not being accepted I would not have enough time for working on GCC since I have to earn money otherwise. Perhaps with a more detailled application my chances would have been better. Now i am only curious which projects have been accepted from GCC... The list of accepted projects can be found here: http://code.google.com/soc/gcc/about.html Unfortunately Google only provides a limited number of slots for each project. The gcc project received 22 applications, of which Google approved 8. Thanks for your interest, and I encourage you to apply again next year. Ian
Re: Questions/Comments regarding my SoC application
I was a little bit disappointed that the first reply on this newsgroup took so long. I just wanted to know which problems can be tackled and completed in the SoC timeframe... And i wonder why i only got 2 responses in the last two weeks in contrast with todays conversation with more than 2 responses in one day. Ian Lance Taylor schrieb: Dennis Weyland <[EMAIL PROTECTED]> writes: That means GOOGLE did not approve my application? I thought it was GCC. How can I get to know why they did not approve me? As far as i know, the mentors can select which projects they want and which not, and not google itsel. but it seems that i was wrong. The mentors for each project rank the applications. Google sets the number of applications which will be granted to each project. The gcc mentors (of whom I am one) ranked the 22 applications in order. Then Google decided to approve 8 applications for gcc. So the top 8 were approved. Your application was not one of the top 8. Well, I already completed one SoC successfully and so it is not that bad. Perhaps I will apply again next year and if, I will apply for GCC. Glad to hear it. It's unfortunate that you didn't have net access at a critical time to respond to the comment on your application. More details on your plans would have been helpful. Ian
Is ther document that describes how the "braching/fixing" on releases is done
GCC 7.5 November 14, 2019 GCC 9.2 August 12, 2019 GCC 9.1 May 3, 2019 GCC 8.3 February 22, 2019 GCC 7.4 December 6, 2018 GCC 6.5 October 26, 2018 GCC 8.2 July 26, 2018 GCC 8.1 May 2, 2018 GCC 7.3 January 25, 2018 GCC 5.5 October 10, 2017 GCC 7.2 August 14, 2017 GCC 6.4 July 4, 2017 GCC 7.1 May 2, 2017 GCC 6.3 December 21, 2016 for example: is the 6.4 release only a bug fix "branch" of the 6.3 "branch" and the real succesor of 6.3 is 7.1? and sucessor of 7.3 is 8.1?
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:03 schrieb David Edelsohn: https://gcc.gnu.org/develop.html#timeline Thanks any idea how to reintegrate (many) changes from a release/6.3.0 branch back into mainline? is there a tag or something where mainline was for short time in sync with 6.3.0?
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:27 schrieb David Edelsohn: On Sun, Feb 16, 2020 at 12:19 PM Dennis Luehring wrote: > > Am 16.02.2020 um 18:03 schrieb David Edelsohn: > > https://gcc.gnu.org/develop.html#timeline > > > Thanks > > any idea how to reintegrate (many) changes from a release/6.3.0 branch > back into mainline? > > is there a tag or something where mainline was for short time in sync > with 6.3.0? There is no need to reintegrate changes from a release into trunk. The intent is that all bugs are fixed on trunk and back-ported to branches. The fix on a release branch may be implemented differently or as a work-around, but the bug is intended to be fixed in all release branches that still are maintained, where the bug is relevant, that exhibited the bug and where the benefit justifies the potential risk of the bug fix. Thanks David i've got an older project where features where integrated based on an 6.3.0 branch no bug fixes - only new features and no backporting was done :( i now want to reintegrate these new features back into mainline (not directly into head due to amount conflicts) but somewhere around "GCC 7 Stage 4 (starts 2017-01-20)" could work i think or should i try to directly merge with a 7.1 tag branch, i've no idea how many changes where done
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:42 schrieb David Edelsohn: If you are trying to forward-port your own, proprietary features into a newer release of GCC for your own, internal use, that's your responsibility. that is my case, i ask for a meaningfull way of doing that i could upgrade the 6.3 branch to 6.4, 6.5 and then try to merge back into a branch based on releases/gcc-7.1.0 or try to directly merge the 6.3 with a releases/gcc-7.1 tag based branch, what would be easier?
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 17.02.2020 um 10:51 schrieb Richard Biener: I would start merging the new feature ontop master to the point where GCC 6 branched (so go _back_ in time) and only then start moving forward, remaining on master. good idea, thank you
update github gcc mirror forks to the new repo?
so the github gcc mirror is already using the new reposurgeon based git repo, that means that all the commit hashes etc. are different if someone forked this gcc mirror so easy pulling from the mirror isn't possible anymore - or am im wrong? is there any description how to "port" over github projects that dependens on the old repo? would a simple rebase work, or cherry picking? thx
Re: update github gcc mirror forks to the new repo?
Am 18.02.2020 um 11:43 schrieb Jonathan Wakely: On Tue, 18 Feb 2020 at 06:38, Dennis Luehring wrote: > > so the github gcc mirror is already using the new reposurgeon based git > repo, > > that means that all the commit hashes etc. are different if someone > forked this gcc mirror > > so easy pulling from the mirror isn't possible anymore - or am im wrong? > > > is there any description how to "port" over github projects that > dependens on the old repo? > > would a simple rebase work, or cherry picking? You can use rebasing or cherry-picking, but you need to do so carefully. If you try to rebase (or cherry-pick) onto the tip of a branch in the new repo you'll almost certainly get conflicts, because the new branch in the new repo has moved on since the point where you last pulled from the old repo. The best way is to find the commit in the new repo which corresponds to the last commit you have from the old repo, and rebase onto that. That way you can graft your local commits onto exactly the same tree (but with different hashes and different history) which should apply cleanly. There's a script to do that at https://gcc.gnu.org/ml/gcc/2020-01/msg00202.html (and an alternative in the reply to that email). To use the script you need to have set up a remote for the old repo (which you can remove again later if you want): git remote add gcc-old git://gcc.gnu.org/git/gcc-old.git git fetch gcc-old lets see if rebasing or cherry picking is easier, thank you
is there a reason why "explicit specialization in non-namespace scope" is still an error in gcc-trunk?
i've read that scoped template specalization is allowed in C++17
clang supports it starting with release 7
MSVC supports it with VS2017(i don't know what revision)
Intel does not like it
https://gcc.godbolt.org/z/1GET6v
--
enumclass E{ A, B };
struct Ta{ int x; };
struct Tb{ float y; };
struct Mapper
{
template struct type_to_enum{};
template<> // <-- FAILS
struct type_to_enum
{
staticconstexprauto value = E::A;
};
template <> // <-- Fails
struct type_to_enum
{
staticconstexprauto value = E::B;
};
};
---
when will scoped template specialization be available in gcc?
i've read that scoped template specalization is allowed in C++17
suports it:
-clang starting with release 7
-MSVC starting with VS2017(i don't know what revision)
no support:
-gcc(trunk)
-latest Intel
https://gcc.godbolt.org/z/1GET6v
--
enum class E{ A, B };
struct Ta{ int x; };
struct Tb{ float y; };
struct Mapper
{
template struct type_to_enum{};
template<> // <-- FAILS
struct type_to_enum
{
static constexpr auto value = E::A;
};
template <> // <-- Fails
struct type_to_enum
{
static constexpr auto value = E::B;
};
};
---
when will "scoped template specalization" be available? gcc trunk seems not support it
i've read that scoped template specalization is allowed in C++17 - is it
planned for the next gcc release?
otherwise i will switch to an if constexpr solution - but would be still
to have this feature
checked compiler:
gcc trunk (and latest intel) do not support it
clang (starting with release 7) and MSVC (starting with VS2017(i don't
know the exact revision)) supports it
--
enum class E{ A };
struct Ta{ int x; };
struct Mapper
{
template struct type_to_enum{};
template<> // <-- FAILS
struct type_to_enum
{
static constexpr auto value = E::A;
};
};
gcc 4.8.3 configure/build targeting alpha dec does not fully respect --prefix - or is it something else?
fs_tools/clfs_cross_tools/system/alpha/build_log/step_16_glibc-2.19/crt-path.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/mips64-64/build_log/step_16_glibc-2.19/crt-path.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/sparc64-64/build_log/step_16_glibc-2.19/crt-path.out
logged ld SEARCHDIR:
the ld searchpath is the same "/tools/lib" for all targets - that seems
correct
ld_SEARCHDIR.out is generated in step(14) Cross Binutils-2.24,
build_clfs_cross_tools.sh, line: 626
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/alpha/build_log/step_14_binutils-2.24/ld_SEARCHDIR.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/mips64-64/build_log/step_14_binutils-2.24/ld_SEARCHDIR.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/sparc64-64/build_log/step_14_binutils-2.24/ld_SEARCHDIR.out
the configure/make differences between the targets:
the mips64/sparc64/alpha Makefile/config.(status|log) for step(15) Cross
GCC-4.8.3 are nearly equal for the targets
and it doesn't seem that the gcc-search-dirs difference comes from here
see folder
https://github.com/LowLevelMahn/build_clfs_tools/step15_build_configure_logs_diffable
for being better diffable the target replaced by {TARGET}, the
clfs_target replace by [CLFS_TARGET} etc. so its easier to diff localy
with the prefered tool
===
My suspicions so far :
===
First idea: The also alpha targeting (but not supported) CLFS gcc
patching does not "change" enough for alpha
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/files/gcc-4.8.3-pure64_specs-1.patch
in step(15) Cross GCC-4.8.3, build_clfs_cross_tools.sh
1. line 680: patch -Np1 -i "${FILES}/gcc-4.8.3-pure64_specs-1.patch"
2. line 683: echo -en '/n#undef STANDARD_STARTFILE_PREFIX_1/n#define
STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"/n' >> gcc/config/linux.h
3. line 685: echo -en '/n#undef STANDARD_STARTFILE_PREFIX_2/n#define
STANDARD_STARTFILE_PREFIX_2 ""/n' >> gcc/config/linux.h
The patching only changes files in /gcc/config
I've copyied the original and patched /gcc/config tree into the
https://github.com/LowLevelMahn/build_clfs_tools/gcc-4.8.3.patch.files
folder - so its easier to diff localy with the prefered tool
!!!
Second and better idea:
!!!
i think gcc ./configure does not treat the parameters
--prefix=/cross-tools and --with-local-prefix=/tools in step(15) Cross
GCC-4.8.3, the same way for alpha as for mips/sparc targets
because the CLFS gcc patch does not patch /cross-tools into the sources
at all so /cross-tools from the gcc-search-dirs must come through gcc
configure parameters - but are just partialy missing with target alpha
so mips/sparc respecting --prefix=/cross-tools, but alpha only partialy
- seems to be a bug in gcc/configuration
===
Any idea/hint where/how to find/correct the gcc-search-dirs differences
for the alpha target to be CLFS conform and buildable?
Thanks,
Dennis
FIXED LINKS: gcc 4.8.3 configure/build targeting alpha dec does not fully respect --prefix - or is it something else?
ems correct
crt-path.out is generated in step(16) Glibc-2.19,
build_clfs_cross_tools.sh, line: 776
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/alpha/build_log/step_16_glibc-2.19/crt-path.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/mips64-64/build_log/step_16_glibc-2.19/crt-path.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/sparc64-64/build_log/step_16_glibc-2.19/crt-path.out
logged ld SEARCHDIR:
the ld searchpath is the same "/tools/lib" for all targets - that seems
correct
ld_SEARCHDIR.out is generated in step(14) Cross Binutils-2.24,
build_clfs_cross_tools.sh, line: 626
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/alpha/build_log/step_14_binutils-2.24/ld_SEARCHDIR.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/mips64-64/build_log/step_14_binutils-2.24/ld_SEARCHDIR.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/sparc64-64/build_log/step_14_binutils-2.24/ld_SEARCHDIR.out
the configure/make differences between the targets:
the mips64/sparc64/alpha Makefile/config.(status|log) for step(15) Cross
GCC-4.8.3 are nearly equal for the targets
and it doesn't seem that the gcc-search-dirs difference comes from here
see folder
https://github.com/LowLevelMahn/build_clfs_tools/step15_build_configure_logs_diffable
for being better diffable the target replaced by {TARGET}, the
clfs_target replace by [CLFS_TARGET} etc. so its easier to diff localy
with the prefered tool
===
My suspicions so far :
===
First idea: The also alpha targeting (but not supported) CLFS gcc
patching does not "change" enough for alpha
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/files/gcc-4.8.3-pure64_specs-1.patch
in step(15) Cross GCC-4.8.3, build_clfs_cross_tools.sh
1. line 680: patch -Np1 -i "${FILES}/gcc-4.8.3-pure64_specs-1.patch"
2. line 683: echo -en '/n#undef STANDARD_STARTFILE_PREFIX_1/n#define
STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"/n' >> gcc/config/linux.h
3. line 685: echo -en '/n#undef STANDARD_STARTFILE_PREFIX_2/n#define
STANDARD_STARTFILE_PREFIX_2 ""/n' >> gcc/config/linux.h
The patching only changes files in /gcc/config
I've copyied the original and patched /gcc/config tree into the
https://github.com/LowLevelMahn/build_clfs_tools/gcc-4.8.3.patch.files
folder - so its easier to diff localy with the prefered tool
Second and better idea:
i think gcc ./configure does not treat the parameters
--prefix=/cross-tools and --with-local-prefix=/tools in step(15) Cross
GCC-4.8.3, the same way for alpha as for mips/sparc targets
because the CLFS gcc patch does not patch /cross-tools into the sources
at all so /cross-tools from the gcc-search-dirs must come through gcc
configure parameters - but are just partialy missing with target alpha
so mips/sparc respecting --prefix=/cross-tools, but alpha only partialy
- seems to be a bug in gcc/configuration
===
Any idea/hint where/how to find/correct the gcc-search-dirs differences
for the alpha target to be CLFS conform and buildable?
Thanks,
Dennis
check for the existence of "__sync_lock_test_and_set"
https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html is there a define to check for the existence of "__sync_lock_test_and_set"
Re: Successful bootstrap and install of gcc (GCC) 6.3.0 on mips64el-unknown-linux-gnu
are you only building gcc or also glibc/binutils? and building a kernel with minimal hello world init or something for testing? what about a dec-alpha build test :) Am 08.01.2017 um 21:27 schrieb Aaro Koskinen: Hi, Here's a report of a successful build and install of GCC: $ gcc-6.3.0/config.guess mips64el-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/mipsel-unknown-linux-gnu/6.3.0/lto-wrapper Target: mipsel-unknown-linux-gnu Configured with: ../gcc-6.3.0/configure --with-arch=loongson2f --with-abi=32 --with-fp-32=xx --enable-targets=all --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=mipsel-unknown-linux-gnu --build=mipsel-unknown-linux-gnu --target=mipsel-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 6.3.0 (GCC) -- Build environment -- host: fuloong-minipc distro: los.git rootfs=ef31e1 native=ef31e1 kernel: Linux 4.9.0-lemote-los_ef31e1 binutils: GNU binutils 2.27 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.24 zlib: 1.2.8 mpfr: 3.1.3 gmp: 6 -- Time consumed -- configure: real0m 23.73s user0m 15.35s sys 0m 6.22s bootstrap: real50h 9m 38s user46h 31m 26s sys 3h 16m 30s install:real16m 28.01s user6m 15.90s sys 7m 51.50s -- Hardware details --- MemTotal: 494016 kB system type : lemote-fuloong-2f-box machine : Unknown processor : 0 cpu model : ICT Loongson-2 V0.3 FPU V0.1 BogoMIPS: 264.19 wait instruction: yes microsecond timers : yes tlb_entries : 64 extra interrupt vector : no hardware watchpoint : yes, count: 0, address/irw mask: [] isa : mips2 mips3 ASEs implemented: shadow register sets: 1 kscratch registers : 0 package : 0 core: 0 VCED exceptions : not available VCEI exceptions : not available A.
simple example -O3 optimizer problem?
tested following code with
http://gcc.godbolt.org/
tested with
g++-4.8 (Ubuntu 4.8.1.2ubuntu1~12.04) 4.8.1
g++ (GCC) 4.9.0 20130909 (experimental)
and the result with -O3 + defined USE_ITER seems to be a little bit long
--
static void foo(int a, int& dummy)
{
dummy += a;
}
#define USE_ITER
int main(int argc, char** argv)
{
//--
//anti-optimizer
int dummy = 0;
int* array = (int*)&argv;
//--
#if defined(USE_ITER)
int* pend = &array[10];
for(int* p = &array[0]; p < pend; ++p) foo(*p, dummy);
#else
for(int i = 0; i < 10; ++i) foo(array[i], dummy);
#endif
return dummy;
}
-
with -O2
with/without define USE_ITER
result:
main:
leardx, [rsp-8]
learcx, [rsp+32]
movQWORD PTR [rsp-8], rsi
xoreax, eax
.L3:
addeax, DWORD PTR [rdx]
addrdx, 4
cmprdx, rcx
jb.L3
rep; ret
with -O3
without define USE_ITER
main:
movrax, rsi
shrrax, 32
addeax, esi
addeax, DWORD PTR [rsp]
addeax, DWORD PTR [rsp+4]
addeax, DWORD PTR [rsp+8]
addeax, DWORD PTR [rsp+12]
addeax, DWORD PTR [rsp+16]
addeax, DWORD PTR [rsp+20]
addeax, DWORD PTR [rsp+24]
addeax, DWORD PTR [rsp+28]
ret
with define USE_ITER
main:
leardi, [rsp-16]
learax, [rsp+27]
movQWORD PTR [rsp-16], rsi
lear8, [rsp+24]
movecx, 1
leardx, [rdi+4]
learsi, [rdi+1]
subrax, rdx
movrdx, rdi
shrrax, 2
addrax, 1
cmprsi, r8
cmovbercx, rax
andedx, 15
shrrdx, 2
cmprcx, rdx
cmovberdx, rcx
cmprax, 8
ja.L30
.L2:
movrdx, rcx
.L11:
cmprdx, 1
moveax, DWORD PTR [rsp-16]
je.L13
addeax, DWORD PTR [rsp-12]
cmprdx, 2
je.L14
addeax, DWORD PTR [rsp-8]
cmprdx, 3
je.L15
addeax, DWORD PTR [rsp-4]
cmprdx, 4
je.L16
addeax, DWORD PTR [rsp]
cmprdx, 5
je.L17
addeax, DWORD PTR [rsp+4]
cmprdx, 6
je.L18
addeax, DWORD PTR [rsp+8]
cmprdx, 7
je.L19
addeax, DWORD PTR [rsp+12]
learsi, [rsp+16]
.L4:
cmprcx, rdx
je.L23
.L3:
subrcx, rdx
movr9, rcx
shrr9, 2
lear10, [0+r9*4]
testr10, r10
je.L6
leardx, [rdi+rdx*4]
cmpr9, 1
movdquxmm0, XMMWORD PTR [rdx]
jbe.L7
movdquxmm1, XMMWORD PTR [rdx+16]
cmpr9, 2
padddxmm0, xmm1
je.L7
movdquxmm1, XMMWORD PTR [rdx+32]
padddxmm0, xmm1
.L7:
movdqaxmm2, xmm0
learsi, [rsi+r10*4]
psrldqxmm2, 8
padddxmm0, xmm2
movdqaxmm3, xmm0
psrldqxmm3, 4
padddxmm0, xmm3
movdedx, xmm0
addeax, edx
cmprcx, r10
je.L23
.L6:
leardx, [rsi+4]
addeax, DWORD PTR [rsi]
cmpr8, rdx
jbe.L23
leardx, [rsi+8]
addeax, DWORD PTR [rsi+4]
cmpr8, rdx
jbe.L31
addeax, DWORD PTR [rsi+8]
ret
.L23:
rep; ret
.L30:
cmprsi, r8
ja.L2
xoreax, eax
testrdx, rdx
movrsi, rdi
je.L3
jmp.L11
.L31:
ret
.L16:
movrsi, rsp
jmp.L4
.L17:
learsi, [rsp+4]
jmp.L4
.L18:
learsi, [rsp+8]
jmp.L4
.L19:
learsi, [rsp+12]
jmp.L4
.L14:
learsi, [rsp-8]
jmp.L4
.L15:
learsi, [rsp-4]
jmp.L4
.L13:
learsi, [rdi+4]
jmp.L4
Re: simple example -O3 optimizer problem?
Am 18.07.2014 10:29, schrieb Andrew Haley: On 18/07/14 08:30, Dennis Luehring wrote: >int* array = (int*)&argv; This looks like undefined behaviour. Don't you get a warning? Andrew. no warning - its an valid typed pointer to stack and i don't care what the values are its just an anti-optimizer trick nothing more
Re: simple example -O3 optimizer problem?
Am 18.07.2014 11:14, schrieb Andrew Haley:
On 07/18/2014 09:40 AM, Dennis Luehring wrote:
> Am 18.07.2014 10:29, schrieb Andrew Haley:
>> On 18/07/14 08:30, Dennis Luehring wrote:
>>>int* array = (int*)&argv;
>>
>> This looks like undefined behaviour. Don't you get a warning?
>
> no warning - its an valid typed pointer to stack and i don't care what
> the values are
> its just an anti-optimizer trick nothing more
And if you give it the correct type, doe that make any difference?
static void foo(int a, int& dummy)
{
dummy += a;
}
#define USE_CHAR
#define USE_ITER
int main(int argc, char** argv)
{
//--
//anti-optimizer
int dummy = 0;
#if defined(USE_CHAR)
typedef char T;
T* array = argv[0];
#else
typedef int T;
T* array = (int*)&argv; // undefined?
#endif
//--
#if defined(USE_ITER)
T* pend = &array[10];
for(T* p = &array[0]; p < pend; ++p) foo(*p, dummy);
#else
for(int i = 0; i < 10; ++i) foo(array[i], dummy);
#endif
return dummy;
}
with USE_CHAR, with/without USE_ITER, -O3 gives:
main:
movrdx, QWORD PTR [rsi]
movsxecx, BYTE PTR [rdx]
movsxeax, BYTE PTR [rdx+1]
addeax, ecx
movsxecx, BYTE PTR [rdx+2]
addeax, ecx
movsxecx, BYTE PTR [rdx+3]
addeax, ecx
movsxecx, BYTE PTR [rdx+4]
addeax, ecx
movsxecx, BYTE PTR [rdx+5]
addeax, ecx
movsxecx, BYTE PTR [rdx+6]
addeax, ecx
movsxecx, BYTE PTR [rdx+7]
addeax, ecx
movsxecx, BYTE PTR [rdx+8]
movsxedx, BYTE PTR [rdx+9]
addeax, ecx
addeax, edx
ret
without USE_CHAR, without USE_ITER, -O3 gives:
main:
movrax, rsi
shrrax, 32
addeax, esi
addeax, DWORD PTR [rsp]
addeax, DWORD PTR [rsp+4]
addeax, DWORD PTR [rsp+8]
addeax, DWORD PTR [rsp+12]
addeax, DWORD PTR [rsp+16]
addeax, DWORD PTR [rsp+20]
addeax, DWORD PTR [rsp+24]
addeax, DWORD PTR [rsp+28]
ret
without USE_CHAR, with USE_ITER, -O3 gives
main:
leardi, [rsp-16]
learax, [rsp+27]
movQWORD PTR [rsp-16], rsi
lear8, [rsp+24]
movecx, 1
leardx, [rdi+4]
learsi, [rdi+1]
subrax, rdx
movrdx, rdi
shrrax, 2
addrax, 1
cmprsi, r8
cmovbercx, rax
andedx, 15
shrrdx, 2
cmprcx, rdx
cmovberdx, rcx
cmprax, 8
ja.L30
.L2:
movrdx, rcx
.L11:
cmprdx, 1
moveax, DWORD PTR [rsp-16]
je.L13
addeax, DWORD PTR [rsp-12]
cmprdx, 2
je.L14
addeax, DWORD PTR [rsp-8]
cmprdx, 3
je.L15
addeax, DWORD PTR [rsp-4]
cmprdx, 4
je.L16
addeax, DWORD PTR [rsp]
cmprdx, 5
je.L17
addeax, DWORD PTR [rsp+4]
cmprdx, 6
je.L18
addeax, DWORD PTR [rsp+8]
cmprdx, 7
je.L19
addeax, DWORD PTR [rsp+12]
learsi, [rsp+16]
.L4:
cmprcx, rdx
je.L23
.L3:
subrcx, rdx
movr9, rcx
shrr9, 2
lear10, [0+r9*4]
testr10, r10
je.L6
leardx, [rdi+rdx*4]
cmpr9, 1
movdquxmm0, XMMWORD PTR [rdx]
jbe.L7
movdquxmm1, XMMWORD PTR [rdx+16]
cmpr9, 2
padddxmm0, xmm1
je.L7
movdquxmm1, XMMWORD PTR [rdx+32]
padddxmm0, xmm1
.L7:
movdqaxmm2, xmm0
learsi, [rsi+r10*4]
psrldqxmm2, 8
padddxmm0, xmm2
movdqaxmm3, xmm0
psrldqxmm3, 4
padddxmm0, xmm3
movdedx, xmm0
addeax, edx
cmprcx, r10
je.L23
.L6:
leardx, [rsi+4]
addeax, DWORD PTR [rsi]
cmpr8, rdx
jbe.L23
leardx, [rsi+8]
addeax, DWORD PTR [rsi+4]
cmpr8, rdx
jbe.L31
addeax, DWORD PTR [rsi+8]
ret
.L23:
rep; ret
.L30:
cmprsi, r8
ja.L2
xoreax, eax
testrdx, rdx
movrsi, rdi
je.L3
jmp.L11
.L31:
ret
.L16:
movrsi, rsp
jmp.L4
.L17:
learsi, [rsp+4]
jmp.L4
.L18:
learsi, [rsp+8]
jmp.L4
.L19:
learsi, [rsp+12]
jmp.L4
.L14:
learsi, [rsp-8]
jmp.L4
.L15:
learsi, [rsp-4]
jmp.L4
.L13:
learsi, [rdi+4]
jmp.L4
but is still don't get whats undefined is with (int*)&argv - i
understand that the values are undefined (pointing anywhere in stack)
but why should the -O3 optimization generate such amount of code due to
this "undefined behavior"
strangely for clang 3.4.1 behaves different
with USE_CHAR, without USE_ITER, -O3 gives:
main: # @main
movq(%rsi), %rax
movsbl(%rax), %ecx
movsbl1(%rax), %edx
addl%ecx, %edx
movsbl2(%rax
Re: Status of C++11 support
Overview: https://gcc.gnu.org/projects/cxx-status.html#cxx11 Am 09.12.2019 um 04:17 schrieb Nicholas Krause: Greetings, I was wondering what the current status of being able to use C++11 is without the gcc project. Seems it will be much easier to implement basic spinlocks with the C++11 memory model than without. Thanks, Nick
Re: Proposal for the transition timetable for the move to GIT
the differences between Maxim and Erics final result will hopefully show the open bugs in both tools and allow fixing - i think this compare phase is needed if the result should be the best possible Am 11.12.2019 um 16:19 schrieb Jonathan Wakely: On Wed, 11 Dec 2019 at 15:03, Richard Earnshaw (lists) wrote: > I wouldn't bother with that. There are known defects in the version of > reposurgeon that I used to produce that which have since been fixed. It > was *never* the point of that upload to ask for correctness checks on > the conversion (I said so at the time). Instead it was intended to > demonstrate the improvements to the commit summaries that I think we can > make. My concern is that there is no conversion done using reposurgeon that *can* be used to do correctness checks.
current state of gcc-ia16?
is the patch already integrated into mainline? is this the most recent development place? https://github.com/tkchia/gcc-ia16
Re: current state of gcc-ia16?
is the patch already integrated into mainline? No, it's not. will that ever happen? is this the most recent development place? https://github.com/tkchia/gcc-ia16 Yes, that's the right place. thx Am 08.06.2018 um 12:59 schrieb Andrew Jenner: Hi Dennis, On 08/06/2018 11:37, Dennis Luehring wrote: > is the patch already integrated into mainline? No, it's not. > is this the most recent development place? > https://github.com/tkchia/gcc-ia16 Yes, that's the right place. Andrew
Re: Parma Polyhedra Library 0.11.1
> > We announce the availability of PPL 0.11.1, a new release of the Parma > Polyhedra Library. This release includes several important bug fixes > and performance improvements. I was awaiting this. I will now try this on Solaris. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
[Fwd: GCC 4.6.0 Released]
Seems to be working well on Solaris 8 Sparc thus far. No surprises. I'll
post a result set once the tests are complete but for now I see the output
from hello.c is exactly as expected :
# pwd
/tmp/test
# cat -n hello.c
1 #include
2
3 int
4 main(int argc, char *argv[])
5 {
6 printf ( "Hello World!\n" );
7 return (0);
8 }
# gcc --version
gcc (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# gcc -mcpu=v8 -mno-app-regs -mno-vis -m32 -S -o hello.s hello.c
# cat hello.s
.file "hello.c"
.section".rodata"
.align 8
.LLC0:
.asciz "Hello World!"
.section".text"
.align 4
.global main
.type main, #function
.proc 04
main:
save%sp, -96, %sp
st %i0, [%fp+68]
st %i1, [%fp+72]
sethi %hi(.LLC0), %g1
or %g1, %lo(.LLC0), %o0
callputs, 0
nop
mov 0, %g1
mov %g1, %i0
restore
jmp %o7+8
nop
.size main, .-main
.ident "GCC: (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011)
4.6.0"
#
This is precisely the same as the output from 4.5.2 :
# diff /export/medusa/dclarke/build/test/hello_gcc_sparcv7.s hello.s
25c25
< .ident "GCC: (Blastwave.org Inc. Thu Dec 16 18:30:45 GMT 2010)
4.5.2"
---
> .ident "GCC: (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011)
4.6.0"
#
Thus all is well.
GCC is the ultimate open source project in my opinion in that it gives
birth to everything else. Well, that makes binutils the pen-ultimate I
guess. :-)
Thank you to the massive collection of Red Hat guys and volunteers and
to a massive colleection of truely gifted programmers and the FSF for
making GCC possible.
--
Dennis Clarke
dcla...@opensolaris.ca <- related to the open source Solaris
dcla...@blastwave.org <- related to open source for Solaris
pub 1024D/FA35B44B 2008-08-17
fingerprint = B766 3250 1511 40C8 088A 12B9 1D93 6C72 FA35 B44B
--
/~\ The ASCII Ribbon Campaign
\ /No HTML/RTF in email
X No Word docs in email
/ \ Respect for open standards
Thought du jour
---
In fact, my main conclusion after spending ten
years of my life working on the TeX project is
that software is hard. It.s harder than anything
else I.ve ever had to do. Donald E. Knuth, 5 Oct 2001,
Professor Emeritus of The Art of Computer Programming
at the Technische Universitat M�chen in a lecture
entitled "All Questions Answered".
123456789+123456789+123456789+123456789+123456789+123456789+1234
MESSAGE ENDS --
Original Message
Subject: GCC 4.6.0 Released
From:"Jakub Jelinek"
Date:Mon, March 28, 2011 03:25
To: gcc-annou...@gcc.gnu.org
Cc: gcc@gcc.gnu.org
--
The GNU Compiler Collection version 4.6.0 has been released.
GCC 4.6.0 is a major release, containing substantial new functionality
not available in GCC 4.5.x or previous GCC releases.
The "link-time optimization" framework introduced in GCC 4.5.0 has been
significantly improved in this release, it is now possible to compile
very large applications like Mozilla or GCC itself with LTO.
GCC can now partially inline functions, inlining just hot short path
to exit and keeping the rest of the function out of line.
Support for the upcoming C++0x standard has been notably improved,
Fortran 2003 and 2008 has been greatly extended and many other frontends
undergone substantial changes as well.
Many other improvements have been added and more than thousand of bugs
have been fixed in various parts of the compiler collection.
See:
http://gcc.gnu.org/gcc-4.6/changes.html
for more information about changes in GCC 4.6.0.
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The release is in gcc/gcc-4.6.0/ subdirectory.
If you encounter difficulties using GCC 4.6, please do not contact me
directly. Instead, please visit http://gcc.gnu.org for information
about getting help.
As always, a vast number of people contributed to this GCC releases --
far too many to thank individually!
Re: GCC 4.6.0 Released
> On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote: >> Ryan Hill writes: >> >> > Does anyone know since when (if) running make check with more than one >> job >> > has been supported? IIRC back in the 3.x days it caused issues so >> we've >> > been forcing -j1 here forever. If we could run it in parallel that >> would be a >> > big timesaver. >> >> Jakub fixed it back in 2008 for gcc 4.4. It is indeed a big timesaver. > > Fixed just in the sense that the testing is more parallelized. > I've been using make -jN -k check for more than a decade and I don't > remember problems with that, mudflap tests are flaky and tend to fail > more often under load, but mudflap has only been added in 4.0. > Of course the N keeps changing over time, but currently testing certainly > works with -j48 that I'm using daily. > > Jakub Do you know if anyone has ever tested that on Solaris ? Lately Solaris is where open source goes to die ( blame Larry for that ) so I figure I may as well give it a shot, but before I do .. tell me know if this little trick works at all. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
> Dennis Clarke writes: > >> Do you know if anyone has ever tested that on Solaris ? Lately Solaris >> is >> where open source goes to die ( blame Larry for that ) so I figure I may >> as well give it a shot, but before I do .. tell me know if this little >> trick works at all. > > Why shouldn't it? No idea, and in the absence of data, I just am not sure yet. > I'm using it all the way from Solaris 8 to 11, with N > from 2 on a single-CPU HP Proliant DL-320 G2 via 96 on a 8-socket > NehalemEX Fujitsu RX900 S1 up to 128 on a SPARC Enterprise T5120. > awesome ... I am running it right now with N=2 and I have to assume that it will do the *exact* same results for my testsuite results. I already posted this : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02960.html So right now the very same machine, with no changes at all, is runnung with N=2. Thus far it looks to be quite busy : mpstat 5 says . . . CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 4552 1 151 623 235 399 100 80 820 4185 50 46 4 0 1 4538 1 225 286 49 360 106 76 810 3200 59 38 2 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3836 1 213 582 282 316 93 62 620 3375 62 34 3 0 1 4463 0 142 378 81 348 108 57 640 3655 62 36 2 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3180 1 141 521 220 286 81 56 440 3363 65 32 2 1 1 2895 0 150 258 38 298 93 59 490 2791 67 30 2 0 . . . > The only caveat are strange errors with gmake: > > make[3]: write error > > See CR 6938116GNU make highly unreliable: `write error' message. > > I've hacked around this by ignoring the error in misc.c (close_stdout) ;-) > It seems odd that gmake would pass every test in its own testsuite and then get an odd little message like that. Oh well, if you feel it can be ignored then I'm so very happy to see this. By the way, I just want to say thank you for posting results on Solaris because I review them and use them for comparison all the time. I am still fascinated that GCC can post different results on two servers running the same OS and probably with the same revs of tools avail. Consider this on Sol 8 i386 : === gcc Summary === # of expected passes72652 # of unexpected failures18 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1874 /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html === gcc Summary === # of expected passes74529 # of unexpected failures1 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1031 /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) I decided to toss caution to the wind and run my build with as and ld in /usr/ccs/bin and I was happy to see a decent result set. I often wonder if we *need* GNU as or just *want* GNU as in an older Solaris release like 8. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
> Dennis Clarke writes: > >>> The only caveat are strange errors with gmake: >>> >>> make[3]: write error >>> >>> See CR 6938116 GNU make highly unreliable: `write error' message. >>> >>> I've hacked around this by ignoring the error in misc.c (close_stdout) >>> ;-) >>> >> >> It seems odd that gmake would pass every test in its own testsuite and >> then get an odd little message like that. Oh well, if you feel it can be > > It only happens once in a while, and primarily for Solaris 11 NFS > servers. Even more rarely, it occurs on Solaris 11 locally. I generally build my prod things on Solaris 8 with the assumption that the Solaris ABI stability will provide what I need up to Solaris 9. Then I rebuild again on Solaris 10 for AMD64/x86_64 functionality. This has worked well thus far. I avoid Solaris 11 Express entirely as I just don't see it as a valid release yet. If the OpenSolaris project was still alive and the bug process was open then I'd may feel differently but with thing being as they are ... I avoid Sol 11 for now. > >> ignored then I'm so very happy to see this. > > I think it is harmless enough to be ignored in this particular case, but > this deviation from pre-S11 behaviour is bad. Suddenly expecting every > single piece of software to handle EINTR all over the place when you > didn't need to before and don't need it on any other platform isn't > exactly a winning proposition to me ;-( I'll try to pursue this with > Solaris engineering. How is that going ? I have filed bugs in the past regarding Studio 11 Update 1 and was not exactly thrilled with the response. However .. dropping an email to Daryl Gove can generally get things moving. >> By the way, I just want to say thank you for posting results on Solaris >> because I review them and use them for comparison all the time. I am >> still >> fascinated that GCC can post different results on two servers running >> the >> same OS and probably with the same revs of tools avail. >> >> Consider this on Sol 8 i386 : >> >> === gcc Summary === >> >> # of expected passes72652 >> # of unexpected failures18 >> # of expected failures 212 >> # of unresolved testcases 1 >> # of unsupported tests 1874 >> /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 >> (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) >> >> This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html >> >> === gcc Summary === >> >> # of expected passes 74529 >> # of unexpected failures 1 >> # of expected failures 212 >> # of unresolved testcases1 >> # of unsupported tests 1031 >> /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) > > One would have to compare gcc.sum in detail to know what's going on. > Well my testsuite run with N=2 finished and the results look like : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03106.html === gcc Summary === # of expected passes72652 # of unexpected failures18 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1874 /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) Exact same as before ! This is a very good sign. OKay .. so my days of running gmake -k check as a single thread are over. Thank you very much! >> I decided to toss caution to the wind and run my build with as and ld in >> /usr/ccs/bin and I was happy to see a decent result set. I often wonder >> if >> we *need* GNU as or just *want* GNU as in an older Solaris release like >> 8. > > IMO you want gas on Solaris/x86 before 10 because as lacks several > features there (like visibility support). On Solaris 10/x86 and up, as > is mostly fine (primarily COMDAT group support is missing, but I'm > working on that with the assembler and linker engineers as we speak). > Unfortunately, a recent as patch broke several -gstabs tests, but this > is expected to be fixed soon. > > On Solaris/SPARC I usually do the production builds with as; there seems > little reason to go for gas instead. > > Hope this helps. Very much so, thank you. I'll go back and rebuild on x86 with gas and leave my Sparc build as is. I generally do a double bootstrap merely to see what happens when GCC 4.6.0 is built with GCC 4.6.0 after it has already been bootstrapped. If I see any significant changes in the testsuite results then I assume something funky is afoot. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: I've successfully build 4.5.3 on Solaris x86
> uname -a : > SunOS devsolx86 5.10 Generic_139556-08 i86pc i386 i86pc Solaris > > config.guess output: > i386-pc-solaris2.10 > > gcc -v output: > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/usr_local/gcc4/bin/../libexec/gcc/i386-pc-solaris2.10/4.5.3/lto-wrapper > Target: i386-pc-solaris2.10 > Configured with: ../configure --with-gnu-as --with-as=/usr/sfw/bin/gas > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared > --enable-languages=c,c++ --with-gmp=/usr/local --with-mpfr=/usr/local > --prefix=/usr/local/gcc4 > Thread model: posix > gcc version 4.5.3 (GCC) > > Only enabled C/C++ > > Had to install mpc-0.8.1 (newer one didn't compile). Â used gmp-5.0.2, > mpfr-3.0.1 > see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00795.html New mpc compiles fine on Solaris 8 and 10 on Sparc v7, v8, v9 and on i386 and AMD64. I have not bothered with Intel i7 as I don't see it as any different from an x86_64 build on AMD Opterons. At least, the result is the same. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
gcc-4.6.2-RC-20111019 build problem in stage 2
uot;/usr/include/stdio.h" 3 4
typedef __longlong_t fpos64_t;
# 137 "/usr/include/stdio.h" 3 4
extern unsigned char _sibuf[], _sobuf[];
# 179 "/usr/include/stdio.h" 3 4
extern unsigned char *_bufendtab[];
extern FILE *_lastbuf;
# 215 "/usr/include/stdio.h" 3 4
extern void setbuffer(FILE *, char *, size_t);
extern int setlinebuf(FILE *);
extern int snprintf(char *, size_t, const char *, ...);
extern int vsnprintf(char *, size_t, const char *, __va_list);
# 236 "/usr/include/stdio.h" 3 4
extern FILE *fdopen(int, const char *);
extern char *ctermid(char *);
extern int fileno(FILE *);
# 262 "/usr/include/stdio.h" 3 4
extern FILE *popen(const char *, const char *);
extern char *cuserid(char *);
extern char *tempnam(const char *, const char *);
extern int getopt(int, char *const *, const char *);
extern int getsubopt(char **, char *const *, char **);
extern char *optarg;
extern int optind, opterr, optopt;
extern int getw(FILE *);
extern int putw(int, FILE *);
extern int pclose(FILE *);
extern int fseeko(FILE *, off_t, int);
extern off_t ftello(FILE *);
# 291 "/usr/include/stdio.h" 3 4
extern FILE *fopen64(const char *, const char *);
extern FILE *freopen64(const char *, const char *, FILE *);
extern FILE *tmpfile64(void);
extern int fgetpos64(FILE *, fpos64_t *);
extern int fsetpos64(FILE *, const fpos64_t *);
extern int fseeko64(FILE *, off64_t, int);
extern off64_t ftello64(FILE *);
# 2 "/export/medusa/dclarke/build/test/hello.c" 2
int
main(int argc, char *argv[])
{
printf ( "Hello World!\n" );
return (0);
}
Execution times (seconds)
TOTAL : 0.02 0.00 0.07
103 kB
#
#
looks good to me.
Somewhere in the Makefile the -liconv is absent and the breaks the build.
Let me vi Makefile and modify this :
# Libs and linker options needed for plugin support
PLUGINLIBS = -ldl
to this :
# Libs and linker options needed for plugin support
PLUGINLIBS = -ldl -liconv
Then run gmake again and see what I get.
# rm cc1
# cd ..
# pwd
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build
#
# ptime gmake
A few minutes later I see
.
.
.
gmake[3]: Entering directory
`/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/gcc'
.
.
.
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/xgcc
-B/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/
-B/opt/bw/sparc-sun-solaris2.8/bin/ -B/opt/bw/sparc-sun-solaris2.8/bin/
-B/opt/bw/sparc-sun-solaris2.8/lib/ -isystem
/opt/bw/sparc-sun-solaris2.8/include -isystem
/opt/bw/sparc-sun-solaris2.8/sys-include -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o
c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o
c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
sol2-c.o \
cc1-checksum.o main.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/opt/bw/lib/sparcv8 -lmpc -lmpfr -lgmp -ldl -liconv -L../zlib -lz
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/xgcc
-B/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/
-B/opt/bw/sparc-sun-solaris2.8/bin/ -B/opt/bw/sparc-sun-solaris2.8/bin/
-B/opt/bw/sparc-sun-solaris2.8/lib/ -isystem
/opt/bw/sparc-sun-solaris2.8/include -isystem
/opt/bw/sparc-sun-solaris2.8/sys-include-c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6.2-RC-20111019/gcc
-I../../gcc-4.6.2-RC-20111019/gcc/.
-I../../gcc-4.6.2-RC-20111019/gcc/../include -I./../intl
-I../../gcc-4.6.2-RC-20111019/gcc/../libcpp/include -I/opt/bw/include
-I../../gcc-4.6.2-RC-20111019/gcc/../libdecnumber
-I../../gcc-4.6.2-RC-20111019/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.6.2-RC-20111019/gcc/gcov.c -o gcov.o
.
.
.
etc etc and life goes on.
Seems as if -liconv got dropped somewhere and that was what was needed.
Did I miss something here ?
Dennis clarke
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
# of unexpected failures 768 ?
I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am seeing a really large increase in the number of "unexpected failures" on various tests. With 4.6.1 and Solaris I was able to get reasonable results : http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html Then if I use the resultant compiler from a 4.6.1 build I get a massive increase in failures on both i386 and Sparc : http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html and thus far on Sparc I see : === gcc Summary === # of expected passes69236 # of unexpected failures768 # of expected failures 235 # of unresolved testcases 1 # of unsupported tests 1240 /opt/bw/src/GCC/gcc-4.6.2-SunOS5.8-sparc/gcc/xgcc version 4.6.2 (Blastwave.org Inc Thu Oct 27 11:33:20 GMT 2011) and : === g++ Summary === # of expected passes26251 # of unexpected failures101 # of unexpected successes 1 # of expected failures 169 # of unresolved testcases 1 # of unsupported tests 496 /opt/bw/src/GCC/gcc-4.6.2-SunOS5.8-sparc/gcc/testsuite/g++/../../g++ version 4.6.2 (Blastwave.org Inc Thu Oct 27 11:33:20 GMT 2011) This seems blatantly wrong. At what point does one throw out the result of a bootstrap as not-acceptable ? With any non-zero value for "unexpected failures" ? Also, I see bucket loads of these : FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error) What should I think about an "internal compiler error" ? Dennis ( concerned in Solaris world ) -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> On 31 October 2011 15:33, Rainer Orth wrote: >> As an asside, I'd suggest to considerably reduce your set of configure >> options: many of them are the default (like --without-gnu-ld >> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix, >> --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8 >> --build=i386-pc-solaris2.8) or unnecessary >> (--enable-stage1-languages=c). > > Yes, adding completely redundant options looks like cargo cult > programming and just confuses anyone using the compiler who tries to > work out how it was configured. > >> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it >> might be better to keep the default of pentiumpro instead. > > Solaris 8 won't run on anything less than pentium, I recently > convinced someone else to stop building GCC for i386 on Solaris: > > http://gcc.gnu.org/ml/gcc-help/2011-10/msg5.html The Os is on Vintage support until March 2012. Also, I never had problems with it before. As for "completely redundant options" I have been building gcc like this for a while. also never a problem before. This is a case of "magic configure incantation" required ? I certainly hope not. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> These `I've used them for ever' options tend to do more harm than good, > and confuse other users that check how your copy of gcc was built. This > is especially bad for distributors like yourself, since the number of > confused people is far larger than for some company-internal build ;-) > > Rainer * nod * Will redo ... and see what I get. Thanks for the input. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> > Actually, it is uname showing the 'i386' on Solaris: > $ uname -p # Prints the current host's ISA or processor type. > i386 > $ uname -i # Prints the name of the platform. > i86pc > > So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any > difference here. > > Just my 2 cents. no prob. Actually on Solaris you will always get 'i386' even if you are running on a top of the line AMD Opteron 16-core machine with 8 sockets. It still reports that it is a i386 and not x86_64 or even amd64. Now isainfo and isalist are a whole other matter. Personally I'd like to see conffigure take advantage of that data as it is much more rich. On sparc you get this sort of data : # isalist -a sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc # isainfo -v 64-bit sparcv9 applications 32-bit sparc applications On some old pentium box you get this : Sun Microsystems Inc. SunOS 5.8 Generic February 2000 $ $ isalist -a pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 $ isainfo -v 32-bit i386 applications $ Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
>> It's redundant if you *want* to build for that host, but the whole >> point is that building for i386 is usually a very bad idea, so >> --host=i586-pc-solaris2.8 would be better. > > Erm - what I want to say is that I would really wonder if it does have > /any/ > influence (binary-wise) to gcc on Solaris (unlike Linux) whether to > configure > for i386 or i586 (via '--host' or even '--target'). > Oh, well, that would be a worthwhile experiment I think. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-----+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Ian Lance Taylor writes: > >> Michael Haubenwallner writes: >> >>> But still: given that x86-solaris started with some Pentium, I just >>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now. >>> >>> Especially as i386 (from config.guess) is the default too. >> >> I'm not sure why you don't believe it. It is what I would expect. >> >> If we want to make this work more normally for ordinary users, I think >> the right thing to do would be to patch config.guess to compute a better >> value for the build system CPU on Solaris systems. > > Please no: alpha went this route, and the consequence is that your > self-built gcc will generate code for the build system. This breaks > completely if you have a heterogeneous collection of systems, and the > GCC build system isn't the least common denominator of them. This > single-system mindset creates unnecessary trouble in this scenario. > GCC's configure has enough control over the default target CPU, even > without messing with config.guess, and most other programs won't care > about this at all. > > Personally I am all for "it ain't broke, don't fix it". Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Rainer Orth writes: > >> Ian Lance Taylor writes: >> >>> Michael Haubenwallner writes: >>> >>>> But still: given that x86-solaris started with some Pentium, I just >>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now. >>>> >>>> Especially as i386 (from config.guess) is the default too. >>> >>> I'm not sure why you don't believe it. It is what I would expect. >>> >>> If we want to make this work more normally for ordinary users, I think >>> the right thing to do would be to patch config.guess to compute a >>> better >>> value for the build system CPU on Solaris systems. >> >> Please no: alpha went this route, and the consequence is that your >> self-built gcc will generate code for the build system. This breaks >> completely if you have a heterogeneous collection of systems, and the >> GCC build system isn't the least common denominator of them. This >> single-system mindset creates unnecessary trouble in this scenario. >> GCC's configure has enough control over the default target CPU, even >> without messing with config.guess, and most other programs won't care >> about this at all. > > Oh, I completely agree that it would be wrong to have config.guess > produce the exact CPU used on the build system. > > But having config.guess produce "i386" for an OS which does not even run > on a vanilla i386 is also wrong. A much better choice here would be the > earliest CPU value which the OS actually supports. $ isalist -v pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 I would suggest pentium_pro if one can still find one running out there. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
# of unexpected failures 790
Well at this point I am getting results like this : === gcc Summary === # of expected passes74735 # of unexpected failures790 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1039 /opt/bw/src/GCC/gcc-4.6.2_SunOS5.8_i386/gcc/xgcc version 4.6.2 (Blastwave.org Inc. Sat Oct 29 20:12:45 GMT 2011) I am going to scrap the entire stack, start over from scratch with nothing but XPG4 tools ( ls, cp etc ) and a compiler such as Sun Studio 11. I can not recall ever trying to build gcc with Sun Studio but it is probably impossible. I'll give it a go anyways. This can't get worse. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
presence... yes checking for malloc.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking for feof_unlocked... no checking for fgets_unlocked... no checking for getc_unlocked... yes checking for getcwd... yes checking for getegid... yes checking for geteuid... yes checking for getgid... yes checking for getuid... yes checking for mempcpy... no checking for munmap... yes checking for putenv... yes checking for setenv... no checking for setlocale... yes checking for stpcpy... no checking for strcasecmp... yes checking for strdup... yes checking for strtoul... yes checking for tsearch... yes checking for __argz_count... no checking for __argz_stringify... no checking for __argz_next... no checking for __fsetlocking... yes checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... install-shextern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for nl_langinfo and CODESET... yes checking for LC_MESSAGES... yes checking for bison... bison checking version of bison... 2.4.3, ok checking whether NLS is requested... yes checking whether included gettext is requested... no checking for GNU gettext in libc... no checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... -lintl checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader configure: updating cache ./config.cache configure: creating ./config.status /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: ./conf4075subs.sh: file is too large configure: error: could not make ./config.status gmake[2]: *** [configure-stage1-intl] Error 1 gmake[2]: Leaving directory `/opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2_SunOS5.8_i386' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2_SunOS5.8_i386' gmake: *** [all] Error 2 real 49.639 user1.259 sys 0.381 titan$ I can not figure out why I would be seeing a error like that. baffled on Solaris , Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-----+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Dennis Clarke writes: > >> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am >> seeing a really large increase in the number of "unexpected failures" on >> various tests. >> >> With 4.6.1 and Solaris I was able to get reasonable results : >> >> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html >> >> Then if I use the resultant compiler from a 4.6.1 build I get a massive >> increase in failures on both i386 and Sparc : >> >> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html > > FAIL: g++.dg/ext/visibility/fvisibility-inlines-hidden-2.C scan-not-hidden > > All the scan-not-hidden failures are usually an indication that objdump > isn't in your PATH. Right, thank you. On i386 I rectified that situation with binutils however on Sparc this was not an issue. See results : http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html Only the new "go" language seems to be a major issue now. >> This seems blatantly wrong. At what point does one throw out the result >> of >> a bootstrap as not-acceptable ? With any non-zero value for "unexpected >> failures" ? > > There's no such number, only comparisons to other testsuite results. In > many cases (e.g. in the scan-not-hidden failures above), there's nothing > wrong with the compiler, just with the test environment. And in your > case, only two problems account for the vast majority of the failures. > >> Also, I see bucket loads of these : >> >> FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error) >> >> What should I think about an "internal compiler error" ? > > This seems fundamentally broken on your machine. With the exception of > the largefile.c testcases, those pass everywhere else, so you'd have to > debug what's going on there. Any "internal compiler error" mean throw the whole thing out and start over. At least that is the only safe course of action in my mind. > FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler > error) > [...] > FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess > errors) > WARNING: program timed out. > > Those test cases have excessive stack space or runtime requirements and > are known to fail on slow machines or those with default resource > limits. Those are known testcase bugs, but nobody cared about this so > far ;-( I'm so happy to hit those special cases :-) > Overall, your results don't look bad to me, once you've installed > objdump and investigated the PCH failures. yep ... I have been digging. On Sparc things are going much better but on i386 I have tossed the whole scenario out and am starting over from first principles. Build everything from scratch with the Sun Studio compiler until I hit things that need gcc. Like libgmp etc. > As an asside, I'd suggest to considerably reduce your set of configure > options: many of them are the default (like --without-gnu-ld > --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix, > --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8 > --build=i386-pc-solaris2.8) or unnecessary > (--enable-stage1-languages=c). > > I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it > might be better to keep the default of pentiumpro instead. Yep, did that. Thank you. However on i386 things got worse, not better. I have to toss that out and start over. On Sparc things are much better with the exception of "go". Thank you for the input. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
> This should probably be on the gcc-help list. I never really know which direction to go as the issues seem to be related to how limits-exprparen.c gets tested. However, no problem, I'll jump ship and get out of this ml. > On 7 November 2011 01:08, Dennis Clarke wrote: >> >> Well, dear GCC users I am now seeing behavior that falls in the arean of >> the bizarre. No sense in talking much about it but here is the error >> message : >> >> /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: >> ./conf4075subs.sh: file is too large >> configure: error: could not make ./config.status > > Have you checked your ulimit? I was thinking that too! I just recently increased the stack size limit to 16 MB : $ ulimit -a time(seconds)unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes)16384 coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited I am sure "unlimited" will work fine :-\ > And of course disk space? yep, got lots. Thanks for the input. I'll keep working on this until I get a clean bootstrap and if that takes a month, then fine. The results are always worth it and somewhat critical to have a compiler I trust. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Dennis Clarke writes: > >> Only the new "go" language seems to be a major issue now. > > The implementation of Go in the 4.6 releases does not support Solaris. > > Go on Solaris works on mainline. Well, I would not have seen that coming. I should look more closely at the various README's and changelogs. To be honest, I scrapped my Solaris Sparc resultant compiler here : http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html ... and am starting over. With no go, and no pun inteneded. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-----+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
> Message from Dennis Clarke at 2011-11-07 > 06:38:47 -- >> > Have you checked your ulimit? >> >>I was thinking that too! I just recently increased the stack size limit >> to >>16 MB : > > The 'fix' in mainline set it higher: > > 2011-07-22 Jakub Jelinek > > PR c++/49756 > * gcc.c (main): Call stack_limit_increase (64MB). > * toplev.c (toplev_main): Likewise. Well things seem to be working well on sparc and still very poorly on x86 so I am scrapping my whole stack on x86. Starting over one step at a time and carefully looking into testsuite results on every piece as I climb up the requirements. As for sparc, I expect to post good results, minus "go", in about 72 hours. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: bootstrap regression on sparc
> > While building libstdc++ I get an assertion failure in haifa-sched.c, > specifically the assertion on line 3437 is failing: I am seeing no major problems on Sparc at all. What rev of GCC are you referring to please? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
> The Go language is closing in what we are calling Go version 1. This > will be a long-term stable release of Go, with no language or library > API changes. Go 1 is described here: > > https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE per that doc : The Go 1 release will be available in source and binary form for at least these platforms: FreeBSD 7+: amd64, 386 Linux 2.6+: amd64, 386, arm OS X (Snow Leopard + Lion): amd64, 386 Windows (2000 + later): amd64, 386 Therefore not on Solaris 10 or even a baseline Solaris 8 at all. That seems to be an issue given this : People should be able to write Go programs and expect that they will continue to compile and run without change, on a timescale of years. In keeping with the spirit of that vision what are the issues that block a port to Solaris today? Are there specific bugids I can look at ? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
Re "go" for Solaris I see this : http://code.google.com/p/gofrontend/issues/detail?id=6 Not sure what the status in the mainline is but I am willing to do a checkout and build and see what goes wrong. I have 4.6.2 well done on Sparc Solaris 8 and that seems like a good place to start. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
4.7 RC ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any expected date on a 4.7 RC ? - -- - -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (SunOS) iEYEARECAAYFAk8O6ugACgkQHZNscvo1tEuVHACfU3BP6IvjF6ifEqH9VM/emDfH EDMAn1dOUcNOelZU+z9Z81IWrQLE8foV =tWIW -END PGP SIGNATURE-
Re: 4.7 RC ?
>> Any expected date on a 4.7 RC ? > > When it's ready. Which we'd usually expect it to be around the > beginning of April. cool. thank you. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
> Joel Sherrill writes:
>
>> On 01/12/2012 12:16 PM, Andreas Schwab wrote:
>>> Ian Lance Taylor writes:
>>>
>>>> The functions required are makecontext, getcontext, and setcontext.
>>> Note that these functions are obsolescent in POSIX.1-2004 and removed
>>> from POSIX.1-2008.
>> Are there any alternatives? It is bad that Go is already starting
>> out dependent on obsolete methods. :(
>
> I would be glad to use alternatives but I'm not aware of any.
>
> The getcontext and setcontext functions are easy. The harder one is
> makecontext. POSIX appears to be assuming that any use of makecontext
> can be replaced with pthread_create, but if you care about efficiency
> that simply isn't true.
>
> Ian
>
Stuff from the opensolaris project isn't going to help here is it ?
void
makecontext(ucontext_t *ucp, void (*func)(), int argc, ...)
{
greg_t *reg;
long *tsp;
char *sp;
int argno;
va_list ap;
size_t size;
reg = ucp->uc_mcontext.gregs;
reg[REG_PC] = (greg_t)func;
reg[REG_nPC] = reg[REG_PC] + 0x4;
/*
* Reserve enough space for a frame and the arguments beyond the
* sixth; round to stack alignment.
*/
size = sizeof (struct frame);
size += (argc > 6 ? argc - 6 : 0) * sizeof (long);
/*
* The legacy implemenation of makecontext() on sparc has been to
* interpret the uc_stack.ss_sp member incorrectly as the top of the
* stack rather than the base. We preserve this behavior here, but
* provide the correct semantics in __makecontext_v2().
*/
sp = (char *)(((uintptr_t)ucp->uc_stack.ss_sp - size) &
~(STACK_ALIGN - 1));
/*
* Copy all args to the stack, and put the first 6 args into the
* ucontext_t. Zero the other fields of the frame.
*/
/* LINTED pointer cast may result in improper alignment */
tsp = &((struct frame *)sp)->fr_argd[0];
bzero(sp, sizeof (struct frame));
va_start(ap, argc);
for (argno = 0; argno < argc; argno++) {
if (argno < 6)
*tsp++ = reg[REG_O0 + argno] = va_arg(ap, long);
else
*tsp++ = va_arg(ap, long);
}
va_end(ap);
reg[REG_SP] = (greg_t)sp - STACK_BIAS; /* sp (when done) */
reg[REG_O7] = (greg_t)resumecontext - 8;/* return pc */
}
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: Go in gcc 4.7
> Dennis Clarke writes:
>
>> for (argno = 0; argno < argc; argno++) {
>> if (argno < 6)
>> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long);
>> else
>> *tsp++ = va_arg(ap, long);
>
> This is broken. The arguments are of type int, not long.
To be more compliant with IEEE Std 1003.1-2001 ( ISO/IEC 9899:1999
standard, Section 6.2.5 ) they should be int32_t or similar as
per stdint.h.
But hey, I was just thinking out loud and more concerned about a
functional go compiler in gcc 4.7 RC. I am currently digging around
in snapshots 4.7-20120107.
Dennis
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-----+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: Memory corruption due to word sharing
> I have actually tried exactly this earlier today (because while looking at
> this, I had an idea that putting volatile in place could be a workaround,
> causing gcc to generate a saner code), but it doesn't work either:
>
> # cat x.c
> struct x {
> long a;
> volatile unsigned int lock;
> unsigned int full:1;
> };
>
> void
> wrong(struct x *ptr)
> {
> ptr->full = 1;
> }
>
> int main()
> {
> wrong(0);
> }
> In my opinion, this is a clear bug in gcc (while the original problem,
> without explitict volatile, is not a C spec violation per se, it's just
> very inconvenient :) ).
As a data point, the exact same code on a Solaris 8 pentium III box:
$ gcc -S -o x.s x.c
$ cat x.s
.file "x.c"
.text
.globl wrong
.type wrong, @function
wrong:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movzbl 8(%eax), %edx
orl $1, %edx
movb%dl, 8(%eax)
popl%ebp
ret
.size wrong, .-wrong
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$4, %esp
movl$0, (%esp)
callwrong
leave
ret
.size main, .-main
.ident "GCC: (Blastwave.org Inc. Thu Dec 16 18:05:01 GMT 2010) 4.5.2"
$ gcc -o x x.c
$ file x
x: ELF 32-bit LSB executable 80386 Version 1, dynamically linked,
not stripped
$ ldd x
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
$ ./x
Segmentation Fault(coredump)
$ ls -l core
-rw--- 1 dclarke csw71384 Feb 1 17:26 core
71384 bytes core is complete thus :
$ elfdump -p core | tail -6
Program Header[12]:
p_vaddr: 0xdfbf3000 p_flags:[ PF_X PF_W PF_R ]
p_paddr: 0 p_type: [ PT_LOAD ]
p_filesz: 0x1000 p_memsz:0x1000
p_offset: 0x106d8 p_align:0
$ /opt/studio/SOS11/SUNWspro/bin/dbx -c "print 0x1000 + 0x106d8; quit"
dbx: warning: unknown language, 'c' assumed
0x1000+0x106d8 = 71384
what caused the seg fault ?
$ /opt/studio/SOS11/SUNWspro/bin/dbx x core
Reading x
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x08050672: wrong+0x0006: movzbl 0x0008(%eax),%edx
(dbx) where
=>[1] wrong(0x0, 0x8047b70, 0x805057d, 0x1, 0x8047b7c, 0x8047b84), at 0x8050672
[2] main(0x1, 0x8047b7c, 0x8047b84), at 0x8050690
However Sun Studio 5.8 does no better :
$ /opt/studio/SOS11/SUNWspro/bin/cc -Xc -o x_Sun_Studio_5.8 x.c
$ ./x_Sun_Studio_5.8
Segmentation Fault(coredump)
$ ls -l core
-rw--- 1 dclarke csw71384 Feb 1 17:48 core
$ /opt/studio/SOS11/SUNWspro/bin/dbx x_Sun_Studio_5.8 core
dbx: warning: core object name "x_Sun_Studio_5." matches
object name "x_Sun_Studio_5.8" within the limit of 14. assuming they match
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x080506ae: wrong+0x000e: movl 0x0008(%ecx),%eax
(dbx) where
=>[1] wrong(0x0), at 0x80506ae
[2] main(0x1, 0x8047b4c, 0x8047b54), at 0x80506ca
(dbx) quit
$ /opt/studio/SOS11/SUNWspro/bin/cc -V
cc: Sun C 5.8 Patch 121016-08 2009/04/20
usage: cc [ options] files. Use 'cc -flags' for details
$
dc
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
> Eric Botcazou writes: > >> > I was looking through the gcc-4.5 primary and secondary platform list >> > to ensure we have coverage for MPC testing. It occurs to me that some >> > of the OS versions are outdated. >> > >> > I've included the list from the page >> > http://gcc.gnu.org/gcc-4.5/criteria.html >> > >> > Should we update: >> > >> > 1. solaris2.10 -> 2.11 >> >> Why move to a not-yet-released version? > > Indeed: while I regularly test on Solaris 11/SPARC at the moment, it's > still so much of a moving target that this doesn't make any sense. The issue may be one of "de facto" vs "defined as being" released. There is no such thing as a released Solaris revision that responds to uname with SunOS5.11 yet. When Sun/Oracle actually releases something AND you can buy a support contract for it then you have a valid platform in commercial use. Having said that .. I see roughly 30% of all my traffic from SunOS5.11 users on either Solaris Nevada or OpenSolaris beta releases. The question should be ... do we in the community end user world see SunOS5.11 as being a de facto release? I would say yes. Solaris 10 is the enterprise class commercial grade Solaris release and it is staying put for a long long long time yet. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
>> you can buy a support contract for it then you have a valid platform in >> commercial use. > > You can get support for the OpenSolaris distribution if you like I just went and looked ... you are correct, they have three levels in fact. It looks like $1080 for premium, $720 is standard business hours $324 is patches and updates with email tech support I think. So that makes it a real commercial platform in my mind. > is still very much work in progress, not a stable platform we can rely on. However, Solaris 10 was also a moving platoform in its first few releases but no one would debate it as a commercial grade release or not. I think Opensolaris must be looked at as viable and commercial grade. I am not at all biased in this regardless of the fact that I have been involved one way or another in the OpenSolaris project since day one. I'm very much an outside guy that just loves to experiment and perhaps even attempt to help where I can. >> Having said that .. I see roughly 30% of all my traffic from SunOS5.11 >> users on either Solaris Nevada or OpenSolaris beta releases. >> >> The question should be ... do we in the community end user world see >> SunOS5.11 as being a de facto release? I would say yes. > > Certainly not, even if it is widely used (primarily on laptops, I > suppose). Well, would Fedora Core on PowerPC or Ubuntu or Debian ( any release ) be considered a platform or does that just fall under a wide umbrella of "Linux" ? Some of those are barely used at all anymore. Consider running Linux on a DEC Alpha. Who does that anymore? Is this a popularity measurement or is this based on something more tangible and quantitative like "commercially supported"? >> Solaris 10 is the enterprise class commercial grade Solaris release and >> it is staying put for a long long long time yet. > > Indeed, and even if we chose sparc-sun-solaris2.10 as the primary platform > doesn't mean that *-*-solaris2.11 doesn't work, quite the contrary: I > regularly test both and try to keep them working. I test everything on *-*-solaris2.8 which by way of the ABI golden rule instantly qualifies as tested on anything up to SunOS2.10. It does not imply SunOS2.11 however. -- Dennis
Re: WTF?
> On Wed, 25 Nov 2009, Dave Korn wrote: >> Joseph S. Myers wrote: >> > Doing it right at the end of branch-to-trunk merges for a release >> (which >> > is where we are right now, just after merges from Graphite) is >> probably >> > the optimal timing in terms of minimising the amount of branches that >> will >> > need fixing up. The problem is doing it without warning or consensus. >> >> Yep. Given that, maybe we should make a global whitespace cleanup an >> official part of the release branching process? It would be nice to >> keep it >> from all building up again, and we could avoid the pain if it was >> regular and >> predictable. > > What is the _point_ in doing this? Is there _any_ positive effect > of removing trailing whitespace? Does it looks like there are no bugs to > fix in gcc so that the pointless task of removing trailing whitespace > looks appealing?? Gentlemen, a point of order please. Many people read these lists and we place high regard on the quality of the GCC project as well as the people involved. A personal slight as well as an error may happen from time to time but this is simply the nature of working as a software engineer. Let us not degrade into a base argument with words traded and thus undermine the great name that GCC and open source has. I am sure that this issue can be resolved without any damage done to the most precious resource we have, good people that work together openly and with respect and dignity. Having said that, I firmly would defend any of you as truely awesome engineers and good people that work to benefit the state of mankind. -- Dennis Clarke http://www.blastwave.org/ dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
trivial trailing whitespace issue
May I make a subject line change please ? This issue is trivial trailing whitespace changes I think and procedures, process and notice of such changes. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris Original Message Subject: [ Three letter acronym deleted ] From:"Richard Guenther" Date:Wed, November 25, 2009 14:43 To: "Richard Kenner" Cc: m...@suse.de gcc@gcc.gnu.org hongjiu...@intel.com l...@redhat.com -- On Wed, 25 Nov 2009, Richard Guenther wrote: > On Wed, 25 Nov 2009, Richard Kenner wrote: > > > > In my mind it's very simple: trailing whitespace poses exactly _no_ > > > problem (except of being against the coding standard), > > > But different timing or a notice wouldn't fix one of my no longer > applying patches. If you can offer advice on how to teach quilt > (which I belive uses patch) to ignore whitespace changes when > applying patches then more power to you - the only tool that > seems to be able to ignore whitespace changes is diff. Btw, I'd be happy with a commit hook that forces you to fix whitespace in the area you patch (basically just make sure there is no trailing whitespace in ^[+ ] lines of a unified diff (maybe even only in ^+ lines to not cause continuous rejects if you fixup the ^ lines in your patch and drag in more context). Anyone willing to implement that? I still see no point in fixing up the existing source just for the sake of it. Richard.
Account request
Hi, I am currently having my first patch to gfortran accepted, but was not able to manipulate the PR in bugzilla. A helpful soul on the gfortran list then pointed me to this address to ask whether I need a gcc.gnu.org account to work with bugzilla. Is that right? If it is, where can I get one of those? If this is already the right place, [EMAIL PROTECTED] would be my choice :) Thanks! Dennis
Re: A bug?
c4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
$ cat foo.s
.file "foo.c"
.section".text"
.align 4
.global s
.type s, #function
.proc 010
s:
save%sp, -136, %sp
ld [%fp+64], %l0
mov 72, %g1
stb %g1, [%fp-36]
stb %g0, [%fp-35]
mov %l0, %g1
add %fp, -36, %g2
mov 20, %g3
mov %g1, %o0
mov %g2, %o1
mov %g3, %o2
callmemcpy, 0
nop
mov %l0, %i0
restore
jmp %o7+12
nop
.size s, .-s
.section".rodata"
.align 8
.LLC0:
.asciz "%s\n"
.section".text"
.align 4
.global main
.type main, #function
.proc 04
main:
save%sp, -168, %sp
add %fp, -36, %g1
st %g1, [%sp+64]
calls, 0
nop
unimp 20
ld [%fp-36], %g1
st %g1, [%fp-64]
ld [%fp-32], %g1
st %g1, [%fp-60]
ld [%fp-28], %g1
st %g1, [%fp-56]
ld [%fp-24], %g1
st %g1, [%fp-52]
ld [%fp-20], %g1
st %g1, [%fp-48]
add %fp, -64, %g2
sethi %hi(.LLC0), %g1
or %g1, %lo(.LLC0), %o0
mov %g2, %o1
callprintf, 0
nop
restore
jmp %o7+8
nop
.size main, .-main
.ident "GCC: (GNU) 4.3.2"
$
$
$ /opt/csw/gcc4/bin/gcc -o foo foo.s
$ ./foo
H
works right ?
Dennis Clarke
http://www.blastwave.org/
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
>
> On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> struct Hello r;
>> r.world[0]='H';
>> r.world[1]='\0';
>> return r;
>> }
>>
>> int main(){
>> printf("%s\n",s().world);
>> }
>>
>> Assigning s() to a variable and then using the variable avoids the
>> segfault.
>
> Had you compiled with -Wall would you have noticed:
>
> e.c:13: warning: format â%sâ expects type âchar *â, but
> argument 2 has type âchar[20]â
>
> And when there is a type mismatch, a crash is pretty likely.
> Not that I can say why gcc does not convert it to char* but g++ does.
>
> Now what happens? The following augmented snippet shows it:
> ---<8---
> #include
> #include
> #include
> struct Hello {
>char world[20];
> };
> struct Hello s(void)
> {
> struct Hello r;
> strcpy(r.world, "Hello");
> return r;
> }
> static void dump(const char *fmt, ...)
> {
> va_list argp;
> va_start(argp, fmt);
> char *p = va_arg(argp, char *);
> printf("%p\n", p);
> va_end(argp);
> }
> int main(void)
> {
> dump("", s().world);
> return 0;
> }
> --->8---
>
> I get 0x6c6c6548, which is obviously part of the string Hello. So
> passing a char[20] into a varargs function seems not to convert it to
> char* when done through a non-visibile temporary (the result of s()
> is hidden on the stack of main).
On a baseline test machine ( Solaris 8 sun4m ) I get this with GCC 4.3.2 :
$ gcc -o foo2_gcc foo2.c
foo2.c: In function 'dump':
foo2.c:16: error: '__builtin_va_alist' undeclared (first use in this
function)
foo2.c:16: error: (Each undeclared identifier is reported only once
foo2.c:16: error: for each function it appears in.)
If I use very very old Sun Studio 8 I get this :
$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.5 Patch 112760-19 2007/08/02
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/SUNWspro/bin/cc -o foo2 foo2.c
$ mcs -p foo2
foo2:
@(#)stdarg.h1.4599/08/10 SMI
@(#)stdarg_iso.h1.1 99/08/09 SMI
@(#)va_list.h 1.1299/05/04 SMI
@(#)stdio.h 1.7899/12/08 SMI
@(#)stdio_iso.h 1.2 99/10/25 SMI
@(#)feature_tests.h 1.1899/07/26 SMI
@(#)isa_defs.h 1.2099/05/04 SMI
@(#)stdio_tag.h 1.3 98/04/20 SMI
@(#)stdio_impl.h1.8 99/06/10 SMI
@(#)string.h1.2499/08/10 SMI
@(#)string_iso.h1.2 99/11/09 SMI
acomp: Sun C 5.5 Patch 112760-19 2007/08/02
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.302
$ ./foo2
ec50
With Sun Studio 12 on Solaris 10 ( AMD64 this time ) I get
$ uname -a
SunOS isis 5.10 Generic_137138-09 i86pc i386 i86pc
$ cat /etc/release
Solaris 10 5/08 s10x_u5wos_10 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
$ /opt/studio/SOS12/SUNWspro/bin/cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/studio/SOS12/SUNWspro/bin/cc -o foo2 foo2.c
$ ./foo2
8047d70
so .. pretty wildly different results.
Dennis
--
Dennis Clarke
gcc-4.3.3 bootstrap fails on old Sun Sparc
This is on an old Sun Sparc machine running Solaris 8. I had CFLAGS set thus : $ echo $CFLAGS -mcpu=v7 -m32 -mno-app-regs -pthreads I was using gcc version 4.2.4 to perform this bootstrap and I set the configure options for non-GNU as and ld thus : $ ../gcc-4.3.3/configure --with-as=/usr/ccs/bin/as \ > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7 \ > --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local \ > --with-local-prefix=/export/home/dclarke/local --enable-shared \ > --enable-languages=c,c++,objc,fortran \ > --with-gmp=/export/home/dclarke/local \ > --with-mpfr=/export/home/dclarke/local \ > --enable-bootstrap Phase one of the boot strap results in this : $ /export/nfs/build/gnu/GCC/gcc-4.3.3-build/gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local --with-local-prefix=/export/home/dclarke/local --enable-shared --enable-languages=c,c++,objc,fortran --with-gmp=/export/home/dclarke/local --with-mpfr=/export/home/dclarke/local --enable-bootstrap Thread model: posix gcc version 4.3.3 (GCC) Shortly into what looks like phase 2 I see the process fails thus : /export/nfs/build/gnu/GCC/gcc-4.3.3-build/./gcc/xgcc -B/export/nfs/build/gnu/GCC/gcc-4.3.3-build/./gcc/ -B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/ -B/export/home/dclarke/local/sparc-sun-solaris2.8/lib/ -isystem /export/home/dclarke/local/sparc-sun-solaris2.8/include -isystem /export/home/dclarke/local/sparc-sun-solaris2.8/sys-include -g -fkeep-inline-functions -m64 -O2 -O2 -g -mcpu=v7 -m32 -mno-app-regs -pthreads -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I../../../../gcc-4.3.3/libgcc -I../../../../gcc-4.3.3/libgcc/. -I../../../../gcc-4.3.3/libgcc/../gcc -I../../../../gcc-4.3.3/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-4.3.3/libgcc/../gcc/libgcc2.c \ xgcc: may not use both -m32 and -m64 make[5]: *** [_muldi3.o] Error 1 make[5]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build/sparc-sun-solaris2.8/sparcv9/libgcc' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build/sparc-sun-solaris2.8/libgcc' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build/sparc-sun-solaris2.8/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build' make: *** [all] Error 2 I do not know why the option -m64 is in there. I certainly didn't ask for it. Any thoughts on this ? -- Dennis Clarke
Re: gcc-4.3.3 bootstrap fails on old Sun Sparc
> On Tue, Jan 27, 2009 at 04:53:09PM -0800, Dennis Clarke wrote: >> >> This is on an old Sun Sparc machine running Solaris 8. >> >> I had CFLAGS set thus : >> >> $ echo $CFLAGS >> -mcpu=v7 -m32 -mno-app-regs -pthreads > > That's your problem. Try again without this setting. > >> Shortly into what looks like phase 2 I see the process fails thus : >> ... > >> xgcc: may not use both -m32 and -m64 > > It blew up when trying to build 64-bit code, when you'd set CFLAGS > to -m32. First ... thank you for the reply. I know that you do a great deal of work with GCC on Solaris and Sparc and I compare my testsuite data to your reports at every opportunity. That sort of makes your results my benchmark. Now, the issue is that I don't want 64-bit code. At all. Period. This is old 32-bit Sparc so I don't think 64-bit code will serve any purpose here. Am I wallowing in ignorance and missing something obvious? Please feel free to hit me with a brick if that is the case :-) Dennis
Re: gcc-4.3.3 bootstrap fails on old Sun Sparc
> On Tue, Jan 27, 2009 at 05:24:36PM -0800, Dennis Clarke wrote: >> This is old 32-bit Sparc so I don't think 64-bit code will serve any >> purpose here. > > Specifying --disable-multilib at configure time should keep it from > building the 64-bit libraries. I'll give that a try thank you ! My objective here is to build a basic sparc compiler package first and then use that resultant compiler to build a full package. One of the things I have had no joy with is figuring out how to include the ada component but that is a battle for another day. Dennis
Re: gcc-4.3.3 bootstrap fails on old Sun Sparc
> Andreas Schwab writes: > >> Dennis Clarke writes: >> >> > One of the things I have had no joy with is figuring out how to >> > include the ada component but that is a battle for another day. >> >> To build ada you need a good ada compiler to start with. If you don't >> have one natively you need to build a cross compiler on a system that >> has one and then build the native ada compiler with this cross >> compiler. Then you can rebootstrap with ada enabled. > > Probably lots of hassle. If needed, I can provide bootstrap GNAT for both > Solaris/SPARC and x86, since I (sort of) regularly test on both platforms > with Ada included. > > Rainer Dear Sir : Would there be any way that I could invite you into the community build farm at Blastwave.org for this purpose ? I think it would be great if we could get a GCC package built ( with ada ) that passes a set of QC/QA steps and then release it to the Solaris world. Clearly I'll need a bit of help with the ada portion. All I would need is a public key from you and then you could ssh in through the gateway and into the server farm on any architecture or OS level that you want. This is something that Blastwave does for community open source people for years and it works rather well. Dennis
Re: GCC 4.3.3 Released
> On Sun, 2009-02-01 at 12:15 +0100, Richard Guenther wrote: >> The GNU Compiler Collection version 4.3.3 has been released. >> >> GCC 4.3.3 is a bug-fix release containing fixes for regressions and >> serious bugs in GCC 4.3.2. This release is available from the >> FTP servers listed at: >> >> http://www.gnu.org/order/ftp.html >> >> Please do not contact me directly regarding questions or comments about >> this release. Instead, use the resources available from >> http://gcc.gnu.org. >> >> As always, a vast number of people contributed to this GCC release -- >> far >> too many to thank individually! > > Unpatched release results on various architectures running linux from > the compile farm: > > x86_64=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00081.html > i686 => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00126.html > powerpc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00125.html > mipsel=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00210.html > sparc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00168.html > armv5tel => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00281.html > alpha => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html > > I'll try sparc64, powerpc64 and ia64 when the machines are available. I can probably help you with the Sparc64 requirement. To be precise, do you need Sun UltraSparc or are you looking for the multicore SPARC64 processor which is a ( slightly ) different beast? Dennis Clarke http://www.blastwave.org/
Re: GCC 4.3.3 Released
>> > I'll try sparc64, powerpc64 and ia64 when the machines are available. >> >> I can probably help you with the Sparc64 requirement. To be precise, do >> you need Sun UltraSparc or are you looking for the multicore SPARC64 >> processor which is a ( slightly ) different beast? > > Thanks for your offer. > > I do have access to a sparc64, in fact it's the same machine that I used > for the sparc (32 bits) report in the farm, but it is down since since > morning and will probably be up again in the next few days. I am always a very careful with the 32-bit Sparc build because I often end up with a 32-bit gcc but the ABI says SPARC V8PLUS or some such. Thus I use a genuine old old Sparc to build GCC with. # uname -a SunOS fossil 5.8 Generic_117350-56 sun4m sparc SUNW,SPARCstation-20 # isalist -v sparcv8 sparcv8-fsmuld sparcv7 sparc # file /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc: ELF 32-bit MSB executable , dynamically linked, not stripped see the "SPARC Version 1" there? That is my assurance that this will work on everything from old Sparc to the latest Niagara procs. It won't be fast .. but it will work. # /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /export/nfs/build/gnu/GCC/gcc-4.3.3/configure --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix --enable-nls --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --enable-shared --enable-multilib --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-languages=c,c++,f95,objc,ada --enable-bootstrap Thread model: posix gcc version 4.3.3 (GCC) Dennis
make install fails to create gcc ?
This is a strange result, I seem to have everything I wanted, fortran and ada etc but no actual gcc file. If I look at the final output in the $DEST/bin ddir I see this, sorted by inodes numbers with blank lines added for clarity : # ls -lapin bin | sort -n | sed 's/^[ \t]*//' otal 92092 117274 drwxr-xr-x 8 01512 Feb 6 20:05 ../ 320544 drwxr-xr-x 2 01512 Feb 6 20:15 ./ 320545 -rwxr-xr-x 1 014180292 Feb 6 19:56 gnatbind 320546 -rwxr-xr-x 1 01 68796 Feb 6 19:56 gnatbl 320547 -rwxr-xr-x 1 012541072 Feb 6 19:57 gnatchop 320548 -rwxr-xr-x 1 015640680 Feb 6 19:57 gnat 320549 -rwxr-xr-x 1 01 658096 Feb 6 19:57 gnatkr 320550 -rwxr-xr-x 1 011861876 Feb 6 19:57 gnatlink 320551 -rwxr-xr-x 1 012227308 Feb 6 19:57 gnatls 320552 -rwxr-xr-x 1 017927520 Feb 6 19:58 gnatmake 320553 -rwxr-xr-x 1 014314000 Feb 6 19:58 gnatname 320554 -rwxr-xr-x 1 012946072 Feb 6 19:58 gnatprep 320555 -rwxr-xr-x 1 012401060 Feb 6 19:58 gnatxref 320556 -rwxr-xr-x 1 012403280 Feb 6 19:58 gnatfind 320557 -rwxr-xr-x 1 015429992 Feb 6 19:59 gnatclean 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 c++ 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 g++ 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 sparc-sun-solaris2.8-c++ 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 sparc-sun-solaris2.8-g++ 320559 -rwxr-xr-x 2 01 589612 Feb 6 20:05 gfortran 320559 -rwxr-xr-x 2 01 589612 Feb 6 20:05 sparc-sun-solaris2.8-gfortran 320560 -rwxr-xr-x 1 01 188324 Feb 6 20:15 gcov 320561 -rwxr-xr-x 1 01 16191 Feb 6 20:15 gccbug 320562 -rwxr-xr-x 1 01 583720 Feb 6 20:15 cpp The thing that is missing entirely is gcc and then sparc-sun-solaris2.8-gcc and sparc-sun-solaris2.8-gcc-4.3.3 which are all hardlinks on the same inode number. In the build directory I do have an xgcc and it looks to be fine : $ gcc/xgcc --version xgcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ls -lap gcc/xgcc -rwxr-xr-x 1 dclarke csw 580900 Feb 6 05:08 gcc/xgcc Now then ... I kept a detailed log of the entired build/bootstrap process as well as the insatll process. I did see this in the logs : /export/nfs/build/gnu/GCC/gcc-4.3.3/install-sh: gprmake does not exist. gmake[2]: [ada.install-common] Error 1 (ignored) I also saw : /export/nfs/build/gnu/GCC/gcc-4.3.3/install-sh: gnatdll does not exist. gmake[2]: [ada.install-common] Error 1 (ignored) not too sure what the implications of that are. In any case . .the gcc binary is missing in action .. did make install fail in some weird way ? Dennis
fixincludes "fixes" Xlibint.h in an unknown way.
This is just a question. Hopefully someone can shed some light on what the fixincludes stage of "make install" does. I am making the assumption that the "make install" stage is where these headers get mangled or modified. This is on Solaris 8 by the way. Once make install has finished its job I see symlinks down deep in strange places thus : $ ls -lap $DEST/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/ | grep "^lrwx" lrwxrwxrwx 1 dclarke csw 28 Feb 7 17:19 X11 -> root/usr/openwin/include/X11/ lrwxrwxrwx 1 dclarke csw 22 Feb 7 17:19 Xm -> root/usr/dt/include/Xm/ lrwxrwxrwx 1 dclarke csw 29 Feb 7 17:19 kcms -> root/usr/openwin/include/kcms/ lrwxrwxrwx 1 dclarke csw 28 Feb 7 17:19 xil -> root/usr/openwin/include/xil/ These guys point to a dir entry called "root" which seems odd also but there it is. Way down deep in there I see this ( for example ) : $ ls -lap $DEST/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/root/usr/openwin/include/X11/ total 166 drwxr-xr-x 3 dclarke csw 512 Feb 7 09:37 ./ drwxr-xr-x 5 dclarke csw 512 Feb 7 09:37 ../ drwxr-xr-x 2 dclarke csw 512 Feb 7 09:37 DPS/ -rw-r--r-- 1 dclarke csw 4087 Feb 7 09:37 Xfuncs.h -rw-r--r-- 1 dclarke csw39002 Feb 7 09:37 Xlibint.h -rw-r--r-- 1 dclarke csw 6025 Feb 7 09:37 Xos.h -rw-r--r-- 1 dclarke csw 2980 Feb 7 09:37 Xosdefs.h -rw-r--r-- 1 dclarke csw10184 Feb 7 09:37 Xthreads.h -rw-r--r-- 1 dclarke csw 8847 Feb 7 09:37 dni.h -rw-r--r-- 1 dclarke csw 8366 Feb 7 09:37 nmdefs.h That all looks to be copies of *standard* headers found in the OS vendors /usr/openwin/share/include/X11 area. What changed ? $ diff /usr/openwin/share/include/X11/Xlibint.h $DEST/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/root/usr/openwin/include/X11/Xlibint.h 0a1,9 > /* DO NOT EDIT THIS FILE. > > It has been auto-edited by fixincludes from: > > "/usr/include/X11/Xlibint.h" > > This had to be done to correct non-standard usages in the > original, manufacturer supplied header file. */ > 882c891 < #ifdef sun /* added by SUNSOFT */ --- > #ifdef __sun__ /* added by SUNSOFT */ So the entire change is a comment and one line which both say "added by SUNSOFT" in them. Xfuncs.h is somewhat more interesting : < #if (__STDC__ && !defined(X_NOT_STDC_ENV) && !defined(sun) && !defined(macII) && !defined(apollo)) || defined(SVR4) || defined(hpux) || defined(_IBMR2) || defined(_SEQUENT_) --- > #if (__STDC__ && !defined(X_NOT_STDC_ENV) && !defined(__sun__) && !defined(macII) && !defined(apollo)) || defined(SVR4) || defined(hpux) || defined(_IBMR2) || defined(_SEQUENT_) 88c97 < #if !defined(X_NOT_STDC_ENV) && (!defined(sun) || defined(SVR4)) --- > #if !defined(X_NOT_STDC_ENV) && (!defined(__sun__) || defined(SVR4)) 96c105 < #if defined(SYSV) || defined(luna) || defined(sun) || defined(__sxg__) --- > #if defined(SYSV) || defined(luna) || defined(__sun__) || defined(__sxg__) $ It looks like anywhere you find the string "defined(sun)" you change it to "defined(__sun__)". That is an observation. But what did this ? Was it fixincludes or was it the mkheaders script ? and why ? -- Dennis Clarke
Re: fixincludes "fixes" Xlibint.h in an unknown way.
>> Was it fixincludes or was it the mkheaders script ? >> >> and why ? > > Because system headers should not define something in the users namespace, > certainly not a non-uglified three-letter name such as "sun". > > Consider > > #include > > int sun; > > which will not build otherwise. I did find this .. and I see it in the 4.0.2 GCC tree also that I have here : $ cat /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/README This README file is copied into the directory for GCC-only header files when fixincludes is run by the makefile for GCC. Many of the files in this directory were automatically edited from the standard system header files by the fixincludes process. They are system-specific, and will not work on any other kind of system. They are also not part of GCC. The reason we have to do this is because GCC requires ANSI C headers and many vendors supply ANSI-incompatible headers. Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient". simply put .. it all looks good. I simply need to figure out how to release things to users or do I force a fixincludes/make headers script event during install or what. How does Debian and Ubuntu handle this ? When a user installs a pre-compiled ready to run GCC package do they get the headers "fixed" on the fly or do they get delivered ... -- Dennis Clarke
Re: make install fails to create gcc ?
>> In any case . .the gcc binary is missing in action .. did make install >> fail in some weird way ? > > Possibly, but make should have failed also. > I re-ran the whole bootstrap process and this time was rewarded with everything I wanted. I don't know what the issue was earlier. Oh well. Dennis
Re: GCC Compile Farm News: 12 architectures now available
> Hi, > > Thanks to many donors of both hosting and machines the architecture > coverage of the GCC Compile Farm has been greatly expanded > in the recent monthes: > > http://gcc.gnu.org/wiki/CompileFarm I think this is excellent. Will you be installing baseline Solaris machines that ensure testing is done for the vast number of Solaris comercial users out there? When I say "commercial" I mean the older legacy Solaris 8 releases. We currently cover this at Blastwave.org all the way back to the very old Sun Sparc sun4m architecture and in this way we know that anything we compile will run across the whole Solaris suite from Solaris 8 upwards on anything with a Sparc chip. The x86 world is somewhat more messy and in this regard we use a Pentium III based machine with Solaris 8. I note that you have Solaris 10 there in your farm but only for Sparc and no representation for Solaris on x86 or OpenSolaris for that matter. Therefore your test farm will not verify functionality on anything older than Solaris 10 and only on Sparc. That should be "good enough" but not exactly what I would call commercial grade testing. Is this because only Sparc Solaris is on your Primary Platform List? Dennis Clarke dcla...@blastwave.org Director Blastwave.org 905 - 373 - 9441 Open Source Services for Solaris http://www.blastwave.org - Further Info at http://en.wikipedia.org/wiki/Blastwave
"Host/Target specific installation notes for GCC": broken link
Hi! The page on "Host/Target specific installation notes for GCC" (http://gcc.gnu.org/install/specific.html) has a broken link. In the table of contents it links to "http://gcc.gnu.org/install/specific.html#x-x-mingw";, while "http://gcc.gnu.org/install/specific.html#x-x-mingw32"; would be correct. Regards, Dennis Schridde signature.asc Description: This is a digitally signed message part.
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> A successful build on Open Solaris 2008.11: > > $../gcc-4.4.0/config.guess > i386-pc-solaris2.11 > > $ gcc-4.4.0t -v > Using built-in specs. > Target: i386-pc-solaris2.11 > Configured with: ../gcc-4.4.0/configure > --enable-languages=c,c++,fortran --disable-multilib > --program-suffix=-4.4.0t --disable-nls --with-gnu-as > --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld > Thread model: posix > gcc version 4.4.0 (GCC) > > Note that the host/target is one number higher that that listed in the > installation notes, i.e., the one ther is "*solaris2.10" while this > host/target is "*solaris2.11" > > I had problems later building ppl and cloog to incorporate into g++. > I have asked about this on the gcc-help mailing list. well done, do you have a full testsuite report ? Dennis
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> On Sat, Apr 25, 2009 at 9:09 PM, Dennis Clarke > wrote: >> >>> A successful build on Open Solaris 2008.11: >>> >>> $../gcc-4.4.0/config.guess >>> i386-pc-solaris2.11 >>> >>> $ gcc-4.4.0t -v >>> Using built-in specs. >>> Target: i386-pc-solaris2.11 >>> Configured with: ../gcc-4.4.0/configure >>> --enable-languages=c,c++,fortran --disable-multilib >>> --program-suffix=-4.4.0t --disable-nls --with-gnu-as >>> --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld >>> Thread model: posix >>> gcc version 4.4.0 (GCC) >>> >>> Note that the host/target is one number higher that that listed in the >>> installation notes, i.e., the one ther is "*solaris2.10" while this >>> host/target is "*solaris2.11" >>> >>> I had problems later building ppl and cloog to incorporate into g++. >>> I have asked about this on the gcc-help mailing list. >> >> well done, do you have a full testsuite report ? > > Thanks, Dennis, I feel lucky! > > No, but I'll fire one off now before I go to bed. It'll probably take > all night since it's a virtual host running on Linux Centos 5.3 x86_64 > (Intel Core 2 duo 1.86 GHz). ha ! I can relate to that! I have builds that run all night and day and then you get a result set where you look at it and wonder .. gee, what went wrong and you have to go do it all over again. I admire people that have the patience to see this through to the end *and* focus on quality. -- Dennis Clarke
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> On Sat, Apr 25, 2009 at 9:55 PM, Dennis Clarke > wrote: > ... >>>> well done, do you have a full testsuite report ? > > Well, Dennis, I have problems running the testsuite. I think I'm > missing some of the prereqs, so it will be a while. I'll report back > unless someone finishes first.. I am in progress but being very careful with each step. This may take a while. -- Dennis Clarke
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> Attached is a shortened test report with the following lines removed: > excellent, now we have a benchmark/comparison to look at. Well done, excellent work. What did you use to build libgmp and mpfr ? I am curious because most people that try wwith Sun Studio Express or Sun Studio 12 fail pretty badly unless you use the stlport4 libs. How did you did it ? Inquiring minds want to know! :-) Dennis
Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
Re: http://gcc.gnu.org/gcc-4.3/buildstat.html I was looking for testsuite results to compare with on Solaris and I saw that nearly every report for GCC 4.3.3 was done by Tom G. Christensen. All GCC 4.3.3 reports on Solaris from one person : i386-pc-solaris2.6 Test results: 4.3.3 i386-pc-solaris2.8 Test results: 4.3.3 i386-pc-solaris2.9 Test results: 4.3.3 i386-pc-solaris2.10 Test results: 4.3.3 sparc-sun-solaris2.6Test results: 4.3.3 sparc-sun-solaris2.7Test results: 4.3.3 sparc-sun-solaris2.8Test results: 4.3.3 I think it is great we have any report at all but for the sake of diversity and some comparison data I'll add mine in there : Results for 4.3.3 (GCC) testsuite on sparc-sun-solaris2.8 http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html I'll get the i386 reports later this week. -- Dennis Clarke http://www.blastwave.org/
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
> Dennis Clarke wrote: >> Re: http://gcc.gnu.org/gcc-4.3/buildstat.html >> >> I was looking for testsuite results to compare with on Solaris and I saw >> that nearly every report for GCC 4.3.3 was done by Tom G. Christensen. >> >> All GCC 4.3.3 reports on Solaris from one person : >> > > You better get cracking on 4.4.0 aswell since I posted most of those > reports too ;) no rest for the weary .. you have been very busy indeed. How did you do with the new PPL bits ? That went smoothly ? >> I think it is great we have any report at all but for the sake of >> diversity and some comparison data I'll add mine in there : >> > More testresults are always welcome. I think a few datapoints are always better than one. Tough to plot a trend or do comparison with one datapoint. >> Results for 4.3.3 (GCC) testsuite on sparc-sun-solaris2.8 >> http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html >> > Thank you. > >> I'll get the i386 reports later this week. >> > Sounds good. > > The testresults will be added with the next round of updates which I > plan to do early next week. > cool :-) Dennis
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
> Dennis Clarke wrote: > > How did you do with the new PPL bits ? That went smoothly ? >> > They're not mandatory for 4.4.x so I've simply ignored them for now. ah .. how very tricky of you :-) Dennis
Re: GCC 4.4.4 Released
> The GNU Compiler Collection version 4.4.4 has been released. Please provide MD5/SHA1/SHA256 hash sums for the release files in your release announcement. Those would be the reference standard for people to check as opposed to mirror sites which may be all over the world and sysadmins from who knows where. Just a suggestion. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.4.4 Released
> On Sun, May 02, 2010 at 01:41:10PM -0400, Dennis Clarke wrote: >> >> > The GNU Compiler Collection version 4.4.4 has been released. >> >> Please provide MD5/SHA1/SHA256 hash sums for the release files in your >> release announcement. Those would be the reference standard for people >> to >> check as opposed to mirror sites which may be all over the world and >> sysadmins from who knows where. >> >> Just a suggestion. > > You can download md5.sum files directly from gcc.gnu.org: > ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.4.4/md5.sum > ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.4.4/diffs/md5.sum > or, if you download from ftp.gnu.org or its mirrors, you can check > the tarballs and diffs using gpg. > Yes, of course. I agree. However, merely a gentle suggestion that those be in the cleartext of the announcement message as well as perhaps your message can be GPG signed. This is, afterall, the GNU C compiler which is the single most important bit of open source in the world in my ( not so humble ) opinion. All others ( like entire operating systems ) are built with it right? If you see my meaning. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: [RFC] Quad-float support for gfortran
2010/5/24 FX :
> Dear gfortranners,
>
> For some work-related issue, I find the need to switch my code regularly
> between double precision real arithmetics and quad-float. I currently do that
> with a proprietary compiler whose brand name matches the regexp
> "^In{1,}[t]\x65l$", but I'd be even more happy to do that with gfortran (my
> usual compiler) and that gives me an excuse to get to do something I've long
> wanted to achieve for fun: quad-float integration in gfortran.
Nice!
I have occasionally missed it as well, and had to resort to things like XBLAS.
> [...] There is one more issue, which is how to best integrate this? [...]
I think it would be a boon to gfortran if this also supported
cross-compiling to targets which support mpfr, or at least does not
pursue an approach that makes this more difficult that it has to be.
Thus, option 2 has my vote, because people out there have built mpfr
for all kinds of targets where gcc runs natively, so the results of
their efforts can easily be re-used. Actually I like option 3, but
only as long as it does not collect bit-rot: I would always prefer
building mpfr myself over debugging the GCC build system.
Thinking about this some more, option 3 might actually make more
sense, because then the regular bootstrap is enough to produce a
quad-capable cross-gfortran, where otherwise you would have to
bootstrap, build target-mpfr and then edit the specs file accordingly
(assuming you don't have the crosstools lying around to build
target-mpfr before bootstrap). Yuck!
Cheers,
Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> > A release canidate for GCC 4.5.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.1-RC-20100722/ > > and shortly its mirrors. It has been generated from SVN revision 162408. > > I have sofar bootstrapped and tested the release candidate on > x86_64-unknown-linux-gnu. Please test it and report any issues to > bugzilla. > > The branch remains frozen and all checkins until after the final > release of GCC 4.5.1 require explicit RM approval. > > If all goes well, I'd like to release 4.5.1 before Aug 1st. > FYI , bug 44455 is a show stopper in the Solaris world. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455 -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> Dennis Clarke writes:
>
>> FYI , bug 44455 is a show stopper in the Solaris world.
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
>
> This is
>
> bootstrap/44455 GCC fails to build if MPFR 3.0.0 (Release Candidate) is
used
>
> Why would this be a showstopper? Who forces you to build and install
mpfr 3.0.0? OpenSolaris comes with 2.4.1, and older versions don't
OpenSolaris is not a production release run by anyone anywhere :-)
> have mpfr bundled at all, so just use a version that works with GCC,
building it in-tree if you must.
OKay .. I guess details are needed.
If I place the latest mpfr and gmp and mpc and ppl and cloog in tree then
the build fails in stage one very early with bizarre warning about not
being able to find gmp rev greater than 4.3.1 despite the face that I have
already built and tested :
GMP: include 4.3.2, lib 4.3.2
MPFR: include 3.0.0-p3, lib 3.0.0-p3
MPC: include 0.8.2, lib 0.8.2
Those would all be installed in /usr/local with no surprises.
Regardless .. the build fails with the same message as bugid 44455.
Of course I try with gmp-5.0.1 first and that also fails so long as ppl is
around in the tree.
So I throw away ppl and cloog ( which I have *never* seen build on Solaris
10 anyways ) and then the build fails a little later with :
make[3]: Leaving directory
`/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/gcc'
mkdir i386-pc-solaris2.10/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in i386-pc-solaris2.10/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722/install-sh -c
checking for gawk... nawk
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for i386-pc-solaris2.10-ar... ar
checking for i386-pc-solaris2.10-lipo... lipo
checking for i386-pc-solaris2.10-nm...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/nm
checking for i386-pc-solaris2.10-ranlib... ranlib
checking for i386-pc-solaris2.10-strip... strip
checking whether ln -s works... yes
checking for i386-pc-solaris2.10-gcc...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-include
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-includeaccepts -g... yes
checking for
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-includeoption to accept ISO
C89... none needed
checking how to run the C preprocessor...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-include-E
checking whether decimal floating point is supported... no
checking whether fixed-point is supported... no
checking for __attribute__((visibility("hidden")))... no
checking whether the target assembler supports thread-local storage... yes
checking whether the thread-local storage support is from emutls... no
configure: updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: executing default commands
Adding multilib support to Makefile in
../../../gcc-4.5.1-RC-20100722/libgcc
multidirs=amd64
with_multisubdir=
Running configure in multilib subdirs amd64
pwd:
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/i386-pc-solaris2.10/libgcc
Running configure in multilib subdir amd64
pwd:
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/i386-pc-solaris2.10
mkdir amd64
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722/install-sh -c
checking for gawk... nawk
checking build system type... i386-pc-solaris2.10
checking host system type... i3
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>> If I go back and rebuild gmp mpfr and mpc thus : >> >> >> GMP: include 5.0.1, lib 5.0.1 >> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >> MPC: include 0.8.2, lib 0.8.2 > > Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do > not build these libraries in-tree. I built and tested them separate. -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>>>> GMP: include 5.0.1, lib 5.0.1 >>>> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >>>> MPC: include 0.8.2, lib 0.8.2 >>> >>> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do >>> not build these libraries in-tree. >> >> I built and tested them separate. > > You forgot to set LD_LIBRARY_PATH. > > That is considered evil on Solaris. http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the http://blogs.sun.com/rie/entry/tt_ld_library_path_tt I did set LD_RUN_PATH and LD_OPTIONS however. -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> On Jul 23, 2010, at 9:58 AM, Dennis Clarke > wrote: >>>>>> GMP: include 5.0.1, lib 5.0.1 >>>>>> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >>>>>> MPC: include 0.8.2, lib 0.8.2 >>>>> >>>>> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or >>>>> do >>>>> not build these libraries in-tree. >>>> >>>> I built and tested them separate. >>> >>> You forgot to set LD_LIBRARY_PATH. >>> >>> >> >> That is considered evil on Solaris. >> >> http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the >> >> http://blogs.sun.com/rie/entry/tt_ld_library_path_tt >> >> I did set LD_RUN_PATH and LD_OPTIONS however. > > -R and run path has bigger issues than ld library path. But then you > should look into config.log and see why it fails. I bet a beer it is > not finding the shared libraries. Now this is serious ! Would you bet a case of beer ? gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../gcc-4.4.4/configure --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu-32=i386 --with-cpu-64=opteron --with-arch-32=i386 --with-arch-64=opteron --enable-stage1-languages=c --enable-nls --with-libiconv-prefix=/usr/local --enable-threads=posix --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --prefix=/usr/local/gcc4 --with-local-prefix=/usr/local --enable-shared --enable-multilib --with-system-zlib --with-pkgversion='Blastwave.org Inc. Fri Jul 23 15:32:37 GMT 2010' --with-bugurl=http://www.blastwave.org/support --enable-languages=c,c++,objc,fortran --enable-bootstrap Thread model: posix gcc version 4.4.4 (Blastwave.org Inc. Fri Jul 23 15:32:37 GMT 2010) $ I'll run the testsuite , post the results and then make install. Then I'll rebuild binutils and try gcc 4.5.1 release candidate again with the exact same environment settings. By the way .. I did not use LD_LIBRARY_PATH at all. I was thinking Grolsch. I love that stuff and the bottles are cool. -- Dennis
embedded dataflow tracking code?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I'm sorry if I chose wrong place for my question. I would like to load debugger, attach to working process, and at some breakpoint, instead of numerical values in the CPU registers, I would like to see genesis of each value like "result of f(arg1, arg2,arg3) called at point X" or "result of comparison of values X and Y" and so on. Probably, compiler backend could embed some dataflow tracking code between basic blocks and store information about all variables flow in some separate data segment.. Are there any known attempts or projects or...? - -- My PGP public key: http://yurichev.com/dennis.yurichev.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxJ1G4ACgkQ1YPmFmJG++PtSwCeLYhvtOXTYNG51bIAksYdb2Ny 9vAAoL5RIcEdcPYZkXzLPNtf+sOa7SJT =IO9j -END PGP SIGNATURE-
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> Richard Guenther wrote: > >> On Fri, 23 Jul 2010, Dennis Clarke wrote: > >>> GMP: include 4.3.2, lib 4.3.2 >>> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >>> MPC: include 0.8.2, lib 0.8.2 > > fails, > > Richard recommends: > >> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do >> not build these libraries in-tree. > > Recently, I was thrown back to Debian Lenny, out of a mistake of my own > regard 1) (which dates back to 14 February 2009, so over 1.5 years ago). > > What I did was downloading: > > gmp-4.3.2.tar.bz2 > mpfr-2.4.2.tar.bz2 > mpc-0.8.2.tar.gz > > unpack them into their own directories and adding: > > lrwxrwxrwx 1 toon toon 15 2010-07-14 15:19 gmp -> ../../gmp-4.3.2 > lrwxrwxrwx 1 toon toon 15 2010-07-14 14:51 mpc -> ../../mpc-0.8.2 > lrwxrwxrwx 1 toon toon 16 2010-07-14 15:24 mpfr -> ../../mpfr-2.4.2 > > as those source directories were two levels up from my 'gcc' source > directory. > > That worked (I never got it working with mpfr 3.0.0 and gmp 5.0.x) > [ You can't imagine the pain working with a 1.5 year old OS ] > Have you seen Solaris 8 ? [titan]uname -a SunOS titan 5.8 Generic_127722-03 i86pc i386 i86pc [titan]cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 [titan] [titan]psrinfo -v Status of virtual processor 0 as of: 07/23/10 17:46:33 on-line since 06/15/10 20:44:18. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 07/23/10 17:46:33 on-line since 06/15/10 20:44:22. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. [titan] -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do >> not build these libraries in-tree. > > Yes, and verify that GMP and MPFR are correctly compiled with > "make check". Recent versions are miscompiled on SPARC/Solaris > by GCC 4.3.x for x < 3 or 4. > > The recommended versions (GMP 4.3.2, MPFR 2.4.2, MPC 0.8.1) also > work fine if compiled by the latest GCC 4.3.x compilers (or > compilers of later series). === gcc Summary === # of expected passes57009 # of unexpected failures67 # of unexpected successes 7 # of expected failures 197 # of unsupported tests 518 === g++ Summary === # of expected passes20118 # of unexpected failures29 # of unexpected successes 4 # of expected failures 158 # of unsupported tests 136 Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>> === gcc Summary === >> >> # of expected passes57009 >> # of unexpected failures67 >> # of unexpected successes 7 >> # of expected failures 197 >> # of unsupported tests 518 >> >> === g++ Summary === >> >> # of expected passes20118 >> # of unexpected failures29 >> # of unexpected successes 4 >> # of expected failures 158 >> # of unsupported tests 136 > > I meant "make check" for GMP and MPFR, not for GCC. > did that too :-) -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> Dennis Clarke writes: > >> FYI , bug 44455 is a show stopper in the Solaris world. >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455 > > This is > > bootstrap/44455 GCC fails to build if MPFR 3.0.0 (Release Candidate) is > used > > Why would this be a showstopper? Who forces you to build and install > mpfr 3.0.0? OpenSolaris comes with 2.4.1, and older versions don't > have mpfr bundled at all, so just use a version that works with GCC, > building it in-tree if you must. > Sorted things out and all is well now : http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg02266.html Thanks all for the lectures/pointers/edification :-) -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: Parma Polyhedra Library 0.11
>> Roberto Bagnara Patricia M. Hill Enea Zaffanella >> >> Applied Formal Methods Laboratory >> Department of Mathematics >> University of Parma, Italy >> > > cool.. just downloaded it.. just curious if I need to install ppl and > cloog on the system then build gcc? right now with the latest snapshot > of gcc, mpfr gmp are in the source tree and build fine but as soon as I > add cloog ppl and mpc I crapp out at ppl telling me it cant find gmp > > keep in mind this is my first attempt to build gcc with all these > packages in the source tree of gcc rather than building them separately. > On a number of occasions I have tried to build ppl and Cloog and watched the process fail repeatedly. I have yet to see it complete with any degree of success. Perhaps this is due to some strange issue with gmp and mpfr header versions and a false error message about libgmp versions is generally seen early in the build process. If this fault in the ppl/cloog code has been fixed then I'll be quite glad to see it. If not then I shall continue to work with GCC without either ppl or cloog as their absence seems to not matter a bit. This is entirely based on my experiences within the Solaris world where we still have issues with the GNU Binutils ld linker also. -- Dennis
Re: GCC 4.5.1 Released
> > The GNU Compiler Collection version 4.5.1 has been released. > > GCC 4.5.1 is a bug-fix release containing fixes for regressions and > serious bugs in GCC 4.5.0. This release is available from the > FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments about > this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release -- far > too many to thank individually! Based on what I have seen thus far ( I know time will tell ) it seems to be one of the very best releases in years. Works well in the Solaris world also and even on i386-pc-solaris2.8 and that is saying something. :-) -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Regarding the GCC Binaries and Build status pages
Dear GCC Team : This is just a friendly letter. There probably will not be another GCC update from the Sunfreeware site ( which is still showing 3.4.6 ) for a long time now that Oracle has pulled finances. The same sad state of affairs affects the OpenSolaris project as a whole. I do expect that the Blastwave site will release formal 4.5.1 packages to the world sometime in the next week and there should be at least some mention on this page given that we have released packages for GCC ver 4.x ( 4.0.1 and 4.3.4 etc ) for four years now : http://gcc.gnu.org/install/binaries.html Also, we have some excellent GCC 4.5.1 test results on Solaris 8 Sparc as well as i386 ( 32-bit ) thus : http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01024.html http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01023.html We have a team of people that perform GCC builds and tests on the Solaris production releases and we are happy to release these packages in SVR4 spec format to the Solaris user world. It would be nice if there were some mention on the "Binaries" page that we have been doing this service. Any reference to the test suite results is always nice also. We have been building 4.5.1 since the pre-release and it just seems to be an excellent compiler. In fact, we are moving our entire build process internally over to GCC 4.5.1 and saying goodbye to Sun Studio now that Oracle has stepped in and taken over Sun. Any questions or need for Solaris based test accounts, please feel free to ask. -- Dennis Clarke 2010 OpenSolaris Governance Board Member dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
> On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >> > This was built against ppl 0.10.2 and cloog 0.15.10. Have you tried a bootstrap with neither ppl nor cloog ? I have yet to see their value and I generally exclude them. This results ( thus far ) in nice clean bootstrap builds. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
