In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
> Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
> odcctools 590-20060413 using a modified Fink script (working
> with the previous snapshot) failed with:
> ...
Since the problem is still there in gcc4-4.
Thanks for the answers.
> Please remove your changes from your tree, re-pull the current
> mainline and try building again. See my posting test results posting
> in http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00708.html for
> details on how I got those results. You don't have to appl
> Let me know if that works for you.
After applying the Andrew Pinski's patch for pr29879, the build of snapshot
20061118 went without problem on OSX 10.3.9. So your patch fixes the
problem I have reported. Thanks a lot.
If I may abuse of the situation, I am using the following patches:
Index:
On OSX 1Â0.3 updating to gcc-4.3-20061209 failed with:
...
cc1: warnings being treated as errors
../../gcc-4.3-20061209/gcc/varasm.c: In function 'elf_record_gcc_switches':
../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: format '%llu' expects type
'long long unsigned int', but argument 3 has t
Building gcc4-4.3.0-20061223 on OSX 10.3 failed with:
...
gcc -g -fkeep-inline-functions -no-cpp-precomp
-DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common
-DHAVE_CONFIG_H -DGENERATOR_FILE -o
> This was seen on a few platforms. I think it's due to zdenek's patch.
It seems that 'integer_zerop' and 'integer_nonzerop' are defined in gcc/tree.c
and as far as I can tell the file is not compiled before the error. Any idea
why?
TIA
Dominique
Thanks to Steve Ellcey for having asked the question I did not care (dare)
to ask and to those who answered.
> So please use contrib/test_installed
This script seems quite outdated: it tests g77 and not gfortran, even with
the latest 4.3.0 snapshot (20070112). As I was primarily interested in
Gerald,
> > This script seems quite outdated: it tests g77 and not gfortran, even
> > with the latest 4.3.0 snapshot (20070112). ...
>
> Would you mind submitting this as a patch?
--- gcc-4.3-20070120/contrib/test_installed Fri Jul 11 08:05:01 2003
+++ gcc-4.3-20070119/contrib/test_installe
While building the gcc4-4.3.0-20070209 snapshot, I got the error
...
checking for correct version of gmp.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+.
...
I am using the same script that worked last week and I have
gmp 4.2.1 and mpfr 2.2.1 since several builds. I am us
Daniel,
Thanks for the answer.
> You need to show us your configure arguments to be sure. I bet
> you're specifying just --host.
You are right, the configure I am using since some time is:
ConfigureParams: --prefix=%p/lib/gcc4 --disable-multilib
--enable-languages=c,c++,fortran,objc,java
--in
I have written:
> Would something like
> --build=%m-apple-darwin`uname -r|cut -f1 -d.`
> work?
Apparently it works.
Thanks
Dominique
The discussion is becoming to technical for me.
Let me just say that adding --build=%m-apple-darwin`uname -r|cut -f1 -d.`
to config allowed me to build gcc without further glitch.
I guess it will do no harm to keep this addition even if it
becomes no longer necessary.
Thanks for the help
Dominiq
Following the discussions for PR30969, PR30980, and PR31161,
it appears that TARGET_C99_FUNCTIONS is not set on OSX 10.3.9
nor OSX 10.4.9. Is this in line with the comment
/* Old versions of Mac OS/Darwin don't have C99 functions available. */
in gcc/config/rs6000/darwin.h? and
#undef TARGET_C9
Mike,
Thanks for the answer, but I understand very little of it.
> The above can be read as:
>
> If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
> otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
> is true, otherwise, TARGET_C99_FUNCTIONS is false.
So far so g
Eric,
Thanks for the explanations.
> The idea, I believe, is that the default will be the system that you
> are currently on.
It would be nice, but it is not the way it seems to work (at least for gcc,
for g++ and gfortran it may, but I am not sure). For instance
I have a version of 4.3.0 on 10
> The new method will be that the default will be the system that you are
> currently on. It's not the default now.
How new is new? As far as I can tell, it did not work for the
20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and
friends which do not pass for the 20070316 snapshot, it is
> It's not yet checked in :)
So, I'll wait!-)
Dominique
Gerald,
Thanks (late) for the patch. I have some new questions:
(1) I get the following errors:
ERROR: can't read "HOSTCC": no such variable
while executing
"remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd""
invoked from within
"set status [remote_exec host "$HOSTCC $HOSTCFLAGS $gen
Building gcc4-4.3.0-20070331 fails on PPC Darwin7 with:
...
/sw/src/fink.build/gcc4-4.3.0-20070331/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20070331/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -I../../gcc-4.3-20070331/libcpp -I.
-I../../gcc-4.3-2007
> Re-update and build again, should work now I think.
Yes, the problem is now fixed, thanks.
Dominique
While regtesting my build of the 20070330 snapshot (Darwin7), I got a lot
(~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ...,
gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found
that this has started on 20070325 for Darwin8:
http://gcc.gnu.org/ml/gcc-te
> * powerpc-apple-darwin8.5.0: gfortran.dg/edit_real_1.f90
I don't see these failures on my weekly snapshot build on OSX 10.3.9
(nor in a month old build on OSX 10.4.8 or 9, cannot remember).
Could it be related to 10.4.5 gcc failures gcc.dg/torture/builtin-pow-mpfr-1.c
and gcc.dg/torture/builtin-
I managed to regtest libffi and got the following summary:
=== libffi tests ===
Running target unix
FAIL: libffi.call/cls_align_longdouble.c -O0 -W -Wall output pattern test, is
12 7.29112e-304 191 0 1.98612e-309 0: 12 7.29114e-304 191
FAIL: libffi.call/nested_struct5.c -O0 -W -
> Are you building with --enable-checking (the default)?
On AMD I am using the François-Xavier's builds. On my G5 I use a patched
version of the Fink's info file, the answer is probably in
ConfigureParams: --prefix=%p/lib/gcc4
--enable-languages=c,c++,fortran,objc,java --infodir='${prefix}/share
On an AMD, the 20060105 build gives
[scala] gfortran/2006> time irun/bin/gfortran -ftime-report -O3 -ffast-math
-funroll-loops induct.f90
Execution times (seconds)
garbage collection: 0.39 ( 2%) usr 0.01 ( 2%) sys 0.40 ( 2%) wall
0 kB ( 0%) ggc
callgraph construction: 0.09 (
> You can also try -fno-tree-salias and see if this helps compile time.
On my G5 I get:
[karma] lin/source% time gfortran -ftime-report -fno-tree-salias -O3
-ffast-math -funroll-loops induct.f90
Execution times (seconds)
garbage collection: 0.51 ( 2%) usr 0.05 ( 2%) sys 0.56 ( 2%) wa
> with the patch applied it improves a little bit ;)
I get for the list I have sent:
snapshot 12/24 12/31 01/07 01/14 +patch
ac5.8s 6.0s 24.7s 23.0s+ 37.9s
aermod 223.9s227.3s485.8s467.6s+ 229.6s
air
> > ac5.8s 6.0s 24.7s 23.0s+ 37.9s
>
> Hm, so that regresses even more. Weird. I'd like to have it to
> investigate.
Sorry this was a typo, the first two lines should be:
ac5.8s 6.0s 24.7s 23.0s+4.0s
aermod 223.9s227.3s
pr61505
Dominique
> I've been looking for a smoking gun, but did not find one. Interestingly
> this only happens in stage3 on i386-unknown-freebsd10.0 where clang is the
> bootstrap compiler: ...
Same thing here on x86_64-apple-darwin13 at r212373 configured with
$ ../p_work/configure --prefix=/opt/gcc/gcc4.10p
See also https://gcc.gnu.org/ml/gcc-regression/2014-07/
Dominique
This was caused by r215794 and seems fixed at r215833.
Dominique
> ...
> Can you please test it on Darwin (or whatever other target has similar
> issues with bootstrapping libcc1)?
>
> 2014-12-05 Jakub Jelinek
> ...
The patch does not work for x86_64-apple-darwin14.0.0. However the following
patch does:
--- ../_clean/Makefile.in 2014-11-26 23:09:14.0
> As I've tried to explain, that is IMHO wrong though.
> If what you are after is the -B stuff too, then perhaps:
> ...
Sorry but it does not work:
true DO=all multi-do # make
make[4]: Leaving directory '/opt/gcc/build_w/libbacktrace'
make[3]: Leaving directory '/opt/gcc/build_w/libbacktrace'
ma
Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
Would it be possible to apply the patch at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932
before 4.8.4 is released? Results with the patch are posted at
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02096.html.
Paolo,
While chasing bootstrap failures on Darwin, I did notice the following
(harmless) warnings:
ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from
.libs/complex_io.o
ld: warning: cannot export hidden symbol std::basic_stringbuf, std::alloc
Hi,
I have provided a backtrace and a preprocessed file in
PR49344.
Dominique
Toon,
> Perhaps some kind soul with access to bugzilla can close this one.
Done,
Dominique
Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
../../work/gcc/collect2.c: In function 'int main(int, char**)':
../../work/gcc/collect2.c:1094:7: error: unused variable 'object_nbr'
[-Werror=unused-variable]
cc1plus: all warnings being treated as errors
Note that I did not find any en
> Just to make sure nobody is midled by th subject of your message:
> your bootstrap problem obviously has nothing to do with the warning itself.
> The latter has been discussed already on these mailing lists, is absolutely
> bening.
I have open pr51094 for this bootstrap failure.
Note that it is
Hi Uros,
Is your patch dealing with gcc.dg/simulate-thread/atomic-other-* running
for ever without timeout? If yes, I have seen the same problem on
powerpc-apple-darwin9. Could you add powerpc*-apple-darwin* to your
patch?
TIA
Dominique
For the record, Jakub's comment on IRC:
> with older gdb you simply had to find the stwcx
> or whatever SC insn is, put a breakpoint after
> it and continue instead of single stepping
Dominique
While I fail to see how the "correct value" of
cos(4.47460300787e+182)+sin(4.47460300787e+182)
can be defined in the 'double' world, cos^2(x)+sin^2(x)=1 and
sin(2*x)=2*sin(x)*cos(x) seems to be verified (at least for this value)
even if the actual values of sin and cos depends on the optimisation
Since 4.4.1 is closed to be released, I have bootstrapped and regtested
4.4.1 in the 4_4 branch at revision 149690. It took ~2h30 to bootstrap
and ~5+h to regtest (single thread) on my macbook. The typical times
for trunk are between 3h30 and 4h for bootstrap and ~8h to regtest.
Is this known or a
IIRC another code that is "improved" by complete_unrolli is the polyhedron
test induct.f90. However it gives worse results for some variants
(see pr34265: induct_v2/3).
> Can't we use graphite to re-roll loops? ...
Is doing and undoing always some kind of work?
Cheers
Dominique
Diego,
> In fact, it'd be nice to hide some other flags, but that's another problem.
Absolutely, I think the user flags should be well separated from the
developer ones.
Cheers
Dominique
Kaveh,
mpc-0.7-dev passed the 45 tests on i686-apple-darwin9 when compiled
with gcc version 4.0.1 (Apple Inc. build 5493).
Cheers
Dominique
> Should we perhaps, again? I'm having trouble fixing one bootstrap-breaking
> bug because of a second one that's piled in on top of it right now; how is it
> for other targets?
Bad for darwin!-(bootstrap failing since at least r151822, see pr41405).
If you add pr41407+others, a slush should be
Iain,
I am currently bootstrapping on i686-apple-darwin9 with the current patch:
diff -uN /opt/gcc/_gcc_clean/config/mh-intel-darwin
/opt/gcc/gcc-4.5-work/config/mh-intel-darwin
--- /opt/gcc/_gcc_clean/config/mh-intel-darwin 1970-01-01 01:00:00.0
+0100
+++ /opt/gcc/gcc-4.5-work/config/
With the previous patch, bootstrap failed when building libgomp: -gstrict-dwarf
was
not passed during the configure stage. So it is not sufficient to pass it to
BOOT_CFLAGS. Would repeating the trick for CFLAGS_FOR_TARGET have a chance to
work?
Dominique
With revision 152076 on i686-apple-darwin9 bootstrapped as described
in comment#61 of pr41405, I get:
[ibook-dhum] bug/debug% gcc45 -c -save-temps -dA -g -O0 -fverbose-asm
-gno-strict-dwarf simplistic.c
[ibook-dhum] bug/debug% dwarfdump --debug-frame simplistic.o
-
I wonder if this is not pr41043.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
Dominique
In the block "Handle constant exponents." in gcc/builtins.c, the condition
!optimize_size has been replaced with optimize_insn_for_speed_p () between
gcc 4.3 and 4.4, but I have not been able to find when and why.
Does anybody remembers the when and why?
This change make the optimization sensitive
May I remind my original question:
> In the block "Handle constant exponents." in gcc/builtins.c, the condition
> !optimize_size has been replaced with optimize_insn_for_speed_p () between
> gcc 4.3 and 4.4, but I have not been able to find when and why.
> Does anybody remembers the when and why?
> Google is your friend...
Thanks Jack. As you can see in comment #46 of pr40106, I have found
my own way. In my previous attempts I have made two mistakes:
(1) I tried to use the search engine of the gcc mailing lists that
kept parsing optimize_insn_for_speed_p as if the _ were spaces.
(2) I did
With revision 156618, grepping the assembly of
gcc/testsuite/gcc.dg/matrix/transpose-1.c
for gcov_indirect, I get
movq___gcov_indirect_call_callee(%rip), %rcx
movq___gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
movq$0,
Hi!
I use to build gcc with a command line such as
make -j2 >& somelogfile &
I recently found that if I logout, the build fails with
perl: no user 501
Is this a bug or a feature? In the former case I'll open a PR.
In the later is it documented somewhere that you should not logout
while buildin
Jack,
This is pr37106. It first appeared with -m64 and is now also with
-m32.
Dominique
I have done a few tests at r142680 on i686-apple-darwin9 on the polyhedron
test suite and I have found a couple of wrong codes at -O3 -fgraphite-identity,
namely for capacita.f90 and fatigue.f90 (nothing to report so far for
channel.f90
and induct.f90). I have little time to explore the problems.
NightStrike wrote:
> What if GCC went back to stage 3 until the issue is resolved, thus
> opening the door for a number of stage3-type patches that don't affect
> 1) licensing and 2) plugin frameworks, but are merely bug fixes which
> would have long been shaken out by now.
It would be indeed nice
Sorry guys for a naive question, but I did not find any answer
in this thread.
Could someone at FSF, directly or through the SC, be kind enough to
explain in plain English for non-native speakers why it was so urgent
to disrupt the release process for a licence exception.
Indeed I am not expectin
On 23 Mar 2009, Ian Lance Taylor wrote:
> > Could someone at FSF, directly or through the SC, be kind enough to
> > explain in plain English for non-native speakers why it was so urgent
> > to disrupt the release process for a licence exception.
>
> I don't think any of us know. You would have t
Hi,
FX Coudert has sent me the following patch for fixincludes/inclhack.def:
--- ../_gcc_clean/fixincludes/inclhack.def 2009-03-31 22:37:57.0
+0200
+++ fixincludes/inclhack.def2009-04-06 19:50:43.0 +0200
@@ -1023,6 +1023,35 @@
/*
+ * Fix stdint.h header on Darwin.
Dave,
Thanks for the quick answer.
> I don't know what it's trying to tell you with the fixincludes FAIL. Did
> you verify manually if the fixes perhaps didn't match against the stdint.h you
> have on your release of the O/S?
AFAICT the patch looks fine, but I cannot rule out typos. I'll try
Dave,
I have looked more closely to the sed part and it is probably incorrect,
i.e. doing nothing. I'll coninue to experiment, but if you or someone else
have idea, I'll be glad to use it.
Thanks,
Dominique
Paolo,
> sed does not have +.
Thanks for the hint. Apparently GNU sed version 4.1.5 has it, provided you use
-r,
but I was wondering what to do since I did not see it in fixincl.x.
So I will use [ \t][ \t]*.
Dominique
Hi!
I have made some progress with your help. I have fixed the sed part:
(1) there were missing 's' in the scripts, first I did not noticed it,
then I did not know if I was supposed to povide it;
(2) I have replaced the [ \t]+ by [ \t][ \t]*
to get:
--- ../_gcc_clean/fixincludes/inclhack.def
In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
Arnaud Charlet wrote:
> Can someone please fix or disable these runs? They are getting very
> irritating.
What I find extremely irritating is that it takes so long to
fix bootstrap failures. Meanwhile I hope to see such mails
until the
Andrew Haley wrote
> Is this really a good idea? Surely the solution is to fix the
> failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failure
was Darwin specific and is now fixed, two others are powerpc ones.
When they will be fixed on trunk the annoying mails will
Note that revision 149171 not only breaks powerpc-apple-darwin9.7.0
but now also i686-pc-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00114.html).
Dominique
Hi,
I just noticed today that (implicit) loops of the kind
xmin = minval(nodes(1,inductor_number(1:number_of_nodes)))
(lines 5057 to 5062 of the polyhedron test induct.f90) are no longer
vectorized (the change occurred between revisions 158215 and
158921). With -ftree-vectorizer-verbose=
Ira,
Thanks for the answer.
> The loop that got vectorized in the older revision is another loop
> associated with the same source code line:
Upon further investigation this loops is likely related to a temporary that
have been removed in recent versions. Using the older revision with
-Warray-te
On x86_64-apple-darwin10.3.0 bootstrapping with --enable-build-with-cxx
fails at stage 2 with:
...
/opt/gcc/build_w/./prev-gcc/g++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/bin/ -nostdinc++
-I/opt/gcc/build_w/prev-x86_64-apple-darwin10.3.0/libstdc++-v3/include/x
Hi Bernhard,
Thanks for the "Not a patch!". I have started to play with it.
In order to get something working I had to add
rename standard_file ""
rename saved-standard_file standard_file
at the end of the proc remove-build-dir, otherwise I had only errors
ERROR: gcc.c-torture/compile/2
> >> We do have regular requests for this, so it is not just out of thin
> >> air.
> >
> > Perhaps, but I think that changing the default like this is far too
> > invasive. ?GCC should do what it's told, if a user asks for warnings,
> > give them, if they don't, then don't.
>
> It is hard to defi
Test on x86_64-apple-darwin10
GMP: include 5.0.4, lib 5.0.4
MPFR: include 3.1.1, lib 3.1.1
MPC: include 1.0.0rc1, lib 1.0.0rc1
C compiler: gcc
GCC: yes
GCC version: 4.8.0
PASS: tget_version
===
All 64 tests passed
===
Dominique
Hi Uros,
> Recent patch introduced 10% runtime regression on x86_64 targets in
> rnflow Polyhedron benchmark [1]. Did somebody alread bisected to the
> offending patch?
I see it since some time. It is on my TODO list to open a new PR.
You can suppress the slowdown with -fno-tree-loop-if-convert.
These questions are motivated by the comments #4 to #15 of pr54407.
The bottom line is that
{ dg-do compile targets1 }
{ dg-do run targets2 }
behaves as
{dg-do run { targets1 targets2 } }
while
{ dg-do run targets1 }
{ dg-do compile targets2 }
as
{ dg-do compile { targets1 targets2 } }
(1)
Thanks for the quick answer.
> That's just the way it works, so I suppose you could call it a feature.
So the answer to (1) is yes and to (2) it is a poorly documented feature.
May be the restriction to one dg-do directive should be added to
http://gcc.gnu.org/wiki/HowToPrepareATestcase .
In gcc
> Perhaps Darwin doesn't define _SC_NPROCESSORS_ONLN
It is defined on Darwin9:
[ibook-dhum] f90/bug% grep _SC_NPROCESSORS_ONLN /usr/include/*
/usr/include/unistd.h:#define _SC_NPROCESSORS_ONLN58
but apparently not for Darwin8.
Dominique
> The issue is trivial enough to fix, if people want to fix it.
> Essentially, the various builtins need to have different linkage names,
> not just _sin.
Those who kow how to fix it don't want to fix it, and those who want
to fix it don't how to fix it! Would it be possible to break this
vicious
> I would vote for -ffast-math to disable it.
Please don't. I think parentheses should be obeyed in FORTRAN.
-ffast-math groups several useful optimization for usual codes
and I don't see why users should have to remember their names
if they want to keep mandatory parentheses.
Now I also think on
This is PR373, see http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01134.html
for a fix.
Dominique
See my comments in PR33009.
Dominique d'Humieres
While rebuilding gcc I got the following failure:
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame-pointer
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definitio
At revision 134333, boostrap fails on i686-apple-darwin9 at stage 1
with:
...
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.4-wo
> Does this help?
Thanks for tha answer, but now I have:
...
../../gcc-4.4-work/gcc/except.c: In function 'set_nothrow_function_flags':
../../gcc-4.4-work/gcc/except.c:2787: error: 'struct rtl_data' has no member
named 'epilogue_delay_list'
make[3]: *** [except.o] Error 1
...
Dominique
Jan,
The second patch worked (now building libgfortran).
Thanks
Dominique
At revision 134523, bootstraping fails on i686-apple-darwin9 with:
...
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.4-work/gcc
Is the following syntax correct?
/* { dg-require-effective-target ilp32 && dfp } */
It appears in gcc/testsuite/gcc.target/i386/pr32000-2.c and
gcc/testsuite/gcc.target/i386/stackalign/return-3.c.
TIA
Dominique
> but nothing complains and it seems to work fine.
The tests gcc.target/i386/pr32000-2.c and return-3.c are run
(and fail) on i686-apple-darwin9 which does not support decimal
floating point. So I think the dg-require is not properly
enforced.
Dominique
Boostrap fails on i686-apple-darwin9 at revision 139725 with:
...
mkdir -p ./i686-apple-darwin9/bits/stdc++.h.gch
/opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc
-nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/i686-darwin/i686-apple-d
Paolo,
> I'm going to prepare and test on Darwin the trivial patch, if it fixes
> the bootstrap failure I will post and commit it as obvious.
Bootstrap completed at revision 139739. Thanks for the fix.
Dominique
> Is anyone else seeing the following build failure on i686 Darwin9?
Yes, on both ppc and i686 Darwin9.
Dominique
> should be somewhere between r139740 and r139791.
I have a slightly narrower range: r139753 worked with a clean bootstrap.
Then incremental updates worked for r139766, 768, and 786. r139791 failed
with a clean bootstrap up to 801 (incremental updates). Now the strange
thing is that I reverted
I have done a clean bootstrap for r139780 and it failed.
So the fork is between r139753 (working) and r139780 (broken).
I have also understood why I did not see the failures for the
incremental updates: they did not rebuild libstdc++-v3 where
the failure occurs.
Dominique
>From broken r139780, I did an incremental downgrade to r139770 (still
broken) then to r139760 which seems to work (building libjava).
So the window seems between r139760 and r139770.
Dominique
> I am seeing the same failure in r139763. I'll try r139761 next.
r139761 works, and I confirm that r139763 is broken.
I'll do r139762.
Dominique
r139762 seems broken. Could you fill a bug report: it's bed time for me
and our mail exchange did not seem to have attracted any attention.
Revision 139762
Jump to revision:
Author: hubicka
Date: Fri Aug 29 11:39:04 2008 UTC (35 hours, 39 minutes ago)
Log Message:
* doc/
Mail sent by error to [EMAIL PROTECTED]:
I get the same error on i686-apple-darwin9 revision 139884.
Dominique
1 - 100 of 130 matches
Mail list logo
