--- Comment #54 from steven at gcc dot gnu dot org 2010-07-17 22:55 ---
FIXED in r162047.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-14 22:10 ---
Collecting bits and pieces from all over, I'm trying to make a plan...
Consensus on IRC is that LTO data does not need its own Mach-O segment, and
that can it just fit as a section in the _TEXT (since LTO data is rea
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-04-15
13:48 ---
Can we just use the LTO COFF patch...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html
as a template? Hopefully we can just remove the unnecessary sections of the
patch and rename things as appropr
--- Comment #7 from stevenb dot gcc at gmail dot com 2010-04-15 14:03
---
Subject: Re: Mach-O LTO support needed for darwin
> Can we just use the LTO COFF patch...as a template?
That is certainly my plan, yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #8 from mrs at gcc dot gnu dot org 2010-04-26 14:49 ---
One open question for me would be, are 16 bytes of an arbitrary named
section/segment enough? It you carve out a slice, say lto_%d, that leaves just
12 bytes for the `name', if this big enough?
--
http://gcc.gnu.or
--- Comment #9 from stevenb dot gcc at gmail dot com 2010-04-26 16:06
---
Subject: Re: Mach-O LTO support needed for darwin
Mach-O section names are too short, but I have solved this with a
separate section with section names in a strings table. This is
similar to the solution from lt
--- Comment #10 from davek at gcc dot gnu dot org 2010-04-26 18:39 ---
(In reply to comment #1)
> I don't speak Mach-O, but yes, the approach should work. You'd start by
> saying lto_binary_reader=lto-mach-o in config.gcc and adding a new
> lto/lto-mach-o.c with the same handful of t
--- Comment #11 from davek at gcc dot gnu dot org 2010-04-27 02:35 ---
I noticed the dependency was the wrong way round when I saw that this open bug
was blocking a freshly-closed one :)
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2010-04-27 20:25 ---
Created an attachment (id=20500)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20500&action=view)
proof-of-concept patch
This doesn't even include a Mach-O writer yet (except for the to be rewritten
COFF write
--- Comment #13 from dominiq at lps dot ens dot fr 2010-04-28 12:20 ---
> proof-of-concept patch
Great!-) Thanks a lot.
Besides the 17 C failures, for all languages but ADA, I also see
FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link
and
FAIL: gcc.c-torture/ex
--- Comment #14 from dominiq at lps dot ens dot fr 2010-04-28 13:04 ---
Note also that the polyhedron test aermod.f90 fails with -flto or -whopr at any
level of optimization with:
ld: in /var/tmp//ccDGk6QZ.o, in section __TEXT,__text reloc 17: local
relocation for address 0x000E58F4 in
--- Comment #15 from steven at gcc dot gnu dot org 2010-04-28 19:50 ---
Re. comment #14, this is obviously related to LTO but we (gcc) don't do
anything with relocations. I'll try to reproduce this problem, but I suspect it
is an assembler or linker bug.
--
http://gcc.gnu.org/bugzil
--- Comment #16 from steven at gcc dot gnu dot org 2010-04-29 10:48 ---
Re. comment #14 this is now Apple radar 7920267. Let's see if someone on their
end can cq. is willing to help us out here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #17 from steven at gcc dot gnu dot org 2010-04-29 11:39 ---
I've played a bit with modified .s files by hand, and as/ld work if the LTO
sections follow the other sections.
The normal order of output with -flto looks like this in the .s file:
LTO sections (the __GNU_LTO stuf
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-04-29
13:20 ---
Does the executable created from the manually reordered aermod.s run correctly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-01 14:40 ---
Created an attachment (id=20526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20526&action=view)
proof-of-concept patch, with Mach-O writer implemented now
Remaining failures due to missing support for what's
--- Comment #20 from steven at gcc dot gnu dot org 2010-05-01 14:43 ---
On x86_64-unknown-linux-gnu, I see that gcc.dg/lto/20090126 also fails (see
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00031.html). So the test
suite results on x86_64-darwin are the same as on x86_64-linux mo
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-05-01 14:53
---
+ /* ??? Some targets need to handle LTO assembler output specially.
+ Is this the right place to hanlde that? */
+ if (flag_generate_lto)
yes.
+ if (flag_generate_lto)
+targetm.asm_out.lto_end ();
s
--- Comment #22 from dominiq at lps dot ens dot fr 2010-05-01 15:26 ---
Sorry to bother you, but with the patch in comment #19 bootstrap fails at stage
2 with the infamous "all warnings being treated as errors":
...
/opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/
-B/opt/
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-01 21:40 ---
After some surgery in gcc/lto/lto-macho.h and gcc/lto/lto-macho.c, I have
managed to bootstrap. Now the full polyhedron test pass without failure. The
timings with my default options, with -fwhole-file, and with -flt
--- Comment #24 from steven at gcc dot gnu dot org 2010-05-01 21:51 ---
Created an attachment (id=20527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20527&action=view)
final patch
I plan to submit this, but with 32 bits disabled because I get failures I don't
understand.
--
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-05-01
22:18 ---
Steven,
Do you mean the errors which have "symbol xxx can't be undefined in a
subtraction expression"? A google shows this to look like that discussed
here...
http://gcc.gnu.org/ml/gcc-bugs/2003-11/ms
--- Comment #26 from stevenb dot gcc at gmail dot com 2010-05-01 22:30
---
Subject: Re: Mach-O LTO support needed for darwin
> Do you mean the errors which have "symbol xxx can't be undefined in a
> subtraction expression"?
Yes, exactly those.
> A google shows this to look like t
--- Comment #27 from mrs at gcc dot gnu dot org 2010-05-01 23:22 ---
Ok for all the darwin bits with any necessary mods to turn off or fix the
32-bit port. If you attach the the 32-bit .s file, I can puzzle it out for
you. In short, only - of two defined symbols in the same section wor
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2010-05-01
23:59 ---
Created an attachment (id=20529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20529&action=view)
example 32-bit failing testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:01 ---
Mike,
I've attached one of the failing testcases with all of the files generated
by the commands...
/Users/stevenb/lto_objdir32/gcc/xgcc -B/Users/stevenb/lto_objdir32/gcc/
--save-temps -O0 -fwhopr -
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:07 ---
Created an attachment (id=20530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20530&action=view)
non-failing testcase for 64-bit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #31 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:09 ---
Mike,
I've also attached the same non-failing testcase from the x86_64 build
generated with the commands...
/Users/stevenb/lto_objdir/gcc/xgcc -B/Users/stevenb/lto_objdir/gcc/
--save-temps -O0 -fwhop
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-05-02
00:47 ---
The failing command out of the log from the 32-bit testcase is...
/Users/stevenb/lto_objdir32/gcc/lto1 -fPIC -quiet -dumpbase
gcc-dg-lto-2008-01.ltrans0 -dumpdir ./ -mmacosx-version-min=10.6.3
-mtune=
--- Comment #33 from mrs at gcc dot gnu dot org 2010-05-02 01:23 ---
So, mumble isn't defined in the wpa file. The .wpa. file has to be assembled
at the same time as 2008_1.s, or, different code would need to be
generated. darwin.c manages the code gen by asking the question, is th
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2010-05-02
13:11 ---
Mike,
Can you flesh out the implementation of the second option of putting all
of the symbols in the wpa? Would this only require changes to darwin specific
files or a change to the LTO mechanism itse
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2010-05-02
13:59 ---
Proposed patch for LTO support on Mach-O posted at
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00041.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #36 from howarth at nitro dot med dot uc dot edu 2010-05-02
19:15 ---
Testresults on x86_64-apple-darwin10 at r158962 for proposed patch...
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00185.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #37 from mrs at gcc dot gnu dot org 2010-05-03 21:39 ---
First question to decide is what direction they want to go with it, that's an
LTO question. Once that is decided, if the direction to do is to change
darwin.c, I have given the 3 lines to do that, what remains undone w
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2010-05-03
22:01 ---
Mike,
I was more interested about the second option since you seem to indicate
that the first option would pessimize the the LTO code generation on i386
darwin. Or did I misunderstand that comment?
--
--- Comment #39 from steven at gcc dot gnu dot org 2010-05-03 22:15 ---
I still don't understand the 32 bits problem.
Without LTO, there is this code in the for 2008_0.i:
L_mumble$non_lazy_ptr:
.indirect_symbol _mumble
In the WPA code mumble is gone in the code for 2008
--- Comment #40 from mrs at gcc dot gnu dot org 2010-05-03 22:47 ---
Jack, if I follow what you want, that's an LTO fix, I don't know the LTO code.
I don't know that that fix is even possible. I think one must do the LTO_SYM
fix, if I had to guess. I don't have the time to embark upon
--- Comment #41 from howarth at nitro dot med dot uc dot edu 2010-05-03
23:41 ---
I wonder if...
/* Given the decl DECL, return the prevailing decl with the same name. */
tree
lto_symtab_prevailing_decl (tree decl)
{
lto_symtab_entry_t ret;
/* Builtins and local symbols are their
--- Comment #42 from mrs at gcc dot gnu dot org 2010-05-04 08:22 ---
Steve, machopic_symbol_defined_p I think is being asked if that symbol is being
defined. It is saying yes, but is isn't defined. Since it was not defined
before, but is with LTO, I was assuming it was a symbol added b
--- Comment #43 from steven at gcc dot gnu dot org 2010-05-07 22:23 ---
FIXED for x86_64-apple-darwin:
http://gcc.gnu.org/viewcvs?view=revision&revision=159173
ix86 and ppc* are still to be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2010-05-08
14:36 ---
Created an attachment (id=20604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20604&action=view)
example failing test case on powerpc-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2010-05-08
14:39 ---
Attached example failing testcase from lto.exp when using proposed patch from
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00577.html on
powerpc-apple-darwin9. In this testcase, the failure appears as...
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2010-05-08
14:55 ---
Opps. The second compile in the failing example failing testcase was...
/Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/
--save-temps -O0 -fwhopr -c -o c_lto_2008_1.o
/Users
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2010-05-08
20:08 ---
Trying...
make -k check-gcc RUNTESTFLAGS="lto.exp --target_board=unix'{-m64}'"
I get...
=== gcc Summary ===
# of expected passes319
# of unexpected failures73
# of u
--- Comment #48 from howarth at nitro dot med dot uc dot edu 2010-05-08
20:14 ---
Created an attachment (id=20607)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20607&action=view)
example failing test case at -m64 on powerpc-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #49 from mrs at gcc dot gnu dot org 2010-05-25 00:29 ---
r159527 has yet more lto work in it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #50 from dominiq at lps dot ens dot fr 2010-06-06 10:50 ---
On x86_64-apple-darwin10.3.0 between revisions 160235 and 160330 the failures
with -m32 went from
FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr
FAIL: gcc.c-torture/execute/builtins/memcpy-c
--- Comment #51 from dominiq at lps dot ens dot fr 2010-06-06 13:46 ---
The 14 tests were fixed by revision 160258 (that has nothing to do with
darwin).
Also I see the following changes, 160257:
=== gcc tests ===
Schedule of variations:
unix/-m32
unix/-m64
Runn
--- Comment #52 from dominiq at lps dot ens dot fr 2010-06-06 20:23 ---
On powerpc-apple-darwin9 I see a similar improvement at revision 160335:
=== gcc tests ===
Schedule of variations:
unix/-m32
unix/-m64
Running target unix/-m32
Using /sw/share/dejagnu/baseb
--- Comment #53 from howarth at nitro dot med dot uc dot edu 2010-06-14
13:14 ---
Now that r160722, the COFF lto patches, are committed to gcc 4.5 branch, we are
clear to backport r159173 as well for the mach-o patches. I've done this
locally and posted the testsuite results at
http://g
51 matches
Mail list logo
