My additional mechanism for dumping intermediate tree representations.
It took me quite some time to figure out how to browse the different types of trees that I am interested in. There are still many types and components that I will need later to finish my restrictive exception specification warning mechanic. I've tried dumping trees but the format of the dumps isn't too useful for learning the underlying format. The standard dump just reformats it as something looking somewhat similar to a C function. The raw dump isn't structured so you have to search for node numbers in order to parse the tree, which makes it very cumbersome. I have just put together some quick generic nested-tree output code and I'm using it to dump some parts of a tree. It is very far from finished as I have to add the different tree-types. I'm working from tree-dump.c:deque_and_dump(). So far it looks like: = func(0x7fffa8e60d00): decl:tree(function_decl). at test/throw.cpp:10. >-DECL_NAME(0x7fffa8e6a1e0): id:tree(identifier_node). | >-IDENTIFIER_POINTER(0x11695b6): foo. | \-IDENTIFIER_LENGTH(0x7fffa8e6a208): 3. | >-DECL_ASSEMBLER_NAME(0x7fffa8e6a960): id:tree(identifier_node). | >-IDENTIFIER_POINTER(0x116960b): _Z3foov. | \-IDENTIFIER_LENGTH(0x7fffa8e6a988): 7. | >-TREE_TYPE(0x7fffa8e6d240): type:tree(function_type). | >-TYPE_MAIN_VARIANT(0x7fffa97d3e40): type:tree(function_type). | | \-TYPE_SIZE(0x7fffa97a87b0): unk:tree(integer_cst). const:tree(integer_cst). const. | | >-int_cst.int_cst.low(0x7fffb1921184): 8. | | >-int_cst.int_cst.high(0x7fffb1921180): 0. | | \-TREE_TYPE(0x7fffa97bb0c0): type:tree(integer_type). | | >-TYPE_NAME(0x7fffa97ca240): id:tree(identifier_node). | | | >-IDENTIFIER_POINTER(0x112e769): bit_size_type. | | | \-IDENTIFIER_LENGTH(0x7fffa97ca268): 13. | | | | | \-TYPE_SIZE(0x7fffa97a8b40): unk:tree(integer_cst). expr:tree(integer_cst). const. | | >-int_cst.int_cst.low(0x7fffb1920e44): 64. | | \-int_cst.int_cst.high(0x7fffb1920e40): 0. | | | \-TYPE_SIZE(0x7fffa97a87b0): unk:tree(integer_cst). const:tree(integer_cst). const. | >-int_cst.int_cst.low(0x7fffb19212b4): 8. | >-int_cst.int_cst.high(0x7fffb19212b0): 0. | \-TREE_TYPE(0x7fffa97bb0c0): type:tree(integer_type). | >-TYPE_NAME(0x7fffa97ca240): id:tree(identifier_node). | | >-IDENTIFIER_POINTER(0x112e769): bit_size_type. | | \-IDENTIFIER_LENGTH(0x7fffa97ca268): 13. | | | \-TYPE_SIZE(0x7fffa97a8b40): unk:tree(integer_cst). const:tree(integer_cst). const. | >-int_cst.int_cst.low(0x7fffb1920f74): 64. | \-int_cst.int_cst.high(0x7fffb1920f70): 0. | \-TREE_CHAIN(0x7fffa8e60c30): = At present it's picking up many things it shouldn't (eg type of a TYPE_SIZE) and discarding many that it should care about (eg func params & statement list), but that's the general format of the dump. I'm guessing it'll average out around 30 dumped lines per code line. I'm currently getting it to dump inside -fdump-tree-original to that dump's target file (which dumps once per function), but it can be called anywhere on any tree. Do you think this would be useful to people (especially beginners)? It would certainly have been useful to me, and the tree structure documentation is unfinished. It would probably be useful as it's own dump entry, say -fdump-tree-original-nodetree or something.
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
I have recently been able to put in a few hours toward my restrictive
exception specification warning mechanic.
I have it warning me correctly on very basic regular code with throw,
try/catch, function calls and exception specifications.
It's also activated by -Wres (restrictive exception specification) and
if it's not activated it has virtually no impact (only one if
statement per "interesting" token, such as a "throw" keyword token).
It doesn't yet work for:
- Templates.
- Function pointers.
- Non-explicit function calls, e.g. operators, con/destructors, casts.
Here's an example that does work:
=
test.cpp
=
class A {};
void foo() throw(int);
void bar() throw(A);
void zug();
void bam() throw(bool)
{
try
{
foo();
}
catch(int) {}
bar();
throw 1.0f;
throw false;
}
void zep() throw(int)
{
zug();
}
=
g++-res -c test.cpp -Wres
=
test/test.cpp: In function 'void bam()':
test/test.cpp:6: warning: RES: 'void bam() throw(bool)' may terminate
due to the following uncaught types being thrown:
test/test.cpp:13: warning: RES: 'A' thrown here by 'void bar()'.
test/test.cpp:3: warning: RES: where 'void bar()' is declared here.
test/test.cpp:14: warning: RES: 'float', thrown explicitly here.
test/test.cpp: In function 'void zep()':
test/test.cpp:18: warning: RES: 'void zep() throw (int)' has an
exception specification, yet it calls 'void zug()' which may throw
anything.
=
I have a few of questions:
1) I'm building TREE_LISTs of types for my internal exception lists
since I needs a bit more functionality than the existing exception
specification structure offers.
I'm using tree_cons() to build my tree nodes.
I use 1 node per thrown type per try/catch block, discardable once the
parser exits the try/catch block
How do I clean up my nodes when I'm done? Should I be manually freeing these?
2) I'm pretty sure that function pointers do not have their associated
exception specification, although the C++ standard requires that this
specification be compared when assigning to function pointers.
This is GCC bug 38069/12255: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38069
It looks as if nobody ever attempted making GCC comply with 15.4.3.
I guess nobody's in the process of fixing this? The bug's unassigned.
Is anyone likely to pick up this bug in the recent future?
3) I am adding a blacklist/whitelist mechanism for preventing calls to
functions declared in certain files being checked so that the warnings
don't become excessive. I was thinking of using:
-Wres-bl=, Wres-wl=
where is a list of files enclosed by either <> or ""
(depending on path-type) with paths, hopefully wildcard-able.
eg: -Wres-wl=<*>"cp/*""cgraph.h" -Wres-bl="cp/decl.h" wouldn't check
declarations inside any <> includes, "cgraph.h", or anything inside
"cp/" except for "cp/decl.h"
I think there's a mechanism for suppressing warnings already (although
I had a brief glance now and didn't see it), but unfortunately I need
to suppress the warnings based on the call-target location not the
warning location, and I also need to know whether a call is warn-able
far in advance of issuing the warning.
The questions are:
3a) Is there a better or more consistent way to specify a
whitelist/blacklist than my syntax above?
3b) What's the best or most consistent way of storing a set of
strings? My ideas so far are: make a TREE_LIST of IDENTIFIER_NODEs
storing the strings, use a VEC (not sure how yet), or manually
alloc/dealloc my own list.
4) I'm placing the bulk of my code at the end of [cp/except.c] but I
feel it's probably better as it's own file, [cp/res.c].
Should I use my own file, or just stick with appending [cp/except.c]?
How do I go about adding a .c file to the make? [configure] looks
hideous, please say I don't have to hack inside there.
5) I'm adding this because a) I want to use it myself and b) because
many people requested it. But it's taking me a lot of time. I'm also
about to finish up my current job. I have to ask - is there any
sponsorship available, because if there were I could work on this
full-time instead of the occasional few hours a month, and perhaps fix
the bug in #2.
Re: CSE bug when narrowing constants
On 11/28/08 16:02:11, Gary Funck wrote: > > I'd think that somewhere in there gen_lowpart() needs to > be called. I posted a suggested patch: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01466.html which fixes the reported problem.
CSE bug when narrowing constants
(Configuration: x86_64, GCC 4.2.3 base line)
I've run into a problem where GCSE decides to kill a
conditional jump instruction because it thinks that the
result is always false. This happens when GCSE decides
to propagate a constant that is "narrowed" [the original
mode of the constant is word_mode (DImode) and the use of
the constant is in a narrower mode (SImode)].
This situation arises inside the code generated by our
GCC/UPC compiler, and so far I haven't been able to
come up with a regular C test case that demonstrates
the failure. For efficiency reasons, internal to the
compiler, we overlay a 16 byte struct on top of a TImode
value. The 16 byte struct is the representation of UPC's
"pointer-to-shared", which is a potentially cross-node
pointer consisting of three parts (vaddr, thread, phase).
It looks like this:
typedef struct {
void *vaddr;
unsigned int thread;
unsigned int phase;
}
__attribute__ ((__aligned__(16)))
upc_shared_ptr_t;
Although not allowed by GCC, you can think of it has having
an additional "__attribute__ ((__mode__(__TI__)))" specification.
Here is an excerpt from the offending RTL that when passed to
GCSE will lead to incorrect deletion of a conditional jump:
[...]
(insn 19 16 21 2 (set (reg:DI 81)
(const_int 4294967296 [0x1])) 81 {*movdi_1_rex64} (nil)
(nil))
(insn 21 19 24 2 (set (subreg:DI (reg:TI 70 [ D.2967 ]) 8)
(reg:DI 81)) 81 {*movdi_1_rex64} (nil)
(nil))
(insn 24 21 25 2 (set (reg:SI 60 [ p$phase ])
(const_int 1 [0x1])) 40 {*movsi_1} (nil)
(nil))
(insn 25 24 26 2 (set (reg:SI 61 [ p$thread ])
(subreg:SI (reg:TI 70 [ D.2967 ]) 8)) 40 {*movsi_1} (nil)
(expr_list:REG_EQUAL (const_int 4294967296 [0x1])
(nil)))
[...]
;; Start of basic block 5, registers live: (nil)
(code_label 53 52 54 5 2 "" [2 uses])
(note 54 53 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 56 54 57 5 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 61 [ p$thread ])
(const_int 0 [0x0]))) 3 {*cmpsi_ccno_1} (nil)
(nil))
(jump_insn 57 56 59 5 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 63)
(pc))) 531 {*jcc_1} (nil)
(expr_list:REG_BR_PROB (const_int 7000 [0x1b58])
(nil)))
[...]
The conditional jump instruction formed by instructions
56 and 57 above is deleted because GCSE thinks that
(reg:SI 61 [ p$thread ]) is non-zero. It comes to this
conclusion when it propagates the
REG_EQUAL (const_int 4294967296 [0x1])
value listed in instruction 25:
(insn 25 24 26 2 (set (reg:SI 61 [ p$thread ])
(subreg:SI (reg:TI 70 [ D.2967 ]) 8)) 40 {*movsi_1} (nil)
(expr_list:REG_EQUAL (const_int 4294967296 [0x1])
(nil)))
Note that it takes 33 bits to express 0x1, and it won't
fit into an SImode container. What CSE/GCSE should have done here is
written that REG_EQUAL note as follows:
(insn 25 24 26 2 (set (reg:SI 61 [ p$thread ])
(subreg:SI (reg:TI 70 [ D.2967 ]) 8)) 40 {*movsi_1} (nil)
(expr_list:REG_EQUAL (const_int 0)
(nil)))
because only the lower 32 bits of the value are relevant.
In that case, the conditional jump can be rewritten into
an unconditional jump, but certainly not deleted.
The code that decides it is OK to use the wider constant,
without adjustment to the narrow mode is here:
/* If we are looking for a CONST_INT, the mode doesn't really matter, as
long as we are narrowing. So if we looked in vain for a mode narrower
than word_mode before, look for word_mode now. */
if (p == 0 && code == CONST_INT
&& GET_MODE_SIZE (GET_MODE (x)) < GET_MODE_SIZE (word_mode))
{
x = copy_rtx (x);
PUT_MODE (x, word_mode);
p = lookup (x, SAFE_HASH (x, VOIDmode), word_mode);
}
The logic above is OK as far as it goes, but the subsequent
return of the unadjusted wider constant causes problems:
for (p = p->first_same_value; p; p = p->next_same_value)
if (GET_CODE (p->exp) == code
/* Make sure this is a valid entry in the table. */
&& exp_equiv_p (p->exp, p->exp, 1, false))
return p->exp;
I'd think that somewhere in there gen_lowpart() needs to
be called. I'd appreciate your review of the above analysis
and any suggestions that you might have on implementing a fix.
Re: Functional Purity
When categorising a functions purity i also would like to identify the cause of the impurity. In particular for a function that is impure i want to categorise the impurity cause as: * modifies global state * modifies a function parameter * modifies the object state (this is an extension of the function parameter on the "this" parameter) Hi, Sounds like you want to (at least): 1) automatically qualify every declaration (including parameters, member declarations, and member function declarations) with 'const'. 2) forbid the use of the '=' operator family (including +=, etc...) (might be redundant with #1) Does this accurately summarize your proposed analysis? As a crude start, maybe you could alter the syntax trees, and let the rest of compilation catch any resulting violations? The reason for posting this is to ask. Is there code in GCC that already does something "similar" in say one of the optimisation passes so i can get a look at how to get started on this? Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
Re: Problem with x64 SEH macro implementation for ReactOS
Kai Tietz writes: >Hmm, yes and no. First the exception handler uses the .pdata and .xdata >section for checking throws. But there is still the stack based exception >mechanism as for 32-bit IIRC. No. The mechanism is completely different. The whole point of the unwind tables is to remove the overhead of maintaining the linked list of records on the stack. It works just like DWARF2 exceptions in this respect. >No, this isn't that curious as you mean. In the link you sent me, it is >explained. The exception handler tables (.pdata/.xdata) are optional and >not necessarily required. This is what Microsoft's documentation says: Every function that allocates stack space, calls other functions, saves nonvolatile registers, or uses exception handling must have a prolog whose address limits are described in the unwind data associated with the respective function table entry. In this very limited case RtlUnwindEx() can indeed unwind a function without it having any unwind info associated with it. If RtlUnwindEx() can't find the unwind data for a function then it assumes that the stack pointer points directly at the return address. To unwind through the function it pops the top of stack to get the next frame's RIP and RSP values. Otherwise RltUnwindEx() needs the unwind information. The restrictions on the format of prologue and epilogue only exist to making handle the case where the current RIP points to the prologue or epilogue much easier. Without the unwind info RtlUnwindEx() has no way of knowing where the prologue is. There's a very detailed explaination on how Windows x64 exceptions work, including RltUnwindEx() on this blog: http://www.nynaeve.net/?p=113 >But in general I agree, that the generation of .pdata/.xdata sections >would be a good thing for better support of MS abis by gcc. I'm not advocating that they should be added to GCC now. I'm just pointing out that without them 64-bit SEH macros will be of limitted use. Ross Ridge
Functional Purity
Hi all, I want to use GCC to categorise "functional purity" in C++. My definition will differ from classic functional purity. In particular: A function is considered pure if it makes no changes to existing memory or program state. There may be a few exceptions to this rule such as for new/malloc in that they change program state (allocating new memory) but will be manually marked as pure. However free/delete should be marked as impure (modifying function parameter, but not global state). This means that a function which is pure can create new objects/memory and make changes to those new objects, but the existing memory must remain unchanged. When categorising a functions purity i also would like to identify the cause of the impurity. In particular for a function that is impure i want to categorise the impurity cause as: * modifies global state * modifies a function parameter * modifies the object state (this is an extension of the function parameter on the "this" parameter) The reason for posting this is to ask. Is there code in GCC that already does something "similar" in say one of the optimisation passes so i can get a look at how to get started on this? Thanks, Brendon.
gcc-4.4-20081128 is now available
Snapshot gcc-4.4-20081128 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081128/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 142264 You'll find: gcc-4.4-20081128.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081128.tar.bz2 C front end and core compiler gcc-ada-4.4-20081128.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081128.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081128.tar.bz2 C++ front end and runtime gcc-java-4.4-20081128.tar.bz2 Java front end and runtime gcc-objc-4.4-20081128.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081128.tar.bz2The GCC testsuite Diffs from 4.4-20081121 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Several puzzles about gcc top level makefile
"Cheng bin" <[EMAIL PROTECTED]> writes: > 1 : At the end of that makefile , There is a section noted as > "Regenerating top level configury". > It is clear what it do, but for what? Where is this piece of > code used in building procedure? Those pieces of code are used by developers if and when they change the original source files Makefile.tpl, configure.ac, etc. > 2 : At lines around 462, There is a variable named "RECURSE_FLAGS", I > also puzzled > about its usage. It says that "When doing recursive invocations > of the top-level Makefile, > we don't want the outer make to evaluate them, so we pass these > variables down > unchanged. " Does it mean we will recall the top level makefile? > if so, Is "RECURSE_FLAGS" have any relations with the first > question. Maybe both > "Regenerating top level configury" and "RECURSE_FLAGS" is used > to compile gcc > several times in bootstrap. > Here I need a confirmation. If you look at the uses of RECURSE_FLAGS_TO_PASS you will see the cases where the top-level Makefile is reused in a recursive call to make. > 3 : For the cross compiler, I configured and compiled gcc twice, once > with just language C > supported, once with languages C/C++ supported. I compared the > two top level makefile > generated by configure and found the difference is that > libiberty and libstdc++-v3 is > compiled for target at the second time. So here is the question: > libstdc++v3 is compiled > for target as the c++ runtime library, but what libiberty for? I > can only infer that libstdc++v3 > needs it(otherwise why the first time which only supports c > language do not have it > compiled?). Unfortunately, I did not find any code in > libstdc++-v3 which calls functions > in libiberty. libstdc++-v3 uses the C++ demangler from libiberty. Ian
EPEIGON---xreiazetai aima o Dimitris- Proothiste to pantou !!!!!!!!!!!!!
Epeidi ta pragmata einai polu sovara kai i katastasi tou Dimitri krisimi, 8a parakalousame osous exoun omada aimatos 0- (miden arnitiko) kmporoun na dwsoun aima na perasoun apo ena apo ola ta nosokomeia tis xwras dinontas to onoma k to nosokomeio sto opoio paei to aima. Gia ton Dimitri Xourmouziadi sto Papanikolaou 8essalonikis. Prepei na mazeutoun panw apo 50 fiales aimatos k oi filoi k oikogeneia exoun mazepsei molis 8. Kante ena forward, peite to stous filous sas k isws kapoios na mporei na ton swsei. O Dimitris idi mas euxaristei olous sigoura.. akomi k an vrisketai se Kwma auti ti stigmi ' Paidia, prwwthiste to sas parakalw. Xreiazetai aima. Opoios mporei Sti teliki 8a mporouse na einai o opoiosdipote apo emas... George Georgiadis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
EPEIGON---xreiazetai aima o Dimitris- Proothiste to pantou !!!!!!!!!!!!!
Epeidi ta pragmata einai polu sovara kai i katastasi tou Dimitri krisimi, 8a parakalousame osous exoun omada aimatos 0- (miden arnitiko) kmporoun na dwsoun aima na perasoun apo ena apo ola ta nosokomeia tis xwras dinontas to onoma k to nosokomeio sto opoio paei to aima. Gia ton Dimitri Xourmouziadi sto Papanikolaou 8essalonikis. Prepei na mazeutoun panw apo 50 fiales aimatos k oi filoi k oikogeneia exoun mazepsei molis 8. Kante ena forward, peite to stous filous sas k isws kapoios na mporei na ton swsei. O Dimitris idi mas euxaristei olous sigoura.. akomi k an vrisketai se Kwma auti ti stigmi ' Paidia, prwwthiste to sas parakalw. Xreiazetai aima. Opoios mporei Sti teliki 8a mporouse na einai o opoiosdipote apo emas... George Georgiadis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Problem with x64 SEH macro implementation for ReactOS
Hi Ross,
[EMAIL PROTECTED] wrote on 27.11.2008 23:36:22:
> Kai Tietz writes:
> >Well, you mean the SEH tables on stack.
>
> No, I mean the ABI required unwind information.
So you speak about .pdata and .xdata. Well, those aren't implemented.
First step would be to teach gas to generate those structures by new
keywords. Then afterwards gcc can emit them on function entry. By this
.pdata and .xdata can be generated.
> > Well, those aren't implemented (as they aren't for 32-bit).
>
> 64-bit SEH handling is completely different from 32-bit SEH handling.
> In the 64-bit Windows ABI exceptions are handled using unwind tables
> similar in concept to DWARF2 exceptions. There are no SEH tables on
> the stack. In the 32-bit ABI exceptions are handled using a linked list
> of records on the stack, similar to SJLJ exceptions.
Hmm, yes and no. First the exception handler uses the .pdata and .xdata
section for checking throws. But there is still the stack based exception
mechanism as for 32-bit IIRC. Just the segment is %gs and offsets used to
TEB are different (reasoned by different pointer sizes).
> > But the the unwinding via RtlUnwind and RtlUnwindEx do their job even
> >for gcc compiled code quite well
>
> I don't see how it would be possible in the general case. Without the
> unwind talbes Windows doesn't have the required information to unwind
> through GCC compiled functions.
No, this isn't that curious as you mean. In the link you sent me, it is
explained. The exception handler tables (.pdata/.xdata) are optional and
not necessarily required. The major point here is that the epilogue has
conformancy (as it has for general functions in gcc). The constrains on
prologue are also kept by gcc already. The interesting issue is that the
Unwind code will search for the stack frame adjustment by a 'leaq
constant(%rsp),%rsp'. This is in general (but not in all cases) generated
by gcc w64. So the RtlUnwind is still able to do its job, even when there
is no Unwind information in .pdata/.xdata.
But in general I agree, that the generation of .pdata/.xdata sections
would be a good thing for better support of MS abis by gcc.
Cheers,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: Build fails on i386-apple-darwin8.11.1
On Sat, Nov 1, 2008 at 7:11 AM, Jack Howarth <[EMAIL PROTECTED]> wrote: > On Sat, Nov 01, 2008 at 11:14:14AM +, Andrew Haley wrote: >> Jack Howarth wrote: >> > On Fri, Oct 31, 2008 at 02:30:25PM -0700, Andrew Pinski wrote: >> >> I get the following build failure on i386-apple-darwin8.11.1. >> >> >> >> >> >> libtool: link: /Users/apinski/src/local/gcc/objdir/gcc/gcj >> >> -B/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/ >> >> -B/Users/apinski/src/local/gcc/objdir/gcc/ -ffloat-store >> >> -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert >> >> --main=gnu.gcj.convert.Convert -shared-libgcc >> >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/.libs >> >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava >> >> ./.libs/libgcj.dylib >> >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libstdc++-v3/src >> >> -L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs >> >> -lpthread -ldl >> >> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: >> >> __Unwind_GetIPInfo >> >> collect2: ld returned 1 exit status >> >> warning: no debug map in executable (-arch i386) >> >> warning: no debug map in executable (-arch i386) >> >> make[3]: *** [jv-convert] Error 1 >> >> make[3]: *** Waiting for unfinished jobs >> >> >> >> >> >> Last known build that worked was revision 141116. >> >> >> >> Thanks, >> >> Andrew Pinski >> > >> > The last build I did on i686-apple-darwin9 was r141456 and it built >> > libjava fine. >> > I haven't done a build since (testing llvm 2.4 at the moment) but I would >> > suspect... >> > >> > 2008-10-31 Andrew Haley <[EMAIL PROTECTED]> >> > >> > * Makefile.am (install-data-local): Correct symlink paths for >> > SDK-style installed JARs. >> > Correct symlinks for headers when DESTDIR is set. >> > >> > as the culrpit. >> >> I don't see how. All my patch did was move around the symlinks for java_home >> when --with-java-home is used. >> >> _Unwind_GetIPInfo should be in libgcc. I'm not sure where the extra leading >> __ came from: is Darwin one of those systems that prefixes all C symbols with >> an extra underscore? >> >> Is __Unwind_GetIPInfo in the built libgcc? >> >> Is >> #define HAVE_GETIPINFO 1 >> in config.log ? >> >> Andrew. > > Andrew, >I was just pointing out the only change related to libjava between > Andrew's failed > build and my last successful one. Actually, I just built r141510 last night > without > problems on i686-apple-darwin9 against Xcode 3.1.2 Preview and will post the > testresults > to the mailing list shortly. So it turned out it was a patch to config/unwind_ipinfo.m4 which caused the failure. I filed it as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38300. Thanks, Andrew Pinski
