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.
> 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
> ...
> 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
This was caused by r215794 and seems fixed at r215833.
Dominique
See also https://gcc.gnu.org/ml/gcc-regression/2014-07/
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
pr61505
Dominique
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
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)
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.
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
> >> 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
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
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
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
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
> 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
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
Toon,
> Perhaps some kind soul with access to bugzilla can close this one.
Done,
Dominique
Hi,
I have provided a backtrace and a preprocessed file in
PR49344.
Dominique
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
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
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
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=
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
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,
> 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
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?
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
I wonder if this is not pr41043.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
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
-
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
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/
> 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
Jack,
This is pr37106. It first appeared with -m64 and is now also with
-m32.
Dominique
Mail sent by error to [EMAIL PROTECTED]:
I get the same error on i686-apple-darwin9 revision 139884.
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/
> 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
>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 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
> 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
> Is anyone else seeing the following build failure on i686 Darwin9?
Yes, on both ppc and i686 Darwin9.
Dominique
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
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
> 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
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
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
Jan,
The second patch worked (now building libgfortran).
Thanks
Dominique
> 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
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
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
See my comments in PR33009.
Dominique d'Humieres
This is PR373, see http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01134.html
for a fix.
Dominique
> 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
> 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
> 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
Some time ago I had a look at pr30388 and got the following results:
g77 -O2 g95 -O2 gfc -O2 gfc -m64 -O2
MFLOPS: 10631061 8581129
ref. g77-19% +6%
Since the evening is quite calm I decided to check if
At revision 130629 regtesting on Intel Darwin9 gives a dozen
The process has forked and you cannot use this CoreFoundation functionality
safely. You MUST exec().
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.
then stop to do
A full bootstrap took 12h 38' on my machine (1.8Ghz G5) minus probably ~1h
diverted for
other tasks. Although I did not measured accurately this time before, it could
be my
fastest one. Most of the improvement from my original post comes from
gnu/javax/swing/text/html/parser/HTML_401F.deps, for
There is something I don't understand: why the problem shows only (mainly) in
jc1?
If a similar increase had happened in gfortran, I (and others) would have seen
it.
Dominique
David,
> ... I would give it a couple of hours before calling it broken.
You are right, a small "couple" of hours is need for the three stages: slightly
less than two hours on my machine (1.8Ghz G5). I never noticed that this part
was so long and I was too eager to do something else with the CPU.
On powerpc-apple-darwin8, I killed jc1 after it took over 37:29.81 at:
...
echo
../../../../gcc-4.3-work/libjava/classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F*.class>
gnu/javax/swing/text/html/parser/HTML_401F.list
/bin/sh ./libtool --tag=GCJ --mode=compile /opt/gcc/darwin_buildw/gcc/
In comment #7 of PR0, Richard Guenther asked the following question
I cannot answer:
> Btw, is it mandated by the fortran standard to pass a scalar as array
> reference?
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
TIA
Dominique
At revision 128228, the patch enables me to go from stage1 to stage3, but
bootstrap
still fails with:
libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
-B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
-B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
-fbootclasspath=../../../../gcc-4.3-w
This is now PR0 handled by Richard Guenther.
Dominique
I have done some investigation about the recent failure of
gfortran.dg/c_char_tests.f03. First the failure disappears
with -fno-inline or -fno-inline-functions:
[karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline c_char_driver_db.c
[karma] f90/bug% a.out
[karma] f90/bug% gfc c_char_tests_db.f
> The testcase was indeed previously not inlined at all. Shall we add
> -fno-strict-overflow to the testcase then?
This what I would do, but I am not qualified to make the call.
In addition my working setup is totally broken right now
(at stage1). Could you do the addition to the testcase
and ru
> Sadly, the testsuite regressions don't seems to be fixed. I will try to
> figure out tomorrow why the function is still being inlined.
The test case gfortran.dg/do_3.F90 pass with -fno-strict-overflow
(see http://gcc.gnu.org/ml/fortran/2007-09/msg00116.html).
I have posted at http://gcc.gnu.org
Since yesterday ~16h GMT boostraping is broken on Darwin8 at stage1:
...
/opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/
-B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/powerpc-apple-darwin8/include -isystem
Build succeeded with revision 128101.
Thanks.
Dominique
Same thing here on Darwin:
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedant
Following http://gcc.gnu.org/ml/gcc/2007-08/msg00544.html
I have updated to revision 128003 and tried 'make bootstrap',
then 'configure' + 'make bootstrap' without success (the same kind
of failure in libgcc). I the tried a fresh install: new directory,
configure, and make, and it worked. So now
After an update to revision 127998 (from 127986), make failed with:
make[3]: Nothing to be done for `all'.
true "AR_FLAGS=rc" "CC_FOR_BUILD=/opt/gcc/darwin_buildw/./prev-gcc/xgcc
-B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/" "CFLAGS=-g -O2" "CXXFLAGS=-g
-O2
Jack Howarth has reported vect failures at -m64 on darwin with gfortran:
http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html
I see the same kind of failures with gcc 4.3.0 revision 127178:
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times
vectorization not profitable 1
FA
> Btw, is this a compiler with checking enabled?
As fas as I can tell, yes.
> If so try comparing numbers with --enable-checking=release.
I am more interested to compare times rather than get the lowest possible
number.
The following update of the timings shows that the compile time is
wors
The test FAIL: gcc.dg/pragma-darwin.c fails with
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 15)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 16)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 17)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 18)
FAIL: gcc.dg/pragma-d
> Maybe you can identify the single most increase for ppc?
The ranking is:
compile
06/15 06/08%
channel 4.289 2.519 70
induct 36.87823.671 56
protein 20.09713.162 53
nf 5.412 3.629 49
fa
Exctracted from
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt:
date compile execute
070608 106.29 628.74
070615 117.43 629.73
070620 105.95 616.99
So these tests show a ~10% increase of the compilation time
from 070612 to 070618. I have forgotten to mention tha
> I did not see this change. What flags are you using?
gfortran -w -O3 -ffast-math -funroll-loops
Dominique
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time
of the polyhedron test suite increased by 35% compared to the
previous snapshot and by 41% compared to the Apr 13 one:
compile execute
06/15 06/
On OSX 10.3.9 compiling gcc4-4.3.0-20070525 failed with:
...
/bin/sh ./libtool --tag=GCJ --mode=compile
/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/gcj
-B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/
-B/sw/src/fink.build/gcc4-4.3.0-20070526/dar
> Thanks,
You're welcome!
This is PR32009.
Cheers
Dominique
> In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in
I used the files from trunk revision 124627 and the build went fine.
I'll try to find some time to fill a PR
Dominique
Comparing the log of successful and failed builds I have found
that the failed one contains -mdynamic-no-pic which does not
appear in the previous build. According Apple's doc this
should be used in "application", but it should not appear
when building libraries (at least it is my understanding).
1 - 100 of 130 matches
Mail list logo
